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

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

[Grant Grundler]

On Mon, Oct 09, 2006 at 11:41:11AM +0200, Joel Soete wrote:
> Hello Grant,
> 
> I back port the sba sg list manager in ccio-dma on my d380 (not enough time to
> test c110).
...

Sounds like you have some debugging to do still...I'll try to
answer the questions below.

> 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.


> and so I didn't change those 2 hunks:
> [snip]
> static CCIO_INLINE void
> ccio_clear_io_tlb(struct ioc *ioc, dma_addr_t iovp, size_t byte_cnt)
...
> ccio_ioc_init(struct ioc *ioc)
...
> About which cames to me 2 questions:
>    1/ what is supposed to contain an io_tlb entry:

You want to know the layout of the "ioc_command" register.
It is a combination of iovp and command.


>       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().

>       or a memory page size should be splited in
>       severall tlb entries per ioc->chainid_shift?

ccio_ioc_init is just clearing the entire IO TLB.
We know there are only "1<<CCIO_CHAINID_SHIFT" IO TLB entries.
See comments above where CCIO_CHAINID_SHIFT is defined.
ccio_clear_io_tlb() is just purging all of them.

>    2/ what is supposed to contain the ccio io_command register, I mean that
>       I don't understand what seems to me to be different io_command
>       contents for CMD_TLB_DIRECT_WRITE or CMD_TLB_PURGE?

Generally we only need to use CMD_TLB_PURGE to avoid use of stale entries.
You shouldn't need to change the uses of CMD_TLB_DIRECT_WRITE.

> If you still have (or access to) this internal doc, it would be great if you
> could find some time to explain me those stuff.

Sorry - I don't.

Hope that helps,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

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

[Joel Soete]

> On Mon, Oct 09, 2006 at 11:41:11AM +0200, Joel Soete wrote:
> > Hello Grant,
> > 
> > I back port the sba sg list manager in ccio-dma on my d380 (not enoug=
h time to
> > test c110).
> ...
> 
> Sounds like you have some debugging to do still...
(why I mentioned progress and failures ;-) )

> I'll try to
> answer the questions below.
> 
> > 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).
too bad ;_(

> You'd need access to U2/Uturn ERS via OSDL.
> 
Any links (I looking for in http://ftp.parisc-linux.org/docs/chips and mo=
re
google search but no success?)

> 
> > and so I didn't change those 2 hunks:
> > [snip]
> > static CCIO_INLINE void
> > ccio_clear_io_tlb(struct ioc *ioc, dma_addr_t iovp, size_t byte_cnt)
> ...
> > ccio_ioc_init(struct ioc *ioc)
> ...
> > About which cames to me 2 questions:
> >    1/ what is supposed to contain an io_tlb entry:
> 
> You want to know the layout of the "ioc_command" register.
> It is a combination of iovp and command.
> 
> 
> >       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 (deci=
mal)?

btw what's about the IOV page size used by sba (IOVP_SIZE i.e. PAGE_SIZE =
till
now?)

The question for ccio is: why using chainid_shift (by set io_chain_id_mas=
k)
different then IOVP_SHIFT, as ,as far as I understand, we manage only
IPVP_SIZE page? (imho couls be what means "FIXME: Can we change byte_cnt =
to
pages_mappged" of ccio_mark_invalid?)

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 =3D (1UL << ioc->chainid_shift) and so
&ioc->ioc_regs->io_chain_id_mask =3D (~(CHAINID_SIZE -1))



> >       or a memory page size should be splited in
> >       severall tlb entries per ioc->chainid_shift?
> 
> ccio_ioc_init is just clearing the entire IO TLB.
> We know there are only "1<<CCIO_CHAINID_SHIFT" IO TLB entries.
> See comments above where CCIO_CHAINID_SHIFT is defined.
> ccio_clear_io_tlb() is just purging all of them.
> 
ok.

Ah btw there wasn't any 'flush purges' action o do with ccio like in sba =
or
only to be managed with fdc/sync?

> >    2/ what is supposed to contain the ccio io_command register, I mea=
n that
> >       I don't understand what seems to me to be different io_command
> >       contents for CMD_TLB_DIRECT_WRITE or CMD_TLB_PURGE?
> 
> Generally we only need to use CMD_TLB_PURGE to avoid use of stale entri=
es.
no pb to understand it.

> You shouldn't need to change the uses of CMD_TLB_DIRECT_WRITE.
> 
but here it's a bit confusing: we are at the kernel startup and just init=
 the
ccio so afaik nothing yet in ccio tlb or at least we don't know what it
contains and we are writing this CMD_TLB_DIRECT_WRITE for this iov page
address (i << chainid_shift) for i =3D 1 to 256 (the 256 Uturn tlb entrie=
s).

That said (without doc), I wouldn't touch to this loop.

> > If you still have (or access to) this internal doc, it would be great=
 if you
> > could find some time to explain me those stuff.
> 
> Sorry - I don't.
> 
No pb, that already helpfull.

May be a last q.

in your code comment you spoke about spa_shift but I didn't find it anywh=
ere
else (neither in the code nor in iodc doc), any idea which symbol is rela=
ted to?

> Hope that helps,

Yes, thanks a lot,
   Joel
> grant
> 
> =0A=0A----------=0AClub Scarlet : Tout le monde gagne! Si vous devenez =
aujourd'hui Scarlet One grace a un client existant de Scarlet, vous recev=
ez tous les deux un cadeau d'une valeur de 50 euros! Surfez vite sur http=
://www.clubscarlet.be

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

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

[Grant Grundler]

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)?
> 
> 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.


> The question for ccio is: why using chainid_shift (by set io_chain_id_mask)
> different then IOVP_SHIFT, as ,as far as I understand, we manage only
> IPVP_SIZE page? (imho couls be what means "FIXME: Can we change byte_cnt to
> pages_mappged" of ccio_mark_invalid?)

Maybe look at how chainid_shift is initialized and that will make sense.
I'm not sure I understand your question otherwise.

> 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.

> Ah btw there wasn't any 'flush purges' action o do with ccio like in sba or
> only to be managed with fdc/sync?

No. Purging IO TLB entries is not like changing the IO Pdir entries.
Related but seperate activities.

> > You shouldn't need to change the uses of CMD_TLB_DIRECT_WRITE.
>
> but here it's a bit confusing: we are at the kernel startup and just init the
> ccio so afaik nothing yet in ccio tlb or at least we don't know what it
> contains

Exactly. We don't know what it contains. This makes sure we know.

>  and we are writing this CMD_TLB_DIRECT_WRITE for this iov page
> address (i << chainid_shift) for i = 1 to 256 (the 256 Uturn tlb entries).
> 
> That said (without doc), I wouldn't touch to this loop.

Good. :)

> May be a last q.

Maybe? :)

> in your code comment you spoke about spa_shift but I didn't find it anywhere
> else (neither in the code nor in iodc doc), any idea which symbol is related to?

It's obviously a stale comment and you might look at versions of the CCIO code
in the 2.4 source tree to find it.

I suspect it's chain_id_shift but am not sure.

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

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

[James Bottomley]

On Wed, 2006-10-11 at 19:04 -0600, Grant Grundler wrote:
> 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).

Actually, not just OSDL developers.  The OSDL NDA programme is designed
oto manage general spec access for specific lists of developers who may
or may not be associated with OSDL.

Unfortunately, the HP programme is on hold pending the resolution of
external legal issues.

James


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

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

[Grant Grundler]

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?
PAGE_SIZE is a compile time option.
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.

...
> (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"?
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.


> (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
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

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

[Joel Soete]

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

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

[Grant Grundler]

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.

> >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.


> >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.

> >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.


> 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
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

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

[Matthew Wilcox]

On Sat, Oct 14, 2006 at 12:59:11PM +0000, Joel Soete wrote:
> 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?)

You should never listen to Zick.  53c710 is always part of Lasi on PA
machines.  There's a discrete 53c700 on pre-Lasi machines.  There is
never a 53c710 behind Dino.  Dino has a serial port, a ps/2 port, and a
pci host bridge.

> 	* most probably the pb is well in sg list management in ccio (afaik 
> 	not used by dino)

Wrong.  sg list management is used by PCI devices behind Dino as well as
by GSC devices.

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

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

[Michael S. Zick]

On Sat October 14 2006 09:11, Matthew Wilcox wrote:
> On Sat, Oct 14, 2006 at 12:59:11PM +0000, Joel Soete wrote:
> > 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?)
> 
> You should never listen to Zick.  

More from the least trusted source of information:

The C710 designed into the LASI chip operates from a fixed frequency
clock of 40Mhz.

Ref:
http://www.hpl.hp.com/hpjournal/95apr/apr95a4.pdf
Page: 3, Section: Phase-Locked Loop Clock Generators, Paragraph: 1

All K-class systems have at least 1 HP-HSC bus, it runs at 32Mhz.
In addition the K-400 and K-410 may have an additional HP-HSC bus
which runs at 40Mhz.

Ref:
http://www.hpl.hp.com/hpjournal/96feb/feb96a1.pdf
Page: 6, Section: I/O Expansion, Paragraph: 1

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

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

[Joel Soete]

Matthew Wilcox wrote:
> On Sat, Oct 14, 2006 at 12:59:11PM +0000, Joel Soete wrote:
>> 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?)
> 
> You should never listen to Zick.
Don't blame Mike, it's my mistake I would have to check my ioscan before mentioned this hypothesis
(Appologie Mike)

   53c710 is always part of Lasi on PA
> machines.  There's a discrete 53c700 on pre-Lasi machines.  There is
> never a 53c710 behind Dino.  Dino has a serial port, a ps/2 port, and a
> pci host bridge.
> 
ok my bad.

>> 	* most probably the pb is well in sg list management in ccio (afaik 
>> 	not used by dino)
> 
> Wrong.  sg list management is used by PCI devices behind Dino as well as
> by GSC devices.
> 
Yes and no: there is a big diff between b180 and c110/d380 arch about connectic between cpu and lasi in particular:
on b180 ioscan tel me (grab from hw db):

> :pa:F:F:F:-1:-1:4294967295:bc:root:::0:root:root:CLAIMED:BUS_NEXUS::0
> pa:pa:F:F:F:-1:-1:4294967295:bc:bus_converter:8:80 64 0 7 0 0 0 0 0 0 0 0 0 0 0 0 :1:root.bc:bc:CLAIMED:BUS_NEXUS:Pseudo Bus Converter:1
[snip]
> pa:core:F:F:F:-1:-1:4294967295:ba:core_adapter:8/16:3 240 128 75 0 0 129 0 0 0 0 0 0 0 0 0 :1:root.bc.bus_adapter:bus_adapter:CLAIMED:BUS_NEXUS:Core I/O Adapter:1
> core:wsio:F:T:F:-1:216:131072:ext_bus:CentIf:8/16/0:3 240 128 10 0 0 116 0 0 0 0 0 0 0 0 0 :2:root.bc.bus_adapter.CentIf:CentIf:CLAIMED:INTERFACE:Built-in Parallel Interface:2
> core:wsio:F:T:F:-1:66:0:audio:audio:8/16/1:3 244 128 10 0 0 123 0 0 0 0 0 0 0 0 0 :0:root.bc.bus_adapter.audio:audio:CLAIMED:INTERFACE:Built-in Audio:0
> core:wsio:F:T:F:-1:1:0:tty:asio0:8/16/4:3 240 0 138 0 0 140 0 1 0 0 0 99 9 0 2 :0:root.bc.bus_adapter.asio0:asio0:CLAIMED:INTERFACE:Built-in RS-232C:0
> core:wsio:F:F:F:0:0:65536:ext_bus:c720:8/16/5:3 240 128 138 0 0 130 0 153 0 1 0 77 65 0 2 :1:root.bc.bus_adapter.c720:c720:CLAIMED:INTERFACE:Built-in SCSI:1
> scsi:wsio:F:F:F:-1:-1:4294967295:target:tgt:8/16/5.7:0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 :2:root.bc.bus_adapter.c720.tgt:tgt:CLAIMED:DEVICE::1
> scsi:wsio:F:T:F:-1:203:94208:ctl:sctl:8/16/5.7.0:0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 :1:root.bc.bus_adapter.c720.tgt.sctl:sctl:CLAIMED:DEVICE:Initiator:1
> core:wsio:F:T:F:-1:159:0:ps2:ps2:8/16/7:3 240 0 138 0 0 132 0 0 0 0 0 110 5 0 2 :0:root.bc.bus_adapter.ps2:ps2:CLAIMED:INTERFACE:Built-in Keyboard/Mouse:0
> pa:wsio:F:F:F:-1:229:4294967295:graphics:graph3:8/24:1 96 0 138 0 0 133 0 1 0 0 0 104 38 0 2 :1:root.bc.graph3:graph3:CLAIMED:INTERFACE:Graphics:1
> pa:pa:F:F:F:-1:-1:4294967295:processor:processor:62:80 64 0 64 0 0 4 129 0 0 0 0 0 0 0 0 :0:root.processor:processor:CLAIMED:PROCESSOR:Processor:0
> pa:pa:F:F:F:-1:-1:4294967295:memory:memory:63:5 160 31 65 0 0 9 0 0 0 0 0 0 0 0 0 :0:root.memory:memory:CLAIMED:MEMORY:Memory:0
> 

so the cpu and ram seems to me connected directly to the root bus.

and the "core_adapter" (I guess lasi interface) is connected to the root bus (btw to cpu) through a bc named here Pseudo Bus 
Converter.

Otoh for c110 (e.g.)

> :pa:F:F:F:-1:-1:4294967295:bc:root:::0:root:root:CLAIMED:BUS_NEXUS::0
> pa:pa:F:F:F:-1:-1:4294967295:bc:bus_converter:8:88 7 8 76 0 0 11 80 0 0 0 0 0 0 0 0 :1:root.ccio:ccio:CLAIMED:BUS_NEXUS:I/O Adapter:1
[snip]
> pa:core:F:F:F:-1:-1:4294967295:ba:core_adapter:8/16:3 32 0 139 0 0 129 0 0 0 0 0 123 85 0 0 :0:root.ccio.bus_adapter:bus_adapter:CLAIMED:BUS_NEXUS:Core I/O Adapter:0
> core:wsio:F:T:F:-1:216:131072:ext_bus:CentIf:8/16/0:3 32 0 10 0 0 116 0 0 0 0 0 0 0 0 0 :2:root.ccio.bus_adapter.CentIf:CentIf:CLAIMED:INTERFACE:Built-in Parallel Interface:2
> core:wsio:F:T:F:-1:66:0:audio:audio:8/16/1:3 32 0 10 0 0 123 0 0 0 0 0 0 0 0 0 :0:root.ccio.bus_adapter.audio:audio:CLAIMED:INTERFACE:Built-in Audio:0
> core:wsio:F:T:F:-1:1:0:tty:asio0:8/16/4:3 32 0 138 0 0 140 0 0 0 0 0 100 121 0 2 :0:root.ccio.bus_adapter.asio0:asio0:CLAIMED:INTERFACE:Built-in RS-232C:0
> core:wsio:F:F:F:0:0:65536:ext_bus:c720:8/16/5:3 32 0 138 0 0 130 0 0 0 0 0 105 39 0 2 :1:root.ccio.bus_adapter.c720:c720:CLAIMED:INTERFACE:Built-in SCSI:1
> scsi:wsio:F:F:F:-1:-1:4294967295:target:tgt:8/16/5.5:0 0 2 2 0 0 0 0 255 242 66 246 235 229 217 91 :2:root.ccio.bus_adapter.c720.tgt:tgt:CLAIMED:DEVICE::1
> scsi:wsio:T:T:F:31:188:86016:disk:sdisk:8/16/5.5.0:0 0 2 2 0 0 0 0 255 242 66 246 235 229 217 91 :3:root.ccio.bus_adapter.c720.tgt.sdisk:sdisk:CLAIMED:DEVICE:Quantum VP32210:1
> scsi:wsio:F:F:F:-1:-1:4294967295:target:tgt:8/16/5.7:0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 :3:root.ccio.bus_adapter.c720.tgt:tgt:CLAIMED:DEVICE::1
> scsi:wsio:F:T:F:-1:203:94208:ctl:sctl:8/16/5.7.0:0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 :1:root.ccio.bus_adapter.c720.tgt.sctl:sctl:CLAIMED:DEVICE:Initiator:1
> core:wsio:F:T:F:-1:52:0:lan:lan2:8/16/6:3 32 0 138 0 0 138 0 0 0 0 0 91 253 0 2 :0:root.ccio.bus_adapter.lan2:lan2:CLAIMED:INTERFACE:Built-in LAN:0
> core:wsio:F:T:F:-1:159:0:ps2:ps2:8/16/7:3 32 0 138 0 0 132 0 0 0 0 0 110 57 0 2 :0:root.ccio.bus_adapter.ps2:ps2:CLAIMED:INTERFACE:Built-in Keyboard/Mouse:0
> core:wsio:F:F:F:0:0:0:pc:fdc:8/16/10:3 32 0 10 0 0 131 0 0 0 0 0 0 0 0 0 :0:root.ccio.bus_adapter.fdc:fdc:CLAIMED:INTERFACE:Built-in Floppy Drive:0
> pa:core:F:F:F:-1:-1:4294967295:ba:core_adapter:8/20:1 224 0 11 0 0 142 0 0 0 0 0 0 0 0 0 :1:root.ccio.bus_adapter:bus_adapter:CLAIMED:BUS_NEXUS:Core I/O Adapter:1
> core:wsio:F:T:F:-1:24:0:hil:hil:8/20/1:1 224 0 138 0 0 115 0 0 0 0 0 129 124 0 2 :0:root.ccio.bus_adapter.hil:hil:CLAIMED:INTERFACE:Built-in HIL:0
> core:wsio:F:T:F:-1:1:65536:tty:asio0:8/20/2:1 224 0 138 0 0 140 128 0 0 0 0 101 57 0 2 :1:root.ccio.bus_adapter.asio0:asio0:CLAIMED:INTERFACE:Built-in RS-232C:1
> core:eisa:F:F:F:-1:-1:4294967295:ba:eisa_adapter:8/20/5:1 224 0 11 0 0 144 0 0 0 0 0 0 0 0 0 :2:root.ccio.bus_adapter.eisa:eisa:CLAIMED:BUS_NEXUS:EISA Bus Adapter:2
> core:wsio:F:F:F:-1:-1:4294967295:unknown:unknown:8/20/5/1:0 0 0 0 :0:root.ccio.bus_adapter.eisa.unknown:unknown:CLAIMED:INTERFACE:ISA card #:0
> core:wsio:F:T:F:-1:76:0:sicl:sicl:8/20/5/2:0 0 0 0 :0:root.ccio.bus_adapter.eisa.sicl:sicl:CLAIMED:INTERFACE:ISA card #:0
> pa:pa:F:F:F:-1:-1:4294967295:bc:bus_converter:10:88 7 8 76 0 0 11 80 0 0 0 0 0 0 0 0 :2:root.ccio:ccio:CLAIMED:BUS_NEXUS:I/O Adapter:2
> pa:wsio:F:F:F:-1:229:4294967295:graphics:graph3:10/16:3 32 0 138 0 0 133 0 1 0 0 0 107 5 0 2 :0:root.ccio.graph3:graph3:CLAIMED:INTERFACE:Graphics:0
> pa:pa:F:F:F:-1:-1:4294967295:processor:processor:32:88 224 0 0 0 0 4 129 0 0 0 0 0 0 0 0 :0:root.processor:processor:CLAIMED:PROCESSOR:Processor:0
> pa:pa:F:F:F:-1:-1:4294967295:memory:memory:49:4 144 26 1 0 0 9 0 0 0 0 0 0 0 0 0 :0:root.memory:memory:CLAIMED:MEMORY:Memory:0

Here again cpu and ram are also connected directly connected to the root bus.

and otc the core_adapter (I always guess that's lasi interface) is connected to the root bus through ccio bc.

So here, I guess that software reflect this hw configuration and when a lasi module driver (let say e.g. 53c710) need some 
io resources it would forward the request to ccio module driver which would most probably have to use its own sg list 
management functions (like ccio_map_single(), ccio_unmap_single(), ccio_map_sg(), ccio_unmap_sg(), etc) which I called "sg 
list management in ccio".

Otc on b180 lasi module would better have to address there request to the "Pseudo Bus Converter", i.e. quasi directly.

So why/how the kernel on b180 would use those same functions (ccio_map_single(), ccio_unmap_single(), ccio_map_sg(), 
ccio_unmap_sg(), etc) to manage sg list of a non-exitent device???

What did I miss?

Thanks,
	Joel


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

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

[Grant Grundler]

On Sat, Oct 14, 2006 at 11:35:47PM +0000, Joel Soete wrote:
...
> So here, I guess that software reflect this hw configuration and when a 
> lasi module driver (let say e.g. 53c710) need some io resources it would 
> forward the request to ccio module driver which would most probably have to 
> use its own sg list management functions (like ccio_map_single(), 
> ccio_unmap_single(), ccio_map_sg(), ccio_unmap_sg(), etc) which I called 
> "sg list management in ccio".

This is correct for C/K/D/R class machines which have U2/Uturn chip.

> Otc on b180 lasi module would better have to address there request to the 
> "Pseudo Bus Converter", i.e. quasi directly.

"Pseudo" means "fake". Ie the "Pseudo bus converter" just a place holder
in the HW path on B-class machines and not a real piece of HW.

> So why/how the kernel on b180 would use those same functions 
> (ccio_map_single(), ccio_unmap_single(), ccio_map_sg(), ccio_unmap_sg(), 
> etc) to manage sg list of a non-exitent device???

See arch/parisc/kernel/pci-dma.c for B180 DMA mapping functions.

> What did I miss?

You missed where/how dma_ops gets assigned.
Find that and I think you'll understand one more bit of the puzzle.

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

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

[Michael S. Zick]

On Mon October 16 2006 06:51, Joel Soete wrote:
>
> ====<>====
> 
> May be could we also use some define like:
> #define Mb        (1 << 20)
> #define Gb        (1 << 30)
>

Joel,
Let me add a bit (no pun intended) from the 53c7xx manuals ...

The transfer offset register is 21 bits - -

So the largest single chunk of memory 7xx can transfer is 2^21
in a single command (single list entry, if passing it lists).

There was a mention somewhere of a special use for the high bit,
I do not recall the details at this moment.

So a limit on the contiguous block size of 2^20 should work.
Larger blocks would have to generate multiple list entries
by the time the code reaches the controller.

Another limit of the transfer hardware in the controller is
that it can not transfer a block which crosses 2^32 boundaries.
(The transfer base register is 32 bits.)

In those cases, you also have to split the block into above/below
2^32 and reprogram the chips interface (HP) hardware inbetween.

Some of the 53c8xx controllers handle 2^64 physical addressing,
but I have not studied those yet.

> Duno yet if it's realted to my pb but tia for your attention,
>     Joel 
Mike
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

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

[Grant Grundler]

On Mon, Oct 16, 2006 at 01:51:27PM +0200, Joel Soete wrote:
...
>     but it seems that at in the history num_physpages (now ram size in bytes)
>     was well the physical number of page:
...
>     nowaday num_physpages is bytes so the comparision is eronous?
>     (compare bytes against page number)

Where did you get the idea num_physpages is in bytes?

These two examples suggest it's counting PAGE_SIZE pages :

mm/slab.c:      if (num_physpages > (32 << 20) >> PAGE_SHIFT)
mm/swap.c:      unsigned long megs = num_physpages >> (20 - PAGE_SHIFT);


>     the same way in:
>     iov_order = get_order(iova_space_size << PAGE_SHIFT);
> 
>     iova_space_size << PAGE_SHIFT == iova_space_size * 2^PAGE_SHIFT
>                                   == iova_space_size * PAGE_SIZE
> 
>     made sense when iova_space_size was a number of pages,

Look at get_order() then you'll understand why the "<< PAGE_SHIFT".
iov_order is being set to log2(iova_space_size)+1.

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

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

[Kyle McMartin]

On Tue, Oct 17, 2006 at 07:43:19PM +0200, Andrew Gaylard wrote:
>    Why do we truncate the memory like this?
>    My 4GB box is now "missing" 512M.
> 

the top 1/16 of physical memory is F-space for PDC and IO. there
are other reservations too.

it seems fairly logical that you can't fit 4GB of memory and anything
else in a 32bit number.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

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

[Grant Grundler]

On Fri, Oct 20, 2006 at 12:04:47PM +0000, Joel Soete wrote:
> 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)

I don't remember.
ia64 sba is the 3rd generation IO controller.
U2 (ccio) is the first generation.
Sorry, I'm not interested in comparing them.

> >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

This looks correct.

> > 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

This second chainid_mask is 13 bits wide.
Remember that the mask can only be 8 bits wide for ccio.

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

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

[Grant Grundler]

On Fri, Oct 20, 2006 at 09:50:59AM -0600, Grant Grundler wrote:
> On Fri, Oct 20, 2006 at 12:04:47PM +0000, Joel Soete wrote:
> > 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)
> 
> I don't remember.
> ia64 sba is the 3rd generation IO controller.
> U2 (ccio) is the first generation.
> Sorry, I'm not interested in comparing them.

Willy reminded me that Mongoose/WAX was the first.
He's correct of course.

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

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

[Joel Soete]

Grant Grundler wrote:
> On Fri, Oct 20, 2006 at 12:04:47PM +0000, Joel Soete wrote:
>> 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)
> 
> I don't remember.
> ia64 sba is the 3rd generation IO controller.
> U2 (ccio) is the first generation.
> Sorry, I'm not interested in comparing them.
> 
no pb,

>>> 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
> 
> This looks correct.
> 
>>> 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
> 
> This second chainid_mask is 13 bits wide.
mmm sorry how do you compute this wide value?

> Remember that the mask can only be 8 bits wide for ccio.
> 

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.

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).
but in term to 'avoid memory corruption' why don't we limit the iova_space_size to 256 * IOVP_SIZE?

Many thanks,
	Joel
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

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

[Grant Grundler]

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.

> 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. The trade-off is between efficiency in creating
DMA mappings (reducing the number of mappings) and how much
address space we actually use.

> 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.

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

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

[Joel Soete]

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

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

[Grant Grundler]

On Sat, Oct 21, 2006 at 05:17:46PM +0000, Joel Soete wrote:
...
> Or I just have to wait public ccio doc to better understand how this hw 
> works ;-)

Sorry, I guess so. :(

Not unless someone at HP can look up a description of "Chain ID" and
related registers in the CCIO documentation and share a summarized
version of those.

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