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!