Re: [PATCH 11/13] MIPS: Add Mobileye EyeQ6Lplus evaluation board dts

Re: [PATCH 11/13] MIPS: Add Mobileye EyeQ6Lplus evaluation board dts

[Linus Walleij]

On Fri, Dec 19, 2025 at 4:57 PM Benoît Monin <benoit.monin@bootlin.com> wrote:

> In my particular case of a microcontroller acting as an SPI "relay" on the
> evaluation board, what would be the best way to describe it? It connects
> the two SPI controllers of the SoC, one is a host and one is a target, so
> it behave as an SPI target on one side and as an SPI host on the other.
>
> The trivial devices bindings seems to be dedicated to devices, thus not for
> SPI hosts. Do I need a dedicated binding or did I miss something I could
> use for a trivial spidev slave?

That needs to be detailed and discussed with the SPI maintainer on the SPI
devel list. (Added.)

Can you illustrate with a picture or so what is going on here?

Yours,
Linus Walleij

Re: [PATCH 11/13] MIPS: Add Mobileye EyeQ6Lplus evaluation board dts

[Benoît Monin]

Hi Linus,

On Thursday, 1 January 2026 at 23:42:36 CET, Linus Walleij wrote:
> On Fri, Dec 19, 2025 at 4:57 PM Benoît Monin <benoit.monin@bootlin.com> wrote:
> 
> > In my particular case of a microcontroller acting as an SPI "relay" on the
> > evaluation board, what would be the best way to describe it? It connects
> > the two SPI controllers of the SoC, one is a host and one is a target, so
> > it behave as an SPI target on one side and as an SPI host on the other.
> >
> > The trivial devices bindings seems to be dedicated to devices, thus not for
> > SPI hosts. Do I need a dedicated binding or did I miss something I could
> > use for a trivial spidev slave?
> 
> That needs to be detailed and discussed with the SPI maintainer on the SPI
> devel list. (Added.)
> 
> Can you illustrate with a picture or so what is going on here?
> 
> Yours,
> Linus Walleij
> 
Here is what it looks like on the evaluation board of the EyeQ6Lplus:

    +------------------------+          +------------------------+
    | EyeQ6Lplus SoC         |          | Evaluation board MCU   |
    |                        |          |                        |
    |           +------------+          +------------+           |
    |           | SPI host   |          | SPI target |           |
    |           |            |          |            |           |
    |           |        CLK >----------> CLK        |           |
    |           |        SDO >----------> SDI        |           |
    |           |        SDI <----------< SDO        |·····      |
    |           |        CS0 >----------> CS         |    ·      |
    |           +------------+          +------------+    ·      |
    |                        |          |                 · (1)  |
    |           +------------+          +------------+    ·      |
    |           | SPI target |          | SPI host   |    ·      |
    |           |            |          |            |<····      |
    |           |        CLK <----------< CLK        |           |
    |           |        SDI <----------< SDO        |           |
    |           |        SDO >----------> SDI        |           |
    |           |        CS  <----------< CS0        |           |
    |           +------------+          +------------+           |
    |                        |          |                        |
    +------------------------+          +------------------------+

(1): The MCU, when the chip select is asserted on its SPI target, starts
     a transaction on its SPI host side. It then copies data received by
     the target side to the host side.

With the spidev entries in the device tree, it is used to test that SPI
of the SoC is working with `spidev_test`. So the MCU is part of the test
harness found on the evaluation board.

If the SPI signals of the SoC had been routed to a header, we could do the
same test with jumper wires, directly connecting the host and the target.

Best regards,
-- 
Benoît Monin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com