Re: [PATCH 1/3 v3] pinctrl: ADI PIN control driver for the GPIOcontroller on bf54x and bf60x.

[Sonic Zhang]

Hi Linus,

On Thu, Aug 29, 2013 at 4:12 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
> On Thu, Aug 22, 2013 at 9:07 AM, Sonic Zhang <sonic.adi@xxxxxxxxx> wrote:
>
>> There are 6 to 9 GPIO HW blocks in one Blackfin SoC. Function
>> pinmux_enable_setting() in current pinctrl framework assumes the
>> function mux setting of one peripheral pin group is configured in one
>> pinctrl device. But, the function mux setting of one blackfin
>> peripheral may be done among different GPIO HW blocks. So, I have to
>> separate the pinctrl driver from the GPIO block driver add the ranges
>> of all GPIO blocks into one pinctrl device for Blackfin.
>
> This is similar to the situation in the pinctrl-nomadik.c driver,
> where the pinctrl portions wait for the GPIO devices to instantiate
> before proceeding to probe "on top" of the GPIO blocks, using
> the latter to get to the registers.
>
> I am not sure we have found the best way to sort out this
> type of system, let's see what we can come up with.

In the blackfin pinctrol-adi2 driver, I probe all gpio devices
independently after all logic pinctrl devices. When one gpio device is
probed, it can get its pinctrl device name from its platform data and
add its gpio range into the pinctrl device via
gpiochip_add_pin_range(). The gpio device don't need to know anything
else about its pinctrl device.

Regards,

Sonic

>
> One way I was contemplating was to have just one fat node
> in the device tree containing all the register ranges, and one
> fat probe function, so all these ranges associated with a
> single struct device, but that does not well work with
> clocking and interrupts (the GPIO ranges needed one
> clock and interrupt each) so I gave up on that idea.
>
> My latest idea was to to to break the subsystems apart a
> bit by letting GPIO devices probe without the underlying
> pin controller being in place, so I queued up the operations
> until the pin controller arrived, but unfortunately this creates
> other problems :-(
>
> Still this creates a fuzz when trying to refactor stuff so we
> need to find a solution.
>
> Yours,
> Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/