Paul Bolle writes:
> On Wed, 2015-05-27 at 08:15 +0200, Robert Jarzmik wrote:
>> Paul Bolle writes:
>> > Was it actually intended for PXA_DMA to be tristate?
>> It is designed to be a module, and in the "end" it will be a module.
>>
>> What is important to understand is the 3 phases which are g
On Wed, 2015-05-27 at 08:15 +0200, Robert Jarzmik wrote:
> Paul Bolle writes:
> > Was it actually intended for PXA_DMA to be tristate?
> It is designed to be a module, and in the "end" it will be a module.
>
> What is important to understand is the 3 phases which are going to happen :
> - phase
Paul Bolle writes:
> Vinod already applied this, so my remarks, if valid, should probably be
> handled in a follow up patch.
>
>> +module_platform_driver(pxad_driver);
>
> (The series starting at https://lkml.org/lkml/2015/5/10/131 would allow
> to use builtin_platform_driver() for built-in only
Vinod already applied this, so my remarks, if valid, should probably be
handled in a follow up patch.
On Mon, 2015-05-25 at 23:29 +0200, Robert Jarzmik wrote:
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> +config PXA_DMA
> + bool "PXA DMA support"
> + depends on (ARCH_MMP ||
This is a new driver for pxa SoCs, which is also compatible with the former
mmp_pdma.
The rationale behind a new driver (as opposed to incremental patching) was :
- the new driver relies on virt-dma, which obsoletes all the internal
structures of mmp_pdma (sw_desc, hw_desc, ...), and by conse
5 matches
Mail list logo
