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: Sat, 21 Oct 2006 17:17:46 +0000	[thread overview]
Message-ID: <453A563A.9050704@scarlet.be> (raw)
In-Reply-To: <20061021061944.GA24732@colo.lackof.org>



Grant Grundler wrote:
> On Fri, Oct 20, 2006 at 05:18:28PM +0000, Joel Soete wrote:
>>>>> chainid_mask 0xfff80000
>>> This second chainid_mask is 13 bits wide.
>> mmm sorry how do you compute this wide value?
> 
> Count the number of contiguous bits set to 1.
> bit 31 to bit 19 is 13 bits.
> 
Ah thanks (one more stuff in my dico ;-) )

>> Btw I just discover an interesting comment in rope.h
>>> /*
>>> ** IOC supports 4/8/16/64KB page sizes (see TCNFG register)
>>> ** It's safer (avoid memory corruption) to keep DMA page mappings
>>> ** equivalently sized to VM PAGE_SIZE.
>>> **
>> [snip]
>>> **
>>> ** PAGE_SIZE could be greater than IOVP_SIZE. But not the inverse.
>>> */
>> and specialy:
>>> ** It's safer (avoid memory corruption) to keep DMA page mappings
>>> ** equivalently sized to VM PAGE_SIZE.
>> which was related to the original question I didn't reach to explain better.
> 
> The "avoid memory corruption" refers to the fact the we are likely
> to map *more* address space than the device actually will DMA to.
> If the device is doing DMA to 4K and we map 64k, than means there
> is 60k more DMA address space the device can write to than it needs
> permission to.
Exactely my understanding ...

> The trade-off is between efficiency in creating
> DMA mappings (reducing the number of mappings) and how much
> address space we actually use.
>
... too ;-)

>> So even if I don't understand why, we have to limits the number of iotlb 
>> entries to 256 (without doc I just accept it).
> 
> No. The number of IO TLB entries is implemented in HW.
> The SW (e.g. ccio) only controls the number IO Pdir entries and
> thus the total amount to DMA that can be mapped at the one time.
> 
> The size of a page (as seen from IO) is just much simpler to manage
> when it's the same size of a page as seen by the CPU.
> I need a really good reason to make things more complex.
> And in this case I don't have a reason. I just want to enable
> someone else to experiment if they have time or reason to do so.
> 
I didn't mean to make more complex?

But the confusion may be came that I took a comment in sba code to explain somthing which weems to me strange in ccio code?

Or my english is to bad or I missed the meaning of this hunk:

	iova_space_size = (num_physpages << PAGE_SHIFT) / count_parisc_driver(&ccio_driver)

   means simply that we equaly balance all my ram between ioc then
   [in my config 256MB / 2 ccio bc == 128MB]

	(assuming it >= 1MB and < then 1GB)

	iov_order = get_order(iova_space_size << PAGE_SHIFT);

         /* iova_space_size is now bytes, not pages */
         iova_space_size = 1 << (iov_order + PAGE_SHIFT);

   we compute just a new value so that  "iova space is log2() in size."
   [in my config 128MB]

   then we compute a pdir_size, reserve pdir_base and the same for res_size and res_map according to IOVP_SIZE.

   and finaly what I certainly missunderstand:

	ioc->chainid_shift = get_order(iova_space_size) + PAGE_SHIFT - CCIO_CHAINID_SHIFT;

   i.e. if I translate in terms of power 2:
	chain_size = iova_space_size / 256 [ in my config 128Mb / 256 = 512k]

   and my understanding of seting io_chain_id_mask = CCIO_MASK << chainid_shift
   was to configure ccio to use chain_size page size (and not IOVP_SIZE because it would resulting to much io tlb entry)?

   what seems to be confirmed elsewhere by:

> static CCIO_INLINE void
> ccio_clear_io_tlb(struct ioc *ioc, dma_addr_t iovp, size_t byte_cnt)
> {
>         u32 chain_size = 1 << ioc->chainid_shift;
> 
>         iovp &= IOVP_MASK;      /* clear offset bits, just want pagenum */
>         byte_cnt += chain_size;
> 
>         while(byte_cnt > chain_size) {
>                 WRITE_U32(CMD_TLB_PURGE | iovp, &ioc->ioc_regs->io_command);
>                 iovp += chain_size;
>                 byte_cnt -= chain_size;
>         }
> }

and nowhere else chainid_shift is used in sg list managment, only IOVP_[SHIFT,SIZE].

so either somewhere I learn sg manager that actual iovp became 512k (but seems to be break 2 sba advises: iovp_shift > 
PAGE_SIZE, DMA page mappings not equivalently sized to VM PAGE_SIZE)
or i save IOVP_SIZE (my preference) but recompute iova_space_size and all related values to setup ccio?

Or I just have to wait public ccio doc to better understand how this hw works ;-)

Thanks for your patience,
	Joel

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

  reply	other threads:[~2006-10-21 17:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-11  8:48 [parisc-linux] Re: CCIO dma io_command and related io_tlb format questions 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 [this message]
2006-10-23  4:34             ` 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
     [not found] <J70JNP$255156D3B4F90827118C5EFE40FD3ABF@scarlet.be>
2006-10-12 19:55 ` Grant Grundler
2006-10-13 10:56   ` Joel Soete
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
  -- 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=453A563A.9050704@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.