On Mon, Sep 23, 2024 at 03:46:04PM +0300, Serge Semin wrote:
> 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?
Nope, legacy will use current defaults. Only new will be more flexible.
> Do the Intel/AMD/etc ACPI firmware currently provide such a data?
I can't tell for AMD for sure, neither for Intel as a whole (not
a product related engineer). I can tell only for my experience and
I haven't known any of Intel devices with such IP that has it different.
> In anyway it would be inapplicable for the legacy hardware anyway.
Exactly!
> > (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.
Something is telling me that this will never be needed IRL.
...
> > 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.
Thanks!
--
With Best Regards,
Andy Shevchenko
