Re: [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC

[Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]

On Wed, Jan 18, 2017 at 10:44 AM, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> 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.

What we/you need to ask: what is most helpful for the Allwinner
community? What makes the barrier low for new contributions,
and makes it easiest to cooperate?

I try to live by this motto from IETF:

   "rough consensus and running code"

Please do the same.

Yours,
Linus Walleij