On Tue, 18 Feb 2025 18:09:09 +0100
Jernej Škrabec <jernej.skrabec@xxxxxxxxx> wrote:
Hi,
> Dne petek, 14. februar 2025 ob 01:37:31 Srednjeevropski standardni čas je Andre Przywara napisal(a):
> > So far every Allwinner SoC needs a large table in the kernel code, to
> > describe the mapping between the pinctrl function names ("uart") and
> > the actual pincontroller mux value to be written into the registers.
> > This adds a lot of data into a single image kernel, and also looks
> > somewhat weird, as the DT can easily store the mux value.
> >
> > Add some code that allows to avoid that table: the struct that describes
> > the existing pins will be build at *runtime*, based on very basic
> > information provided by the respective SoC's pinctrl driver. This
> > consists of the number of pins per bank, plus information which bank
> > provides IRQ support, along with the mux value to use for that.
> > The code will then iterate over all children of the pincontroller DT
> > node (which describe each pin group), and populate that struct with the
> > mapping between function names and mux values. The only thing that needs
> > adding in the DT is a property with that value, per pin group.
> >
> > When this table is built, it will be handed over to the existing sunxi
> > pinctrl driver, which cannot tell a difference between a hardcoded
> > struct and this new one built at runtime. It will take care of
> > registering the pinctrl device with the pinctrl subsystem.
> >
> > All a new SoC driver would need to do is to provide two arrays, and then
> > call the sunxi_pinctrl_dt_table_init() function.
> >
> > Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx>
>
> I went through the code and it makes sense.
Many thanks, that's much appreciated!
> I wonder if we really need to
> build whole table instead of having on demand lookups into DT. However,
> for now, this will do. So:
I agree that would make some sense, but is also quite a departure from the
current driver, which we have been using for more than a decade now. And I
guess that would mean that we would need to maintain the two approaches,
for the old SoCs, and the new ones? With that patch here generic changes
can be applied just to the one core driver, dealing with the pinctrl
subsystem.
> Reviewed-by: Jernej Skrabec <jernej.skrabec@xxxxxxxxx>
Thanks,
Andre
> Thanks!
>
> Best regards,
> Jernej
>
