Re: Ang: Re: [PATCH 0/2] Setting GPIOs simultaneously
Anton Vorontsov avoront...@ru.mvista.com wrote on 15/07/2009 00:09:31: On Tue, Jul 14, 2009 at 11:20:13PM +0200, Joakim Tjernlund wrote: [...] 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. It's legacy because there are no in-tree users anymore. Nowadays we're trying to pass all needed information via OF, and we're trying to avoid ugly platform-dependant hacks. Your SPI scheme can be easily described via OF, but sure, it's hard to implement it with the current SPI/OF subsystem. Sorry for the long delay, I have been on vaction and been busy with other stuff. Tell me, how does this new OF SPI device scheme work out if you want to use the bitbanged SPI driver? [...] 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? I'm not the right person to ask. I can only express my opinions. The maintainer make final decision. But if you ask for my opinion, I don't think that they should stay unless we'll see a user in the mainline. As is now, SPI has regressed w.r.t earlier releases. Yes and no. Yes, it has regressed for out-of-tree code, and no, I don't feel sorry about that. :-) That is a Yes and some bla bla so the answer is yes. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Ang: Re: [PATCH 0/2] Setting GPIOs simultaneously
On Tue, Aug 04, 2009 at 03:38:40PM +0200, Joakim Tjernlund wrote:
Anton Vorontsov avoront...@ru.mvista.com wrote on 15/07/2009 00:09:31:
On Tue, Jul 14, 2009 at 11:20:13PM +0200, Joakim Tjernlund wrote:
[...]
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.
It's legacy because there are no in-tree users anymore. Nowadays
we're trying to pass all needed information via OF, and we're
trying to avoid ugly platform-dependant hacks. Your SPI scheme
can be easily described via OF, but sure, it's hard to implement
it with the current SPI/OF subsystem.
Sorry for the long delay, I have been on vaction and been busy with other
stuff.
Tell me, how does this new OF SPI device scheme work out if you want
to use the bitbanged SPI driver?
spi-controller {
...
compatible = generic-bitbang-spi;
gpios = GPIO_CLK GPIO_MOSI GPIO_MISO;
spi,chip-select-machines = gpio_csm board_csm;
gpio_csm: chip-select-machine {
#address-cells = 1;
#size-cells = 0;
compatible = generic-gpio-csm;
gpios = GPIO_CS1 GPIO_CS2;
touchscr...@0 {
reg = 0; /* using GPIO CS1 */
};
eep...@1 {
reg = 1; /* using GPIO CS2 */
};
};
};
localbus {
...
board_csm: chip-select-machine {
#address-cells = 1;
#size-cells = 0;
compatibe = board-specific-csm;
light-sen...@0 {
reg = 0; /* using board-specific CS3 */
};
batt...@1 {
reg = 1; /* using board-specific CS4 */
};
};
};
--
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
Re: Ang: Re: [PATCH 0/2] Setting GPIOs simultaneously
Anton Vorontsov avoront...@ru.mvista.com wrote on 04/08/2009 16:22:50:
On Tue, Aug 04, 2009 at 03:38:40PM +0200, Joakim Tjernlund wrote:
Anton Vorontsov avoront...@ru.mvista.com wrote on 15/07/2009 00:09:31:
On Tue, Jul 14, 2009 at 11:20:13PM +0200, Joakim Tjernlund wrote:
[...]
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.
It's legacy because there are no in-tree users anymore. Nowadays
we're trying to pass all needed information via OF, and we're
trying to avoid ugly platform-dependant hacks. Your SPI scheme
can be easily described via OF, but sure, it's hard to implement
it with the current SPI/OF subsystem.
Sorry for the long delay, I have been on vaction and been busy with other
stuff.
Tell me, how does this new OF SPI device scheme work out if you want
to use the bitbanged SPI driver?
spi-controller {
...
compatible = generic-bitbang-spi;
gpios = GPIO_CLK GPIO_MOSI GPIO_MISO;
spi,chip-select-machines = gpio_csm board_csm;
gpio_csm: chip-select-machine {
#address-cells = 1;
#size-cells = 0;
compatible = generic-gpio-csm;
gpios = GPIO_CS1 GPIO_CS2;
touchscr...@0 {
reg = 0; /* using GPIO CS1 */
};
eep...@1 {
reg = 1; /* using GPIO CS2 */
};
};
};
localbus {
...
board_csm: chip-select-machine {
#address-cells = 1;
#size-cells = 0;
compatibe = board-specific-csm;
light-sen...@0 {
reg = 0; /* using board-specific CS3 */
};
batt...@1 {
reg = 1; /* using board-specific CS4 */
};
};
};
hmm, this looks promising. Can I write my own board-specific-csm
and attach it to the SPI CS engine? I don't quite
se how, the 8xxx SPI driver only looks for gpio functions.
Perhaps this is something that you are working on?
Jocke
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Ang: Re: [PATCH 0/2] Setting GPIOs simultaneously
-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
Re: Ang: Re: [PATCH 0/2] Setting GPIOs simultaneously
On Tue, Jul 14, 2009 at 11:20:13PM +0200, Joakim Tjernlund wrote: [...] 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. It's legacy because there are no in-tree users anymore. Nowadays we're trying to pass all needed information via OF, and we're trying to avoid ugly platform-dependant hacks. Your SPI scheme can be easily described via OF, but sure, it's hard to implement it with the current SPI/OF subsystem. [...] 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? I'm not the right person to ask. I can only express my opinions. The maintainer make final decision. But if you ask for my opinion, I don't think that they should stay unless we'll see a user in the mainline. As is now, SPI has regressed w.r.t earlier releases. Yes and no. Yes, it has regressed for out-of-tree code, and no, I don't feel sorry about that. :-) -- 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
