All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V3] net: fec_mxc: allow use with cache enabled
Date: Wed, 14 Mar 2012 06:45:18 +0100	[thread overview]
Message-ID: <201203140645.18801.marex@denx.de> (raw)
In-Reply-To: <4F6028C6.9040804@boundarydevices.com>

Dear Eric Nelson,

> On 03/13/2012 06:43 PM, Marek Vasut wrote:
> > Dear Mike Frysinger,
> > 
> >> On Tuesday 13 March 2012 14:42:29 Eric Nelson wrote:
> >>> On 03/13/2012 07:41 AM, Mike Frysinger wrote:
> >>>> On Tuesday 13 March 2012 10:04:31 Eric Nelson wrote:
> >>>>> --- a/drivers/net/fec_mxc.c
> >>>>> +++ b/drivers/net/fec_mxc.c
> >>>>> 
> >>>>> +#if ARCH_DMA_MINALIGN>   CONFIG_SYS_CACHELINE_SIZE
> >>>>> +#define CONFIG_FEC_ALIGN ARCH_DMA_MINALIGN
> >>>>> +#else
> >>>>> +#define CONFIG_FEC_ALIGN CONFIG_SYS_CACHELINE_SIZE
> >>>>> +#endif
> >>>> 
> >>>> i don't think this is something you should be checking.  if this is an
> >>>> actual problem (and i don't think it is), it's something we should
> >>>> handle in common code.  if you need to dma from memory, then use
> >>>> ARCH_DMA_MINALIGN.
> >>> 
> >>> Marek, you've mentioned some restrictions for other i.MX devices.
> >>> 
> >>> Are you aware of any problem collapsing this?
> >>> 
> >>> Note that other CPUs will need to have CONFIG_SYS_CACHELINE_SIZE to
> >>> prevent the default of 64.
> >> 
> >> and those cores should be making sure that ARCH_DMA_MINALIGN is
> >> sufficient to handle those larger cache lines.  this define provides
> >> two meanings: minimum alignment for the DMA itself, and for sanely
> >> flushing the cache on that dma buffer.  so there should be no situation
> >> where ARCH_DMA_MINALIGN is smaller than the cacheline size.
> >> 
> >> the few boards i see defining CONFIG_SYS_CACHELINE_SIZE to 64 are all
> >> ARM based, and ARM sets ARCH_DMA_MINALIGN to CONFIG_SYS_CACHELINE_SIZE
> >> if it's defined
> >> -mike
> > 
> > Eric, can you check also PPC /wrt to this? This driver is also used on
> > PPC.
> 
> Hi Marek,
> 
> I'm not seeing any reference to FEC_MXC on PPC. All boards that use
> it appear to be i.MX:

I see, my mistake. Though the PPC systems should be converted ;-)

> 
> ~/u-boot-imx6$ grep -w CONFIG_FEC_MXC include/configs/*.h
> include/configs/flea3.h:#define CONFIG_FEC_MXC
> include/configs/imx27lite-common.h:#define CONFIG_FEC_MXC
> include/configs/m28evk.h:#define	CONFIG_FEC_MXC
> include/configs/mx25pdk.h:#define CONFIG_FEC_MXC
> include/configs/mx28evk.h:#define CONFIG_FEC_MXC
> include/configs/mx35pdk.h:#define CONFIG_FEC_MXC
> include/configs/mx51evk.h:#define CONFIG_FEC_MXC
> include/configs/mx53evk.h:#define CONFIG_FEC_MXC
> include/configs/mx53loco.h:#define CONFIG_FEC_MXC
> include/configs/mx53smd.h:#define CONFIG_FEC_MXC
> include/configs/mx6qarm2.h:#define	CONFIG_FEC_MXC
> include/configs/mx6qsabrelite.h:#define	CONFIG_FEC_MXC
> include/configs/tx25.h:#define CONFIG_FEC_MXC
> include/configs/vision2.h:#define CONFIG_FEC_MXC
> include/configs/zmx25.h:#define CONFIG_FEC_MXC
> 
> Most of the PPC devices seem to have values of 16 or 32
> for ARCH_DMA_MINALIGN, but PPC64BRIDGE and E500MC would
> have a problem if their drivers don't implement a bounce
> buffer because PKTALIGN < ARCH_DMA_MINALIGN.

Awww, leave the check there then, those PPC systems should produce warning when 
they will be flipped so this is not forgotten.

> 
> (see arch/powerpc/include/asm/cache.h)
> 
> This condition is properly tested for in fec_mxc.c.
> 
> Regards,
> 
> 
> Eric

Best regards,
Marek Vasut

  parent reply	other threads:[~2012-03-14  5:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <http://lists.denx.de/pipermail/u-boot/2012-March/#119442>
2012-03-13 14:04 ` [U-Boot] [PATCH V3] net: fec_mxc: allow use with cache enabled Eric Nelson
2012-03-13 14:41   ` Mike Frysinger
2012-03-13 18:42     ` Eric Nelson
2012-03-13 20:14       ` Mike Frysinger
2012-03-14  1:43         ` Marek Vasut
2012-03-14  5:12           ` Eric Nelson
2012-03-14  5:41             ` Mike Frysinger
2012-03-14 19:12               ` Eric Nelson
2012-03-14 20:33                 ` Mike Frysinger
2012-03-14 21:04                   ` Eric Nelson
2012-03-14 21:15                     ` Mike Frysinger
2012-03-14  5:45             ` Marek Vasut [this message]
2012-03-14  1:42       ` Marek Vasut
2012-03-13 15:48   ` Eric Nelson
2012-03-14  1:44     ` Marek Vasut
2012-03-14  1:46   ` Marek Vasut

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=201203140645.18801.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.