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:

quoted

Hi Vinod,

On Mon, May 07, 2018 at 07:45:35PM +0530, Vinod Koul wrote:

quoted

On Fri, May 04, 2018 at 09:18:19PM +0200, Angelo Dureghello wrote:

quoted

Hi Vinod,

thanks for the review,

On Thu, May 03, 2018 at 10:18:30PM +0530, Vinod Koul wrote:

quoted

On Wed, Apr 25, 2018 at 10:08:17PM +0200, Angelo Dureghello wrote:

quoted

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

quoted

quoted

quoted

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

quoted

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