1. 03 7月, 2017 10 次提交
  2. 25 4月, 2017 1 次提交
  3. 22 4月, 2017 1 次提交
  4. 21 4月, 2017 1 次提交
  5. 12 4月, 2017 1 次提交
    • S
      PCI: rockchip: Set PCI_EXP_LNKSTA_SLC in the Root Port · 64d6ea60
      Shawn Lin 提交于
      All platforms using Rockchip use a common clock for the Root Port and the
      slot connected to it. Indicate this by setting the Slot Clock Configuration
      (PCI_EXP_LNKSTA_SLC) bit in the Root Port's Link Status.
      
      Per the Implementation Note in the spec (PCIe r3.1, sec 7.8.7), if the
      downstream component also sets PCI_EXP_LNKSTA_SLC, software may set the
      Common Clock Configuration (PCI_EXP_LNKCTL_CCC) bits on both ends of the
      Link. This is done by pcie_aspm_configure_common_clock().
      Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
      Cc: Brian Norris <briannorris@chromium.org>
      Cc: jeffy.chen <jeffy.chen@rock-chips.com>
      64d6ea60
  6. 04 4月, 2017 1 次提交
  7. 24 3月, 2017 3 次提交
  8. 18 2月, 2017 1 次提交
  9. 11 2月, 2017 1 次提交
  10. 31 1月, 2017 2 次提交
  11. 13 1月, 2017 1 次提交
    • S
      PCI: rockchip: Disable RC's ASPM L0s based on DT "aspm-no-l0s" · afc9595e
      Shawn Lin 提交于
      Rockchip's RC produces a 100MHz reference clock but there are two methods
      for the PHY to generate it:
      
        (1) Use the system PLL to generate a 100MHz clock.  The PHY will relock
            it, filter signal noise, and output the reference clock.  ASPM L0s
            works correctly, but circuit noise issues make it difficult to pass
            the TX compatibility test.
      
        (2) Share the SoC's 24MHZ crystal oscillator with the PHY and force the
            PHY's PLL to generate 100MHz internally.  In this case, exit from
            ASPM L0s sometimes fails due to a design error in the RC receiver
            circuit.  Even if we use extended-synch, the PHY sometimes fails to
            relock the bits from FTS, which will hang the system.
      
      We want the flexibility to use both clocking methods, so add a DT property,
      "aspm-no-l0s".  If that's present, disable L0s to avoid the issues with
      case (2).
      
      [bhelgaas: changelog]
      Reported-by: NJeffy Chen <jeffy.chen@rock-chips.com>
      Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NBrian Norris <briannorris@chromium.org>
      Acked-by: NRob Herring <robh@kernel.org>
      afc9595e
  12. 12 1月, 2017 1 次提交
    • S
      PCI: rockchip: Add system PM support · 013dd3d5
      Shawn Lin 提交于
      Add system PM support for Rockchip's RC.  For pre S3, the EP is configured
      into D3 state which guarantees the link state should be in L1.  So we could
      send PME_Turn_Off message to the EP and wait for its ACK to make the link
      state into L2 or L3 without the aux-supply.  This could help save more
      power which I think should be very important for mobile devices.
      
      As note that there is a 5s timeout for RC to wait for the PMA_ACK after
      sending PME_Turn_Off.  Technically it should depend on the hierarchy of
      devices but seems PCIe core framework doesn't handle the L2/3 for S3 at
      all.  So that means we should presume to set a default value for PME_ACK.
      From the bug report[1], we could find a statement that Microsoft Windows
      versions typically wait for 5 seconds.  So we are prone to take 5s for this
      timeout here.
      
      [1] https://lists.launchpad.net/kernel-packages/msg123315.htmlSigned-off-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NBrian Norris <briannorris@chromium.org>
      013dd3d5
  13. 08 12月, 2016 9 次提交
  14. 22 11月, 2016 1 次提交
  15. 11 11月, 2016 1 次提交
  16. 12 10月, 2016 2 次提交
  17. 05 10月, 2016 3 次提交
    • S
      PCI: rockchip: Fix wrong transmitted FTS count · ca198908
      Shawn Lin 提交于
      If the expected number of FTS aren't received by RC when exiting from L0s,
      the LTSSM will fall into recover state, which means it will need to send TS
      for retraining which makes the latency of exiting from L0s a little longer
      than expected.  This issue is caused by an incorrect reset value of FTS
      count on PLC1 register (offset 0x4).  The expected value for Gen1/2 should
      be more than 240 and we may leave a little margin here.  Fix this before
      starting Gen1 training which will make TS1 contain the correct FTS count.
      Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      ca198908
    • S
      PCI: rockchip: Improve the deassert sequence of four reset pins · 58c6990c
      Shawn Lin 提交于
      Per TRM, we need to deassert the four reset pins simultaneously.  Currently
      the reset framework doesn't support that so we did it one by one.  It seems
      no side effect found but it does impact the state machine of controller, so
      sometimes the change speed bit is not set when sending training sequence
      from recover state.  After the silicon RTL review from SoC guys, we don't
      need to do the sequence recommended by TRM, and could just move the
      deassert of mgmt_sticky_rst to the first place.
      Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      58c6990c
    • R
      PCI: rockchip: Increase the Max Credit update interval · 277743ef
      Rajat Jain 提交于
      Increase the likelihood of link state to automatically go to L1 and save
      some power.
      
      The default credit update interval of 7.5 us results in the rootport
      sending UpdateFC-P and UpdateFC-NP packets too often, thus resulting in the
      link never going to L1, and always staying in L0/L0s.  The value 24 us was
      chosen after some experiments and peeking over the PCIe bus to see that we
      do enter L1 substate when there is not enough traffic on the PCIe bus.
      Signed-off-by: NRajat Jain <rajatja@google.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NShawn Lin <shawn.lin@rock-chips.com>
      277743ef