Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Tue, May 12, 2015 at 04:27:59PM +0200, Maxime Ripard wrote: > On Mon, Apr 27, 2015 at 07:07:28PM +0100, Mark Brown wrote: > > Probably best, the Pi bootloader does make it a bit more important. > > Might also be worth speaking to Greg though. > So, do you want me to resend that patch and discuss this directly > there (with Greg in Cc) ? Sounds like a good first step. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
Hello, On 12 May 2015 at 16:27, Maxime Ripard wrote: > On Mon, Apr 27, 2015 at 07:07:28PM +0100, Mark Brown wrote: >> On Mon, Apr 27, 2015 at 07:30:36PM +0200, Maxime Ripard wrote: >> > On Mon, Apr 27, 2015 at 11:16:01AM +0100, Mark Brown wrote: >> >> > > lkml.org is being terrible as usual so I can't see half the thread (or >> > > at least got fed up trying to get it to load) >> >> > A part of it is also here: >> > http://lkml.iu.edu/hypermail/linux/kernel/1405.0/00484.html >> >> OK, thanks. >> >> > > but I think the discussion there petered out more than anything >> > > else. >> >> > Maybe it did :) >> >> I think so looking at the archives. >> >> > > Or was it the suggestion to make this something that the driver core >> > > supported so that we didn't have to open code it for every bus? >> >> > Probably. That's something I really haven't took the time to look at, >> > and don't really plan on doing so. >> >> > I guess a good way forward would be to revive this patch, and wait for >> > that generic way to happen. >> >> > What do you think of this? >> >> Probably best, the Pi bootloader does make it a bit more important. >> Might also be worth speaking to Greg though. > > So, do you want me to resend that patch and discuss this directly > there (with Greg in Cc) ? My general idea is to get overlay loading to work and then make spidev bind to all CS which are not taken by anything and unbind when an overlay tries to take over the CS. Since there are some overlay loading patches available that part can be considered solved but I did not get to looking at the dynamic spidev binding. For now I use your patch with additional patch that marks the spidev devices with a flag so they are not checked when it is determined if the CS is in use. Thanks Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Mon, Apr 27, 2015 at 07:07:28PM +0100, Mark Brown wrote: > On Mon, Apr 27, 2015 at 07:30:36PM +0200, Maxime Ripard wrote: > > On Mon, Apr 27, 2015 at 11:16:01AM +0100, Mark Brown wrote: > > > > lkml.org is being terrible as usual so I can't see half the thread (or > > > at least got fed up trying to get it to load) > > > A part of it is also here: > > http://lkml.iu.edu/hypermail/linux/kernel/1405.0/00484.html > > OK, thanks. > > > > but I think the discussion there petered out more than anything > > > else. > > > Maybe it did :) > > I think so looking at the archives. > > > > Or was it the suggestion to make this something that the driver core > > > supported so that we didn't have to open code it for every bus? > > > Probably. That's something I really haven't took the time to look at, > > and don't really plan on doing so. > > > I guess a good way forward would be to revive this patch, and wait for > > that generic way to happen. > > > What do you think of this? > > Probably best, the Pi bootloader does make it a bit more important. > Might also be worth speaking to Greg though. So, do you want me to resend that patch and discuss this directly there (with Greg in Cc) ? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Mon, May 04, 2015 at 12:42:03PM +0200, Michal Suchanek wrote: > On 4 May 2015 at 12:12, Mark Brown wrote: > > I'm confused. What would the point of the functionality be if not to > > override the existing data, otherwise we'd already have bound the > > driver? > Presumably you can swap different versions of a driver this way. > Many devices have two drivers in Linux (old and new) which are > obviously both compatible. Many? We have a couple but if we ever have many then that would be a bit of a disaster. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On 4 May 2015 at 12:12, Mark Brown wrote: > On Sun, May 03, 2015 at 11:00:40PM +0200, Martin Sperl wrote: > >> I will investigate the fine details, but I fear we may need some >> “compatibility” magic similar to “new_id” in USB to make it work, >> because it seems as if you can ONLY force a driver to bind if it >> _is_ compatible... > > I'm confused. What would the point of the functionality be if not to > override the existing data, otherwise we'd already have bound the > driver? Presumably you can swap different versions of a driver this way. Many devices have two drivers in Linux (old and new) which are obviously both compatible. Loading driver which is not compatible is something which you probably do not want to be done easily as much as sending random junk to SPI devices controlled by a kernel driver. I am, of course, enjoying the ability to send some ID command to a flash memory which is technically controlled by a kernel driver when I physically replace the chip in the socket or the chip was not seated well to start with and I want to check that it's working without rebooting the board. Thanks Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Sun, May 03, 2015 at 11:00:40PM +0200, Martin Sperl wrote: > I will investigate the fine details, but I fear we may need some > “compatibility” magic similar to “new_id” in USB to make it work, > because it seems as if you can ONLY force a driver to bind if it > _is_ compatible... I'm confused. What would the point of the functionality be if not to override the existing data, otherwise we'd already have bound the driver? > But from what I can tell this functionality (mentioned in this article > by Greg) has not been moved into driver-core and bus, so we would need > to run our own version of it. That seems like things are being done at the wrong level. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
Hello, On 3 May 2015 at 23:00, Martin Sperl wrote: > >> On 03.05.2015, at 11:59, Mark Brown wrote: >> Hrm, yes - that should work. I'd ask Greg, that's not something the bus >> implements. > > It is still slightly more “complicated” from a distribution perspective, > but if that is what makes it a “clean” solution, then that is the way to > go forward. > > I will investigate the fine details, but I fear we may need some > “compatibility” magic similar to “new_id” in USB to make it work, > because it seems as if you can ONLY force a driver to bind if it > _is_ compatible... > > See also here: https://lwn.net/Articles/143397/ > > But from what I can tell this functionality (mentioned in this article > by Greg) has not been moved into driver-core and bus, so we would need > to run our own version of it. Maybe you could make the spidev driver magically bind to any CS to which no other driver is bound? This would also probably solve the problem with the device going away when the driver is unbound if that still happens. Thanks Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
> On 03.05.2015, at 11:59, Mark Brown wrote: > Hrm, yes - that should work. I'd ask Greg, that's not something the bus > implements. It is still slightly more “complicated” from a distribution perspective, but if that is what makes it a “clean” solution, then that is the way to go forward. I will investigate the fine details, but I fear we may need some “compatibility” magic similar to “new_id” in USB to make it work, because it seems as if you can ONLY force a driver to bind if it _is_ compatible... See also here: https://lwn.net/Articles/143397/ But from what I can tell this functionality (mentioned in this article by Greg) has not been moved into driver-core and bus, so we would need to run our own version of it. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Sun, May 3, 2015 at 11:01 AM, Martin Sperl wrote:
>> On 30.04.2015, at 21:58, Mark Brown wrote:
>> A big reason for that is that it's not in my inbox for me to review,
>> these messages I flagged as unhelpful aren't going to help with that if
>> only because I don't want to create the impression that such behaviour
>> achieves results.
>
> What about implementing it like this:
> echo -n “spi32761.4” > /sys/bus/spi/drivers/spidev/bind
>
> Would this be an acceptable solution?
>
> This is actually mentioned in Documentation/spi/spidev as a
> possible option for the future - quote:
>
>> (Sysfs also supports userspace driven binding/unbinding of drivers to
>> devices. That mechanism might be supported here in the future.)
>
> Not sure why it does not work right now (but it works for “real”
> device-drivers), but I guess it has to do with compatibility checks.
IIRC, PCI drivers support adding more compatible entries through /sysfs.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Sun, May 03, 2015 at 11:01:05AM +0200, Martin Sperl wrote: > What about implementing it like this: > echo -n “spi32761.4” > /sys/bus/spi/drivers/spidev/bind > Would this be an acceptable solution? > This is actually mentioned in Documentation/spi/spidev as a > possible option for the future - quote: > > (Sysfs also supports userspace driven binding/unbinding of drivers to > > devices. That mechanism might be supported here in the future.) > Not sure why it does not work right now (but it works for “real” > device-drivers), but I guess it has to do with compatibility checks. Hrm, yes - that should work. I'd ask Greg, that's not something the bus implements. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
> On 30.04.2015, at 21:58, Mark Brown wrote: > > A big reason for that is that it's not in my inbox for me to review, > these messages I flagged as unhelpful aren't going to help with that if > only because I don't want to create the impression that such behaviour > achieves results. > What about implementing it like this: echo -n “spi32761.4” > /sys/bus/spi/drivers/spidev/bind Would this be an acceptable solution? This is actually mentioned in Documentation/spi/spidev as a possible option for the future - quote: > (Sysfs also supports userspace driven binding/unbinding of drivers to > devices. That mechanism might be supported here in the future.) Not sure why it does not work right now (but it works for “real” device-drivers), but I guess it has to do with compatibility checks. Martin -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Wed, Apr 29, 2015 at 08:37:24PM +0200, Michal Suchanek wrote: > On 29 April 2015 at 20:06, Mark Brown wrote: > > I think the rest of the thread had that covered - there's both adding > > the device IDs and Maxime's patch. > And adding device IDs is unacceptable for users of devboards while > Maxime's patch is not accepted into the kernel. > I am using a version of Maxime's patch myself right now. It does not > seem it's going to be include in the kernel any time soon, however. A big reason for that is that it's not in my inbox for me to review, these messages I flagged as unhelpful aren't going to help with that if only because I don't want to create the impression that such behaviour achieves results. > FWIW I added the ability to open any CS, even those claimed by kernel > drivers. This addresses any potential race of spidev binding before > the actual driver but has the potential to introduce some subtle bugs > when you open and reconfigure a CS used by a kernel driver or send > some commands that upset the device. This doesn't seem like an obviously good idea - having userspace be able to interact with a device without a running kernel driver knowing about it doesn't seem like something that will end well. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
Hi, I give Maxime's patch a try, but get divide by zero in kernel traces due to spi max speed not being setted. I then tried declaring spidev in the DT, and my application just work's. Adding spi0 alias in DT give's me a beautyful /dev/spidev0.0, where Maxime's was creating /dev/spidev0.[0-3] nodes. Thanks Eric -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On 29 April 2015 at 20:56, Geert Uytterhoeven wrote: > On Wed, Apr 29, 2015 at 8:37 PM, Michal Suchanek wrote: >> I am using a version of Maxime's patch myself right now. It does not >> seem it's going to be include in the kernel any time soon, however. >> >> FWIW I added the ability to open any CS, even those claimed by kernel >> drivers. This addresses any potential race of spidev binding before >> the actual driver but has the potential to introduce some subtle bugs >> when you open and reconfigure a CS used by a kernel driver or send >> some commands that upset the device. > > Uh, that sounds dangerous. > > Perhaps you can add some safety net, before user space can access > them, cfr. /sys/class/gpio/export? > That's what accessing random devices from userspace is. I can issue the identify commead to my SPI flash allright since it is idle. I am not sure of its protocol details but I am quite sure that some displays have data transfers that allow pauses so if I sent a command during a screen update it would likely get inserted into the framebuffer bitstream. And changing CS polarity or something like that will certainly have interesting results. Still not binding spidev to busy CS is just one test that can be compiled in as an option. If things stay this simple I don't see much problem with that. Thanks Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Wed, Apr 29, 2015 at 8:37 PM, Michal Suchanek wrote:
> I am using a version of Maxime's patch myself right now. It does not
> seem it's going to be include in the kernel any time soon, however.
>
> FWIW I added the ability to open any CS, even those claimed by kernel
> drivers. This addresses any potential race of spidev binding before
> the actual driver but has the potential to introduce some subtle bugs
> when you open and reconfigure a CS used by a kernel driver or send
> some commands that upset the device.
Uh, that sounds dangerous.
Perhaps you can add some safety net, before user space can access
them, cfr. /sys/class/gpio/export?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On 29 April 2015 at 20:06, Mark Brown wrote: > On Wed, Apr 29, 2015 at 07:44:59PM +0200, Michal Suchanek wrote: >> On 29 April 2015 at 19:40, Mark Brown wrote: > >> > Please stop this, it is not helpful. > >> Then please make one of the useful ways of instantiating spidev nodes >> approved or suggest another that when implemented can be mainlined. > > I think the rest of the thread had that covered - there's both adding > the device IDs and Maxime's patch. And adding device IDs is unacceptable for users of devboards while Maxime's patch is not accepted into the kernel. I am using a version of Maxime's patch myself right now. It does not seem it's going to be include in the kernel any time soon, however. FWIW I added the ability to open any CS, even those claimed by kernel drivers. This addresses any potential race of spidev binding before the actual driver but has the potential to introduce some subtle bugs when you open and reconfigure a CS used by a kernel driver or send some commands that upset the device. Thanks Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Wed, Apr 29, 2015 at 07:44:59PM +0200, Michal Suchanek wrote: > On 29 April 2015 at 19:40, Mark Brown wrote: > > Please stop this, it is not helpful. > Then please make one of the useful ways of instantiating spidev nodes > approved or suggest another that when implemented can be mainlined. I think the rest of the thread had that covered - there's both adding the device IDs and Maxime's patch. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On 29 April 2015 at 19:40, Mark Brown wrote: > On Tue, Apr 28, 2015 at 10:43:37PM +0200, Michal Suchanek wrote: > >> > I know you have a viewpoint on this but engaging in this way is not >> > helping anyone. > >> The point is that patching the kernel to use spidev is totally useless >> complication which is brought on spidev users by obtuse kernel >> maintainers. > >> This patch applied to a kernel which is distributed with the board >> solves the problem for all spidev users of the board which >> TheApprovedWay(tm) does not. > > Please stop this, it is not helpful. Then please make one of the useful ways of instantiating spidev nodes approved or suggest another that when implemented can be mainlined. Thanks Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Tue, Apr 28, 2015 at 10:43:37PM +0200, Michal Suchanek wrote: > > I know you have a viewpoint on this but engaging in this way is not > > helping anyone. > The point is that patching the kernel to use spidev is totally useless > complication which is brought on spidev users by obtuse kernel > maintainers. > This patch applied to a kernel which is distributed with the board > solves the problem for all spidev users of the board which > TheApprovedWay(tm) does not. Please stop this, it is not helpful. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On 28 April 2015 at 19:17, Mark Brown wrote: > On Tue, Apr 28, 2015 at 04:22:24PM +0200, Michal Suchanek wrote: >> On 28 April 2015 at 16:16, Mark Brown wrote: > >> > That is not the case as you well know. As has been said several times >> > the compatible for the device should be added to the match table in >> > spidev.c. > >> That's a way unusable for people who actually want to use spidev so it >> might be TheApprovedWay(tm) but not RightWay(tm). > > I'm pretty sure that someone who's able to edit one file can edit two. > I know you have a viewpoint on this but engaging in this way is not > helping anyone. The point is that patching the kernel to use spidev is totally useless complication which is brought on spidev users by obtuse kernel maintainers. This patch applied to a kernel which is distributed with the board solves the problem for all spidev users of the board which TheApprovedWay(tm) does not. Thanks Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Tue, Apr 28, 2015 at 04:22:24PM +0200, Michal Suchanek wrote: > On 28 April 2015 at 16:16, Mark Brown wrote: > > That is not the case as you well know. As has been said several times > > the compatible for the device should be added to the match table in > > spidev.c. > That's a way unusable for people who actually want to use spidev so it > might be TheApprovedWay(tm) but not RightWay(tm). I'm pretty sure that someone who's able to edit one file can edit two. I know you have a viewpoint on this but engaging in this way is not helping anyone. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On 28 April 2015 at 16:12, Maxime Ripard
wrote:
> On Tue, Apr 28, 2015 at 07:03:16AM -0700, Eric D. wrote:
>> Hi,
>>
>> I give Maxime's patch a try and got 4 spidev devices :
>> /dev/spidev32766.[0-3]
>>
>> root@bpi:~# ls -lh /dev/spidev*
>> crw--- 1 root root 153, 0 Apr 28 15:52 /dev/spidev32766.0
>> crw--- 1 root root 153, 1 Apr 28 15:52 /dev/spidev32766.1
>> crw--- 1 root root 153, 2 Apr 28 15:52 /dev/spidev32766.2
>> crw--- 1 root root 153, 3 Apr 28 15:52 /dev/spidev32766.3
>>
>> Shouldn't they be numbered from like spidev0.[0-3].
>> Is this an udev problem ? any clues ?
>
> You're missing an SPI alias in the DT.
Indeed, adding some SPI aliases makes the device nodes tidier:
aliases {
serial0 = &uart0;
serial1 = &uart2;
serial2 = &uart3;
spi0 = &spi0;
spi1 = &spi1;
spi2 = &spi2;
};
However, SPI usage examples I have seen showed some random high number.
Thanks
Michal
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On 28 April 2015 at 16:16, Mark Brown wrote: > On Tue, Apr 28, 2015 at 02:52:54PM +0200, Michal Suchanek wrote: >> On 28 April 2015 at 14:15, Eric D. wrote: > >> > I was just seeking a way to make spidev device appear under mainline kernel >> > and found this thread. >> > Could someone explain the right way to do this ? > >> There is no approved RightWay(tm). > > That is not the case as you well know. As has been said several times > the compatible for the device should be added to the match table in > spidev.c. That's a way unusable for people who actually want to use spidev so it might be TheApprovedWay(tm) but not RightWay(tm). Thanks Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Tue, Apr 28, 2015 at 02:52:54PM +0200, Michal Suchanek wrote: > On 28 April 2015 at 14:15, Eric D. wrote: > > I was just seeking a way to make spidev device appear under mainline kernel > > and found this thread. > > Could someone explain the right way to do this ? > There is no approved RightWay(tm). That is not the case as you well know. As has been said several times the compatible for the device should be added to the match table in spidev.c. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Tue, Apr 28, 2015 at 07:03:16AM -0700, Eric D. wrote: > Hi, > > I give Maxime's patch a try and got 4 spidev devices : > /dev/spidev32766.[0-3] > > root@bpi:~# ls -lh /dev/spidev* > crw--- 1 root root 153, 0 Apr 28 15:52 /dev/spidev32766.0 > crw--- 1 root root 153, 1 Apr 28 15:52 /dev/spidev32766.1 > crw--- 1 root root 153, 2 Apr 28 15:52 /dev/spidev32766.2 > crw--- 1 root root 153, 3 Apr 28 15:52 /dev/spidev32766.3 > > Shouldn't they be numbered from like spidev0.[0-3]. > Is this an udev problem ? any clues ? You're missing an SPI alias in the DT. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On 28 April 2015 at 16:03, Eric D. wrote: > Hi, > > I give Maxime's patch a try and got 4 spidev devices : > /dev/spidev32766.[0-3] > > root@bpi:~# ls -lh /dev/spidev* > crw--- 1 root root 153, 0 Apr 28 15:52 /dev/spidev32766.0 > crw--- 1 root root 153, 1 Apr 28 15:52 /dev/spidev32766.1 > crw--- 1 root root 153, 2 Apr 28 15:52 /dev/spidev32766.2 > crw--- 1 root root 153, 3 Apr 28 15:52 /dev/spidev32766.3 > > Shouldn't they be numbered from like spidev0.[0-3]. > Is this an udev problem ? any clues ? I don't know where the 32766 comes from but it's normal. It seems to be the same number every time for the same port. If you really wanted you could probably rename the device nodes with udev. Or with only one spi bus enabled /dev/spidev*.0 should work too. Thanks Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
Hi, I give Maxime's patch a try and got 4 spidev devices : /dev/spidev32766.[0-3] root@bpi:~# ls -lh /dev/spidev* crw--- 1 root root 153, 0 Apr 28 15:52 /dev/spidev32766.0 crw--- 1 root root 153, 1 Apr 28 15:52 /dev/spidev32766.1 crw--- 1 root root 153, 2 Apr 28 15:52 /dev/spidev32766.2 crw--- 1 root root 153, 3 Apr 28 15:52 /dev/spidev32766.3 Shouldn't they be numbered from like spidev0.[0-3]. Is this an udev problem ? any clues ? For now I will try with this devices. Thanks a lot, Eric On Tuesday, April 28, 2015 at 2:53:37 PM UTC+2, Michal Suchanek wrote: > > On 28 April 2015 at 14:15, Eric D. > > wrote: > > Hi, > > > > I'am a mainline linux user of A20 (bananapi). I'am currently running a > > debian jessie with latest mainline kernel (4.0.0+). > > I have a project of home automation, based on nrfl04+ spi driven > wireless > > chip. > > I was just seeking a way to make spidev device appear under mainline > kernel > > and found this thread. > > Could someone explain the right way to do this ? > > There is no approved RightWay(tm). > > However, you can use this patch: > > https://lkml.org/lkml/2014/4/28/612 > > which is probably the least controversial way for now. > > The example at the start of the thread also works but is > CertainlyNotApprovedWay(tm). > > HTH > > Michal > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On 28 April 2015 at 14:15, Eric D. wrote: > Hi, > > I'am a mainline linux user of A20 (bananapi). I'am currently running a > debian jessie with latest mainline kernel (4.0.0+). > I have a project of home automation, based on nrfl04+ spi driven wireless > chip. > I was just seeking a way to make spidev device appear under mainline kernel > and found this thread. > Could someone explain the right way to do this ? There is no approved RightWay(tm). However, you can use this patch: https://lkml.org/lkml/2014/4/28/612 which is probably the least controversial way for now. The example at the start of the thread also works but is CertainlyNotApprovedWay(tm). HTH Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
Hi, I'am a mainline linux user of A20 (bananapi). I'am currently running a debian jessie with latest mainline kernel (4.0.0+). I have a project of home automation, based on nrfl04+ spi driven wireless chip. I was just seeking a way to make spidev device appear under mainline kernel and found this thread. Could someone explain the right way to do this ? Thanks for your time, Regards, Eric -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Mon, Apr 27, 2015 at 07:30:36PM +0200, Maxime Ripard wrote: > On Mon, Apr 27, 2015 at 11:16:01AM +0100, Mark Brown wrote: > > lkml.org is being terrible as usual so I can't see half the thread (or > > at least got fed up trying to get it to load) > A part of it is also here: > http://lkml.iu.edu/hypermail/linux/kernel/1405.0/00484.html OK, thanks. > > but I think the discussion there petered out more than anything > > else. > Maybe it did :) I think so looking at the archives. > > Or was it the suggestion to make this something that the driver core > > supported so that we didn't have to open code it for every bus? > Probably. That's something I really haven't took the time to look at, > and don't really plan on doing so. > I guess a good way forward would be to revive this patch, and wait for > that generic way to happen. > What do you think of this? Probably best, the Pi bootloader does make it a bit more important. Might also be worth speaking to Greg though. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Mon, Apr 27, 2015 at 06:25:26PM +0200, Martin Sperl wrote: > > On 27.04.2015, at 17:27, Mark Brown wrote: > > OK, so that is just a default overlay which is abusing the fact that we > > will bind to spidev without a DT compatible and when the binding is > > undocumented (which also applies to other devices and buses sadly). > > Unfortunately nobody ever mentioned this upstream and the feedback > > upstream that listing spidev in a DT is a bad idea has been ignored. > Maybe it should also have been documented as such in > Documentation/spi/spidev or in Documentation/devicetree/bindings/spi/ It was documented in the DT bindings in that there was no documented binding; people are in general expected to know that anything they're using should be documented. For the main spidev document I guess it's something similar, though if you can think of something there by all means send a patch. > > The whole reason we're doing this in the first place is that we got sick > > of telling people that using spidev in DTs like this was a bad idea. > The only reference I found in my history of the spi-list is this email: It mostly comes up in review of DT files for boards so won't be on the SPI list. > > It does sound like the people maintianing the u-boot fork for the Pi > > need to talk to both u-boot upstream (nothing here is specific to the > > Pi that I can see) and the kernel community a bit more. I'd be a bit > > worried that they may be relying on other things that just happen to > > work without being intentional (and are therefore more vulnerable to > > issues) and it's a bit depressing to see things like this stuck in a > > fork where only a limited community can make use of them. > Actually this functionality is not in u-boot, but in the firmware > boot-loader itself, which can load the kernel (and the devicetree) > without u-boot, but which can also load u-boot as an additional > intermediate boot-stage. Ugh, right. The thing about talking to the kernel community does still stand though. > >> The only thing that could possibly be better would be that > >> the user would define the "real" name of the device in the > >> device tree and spidev would bind to it if there is no driver > >> available (but that would require this "fallback" binding by > >> spidev in case of no driver). > > Yes, that is exactly the solution I'd suggest - change the UI to provide > > a DT compatible to be used for the new device. That would also have the > > benefit of meaning that users who have connected some device that does > > have a driver that works with a simple binding wouldn't need to write an > > overlay which seems like it should be useful. > Well then why did you just make the system complain loudly and bringing > problems to people instead of solving it in a usable manner that does not > require people to maintain an out of tree patch to work around that warning? This is quite honestly the first time I've heard of this bootloader interface that's been implemented for the Pi. All the other users I've been aware of have been writing DT files or overlays in tree and therefore it's not a substantial effort (and indeed the misuse is basically just people being lazy) - if you can use the shipped binaries it's a very different tradeoff. > We still have the one-line warning about using the depreciated > spi_master.transfer interface, but it is not such loud warning as this one. Right, that is a purely in kernel interface visible only to people directly working on implementing SPI controller drivers that isn't especially open to misuse and therefore both less serious and more likely to be noticed. > I guess the time spent discussing this could have been better spent > implementing that solution instead. > All we need is a volunteer to get that implemented. Yes. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Mon, Apr 27, 2015 at 11:16:01AM +0100, Mark Brown wrote: > On Sun, Apr 26, 2015 at 02:51:13PM +0200, Maxime Ripard wrote: > > On Sun, Apr 26, 2015 at 02:38:18PM +0200, Michal Suchanek wrote: > > > > >> I don't know if it's been suggested before, certainly nobody did the > > > >> work to make it happen. I don't think I have a massive objection in > > > >> principal. > > > Actually, I did it a year ago, and it looked at the time that it > > wasn't what should be done either. > > > https://lkml.org/lkml/2014/4/28/612 > > lkml.org is being terrible as usual so I can't see half the thread (or > at least got fed up trying to get it to load) A part of it is also here: http://lkml.iu.edu/hypermail/linux/kernel/1405.0/00484.html > but I think the discussion there petered out more than anything > else. Maybe it did :) > Or was it the suggestion to make this something that the driver core > supported so that we didn't have to open code it for every bus? Probably. That's something I really haven't took the time to look at, and don't really plan on doing so. I guess a good way forward would be to revive this patch, and wait for that generic way to happen. What do you think of this? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
> On 27.04.2015, at 17:27, Mark Brown wrote:
>
>
> OK, so that is just a default overlay which is abusing the fact that we
> will bind to spidev without a DT compatible and when the binding is
> undocumented (which also applies to other devices and buses sadly).
>
> Unfortunately nobody ever mentioned this upstream and the feedback
> upstream that listing spidev in a DT is a bad idea has been ignored.
Maybe it should also have been documented as such in
Documentation/spi/spidev or in Documentation/devicetree/bindings/spi/
> The whole reason we're doing this in the first place is that we got sick
> of telling people that using spidev in DTs like this was a bad idea.
The only reference I found in my history of the spi-list is this email:
> On 08.10.2014, at 22:05, Mark Brown wrote:
>
> On Wed, Oct 08, 2014 at 02:27:08PM -0500, ttha...@opensource.altera.com wrote:
>
>> +spidev@0 {
>> +compatible = "spidev";
>> +reg = <0>; /* chip select */
>> +spi-max-frequency = <1>;
>> +};
>
> No, if you're putting spidev into the DT that's broken - describe the
> hardware, not the software you're using to control it.
And google found this patch from a little earlier:
http://comments.gmane.org/gmane.linux.ports.arm.kernel/231050
So finding this piece of information on the “use-policy” is quite hard
- google finds lots of links where it is described as working that way.
> It does sound like the people maintianing the u-boot fork for the Pi
> need to talk to both u-boot upstream (nothing here is specific to the
> Pi that I can see) and the kernel community a bit more. I'd be a bit
> worried that they may be relying on other things that just happen to
> work without being intentional (and are therefore more vulnerable to
> issues) and it's a bit depressing to see things like this stuck in a
> fork where only a limited community can make use of them.
Actually this functionality is not in u-boot, but in the firmware
boot-loader itself, which can load the kernel (and the devicetree)
without u-boot, but which can also load u-boot as an additional
intermediate boot-stage.
>> The only thing that could possibly be better would be that
>> the user would define the "real" name of the device in the
>> device tree and spidev would bind to it if there is no driver
>> available (but that would require this "fallback" binding by
>> spidev in case of no driver).
>
> Yes, that is exactly the solution I'd suggest - change the UI to provide
> a DT compatible to be used for the new device. That would also have the
> benefit of meaning that users who have connected some device that does
> have a driver that works with a simple binding wouldn't need to write an
> overlay which seems like it should be useful.
Well then why did you just make the system complain loudly and bringing
problems to people instead of solving it in a usable manner that does not
require people to maintain an out of tree patch to work around that warning?
We still have the one-line warning about using the depreciated
spi_master.transfer interface, but it is not such loud warning as this one.
I guess the time spent discussing this could have been better spent
implementing that solution instead.
All we need is a volunteer to get that implemented.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On 27 April 2015 at 17:13, Geert Uytterhoeven wrote: > On Mon, Apr 27, 2015 at 4:28 PM, Michal Suchanek wrote: >> When you have a serial port and just connect serial device to it with >> no special requirement you just specify the serial port in DT and talk >> to the device directly without any DT foo. >> >> When there is a BT module with reset lines and a kernel driver you >> write in DT that you have such and such BT module with such and such >> reset lines on the uart so the driver picks it up. >> >> Same for USB attached on-board WiFi - that some USB device needs >> special handling does not mean you have to specify your keyboard in DT >> to connect it to an USB port. >> >> What you are mandating here, basically, is equivalent of requiring a >> DT overlay to connect an USB keyboard or mouse because it is a device >> connected in hardware to the USB port and DT is supposed to describe >> the hardware. > > Unlike the spi bus, the USB bus is a discoverable bus. So you can probe > for connected devices. No need to put them in DT (but you can, if the > firmware does the probing and updates the DTB. E.g. Open Firmware did > that for PCI (which was not hot-pluggable)). > > Unlike the spi bus, you can (more or less) find out if a device is attached > to a uart, by listening to the bus, and waiting for a start bit. > > I do agree that it would be nice to put the other end of the uart link in DT, > as you can't always know what you're talking to. Is it a modem? Is it a > printer? Is it a BT module? Is it Super Grover? Is it Mega Mindy? And the point is that it can be any of those and you can swap them. So the DT cannot and will not describe the other end of the bus. There is some point where the static part of the hardware configuration ends and pluggable devices start and DT has to deal with that. Sticking your head into the sand and pretending there is no connector on the device will only give you a fork. When the DT is unusable for me and it is unusable for other people then either a change gets upstream which would be nice or it's bound to be floating around the net as a patchset which would be annoying but has happened in the past and will again. And we are not really discussing some fundamental change to the kernel that might have unexpected effects on unrelated subsystems. We are just having a bikeshedding debate if and how a SPI connector is represented in DT. Thanks Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Mon, Apr 27, 2015 at 04:14:31PM +0200, Martin Sperl wrote: > On 2015-04-27 13:25, Mark Brown wrote: > >I don't think you've fully considered your use case here. As I said in > >my reply to your earlier e-mail I think what you're looking for here is > >something like better UI around overlays. Registering a SPI bus without > >knowing what's connected to it doesn't allow generic maker style usage > >of the board, it's just as likely to hinder a user as help them. For > So you see that spi is disabled by default - the pins are > free to use for anything. > The firmware then integrates the overrrides into the device-tree > before loading the kernel. > So to enable spi in general you add the following to /boot/config.txt: > dtparam=spi=on > That gives you spi plus two "generic" spidev devices. OK, so that is just a default overlay which is abusing the fact that we will bind to spidev without a DT compatible and when the binding is undocumented (which also applies to other devices and buses sadly). Unfortunately nobody ever mentioned this upstream and the feedback upstream that listing spidev in a DT is a bad idea has been ignored. The whole reason we're doing this in the first place is that we got sick of telling people that using spidev in DTs like this was a bad idea. > If you want to include a mcp2515 you add also the following: > dtoverlay=mcp2515-can0-overlay > and that loads also the overlay for the mcp2515 can module. And this is just a user specified overlay which is completely fine already. > So coming from this perspective I believe that there is some > concern in the raspberry pi community, because the description > they provide is now specific to the HW and their intent and so > the loud "croaking" of spidev will irritate people even when > they have done everything the best they can. It does sound like the people maintianing the u-boot fork for the Pi need to talk to both u-boot upstream (nothing here is specific to the Pi that I can see) and the kernel community a bit more. I'd be a bit worried that they may be relying on other things that just happen to work without being intentional (and are therefore more vulnerable to issues) and it's a bit depressing to see things like this stuck in a fork where only a limited community can make use of them. > The only thing that could possibly be better would be that > the user would define the "real" name of the device in the > device tree and spidev would bind to it if there is no driver > available (but that would require this "fallback" binding by > spidev in case of no driver). Yes, that is exactly the solution I'd suggest - change the UI to provide a DT compatible to be used for the new device. That would also have the benefit of meaning that users who have connected some device that does have a driver that works with a simple binding wouldn't need to write an overlay which seems like it should be useful. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Mon, Apr 27, 2015 at 4:28 PM, Michal Suchanek wrote:
> When you have a serial port and just connect serial device to it with
> no special requirement you just specify the serial port in DT and talk
> to the device directly without any DT foo.
>
> When there is a BT module with reset lines and a kernel driver you
> write in DT that you have such and such BT module with such and such
> reset lines on the uart so the driver picks it up.
>
> Same for USB attached on-board WiFi - that some USB device needs
> special handling does not mean you have to specify your keyboard in DT
> to connect it to an USB port.
>
> What you are mandating here, basically, is equivalent of requiring a
> DT overlay to connect an USB keyboard or mouse because it is a device
> connected in hardware to the USB port and DT is supposed to describe
> the hardware.
Unlike the spi bus, the USB bus is a discoverable bus. So you can probe
for connected devices. No need to put them in DT (but you can, if the
firmware does the probing and updates the DTB. E.g. Open Firmware did
that for PCI (which was not hot-pluggable)).
Unlike the spi bus, you can (more or less) find out if a device is attached
to a uart, by listening to the bus, and waiting for a start bit.
I do agree that it would be nice to put the other end of the uart link in DT,
as you can't always know what you're talking to. Is it a modem? Is it a
printer? Is it a BT module? Is it Super Grover? Is it Mega Mindy?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On 27 April 2015 at 12:10, Mark Brown wrote: > On Sun, Apr 26, 2015 at 04:40:50PM +0200, Hans de Goede wrote: > >> Hi, > > Please always provide context in your replies so people know what you're > talking about. > >> I've a feeling everyone in this thread is ignoring the >> raspberry pi use-case. Where the board is specifically >> designed for educational purposes and used with lots of >> peripherals which are usually programmed from userspace >> using e.g. python bindings for i2c-dev or spidev, for >> such a setup we really want spidev to be loaded on the >> spibus by default and we really do not have a proper >> compatible for a child device. > > No, that's a different problem - the context you describe just happens > to be your use case but it's in no way universal, there are plenty of > expansion boards out there that have devices that use real drivers > connected to them normally (and some of those could even be used in the > educational contexts you describe). I think the underlying need here is > either for a better way of registering things or better tooling around > device tree overlays to address the usability issues. No. When you have a serial port and just connect serial device to it with no special requirement you just specify the serial port in DT and talk to the device directly without any DT foo. When there is a BT module with reset lines and a kernel driver you write in DT that you have such and such BT module with such and such reset lines on the uart so the driver picks it up. Same for USB attached on-board WiFi - that some USB device needs special handling does not mean you have to specify your keyboard in DT to connect it to an USB port. What you are mandating here, basically, is equivalent of requiring a DT overlay to connect an USB keyboard or mouse because it is a device connected in hardware to the USB port and DT is supposed to describe the hardware. Thanks Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On 2015-04-27 13:25, Mark Brown wrote:
On Mon, Apr 27, 2015 at 12:04:12PM +0200, Hans de Goede wrote:
Have you seen my mail about the raspberry pi use-case? Using dt-overlays
simply is not an acceptable answer there. There are legitimate use-cases
for a "generic spi bus" concept with the bus only being accessible via
spidev.
Blocking this use-case because you do not believe it is a valid use-case
is not going to help, this will just lead to the custom distros these
boards are shipping doing some ugly hack, which is not what we want
IMHO.
I don't think you've fully considered your use case here. As I said in
my reply to your earlier e-mail I think what you're looking for here is
something like better UI around overlays. Registering a SPI bus without
knowing what's connected to it doesn't allow generic maker style usage
of the board, it's just as likely to hinder a user as help them. For
example, if someone wants to use the SPI pins for another function such
as GPIO they'll have to handle that (and may have problems with pin
conflicts causing electrical issues if they do load up the DT with
spidev in it). If someone has a SPI device they want to bind an in
kernel driver to they'll have to handle that, if they want to use a GPIO
to provide an additional chip select they'll have to handle that too.
Note that the discussion here isn't about userspace drivers, it's about
how the hardware is described.
Mark, maybe you are missing something of how this can get done on the
raspberry pi with devicetree (and overlays).
So here how the raspberry-foundation describes the devices in their
device-tree for spi:
dtsi:
spi0: spi@7e204000 {
compatible = "brcm,bcm2708-spi";
reg = <0x7e204000 0x1000>;
interrupts = <2 22>;
clocks = <&clk_spi>;
#address-cells = <1>;
#size-cells = <0>;
status = "disabled";
};
dts:
&spi0 {
pinctrl-names = "default";
pinctrl-0 = <&spi0_pins>;
spidev@0{
compatible = "spidev";
reg = <0>; /* CE0 */
#address-cells = <1>;
#size-cells = <0>;
spi-max-frequency = <50>;
};
spidev@1{
compatible = "spidev";
reg = <1>; /* CE1 */
#address-cells = <1>;
#size-cells = <0>;
spi-max-frequency = <50>;
};
};
/ {
__overrides__ {
spi = <&spi0>,"status";
};
}
So you see that spi is disabled by default - the pins are
free to use for anything.
The firmware then integrates the overrrides into the device-tree
before loading the kernel.
So to enable spi in general you add the following to /boot/config.txt:
dtparam=spi=on
That gives you spi plus two "generic" spidev devices.
If you want to include a mcp2515 you add also the following:
dtoverlay=mcp2515-can0-overlay
and that loads also the overlay for the mcp2515 can module.
The corresponding mcp2515 overlay looks like this:
/ {
/* the spi config of the can-controller itself */
fragment@1 {
target = <&spi0>;
__overlay__ {
/* needed to avoid dtc warning */
#address-cells = <1>;
#size-cells = <0>;
can0: mcp2515@0 {
reg = <0>;
compatible = "microchip,mcp2515";
pinctrl-names = "default";
pinctrl-0 = <&can0_pins>;
spi-max-frequency = <1000>;
interrupt-parent = <&gpio>;
interrupts = <25 0x2>;
clocks = <&can0_osc>;
};
};
};
};
(left out the unimportant stuff like clocks,
interrupt GPIOs,...)
All this implements:
* easy means to enable spi if requested by user
* by default includes spidev as the default device
* but this can get just as easily get overridden by another
devicetree to get specific devices onboarded using the
in kernel drivers - there are now something like 25+
overlays provided by the foundation that follow this
pattern...
This is really about describing the hardware in the best possible
ways and keeping the interface with the users simple by having
him only to edit /boot/config.txt.
Adding your own overlays is just as simple and also quite well
defined.
So coming from this perspective I believe that there is some
concern in the raspberry pi community, because the description
they provide is now specific to the HW and their intent and so
the loud "croaking" of spidev will irritate people even when
they have done everything the best they can.
OK, I admit, the spi-devices could be separate overlays if
one really wants to have them, but they can get disabled just
as easily (by a specific overlay) if only a single device is
needed.
The only thing that could p
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Mon, Apr 27, 2015 at 12:04:12PM +0200, Hans de Goede wrote: > Have you seen my mail about the raspberry pi use-case? Using dt-overlays > simply is not an acceptable answer there. There are legitimate use-cases > for a "generic spi bus" concept with the bus only being accessible via > spidev. > Blocking this use-case because you do not believe it is a valid use-case > is not going to help, this will just lead to the custom distros these > boards are shipping doing some ugly hack, which is not what we want > IMHO. I don't think you've fully considered your use case here. As I said in my reply to your earlier e-mail I think what you're looking for here is something like better UI around overlays. Registering a SPI bus without knowing what's connected to it doesn't allow generic maker style usage of the board, it's just as likely to hinder a user as help them. For example, if someone wants to use the SPI pins for another function such as GPIO they'll have to handle that (and may have problems with pin conflicts causing electrical issues if they do load up the DT with spidev in it). If someone has a SPI device they want to bind an in kernel driver to they'll have to handle that, if they want to use a GPIO to provide an additional chip select they'll have to handle that too. Note that the discussion here isn't about userspace drivers, it's about how the hardware is described. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On 27 April 2015 at 12:04, Maxime Ripard wrote: > On Sun, Apr 26, 2015 at 08:53:16PM +0200, Michal Suchanek wrote: >> >> Also for driver prototyping you need a compatible which makes the >> >> device accessible. >> >> >> >> If no spidev general compatible is available people will just use >> >> compatible for some random device which happens to bind to spidev and >> >> will send many letters of thanks to the DT maintainers when the device >> >> used for this purpose suddenly grows a Linux driver. >> > >> > If people do dumb things, they should expect it to backfire. >> >> Yes, dumb things like not allowing people to say in the DT that the >> board actually has pins on it connected to a SPI bus. Which is the >> actual hardware which should be described in the DT. > > It's not connected to an SPI bus. It's connected to a device using an > SPI bus. If you just had floating SPI lines, I'm pretty sure you > wouldn't care about spidev at all. > >> Do you have to describe a modem or terminal emulator in DT to connect >> it to your serial port? You just describe the port. So here you have a >> SPI port and it should be described in the DT as faithfully as the >> serial port. > > Except that in the serial port, you have a representation of a bus, > while spidev represents a *device* connected on an SPI bus. So these > are two different things, really. No it's the same thing, really. With serial you just have serial lines which you expose on a connector. With SPI you have CS so you can technically have several connectors for the same SPI bus selected by different CS. So yes, making a spidev entry for the connector under SPI bus is the equivalent of making an UART entry to specify that there is a connector. Thanks Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Mon, Apr 27, 2015 at 11:39:50AM +0200, Michal Suchanek wrote: > On 27 April 2015 at 11:36, Mark Brown wrote: > > On Sun, Apr 26, 2015 at 04:14:33PM +0200, Michal Suchanek wrote: > >> There is no device connected in the slot by design. The slot is there > >> for connecting random stuff you find in your mailbox or other drawers > >> and boxes. > > You should be using device tree overlays to describe what actually ended > > up getting connected there. > NO Please try to discuss things in a more appropriate fashion, responses like the above are not constructive. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Sun, Apr 26, 2015 at 08:53:16PM +0200, Michal Suchanek wrote: > Do you have to describe a modem or terminal emulator in DT to connect > it to your serial port? You just describe the port. So here you have a > SPI port and it should be described in the DT as faithfully as the > serial port. Serial ports have runtime mechanisms defined for connecting devices to them (opening the device or attaching a line discipline). > Or do you suggest that I patch the compatible into spidev, write a > driver for it, and then back out the compatible from spidev and check > in the compatible again with the driver? Until someone provides a way of binding spidev to otherwise unbound devices that's exactly what is being suggested; if your main purpose in this is to write a kernel driver for the device then that would be a local modification to add the compatible (or you could just ignore the warning) until you get something in kernel space, no need to upstream. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Sun, Apr 26, 2015 at 02:51:13PM +0200, Maxime Ripard wrote: > On Sun, Apr 26, 2015 at 02:38:18PM +0200, Michal Suchanek wrote: > > >> I don't know if it's been suggested before, certainly nobody did the > > >> work to make it happen. I don't think I have a massive objection in > > >> principal. > Actually, I did it a year ago, and it looked at the time that it > wasn't what should be done either. > https://lkml.org/lkml/2014/4/28/612 lkml.org is being terrible as usual so I can't see half the thread (or at least got fed up trying to get it to load) but I think the discussion there petered out more than anything else. Or was it the suggestion to make this something that the driver core supported so that we didn't have to open code it for every bus? -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Sun, Apr 26, 2015 at 04:40:50PM +0200, Hans de Goede wrote: > Hi, Please always provide context in your replies so people know what you're talking about. > I've a feeling everyone in this thread is ignoring the > raspberry pi use-case. Where the board is specifically > designed for educational purposes and used with lots of > peripherals which are usually programmed from userspace > using e.g. python bindings for i2c-dev or spidev, for > such a setup we really want spidev to be loaded on the > spibus by default and we really do not have a proper > compatible for a child device. No, that's a different problem - the context you describe just happens to be your use case but it's in no way universal, there are plenty of expansion boards out there that have devices that use real drivers connected to them normally (and some of those could even be used in the educational contexts you describe). I think the underlying need here is either for a better way of registering things or better tooling around device tree overlays to address the usability issues. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Mon, Apr 27, 2015 at 08:51:12AM +0200, Michal Suchanek wrote: > On 26 April 2015 at 17:47, Maxime Ripard > wrote: > > On Sun, Apr 26, 2015 at 04:40:50PM +0200, Hans de Goede wrote: > >> Hi, > >> > >> I've a feeling everyone in this thread is ignoring the > >> raspberry pi use-case. Where the board is specifically > >> designed for educational purposes and used with lots of > >> peripherals which are usually programmed from userspace > >> using e.g. python bindings for i2c-dev or spidev, for > >> such a setup we really want spidev to be loaded on the > >> spibus by default and we really do not have a proper > >> compatible for a child device. > > > > I'm not sure we're ignoring it, it just is the exact same use case > > than the whole spidev use case: people want to write SPI userspace > > drivers, the rpi really is not special here, except maybe for its user > > space code base, but it really boils down to the same issue. > > > >> And no having to use per device devicetree overlays > >> for this is not the answer, this needs to be really > >> really easy. With pre device-tree kernels this just > >> works, we should be able to match that ease of use > >> with devicetree. > > > > We do agree on that. We repeatedly told that the DT was not a good > > solution, overlays or not, and this is exactly one of the reasons. > > > > Ok, so how about skipping the bindings altogether. > > Just instantiate a spidev for each SPI bus and each CS the SPI core > knows of once spidev is loaded. Which is exactly what my patch did but didn't seem like good enough for you at the time... Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
Hi, On 27-04-15 12:04, Hans de Goede wrote: Hi Mark, On 27-04-15 11:36, Mark Brown wrote: On Sun, Apr 26, 2015 at 04:14:33PM +0200, Michal Suchanek wrote: On 26 April 2015 at 14:51, Maxime Ripard No, you add a compatible for the device that is connected to the bus through that slot. There is no device connected in the slot by design. The slot is there for connecting random stuff you find in your mailbox or other drawers and boxes. You should be using device tree overlays to describe what actually ended up getting connected there. Have you seen my mail about the raspberry pi use-case? Using dt-overlays simply is not an acceptable answer there. There are legitimate use-cases for a "generic spi bus" concept with the bus only being accessible via spidev. Blocking this use-case because you do not believe it is a valid use-case is not going to help, this will just lead to the custom distros these boards are shipping doing some ugly hack, which is not what we want IMHO. I hope that with the raspberry pi 2 the raspberry pi-s will eventually go fully devicetree / multi-platform kernel so that they can be supported ootb by distros which only want to ship a single multi-platform kernel like Debian, but that does require us to solve problems like this one. To expand a bit on this, as you know there is this whole maker movement thing going on, these are people using arduinos and raspberry pi-s and they expect things to be easy and just work. This is also a huge pool of potential new FOSS / Linux contributors. I believe that it is important that we cater to these people. One day one of them may have a kernel related itch and decide to scratch it, do we work that person to then work on some weird (and often ugly) fork of the kernel, or do we want such boards to be running a pristine upstream kernel and have potential new contributors work on the upstream kernel and hopefully also engage with the upstream kernel community, where we can teach them our best practices which are often lacking in the various "fork" communities ? Regards, Hans -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Sun, Apr 26, 2015 at 08:53:16PM +0200, Michal Suchanek wrote: > >> Also for driver prototyping you need a compatible which makes the > >> device accessible. > >> > >> If no spidev general compatible is available people will just use > >> compatible for some random device which happens to bind to spidev and > >> will send many letters of thanks to the DT maintainers when the device > >> used for this purpose suddenly grows a Linux driver. > > > > If people do dumb things, they should expect it to backfire. > > Yes, dumb things like not allowing people to say in the DT that the > board actually has pins on it connected to a SPI bus. Which is the > actual hardware which should be described in the DT. It's not connected to an SPI bus. It's connected to a device using an SPI bus. If you just had floating SPI lines, I'm pretty sure you wouldn't care about spidev at all. > Do you have to describe a modem or terminal emulator in DT to connect > it to your serial port? You just describe the port. So here you have a > SPI port and it should be described in the DT as faithfully as the > serial port. Except that in the serial port, you have a representation of a bus, while spidev represents a *device* connected on an SPI bus. So these are two different things, really. > >> >> > https://lkml.org/lkml/2014/4/28/612 > >> >> > > >> >> >> But how do you know there is a device? > >> >> >> > >> >> >> Devices on i2c can be probed. On spi you just transfer random data > >> >> >> and > >> >> >> hope it does something useful. Some devices have readable registers > >> >> >> and can be probed in a device-specific way but others are write-only. > >> >> > > >> >> > Well, what's the point of communicating with a non-existent device in > >> >> > the first place? > >> >> > >> >> I have multitude of SPI devices which are not part of the board and > >> >> hence its DT and can be connected to the board with jumper wires. > >> >> > >> >> Most of them don't have a linux driver or compatible to bind with. > >> > > >> > Then create such a compatible... > >> > >> I will if and when the device is usable. > > > > That's backward. The fact that your "driver" works really doesn't > > depend on what the device actually is. > > Indeed. > > However, for the device to have a compatible the compatible must be > specified in a driver and then I need a driver for the device to > record the compatible in. > > Or do you suggest that I patch the compatible into spidev, write a > driver for it, and then back out the compatible from spidev and check > in the compatible again with the driver? > > Now that is backwards. What Mark was suggesting was that you add a compatible to the spidev driver, and then you have access to spidev from userspace, period. If later on, you introduce a real driver for that, then yes, you would have to remove the compatible from spidev, and have that matching compatible in that new driver. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
Hi Mark, On 27-04-15 11:36, Mark Brown wrote: On Sun, Apr 26, 2015 at 04:14:33PM +0200, Michal Suchanek wrote: On 26 April 2015 at 14:51, Maxime Ripard No, you add a compatible for the device that is connected to the bus through that slot. There is no device connected in the slot by design. The slot is there for connecting random stuff you find in your mailbox or other drawers and boxes. You should be using device tree overlays to describe what actually ended up getting connected there. Have you seen my mail about the raspberry pi use-case? Using dt-overlays simply is not an acceptable answer there. There are legitimate use-cases for a "generic spi bus" concept with the bus only being accessible via spidev. Blocking this use-case because you do not believe it is a valid use-case is not going to help, this will just lead to the custom distros these boards are shipping doing some ugly hack, which is not what we want IMHO. I hope that with the raspberry pi 2 the raspberry pi-s will eventually go fully devicetree / multi-platform kernel so that they can be supported ootb by distros which only want to ship a single multi-platform kernel like Debian, but that does require us to solve problems like this one. Regards, Hans -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On 27 April 2015 at 11:36, Mark Brown wrote: > On Sun, Apr 26, 2015 at 04:14:33PM +0200, Michal Suchanek wrote: >> On 26 April 2015 at 14:51, Maxime Ripard > >> > No, you add a compatible for the device that is connected to the bus >> > through that slot. > >> There is no device connected in the slot by design. The slot is there >> for connecting random stuff you find in your mailbox or other drawers >> and boxes. > > You should be using device tree overlays to describe what actually ended > up getting connected there. NO -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Sun, Apr 26, 2015 at 04:14:33PM +0200, Michal Suchanek wrote: > On 26 April 2015 at 14:51, Maxime Ripard > > No, you add a compatible for the device that is connected to the bus > > through that slot. > There is no device connected in the slot by design. The slot is there > for connecting random stuff you find in your mailbox or other drawers > and boxes. You should be using device tree overlays to describe what actually ended up getting connected there. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On 26 April 2015 at 17:47, Maxime Ripard wrote: > On Sun, Apr 26, 2015 at 04:40:50PM +0200, Hans de Goede wrote: >> Hi, >> >> I've a feeling everyone in this thread is ignoring the >> raspberry pi use-case. Where the board is specifically >> designed for educational purposes and used with lots of >> peripherals which are usually programmed from userspace >> using e.g. python bindings for i2c-dev or spidev, for >> such a setup we really want spidev to be loaded on the >> spibus by default and we really do not have a proper >> compatible for a child device. > > I'm not sure we're ignoring it, it just is the exact same use case > than the whole spidev use case: people want to write SPI userspace > drivers, the rpi really is not special here, except maybe for its user > space code base, but it really boils down to the same issue. > >> And no having to use per device devicetree overlays >> for this is not the answer, this needs to be really >> really easy. With pre device-tree kernels this just >> works, we should be able to match that ease of use >> with devicetree. > > We do agree on that. We repeatedly told that the DT was not a good > solution, overlays or not, and this is exactly one of the reasons. > Ok, so how about skipping the bindings altogether. Just instantiate a spidev for each SPI bus and each CS the SPI core knows of once spidev is loaded. Thanks Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On 26 April 2015 at 17:54, Maxime Ripard wrote: > On Sun, Apr 26, 2015 at 05:33:36PM +0200, Michal Suchanek wrote: >> On 26 April 2015 at 16:33, Maxime Ripard >> wrote: >> > On Sun, Apr 26, 2015 at 04:14:33PM +0200, Michal Suchanek wrote: >> >> On 26 April 2015 at 14:51, Maxime Ripard >> >> wrote: >> >> > On Sun, Apr 26, 2015 at 02:38:18PM +0200, Michal Suchanek wrote: >> >> >> On 26 April 2015 at 13:56, Martin Sperl >> >> >> wrote: >> >> >> > >> >> >> >> On 26.04.2015, at 13:23, Hans de Goede wrote: >> >> >> >> I think there is actual a use for just binding spidev as spidev, >> >> >> >> think e.g. the spi pins on the raspberry pi. >> >> >> >> >> >> >> >> How do you deal we suggest with such a situation ? >> >> >> > >> >> >> > I actually asked the same question a few days ago on the spi list >> >> >> > (in thread: "spi: spidev: Warn loudly if instantiated from DT as >> >> >> > “spidev”) >> >> >> > and the summary was: >> >> >> > >> >> >> > You can still do as before, but you have to accept that long >> >> >> > irritating warning. >> >> >> > >> >> >> > Or you patch spidev.c to include your pattern of choice for >> >> >> > compatiblity >> >> >> >> >> >> So the suggestion is to add a compatible string like olimex,uext-slot >> >> >> to spidev and use that compatible in the DT? >> >> > >> >> > No, you add a compatible for the device that is connected to the bus >> >> > through that slot. >> >> >> >> There is no device connected in the slot by design. The slot is there >> >> for connecting random stuff you find in your mailbox or other drawers >> >> and boxes. >> > >> > I know. Our point is add a compatible for that random device you find >> > in your mailbox. >> >> That would be mailbox,device-tbd I suppose? > > If you can find a programming model and a matching datasheet for that > device, I suppose, yes. > >> >> >> That can certainly be done but adding a new compatible for every board >> >> >> that has some random pins looks like a needless nuisance to me. >> >> >> Especially compared to i2c where you can just open the bus so long as >> >> >> ti is enabled. >> >> >> >> >> >> > >> >> >> > Or you implement the following proposal (which needs a volunteer): >> >> >> >> On 23.04.2015, at 09:42, Geert Uytterhoeven >> >> >> >> wrote: >> >> >> >> >> >> >> >> So what you need is a way to handover from generic spidev to a >> >> >> >> device-specific >> >> >> >> driver, cfr. what graphics drivers do when the device has been >> >> >> >> bound to by >> >> >> >> vesafb or simplefb. >> >> >> >> >> >> >> >> Could this be implemented in a generic way in the spi or DT code? >> >> >> > >> >> >> > ... >> >> >> >> On 23.04.2015, at 12:36, Mark Brown wrote: >> >> >> >> On Thu, Apr 23, 2015 at 09:45:16AM +0200, Geert Uytterhoeven wrote: >> >> >> >> >> >> >> >>> I guess this has been suggested before: the spi core could provide >> >> >> >>> spidev >> >> >> >>> access to all spi client devices which are not bound by a driver? >> >> >> >> >> >> >> >> I don't know if it's been suggested before, certainly nobody did the >> >> >> >> work to make it happen. I don't think I have a massive objection in >> >> >> >> principal. >> >> > >> >> > Actually, I did it a year ago, and it looked at the time that it >> >> > wasn't what should be done either. >> >> >> >> There is nothing like unclaimed device. Either there is a device and >> >> driver for it may in principle be loaded later as a module or the chip >> >> select is reserved for use from userspace. >> > >> > I never said it was perfect. >> > >> >> Userspace driver is valid option and should have the ability to have >> >> the chip select reserved. >> > >> > Whether an userspace driver is a valid option can spawn a whole debate >> > by its own, but it's true that we should be able to have it exported >> > to the userspace. >> > >> > However, having a spidev compatible is not the solution to that >> > problem. >> >> Having to patch the kernel to use an unknown device with userspace >> driver is not the answer either. >> >> Devices which are not performance critical and don't use existing >> kernel frameworks don't have any use for kernel driver. >> >> In fact, writing a kernel driver for them is counter-productive >> because you will have to write from scratch when you connect the >> device to a box running another OS due to interface *and* license >> difference. > > And here is the debate... > >> Also for driver prototyping you need a compatible which makes the >> device accessible. >> >> If no spidev general compatible is available people will just use >> compatible for some random device which happens to bind to spidev and >> will send many letters of thanks to the DT maintainers when the device >> used for this purpose suddenly grows a Linux driver. > > If people do dumb things, they should expect it to backfire. Yes, dumb things like not allowing people to say in the DT that the board actually has pins on it connected to a SPI bus. Which is the actual hardware which shoul
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Sun, Apr 26, 2015 at 05:33:36PM +0200, Michal Suchanek wrote: > On 26 April 2015 at 16:33, Maxime Ripard > wrote: > > On Sun, Apr 26, 2015 at 04:14:33PM +0200, Michal Suchanek wrote: > >> On 26 April 2015 at 14:51, Maxime Ripard > >> wrote: > >> > On Sun, Apr 26, 2015 at 02:38:18PM +0200, Michal Suchanek wrote: > >> >> On 26 April 2015 at 13:56, Martin Sperl wrote: > >> >> > > >> >> >> On 26.04.2015, at 13:23, Hans de Goede wrote: > >> >> >> I think there is actual a use for just binding spidev as spidev, > >> >> >> think e.g. the spi pins on the raspberry pi. > >> >> >> > >> >> >> How do you deal we suggest with such a situation ? > >> >> > > >> >> > I actually asked the same question a few days ago on the spi list > >> >> > (in thread: "spi: spidev: Warn loudly if instantiated from DT as > >> >> > “spidev”) > >> >> > and the summary was: > >> >> > > >> >> > You can still do as before, but you have to accept that long > >> >> > irritating warning. > >> >> > > >> >> > Or you patch spidev.c to include your pattern of choice for > >> >> > compatiblity > >> >> > >> >> So the suggestion is to add a compatible string like olimex,uext-slot > >> >> to spidev and use that compatible in the DT? > >> > > >> > No, you add a compatible for the device that is connected to the bus > >> > through that slot. > >> > >> There is no device connected in the slot by design. The slot is there > >> for connecting random stuff you find in your mailbox or other drawers > >> and boxes. > > > > I know. Our point is add a compatible for that random device you find > > in your mailbox. > > That would be mailbox,device-tbd I suppose? If you can find a programming model and a matching datasheet for that device, I suppose, yes. > >> >> That can certainly be done but adding a new compatible for every board > >> >> that has some random pins looks like a needless nuisance to me. > >> >> Especially compared to i2c where you can just open the bus so long as > >> >> ti is enabled. > >> >> > >> >> > > >> >> > Or you implement the following proposal (which needs a volunteer): > >> >> >> On 23.04.2015, at 09:42, Geert Uytterhoeven > >> >> >> wrote: > >> >> >> > >> >> >> So what you need is a way to handover from generic spidev to a > >> >> >> device-specific > >> >> >> driver, cfr. what graphics drivers do when the device has been bound > >> >> >> to by > >> >> >> vesafb or simplefb. > >> >> >> > >> >> >> Could this be implemented in a generic way in the spi or DT code? > >> >> > > >> >> > ... > >> >> >> On 23.04.2015, at 12:36, Mark Brown wrote: > >> >> >> On Thu, Apr 23, 2015 at 09:45:16AM +0200, Geert Uytterhoeven wrote: > >> >> >> > >> >> >>> I guess this has been suggested before: the spi core could provide > >> >> >>> spidev > >> >> >>> access to all spi client devices which are not bound by a driver? > >> >> >> > >> >> >> I don't know if it's been suggested before, certainly nobody did the > >> >> >> work to make it happen. I don't think I have a massive objection in > >> >> >> principal. > >> > > >> > Actually, I did it a year ago, and it looked at the time that it > >> > wasn't what should be done either. > >> > >> There is nothing like unclaimed device. Either there is a device and > >> driver for it may in principle be loaded later as a module or the chip > >> select is reserved for use from userspace. > > > > I never said it was perfect. > > > >> Userspace driver is valid option and should have the ability to have > >> the chip select reserved. > > > > Whether an userspace driver is a valid option can spawn a whole debate > > by its own, but it's true that we should be able to have it exported > > to the userspace. > > > > However, having a spidev compatible is not the solution to that > > problem. > > Having to patch the kernel to use an unknown device with userspace > driver is not the answer either. > > Devices which are not performance critical and don't use existing > kernel frameworks don't have any use for kernel driver. > > In fact, writing a kernel driver for them is counter-productive > because you will have to write from scratch when you connect the > device to a box running another OS due to interface *and* license > difference. And here is the debate... > Also for driver prototyping you need a compatible which makes the > device accessible. > > If no spidev general compatible is available people will just use > comaptible for some random device which happens to bind to spidev and > will send many letters of thanks to the DT maintainers when the device > used for this purpose suddenly grows a Linux driver. If people do dumb things, they should expect it to backfire. > >> > https://lkml.org/lkml/2014/4/28/612 > >> > > >> >> But how do you know there is a device? > >> >> > >> >> Devices on i2c can be probed. On spi you just transfer random data and > >> >> hope it does something useful. Some devices have readable registers > >> >> and can be probed in a device-specific way but others are write-only
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Sun, Apr 26, 2015 at 04:40:50PM +0200, Hans de Goede wrote: > Hi, > > I've a feeling everyone in this thread is ignoring the > raspberry pi use-case. Where the board is specifically > designed for educational purposes and used with lots of > peripherals which are usually programmed from userspace > using e.g. python bindings for i2c-dev or spidev, for > such a setup we really want spidev to be loaded on the > spibus by default and we really do not have a proper > compatible for a child device. I'm not sure we're ignoring it, it just is the exact same use case than the whole spidev use case: people want to write SPI userspace drivers, the rpi really is not special here, except maybe for its user space code base, but it really boils down to the same issue. > And no having to use per device devicetree overlays > for this is not the answer, this needs to be really > really easy. With pre device-tree kernels this just > works, we should be able to match that ease of use > with devicetree. We do agree on that. We repeatedly told that the DT was not a good solution, overlays or not, and this is exactly one of the reasons. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On 26 April 2015 at 16:33, Maxime Ripard wrote: > On Sun, Apr 26, 2015 at 04:14:33PM +0200, Michal Suchanek wrote: >> On 26 April 2015 at 14:51, Maxime Ripard >> wrote: >> > On Sun, Apr 26, 2015 at 02:38:18PM +0200, Michal Suchanek wrote: >> >> On 26 April 2015 at 13:56, Martin Sperl wrote: >> >> > >> >> >> On 26.04.2015, at 13:23, Hans de Goede wrote: >> >> >> I think there is actual a use for just binding spidev as spidev, >> >> >> think e.g. the spi pins on the raspberry pi. >> >> >> >> >> >> How do you deal we suggest with such a situation ? >> >> > >> >> > I actually asked the same question a few days ago on the spi list >> >> > (in thread: "spi: spidev: Warn loudly if instantiated from DT as >> >> > “spidev”) >> >> > and the summary was: >> >> > >> >> > You can still do as before, but you have to accept that long >> >> > irritating warning. >> >> > >> >> > Or you patch spidev.c to include your pattern of choice for compatiblity >> >> >> >> So the suggestion is to add a compatible string like olimex,uext-slot >> >> to spidev and use that compatible in the DT? >> > >> > No, you add a compatible for the device that is connected to the bus >> > through that slot. >> >> There is no device connected in the slot by design. The slot is there >> for connecting random stuff you find in your mailbox or other drawers >> and boxes. > > I know. Our point is add a compatible for that random device you find > in your mailbox. That would be mailbox,device-tbd I suppose? > >> >> That can certainly be done but adding a new compatible for every board >> >> that has some random pins looks like a needless nuisance to me. >> >> Especially compared to i2c where you can just open the bus so long as >> >> ti is enabled. >> >> >> >> > >> >> > Or you implement the following proposal (which needs a volunteer): >> >> >> On 23.04.2015, at 09:42, Geert Uytterhoeven >> >> >> wrote: >> >> >> >> >> >> So what you need is a way to handover from generic spidev to a >> >> >> device-specific >> >> >> driver, cfr. what graphics drivers do when the device has been bound >> >> >> to by >> >> >> vesafb or simplefb. >> >> >> >> >> >> Could this be implemented in a generic way in the spi or DT code? >> >> > >> >> > ... >> >> >> On 23.04.2015, at 12:36, Mark Brown wrote: >> >> >> On Thu, Apr 23, 2015 at 09:45:16AM +0200, Geert Uytterhoeven wrote: >> >> >> >> >> >>> I guess this has been suggested before: the spi core could provide >> >> >>> spidev >> >> >>> access to all spi client devices which are not bound by a driver? >> >> >> >> >> >> I don't know if it's been suggested before, certainly nobody did the >> >> >> work to make it happen. I don't think I have a massive objection in >> >> >> principal. >> > >> > Actually, I did it a year ago, and it looked at the time that it >> > wasn't what should be done either. >> >> There is nothing like unclaimed device. Either there is a device and >> driver for it may in principle be loaded later as a module or the chip >> select is reserved for use from userspace. > > I never said it was perfect. > >> Userspace driver is valid option and should have the ability to have >> the chip select reserved. > > Whether an userspace driver is a valid option can spawn a whole debate > by its own, but it's true that we should be able to have it exported > to the userspace. > > However, having a spidev compatible is not the solution to that > problem. Having to patch the kernel to use an unknown device with userspace driver is not the answer either. Devices which are not performance critical and don't use existing kernel frameworks don't have any use for kernel driver. In fact, writing a kernel driver for them is counter-productive because you will have to write from scratch when you connect the device to a box running another OS due to interface *and* license difference. Also for driver prototyping you need a compatible which makes the device accessible. If no spidev general compatible is available people will just use comaptible for some random device which happens to bind to spidev and will send many letters of thanks to the DT maintainers when the device used for this purpose suddenly grows a Linux driver. > >> > https://lkml.org/lkml/2014/4/28/612 >> > >> >> But how do you know there is a device? >> >> >> >> Devices on i2c can be probed. On spi you just transfer random data and >> >> hope it does something useful. Some devices have readable registers >> >> and can be probed in a device-specific way but others are write-only. >> > >> > Well, what's the point of communicating with a non-existent device in >> > the first place? >> >> I have multitude of SPI devices which are not part of the board and >> hence its DT and can be connected to the board with jumper wires. >> >> Most of them don't have a linux driver or compatible to bind with. > > Then create such a compatible... I will if and when the device is usable. > >> >> So binding spidev is in my view just saying that you are going to >> >
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
Hi, I've a feeling everyone in this thread is ignoring the raspberry pi use-case. Where the board is specifically designed for educational purposes and used with lots of peripherals which are usually programmed from userspace using e.g. python bindings for i2c-dev or spidev, for such a setup we really want spidev to be loaded on the spibus by default and we really do not have a proper compatible for a child device. And no having to use per device devicetree overlays for this is not the answer, this needs to be really really easy. With pre device-tree kernels this just works, we should be able to match that ease of use with devicetree. Regards, Hans -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Sun, Apr 26, 2015 at 04:14:33PM +0200, Michal Suchanek wrote: > On 26 April 2015 at 14:51, Maxime Ripard > wrote: > > On Sun, Apr 26, 2015 at 02:38:18PM +0200, Michal Suchanek wrote: > >> On 26 April 2015 at 13:56, Martin Sperl wrote: > >> > > >> >> On 26.04.2015, at 13:23, Hans de Goede wrote: > >> >> I think there is actual a use for just binding spidev as spidev, > >> >> think e.g. the spi pins on the raspberry pi. > >> >> > >> >> How do you deal we suggest with such a situation ? > >> > > >> > I actually asked the same question a few days ago on the spi list > >> > (in thread: "spi: spidev: Warn loudly if instantiated from DT as > >> > “spidev”) > >> > and the summary was: > >> > > >> > You can still do as before, but you have to accept that long > >> > irritating warning. > >> > > >> > Or you patch spidev.c to include your pattern of choice for compatiblity > >> > >> So the suggestion is to add a compatible string like olimex,uext-slot > >> to spidev and use that compatible in the DT? > > > > No, you add a compatible for the device that is connected to the bus > > through that slot. > > There is no device connected in the slot by design. The slot is there > for connecting random stuff you find in your mailbox or other drawers > and boxes. I know. Our point is add a compatible for that random device you find in your mailbox. > >> That can certainly be done but adding a new compatible for every board > >> that has some random pins looks like a needless nuisance to me. > >> Especially compared to i2c where you can just open the bus so long as > >> ti is enabled. > >> > >> > > >> > Or you implement the following proposal (which needs a volunteer): > >> >> On 23.04.2015, at 09:42, Geert Uytterhoeven > >> >> wrote: > >> >> > >> >> So what you need is a way to handover from generic spidev to a > >> >> device-specific > >> >> driver, cfr. what graphics drivers do when the device has been bound to > >> >> by > >> >> vesafb or simplefb. > >> >> > >> >> Could this be implemented in a generic way in the spi or DT code? > >> > > >> > ... > >> >> On 23.04.2015, at 12:36, Mark Brown wrote: > >> >> On Thu, Apr 23, 2015 at 09:45:16AM +0200, Geert Uytterhoeven wrote: > >> >> > >> >>> I guess this has been suggested before: the spi core could provide > >> >>> spidev > >> >>> access to all spi client devices which are not bound by a driver? > >> >> > >> >> I don't know if it's been suggested before, certainly nobody did the > >> >> work to make it happen. I don't think I have a massive objection in > >> >> principal. > > > > Actually, I did it a year ago, and it looked at the time that it > > wasn't what should be done either. > > There is nothing like unclaimed device. Either there is a device and > driver for it may in principle be loaded later as a module or the chip > select is reserved for use from userspace. I never said it was perfect. > Userspace driver is valid option and should have the ability to have > the chip select reserved. Whether an userspace driver is a valid option can spawn a whole debate by its own, but it's true that we should be able to have it exported to the userspace. However, having a spidev compatible is not the solution to that problem. > > https://lkml.org/lkml/2014/4/28/612 > > > >> But how do you know there is a device? > >> > >> Devices on i2c can be probed. On spi you just transfer random data and > >> hope it does something useful. Some devices have readable registers > >> and can be probed in a device-specific way but others are write-only. > > > > Well, what's the point of communicating with a non-existent device in > > the first place? > > I have multitude of SPI devices which are not part of the board and > hence its DT and can be connected to the board with jumper wires. > > Most of them don't have a linux driver or compatible to bind with. Then create such a compatible... > >> So binding spidev is in my view just saying that you are going to > >> transfer random data from userspace on this bus. > > > > Yes, to a device connected on that bus. > > Yes, so I have this red rectangular PCB, blue PCB, and red square PCB > and blue very thin rectangular PCB. > > Please enlighten me how to add DT bindings for these and the PCB which > is in the mail and I did not pick up at the post office yet. > > Of course, I have some hope that the chips on the PCBs are at least > somewhat compatible with what I ordered but I cannot be sure until I > test that. Come on, this is pure bad faith. If you don't even know what that device is, how do you even know how to interact with it? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/o
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On 26 April 2015 at 14:51, Maxime Ripard wrote: > On Sun, Apr 26, 2015 at 02:38:18PM +0200, Michal Suchanek wrote: >> On 26 April 2015 at 13:56, Martin Sperl wrote: >> > >> >> On 26.04.2015, at 13:23, Hans de Goede wrote: >> >> I think there is actual a use for just binding spidev as spidev, >> >> think e.g. the spi pins on the raspberry pi. >> >> >> >> How do you deal we suggest with such a situation ? >> > >> > I actually asked the same question a few days ago on the spi list >> > (in thread: "spi: spidev: Warn loudly if instantiated from DT as “spidev”) >> > and the summary was: >> > >> > You can still do as before, but you have to accept that long >> > irritating warning. >> > >> > Or you patch spidev.c to include your pattern of choice for compatiblity >> >> So the suggestion is to add a compatible string like olimex,uext-slot >> to spidev and use that compatible in the DT? > > No, you add a compatible for the device that is connected to the bus > through that slot. There is no device connected in the slot by design. The slot is there for connecting random stuff you find in your mailbox or other drawers and boxes. > >> That can certainly be done but adding a new compatible for every board >> that has some random pins looks like a needless nuisance to me. >> Especially compared to i2c where you can just open the bus so long as >> ti is enabled. >> >> > >> > Or you implement the following proposal (which needs a volunteer): >> >> On 23.04.2015, at 09:42, Geert Uytterhoeven wrote: >> >> >> >> So what you need is a way to handover from generic spidev to a >> >> device-specific >> >> driver, cfr. what graphics drivers do when the device has been bound to by >> >> vesafb or simplefb. >> >> >> >> Could this be implemented in a generic way in the spi or DT code? >> > >> > ... >> >> On 23.04.2015, at 12:36, Mark Brown wrote: >> >> On Thu, Apr 23, 2015 at 09:45:16AM +0200, Geert Uytterhoeven wrote: >> >> >> >>> I guess this has been suggested before: the spi core could provide spidev >> >>> access to all spi client devices which are not bound by a driver? >> >> >> >> I don't know if it's been suggested before, certainly nobody did the >> >> work to make it happen. I don't think I have a massive objection in >> >> principal. > > Actually, I did it a year ago, and it looked at the time that it > wasn't what should be done either. There is nothing like unclaimed device. Either there is a device and driver for it may in principle be loaded later as a module or the chip select is reserved for use from userspace. Userspace driver is valid option and should have the ability to have the chip select reserved. > > https://lkml.org/lkml/2014/4/28/612 > >> But how do you know there is a device? >> >> Devices on i2c can be probed. On spi you just transfer random data and >> hope it does something useful. Some devices have readable registers >> and can be probed in a device-specific way but others are write-only. > > Well, what's the point of communicating with a non-existent device in > the first place? I have multitude of SPI devices which are not part of the board and hence its DT and can be connected to the board with jumper wires. Most of them don't have a linux driver or compatible to bind with. > >> So binding spidev is in my view just saying that you are going to >> transfer random data from userspace on this bus. > > Yes, to a device connected on that bus. Yes, so I have this red rectangular PCB, blue PCB, and red square PCB and blue very thin rectangular PCB. Please enlighten me how to add DT bindings for these and the PCB which is in the mail and I did not pick up at the post office yet. Of course, I have some hope that the chips on the PCBs are at least somewhat compatible with what I ordered but I cannot be sure until I test that. Thanks Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On Sun, Apr 26, 2015 at 02:38:18PM +0200, Michal Suchanek wrote: > On 26 April 2015 at 13:56, Martin Sperl wrote: > > > >> On 26.04.2015, at 13:23, Hans de Goede wrote: > >> I think there is actual a use for just binding spidev as spidev, > >> think e.g. the spi pins on the raspberry pi. > >> > >> How do you deal we suggest with such a situation ? > > > > I actually asked the same question a few days ago on the spi list > > (in thread: "spi: spidev: Warn loudly if instantiated from DT as “spidev”) > > and the summary was: > > > > You can still do as before, but you have to accept that long > > irritating warning. > > > > Or you patch spidev.c to include your pattern of choice for compatiblity > > So the suggestion is to add a compatible string like olimex,uext-slot > to spidev and use that compatible in the DT? No, you add a compatible for the device that is connected to the bus through that slot. > That can certainly be done but adding a new compatible for every board > that has some random pins looks like a needless nuisance to me. > Especially compared to i2c where you can just open the bus so long as > ti is enabled. > > > > > Or you implement the following proposal (which needs a volunteer): > >> On 23.04.2015, at 09:42, Geert Uytterhoeven wrote: > >> > >> So what you need is a way to handover from generic spidev to a > >> device-specific > >> driver, cfr. what graphics drivers do when the device has been bound to by > >> vesafb or simplefb. > >> > >> Could this be implemented in a generic way in the spi or DT code? > > > > ... > >> On 23.04.2015, at 12:36, Mark Brown wrote: > >> On Thu, Apr 23, 2015 at 09:45:16AM +0200, Geert Uytterhoeven wrote: > >> > >>> I guess this has been suggested before: the spi core could provide spidev > >>> access to all spi client devices which are not bound by a driver? > >> > >> I don't know if it's been suggested before, certainly nobody did the > >> work to make it happen. I don't think I have a massive objection in > >> principal. Actually, I did it a year ago, and it looked at the time that it wasn't what should be done either. https://lkml.org/lkml/2014/4/28/612 > But how do you know there is a device? > > Devices on i2c can be probed. On spi you just transfer random data and > hope it does something useful. Some devices have readable registers > and can be probed in a device-specific way but others are write-only. Well, what's the point of communicating with a non-existent device in the first place? > So binding spidev is in my view just saying that you are going to > transfer random data from userspace on this bus. Yes, to a device connected on that bus. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
On 26 April 2015 at 13:56, Martin Sperl wrote: > >> On 26.04.2015, at 13:23, Hans de Goede wrote: >> I think there is actual a use for just binding spidev as spidev, >> think e.g. the spi pins on the raspberry pi. >> >> How do you deal we suggest with such a situation ? > > I actually asked the same question a few days ago on the spi list > (in thread: "spi: spidev: Warn loudly if instantiated from DT as “spidev”) > and the summary was: > > You can still do as before, but you have to accept that long > irritating warning. > > Or you patch spidev.c to include your pattern of choice for compatiblity So the suggestion is to add a compatible string like olimex,uext-slot to spidev and use that compatible in the DT? That can certainly be done but adding a new compatible for every board that has some random pins looks like a needless nuisance to me. Especially compared to i2c where you can just open the bus so long as ti is enabled. > > Or you implement the following proposal (which needs a volunteer): >> On 23.04.2015, at 09:42, Geert Uytterhoeven wrote: >> >> So what you need is a way to handover from generic spidev to a >> device-specific >> driver, cfr. what graphics drivers do when the device has been bound to by >> vesafb or simplefb. >> >> Could this be implemented in a generic way in the spi or DT code? > > ... >> On 23.04.2015, at 12:36, Mark Brown wrote: >> On Thu, Apr 23, 2015 at 09:45:16AM +0200, Geert Uytterhoeven wrote: >> >>> I guess this has been suggested before: the spi core could provide spidev >>> access to all spi client devices which are not bound by a driver? >> >> I don't know if it's been suggested before, certainly nobody did the >> work to make it happen. I don't think I have a massive objection in >> principal. But how do you know there is a device? Devices on i2c can be probed. On spi you just transfer random data and hope it does something useful. Some devices have readable registers and can be probed in a device-specific way but others are write-only. So binding spidev is in my view just saying that you are going to transfer random data from userspace on this bus. Thanks Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example.
> On 26.04.2015, at 13:23, Hans de Goede wrote: > I think there is actual a use for just binding spidev as spidev, > think e.g. the spi pins on the raspberry pi. > > How do you deal we suggest with such a situation ? I actually asked the same question a few days ago on the spi list (in thread: "spi: spidev: Warn loudly if instantiated from DT as “spidev”) and the summary was: You can still do as before, but you have to accept that long irritating warning. Or you patch spidev.c to include your pattern of choice for compatiblity Or you implement the following proposal (which needs a volunteer): > On 23.04.2015, at 09:42, Geert Uytterhoeven wrote: > > So what you need is a way to handover from generic spidev to a device-specific > driver, cfr. what graphics drivers do when the device has been bound to by > vesafb or simplefb. > > Could this be implemented in a generic way in the spi or DT code? ... > On 23.04.2015, at 12:36, Mark Brown wrote: > On Thu, Apr 23, 2015 at 09:45:16AM +0200, Geert Uytterhoeven wrote: > >> I guess this has been suggested before: the spi core could provide spidev >> access to all spi client devices which are not bound by a driver? > > I don't know if it's been suggested before, certainly nobody did the > work to make it happen. I don't think I have a massive objection in > principal. Martin -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
