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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
