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

[Joel Soete]

Hello Grant,

Grant Grundler wrote:
> On Wed, Oct 11, 2006 at 10:48:56AM +0200, Joel Soete wrote:
>>>> That said, there are no public doc of this IO stuff
>>> There is none for CCIO. And I no longer have access to those
>>> documents (deleted them from my laptop/workstations).
>>> You'd need access to U2/Uturn ERS via OSDL.
>> Any links (I looking for in http://ftp.parisc-linux.org/docs/chips and more
>> google search but no success?)
> 
> No links. OSDL has been talking with HP about NDA access to specific
> HP docs for OSDL developers. CCIO docs could be added to that
> list of docs if it exists anywhere. I believe PA8800 ERS was
> a targeted document as well (for example).
> 
> 
>>>>       a io (page size) address as seems to say the value
>>>>      ("CMD_TLB_PURGE | iovp") in ccio_clear_io_tlb()
>>> Offhand I'm not sure of the exact split but guess it's
>>> lower 12 bits for command and upper 20 bits for IO Virtual Page
>>> as used in ccio_clear_io_tlb().
>>>
>> mmm could it be the pb: the computed chainid_shift on my d380 is 19 (decimal)?
>>
Grr forget to check, ...

>> btw what's about the IOV page size used by sba (IOVP_SIZE i.e. PAGE_SIZE till
>> now?)
> 
> sba and ccio are similar but not identical.
> The intent for variable page sizes in SBA is so it can match
> whatever page size the kernel is using.
> 
mmm offhand wasn't there limits in ccio page size like in ia64 sba comments:
> /*
> ** The zx1 IOC supports 4/8/16/64KB page sizes (see TCNFG register)
[snip]

[snip]

> 
>> btw what is correct for you in this setup:
>> WRITE_U32(CCIO_CHAINID_MASK << ioc->chainid_shift,
>> &ioc->ioc_regs->io_chain_id_mask);
>>
>> the name variable seems to said it should contains the mask correcponding to
>> the chainid_shift i.e. imho:
>> let say CHAINID_SIZE = (1UL << ioc->chainid_shift) and so
>> &ioc->ioc_regs->io_chain_id_mask = (~(CHAINID_SIZE -1))
> 
> Uhm....sounds reasonable to me. All I know is I believe the existing
> code use of chain_id is correct.
> 
Just come back here shortly: the computed values with my hw config (256Mb and 2 ccio) are
 > Found U2 at 0xfff88000
 > ccio_ioc_init() hpa 0x00008000 mem 256Mb IOV 128Mb (27 bits)
 >  base 10740000
 > ccio_ioc_init() res_size 0x1000
 >  chainid_shift 0x13
 >  chainid_mask 0x7f80000
 > Found U2 at 0xfff8a000
 > ccio_ioc_init() hpa 0x0000a000 mem 256Mb IOV 128Mb (27 bits)
 >  base 10780000
 > ccio_ioc_init() res_size 0x1000
 >  chainid_shift 0x13
 >  chainid_mask 0x7f80000

otoh, applying this other formula [io_chain_id_mask = (~(CHAINID_SIZE -1)); with CHAINID_SIZE = (1UL << 
ioc->chainid_shift)], I got:
 >  chainid_mask 0xfff80000
 >
well I tried the two: if it doen't show breackage against ncr53c720, it doen't show any progress against ncr53c710?

(to be continue ;-) )
Joel

PS: I was hoping that #undefine CCIO_SEARCH_TIME would help according to sba comment:
 > #ifdef CONFIG_PROC_FS
 > /* depends on proc fs support. But costs CPU performance */
 > #undef SBA_COLLECT_STATS
 > #endif
but test against ncr53c710 are even worse as it didn't reach to complete one tar/rm loop.
(this test make me fill like a pb of coherency some where, what do you think?)

PS2: about your oder comment:
>> 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,
> then it's either a SCSI driver problem or the ccio_map_sg() support
> is broken (handles coalescing of blocks - disable coalescing
> to test this out). 
> 
> grant
> 
> 
I found those 2 related call:
>         /*
>         ** First coalesce the chunks and allocate I/O pdir space
>         **
>         ** If this is one DMA stream, we can properly map using the
>         ** correct virtual address associated with each DMA page.
>         ** w/o this association, we wouldn't have coherent DMA!
>         ** Access to the virtual address is what forces a two pass algorithm.
>         */
>         coalesced = iommu_coalesce_chunks(ioc, sglist, nents, ccio_alloc_range);
> 
>         /*
>         ** Program the I/O Pdir
>         **
>         ** map the virtual addresses to the I/O Pdir
>         ** o dma_address will contain the pdir index
>         ** o dma_len will contain the number of bytes to map
>         ** o page/offset contain the virtual address.
>         */
>         filled = iommu_fill_pdir(ioc, sglist, nents, hint, ccio_io_pdir_entry);
> 
removing the first only (iommu_coalesce_chunks()) showed me a panic in the second (iommu_fill_pdir()):
>                 BUG_ON(pdirp == NULL);
> 
but I couldn't remove the call to iommu_fill_pdir(): filled being the return value to:
> static int
> ccio_map_sg(struct device *dev, struct scatterlist *sglist, int nents,
>             enum dma_data_direction direction)
> {
[snip]
> 
>         return filled;
> }

So I don't understand how may I try to "disable coalescing", any idea?