Re: [uClinux-dev] [PATCH 3/3] m68knommu: Add ethernet driver for MCF547x/MCF548x

2012-10-09 Thread Greg Ungerer

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.
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.

Regards
Greg


--

Greg Ungerer  --  Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee  PHONE:   +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, AustraliaWEB: 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


Re: [uClinux-dev] [PATCH 3/3] m68knommu: Add ethernet driver for MCF547x/MCF548x

2012-10-04 Thread Greg Ungerer

Hi Philippe,

I think this needs to be done as a platform driver. It is really the
standard way to deal with platform specifics cleanly. I know this
hardware really only exists on one device, but that is no reason
not to do it. Follow the example of the other Freescale FEC driver.
It won't really change the code too much, it just makes the
platform hardware specifics more cleanly separated from the driver
proper.

A few inline comments below too.


On 24/09/12 18:05, Philippe De Muyter wrote:

This is a fully functionnal  ethernet driver for the MCF547x and MCF548x

  ^^^
  functional


processors, tested on the M5484EVB board and on a custom board inpired
by the M5484EVB board.  It implements a FEC+DMA driver and a mdio driver.

Original work was made by freescale for 2.6.25, but never submitted for
mainline, but cache support, mdio driver, phylib support, general
cleanup and 2.6.30-3.6 ports are mine.

Signed-off-by: Philippe De Muyter p...@macqel.be
---
  arch/m68k/include/asm/m54xxsim.h   |2 +
  arch/m68k/kernel/setup_no.c|5 +
  drivers/net/ethernet/freescale/Kconfig |   26 +-
  drivers/net/ethernet/freescale/Makefile|1 +
  drivers/net/ethernet/freescale/fec_m54xx.c | 1506 
  drivers/net/ethernet/freescale/fec_m54xx.h |  144 +++
  6 files changed, 1683 insertions(+), 1 deletions(-)
  create mode 100644 drivers/net/ethernet/freescale/fec_m54xx.c
  create mode 100644 drivers/net/ethernet/freescale/fec_m54xx.h

diff --git a/arch/m68k/include/asm/m54xxsim.h b/arch/m68k/include/asm/m54xxsim.h
index f5531d5..b4c81bf 100644
--- a/arch/m68k/include/asm/m54xxsim.h
+++ b/arch/m68k/include/asm/m54xxsim.h
@@ -46,6 +46,8 @@
  #define MCF_IRQ_UART2 (MCFINT_VECBASE + 33)
  #define MCF_IRQ_UART3 (MCFINT_VECBASE + 32)
  #define MCF_IRQ_DMA   (MCFINT_VECBASE + 48)   /* DMA */
+#define MCF_IRQ_FEC0   (MCFINT_VECBASE + 39)   /* FEC0 */
+#define MCF_IRQ_FEC1   (MCFINT_VECBASE + 38)   /* FEC1 */

  /*
   *Generic GPIO support


If you want to separate out these types of changes into separate
patches I will happily push them via the m68knommu tree right now.



diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index 71fb299..10131b4 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -261,6 +261,11 @@ void __init setup_arch(char **cmdline_p)
paging_init();
  }

+const char *machdep_get_mac_address(int i)
+{
+   return 0;
+}
+
  /*
   *Get CPU information for use by the procfs.
   */


This really seems like the wrong place to deal with this.
Doing as a platform driver should make this go away anyway.



diff --git a/drivers/net/ethernet/freescale/Kconfig 
b/drivers/net/ethernet/freescale/Kconfig
index 3574e14..64d8fc6 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -7,7 +7,7 @@ config NET_VENDOR_FREESCALE
default y
depends on FSL_SOC || QUICC_ENGINE || CPM1 || CPM2 || PPC_MPC512x || \
   M523x || M527x || M5272 || M528x || M520x || M532x || \
-  ARCH_MXC || ARCH_MXS || (PPC_MPC52xx  PPC_BESTCOMM)
+  M54xx || ARCH_MXC || ARCH_MXS || (PPC_MPC52xx  
PPC_BESTCOMM)
---help---
  If you have a network (Ethernet) card belonging to this class, say Y
  and read the Ethernet-HOWTO, available from
@@ -30,6 +30,30 @@ config FEC
  Say Y here if you want to use the built-in 10/100 Fast ethernet
  controller on some Motorola ColdFire and Freescale i.MX processors.

+config FEC_54xx
+   tristate MCF547x/MCF548x Fast Ethernet Controller support
+   depends on M54xx
+   default y
+   select CRC32
+   select PHYLIB
+   select M54xx_DMA
+   help
+ The MCF547x and MCF548x have a built-in Fast Ethernet Controller.
+ This is not the same FEC controller as on other ColdFire as here
+ the DMA controller is not reserved to the FEC driver, but made
+ available for general DMA work.
+ Saying Y here will include support for this device in the kernel.
+
+config FEC2
+   bool Second FEC ethernet controller (on some ColdFire CPUs)
+   depends on FEC || FEC_54xx
+   default y
+   help
+ Say Y here if you want to use the second built-in 10/100 Fast
+ ethernet controller on some Motorola ColdFire processors. On M54xx,
+ If your second ethernet port is not connected, saying N here will
+ free 2 DMA channels and allow you to use FEC io ports as GPIO's.
+


With a platform driver you won't want this. The similar configuration
we had for the other common Freescale FEC driver got removed. We don't
want to re-introduce it again :-)



  config FEC_MPC52xx
tristate FEC MPC52xx driver
depends on PPC_MPC52xx  PPC_BESTCOMM
diff --git 

Re: [uClinux-dev] [PATCH 3/3] m68knommu: Add ethernet driver for MCF547x/MCF548x

2012-10-04 Thread Philippe De Muyter
Hi Greg,

On Thu, Oct 04, 2012 at 04:56:35PM +1000, Greg Ungerer wrote:
 Hi Philippe,

 I think this needs to be done as a platform driver. It is really the
 standard way to deal with platform specifics cleanly. I know this
 hardware really only exists on one device, but that is no reason
 not to do it. Follow the example of the other Freescale FEC driver.
 It won't really change the code too much, it just makes the
 platform hardware specifics more cleanly separated from the driver
 proper.

 A few inline comments below too.


Thanks for your comments.  I had already started the conversion
to the dma_map_single api, but I am worried that those functions
are not inlined altough IIRC they often resolve to nothing (for the
unmap case) or to a single asm(nop)  (for the map case).

I'll look at your other comments, and especially the notion of
platform driver, that I do not really know.

Best regards

Philippe

-- 
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
___
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


Re: [uClinux-dev] [PATCH 3/3] m68knommu: Add ethernet driver for MCF547x/MCF548x

2012-10-04 Thread Greg Ungerer

Hi Philippe,

On 10/04/2012 05:34 PM, Philippe De Muyter wrote:

On Thu, Oct 04, 2012 at 04:56:35PM +1000, Greg Ungerer wrote:

Hi Philippe,

I think this needs to be done as a platform driver. It is really the
standard way to deal with platform specifics cleanly. I know this
hardware really only exists on one device, but that is no reason
not to do it. Follow the example of the other Freescale FEC driver.
It won't really change the code too much, it just makes the
platform hardware specifics more cleanly separated from the driver
proper.

A few inline comments below too.



Thanks for your comments.  I had already started the conversion
to the dma_map_single api, but I am worried that those functions
are not inlined altough IIRC they often resolve to nothing (for the
unmap case) or to a single asm(nop)  (for the map case).

I'll look at your other comments, and especially the notion of
platform driver, that I do not really know.


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.

Regards
Greg



Greg Ungerer  --  Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee  PHONE:   +61 7 3435 2888
8 Gardner Close,FAX: +61 7 3891 3630
Milton, QLD, 4064, AustraliaWEB: 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


Re: [uClinux-dev] [PATCH 3/3] m68knommu: Add ethernet driver for MCF547x/MCF548x

2012-09-27 Thread Greg Ungerer

Hi Stany,

On 27/09/12 00:02, Stany MARCEL wrote:

Are cache flush needed as GFP_DMA flags are used for memory allocations 
(kmalloc and skbuff) ?


Yes, you will still need to flush caches. Allocating with GFP_DMA means
that the memory you get is capable of being DMA'ed from and to.



Is not the responsibility of arch dependent file to allocate DMA'able memory 
when this flag is used.


Its is DMA'able, but it is not normally cache coherent.

Regards
Greg




-Original Message-
From: Greg Ungerer [mailto:g...@snapgear.com]
Sent: Wed 9/26/2012 2:07 PM
To: uClinux development list
Cc: Philippe De Muyter; Stany MARCEL
Subject: Re: [uClinux-dev] [PATCH 3/3] m68knommu: Add ethernet driver for 
MCF547x/MCF548x

On 09/26/2012 06:20 AM, Philippe De Muyter wrote:

Hello Stany

[CCing uclinux-dev]

On Tue, Sep 25, 2012 at 06:07:45PM +0200, Stany MARCEL wrote:

Hello Philippe,

I have to do the following modification to compile your drivers with MMU 
enabled :

diff --git a/drivers/net/ethernet/freescale/fec_m54xx.c 
b/drivers/net/ethernet/freescale/fec_m54xx.c
index 4204a14..f6cafc6 100644
--- a/drivers/net/ethernet/freescale/fec_m54xx.c
+++ b/drivers/net/ethernet/freescale/fec_m54xx.c
@@ -41,6 +41,10 @@
*/
   #define flush_and_invalidate_dcache() flush_cache_all()

+#ifdef CONFIG_MMU
+#defineflush_dcache_range(A, L) flush_cf_dcache(A, L)


Drivers shouldn't be calling these architecture flush functions at all.
They must use the DMA API and the functions it defines. See

Documentation/DMA-API.txt

For example look at the use of dma_map_single()/dma_unmap_single()
in drivers/net/ethernet/freescale/fec.c. (Ignore the almost certainly
bogus cache_flush_all() for CONFIG_M532x).

Regards
Greg




Greg Ungerer  --  Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee  PHONE:   +61 7 3435 2888
8 Gardner Close,FAX: +61 7 3891 3630
Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com







--

Greg Ungerer  --  Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee  PHONE:   +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, AustraliaWEB: 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


Re: [uClinux-dev] [PATCH 3/3] m68knommu: Add ethernet driver for MCF547x/MCF548x

2012-09-26 Thread Greg Ungerer

On 09/26/2012 06:20 AM, Philippe De Muyter wrote:

Hello Stany

[CCing uclinux-dev]

On Tue, Sep 25, 2012 at 06:07:45PM +0200, Stany MARCEL wrote:

Hello Philippe,

I have to do the following modification to compile your drivers with MMU 
enabled :

diff --git a/drivers/net/ethernet/freescale/fec_m54xx.c 
b/drivers/net/ethernet/freescale/fec_m54xx.c
index 4204a14..f6cafc6 100644
--- a/drivers/net/ethernet/freescale/fec_m54xx.c
+++ b/drivers/net/ethernet/freescale/fec_m54xx.c
@@ -41,6 +41,10 @@
   */
  #define flush_and_invalidate_dcache() flush_cache_all()

+#ifdef CONFIG_MMU
+#defineflush_dcache_range(A, L) flush_cf_dcache(A, L)


Drivers shouldn't be calling these architecture flush functions at all.
They must use the DMA API and the functions it defines. See

  Documentation/DMA-API.txt

For example look at the use of dma_map_single()/dma_unmap_single()
in drivers/net/ethernet/freescale/fec.c. (Ignore the almost certainly
bogus cache_flush_all() for CONFIG_M532x).

Regards
Greg




Greg Ungerer  --  Principal EngineerEMAIL: g...@snapgear.com
SnapGear Group, McAfee  PHONE:   +61 7 3435 2888
8 Gardner Close,FAX: +61 7 3891 3630
Milton, QLD, 4064, AustraliaWEB: 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


Re: [uClinux-dev] [PATCH 3/3] m68knommu: Add ethernet driver for MCF547x/MCF548x

2012-09-25 Thread Philippe De Muyter
Hello Stany

[CCing uclinux-dev]

On Tue, Sep 25, 2012 at 06:07:45PM +0200, Stany MARCEL wrote:
 Hello Philippe,
 
 I have to do the following modification to compile your drivers with MMU 
 enabled :
 
 diff --git a/drivers/net/ethernet/freescale/fec_m54xx.c 
 b/drivers/net/ethernet/freescale/fec_m54xx.c
 index 4204a14..f6cafc6 100644
 --- a/drivers/net/ethernet/freescale/fec_m54xx.c
 +++ b/drivers/net/ethernet/freescale/fec_m54xx.c
 @@ -41,6 +41,10 @@
   */
  #define flush_and_invalidate_dcache() flush_cache_all()
  
 +#ifdef CONFIG_MMU
 +#defineflush_dcache_range(A, L) flush_cf_dcache(A, L)
 +#endif
 +
  #include fec_m54xx.h
  #include linux/phy.h

Unfortunately, that's wromg.  Read the comment in
arch/m68k/include/asm/cacheflush_mm.h :

/*
 * Use the ColdFire cpushl instruction to push (and invalidate) cache lines.
 * The start and end addresses are cache line numbers not memory addresses.
 */

So IIRC flush_cf_icache, flush_cf_dcache and flush_cf_bcache seemed uselesss
to me.

You should rather use 'mcf_cache_push'.
 
 
 
 I'll keep you informed of my results.

Thanks

Philippe
___
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


Re: [uClinux-dev] [PATCH 3/3] m68knommu: Add ethernet driver for MCF547x/MCF548x

2012-09-25 Thread Philippe De Muyter
On Tue, Sep 25, 2012 at 10:20:07PM +0200, Philippe De Muyter wrote:
 
 You should rather use 'mcf_cache_push'.

I should have written:

You should rather use '__flush_cache_all'

And that should probably go in arch/m68k/include/asm/cacheflush_mm.h,
as long as arch/m68k/include/asm/cacheflush_mm.h and
arch/m68k/include/asm/cacheflush_no.h are separate files.

Philippe
___
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