[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b3b15c31-2e54-409e-86f3-3102c6ab95ba@linux.dev>
Date: Mon, 18 Aug 2025 10:55:38 -0400
From: Sean Anderson <sean.anderson@...ux.dev>
To: Miquel Raynal <miquel.raynal@...tlin.com>,
David Lechner <dlechner@...libre.com>
Cc: Mark Brown <broonie@...nel.org>, Michal Simek <michal.simek@....com>,
linux-spi@...r.kernel.org, Jinjie Ruan <ruanjinjie@...wei.com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Amit Kumar Mahapatra <amit.kumar-mahapatra@....com>
Subject: Re: [PATCH v2 1/9] dt-bindings: spi: Add spi-buses property
On 8/18/25 04:28, Miquel Raynal wrote:
> Hello,
>
>>> + spi-buses:
>>> + description:
>>> + Array of bus numbers that describes which SPI buses of the controller are
>>> + connected to the peripheral. This only applies to peripherals connected
>>> + to specialized SPI controllers that have multiple SPI buses on a single
>>> + controller.
>>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>>> + minItems: 1
>
>>
>> Finally have some hardware to test this series with using 2 or 4 buses.
>
> Out of curiosity, what is the practical use case and intended benefit?
> Maybe an example of such device and an explanation of how useful this is
> would be welcome, as it does not seem to fit the initial spi idea
> (which has been greatly "improved", not saying it is bad, just unusual).
The idea is to model the case where there are several tightly-integrated
busses on a single controller. e.g. sharing registers and maybe even
clocks. Some of these allow you to drive both busses at once, reading
e.g. the high nibble from one bus and the low nibble from the other.
These sorts of things require coordination from the controller, hence a
spi-buses property instead of two separate buses. This also makes
compatibility easier, since new devicetrees remain more-or-less
compatible with old kernels.
--Sean
Powered by blists - more mailing lists