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 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.