Message ID | 20180924130021.20530-2-peter.ujfalusi@ti.com (mailing list archive) |
---|---|
State | RFC |
Headers | show |
Series | dmaengine: ti: New DMA driver for Texas Instruments UDMA | expand |
On 24-09-18, 16:00, Peter Ujfalusi wrote: > A DMA hardware can have big cache or FIFO and the amount of data sitting in > the DMA fabric can be an interest for the clients. > > For example in audio we want to know the delay in the data flow and in case > the DMA have significantly large FIFO/cache, it can affect the latenc/delay this looks okay to me, but not really up for 'cached', better alternates? Also we need to update Documentation for this.. > > Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> > --- > drivers/dma/dmaengine.h | 7 +++++++ > include/linux/dmaengine.h | 2 ++ > 2 files changed, 9 insertions(+) > > diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h > index 501c0b063f85..80214270b70e 100644 > --- a/drivers/dma/dmaengine.h > +++ b/drivers/dma/dmaengine.h > @@ -77,6 +77,7 @@ static inline enum dma_status dma_cookie_status(struct dma_chan *chan, > state->last = complete; > state->used = used; > state->residue = 0; > + state->cached = 0; > } > return dma_async_is_complete(cookie, complete, used); > } > @@ -87,6 +88,12 @@ static inline void dma_set_residue(struct dma_tx_state *state, u32 residue) > state->residue = residue; > } > > +static inline void dma_set_cached(struct dma_tx_state *state, u32 cached) > +{ > + if (state) > + state->cached = cached; > +} > + > struct dmaengine_desc_callback { > dma_async_tx_callback callback; > dma_async_tx_callback_result callback_result; > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h > index 10ff71b13eef..16c9d021988a 100644 > --- a/include/linux/dmaengine.h > +++ b/include/linux/dmaengine.h > @@ -701,11 +701,13 @@ static inline struct dma_async_tx_descriptor *txd_next(struct dma_async_tx_descr > * @residue: the remaining number of bytes left to transmit > * on the selected transfer for states DMA_IN_PROGRESS and > * DMA_PAUSED if this is implemented in the driver, else 0 > + * @cached: amount of data in bytes cached by the DMA. > */ > struct dma_tx_state { > dma_cookie_t last; > dma_cookie_t used; > u32 residue; > + u32 cached; > }; > > /** > -- > Peter > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 2018-10-09 13:47, Vinod wrote: > On 24-09-18, 16:00, Peter Ujfalusi wrote: >> A DMA hardware can have big cache or FIFO and the amount of data sitting in >> the DMA fabric can be an interest for the clients. >> >> For example in audio we want to know the delay in the data flow and in case >> the DMA have significantly large FIFO/cache, it can affect the latenc/delay > > this looks okay to me, but not really up for 'cached', better > alternates? It is after all the amount of bytes cached within the DMA fabric, but I agree it is a bit awkward. Recently I tried to come up with something better, but did not went too far... dma_cached_bytes? dma_held_bytes? in_flight_bytes? not_in_source_but_not_yet_in_destination_bytes :D ? I try to come up with something for the initial series. > Also we need to update Documentation for this.. Sure, I tend to forget that. > >> >> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> >> --- >> drivers/dma/dmaengine.h | 7 +++++++ >> include/linux/dmaengine.h | 2 ++ >> 2 files changed, 9 insertions(+) >> >> diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h >> index 501c0b063f85..80214270b70e 100644 >> --- a/drivers/dma/dmaengine.h >> +++ b/drivers/dma/dmaengine.h >> @@ -77,6 +77,7 @@ static inline enum dma_status dma_cookie_status(struct dma_chan *chan, >> state->last = complete; >> state->used = used; >> state->residue = 0; >> + state->cached = 0; >> } >> return dma_async_is_complete(cookie, complete, used); >> } >> @@ -87,6 +88,12 @@ static inline void dma_set_residue(struct dma_tx_state *state, u32 residue) >> state->residue = residue; >> } >> >> +static inline void dma_set_cached(struct dma_tx_state *state, u32 cached) >> +{ >> + if (state) >> + state->cached = cached; >> +} >> + >> struct dmaengine_desc_callback { >> dma_async_tx_callback callback; >> dma_async_tx_callback_result callback_result; >> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h >> index 10ff71b13eef..16c9d021988a 100644 >> --- a/include/linux/dmaengine.h >> +++ b/include/linux/dmaengine.h >> @@ -701,11 +701,13 @@ static inline struct dma_async_tx_descriptor *txd_next(struct dma_async_tx_descr >> * @residue: the remaining number of bytes left to transmit >> * on the selected transfer for states DMA_IN_PROGRESS and >> * DMA_PAUSED if this is implemented in the driver, else 0 >> + * @cached: amount of data in bytes cached by the DMA. >> */ >> struct dma_tx_state { >> dma_cookie_t last; >> dma_cookie_t used; >> u32 residue; >> + u32 cached; >> }; >> >> /** >> -- >> Peter >> >> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. >> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 09-10-18, 14:05, Peter Ujfalusi wrote: > > > On 2018-10-09 13:47, Vinod wrote: > > On 24-09-18, 16:00, Peter Ujfalusi wrote: > >> A DMA hardware can have big cache or FIFO and the amount of data sitting in > >> the DMA fabric can be an interest for the clients. > >> > >> For example in audio we want to know the delay in the data flow and in case > >> the DMA have significantly large FIFO/cache, it can affect the latenc/delay > > > > this looks okay to me, but not really up for 'cached', better > > alternates? > > It is after all the amount of bytes cached within the DMA fabric, but I > agree it is a bit awkward. > > Recently I tried to come up with something better, but did not went too > far... > dma_cached_bytes? > dma_held_bytes? > in_flight_bytes? > not_in_source_but_not_yet_in_destination_bytes :D ? yeah_that_sounds_good :D, i think in_flight would be apt here..
diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h index 501c0b063f85..80214270b70e 100644 --- a/drivers/dma/dmaengine.h +++ b/drivers/dma/dmaengine.h @@ -77,6 +77,7 @@ static inline enum dma_status dma_cookie_status(struct dma_chan *chan, state->last = complete; state->used = used; state->residue = 0; + state->cached = 0; } return dma_async_is_complete(cookie, complete, used); } @@ -87,6 +88,12 @@ static inline void dma_set_residue(struct dma_tx_state *state, u32 residue) state->residue = residue; } +static inline void dma_set_cached(struct dma_tx_state *state, u32 cached) +{ + if (state) + state->cached = cached; +} + struct dmaengine_desc_callback { dma_async_tx_callback callback; dma_async_tx_callback_result callback_result; diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h index 10ff71b13eef..16c9d021988a 100644 --- a/include/linux/dmaengine.h +++ b/include/linux/dmaengine.h @@ -701,11 +701,13 @@ static inline struct dma_async_tx_descriptor *txd_next(struct dma_async_tx_descr * @residue: the remaining number of bytes left to transmit * on the selected transfer for states DMA_IN_PROGRESS and * DMA_PAUSED if this is implemented in the driver, else 0 + * @cached: amount of data in bytes cached by the DMA. */ struct dma_tx_state { dma_cookie_t last; dma_cookie_t used; u32 residue; + u32 cached; }; /**
A DMA hardware can have big cache or FIFO and the amount of data sitting in the DMA fabric can be an interest for the clients. For example in audio we want to know the delay in the data flow and in case the DMA have significantly large FIFO/cache, it can affect the latenc/delay Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> --- drivers/dma/dmaengine.h | 7 +++++++ include/linux/dmaengine.h | 2 ++ 2 files changed, 9 insertions(+)