Ang: Re: [PATCH 0/2] Setting GPIOs simultaneously

[Joakim Tjernlund]

-----Anton Vorontsov <avorontsov@xxxxxxxxxxxxx> skrev: -----
>Till: Joakim Tjernlund <joakim.tjernlund@xxxxxxxxxxxx>
>Från: Anton Vorontsov <avorontsov@xxxxxxxxxxxxx>
>Datum: 07/14/2009 00:20
>Kopia: David Brownell <dbrownell@xxxxxxxxxxxxxxxxxxxxx>,
>linux-kernel@xxxxxxxxxxxxxxx, linuxppc-dev@xxxxxxxxxx
>Ä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@xxxxxxxxxxxxxxxx/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: cbouatmailru@xxxxxxxxx
>irc://irc.freenode.net/bd2

--
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/