-----Anton Vorontsov <avoront...@ru.mvista.com> skrev: ----- >Till: Joakim Tjernlund <joakim.tjernl...@transmode.se> >Från: Anton Vorontsov <avoront...@ru.mvista.com> >Datum: 07/14/2009 00:20 >Kopia: David Brownell <dbrown...@users.sourceforge.net>, >linux-ker...@vger.kernel.org, linuxppc-...@ozlabs.org >Ärende: Re: [PATCH 0/2] Setting GPIOs simultaneously > > >On Mon, Jul 13, 2009 at 09:59:54PM +0200, Joakim Tjernlund wrote: >[...] >> > > While being at it, the reason for me needing this is that the spi_mpc83xx >driver >> > > was recently converted to a OF only driver so I have no way of defining >my own >> > > CS function anymore. While OF is good I don't feel that OF drivers >should >> > block the native >> > > method, OF should be a layer on top of the native methods. >> > >> > Um, I don't get it. You have a mux, which is a sort of GPIO controller. >> > All you need to do is to write "of-gpio-mux" driver, that will get all >> > the needed gpios from the underlaying GPIO controller. >> >> Well, I already have a mux controller that is using the native spi methods. >I >> don't want to write a new one, far more complicated than what I got now. >> While the OF system is very powerful and flexible I still think that >> one should be able to use native SPI methods too. Why can they not >> co-exist? > >I strongly believe that they can. You just need to post patches >so that we could see them, and maybe discuss how to do things >more generic. But if making things generic will be too hard (see >below), I don't think anybody will object applying a non-generic >solution (even permitting "legacy" bindings in the spi_8xxx driver). > >But any users of the legacy bindings should be in-tree.
ehh, it was working until you made it OF only. Why do call the native way legacy? It is the method all non OF arch uses. > >> > In the device tree it'll look like this: >> >> I must admit that I just started to look at the GPIO subsystem, but >> I do wonder if mpc83xx_spi_cs_control() can do this muxing >> without any change. >> >> Very good example BTW. > >Well, there is one caveat: the "GPIOs" aren't independent, >so thinking about it more, I believe we should now discuss >"chip-select framework", not gpio controllers (it could be >that using gpio controllers for this purpose wasn't that >good idea). > >http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg34738.html >^^^ I'm dreaming about this framework. I.e. true addressing > for chip-selects. :-) This is probably needed to support most SPI users out there, but until such framework is in place I think the native methods need to stay, right? As is now, SPI has regressed w.r.t earlier releases. Jocke BTW, I will be offline for a few days as of now. > >-- >Anton Vorontsov >email: cbouatmai...@gmail.com >irc://irc.freenode.net/bd2 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
