All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Dan Malek <dan@embeddededge.com>
Cc: linux-ppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: Re: [PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries
Date: Fri, 6 May 2005 10:38:58 -0300	[thread overview]
Message-ID: <20050506133858.GA6032@logos.cnet> (raw)
In-Reply-To: <1b2c7da800815bcdd76ddf27a2ab9c55@embeddededge.com>


> >The following patch changes "mmu_mapin_ram" (hook used by mapin_ram), 
> >to
> >begin creation of pagetables after the first 8Megs, preserving the
> >8Mbyte TLB entry.
> 
> Please don't do this.  It isn't necessary.

Why it is not necessary? 

Have you read the section of the manual which I pasted here? 

> >This changes the assumption that DMA allocations can start at the first
> >kernel address, given that those need to be marked uncached due to DMA
> >cache coherency issues.
> 
> VM space for uncached DMA has always been allocated using vmalloc(),
> the location of the physical pages backing this space is irrelevant.    
>
> The only thing you have to ensure is the virtual address is outside 
> of the pinned entry.  

What you replied to is:

"This changes the assumption that DMA allocations can start at the first
kernel address, given that those need to be marked uncached due to DMA
cache coherency issues." 

I think we mean the same, yes? 

> If something about the way the VM space is structured in 2.6 is
> different, we need to fix that in general. 

>
> >Panto: FEC currently does
> >
> >        mem_addr = __get_free_page(GFP_KERNEL);
> >        cbd_base = (cbd_t *)mem_addr;
> 
> This is just plain broken and it shouldn't do this.
> 
> >We are still using v2.4 FEC driver, so this fixed it:
> >
> >//      mem_addr = __get_free_page(GFP_KERNEL);
> >        mem_addr = dma_alloc_coherent(NULL, PAGE_SIZE, &physaddr,
> >                        GFP_KERNEL);
> 
> This is the proper way, and should be moved to the equivalent in 2.6.
> 
> >Allocateing from the coherent memory DMA region. Which sits at, I 
> >suppose,
> >after initial 8Megs in all configurations (should be always).
> 
> You are making this too complicated :-)  All we have to do is use the
> proper dma allocators and make sure the TLBs are pinned properly.
> That is all.

Sorry, but, what is too complicated? 

The patch I sent does two things (pretty much the same thing you suggest 
after stating that its "too complicated", AFAICS):

1) avoids the creation of pte tables in the 8Mbyte range, thus preserving
the pinned TLB entry.
2) restricts bootmem to above 8Mbyte region

And last thing is: 

3) Memory for DMA pages must not be in the pinned region. ie. drivers 
should not allocate memory directly for DMA purposes.

Dan, I would really enjoy having access to some of your precious 8xx
knowledge: share it, along with the correct way to fix this and the 
other pending issues.

  reply	other threads:[~2005-05-06 18:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-05 17:20 [PATCH] 8xx: fix usage of pinned 8Mbyte TLB entries Marcelo Tosatti
2005-05-06 13:04 ` Jason McMullan
2005-05-06 11:39   ` Marcelo Tosatti
2005-05-06 16:43 ` Dan Malek
2005-05-06 13:38   ` Marcelo Tosatti [this message]
2005-05-06 22:49     ` Dan Malek
2005-05-06 20:03       ` Marcelo Tosatti
2005-05-07  3:09         ` Dan Malek
2005-05-06 23:05           ` Marcelo Tosatti
2005-05-07  4:39             ` Dan Malek
2005-05-07  5:16               ` Dan Malek
2005-05-07 13:16               ` Marcelo Tosatti
2005-05-07 20:02                 ` Dan Malek
2005-05-07 15:47                   ` Marcelo Tosatti
2005-05-07 14:05               ` Marcelo Tosatti
2005-05-09  6:09                 ` Pantelis Antoniou
2005-05-07 14:59             ` Wolfgang Denk
2005-05-07  5:27         ` Dan Malek
2005-05-07  5:55           ` Dan Malek
2005-05-06 23:10       ` Dan Malek

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=20050506133858.GA6032@logos.cnet \
    --to=marcelo.tosatti@cyclades.com \
    --cc=dan@embeddededge.com \
    --cc=linuxppc-embedded@ozlabs.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 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.