1. 05 6月, 2015 1 次提交
  2. 22 5月, 2015 2 次提交
  3. 17 3月, 2015 1 次提交
  4. 04 2月, 2015 1 次提交
  5. 05 8月, 2014 1 次提交
  6. 11 7月, 2014 1 次提交
    • A
      powernv: Add OPAL tracepoints · c49f6353
      Anton Blanchard 提交于
      Knowing how long we spend in firmware calls is an important part of
      minimising OS jitter.
      
      This patch adds tracepoints to each OPAL call. If tracepoints are
      enabled we branch out to a common routine that calls an entry and exit
      tracepoint.
      
      This allows us to write tools that monitor the frequency and duration
      of OPAL calls, eg:
      
      name                  count  total(ms)  min(ms)  max(ms)  avg(ms)  period(ms)
      OPAL_HANDLE_INTERRUPT     5      0.199    0.037    0.042    0.040   12547.545
      OPAL_POLL_EVENTS        204      2.590    0.012    0.036    0.013    2264.899
      OPAL_PCI_MSI_EOI       2830      3.066    0.001    0.005    0.001      81.166
      
      We use jump labels if configured, which means we only add a single
      nop instruction to every OPAL call when the tracepoints are disabled.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      c49f6353
  7. 25 6月, 2014 1 次提交
    • M
      powerpc/powernv: Remove OPAL v1 takeover · e2500be2
      Michael Ellerman 提交于
      In commit 27f44888 "Add OPAL takeover from PowerVM" we added support
      for "takeover" on OPAL v1 machines.
      
      This was a mode of operation where we would boot under pHyp, and query
      for the presence of OPAL. If detected we would then do a special
      sequence to take over the machine, and the kernel would end up running
      in hypervisor mode.
      
      OPAL v1 was never a supported product, and was never shipped outside
      IBM. As far as we know no one is still using it.
      
      Newer versions of OPAL do not use the takeover mechanism. Although the
      query for OPAL should be harmless on machines with newer OPAL, we have
      seen a machine where it causes a crash in Open Firmware.
      
      The code in early_init_devtree() to copy boot_command_line into cmd_line
      was added in commit 817c21ad "Get kernel command line accross OPAL
      takeover", and AFAIK is only used by takeover, so should also be
      removed.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      e2500be2
  8. 11 6月, 2014 1 次提交
  9. 28 5月, 2014 1 次提交
    • M
      powerpc/powernv: Add support for POWER8 split core on powernv · e2186023
      Michael Ellerman 提交于
      Upcoming POWER8 chips support a concept called split core. This is where the
      core can be split into subcores that although not full cores, are able to
      appear as full cores to a guest.
      
      The splitting & unsplitting procedure is mildly complicated, and explained at
      length in the comments within the patch.
      
      One notable detail is that when splitting or unsplitting we need to pull
      offline cpus out of their offline state to do work as part of the procedure.
      
      The interface for changing the split mode is via a sysfs file, eg:
      
       $ echo 2 > /sys/devices/system/cpu/subcores_per_core
      
      Currently supported values are '1', '2' and '4'. And indicate respectively that
      the core should be unsplit, split in half, and split in quarters. These modes
      correspond to threads_per_subcore of 8, 4 and 2.
      
      We do not allow changing the split mode while KVM VMs are active. This is to
      prevent the value changing while userspace is configuring the VM, and also to
      prevent the mode being changed in such a way that existing guests are unable to
      be run.
      
      CPU hotplug fixes by Srivatsa.  max_cpus fixes by Mahesh.  cpuset fixes by
      benh.  Fix for irq race by paulus.  The rest by mikey and mpe.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      e2186023
  10. 09 4月, 2014 1 次提交
  11. 24 3月, 2014 3 次提交
  12. 07 3月, 2014 2 次提交
    • S
      powerpc/powernv Platform dump interface · c7e64b9c
      Stewart Smith 提交于
      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: NStewart Smith <stewart@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      c7e64b9c
    • S
      powerpc/powernv: Read OPAL error log and export it through sysfs · 774fea1a
      Stewart Smith 提交于
      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: NStewart Smith <stewart@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      774fea1a
  13. 09 12月, 2013 1 次提交
  14. 30 10月, 2013 1 次提交
    • V
      powerpc/powernv: Code update interface · 50bd6153
      Vasant Hegde 提交于
      Code update interface for powernv platform. This provides
      sysfs interface to pass new image, validate, update and
      commit images.
      
      This patch includes:
        - Below OPAL APIs for code update
          - opal_validate_flash()
          - opal_manage_flash()
          - opal_update_flash()
      
        - Create below sysfs files under /sys/firmware/opal
          - image		: Interface to pass new FW image
          - validate_flash	: Validate candidate image
          - manage_flash	: Commit/Reject operations
          - update_flash	: Flash new candidate image
      
      Updating Image:
        "update_flash" is an interface to indicate flash new FW.
      It just passes image SG list to FW. Actual flashing is done
      during system reboot time.
      
      Note:
        - SG entry format:
          I have kept version number to keep this list similar to what
          PAPR is defined.
      Signed-off-by: NVasant Hegde <hegdevasant@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      50bd6153
  15. 11 10月, 2013 2 次提交
  16. 14 8月, 2013 1 次提交
  17. 20 6月, 2013 2 次提交
  18. 25 11月, 2011 1 次提交
    • B
      powerpc/powernv: PCI support for p7IOC under OPAL v2 · 184cd4a3
      Benjamin Herrenschmidt 提交于
      This adds support for p7IOC (and possibly other IODA v1 IO Hubs)
      using OPAL v2 interfaces.
      
      We completely take over resource assignment and assign them using an
      algorithm that hands out device BARs in a way that makes them fit in
      individual segments of the M32 window of the bridge, which enables us
      to assign individual PEs to devices and functions.
      
      The current implementation gives out a PE per functions on PCIe, and a
      PE for the entire bridge for PCIe to PCI-X bridges.
      
      This can be adjusted / fine tuned later.
      
      We also setup DMA resources (32-bit only for now) and MSIs (both 32-bit
      and 64-bit MSI are supported).
      
      The DMA allocation tries to divide the available 256M segments of the
      32-bit DMA address space "fairly" among PEs. This is done using a
      "weight" heuristic which assigns less value to things like OHCI USB
      controllers than, for example SCSI RAID controllers. This algorithm
      will probably want some fine tuning for specific devices or device
      types.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      184cd4a3
  19. 20 9月, 2011 5 次提交
    • B
      powerpc/powernv: Add support for p5ioc2 PCI-X and PCIe · 61305a96
      Benjamin Herrenschmidt 提交于
      This adds support for PCI-X and PCIe on the p5ioc2 IO hub using
      OPAL. This includes allocating & setting up TCE tables and config
      space access routines.
      
      This also supports fallbacks via RTAS when OPAL is absent, using
      legacy TCE format pre-allocated via the device-tree (BML style)
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      61305a96
    • B
      powerpc/powernv: Add RTC and NVRAM support plus RTAS fallbacks · 628daa8d
      Benjamin Herrenschmidt 提交于
      Implements OPAL RTC and NVRAM support and wire all that up to
      the powernv platform.
      
      We use RTAS for RTC as a fallback if available. Using RTAS for nvram
      is not supported yet, pending some rework/cleanup and generalization
      of the pSeries & CHRP code. We also use RTAS fallbacks for power off
      and reboot
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      628daa8d
    • B
      powerpc/powernv: Basic support for OPAL · 14a43e69
      Benjamin Herrenschmidt 提交于
      Add definition of OPAL interfaces along with  the wrappers to call
      into OPAL runtime and the early device-tree parsing hook to locate
      the OPAL runtime firmware.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      14a43e69
    • B
      powerpc/powernv: Add OPAL takeover from PowerVM · 27f44888
      Benjamin Herrenschmidt 提交于
      On machines supporting the OPAL firmware version 1, the system
      is initially booted under pHyp. We then use a special hypercall
      to verify if OPAL is available and if it is, we then trigger
      a "takeover" which disables pHyp and loads the OPAL runtime
      firmware, giving control to the kernel in hypervisor mode.
      
      This patch add the necessary code to detect that the OPAL takeover
      capability is present when running under PowerVM (aka pHyp) and
      perform said takeover to get hypervisor control of the processor.
      
      To perform the takeover, we must first use RTAS (within Open
      Firmware runtime environment) to start all processors & threads,
      in order to give control to OPAL on all of them. We then call
      the takeover hypercall on everybody, OPAL will re-enter the kernel
      main entry point passing it a flat device-tree.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      27f44888
    • B
      powerpc: Add skeleton PowerNV platform · 55190f88
      Benjamin Herrenschmidt 提交于
      This adds a skeletton for the new Power "Non Virtualized"
      platform which will be used by machines supporting running
      without an hypervisor, for example in order to run KVM.
      
      These machines will be using a new firmware called OPAL
      for which the support will be provided by later patches.
      
      The PowerNV platform is intended to be also usable under
      the BML environment used internally for early CPU bringup
      which is why the code also supports using RTAS instead of
      OPAL in various places.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      55190f88