On Thu, Aug 22, 2013 at 9:07 AM, Sonic Zhang <sonic....@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/