Re: [PATCH v3 1/1] dmaengine: dw: Select only supported masters for ACPI devices

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

 



On Mon, Sep 23, 2024 at 03:26:24PM +0300, Andy Shevchenko wrote:
> On Mon, Sep 23, 2024 at 02:57:27PM +0300, Serge Semin wrote:
> > On Mon, Sep 23, 2024 at 11:21:37AM +0300, Andy Shevchenko wrote:
> > > On Mon, Sep 23, 2024 at 01:01:08AM +0300, Serge Semin wrote:
> > > > On Fri, Sep 20, 2024 at 06:56:17PM +0300, Andy Shevchenko wrote:
> 
> ...
> 
> 
> Yes, I still prefer mine.
> 
> > But, again IMO, it seems to be
> > better to add the default_{m,p}_master/d{p,m}_master/etc fields to the
> > dw_dma_platform_data structure since the platform-specific controller
> > settings have been consolidated in there. The dw_dma_chip_pdata
> > structure looks as more like generic driver data storage.
> 
> I don't think that is correct place for it. The platform data is specific
> to the DMA controller as a whole and having there the master configuration
> will mean to have the arrays of them. This OTOH will break the OF setup
> where this comes from the slave descriptions and may not be provided with
> DMA controller, making it imbalanced. Yes, I may agree with you that chip data
> is not a good place either, but at least it isolates the case to PCI + ACPI /
> pure ACPI devices (and in particular we won't need to alter Intel Quark case).
> 

> Ideally, we should parse the additional properties from ACPI for this kind
> of DMA controllers to get this from the _slave_ resources. Currently this is
> not done, but anyone may propose a such

I guess it would also mean to fix all the firmware as well, wouldn't it?
Do the Intel/AMD/etc ACPI firmware currently provide such a data? In
anyway it would be inapplicable for the legacy hardware anyway.

> (would you like to volunteer?).

not really.) Maybe in some long-distance future when I get to meet a
device on the ACPI-based platform with the DW DMAC + some peripheral
experiencing the denoted problem, I'll think about implementing what
we've discussed here.

> 
> ...
> 
> TL;DR: If you are okay with your authorship in v3, I prefer it over other
> versions with the explanations given in this email thread.

Ok. Let's leave it as of your preference.

-Serge(y)

> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux