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 Wilczyński" <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
Date: Tue, 13 Feb 2024 13:23:06 +0530 [thread overview]
Message-ID: <20240213075232.GA5067@thinkpad> (raw)
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
--
மணிவண்ணன் சதாசிவம்
next prev parent reply other threads:[~2024-02-13 7:53 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-19 13:00 [PATCH v1 0/6] Add Change to integrate HDMA with dwc ep driver Mrinmay Sarkar
2024-01-19 13:00 ` [PATCH v1 1/6] dmaengine: dw-edma: Pass 'struct dw_edma_chip' to irq_vector() Mrinmay Sarkar
2024-01-19 13:23 ` Dmitry Baryshkov
2024-02-02 10:50 ` Serge Semin
2024-01-19 13:00 ` [PATCH v1 2/6] dmaengine: dw-edma: Introduce helpers for getting the eDMA/HDMA max channel count Mrinmay Sarkar
2024-01-19 13:26 ` Dmitry Baryshkov
2024-01-30 8:48 ` Manivannan Sadhasivam
2024-02-02 10:51 ` Serge Semin
2024-01-19 13:00 ` [PATCH v1 3/6] PCI: dwc: Add HDMA support Mrinmay Sarkar
2024-02-02 21:40 ` Serge Semin
2024-02-07 17:06 ` Manivannan Sadhasivam
2024-02-09 17:10 ` Bjorn Helgaas
2024-02-11 19:37 ` Serge Semin
2024-02-13 7:53 ` Manivannan Sadhasivam [this message]
2024-01-19 13:00 ` [PATCH v1 4/6] dmaengine: dw-edma: Move HDMA_V0_MAX_NR_CH definition to edma.h Mrinmay Sarkar
2024-02-02 10:47 ` Serge Semin
2024-02-02 12:26 ` Manivannan Sadhasivam
2024-01-19 13:00 ` [PATCH v1 5/6] PCI: qcom-ep: Provide number of read/write channel for HDMA Mrinmay Sarkar
2024-01-30 8:53 ` Manivannan Sadhasivam
2024-01-30 13:18 ` Mrinmay Sarkar
2024-01-19 13:00 ` [PATCH v1 6/6] PCI: epf-mhi: Add flag to enable HDMA for SA8775P Mrinmay Sarkar
2024-01-30 8:53 ` Manivannan Sadhasivam
2024-01-30 10:00 ` [PATCH v1 0/6] Add Change to integrate HDMA with dwc ep driver Serge Semin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240213075232.GA5067@thinkpad \
--to=manivannan.sadhasivam@linaro.org \
--cc=bhelgaas@google.com \
--cc=conor+dt@kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=fancer.lancer@gmail.com \
--cc=gustavo.pimentel@synopsys.com \
--cc=helgaas@kernel.org \
--cc=jingoohan1@gmail.com \
--cc=kishon@kernel.org \
--cc=konrad.dybcio@linaro.org \
--cc=kw@linux.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=mhi@lists.linux.dev \
--cc=quic_krichai@quicinc.com \
--cc=quic_msarkar@quicinc.com \
--cc=quic_nayiluri@quicinc.com \
--cc=quic_nitegupt@quicinc.com \
--cc=quic_parass@quicinc.com \
--cc=quic_ramkri@quicinc.com \
--cc=quic_schintav@quicinc.com \
--cc=quic_shazhuss@quicinc.com \
--cc=quic_shijjose@quicinc.com \
--cc=quic_vbadigan@quicinc.com \
--cc=robh+dt@kernel.org \
--cc=robh@kernel.org \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).