spidev: That spidev in the DT issue again...

spidev: That spidev in the DT issue again...

[Henry Gomersall]

[-- Attachment #1.1: Type: text/plain, Size: 763 bytes --]

Hi All,

Following on from Kyle's email on 2017-11-29 in questioning the
"correct" way to deal with the device type being set as spidev, I'm
still not clear on the solution.

Before I dig deeper into understanding it, is there a reason why we
can't have an "spi-generic" device as a catch-all for a DT defined
userspace SPI bus?

The clear use case for more flexibility in the system is around FPGA
based SoCs (in my case a Zynq). In such a scenario the use of userspace
is a natural complement to runtime configurable hardware blocks. It
would really ease access to (at least somewhat) correct use of the
driver if it could be recognised that the kernel might not actually need
to know what's on the end of an SPI bus.

Best wishes,

Henry


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: spidev: That spidev in the DT issue again...

[Trent Piepho]

On Fri, 2018-02-02 at 15:47 +0000, Henry Gomersall wrote:
> 
> Before I dig deeper into understanding it, is there a reason why we
> can't have an "spi-generic" device as a catch-all for a DT defined
> userspace SPI bus?
> 
> The clear use case for more flexibility in the system is around FPGA
> based SoCs (in my case a Zynq). In such a scenario the use of userspace
> is a natural complement to runtime configurable hardware blocks. It
> would really ease access to (at least somewhat) correct use of the
> driver if it could be recognised that the kernel might not actually need
> to know what's on the end of an SPI bus.

I've got a patch that adds "driver_override" to the SPI bus.  This
already exists on the PCI bus, platform bus, and AMBA bus.

One can name the SPI device's type in the DT correctly to anything you
want.  Call it "smartacoustics,fpga-codec-block-1.0" or whatever.  It
doesn't have to have to be "generic" or "name-of-linux-driver".  Names
like that are what aren't supposed to be in the DT.

Then driver_override allows this specific device to be bound to spidev.
 It works for all other spi drivers too.  Suppose the device you have
created in an FPGA is or can be compatible with a standard SPI eeprom. 
Bind the eeprom driver to it.  Reconfigure the FPGA logic and now it
works like a SPI controlled DAC and switch to the DAI driver.

I think this solves the problems of SPI slaves that are:
* Of an unknown type at the time the DT is given to the kernel.
* Unique devices that don't make sense to put into a kernel driver
framework and should be controlled from userspace as SPI devices.
* Implemented in re-configurable logic and how the kernel should view
them can change.

It does not solve the problem of creating and destroying SPI slaves
dynamically at run time.  This can be solved (and it way that isn't
specific to spidev), via:
* Copying the I2C new_device system, which allows this with limitations
and in a SPI (and I2C) specific way.
* Incorporation of the dynamic DT fragment loading system, which solves
this with far less limitation and it manner that is not bus specific.

Re: spidev: That spidev in the DT issue again...

[Henry Gomersall]

[-- Attachment #1.1: Type: text/plain, Size: 1984 bytes --]

Hi Trent,

On 02/02/18 18:58, Trent Piepho wrote:
>> The clear use case for more flexibility in the system is around FPGA
>> based SoCs (in my case a Zynq). In such a scenario the use of userspace
>> is a natural complement to runtime configurable hardware blocks. It
>> would really ease access to (at least somewhat) correct use of the
>> driver if it could be recognised that the kernel might not actually need
>> to know what's on the end of an SPI bus.
> I've got a patch that adds "driver_override" to the SPI bus.  This
> already exists on the PCI bus, platform bus, and AMBA bus.
> 
> One can name the SPI device's type in the DT correctly to anything you
> want.  Call it "smartacoustics,fpga-codec-block-1.0" or whatever.  It
> doesn't have to have to be "generic" or "name-of-linux-driver".  Names
> like that are what aren't supposed to be in the DT.
> 
> Then driver_override allows this specific device to be bound to spidev.
>  It works for all other spi drivers too.  Suppose the device you have
> created in an FPGA is or can be compatible with a standard SPI eeprom. 
> Bind the eeprom driver to it.  Reconfigure the FPGA logic and now it
> works like a SPI controlled DAC and switch to the DAI driver.
> 

Thanks for that. What's the status of the patch currently? I can't see
it on patchwork...

Looking back at your earlier email you point out doing this through udev
rules, which is IMO a good way to solve the problem

> 
> It does not solve the problem of creating and destroying SPI slaves
> dynamically at run time.  This can be solved (and it way that isn't
> specific to spidev), via:
> * Copying the I2C new_device system, which allows this with limitations
> and in a SPI (and I2C) specific way.
> * Incorporation of the dynamic DT fragment loading system, which solves
> this with far less limitation and it manner that is not bus specific.

Is this an aspiration, a WIP, or just a thought?

Thanks,

Henry


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: spidev: That spidev in the DT issue again...

[Trent Piepho]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2139 bytes --]

On Sat, 2018-02-03 at 08:31 +0000, Henry Gomersall wrote:
> On 02/02/18 18:58, Trent Piepho wrote:
> > > The clear use case for more flexibility in the system is around FPGA
> > > based SoCs (in my case a Zynq). In such a scenario the use of userspace
> > > is a natural complement to runtime configurable hardware blocks. It
> > > would really ease access to (at least somewhat) correct use of the
> > > driver if it could be recognised that the kernel might not actually need
> > > to know what's on the end of an SPI bus.
> > 
> > I've got a patch that adds "driver_override" to the SPI bus.  This
> > already exists on the PCI bus, platform bus, and AMBA bus.
> > 
> 
> Thanks for that. What's the status of the patch currently? I can't see
> it on patchwork...
> 
> Looking back at your earlier email you point out doing this through udev
> rules, which is IMO a good way to solve the problem

I'll need to send it again.

> > 
> > It does not solve the problem of creating and destroying SPI slaves
> > dynamically at run time.  This can be solved (and it way that isn't
> > specific to spidev), via:
> > * Copying the I2C new_device system, which allows this with limitations
> > and in a SPI (and I2C) specific way.
> > * Incorporation of the dynamic DT fragment loading system, which solves
> > this with far less limitation and it manner that is not bus specific.
> 
> Is this an aspiration, a WIP, or just a thought?

The new_device was presented as a patch recently, but was linked to
spidev.  I don't remember seeing a v2 that was not linked to spidev,
which seemed straightforward, but I easily could have missed it.

Most of the dynamic DT pieces are already in the kernel, for example
ce79d54ae44 "spi/of: Add OF notifier handler".  I think the configfs
part is still unmerged, see https://patchwork.kernel.org/patch/5179621/
I don't know why it's not in already.  This would solve the problem of
dynamically adding and removing SPI (and I2C) devices.N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±²˜¢žØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&¢îý»\x05ËÛÔØï¦v¬Îf\x1dp)¹¹br	šê+€Ê+zf£¢·hšˆ§~†­†Ûiÿûàz¹\x1e®w¥¢¸?™¨è­Ú&¢)ߢ^[f

Re: spidev: That spidev in the DT issue again...

[Geert Uytterhoeven]

On Mon, Feb 5, 2018 at 9:42 PM, Trent Piepho <tpiepho-cgc2CodaaHDQT0dZR+AlfA@public.gmane.org> wrote:
> On Sat, 2018-02-03 at 08:31 +0000, Henry Gomersall wrote:
>> On 02/02/18 18:58, Trent Piepho wrote:
>> > It does not solve the problem of creating and destroying SPI slaves
>> > dynamically at run time.  This can be solved (and it way that isn't
>> > specific to spidev), via:
>> > * Copying the I2C new_device system, which allows this with limitations
>> > and in a SPI (and I2C) specific way.
>> > * Incorporation of the dynamic DT fragment loading system, which solves
>> > this with far less limitation and it manner that is not bus specific.
>>
>> Is this an aspiration, a WIP, or just a thought?
>
> The new_device was presented as a patch recently, but was linked to
> spidev.  I don't remember seeing a v2 that was not linked to spidev,
> which seemed straightforward, but I easily could have missed it.

You can base the implementation on the existing spi_slave_store() for SPI
slave controllers. Changes to be made:
  1. Read both chipselect number and driver name from the string passed,
  2. Change the device_find_child() call to look for an existing child with the
     specified chipselect number.
     XXX Do we want to allow overrides, or return -EBUSY if found?
  3. Fill in the chipselect number before calling spi_add_device().
  4. Tie it to the spi_master class,

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html