Discussion:
[m68k,powerpc,dma,ethernet,freescale RFA] Coldfire m54xx FEC ethernet driver
Philippe De Muyter
2012-10-09 09:07:58 UTC
Permalink
[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

Best regards

Philippe
Hi Philippe,
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
2012-10-16 06:39:05 UTC
Permalink
Hi Philippe,
Post by Philippe De Muyter
[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
Post by Philippe De Muyter
Hi Philippe,
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
- 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
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: ***@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
Philippe De Muyter
2012-10-16 08:03:49 UTC
Permalink
Hi Greg,
Hi Philippe,
Post by Philippe De Muyter
[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...
No, and none also about my simpler patch moving arch/powerpc/sysdev/bestcomm
to drivers/dma/bestcomm (except a private and useful one telling me how to
set '-M' option as default for 'git format-patch'), but at least this simpler
patch seems to be in a wait bucket at
http://patchwork.ozlabs.org/project/linuxppc-dev/list/.

Regards

Philippe

PS: -M as default for 'git format-patch':

put
[diff]
renames = true
in .git/config
Regards
Greg
Post by Philippe De Muyter
Hi Philippe,
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
- 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
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
2012-10-24 06:30:08 UTC
Permalink
Hi Philippe,
Post by Philippe De Muyter
Post by Greg Ungerer
Post by Philippe De Muyter
[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...
No, and none also about my simpler patch moving arch/powerpc/sysdev/bestcomm
to drivers/dma/bestcomm (except a private and useful one telling me how to
set '-M' option as default for 'git format-patch'), but at least this simpler
patch seems to be in a wait bucket at
http://patchwork.ozlabs.org/project/linuxppc-dev/list/.
Well, something useful then :-)

Feel free to send me the m68k header file updates as a patch (or patches
as appropriate), lets get those in now. They are worthwhile changes
on their own.

In light of no other other feedback you may want to push ahead then
with your patches to put the DMA engine code in drivers/dma. That
does seem like the right place to put it.

The new fec driver code should go to the netdev list for review.

Regards
Greg
Post by Philippe De Muyter
Regards
Philippe
put
[diff]
renames = true
in .git/config
Post by Greg Ungerer
Regards
Greg
Post by Philippe De Muyter
Hi Philippe,
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
- 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
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: ***@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
Steven King
2014-05-31 02:09:34 UTC
Permalink
Hello,
I have cleaned up and updated to 3.6-rc5 my previous port of the
freescale-written driver for the fast Ethernet Controller of the M547x
and M548x ColdFires. It seems from comments found in Freescale sources
that this uses a MultiChannel DMA controller marketed as MCD and available
also in the NPC8220 also from Freescale. Therefore, I have split the
A generic MCD dma driver
The M54xx instantiation of the MCD driver
The FEC driver for M54xx
I know there are still lines above 80 characters, but I feel they must be
left that way. There are also parts of an unfinished netpoll interface.
Feel free to test and comment.
So whatever happened with this? Was there ever any feedback from the other
maintainers?

For what it is worth, I was able to take the original patches and rebase them
to v3.15-rc6 with just a couple of very minor changes and produce a working
ethernet for my 5484 system.
Greg Ungerer
2014-06-02 06:55:31 UTC
Permalink
Post by Steven King
Hello,
I have cleaned up and updated to 3.6-rc5 my previous port of the
freescale-written driver for the fast Ethernet Controller of the M547x
and M548x ColdFires. It seems from comments found in Freescale sources
that this uses a MultiChannel DMA controller marketed as MCD and available
also in the NPC8220 also from Freescale. Therefore, I have split the
A generic MCD dma driver
The M54xx instantiation of the MCD driver
The FEC driver for M54xx
I know there are still lines above 80 characters, but I feel they must be
left that way. There are also parts of an unfinished netpoll interface.
Feel free to test and comment.
So whatever happened with this? Was there ever any feedback from the other
maintainers?
For what it is worth, I was able to take the original patches and rebase them
to v3.15-rc6 with just a couple of very minor changes and produce a working
ethernet for my 5484 system.
I don't recall seeing too much. Time to try again?

Regards
Greg

Loading...