Received-SPF: pass (google.com: domain of linux-kernel+bounces-63066-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Tue, 13 Feb 2024 13:23:06 +0530
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Serge Semin <fancer.lancer@gmail.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	Mrinmay Sarkar <quic_msarkar@quicinc.com>,
	Manivannan Sadhasivam <mani@kernel.org>, vkoul@kernel.org,
	jingoohan1@gmail.com, conor+dt@kernel.org, konrad.dybcio@linaro.org,
	robh+dt@kernel.org, quic_shazhuss@quicinc.com,
	quic_nitegupt@quicinc.com, quic_ramkri@quicinc.com,
	quic_nayiluri@quicinc.com, dmitry.baryshkov@linaro.org,
	quic_krichai@quicinc.com, quic_vbadigan@quicinc.com,
	quic_parass@quicinc.com, quic_schintav@quicinc.com,
	quic_shijjose@quicinc.com,
	Gustavo Pimentel <gustavo.pimentel@synopsys.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= <kw@linux.com>,
	Rob Herring <robh@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>,
	Kishon Vijay Abraham I <kishon@kernel.org>,
	dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	mhi@lists.linux.dev
Subject: Re: [PATCH v1 3/6] PCI: dwc: Add HDMA support
Message-ID: <20240213075232.GA5067@thinkpad>
References: <oa76ts3zqud7mtkpilbo4uub7gazqncnbh6rma26kaz6wt6fch@ufv672fgrcgj>
 <20240209171032.GA1004885@bhelgaas>
 <qppxhhlbjqmop2vmaa6b5zjesgry75hapllokcmllgfwti4tbo@55aeewwp23cq>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <qppxhhlbjqmop2vmaa6b5zjesgry75hapllokcmllgfwti4tbo@55aeewwp23cq>

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@linaro.org>
> > > > 
> > > > 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

-- 
மணிவண்ணன் சதாசிவம்