All of lore.kernel.org
 help / color / mirror / Atom feed
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

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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.