[lkml]   [2020]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v3 2/3] dmaengine: add peripheral configuration
Hi Vinod,

On 01/10/2020 14.23, Vinod Koul wrote:
> Hi Peter,
> On 29-09-20, 11:06, Peter Ujfalusi wrote:
>>> + * @spi: peripheral config for spi
>>> + * @i2c: peripheral config for i2c
>>> + */
>>> +struct dmaengine_peripheral_config {
>>> + enum dmaengine_peripheral peripheral;
>>> + u8 set_config;
>>> + u32 rx_len;
>>> + struct dmaengine_spi_config spi;
>>> + struct dmaengine_i2c_config i2c;
>> I know that you want this to be as generic as much as it is possible,
>> but do we really want to?
> That is really a good question ;-)
>> GPIv2 will also handle I2S peripheral, other vendor's similar solution
> Not I2S, but yes but additional peripherals is always a question

Never underestimate the 'creativity'.

>> would require different sets of parameters unique to their IPs?
>> How we are going to handle similar setups for DMA which is used for
>> networking, SPI/I2C/I2S/NAND/display/capture, etc?
>> Imho these settings are really part of the peripheral's domain and not
>> the DMA. It is just a small detail that instead of direct register
>> writes, your setup is using the DMA descriptors to write.
>> It is similar to what I use as metadata (part of the descriptor belongs
>> and owned by the client driver).
>> I think it would be better to have:
>> enum dmaengine_peripheral {
>> ...
>> };
>> enum dmaengine_peripheral peripheral_type;
>> void *peripheral_config;
>> and that's it. The set_config is specific to GPI.
>> It can be debated where the structs should be defined, in the generic
>> dmaengine.h or in include/linux/dma/ as controller specific
>> (gpi_peripheral.h) or a generic one, like dmaengine_peripheral.h
>> The SPI/I2C/UART client of yours would pass the GPI specific struct as
>> in any case it has to know what is the DMA it is serviced by.
> If we want to take that approach, I can actually move the whole logic of
> creating the specific TREs from DMA to clients and they pass on TRE
> values and driver adds to ring after appending DMA TREs

The drawback is that you are tying the driver to a specific DMA with
directly giving the TREs. If the TRE (or other method) is used by a
newer device you need to work on both sides.

> Question is how should this interface look like? reuse metadata or add a
> new API which sets the txn specific data (void pointer and size) to the
> txn..

It depends which is best for the use case.
I see the metadata useful when you need to send different
metadata/configuration with each transfer.
It can be also useful when you need it seldom, but for your use case and
setup the dma_slave_config extended with

enum dmaengine_peripheral peripheral_type;
void *peripheral_config;

would be a bit more explicit.

I would then deal with the peripheral config in this way:
when the DMA driver's device_config is called, I would take the
parameters and set a flag that the config needs to be processed as it
has changed.
In the next prep_slave_sg() then I would prepare the TREs with the
config and clear the flag that the next transfer does not need the
configuration anymore.

In this way each dmaengine_slave_config() will trigger at the next
prep_slave_sg time configuration update for the peripheral to be
included in the TREs.
The set_config would be internal to the DMA driver, clients just need to
update the configuration when they need to and everything is taken care of.

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

 \ /
  Last update: 2020-10-02 10:49    [W:0.085 / U:0.820 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site