All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Soete <soete.joel@scarlet.be>
To: Grant Grundler <grundler@parisc-linux.org>
Cc: parisc-linux <parisc-linux@parisc-linux.org>
Subject: [parisc-linux] Re: CCIO dma io_command and related io_tlb format questions.
Date: Fri, 13 Oct 2006 10:56:50 +0000	[thread overview]
Message-ID: <452F70F2.4020700@scarlet.be> (raw)
In-Reply-To: <20061012195503.GA15124@colo.lackof.org>



Grant Grundler wrote:
> On Thu, Oct 12, 2006 at 10:02:13AM +0200, Joel Soete wrote:
> ...
>> well according to the choice of a PAGE_SIZE, a IOVP_SIZE and the actual system
>> ramsize (imho badly named num_physpages?), you can setup the sba?
> 
> Is that a question or a statement?
yes,
> PAGE_SIZE is a compile time option.
as well as IOVP_SIZE.

I would just like to be sure, even if it's not translated the same way in C code, that the ccio statement:
	WRITE_U32(CCIO_CHAINID_MASK << ioc->chainid_shift,
                   &ioc->ioc_regs->io_chain_id_mask);

do the same job as sba statement:
         WRITE_REG(ioc->imask, ioc->ioc_hpa+IOC_IMASK);

i.e. seting up the ioc register containing the mask corresponding (one-to-one mapping) to the size of a ioc physical page; 
and by the means of this mask we set up inderectly the physical page size the ioc (respectilvely ccio and sba) will use to work?
(just my guessing because no docs)

> PA2.0 CPUs support sizes other than 4k.
> And I think it was Helge that started on enabling bigger
> page sizes but it's not working yet.
> 
Yes what I remember too

> ...
>> (is it only the number of io tlb entries?)
> 
> Off hand, I'm not sure. It's probably related though.
> 
>> My thought was very basic: imho vitualising actual adresses pages would just
>> be translation of adresses but the virtual page size should be the same as the
>> actual one?
> 
> "actual one"?
yes my mind is very ground basic and only what is 'physical' is actual to me (well near about, I never made the travel of an 
electron to verify the cut-up of the ram but as far as it behaves like foreseen I just have to accept it ;-) )

> We have RAM. The CPU TLB that organizes RAM into "pages" as the
> minimum granularity that the kernel manages permissions and use of RAM.
> The IO TLB doesn't have to use the same granularity as the kernel
> though it's easier (and probably faster in general) to do so.
> 
Ok so rephrasing the question: the ioc physical page size should be the same as the virtual page size managed by the related 
sg list driver?

> 
>> (and btw the ccio bc using actual pages'size in accordance with computed
>> chainid_shift (different then IOVP_SHIFT), ccio_[map, unmap]_single should
>> also use chainid_shift to compute chainid_size and chainid_mask to manage sg
>> list?)
> 
> Ah. chainid could have more to do with the number of TLB entries than
> the size of the pages. I'm not certain though.
> 
> grant
> 
> 
PS: those investigations to atempt to fix c110/d380 fs pb make me discover that this d380 have in fact 2 U2/UTurn (as well 
dicovered by linux kernel). But one this is specialy design to server only one hsc (aka gsc) io slot tagged TURBO ;-)

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

  reply	other threads:[~2006-10-13 10:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <J70JNP$255156D3B4F90827118C5EFE40FD3ABF@scarlet.be>
2006-10-12 19:55 ` [parisc-linux] Re: CCIO dma io_command and related io_tlb format questions Grant Grundler
2006-10-13 10:56   ` Joel Soete [this message]
2006-10-13 16:44     ` Grant Grundler
     [not found]       ` <4530DF1F.5060601@scarlet.be>
2006-10-14 14:11         ` Matthew Wilcox
2006-10-14 16:40           ` Michael S. Zick
2006-10-14 23:35           ` Joel Soete
2006-10-15  3:28             ` Grant Grundler
     [not found] <J7AHPO$ED967CCDD9E203D6968EA2045C11A08A@scarlet.be>
     [not found] ` <45351637.4070604@computer.org>
2006-10-17 19:07   ` Kyle McMartin
     [not found] <J788XR$E1A2FE043CF88207AEC13412E82258F2@scarlet.be>
2006-10-16 14:37 ` Michael S. Zick
2006-10-17  5:59 ` Grant Grundler
2006-10-11  8:48 Joel Soete
2006-10-12  1:04 ` Grant Grundler
2006-10-12  3:27   ` James Bottomley
     [not found]   ` <4538BB5F.5040703@scarlet.be>
2006-10-20 15:50     ` Grant Grundler
2006-10-20 16:31       ` Grant Grundler
2006-10-20 17:18       ` Joel Soete
2006-10-21  6:19         ` Grant Grundler
2006-10-21 17:17           ` Joel Soete
2006-10-23  4:34             ` Grant Grundler
  -- strict thread matches above, loose matches on Subject: below --
2006-10-09  9:41 [parisc-linux] " Joel Soete
2006-10-10 22:08 ` [parisc-linux] " Grant Grundler

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=452F70F2.4020700@scarlet.be \
    --to=soete.joel@scarlet.be \
    --cc=grundler@parisc-linux.org \
    --cc=parisc-linux@parisc-linux.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.