1. 23 Mar, 2014 29 commits
  2. 07 Mar, 2014 11 commits
    • Stewart Smith's avatar
      powerpc/powernv Platform dump interface · c7e64b9c
      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: default avatarStewart Smith <stewart@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      c7e64b9c
    • Stewart Smith's avatar
      powerpc/powernv: Read OPAL error log and export it through sysfs · 774fea1a
      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: default avatarStewart Smith <stewart@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      774fea1a
    • Benjamin Krill's avatar
      powerpc/book3e: Fix check for linear mapping in TLB miss handler · 60b96223
      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: default avatarRalph E. Bellofatto <ralphbel@us.ibm.com>
      Signed-off-by: default avatarBenjamin Krill <ben@codiert.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      60b96223
    • Sebastian Siewior's avatar
      powerpc: Add "force config cmd line" Kconfig option · eb3b80f6
      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: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      eb3b80f6
    • Tyrel Datwyler's avatar
      powerpc/pseries: Expose in kernel device tree update to drmgr · 9da34892
      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: default avatarTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      9da34892
    • Haren Myneni's avatar
      powerpc/pseries: Update dynamic cache nodes for suspend/resume operation · 6b36ba84
      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: default avatarHaren Myneni <hbabu@us.ibm.com>
      Signed-off-by: default avatarTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      6b36ba84
    • Haren Myneni's avatar
      powerpc/pseries: Device tree should only be updated once after suspend/migrate · 39a33b59
      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: default avatarHaren Myneni <hbabu@us.ibm.com>
      Signed-off-by: default avatarTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      39a33b59
    • Shuah Khan's avatar
      macintosh/adb: Change platform power management to use dev_pm_ops · 639291f2
      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: default avatarShuah Khan <shuah.kh@samsung.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      639291f2
    • Paul Gortmaker's avatar
      powerpc: Delete old PrPMC 280/2800 support · 3c8464a9
      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: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      3c8464a9
    • Brandon Stewart's avatar
    • Nathan Fontenot's avatar
      powerpc/pseries: Use remove_memory() to remove memory · 9ac8cde9
      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: default avatarNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      9ac8cde9