- 23 Mar, 2014 26 commits
-
-
Michael Neuling authored
The facility unavailable exception can be triggered from userspace by accessing PMU registers when EBB is not enabled. This causes the included pr_err() to run, hence spamming the kernel log buffer. This avoids this by rate limiting these messages. Signed-off-by:
Michael Neuling <mikey@neuling.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Michael Ellerman authored
Currently we reject events which have the L3 bank == 1, such as 0x000084918F, because the cache field is non-zero. However that is incorrect, because although the bank is non-zero, the value we would write into MMCRC is zero, and so we can count the event. So fix the check to ignore the bank selector when checking whether the cache selector is non-zero. Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Cody P Schafer authored
gpci and 24x7 expose some device specific attributes. Add some documentation for them. Signed-off-by:
Cody P Schafer <cody@linux.vnet.ibm.com> Signed-off-by:
-
Cody P Schafer authored
The commit adds a Kconfig option which allows the hv_gpci and hv_24x7 PMUs, added in the preceeding commits, to be built. Signed-off-by:
-
Cody P Schafer authored
This provides a basic interface between hv_24x7 and perf. Similar to the one provided for gpci, it lacks transaction support and does not list any events. Example usage via perf tool: perf stat -e 'hv_24x7/domain=2,offset=8,starting_index=0,lpar=0xffffffff/' -r 0 -C 0 -x ' ' sleep 0.1 Signed-off-by:
-
Cody P Schafer authored
This provides a basic link between perf and hv_gpci. Notably, it does not yet support transactions and does not list any events (they can still be manually composed). Example usage via perf tool: perf stat -e 'hv_gpci/counter_info_version=3,offset=0,length=8,secondary_index=0,starting_index=0xffffffff,request=0x10/' -r 0 -C 0 -x ' ' sleep 0.1 Signed-off-by:
-
Cody P Schafer authored
Add two macros which generate functions to extract the relevent bits from event->attr.config{,1,2}. EVENT_DEFINE_RANGE() defines an accessor for a range of bits in the event, as well as a "max" function that gives the maximum value of the field based on the bit width. EVENT_DEFINE_RANGE_FORMAT() defines the accessor & max routine and also a format attribute for use in the PMU's attr_groups. Signed-off-by: -
Cody P Schafer authored
This exposes a simple way to grab the firmware provided collect_priveliged, ga, expanded, and lab capability bits. All of these bits come in from the same gpci request, so we've exposed all of them. Only the collect_priveliged bit is really used by the hv-gpci/hv-24x7 code, the other bits are simply exposed in sysfs to inform the user. Signed-off-by:
-
Cody P Schafer authored
24x7 (also called hv_24x7 or H_24X7) is an interface to obtain performance counters from the hypervisor. These counters do not have a fixed format/possition and are instead documented in a "24x7 Catalog", which is provided by the hypervisor (that interface is also documented paritialy in the included hv-24x7-catalog.h and fully in at https://raw.githubusercontent.com/jmesmon/catalog-24x7/master/hv-24x7-catalog.h ). The 24x7 data access is simply a copy operation into a 4 dimentional array of 64bit counters (from hypervisor to kernel memory). There is no interupt triggered on overflow, these are completely disjoint from the typical power pmu. This method of obtaining performance counters from the hypervisor is intended to paritialy replace the gpci interface. Signed-off-by:
-
Cody P Schafer authored
"H_GetPerformanceCounterInfo" (refered to as hv_gpci or just gpci from here on) is an interface to retrieve specific performance counters and other data from the hypervisor. All outputs have a fixed format. This header only describes the portions of the interface that we plan on using in linux at this time. Signed-off-by:
-
Cody P Schafer authored
Signed-off-by:
-
Cody P Schafer authored
bin_attributes created/updated in create_files() (such as those listed via (struct device).attribute_groups) were not placed under the specified group, and instead appeared in the base kobj directory. Fix this by making bin_attributes use creating code similar to normal attributes. A quick grep shows that no one is using bin_attrs in a named attribute group yet, so we can do this without breaking anything in usespace. Note that I do not add is_visible() support to bin_attributes, though that could be done as well. This is a copy of the patch already merged in Greg's tree. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Michael Ellerman authored
The previous commit added constraint and register handling to allow processes using EBB (Event Based Branches) to request access to the BHRB (Branch History Rolling Buffer). With that in place we can allow processes using EBB to access the BHRB. This is achieved by setting BHRBA in MMCR0 when we enable EBB access. We must also clear BHRBA when we are disabling. Signed-off-by:
-
Michael Ellerman authored
We want a way for users of EBB (Event Based Branches) to also access the BHRB (Branch History Rolling Buffer). EBB does not interoperate with our existing BHRB support, which is wired into the generic Linux branch stack sampling support. To support EBB & BHRB we add three new bits to the event code. The first bit indicates that the event wants access to the BHRB, and the other two bits indicate the desired IFM (Instruction Filtering Mode). We allow multiple events to request access to the BHRB, but they must agree on the IFM value. Events which are not interested in the BHRB can also interoperate with events which do. Finally we program the desired IFM value into MMCRA. Although we do this for every event, we know that the value will be identical for all events that request BHRB access. Signed-off-by:
-
Michael Ellerman authored
We only need to mask the EBB bit out of the event for the check of the special PMC 5 & 6 events. So use a local to do it just for that code, rather than changing the event value for the life of the function. While we're there move the set of mask and value after all the checks. Signed-off-by:
-
Michael Ellerman authored
Rather than using PERF_EVENT_CONFIG_EBB_SHIFT everywhere, add an EVENT_EBB_SHIFT like every other event and use that. Signed-off-by:
-
Michael Ellerman authored
Although we already block EBB events which request sampling using sample_period, technically it's possible for an event to set sample_type but not sample_period. Nothing terrible will happen if an EBB event does specify sample_type, but it signals a major confusion on the part of userspace, and so we do them the favor of rejecting it. Signed-off-by:
-
Michael Ellerman authored
Some power8 revisions have a hardware bug where we can lose a PMU exception, this commit adds a workaround to detect the bad condition and rectify the situation. See the comment in the commit for a full description. Signed-off-by:
-
Michael Ellerman authored
Some power8 revisions have a hardware bug where we can lose a Performance Monitor (PMU) exception under certain circumstances. We will be adding a workaround for this case, see the next commit for details. The observed behaviour is that writing PMAO doesn't cause an exception as we would expect, hence the name of the feature. Signed-off-by:
-
Anshuman Khandual authored
Currently the sysrq ShowRegs command does not print any PMU registers as we have an empty definition for perf_event_print_debug(). This patch defines perf_event_print_debug() to print various PMU registers. Example output: CPU: 0 PMU registers, ppmu = POWER7 n_counters = 6 PMC1: 00000000 PMC2: 00000000 PMC3: 00000000 PMC4: 00000000 PMC5: 00000000 PMC6: 00000000 PMC7: deadbeef PMC8: deadbeef MMCR0: 0000000080000000 MMCR1: 0000000000000000 MMCRA: 0f00000001000000 SIAR: 0000000000000000 SDAR: 0000000000000000 SIER: 0000000000000000 Signed-off-by:
Anshuman Khandual <khandual@linux.vnet.ibm.com> [mpe: Fix 32 bit build and rework formatting for compactness] Signed-off-by:
-
Anshuman Khandual authored
This patchset adds some missing event list for POWER7 PMU raw events which are exported through sysfs interface. Also updates the ABI documentation to add all the sysfs exported raw events. Signed-off-by:
-
Josh Boyer authored
Alistair Popple has volunteered to take over maintainership of the ppc4xx stuff upstream. Switch the MAINTAINERS entry over to him. Signed-off-by:
Josh Boyer <jwboyer@gmail.com> Signed-off-by:
-
Shivaprasad G Bhat authored
This patch adds basic kernel enablement for reading power values, fan speed rpm and temperature values on powernv platforms which will be exported to user space through sysfs interface. Signed-off-by:
Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com> Signed-off-by:
Neelesh Gupta <neelegup@linux.vnet.ibm.com> Signed-off-by:
-
Neelesh Gupta authored
This patch enables fetching of various platform sensor data through OPAL and expects a sensor handle from the driver to pass to OPAL. Signed-off-by:
-
Neelesh Gupta authored
This patch enables reading and updating of system parameters through OPAL call. Signed-off-by:
-
Neelesh Gupta authored
This patch adds support for notifying the clients of their request completion. Clients request for the token before making OPAL call and then wait for the response. This patch uses messaging infrastructure to pull the data to linux by registering itself for the message type OPAL_MSG_ASYNC_COMP. Signed-off-by:
-
- 07 Mar, 2014 14 commits
-
-
Stewart Smith authored
This enables support for userspace to fetch and initiate FSP and Platform dumps from the service processor (via firmware) through sysfs. Based on original patch from Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Flow: - We register for OPAL notification events. - OPAL sends new dump available notification. - We make information on dump available via sysfs - Userspace requests dump contents - We retrieve the dump via OPAL interface - User copies the dump data - userspace sends ack for dump - We send ACK to OPAL. sysfs files: - We add the /sys/firmware/opal/dump directory - echoing 1 (well, anything, but in future we may support different dump types) to /sys/firmware/opal/dump/initiate_dump will initiate a dump. - Each dump that we've been notified of gets a directory in /sys/firmware/opal/dump/ with a name of the dump type and ID (in hex, as this is what's used elsewhere to identify the dump). - Each dump has files: id, type, dump and acknowledge dump is binary and is the dump itself. echoing 'ack' to acknowledge (currently any string will do) will acknowledge the dump and it will soon after disappear from sysfs. OPAL APIs: - opal_dump_init() - opal_dump_info() - opal_dump_read() - opal_dump_ack() - opal_dump_resend_notification() Currently we are only ever notified for one dump at a time (until the user explicitly acks the current dump, then we get a notification of the next dump), but this kernel code should "just work" when OPAL starts notifying us of all the dumps present. Signed-off-by:Stewart Smith <stewart@linux.vnet.ibm.com> Signed-off-by:
-
Stewart Smith authored
Based on a patch by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> This patch adds support to read error logs from OPAL and export them to userspace through a sysfs interface. We export each log entry as a directory in /sys/firmware/opal/elog/ Currently, OPAL will buffer up to 128 error log records, we don't need to have any knowledge of this limit on the Linux side as that is actually largely transparent to us. Each error log entry has the following files: id, type, acknowledge, raw. Currently we just export the raw binary error log in the 'raw' attribute. In a future patch, we may parse more of the error log to make it a bit easier for userspace (e.g. to be able to display a brief summary in petitboot without having to have a full parser). If we have >128 logs from OPAL, we'll only be notified of 128 until userspace starts acknowledging them. This limitation may be lifted in the future and with this patch, that should "just work" from the linux side. A userspace daemon should: - wait for error log entries using normal mechanisms (we announce creation) - read error log entry - save error log entry safely to disk - acknowledge the error log entry - rinse, repeat. On the Linux side, we read the error log when we're notified of it. This possibly isn't ideal as it would be better to only read them on-demand. However, this doesn't really work with current OPAL interface, so we read the error log immediately when notified at the moment. I've tested this pretty extensively and am rather confident that the linux side of things works rather well. There is currently an issue with the service processor side of things for >128 error logs though. Signed-off-by:
-
Benjamin Krill authored
The previous code added wrong TLBs and causes machine check errors if a driver accessed passed the end of the linear mapping instead of a clean page fault. Signed-off-by:
Ralph E. Bellofatto <ralphbel@us.ibm.com> Signed-off-by:
Benjamin Krill <ben@codiert.org> Signed-off-by:
-
Sebastian Siewior authored
powerpc uses early_init_dt_scan_chosen() from common fdt code. By enabling this option, the common code can take the built in command line over the one that is comming from bootloader / DT. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Tyrel Datwyler authored
Traditionally it has been drmgr's responsibilty to update the device tree through the /proc/ppc64/ofdt interface after a suspend/resume operation. This patchset however has modified suspend/resume ops to preform an update entirely in the kernel during the resume. Therefore, a mechanism is required to expose that information to drmgr. This patch adds a show function to the "hibernate" attribute that returns 1 if the kernel performs a device tree update after the resume and 0 otherwise. This allows newer versions of drmgr to avoid doing a second unnecessary device tree update. Signed-off-by:
Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Signed-off-by:
-
Haren Myneni authored
pHyp can change cache nodes for suspend/resume operation. Currently the device tree is updated by drmgr in userspace after all non boot CPUs are enabled. Hence, we do not modify the cache list based on the latest cache nodes. Also we do not remove cache entries for the primary CPU. This patch removes the cache list for the boot CPU, updates the device tree before enabling nonboot CPUs and adds cache list for the boot cpu. This patch also has the side effect that older versions of drmgr will perform a second device tree update from userspace. While this is a redundant waste of a couple cycles it is harmless since firmware returns the same data for the subsequent update-nodes/properties rtas calls. Signed-off-by:
Haren Myneni <hbabu@us.ibm.com> Signed-off-by:
-
Haren Myneni authored
The current code makes rtas calls for update-nodes, activate-firmware and then update-nodes again. The FW provides the same data for both update-nodes calls. As a result a proc entry exists error is reported for the second update while adding device nodes. This patch makes a single rtas call for update-nodes after activating the FW. It also add rtas_busy delay for the activate-firmware rtas call. Signed-off-by:
-
Shuah Khan authored
Change adb platform driver to register pm ops using dev_pm_ops instead of legacy pm_ops. .pm hooks call existing legacy suspend and resume interfaces by passing in the right pm state. Signed-off-by:
Shuah Khan <shuah.kh@samsung.com> Signed-off-by:
-
Paul Gortmaker authored
This processor/memory module was mostly used on ATCA blades and before that, on cPCI blades. It wasn't really user friendly, with custom non u-boot bootloaders (powerboot/motload) and no real way to recover corrupted boot flash (which was a common problem). As such, it had its day back before the big ppc --> powerpc move to device trees, and that was largely through commercial BSPs that started to dry up around 2007. Systems using one were largely in a "deploy and sustain" mode, so interest in upgrading to new kernels in the field was nil. Also, requiring 50A, 48V power supplies and a 2'x2'x2' ATCA chassis largely rules out any hobbyist/enthusiast interest. The point of all this, is that we might as well delete the in kernel files relating to this platform. No point in continuing to build it via walking the defconfigs or via linux-next testing. Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Brandon Stewart authored
Signed-off-by:
Brandon Stewart <stewartb2@gmail.com> Signed-off-by:
-
Nathan Fontenot authored
The memory remove code for powerpc/pseries should call remove_memory() so that we are holding the hotplug_memory lock during memory remove operations. This patch updates the memory node remove handler to call remove_memory() and adds a ppc_md.remove_memory() entry to handle pseries specific work that is called from arch_remove_memory(). During memory remove in pseries_remove_memblock() we have to stay with removing memory one section at a time. This is needed because of how memory resources are handled. During memory add for pseries (via the probe file in sysfs) we add memory one section at a time which gives us a memory resource for each section. Future patches will aim to address this so will not have to remove memory one section at a time. Signed-off-by:
Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by:
-
Michael Ellerman authored
Turn Anton's memcpy / copy_tofrom_user test into something that can live in tools/testing/selftests. It requires one turd in arch/powerpc/lib/memcpy_64.S, but it's pretty harmless IMHO. We are sailing very close to the wind with the feature macros. We define them to nothing, which currently means we get a few extra nops and include the unaligned calls. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Mahesh Salgaonkar authored
Detect and recover from machine check when inside opal on a special scom load instructions. On specific SCOM read via MMIO we may get a machine check exception with SRR0 pointing inside opal. To recover from MC in this scenario, get a recovery instruction address and return to it from MC. OPAL will export the machine check recoverable ranges through device tree node mcheck-recoverable-ranges under ibm,opal: # hexdump /proc/device-tree/ibm,opal/mcheck-recoverable-ranges 0000000 0000 0000 3000 2804 0000 000c 0000 0000 0000010 3000 2814 0000 0000 3000 27f0 0000 000c 0000020 0000 0000 3000 2814 xxxx xxxx xxxx xxxx 0000030 llll llll yyyy yyyy yyyy yyyy ... ... # where: xxxx xxxx xxxx xxxx = Starting instruction address llll llll = Length of the address range. yyyy yyyy yyyy yyyy = recovery address Each recoverable address range entry is (start address, len, recovery address), 2 cells each for start and recovery address, 1 cell for len, totalling 5 cells per entry. During kernel boot time, build up the recovery table with the list of recovery ranges from device-tree node which will be used during machine check exception to recover from MMIO SCOM UE. Signed-off-by:
Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by:
-
Benjamin Herrenschmidt authored
This results in oddball messages at boot on other platforms telling us that CPU hotplug isn't supported even when it is. Signed-off-by:
-
