On Sun, Feb 11, 2024 at 10:37:43PM +0300, Serge Semin wrote: > On Fri, Feb 09, 2024 at 11:10:32AM -0600, Bjorn Helgaas wrote: > > On Sat, Feb 03, 2024 at 12:40:39AM +0300, Serge Semin wrote: > > > On Fri, Jan 19, 2024 at 06:30:19PM +0530, Mrinmay Sarkar wrote: > > > > From: Manivannan Sadhasivam <manivannan.sadhasivam@xxxxxxxxxx> > > > > > > > > Hyper DMA (HDMA) is already supported by the dw-edma dmaengine driver. > > > > Unlike it's predecessor Embedded DMA (eDMA), HDMA supports only the > > > > unrolled mapping format. So the platform drivers need to provide a valid > > > > base address of the CSRs. Also, there is no standard way to auto detect > > > > the number of available read/write channels in a platform. So the platform > > > > drivers has to provide that information as well. > > > ... > > > > > Basically this change defines two versions of the eDMA info > > > initialization procedure: > > > 1. use pre-defined CSRs mapping format and amount of channels, > > > 2. auto-detect CSRs mapping and the amount of channels. > > > The second version also supports the optional CSRs mapping format > > > detection procedure by means of the DW_PCIE_CAP_EDMA_UNROLL flag > > > semantics. Thus should this patch is accepted there will be the > > > functionality duplication. I suggest to make things a bit more > > > flexible than that. Instead of creating the two types of the > > > init-methods selectable based on the mapping format, let's split up > > > the already available DW eDMA engine detection procedure into the next > > > three stages: > > > 1. initialize DW eDMA data, > > > 2. auto-detect the CSRs mapping format, > > > 3. auto-detect the amount of channels. > > > and convert the later two to being optional. They will be skipped in case > > > if the mapping format or the amount of channels have been pre-defined > > > by the platform drivers. Thus we can keep the eDMA data init procedure > > > more linear thus easier to read, drop redundant DW_PCIE_CAP_EDMA_UNROLL flag > > > and use the new functionality for the Renesas R-Car S4-8's PCIe > > > controller (for which the auto-detection didn't work), for HDMA with compat > > > and _native_ CSRs mapping. See the attached patches for details: > > > > I am still bound by the opinion of Google's legal team that I cannot > > accept the code changes that were attached here. I think it's fair to > > read the review comments (thank you for those), but I suggest not > > reading the patches that were attached. > > Em, the review comment and the resultant patches were my own private > researches and developments. Is Google now blocking even individual > contributors? > > In anyway if you are agree with the changes suggested above you can > set to the patches any author you think would be acceptable. My only > concern was to maintain the cleanness of the driver code developed by > me and which is going to be affected in the framework of this series. > I take the patch authorship seriously, so I won't change the author of your patches. Instead, I'll just create my own patches based on your comments above. - Mani -- மணிவண்ணன் சதாசிவம்
