From: Angelo Dureghello <angelo@sysam.it>
To: Vinod <vkoul@kernel.org>
Cc: Vinod Koul <vinod.koul@intel.com>,
dmaengine@vger.kernel.org, gerg@linux-m68k.org,
linux-m68k@vger.kernel.org
Subject: dmaengine: mcf-edma: add ColdFire mcf5441x eDMA support
Date: Sat, 26 May 2018 22:50:53 +0200 [thread overview]
Message-ID: <20180526205053.GA17528@jerusalem> (raw)
Hi Vinod,
thanks for your support.
On Wed, May 23, 2018 at 11:07:06AM +0530, Vinod wrote:
> On 22-05-18, 23:28, Angelo Dureghello wrote:
> > Hi Vinod,
> >
> > On Mon, May 07, 2018 at 07:45:35PM +0530, Vinod Koul wrote:
> > > On Fri, May 04, 2018 at 09:18:19PM +0200, Angelo Dureghello wrote:
> > > > Hi Vinod,
> > > >
> > > > thanks for the review,
> > > >
> > > > On Thu, May 03, 2018 at 10:18:30PM +0530, Vinod Koul wrote:
> > > > > On Wed, Apr 25, 2018 at 10:08:17PM +0200, Angelo Dureghello wrote:
> > > > > > This patch adds dma support for NXP mcf5441x (ColdFire) family.
> > > > > >
> > > > > > ColdFire mcf5441x implements an edma hw module similar to the
> > > > >
> > > > > Is it similar to to edma ?
> > > > >
> > > >
> > > > It is similar to Freescale "edma" but with a different number of
> > > > channels, a bit different register set, different interrupt
> > > > structure, no channel multiplexer.
> > >
> > > ok
> > >
> > > > > > one implemented in Vybrid VFxxx controllers, but with a slightly
> > > > > > different register set, more dma channels (64 instead of 32),
> > > > > > a different interrupt mechanism and some other minor differences.
> > > > > >
> > > > > > For the above reasons, modfying fsl-edma.c was too complex and
> > > > > > likely too ugly. From here, the decision to create a different
> > > > > > driver, but starting from fsl-edma.
> > > > >
> > > > > can the common stuff be made into a lib and shared between then two rather
> > > > > than having a same driver or different drivers?
> > > >
> > > > It should be possible to collect some common code in a kind of
> > > > mcf_edma_core.c common module, but in this case i cannot then test
> > > > the Vybrid edma after the changes since i miss that hardware.
> > >
> > > Sure you should send the patches and folks who care about fsl driver
> > > would look it up and test
> > >
> > > > Would be maybe possible for you to diff fsl-edma and this mcf-edma,
> > > > just to confirm if i can still stay this way, or if moving to a
> > > > library becomes mandatory ?
> > >
> > > well since you know the IP you would make a better guess on that, best is
> > > to check register sets in drivers
> > >
> > I fixed all the discussed points.
> >
> > Actaully mcf-edma (ColdFire) has a slightly different register set (due to 64
> > channels in place of 16 of fsl-edma) and, for the same reason, a different
> > DMA interrupt structure.
> > Also, i simplified some parts of the driver considering ColdFire (mcf)
> > big endian architecture.
> >
> > So i would send a rev 2 patch with all the fixes, than eventually in a second
> > phase i may try to create some common code, but at least we have the ColdFire
> > DMA. What do you think ?
>
> wouldn't it be easier to just make common parts and then add edma specific code.
> If I was doing this it would be my apprach and that way code edma specific will
> be lesser and faster review
>
I tried to set up a common module, but couldn't reach any good point.
Issues are:
1) Edma register set between 32 and 64ch is similar, but some offsets/names
are not matching between the 2 variants, some registers names are swapped over
the reg. address range,
2) interrupt numbers and scheme is still different, handler implementation comes
different,
3) as a corollary of the above, all the common functions that needs to access
edma registers should use same structure pointers. I could use a union
someway but points where register are accessed are many, and i should
differentiate the access in each case, referencing to a different structure
in each case.
If you have any idea on how i could reach a common module, with 2 different
registers set, that's welcome.
I stay on the thought that a separate 64-channel module is the best
way to go here.
Currently, as Freescale "edma" variants, i know:
Vybrid VFXXX 32ch DMA multiplexer reg.set 1
Kynetis K70 (CortexM4) 32ch DMA multiplexer reg.set 1
imx8xx (coming) 32ch no multiplexer reg.set 1
MPC57xxk 32ch DMA multiplexer reg.set 1
ColdFire mcf5441x 64ch no multiplexer reg.set 2 <---
There may me other cpu using this fsl edma module but not in my knowledge
right now.
So i still think at the end, to have 2 separate drivers for the 32 and 64
variant is good and probably the most ordered/clean solution.
Regards,
Angelo
> --
> ~Vinod
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
---
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2018-05-26 20:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-26 20:50 Angelo Dureghello [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-05-30 20:59 dmaengine: mcf-edma: add ColdFire mcf5441x eDMA support Angelo Dureghello
2018-05-28 4:01 Vinod Koul
2018-05-23 5:37 Vinod Koul
2018-05-22 21:28 Angelo Dureghello
2018-05-07 14:15 Vinod Koul
2018-05-04 19:18 Angelo Dureghello
2018-05-03 16:48 Vinod Koul
2018-04-25 20:08 Angelo Dureghello
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=20180526205053.GA17528@jerusalem \
--to=angelo@sysam.it \
--cc=dmaengine@vger.kernel.org \
--cc=gerg@linux-m68k.org \
--cc=linux-m68k@vger.kernel.org \
--cc=vinod.koul@intel.com \
--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).