On Fri, Jul 05, 2024 at 05:09:32PM +0800, Liu Ying wrote:
> Add myself as the maintainer of i.MX8qxp Display Controller.
>
> Signed-off-by: Liu Ying
> ---
> MAINTAINERS | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index
On Fri, May 24, 2024 at 07:27:00PM +0100, Dave Stevenson wrote:
> From: Phil Elwell
>
> Slave addresses for DMA are meant to be supplied as physical addresses
> (contrary to what struct snd_dmaengine_dai_dma_data does).
Can you use the same content for patch 14-17?
Frank
>
> Signed-off-by:
On Fri, May 24, 2024 at 07:26:55PM +0100, Dave Stevenson wrote:
> There is a need to account for dma-ranges and iommus in the
> dma mapping process, and the public API for handling that is
> dma_map_resource.
what's means?
>
> Add support for mapping addresses to the DMA driver.
>
>
On Fri, May 24, 2024 at 07:26:53PM +0100, Dave Stevenson wrote:
> The code handling DMA mapping is currently incorrect and
> needs a sequence of fixups.
Can you descript what incorrect here?
> Move the mapping out into a separate function and structure
> to allow for those fixes to be applied
On Fri, May 24, 2024 at 07:26:52PM +0100, Dave Stevenson wrote:
> From: Stefan Wahren
>
> In preparation to support more platforms pass the dma_chan to the
> generic functions. This provides access to the DMA device and possible
> platform specific data.
why need this change? you can easy
On Fri, May 24, 2024 at 07:26:51PM +0100, Dave Stevenson wrote:
> From: Stefan Wahren
>
> The parameters info and finalextrainfo are platform specific. So drop
> them by generating them within bcm2835_dma_create_cb_chain().
Drop 'info' and 'finalextrainfo' because these can be generated by
On Fri, May 24, 2024 at 07:26:50PM +0100, Dave Stevenson wrote:
> From: Stefan Wahren
>
> Actually the criteria to increment source & destination address doesn't
> based on platform specific bits. It's just the DMA transfer direction which
> is translated into the info bits. So introduce two new
On Fri, May 24, 2024 at 07:26:49PM +0100, Dave Stevenson wrote:
> From: Stefan Wahren
>
> Similar to the info generation, generate the final extra info with a
> separate function. This is necessary to introduce other platforms
> with different info bits.
Each patch commit is independent.
On Fri, May 24, 2024 at 07:26:48PM +0100, Dave Stevenson wrote:
> From: Stefan Wahren
>
> Actually the generation of the Control Block info follows some simple
> rules. So handle this with a separate function to avoid open coding
> for every DMA operation. Another advantage is that we can easier
On Fri, May 24, 2024 at 07:26:46PM +0100, Dave Stevenson wrote:
> From: Stefan Wahren
>
> Nowadays there is a generic property for dma-channel-mask in the DMA
> controller binding. So prefer this one instead of the old vendor specific
> one. Print a warning in case the old one is used. Btw use
On Sat, Jan 20, 2024 at 01:14:52AM +0100, Paul Cercueil wrote:
> Hi Frank,
>
> Le vendredi 19 janvier 2024 à 16:49 -0500, Frank Li a écrit :
> > On Wed, Jan 17, 2024 at 01:26:43PM +0100, Paul Cercueil wrote:
> > > Add a new 'sg_was_mapped' field to the struct usb_r
On Wed, Jan 17, 2024 at 01:26:43PM +0100, Paul Cercueil wrote:
> Add a new 'sg_was_mapped' field to the struct usb_request. This field
> can be used to indicate that the scatterlist associated to the USB
> transfer has already been mapped into the DMA space, and it does not
> have to be done
12 matches
Mail list logo
