- 29 Feb, 2016 40 commits
-
-
Souvik Kumar Chakravarty authored
BugLink: http://bugs.launchpad.net/bugs/1520457 This implements debugfs interfaces for reading the telemetry samples from SSRAM and configuring firmware trace verbosity. Interface created under /sys/kernel/debug/telemetry soc_states: SoC Device and Low Power States pss_info: Info from the Primary SubSystem ioss_info: Info from IO SubSusytem pss_trace_verbosity: Read/Modify PSS F/W trace verbosity ioss_trace_verbosity: Read/Modify IOSS F/W trace verbosity. Signed-off-by:
Souvik Kumar Chakravarty <souvik.k.chakravarty@intel.com> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> (cherry picked from commit 87bee290) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Souvik Kumar Chakravarty authored
BugLink: http://bugs.launchpad.net/bugs/1520457 Telemetry platform driver implements the telemetry interfaces. Currently it supports ApolloLake. It uses the PUNIT and PMC IPC interfaces to configure the telemetry samples to read. The samples are read from a Secure SRAM region. Signed-off-by:
-
Souvik Kumar Chakravarty authored
BugLink: http://bugs.launchpad.net/bugs/1520457 Telemetry Device is created by the pmc_ipc driver. Resources are populated according SSRAM region as indicated by the BIOS tables. Signed-off-by:
-
Qipeng Zha authored
BugLink: http://bugs.launchpad.net/bugs/1520457 BIOS restructure exported memory resources for Punit in acpi table, So update resources for Punit. Signed-off-by:
Qipeng Zha <qipeng.zha@intel.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Souvik Kumar Chakravarty authored
BugLink: http://bugs.launchpad.net/bugs/1520457 Intel PM Telemetry is a software mechanism via which various SoC PM and performance related parameters like PM counters, firmware trace verbosity, the status of different devices inside the SoC, etc. can be monitored and analyzed. The different samples that may be monitored can be configured at runtime via exported APIs. This patch adds the telemetry core driver that implements basic exported APIs. Signed-off-by:
-
Qipeng Zha authored
BugLink: http://bugs.launchpad.net/bugs/1520457 intel_punit_ipc_command() maybe called when in or out data pointers are NULL. Signed-off-by:
-
Qipeng Zha authored
BugLink: http://bugs.launchpad.net/bugs/1520457 This driver provides support for P-Unit mailbox IPC on Intel platforms. The heart of the P-Unit is the Foxton microcontroller and its firmware, which provide mailbox interface for power management usage. Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1520457Signed-off-by:
-
Paolo Pisati authored
Disable support for the ZTE ZX Soc that was oopings when probed upon boot. Signed-off-by:
Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by:
-
Paolo Pisati authored
Boot essential for the BBB (MFD_TPS65217 and its regulator REGULATOR_TPS65217) Signed-off-by:
-
Mika Kuoppala authored
BugLink: http://bugs.launchpad.net/bugs/1527462 There is conflicting info between E0 and F0 steppings for this workarounds. Trust more authoritative source and be conservative and extend also for F0. This prevents numerous (>50) gpu hangs with SKL GT4e during piglit run. References: HSD: gen9lp/2134184 Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449505785-20812-1-git-send-email-mika.kuoppala@intel.com (cherry picked from commit 6686ece1) Cc: stable@vger.kernel.org # v4.3+ Signed-off-by:
Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 344df980) Signed-off-by:
-
Mika Kuoppala authored
BugLink: http://bugs.launchpad.net/bugs/1527462 Add Skylake Intel Graphics GT4 PCI IDs v2: Rebase Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Sagar Arun Kamble authored
BugLink: http://bugs.launchpad.net/bugs/1527462 WaRsDisableCoarsePowerGating: Coarse Power Gating (CPG) needs to be disabled for platforms prior to BXT B0 and SKL GT3/GT4 till E0. v2: Added GT3/GT4 Check. Change-Id: Ia3c4c16e050c88d3e259f601054875c812d69c3a Signed-off-by:
Alex Dai <yu.dai@intel.com> [danvet: Align continuation properly.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> (back ported from commit f2d2fe95) Signed-off-by:
-
Harish Chegondi authored
BugLink: http://bugs.launchpad.net/bugs/1461360 Call uncore_pci_box_ctl() function to get the PMON box control MSR offset instead of hard coding the offset. This would allow us to use this snbep_uncore_pci_init_box() function for other PCI PMON devices whose box control MSR offset is different from SNBEP_PCI_PMON_BOX_CTL. Signed-off-by:
Harish Chegondi <harish.chegondi@intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andi Kleen <andi.kleen@intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Harish Chegondi <harish.chegondi@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Kan Liang <kan.liang@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Link: http://lkml.kernel.org/r/872e8ef16cfc38e5ff3b45fac1094e6f1722e4ad.1449470704.git.harish.chegondi@intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> (cherry picked from commit dae25530) Signed-off-by:
-
Harish Chegondi authored
BugLink: http://bugs.launchpad.net/bugs/1461360 Knights Landing uncore performance monitoring (perfmon) is derived from Haswell-EP uncore perfmon with several differences. One notable difference is in PCI device IDs. Knights Landing uses common PCI device ID for multiple instances of an uncore PMU device type. In Haswell-EP, each instance of a PMU device type has a unique device ID. Knights Landing uncore components that have performance monitoring units are UBOX, CHA, EDC, MC, M2PCIe, IRP and PCU. Perfmon registers in EDC, MC, IRP, and M2PCIe reside in the PCIe configuration space. Perfmon registers in UBOX, CHA and PCU are accessed via the MSR interface. For more details, please refer to the public document: https://software.intel.com/sites/default/files/managed/15/8d/IntelXeonPhi%E2%84%A2x200ProcessorPerformanceMonitoringReferenceManual_Volume1_Registers_v0%206.pdfSigned-off-by:
-
Harish Chegondi authored
BugLink: http://bugs.launchpad.net/bugs/1461360 Knights Landing core is based on Silvermont core with several differences. Like Silvermont, Knights Landing has 8 pairs of LBR MSRs. However, the LBR MSRs addresses match those of the Xeon cores' first 8 pairs of LBR MSRs Unlike Silvermont, Knights Landing supports hyperthreading. Knights Landing offcore response events config register mask is different from that of the Silvermont. This patch was developed based on a patch from Andi Kleen. For more details, please refer to the public document: https://software.intel.com/sites/default/files/managed/15/8d/IntelXeonPhi%E2%84%A2x200ProcessorPerformanceMonitoringReferenceManual_Volume1_Registers_v0%206.pdfSigned-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1398274 TPM2 supports authorization policies, which are essentially combinational logic statements repsenting the conditions where the data can be unsealed based on the TPM state. This patch enables to use authorization policies to seal trusted keys. Two following new options have been added for trusted keys: * 'policydigest=': provide an auth policy digest for sealing. * 'policyhandle=': provide a policy session handle for unsealing. If 'hash=' option is supplied after 'policydigest=' option, this will result an error because the state of the option would become mixed. Signed-off-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Tested-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Acked-by:
Peter Huewe <peterhuewe@gmx.de> (cherry picked from commit 5beb0c43) Signed-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1398274 Added 'hash=' option for selecting the hash algorithm for add_key() syscall and documentation for it. Added entry for sm3-256 to the following tables in order to support TPM_ALG_SM3_256: * hash_algo_name * hash_digest_size Includes support for the following hash algorithms: * sha1 * sha256 * sha384 * sha512 * sm3-256 Signed-off-by:
James Morris <james.l.morris@oracle.com> Reviewed-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1398274 The trusted keys option parsing allows specifying the same option multiple times. The last option value specified is used. This is problematic because: * No gain. * This makes complicated to specify options that are dependent on other options. This patch changes the behavior in a way that option can be specified only once. Reported-by:
James Morris James Morris <jmorris@namei.org> Reviewed-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1533035 With ACPI _DSD (introduced in ACPI v5.1) it is now possible to pass device configuration information from ACPI in addition to DT. In order to support this, convert the driver to use the unified device property accessors instead of DT specific. Change to ordering a bit so that we first try platform data and if that's not available look from device properties. ACPI *CNT methods are then used as last resort to override everything else. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Jarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 4c5301ab) Signed-off-by:
-
Andy Shevchenko authored
BugLink: http://bugs.launchpad.net/bugs/1533035 The HS-UART host controller driver needs to know certain properties like width of the register set if it cannot get that information from ACPI or DT. In order to support non-ACPI systems we pass this information to the driver via device properties. Signed-off-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1533035 Intel Skylake the LPSS I2C pad circuit has internal delays that require programming non-zero SDA hold time for the I2C host controller. If this is not done communication to slave devices may fail with arbitration lost errors like the one seen below taken from Lenovo Yoga 900: i2c_hid i2c-SYNA2B29:00: Fetching the HID descriptor i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: cmd=20 00 i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration To fix this we follow what the Windows driver is doing and pass the default SDA hold time of 230 ns to all Intel Skylake host controllers. This still allows the platform to override these values by passing special ACPI methods SSCN and FMCN. Reported-by:
Kevin Fenzi <kevin@scrye.com> Signed-off-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1533035 If the boot firmware does not support ACPI we need a way to pass device configuration information to the drivers. The unified device properties API already supports passing platform data via properties so let's take advantage of that and allow probe drivers to pass set of properties to the host controller driver. In order to do that we need to be able to modify the MFD cell corresponding the host controller, so make the core driver to take copy of the cell instead of using it directly. Then we can assign info->pset to the resulting copy of a cell and let the MFD core to assign that to the resulting device. Signed-off-by:
-
Andy Shevchenko authored
BugLink: http://bugs.launchpad.net/bugs/1533035 In the similar way like we do for the platform data we propagate the device properties. For example, in case of Intel LPSS drivers we may provide a specific property to tell the actual device driver an additional information such as platform name. Signed-off-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1533035 If multiple devices share single firmware node like it is case with MFD devices, the same firmware node (ACPI) is assigned to all of them. The function also modifies the shared firmware node in order to preserve secondary firmware node of the device in question. If the new device which is sharing the firmware node does not have secondary node it will be NULL which will be assigned to the secondary node of the shared firmware node losing all built-in properties. Prevent this by setting the secondary firmware node only if the replacement is non-NULL. Print also warning if someone tries to overwrite secondary node that has already been assigned. Signed-off-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1533035 Make it possible to pass built-in device properties to platform device drivers. This is useful if the system does not have any firmware interface like Device Tree or ACPI which provides these. Properties associated with the platform device will be automatically released when the corresponding device is removed. Suggested-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1533035 It is convenient if the property set associated with the device secondary firmware node is a copy of the original. This allows passing property set from a stack for example for devices created dynamically. This also ties the property set lifetime to the associated device. Because of that we provide new function device_remove_property_set() that is used to disassociate and release memory allocated for the property set. Signed-off-by:
-
Andy Shevchenko authored
BugLink: http://bugs.launchpad.net/bugs/1533035 The struct fwnode has notion of secondary fwnode. This is supposed to used as fallback if the primary firmware interface (DT, ACPI) does not have the property in question. However, the current implementation never checks the secondary node which prevents one to add default "built-in" properties to devices. This patch adds fallback to the secondary fwnode if the primary fwnode returns that the property does not exists. Signed-off-by:
-
Andy Shevchenko authored
BugLink: http://bugs.launchpad.net/bugs/1533035 Change return code to be in align with OF and built-in device properties error codes. In particular -EINVAL means property is not found. Signed-off-by:
-
Andy Shevchenko authored
BugLink: http://bugs.launchpad.net/bugs/1533035 There is no functional change. Signed-off-by:
-
Heikki Krogerus authored
BugLink: http://bugs.launchpad.net/bugs/1533035 Marcos for easier creation of build-in property entries. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
-
Andy Shevchenko authored
BugLink: http://bugs.launchpad.net/bugs/1533035 We may save a lot of lines of code and space by keeping single values inside the struct property_entry. Refactor the implementation to do so. Signed-off-by:
-
Andy Shevchenko authored
BugLink: http://bugs.launchpad.net/bugs/1533035 Instead of using the type and nval fields we will use length (in bytes) of the value. The sanity check is done in the accessors. The built-in property accessors are split in the same way such as device tree. Signed-off-by:
-
Andy Shevchenko authored
BugLink: http://bugs.launchpad.net/bugs/1533035 To be in align with the rest of fwnode types we rename the built-in property set ones, i.e. is_pset() -> is_pset_node() to_pset() -> to_pset_node() There is no functional change. Signed-off-by:
-
Andy Shevchenko authored
BugLink: http://bugs.launchpad.net/bugs/1533035 Currently the property accessors unconditionally fall back to built-in property set as a last resort. Make this strict and return an error in case the type of fwnode is unknown. This is actually a follow up to the commit 4fa7508e (device property: Return -ENXIO if there is no suitable FW interface). Signed-off-by:
-
Mahesh Salgaonkar authored
BugLink: http://bugs.launchpad.net/bugs/1537881 https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-January/138011.html When secondaries are napping in kvm_unsplit_nap() with hwthread_req = 1, the HMI goes ignored even though subcores are already exited the guest. Hence HMI keeps waking up secondaries from nap in a loop and secondaries always go back to nap since no vcore is assigned to them. This makes impossible for primary thread to get hold of secondary threads resulting into a soft lockup in KVM path. This patch fixes this by adding a HMI check just before the thread goes to unsplit nap. Signed-off-by:
Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by:
-
Mahesh Salgaonkar authored
BugLink: http://bugs.launchpad.net/bugs/1537881 https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-January/138010.html When a guest is assigned to a core it converts the host Timebase (TB) into guest TB by adding guest timebase offset before entering into guest. During guest exit it restores the guest TB to host TB. This means under certain conditions (Guest migration) host TB and guest TB can differ. When we get an HMI for TB related issues the opal HMI handler would try fixing errors and restore the correct host TB value. With no guest running, we don't have any issues. But with guest running on the core we run into TB corruption issues. If we get an HMI while in the guest, the current HMI handler invokes opal hmi handler before forcing guest to exit. The guest exit path subtracts the guest TB offset from the current TB value which may have already been restored with host value by opal hmi handler. This leads to incorrect host and guest TB values. With split-core, things become more complex. With split-core, TB also gets split and each subcore gets its own TB register. When a hmi handler fixes a TB error and restores the TB value, it affects all the TB values of sibling subcores on the same core. On TB errors all the thread in the core gets HMI. With existing code, the individual threads call opal hmi handle independently which can easily throw TB out of sync if we have guest running on subcores. Hence we will need to co-ordinate with all the threads before making opal hmi handler call followed by TB resync. This patch introduces a sibling subcore state structure (shared by all threads in the core) in paca which holds information about whether sibling subcores are in Guest mode or host mode. An array in_guest[] of size MAX_SUBCORE_PER_CORE=4 is used to maintain the state of each subcore. The subcore id is used as index into in_guest[] array. Only primary thread entering/exiting the guest is responsible to set/unset its designated array element. On TB error, we get HMI interrupt on every thread on the core. Upon HMI, this patch will now force guest to vacate the core/subcore. Primary thread from each subcore will then turn off its respective bit from the above bitmap during the guest exit path just after the guest->host partition switch is complete. All other threads that have just exited the guest OR were already in host will wait until all other subcores clears their respective bit. Once all the subcores turn off their respective bit, all threads will will make call to opal hmi handler. It is not necessary that opal hmi handler would resync the TB value for every HMI interrupts. It would do so only for the HMI caused due to TB errors. For rest, it would not touch TB value. Hence to make things simpler, primary thread would call TB resync explicitly once for each core immediately after opal hmi handler instead of subtracting guest offset from TB. TB resync call will restore the TB with host value. Thus we can be sure about the TB state. One of the primary threads exiting the guest will take up the responsibility of calling TB resync. It will use one of the top bits (bit 63) from subcore state flags bitmap to make the decision. The first primary thread (among the subcores) that is able to set the bit will have to call the TB resync. Rest all other threads will wait until TB resync is complete. Once TB resync is complete all threads will then proceed. Signed-off-by:
-
Mahesh Salgaonkar authored
BugLink: http://bugs.launchpad.net/bugs/1537881 https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-January/138009.html OPAL_CALL wrapper code sticks the r1 (stack pointer) into PACAR1 purely for debugging purpose only. The power7_wakeup* functions relies on stack pointer saved in PACAR1. Any opal call made using opal wrapper (directly or in-directly) before we fall through power7_wakeup*, then it ends up replacing r1 in PACAR1(r13) leading to kernel panic. So far we don't see any issues because we have never made any opal calls using OPAL wrapper before power7_wakeup*. But the subsequent HMI patch would need to invoke C calls during cpu wakeup/idle path that in-directly makes opal call using opal wrapper. This patch facilitates the subsequent HMI patch by removing usage of PACAR1 from opal call wrapper. Signed-off-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1446906 This is a horrendous HACK, that is a temporary fix until typesplitting can land. Store off the path reference on connection to make up for the path being wiped out on socket shutdown. Signed-off-by:
John Johansen <john.johansen@canonical.com> Reviewed-by:
Tyler Hicks <tyhicks@canonical.com> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1537923Signed-off-by:
-
