Re: [PATCH RFC v4 00/15] spi: axi-spi-engine: add offload support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi David,

On Wed, 2024-10-23 at 15:59 -0500, David Lechner wrote:
> In this revision, I ended up changing quite a bit more that I was
> expecting.
> 
> In the DT bindings, I ended up dropping the #spi-offload-cells and
> spi-offload properties. A couple of reasons for this:
> 
> 1. Several people commented that it is odd to have a separate provider/
>    consumer binding for something that already has a parent/child
>    relationship (both on this series and in another unrelated series
>    with io-backends). For now, the only SPI offload provider is the AXI
>    SPI Engine, which is a SPI controller.
> 2. In a discussion unrelated to this series, but related to the idea
>    of SPI offloads [1], it became apparent that the proposed use for
>    the cells to select triggers and tx/rx streams doesn't actually
>    work for that case.
> 3. In offline review, it was suggested that assigning specific offloads
>    to specific peripherals may be too restrictive, e.g. if there are
>    controllers that have pools of identical offloads. This idea of
>    pools of generic offloads has also come up in previous discussions
>    on the mailing list.
> 
> [1]:
> https://lore.kernel.org/linux-iio/e5310b63-9dc4-43af-9fbe-0cc3b604ab8b@xxxxxxxxxxxx/
> 
> So the idea is that if we do end up needing to use DT to assign certain
> resources (triggers, DMA channels, etc.) to specific peripherals, we
> would make a mapping attribute in the controller node rather than using
> phandle cells. But we don't need this yet, so it isn't present in The
> current patches.
> 
> And if we ever end up with a SPI offload provider that is not a SPI
> controller, we can bring back the #spi-offload-cells and
> spi-offload properties.

Well I do like we kind of gave a step back and are more focused in supporting what we
have and know at the moment. And I think (for what I saw so far) things are being
implemented in fairly flexible manner. So yeah, as far as I'm concerned, I liked what
I saw so far. Hopefully everyone can agree on this so we drop the RFC :)

I'll try to look at the remaining patches tomorrow...

- Nuno Sá







[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux