[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aU_4RhfUlJ5R_inQ@smile.fi.intel.com>
Date: Sat, 27 Dec 2025 17:16:22 +0200
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: David Lechner <dlechner@...libre.com>
Cc: Mark Brown <broonie@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Marcelo Schmitt <marcelo.schmitt@...log.com>,
Michael Hennerich <michael.hennerich@...log.com>,
Nuno Sá <nuno.sa@...log.com>,
Jonathan Cameron <jic23@...nel.org>,
Andy Shevchenko <andy@...nel.org>,
Sean Anderson <sean.anderson@...ux.dev>, linux-spi@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-iio@...r.kernel.org
Subject: Re: [PATCH v4 3/9] spi: support controllers with multiple data lanes
On Fri, Dec 19, 2025 at 03:32:11PM -0600, David Lechner wrote:
> Add support for SPI controllers with multiple physical SPI data lanes.
> (A data lane in this context means lines connected to a serializer, so a
> controller with two data lanes would have two serializers in a single
> controller).
>
> This is common in the type of controller that can be used with parallel
> flash memories, but can be used for general purpose SPI as well.
>
> To indicate support, a controller just needs to set ctlr->num_data_lanes
> to something greater than 1. Peripherals indicate which lane they are
> connected to via device tree (ACPI support can be added if needed).
>
> The spi-{tx,rx}-bus-width DT properties can now be arrays. The length of
> the array indicates the number of data lanes, and each element indicates
> the bus width of that lane. For now, we restrict all lanes to have the
> same bus width to keep things simple. Support for an optional controller
> lane mapping property is also implemented.
...
> +#define SPI_DEVICE_DATA_LANE_CNT_MAX 8
> + /* Multi-lane SPI controller support. */
> + u32 tx_lane_map[SPI_DEVICE_DATA_LANE_CNT_MAX];
> + u32 num_tx_lanes;
> + u32 rx_lane_map[SPI_DEVICE_DATA_LANE_CNT_MAX];
> + u32 num_rx_lanes;
This adds 8*4 + 4 + 8*4 + 4 bytes to the already big enough structure for
the rather rare use cases. Can we start doing it separately and use just
a pointer here?
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists