dmaengine: mcf-edma: add ColdFire mcf5441x eDMA support
Hi Vinod,
thanks for your support.
Quoted 57 lines · Vinod
Quoted 56 lines · Angelo Dureghello
Hi Vinod,
Quoted 38 lines · Vinod Koul
Quoted 8 lines · Angelo Dureghello
Hi Vinod,
thanks for the review,
Quoted 3 lines · Vinod Koul
Quoted 2 lines · Angelo Dureghello
This patch adds dma support for NXP mcf5441x (ColdFire) family.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
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 8 lines
Quoted 8 lines
Quoted 7 lines
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.cwas too complex and likely too ugly. From here, the decision to create a different driver, but starting from fsl-edma.Quoted 6 lines
Quoted 2 lines
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.ccommon 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 7 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 3 lines
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
Quoted 6 lines
Signature · 5 lines
~Vinod -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to [email protected] 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html