Re: [m68k, powerpc, dma, ethernet, freescale RFA] Coldfire m54xx FEC ethernet driver

From: Greg Ungerer <gerg@snapgear•com>
To: Philippe De Muyter <phdm@macqel•be>
Cc: uClinux development list <uclinux-dev@uclinux•org>,
	netdev@vger•kernel.org, linux-kernel@vger•kernel.org,
	linux-m68k@lists•linux-m68k.org,
	stany.marcel@novasys-ingenierie•com,
	linuxppc-dev@lists•ozlabs.org
Subject: Re: [m68k, powerpc, dma, ethernet, freescale RFA] Coldfire m54xx FEC ethernet driver
Date: Tue, 16 Oct 2012 16:39:05 +1000	[thread overview]
Message-ID: <507D0109.1010103@snapgear.com> (raw)
In-Reply-To: <20121009090758.GA14142@frolo.macqel>

Hi Philippe,

On 09/10/12 19:07, Philippe De Muyter wrote:
> [CCing lkml, linux-ppc, netdev, linux-m68k]
>
> Hello kernel sources architects
>
> I have a working driver for the m54xx FEC ethernet driver that I
> would like to integrate in the kernel tree.  Problems are that
> - this driver needs an associated DMA driver (provided by FreeScale)
> wich is not dma-engine enabled
> - they're are already many fec drivers in the kernel tree, and
> at least one, fec_mpc52xx.c, seems to be very similar (information
> below), to the one for the mcf54xx, except it uses a differently
> named associated DMA driver (BestComm/SmartDma/SDMA) which is also
> not dma-engine enabled, and even kept hidden in /arch/powerpc where
> it is inaccessible when compiling for m68k.  The underlying DMA part
> from Freescale however seems similar to the one used in the
> m54xx. (again, see information below)
>
> So, now I am lost, what should I do ?
>
> The current state of my patches
> [http://mailman.uclinux.org/pipermail/uclinux-dev/2012-September/052147.html]
> is pushing the freescale provided MCD_DMA dma driver to /drivers/dma,
> without adding the dma-engine compatibility layer, and adding the specific
> fec_m54xx ethernet driver to /drivers/net/ethernet/freescale

Do you get any responses?
I didn't see any...

Regards
Greg

> On Tue, Oct 09, 2012 at 04:12:44PM +1000, Greg Ungerer wrote:
>> Hi Philippe,
>>
>> On 05/10/12 01:03, Philippe De Muyter wrote:
>>> On Thu, Oct 04, 2012 at 04:56:01PM +0200, Philippe De Muyter wrote:
>>>> On Thu, Oct 04, 2012 at 11:33:32PM +1000, Greg Ungerer wrote:
>>>>>
>>>>> My biggest concern is the amount of MCD/DMA support code. And it is
>>>>> all done quite differently to everything else in the kernel. We may
>>>>> get a bit of push back from kernel folk who look after DMA.
>>>>
>>>> Actually, there is already a similar code in arch/powerpc/sysdev/bestcomm
>>>> (also from freescale, maybe an identical part, but I did not find any
>>>> usable doc), but the powerpc folks kept that hidden in the arch/powerpc
>>>> tree, instead of installing it in drivers/dma.
>>>
>>> The MCD DMA or DMA FEC code from freescale has a comment implying that
>>> this
>>> was first used in the MPC8220 part.  And Montavista has a MPC8220 port,
>>> but
>>> I did not find it, so I do not know where they installed the MCD DMA
>>> driver.
>>
>> Ok, looks like there is a bit a variance in all this.
>
> I also began to read the mpc5200 user's guide parts about the fec and
> BestComm/SmartDma/SDMA (not sure which one is the official FreeScale name)
> and they look very similar, but not identical, to their m54xx counterparts.
>
> It seems possible to make the fec_mpc52xx.c driver work for the m54xx
> but that needs at least:
> - moving some files or part of them from /arch/powerpc/sysdev and
>    /arch/powerpc/include/asm to /drivers/dma and /include/linux,
> - renaming the fec_mpc52xx files to a more sensible name,
> - providing out_be32 and in_be32 in /arch/m68k/include/asm/io.h,
> - and then unifying the interface to BestComm/SmartDma/SDMA and MCD_DMA
>    in mcf_52xx.c.
>
> An additional problem is that the freescale docs for powerpcs and for
> coldfires do not use the same mnemonics for the same registers.
>
> e.g. FEC registers
> 	offset	MPC5200		MCF5484
> 	======	=======		=======
> 	000	FEC_ID		n/a
> 	004	IEVENT		EIR
> 	008	IMASK		EIMR
> 	010	R_DES_ACTIVE	n/a
> 	014	X_DES_ACTIVE	n/a
> 	024	ECNTRL		ECR
> 	040	MII_DATA	MDATA
> 	044	MII_SPEED	MSCR
> 	064	MIB_CONTROL	MIBC
> 	084	R_CNTRL		RCR
> 	088	R_HASH		RHR
> 	0C4	X_CNTRL		TCR
> 	0E4	PADDR1		PALR
> 	0E8	PADDR2		PAHR
> 	0EC	OP_PAUSE	OPD
> 	118	IADDR1		IAUR
> 	11C	IADDR1		IALR
> 	120	GADDR1		GAUR
> 	124	GADDR2		GALR
> 	144	X_WMRK		FECTFWR
> 	184	RFIFO_DATA	FECRFDR
> 	188	RFIFO_STATUS	FECRFSR
> 	18C	RFIFO_CONTROL	FECRFCR
> 	190	RFIFO_LRF_PTR	FECRLRFP
> 	194	RFIFO_LWF_PTR	FECRLWFP
> 	198	RFIFO_ALARM	FECRFAR
> 	19C	RFIFO_RDPTR	FECRFRP
> 	1A0	RFIFO_WRPTR	FECRFWP
> 	1A4	TFIFO_DATA	FECTFDR
> 	1A8	TFIFO_STATUS	FECTFSR
> 	1AC	TFIFO_CONTROL	FECTFCR
> 	1B0	TFIFO_LRF_PTR	FECTLRFP
> 	1B4	TFIFO_LWF_PTR	FECTLWFP
> 	1B8	TFIFO_ALARM	FECTFAR
> 	1BC	TFIFO_RDPTR	FECTFRP
> 	1C0	TFIFO_WRPTR	FECTFWP
> 	1C4	RESET_CNTRL	FECFRST
> 	1C8	XMIT_FSM	FECCTCWR
>
>> Probably the best thing to do is post the patches on the linux kernel
>> mailing list then, asking for direction on a dma driver.
>>
>> I have no problem with it going into the arch/m68k area. So that is
>> always an option.
>
> For the dma engines, the similarity is also obvious.  For example, find
> below side by side mpc52xx and m54xx definitions for the
> main DMA registers :
>
> from mpc52xx.h				from MCD_dma.h
> /* SDMA */				/* MCD_DMA */
> struct mpc52xx_sdma {			struct dmaRegs {
>   u32 taskBar; /* 0x00 */		        u32 taskbar;
>   u32 currentPointer; /* 0x04 */		        u32 currPtr;
>   u32 endPointer; /* 0x08 */		        u32 endPtr;
>   u32 variablePointer; /* 0x0c */	        u32 varTablePtr;
>
>   u8 IntVect1; /* 0x10 */		        u16 dma_rsvd0;
>   u8 IntVect2; /* 0x11 */
>   u16 PtdCntrl; /* 0x12 */		        u16 ptdControl;
>
>   u32 IntPend; /* 0x14 */		        u32 intPending;
>   u32 IntMask; /* 0x18 */		        u32 intMask;
>
>   u16 tcr[16]; /* 0x1c .. 0x3a */	        u16 taskControl[16];
>
>   u8 ipr[32]; /* 0x3c .. 0x5b */		        u8  priority[32];
>
>   u32 cReqSelect; /* 0x5c */		        u32 initiatorMux;
>   u32 task_size0; /* 0x60 */		        u32 taskSize0;
>   u32 task_size1; /* 0x64 */		        u32 taskSize1;
>   u32 MDEDebug; /* 0x68 */		        u32 dma_rsvd1;
>   u32 ADSDebug; /* 0x6c */		        u32 dma_rsvd2;
>   u32 Value1; /* 0x70 */			        u32 debugComp1;
>   u32 Value2; /* 0x74 */			        u32 debugComp2;
>   u32 Control; /* 0x78 */		        u32 debugControl;
>   u32 Status; /* 0x7c */			        u32 debugStatus;
>   u32 PTDDebug; /* 0x80 */		        u32 ptdDebug;
> };					};
>
>
>
>

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear•com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux•org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux•org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev