Messages in this thread | | | Date | Thu, 29 Aug 2013 10:12:45 +0200 | Subject | Re: [PATCH 1/3 v3] pinctrl: ADI PIN control driver for the GPIO controller on bf54x and bf60x. | From | Linus Walleij <> |
| |
On Thu, Aug 22, 2013 at 9:07 AM, Sonic Zhang <sonic.adi@gmail.com> 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.
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
| |