Skip to content

Replace the i.MX35 PDR0 clock workaround with proper CCF support #1

Description

@mcb2003

Problem

The current Kindle 3 mainline bring-up needs out-of-tree i.MX35 clock patches to support the two production CPU operating points:

  • 256 MHz
  • 512 MHz

The i.MX35 PDR0 consumer selector is not an independent CPU divider. It selects a coupled ARM/AHB clock configuration, while the same register also contains HSP and peripheral divider fields. Treating these as unrelated clocks allows the common clock framework to rewrite part of PDR0 using rates calculated from the previous consumer selection.

The initial implementation changed only the consumer selector. This produced invalid working states on Kindle 3:

  • 512 MHz: PDR0 = 0x00002000
  • 256 MHz: PDR0 = 0x00025000

The low state reproducibly locked the system under load and was eventually recovered by the hardware watchdog.

Amazon's vendor implementation uses complete working-point values:

  • 512 MHz: PDR0 = 0x00001000
  • 256 MHz: PDR0 = 0x00021000

The current corrective patch writes those complete values atomically and registers ahb_per_div as read-only so the generic child-clock walk cannot corrupt PER_PODF afterward. This is hardware-tested, but it is still a bring-up workaround rather than a satisfactory model of the i.MX35 clock hardware.

Relevant files:

  • board/amazon/kindle3/mainline/patches/linux/7.0.11/0004-clk-imx35-add-two-point-cpu-clock-scaling.patch
  • board/amazon/kindle3/mainline/patches/linux/7.0.11/0006-clk-imx35-program-complete-cpu-working-points.patch
  • board/amazon/kindle3/mainline/linux-dts/nxp/imx/imx35-kindle3.dts
  • board/amazon/kindle3/mainline/rootfs-overlay/usr/bin/kindle3-cpufreq-test

Why this should be improved

The current code embeds two Kindle-validated PDR0 constants in the shared i.MX35 clock driver. It works for this board, but:

  • it does not model the SoC's coupled consumer-clock table cleanly;
  • it may not generalize to other i.MX35 boards or operating points;
  • marking one child divider read-only is compensating for an incomplete clock topology;
  • it is unlikely to be suitable for upstream Linux in its present form.

Desired work

Replace the workaround with a proper i.MX35 common-clock-framework implementation that:

  • models the coupled ARM, AHB, HSP and peripheral-divider relationships represented by PDR0;
  • coordinates a working-point transition as one hardware operation;
  • prevents intermediate or post-transition child-clock writes from producing an invalid combination;
  • keeps reported CCF rates accurate at every supported consumer selection;
  • safely handles the recovery boot state, where MPLL initially runs at 532 MHz, before entering the 512 MHz production point;
  • avoids Kindle-specific conditionals in the shared SoC driver where possible;
  • determines whether the complete i.MX35 consumer table should be supported rather than only the two Kindle operating points;
  • is structured with eventual upstream submission in mind.

The implementation must be checked against the i.MX35 reference manual, Freescale/NXP kernel history, Amazon's Kindle 3 clock code, and other upstream i.MX35 board behavior.

Existing hardware validation

With the complete-register workaround and production SW2 voltages:

  • correct PDR0 and CCF rates were observed at both 256 and 512 MHz;
  • 256 MHz at 1.275 V passed 180 seconds of continuous full CPU load;
  • 30 loaded cycles (60 frequency/voltage transitions) completed successfully;
  • normal ondemand operation selected both points;
  • no cpufreq, regulator or watchdog errors occurred.

The replacement should retain these as regression tests. In particular, validate stable loaded operation at each point, repeated transitions under load, exact PDR0 values, CCF descendant rates, SW2 voltage pairing, and watchdog boot status after reboot.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions