1. 04 6月, 2015 1 次提交
  2. 22 5月, 2015 4 次提交
  3. 11 4月, 2015 1 次提交
  4. 31 3月, 2015 1 次提交
  5. 25 3月, 2015 3 次提交
  6. 16 3月, 2015 2 次提交
  7. 28 1月, 2015 3 次提交
  8. 27 1月, 2015 1 次提交
  9. 15 12月, 2014 1 次提交
  10. 14 12月, 2014 1 次提交
  11. 02 12月, 2014 1 次提交
  12. 17 11月, 2014 1 次提交
    • N
      rtc/tpo: Driver to support rtc and wakeup on PowerNV platform · 16b1d26e
      Neelesh Gupta 提交于
      The patch implements the OPAL rtc driver that binds with the rtc
      driver subsystem. The driver uses the platform device infrastructure
      to probe the rtc device and register it to rtc class framework. The
      'wakeup' is supported depending upon the property 'has-tpo' present
      in the OF node. It provides a way to load the generic rtc driver in
      in the absence of an OPAL driver.
      
      The patch also moves the existing OPAL rtc get/set time interfaces to the
      new driver and exposes the necessary OPAL calls using EXPORT_SYMBOL_GPL.
      
      Test results:
      -------------
      Host:
      [root@tul169p1 ~]# ls -l /sys/class/rtc/
      total 0
      lrwxrwxrwx 1 root root 0 Oct 14 03:07 rtc0 -> ../../devices/opal-rtc/rtc/rtc0
      [root@tul169p1 ~]# cat /sys/devices/opal-rtc/rtc/rtc0/time
      08:10:07
      [root@tul169p1 ~]# echo `date '+%s' -d '+ 2 minutes'` > /sys/class/rtc/rtc0/wakealarm
      [root@tul169p1 ~]# cat /sys/class/rtc/rtc0/wakealarm
      1413274345
      [root@tul169p1 ~]#
      
      FSP:
      $ smgr mfgState
      standby
      $ rtim timeofday
      
      System time is valid: 2014/10/14 08:12:04.225115
      
      $ smgr mfgState
      ipling
      $
      
      CC: devicetree@vger.kernel.org
      CC: tglx@linutronix.de
      CC: rtc-linux@googlegroups.com
      CC: a.zummo@towertech.it
      Signed-off-by: NNeelesh Gupta <neelegup@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      16b1d26e
  13. 12 11月, 2014 1 次提交
  14. 13 10月, 2014 1 次提交
    • M
      powerpc/powernv: Fallback to old HMI handling behavior for old firmware · 6507955c
      Mahesh Salgaonkar 提交于
      Recently we moved HMI handling into Linux kernel instead of taking
      HMI directly in OPAL. This new change is dependent on new OPAL call
      for HMI recovery which was introduced in newer firmware. While this new
      change works fine with latest OPAL firmware, we broke the HMI handling
      if we run newer kernel on old OPAL firmware that results in system hang.
      
      This patch fixes this issue by falling back to old HMI behavior on older
      OPAL firmware.
      
      This patch introduces a check for opal token OPAL_HANDLE_HMI to see
      if we are running on newer firmware or old firmware. On newer firmware
      this check would return OPAL_TOKEN_PRESENT, otherwise we are running on
      old firmware and fallback to old HMI behavior.
      
      Old firmware: POWER8 System Firmware Release as of today <= SV810_087
      Action: Let OPAL handle HMIs
      
      Newer firmware: in development/yet to be released.
      Action: Let Linux host handle HMIs.
      
      This patch depends on opal check token patch posted at ppc-devel
      https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-August/120224.htmlSigned-off-by: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      [mpe: Minor comment and printk rewording]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      6507955c
  15. 02 10月, 2014 1 次提交
  16. 01 9月, 2014 1 次提交
  17. 13 8月, 2014 1 次提交
  18. 05 8月, 2014 2 次提交
  19. 28 7月, 2014 1 次提交
  20. 05 6月, 2014 1 次提交
  21. 30 4月, 2014 1 次提交
  22. 28 4月, 2014 2 次提交
  23. 09 4月, 2014 3 次提交
  24. 07 4月, 2014 2 次提交
  25. 24 3月, 2014 1 次提交
  26. 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