On Fri, Dec 7, 2018 at 4:34 AM Alexandre Belloni <alexandre.belloni@xxxxxxxxxxx> wrote: > > On 06/12/2018 13:49:10+0800, Chen-Yu Tsai wrote: > > 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 > > I've applied the above patches. However, for whatever reason, patch 3 > didn't apply without some fuzz, please check. Sorry about that. The fuzz was due to a patch that I forgot to send out. The fixup looks good. I applied the remaining device tree patches. I'll send out the missing patch, which fixes the register range in the binding example, later. Thanks! ChenYu
