Hi, On Mon, Dec 3, 2018 at 10:58 PM Chen-Yu Tsai <wens@xxxxxxxx> wrote: > > Hi everyone, > > This is v2 of my rtc-sun6i clean-up series. > > Changes since v1: > > - Collected tags > - Dropped patch "clk: sunxi-ng: r40: Force LOSC parent to RTC LOSC > output"; already merged > - Removed H6 compatible CLK_OF_DECLARE_DRIVER entry that wasn't > overlooked > - Only export IOSC clock for A64/H3/H5 > > Original cover letter, with patch numbers corrected, follows: > > This series was started as part of enabling Bluetooth on various > Allwinner SBCs. The bluetooth controller requires a precise 32.768 kHz > clock fed to it to correctly detect the frequency of its main oscillator. > This clock signal is provided by the RTC, either directly from a special > pin on the SoC, or some clock output function from the clock controllers. > I found that the clock-related properties of the RTC on later SoCs were > incorrect or missing. > > This series reworks the compatible strings and clock parts of the device > tree bindings for sun6i-rtc. Currently we assume most Allwinner SoCs use > the same sun6i-rtc variant, when in fact they do not. The differences > that matter with regards to clocks are a) the A31 does not have an extra > external output for the RTC 32K clock, while most of the others do; > b) the clock frequency of the internal RC oscillator is different on > some SoCs; c) on the H6 the RTC also handles the 24 MHz DCXO, which > feeds the system HOSC. The last difference, and by extension the H6, are > not covered in this series. > > Patch 1 cleans up the clock-related section of the RTC device tree > binding. This would make it easier to read and easier to add additional > clocks. > > Patch 2 adds compatible strings for all identified variants introduced > prior to the H6. > > Patch 3 deprecates the external clock output for the A31. The A31 does > not have this output, so it's introduction and usage was an error. > > Patch 4 adds a clock output for the RTC's internal oscillator to the > device tree binding. This feeds the PRCM in some SoCs. > > Patch 5 adds a default clock name for the LOSC to the RTC driver. > > Patch 6 adds support for different hardware variants to the RTC driver. > > Patch 7 adds support for all known pre-H6 variants. > > Patch 8 exposes the RTC's internal oscillator through the device tree. > > Patch 9 through 14 adds an RTC node or fixes up the RTC device node > address ranges, clock properties, names of existing clocks, and adds > accuracy properties for the external fixed oscillators. > > The clock names require fixing because the sunxi clock driver implicitly > depends on the HOSC and LOSC being named "osc24M" and "osc32k". The > "fixes" to the clock hierarchy introduced in this series means the names > must also be shuffled around or the in kernel representation would be > incorrect. This has been the case since the sunxi-ng drivers were > introduced. There are plans to address this, but the code is still in its > early stages. > > Please have a look. > > Thanks > ChenYu > > Chen-Yu Tsai (14): > dt-bindings: rtc: sun6i-rtc: Rewrite clock outputs as a list > dt-bindings: rtc: sun6i-rtc: Add compatible strings for pre-H6 > variants > dt-bindings: rtc: sun6i-rtc: Deprecate external clock output for A31 > dt-bindings: rtc: sun6i-rtc: Export internal RC oscillator > rtc: sun6i: Add default clock name for LOSC > rtc: sun6i: Add support for different variants > rtc: sun6i: Add support for all known pre-H6 variants > rtc: sun6i: Expose internal oscillator through device tree > ARM: dts: sun8i: a23/a33: Fix up RTC device node > ARM: dts: sunxi: h3/h5: Add clock accuracy for external oscillators > ARM: dts: sunxi: h3/h5: Fix up RTC device node and clock references > ARM: dts: sun8i: r40: Add clock accuracy for external oscillators > ARM: dts: sun8i: r40: Add RTC device node > arm64: dts: allwinner: a64: Fix up RTC device node and clock > references I merged patches 10 and 12 for now. These don't depend on any driver changes. If Alex manages to get the driver bits merged for 4.21, I suppose we could do a late PR for the dts bits? It would be nice to have both in the same release, though I don't think anything would break if the dts bits are delayed. ChenYu
