[U-Boot] [PATCH v1 02/11] sunxi: add pinctrl (UCLASS_PINCTRL) support for sunxi and tie back into GPIO

[Dr. Philipp Tomsich]

ChenYu,

> On 22 Feb 2017, at 07:07, Chen-Yu Tsai <wens at csie.org> wrote:
> 
>> (b) binding the existing gpio driver to the same node (but as the driverdata
>> needs to be matched as well, we’d need to select this based on the
>> compatible string and have a tighter coupling between the drivers than
>> strictly necessary)
> 
> They really should be the same driver. They control the same piece of hardware,
> just exporting different functions to the 2 subsystems. There should be proper
> locking between the 2, as Allwinner's hardware cannot simultaneously mux a pin
> to some function and provide GPIO functionality. The user should not be able
> to request a GPIO on a pin that is already claimed by a UART or MMC card.

This is already being revised, although (with the user being able to change the
function assignment via mw.l — which we use a lot during bringup ourselves)
the data used by the driver might get modified hardware (as we fetch the latest
info directly from the hardware at all times).

Stay tuned for v2...

>> (c) dynamically creating gpio subnodes (just as done by the top-level
>> sunxi_gpio instances) for each of the banks from within the pinctrl driver
>> 
>> Another reason why we felt the gpiobank to be helpful is that it allows us
>> to
>> easily describe where the register sets (i.e. PIO and IRQ) are for each
>> bank.
> 
> These are always at fixed multiple offsets in Allwinner's design though.
> The driver can always calculate which registers it needs to access from
> the pin name/number. IRQ bank relations are also encoded in the pinctrl
> tables you imported. Everything needed is available in code.

I have to disagree on the ext-interrupt aspect of the pinctrl.
E.g. on the A31, we had ext-interrupt for PA at 0x200 and PB at 0x200, while
it’s now

Doesn’t really matter at this point though, as a new version with the changes
requested by you and Maxime will be coming shortly.

>> This will then require sharing the (internal) driver data structure from the
>> gpio-driver with pinctrl and populating it from the pinctrl probe… i.e. we
>> had
>> this in an earlier version of the changes, but it looked messy.
> 
> The Linux kernel driver also has pinctrl and gpio in the same driver. However
> the difference is that the kernel probes device tree nodes as platform devices,
> and the device driver then registers pinctrl and gpio functions.
> 
> The U-boot model is a simplified one assuming that one device only has one
> function, which is not always true. You're going to run into the same issue
> with the CCU, which provides clocks and reset controls.

I fully agree, but didn’t want to open a question regarding whether the device
tree parsing and driver instantiation in U-Boot should be extended in a similar
way (i.e. continue looking for drivers that match a node beyond the first match)
at this stage.

We might in fact want to propose both solutions now, as we may need to have a
discussion about this...

Regards,
Philipp.