Forum | Documentation | Website | Blog

Skip to content
Snippets Groups Projects
  1. May 30, 2024
  2. May 29, 2024
  3. Dec 27, 2023
  4. Feb 22, 2023
  5. Feb 21, 2023
  6. Feb 20, 2023
  7. Feb 17, 2023
  8. Feb 14, 2023
  9. Feb 09, 2023
  10. Feb 08, 2023
  11. Feb 01, 2023
    • Conor Dooley's avatar
      clk: microchip: fix criticality of peripheral clocks on mpfs · b022b277
      Conor Dooley authored
      
      Sync the critical clocks in the U-Boot driver with those marked as
      critical in Linux. The Linux driver has an explanation of why each clock
      is considered to be critical, so import that too.
      
      Fixes: 2f27c921 ("clk: Add Microchip PolarFire SoC clock driver")
      Signed-off-by: default avatarConor Dooley <conor.dooley@microchip.com>
      b022b277
    • Conor Dooley's avatar
      clk: microchip: fix periph clk parentage · 4d9378a1
      Conor Dooley authored
      
      Not all "periph" clocks are children of the AHB clock, some have the AXI
      clock as their parent & the mtimer clock is derived from the external
      reference clock directly. Stop assuming the AHB clock to be the parent
      of all "periph" clocks and define their correct parents instead.
      
      Fixes: 2f27c921 ("clk: Add Microchip PolarFire SoC clock driver")
      Signed-off-by: default avatarConor Dooley <conor.dooley@microchip.com>
      4d9378a1
    • Conor Dooley's avatar
      clk: microchip: fix reference clock handling · 3f245d22
      Conor Dooley authored
      
      The original devicetrees for PolarFire SoC messed up & defined the
      msspll's output as a fixed-frequency, 600 MHz clock & used that as the
      input for the clock controller node. The msspll is not a fixed
      frequency clock and later devicetrees handled this properly. Check the
      devicetree & if it is one of the fixed ones, register the msspll.
      Otherwise, skip registering it & pass the reference clock directly to
      the cfg clock registration function so that existing devicetrees are
      not broken by this change.
      
      As the MSS PLL is not a "cfg" or a "periph" clock, add a new driver for
      it, based on the one in Linux.
      
      Fixes: 2f27c921 ("clk: Add Microchip PolarFire SoC clock driver")
      Signed-off-by: default avatarConor Dooley <conor.dooley@microchip.com>
      3f245d22
    • Conor Dooley's avatar
      clk: microchip: mpfs: convert parent rate acquistion to get_get_rate() · f4e5b4de
      Conor Dooley authored
      
      Currently the clock driver for PolarFire SoC takes a very naive approach
      to the relationship between clocks. It reads the dt to get an input
      clock, assumes that that is fixed frequency, reads the "clock-frequency"
      property & uses that to set up both the "cfg" and "periph" clocks.
      
      Simplifying for the sake of incremental fixes, the "correct" parentage for
      the clocks currently supported in U-Boot is that the "cfg" clocks should
      be children of the fixed frequency clock in the dt. The AHB clock is one
      of these "cfg" clocks and is the parent of the "periph" clocks.
      
      Instead of passing the clock rate of the fixed-frequency clock to the
      "cfg" and "periph" registration functions and the name of the parents,
      pass their actual parents & use clk_get_rate() to determine their parents
      rates.
      
      The "periph" clocks are purely gate clocks and should not be reading the
      AHB clocks registers to determine their rates, as they can simply report
      the output of clk_get_rate() on their parent.
      
      Signed-off-by: default avatarConor Dooley <conor.dooley@microchip.com>
      f4e5b4de
    • Conor Dooley's avatar
      dt-bindings: clk: add missing clk ids for microchip mpfs · bbbe137b
      Conor Dooley authored
      
      When this binding header was initally upstreamed, the PLL clocking the
      microprocessor subsystem (MSS) and the RTC reference clocks were
      omitted. Add them now, matching the IDs used in Linux.
      
      Signed-off-by: default avatarConor Dooley <conor.dooley@microchip.com>
      bbbe137b
  12. Nov 09, 2022
  13. Nov 03, 2022
  14. Sep 19, 2022
Loading