On Thu, Jan 19, 2017 at 09:11:49PM +0800, Icenowy Zheng wrote: > 19.01.2017, 17:23, "Linus Walleij" <linus.walleij@xxxxxxxxxx>: > > On Wed, Jan 18, 2017 at 10:44 AM, Andre Przywara <andre.przywara@xxxxxxx> wrote: > > > >> Any future SoCs could then just use that compatible and would describe > >> the SoC details in the DT, like it's meant to be and like we do already, > >> but extended by putting the mux value in there as well. > >> So the only kernel contribution would then be the DT, really, (...) > > > > Your different positions have existed since the inception of the > > pinctrl subsystem: > > > > - One camp (myself included) wanted to describe the hardware mostly > > in the driver: functions, groups etc are tables in the driver file. > > > > - Another camp (OMAP included) think that the device tree should take > > store most things: groups functions, etc. > > > > What we know for sure should be described in DT is how different > > IP blocks are connected in an SoC (e.g. interrupts, clocks, DMA > > channels, regulators) and on the of course outside of the SoC, on > > the board. > > > > The question here is whether the way a hardware has instantiated > > a certain IP block when doing physical compilation in their > > Verilog, VHDL or SystemC files, is something that should be > > described in DT. > > > > Many companies have developed tools to > > extract this data from their hardware design files and provide > > it to developers as a blob och incomprehensible data, such was > > the situation for OMAP for example. So to them it made most > > sense to implement pinctrl-single, just parsing that data into > > DTS(I) files. > > > > Other companies (such as STMicroelectronics) instead put a > > team of people to write a datasheet with a special chapter > > on how pins etc are connected, and programmers are given > > this datasheet and need to again type in the data and define > > groups etc. > > > > Whether parametrization of a HW block should be done in the > > driver file from the compatible string or with custom attributes > > in the node is not a simple answer to the question. OF is vague > > on this kind of things: both solutions exist. > > > > Allwinner and Qualcomm authors faced a situation such as that > > they were given a code dump and no datasheet and no data > > tables either. That creates an especially complicated situation > > where none of the above scenarios apply. > > Allwinner do give user manual about the pin controller, and they're > used when we write the pinctrl-sunxi driver. That has not always been true for all the SoCs, and it's still not the case, even for newer SoCs. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Attachment:
signature.asc
Description: PGP signature
