Hi Angelo, On 26-05-18, 22:50, Angelo Dureghello wrote: > > 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. Okay there are few ways we can do this. One is to use helpers for register access and these helpers are different for the variant you are loaded on. Another is to use register offsets which are set based on the variant loaded.. HTH -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html