On Thu, Jun 29, 2017 at 01:28:12PM +0200, Emmanuel Vadot wrote: > On Thu, 29 Jun 2017 11:57:05 +0100 > Andre Przywara <andre.przywara@xxxxxxx> wrote: > > > Hi, > > > > On 25/06/17 21:45, Priit Laes wrote: > > > Convert sun7i-a20.dtsi to new CCU driver. > > > > I know that some people hat^Wget annoyed by me asking this, but anyway: > > > > Why do we actually need this? > > No. I can understand the need for clkng/sunxi-ng/whatever you call it, > it's not that bad (but see below) to add a new SoC on FreeBSD now that > I've added the framework, but breaking old SoC that were perfectly fine > isn't acceptable. We haven't broken it. > It also mean that, on FreeBSD, we still have patches for sun7i dts to > add hdmi support (which we have since a year or so) because last time > someone (I think plaes) wanted to add clock node for it, it was said > that it was needed to move to clkng first. This is a circular argument. It wouldn't have been the case with sunxi-ng, since we would have had that clock from the start... > > This ultimately makes the DT incompatible with older kernels (as > > actually shipped by distros today). > > Yes, right now sun5i support is broken in FreeBSD because I couldn't > find the time to make a driver for it yet. Probably because you merged new DTs without updating the code. That has nothing to do with backward compatibility, the old DT would still work fine. > > So if we for instance use UEFI boot or otherwise just use "one golden > > DT" to drive all kernels (like using the DT from U-Boot), we now don't > > have one good DT that fits all. This is really a showstopper for boards > > which ship a DT in firmware (in SPI flash, for instance, or on some eMMC). > > So: > > - Do we actually need to change the .dtsi? The old .dtsi should still work. > > - Is there anything that the new and fancy clocks gives us over the > > existing clocks? If yes, that should be a stated in the commit message > > or cover letter. > > - Why do we change the clocks for those older SoCs in the first place? > > Can't we just keep on using what worked for years? I think we really > > can't remove the old code anyway. > > > > The new clock driver moves information from the DT into the kernel. That > > means it is no longer available for a DT consumer and the SoC details > > (which clocks is located where, for instance), have to be replicated to > > other DT users (U-Boot, *BSD, you-name-it). We already came across this > > issue when looking at converting U-Boot over to use DT clocks. > > Also it ultimately requires kernel changes for each new SoC, even if it > > only differs in some detail which could be perfectly modelled in DT > > (think of H3 vs. H5). > > The last point is very interesting, before adding a new Allwinner SoC > was just a matter of maybe handling one/two new clocks (at least to > have something that 'just boots'), now it's a whole new big boring file > to write while reading datasheet. You can definitely do that with sunxi-ng bindings if you want. You just have to populate only the IDs that are of interest to you. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Attachment:
signature.asc
Description: PGP signature
