From: Appana Durga Kedareswara Rao <appana.durga.rao@xilinx.com>
To: Vinod Koul <vinod.koul@intel.com>
Cc: "dan.j.williams@intel.com" <dan.j.williams@intel.com>,
Michal Simek <michals@xilinx.com>,
Soren Brinkmann <sorenb@xilinx.com>,
"moritz.fischer@ettus.com" <moritz.fischer@ettus.com>,
"anirudha@xilinx.com" <anirudha@xilinx.com>,
"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Anirudha Sarangi <anirudh@xilinx.com>,
Punnaiah Choudary Kalluri <punnaia@xilinx.com>
Subject: RE: [PATCH v9] dmaengine: Add Xilinx AXI Direct Memory Access Engine driver support
Date: Wed, 11 Nov 2015 12:22:42 +0000 [thread overview]
Message-ID: <C246CAC1457055469EF09E3A7AC4E11A4A4FAC21@XAP-PVEXMBX01.xlnx.xilinx.com> (raw)
In-Reply-To: <20151111105527.GL25173@localhost>
Hi Vinod,
> -----Original Message-----
> From: Vinod Koul [mailto:vinod.koul@intel.com]
> Sent: Wednesday, November 11, 2015 4:25 PM
> To: Appana Durga Kedareswara Rao
> Cc: dan.j.williams@intel.com; Michal Simek; Soren Brinkmann;
> moritz.fischer@ettus.com; anirudha@xilinx.com; dmaengine@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; Anirudha
> Sarangi; Punnaiah Choudary Kalluri
> Subject: Re: [PATCH v9] dmaengine: Add Xilinx AXI Direct Memory Access Engine
> driver support
>
> On Tue, Nov 10, 2015 at 10:23:35AM +0000, Appana Durga Kedareswara Rao
> wrote:
> > > > > Pls justify why we should have two drivers. Looking at code
> > > > > makes me think otherwise
> > > >
> > > >
> > > [pls wrap your messages within 80 chars, I have reflowed below]
>
> And ignoring recommendations does not help!!
Sorry for the noise will fix it next time on wards...
>
>
> > > > I agree with you and even initially we had a common driver with
> > > > the similar implementation as you were mentioning. Later on,
> > > > being soft IPs, new features were added and the IPs became
> > > > diversified. As an example, this driver has a residue Calculation
> > > > whereas the other driver (VDMA) is not applicable and the way interrupts
> are handled is completely different.
> > > > Briefly, they are two complete different IPs with a different
> > > > register set and descriptor format. Eventually, it became too
> > > > complex To manage the common driver as the code became messy with
> lot of conditions around.
> > > > Mainly the validation process is a big concern, as every change In
> > > > the IP compels to test all the complete features of both IPs. So,
> > > > we got convinced to the approach of separating the drivers to
> > > > overcome this and it comes with Few addition lines of common code.
> > >
> > > No it is not that hard, bunch of people already do that.
> > >
> > > You need is a smart probe or perhaps invoke IP specfic method to
> > > initialize dma controller.
> > >
> > > In above case no one forces you to register status callback for
> > > both, you can do based on the controller probed...
> > >
> > > I am sorry but validation is not a strong point here. I have a
> > > driver which manages bunch of different generations. Reuse helps in
> > > having lesser code and bug fixes across generations easily..
> > >
> > > We cant have two drivers pretty much doing same thing in kernel
> > >
> > > Please fix this and come back
> >
> > Sorry for delayed response. I was out sick.
> > I had internal discussions with my team. Both DMA's target for completely
> different use cases, have different register sets and different descriptor formats.
> Interrupt processing is also different. Each of these IPs undergo frequent
> changes and enhancements. Having a single driver means for any small change
> in any of the IPs the testing has to happen across a whole lot of test cases which
> looks inefficient.
> > Thinking futuristically where we don't know in which way the IP changes can
> happen, I feel it is always good to have separate drivers. We can't predict the
> HW changes and since the DMAs are targeted for different use cases, we may
> end up in tricky situations if we have a single driver.
> > I do agree that code reuse is generally efficient. But for our case we are not
> dealing with generations of same IP, but completely different IPs. Though there
> are some similarities between them, I feel the differences are many.
> > On v7 of this series, I had put the same observation to which you seem to have
> agreed. That is the reason I went ahead with other comments. At this point it is
> definitely really hard for me to merge.
>
> Lot of this is unreadable and I am not going to add effort on this
>
> > However, if you still insist and see a lot of value in having a single driver, I will
> see what I can do. As I said, it will be some work and in long term it will be a
> maintenance issue for Xilinx and our customers.
>
> Yes please, I know you will have arguments for it but we know reuse helps,
> reduces bugs. Yes validation is increased but that is how drivers are written and
> maintained, and pls automate that!
Sure will come back with a patch by merging the two drivers soon.
Regards,
Kedar.
>
> --
> ~Vinod
prev parent reply other threads:[~2015-11-11 12:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-24 16:11 [PATCH v9] dmaengine: Add Xilinx AXI Direct Memory Access Engine driver support Kedareswara rao Appana
2015-08-27 14:30 ` Moritz Fischer
2015-08-28 6:31 ` Michal Simek
2015-09-21 17:17 ` Moritz Fischer
2015-10-05 13:01 ` Appana Durga Kedareswara Rao
2015-10-05 15:26 ` Vinod Koul
2015-10-05 15:48 ` Appana Durga Kedareswara Rao
2015-10-06 7:45 ` Vinod Koul
2015-11-10 10:23 ` Appana Durga Kedareswara Rao
2015-11-11 10:55 ` Vinod Koul
2015-11-11 12:22 ` Appana Durga Kedareswara Rao [this message]
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=C246CAC1457055469EF09E3A7AC4E11A4A4FAC21@XAP-PVEXMBX01.xlnx.xilinx.com \
--to=appana.durga.rao@xilinx.com \
--cc=anirudh@xilinx.com \
--cc=anirudha@xilinx.com \
--cc=dan.j.williams@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michals@xilinx.com \
--cc=moritz.fischer@ettus.com \
--cc=punnaia@xilinx.com \
--cc=sorenb@xilinx.com \
--cc=vinod.koul@intel.com \
/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).