On Tue, Dec 11, 2007 at 10:04:53AM +1100, David Gibson wrote:
> On Mon, Dec 10, 2007 at 11:47:05PM +0300, Anton Vorontsov wrote:
> > Hi all,
> >
> > Here are patches to support NAND on UPM. That driver is generic for
> > all processors with FSL UPMs. And because of that, few more patches are
> > needed -- GPIO API and generic FSL UPM functions.
> >
> > This is early RFC, all patches are in single thread, so everyone could
> > make up overall picture of what is going on. I'll split the thread by
> > topics after that RFC.
> >
> > Ok, the patches and what they are for:
> >
> > 1,2,3,4. GPIO API:
> > ------------------
> > Usually NAND chips exports RNB (Ready-Not-Busy) pin, so drivers
> > could read it and get a hint when chip is ready.
> >
> > Often, WP (write protect) pin is also connected to GPIO. So, GPIO API
> > is mandatory for generic drivers.
> >
> > OF device tree GPIOs bindings are similar to IRQs:
> >
> > node {
> > gpios = <bank pin bank pin bank pin>;
> > gpio-parent = <&par_io_controller>;
> > };
> >
> > "bank pin" scheme is controller specific, so controllers that want
> > to implement flat mappings or any other could do so.
>
> It might be safest to do as is done for interrupts, and not define the
> internal format at all.
This is how it is done already. Take a look into second and third patches:
+static int par_io_xlate(struct device_node *np, int index)
+{
+ return __of_parse_gpio_bank_pin(np, index, 32, num_par_io_ports);
+}
+
+static struct of_gpio_chip of_gpio_chip = {
+ .xlate = par_io_xlate,
+};
__of_parse_gpio_bank_pin() is helper function, I just factored
it out, because both QE and CPM2 using same format.
But generally, controllers are encouraged to do their own xlates.
Or am I missing the point?
> The gpio within the gpio controller would be
> defined by a gpio-descriptor whose format is determined by the
> controller. You would need to add a #gpio-cells property in this
> case, so you can at least determine the size of the descriptors
> associated with a particular gpio controller.
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
