From: Philippe De Muyter <phdm@macqel.be>
To: Greg Ungerer <gerg@snapgear.com>
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 10:03:49 +0200 [thread overview]
Message-ID: <20121016080349.GA8427@frolo.macqel> (raw)
In-Reply-To: <507D0109.1010103@snapgear.com>
Hi Greg,
On Tue, Oct 16, 2012 at 04:39:05PM +1000, Greg Ungerer wrote:
> 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...
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
>
>
>
>> 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;
>> }; };
_______________________________________________
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
next prev parent reply other threads:[~2012-10-16 8:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1348473919-30257-1-git-send-email-phdm@macqel.be>
[not found] ` <1348473919-30257-4-git-send-email-phdm@macqel.be>
[not found] ` <506D3323.4000205@snapgear.com>
[not found] ` <20121004073448.GA4339@frolo.macqel>
[not found] ` <506D902C.30902@snapgear.com>
[not found] ` <20121004145601.GA15358@frolo.macqel>
[not found] ` <20121004150329.GB15358@frolo.macqel>
[not found] ` <5073C05C.2080809@snapgear.com>
2012-10-09 9:07 ` [m68k, powerpc, dma, ethernet, freescale RFA] Coldfire m54xx FEC ethernet driver Philippe De Muyter
2012-10-16 6:39 ` Greg Ungerer
2012-10-16 8:03 ` Philippe De Muyter [this message]
2012-10-24 6:30 ` Greg Ungerer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121016080349.GA8427@frolo.macqel \
--to=phdm@macqel.be \
--cc=gerg@snapgear.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=stany.marcel@novasys-ingenierie.com \
--cc=uclinux-dev@uclinux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).