[parisc-linux] Re: CCIO dma io_command and related io_tlb format questions.

[Joel Soete]

Grant Grundler wrote:
> On Fri, Oct 13, 2006 at 10:56:50AM +0000, Joel Soete wrote:
>>
>> 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,
> 
> A correct answer here would be "question" or "statement".
> Maybe you want to restate the question so it really looks like
> a question.
> 
Appologie, my hands didn't follow my mind but you well undertood I would mean "yes a question" ;-)

>>> 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)
> 
> I think so but am not sure either.
> 
>>> Off hand, I'm not sure. It's probably related though.
> 
> Actually, it seems that the number of TLB entries is hardcoded
> in the _MASK. ie 256 TLB entries:
> 
> 	/* Uturn supports 256 TLB entries */
> 	#define CCIO_CHAINID_SHIFT      8
> 	#define CCIO_CHAINID_MASK       0xff
> 
> The "if 0" block above that suggests someone was expecting
> the number of TLB entries to be different for different chips.
> However, U2 and Uturn both seem to only support 256 entries.
> 
ok,

> 
>>> 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?
> 
> Yes. important is "should be". It doesn't have to be.
> 
Well for a non-programmer as I am, it's always very hard to understand what another want to do, specialy without doc neither 
on the hw (ccio) nor on the technic it applied (I didn't found any relevant info on sg list management on the web). But 
thanks to your comments/advise, I started a better understanding and hope will make more progress.

>>> Ah. chainid could have more to do with the number of TLB entries than
>>> the size of the pages. I'm not certain though.
> 
> I think the width of chainid_mask describes the number of TLB entries.
> chainid_shift probably describes the IO TLB "page size".
> 
> And reading the comments in the code help too:
>         ** Chainid is the upper most bits of an IOVP used to determine
>         ** which TLB entry an IOVP will use.
> 
ok,

> 
>> 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 ;-)
> 
> Ok. But if there are problems only for SCSI and not for 100BT,
(the 'core io' nic I use the most is only 10BT for c110 and d380,
  I need to check more about additional 100bt nic)

> then it's either a SCSI driver problem or the ccio_map_sg() support
> is broken
but yes that's the primary question and:
	* I encountered pbs with ncr53c720 and core io ncr53c710
	 (different pb with each hba but same one-to-one on d380 and c110),
	* but no pb with same disk (and its scsi chain: cable + terminator) with ncr53c710 (behind dino) on a b180,
so
	* no hw pb with disk,
	* no sw pb with nc53c710 Jame's driver,
	 (even thought less sure, as make me noticed Mike:
		on b180, 53c710 is behind dino i.e. gsc pci bus bridge, right?
		on c110 and d380, this 53c710 is behind LASI (afaik just a vlsi assembly and no bus bridge)
		so could be also a pb with 53c710 when married with gsc?)
	* most probably the pb is well in sg list management in ccio (afaik not used by dino)

  (handles coalescing of blocks - disable coalescing
> to test this out). 
> 
I will try (I didn't yet reach this point: because common with sba where it's not a pb)

Otoh with n4k 64bit smp kernel and sym53c8xx_2:
<http://lists.parisc-linux.org/pipermail/parisc-linux/2006-September/030194.html>
I encountered fs pb similar with ncr53c720 and not with up kernel (on n4k, on c110 and d380 I just spook about up kernel), I 
so worried also a pb of coherency?

Thanks for your attention,
	Joel


> grant
> 
>