DaVinci EMAC is present on TI AM35xx SoCs (ARMv7) which run with D-Cache
enabled by default. So we have to take care and flush/invalidate the
cache before/after the DMA operations.
Signed-off-by: Ilya Yanok
---
drivers/net/davinci_emac.c | 47
1 fil
On Wednesday 05 October 2011 19:36:44 Ilya Yanok wrote:
> --- a/drivers/net/davinci_emac.c
> +++ b/drivers/net/davinci_emac.c
>
> +#ifdef DAVINCI_EMAC_DCACHE
> +static inline void davinci_flush(void *addr, int size)
> +{
> + flush_dcache_range((unsigned long)addr,
> + (unsi
Hi Mike,
On 07.10.2011 21:34, Mike Frysinger wrote:
>> +#ifdef DAVINCI_EMAC_DCACHE
>> +static inline void davinci_flush(void *addr, int size)
>> +{
>> +flush_dcache_range((unsigned long)addr,
>> +(unsigned long)addr + size);
>> +}
>> +
>> +static inline void davinci_invalid
On Sun, Oct 09, 2011 at 02:41:47PM +0400, Ilya Yanok wrote:
> arm926ejs doesn't have {invalidate,flush}_dcache_range(), so we have to
> add this not to break the driver on DaVinci boards (maybe we need to add
> empty cache functions on arm926ejs instead?)
Even better would be working cache functio
On Sunday 09 October 2011 06:41:47 Ilya Yanok wrote:
> On 07.10.2011 21:34, Mike Frysinger wrote:
> >> +#ifdef DAVINCI_EMAC_DCACHE
> >> +static inline void davinci_flush(void *addr, int size)
> >> +{
> >> + flush_dcache_range((unsigned long)addr,
> >> + (unsigned long)addr + size)
On 10/06/2011 01:36 AM, Ilya Yanok wrote:
> DaVinci EMAC is present on TI AM35xx SoCs (ARMv7) which run with D-Cache
> enabled by default. So we have to take care and flush/invalidate the
> cache before/after the DMA operations.
>
> Signed-off-by: Ilya Yanok
Hi Ilya,
> ---
> drivers/net/davinc
Hi Stefano,
On 10.10.2011 16:35, Stefano Babic wrote:
>> +#ifdef DAVINCI_EMAC_DCACHE
>> +static inline void davinci_flush(void *addr, int size)
>> +{
>> +flush_dcache_range((unsigned long)addr,
>> +(unsigned long)addr + size);
>> +}
>
> There is no check with the cache lin
On 10/10/2011 03:03 PM, Ilya Yanok wrote:
> Hi Stefano,
>
Hi Ilya,
> On 10.10.2011 16:35, Stefano Babic wrote:
>>> +#ifdef DAVINCI_EMAC_DCACHE
>>> +static inline void davinci_flush(void *addr, int size)
>>> +{
>>> + flush_dcache_range((unsigned long)addr,
>>> + (unsigned long
Dear Stefano Babic,
In message <4e92f05f.4030...@denx.de> you wrote:
>
> There is a CONFIG_SYS_CACHELINE_SIZE. However, I see recent patches that
> can help in our case ( cache: add ALLOC_CACHE_ALIGN_BUFFER macro):
>
> http://patchwork.ozlabs.org/patch/117698/
>
> Wolfgang replied he has alread
On Monday 10 October 2011 09:39:16 Wolfgang Denk wrote:
> Stefano Babic wrote:
> > There is a CONFIG_SYS_CACHELINE_SIZE. However, I see recent patches that
> > can help in our case ( cache: add ALLOC_CACHE_ALIGN_BUFFER macro):
> >
> > http://patchwork.ozlabs.org/patch/117698/
> >
> > Wolfgang rep
Dear Mike Frysinger,
In message <201110101124.22548.vap...@gentoo.org> you wrote:
>
> > See the rest of the thread. I had applied this patch set to a loal
> > tree, but it was breaking hundreds of systems, so had to back out the
> > patches again.
> >
> > I'm eager to get this code in myself, bu
On Monday 10 October 2011 13:44:21 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > See the rest of the thread. I had applied this patch set to a loal
> > > tree, but it was breaking hundreds of systems, so had to back out the
> > > patches again.
> > >
> > > I'm eager to get this code in mysel
On Mon, Oct 10, 2011 at 10:44 AM, Wolfgang Denk wrote:
> Dear Mike Frysinger,
>
> In message <201110101124.22548.vap...@gentoo.org> you wrote:
>>
>> > See the rest of the thread. I had applied this patch set to a loal
>> > tree, but it was breaking hundreds of systems, so had to back out the
>> >
Dear Anton Staaf,
In message
you wrote:
>
> > When PPC was building again, I tested it on ARM (which I assumed was
> > OK, given that this was Anton's primary architecture). =A0That was when
> > I finally gave up, see
>
> Yes, the patches expose the fact that almost no boards define
> CONFIG_SY
On Mon, Oct 10, 2011 at 11:31 AM, Wolfgang Denk wrote:
> Dear Anton Staaf,
>
> In message
> you
> wrote:
>>
>> > When PPC was building again, I tested it on ARM (which I assumed was
>> > OK, given that this was Anton's primary architecture). =A0That was when
>> > I finally gave up, see
>>
>> Ye
On Mon, Oct 10, 2011 at 11:45 AM, Anton Staaf wrote:
> On Mon, Oct 10, 2011 at 11:31 AM, Wolfgang Denk wrote:
>> Dear Anton Staaf,
>>
>> In message
>> you
>> wrote:
>>>
>>> > When PPC was building again, I tested it on ARM (which I assumed was
>>> > OK, given that this was Anton's primary arch
Dear Anton Staaf,
In message
you wrote:
>
> Would you be OK with a build warning for the lack of definition of
> CONFIG_SYS_CACHELINE_SIZE like I have now if it only happened
> once per board? ...
Yes, that would be great.
> ... I could move it from common.h to a c file that is al
On Thu, Oct 13, 2011 at 1:03 PM, Wolfgang Denk wrote:
> Dear Anton Staaf,
>
> In message
> you
> wrote:
>>
>> Would you be OK with a build warning for the lack of definition of
>> CONFIG_SYS_CACHELINE_SIZE like I have now if it only happened
>> once per board? ...
>
> Yes, that would be great.
Dear Anton Staaf,
In message
you wrote:
>
> Turns out I was able to define ARCH_DMA_MINALIGN for all U-Boot
> architectures and use that
> instead of the actual cache line size to generate correctly aligned
> buffers. My latest
> patch set implements this. So we shouldn't have any warnings bei
On Thursday 13 October 2011 16:03:37 Wolfgang Denk wrote:
> Anton Staaf wrote:
> > ... I could move it from common.h to a c file that is always
> >
> > built. Perhaps I could add a checks.c file to libgeneric? I'm not
> > really sure if that's the right place for it. Do you have a
On Thu, Oct 13, 2011 at 1:31 PM, Wolfgang Denk wrote:
> Dear Anton Staaf,
>
> In message
> you
> wrote:
>>
>> Turns out I was able to define ARCH_DMA_MINALIGN for all U-Boot
>> architectures and use that
>> instead of the actual cache line size to generate correctly aligned
>> buffers. My late
On Thu, Oct 13, 2011 at 1:36 PM, Mike Frysinger wrote:
> On Thursday 13 October 2011 16:03:37 Wolfgang Denk wrote:
>> Anton Staaf wrote:
>> > ... I could move it from common.h to a c file that is always
>> >
>> > built. Perhaps I could add a checks.c file to libgeneric? I'm not
>> >
Dear Anton Staaf,
In message
you wrote:
>
> I believe it is correct yes. But it would be good to have each
> architecture custodian
> weigh in on the architectures I couldn't test directly. Also, Mike
> has submitted a
> patch that adds the asm/cache.h file for blackfin from the Linux
> kernel
Hi Mike,
On 09.10.2011 19:56, Mike Frysinger wrote:
>> arm926ejs doesn't have {invalidate,flush}_dcache_range(), so we have to
>> add this not to break the driver on DaVinci boards (maybe we need to add
>> empty cache functions on arm926ejs instead?)
>
> if the prototype is in include/common.h, t
Hi Stefano,
On 10.10.2011 17:17, Stefano Babic wrote:
>>> Should we not be sure that size is rounded up to align with the cache
>>> line size ?
>>
>> Surely we should. Actually it's not the size that has to be aligned but
>> the buffer itself. Is there any generic API to get the cache line size?
>
25 matches
Mail list logo
