lkml.org 
[lkml]   [2003]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PCI Express support for 2.4 kernel
Gabriel Paubert wrote:

>>Sanity check do pretty good job here. If it is not PCI-E
>>platform, this address in physical memory will not be connected to
>>anything real. You will get 0xff's.
>>
>>
>
>Or a machine check on some architectures which make you know that
>they don't like a bus cycle which terminates on a master abort.
>
>
Could you elaborate a bit? This code is for pci-pc.c, it is platform
specific.
Are there surprises on pc platform? What is visible behavour in this case?

>The major problem I see is that using up 256 Mb of kernel virtual address
>space for accessing PCI config space is gross. Besides that it won't
>work for 32 bit machines with 768 Mb of RAM or more.
>
>I believe that it would be better to use kmap/kunmap like tricks, especially
>for something which is relatively infrequent. You could even reserve
>a fixmap entry for this and keep somewhere a pointer to the PTE, which
>would be modified on every config space access (config space access was
>already properly serialized last time I looked, I believe that all you need
>is a TLB flush after the PTE is updated).
>
>I have no strong opinion on how to handle 64 bit archs.
>
>
I should be missing something here. You have 256M of physical address
space at 0xe0000000 occupied.
You can do nothing with it, it is simply present. Then, ioremap maps it
somewhere in high memory.
It should not conflict with kernel RAM, for which trivial mapping (+3G)
used.

>
>
>>>Further, PCI posting: a writeb() / writew() / writel() will not be
>>>flushed immediately to the processor. The CPU and/or PCI bridge may
>>>post (delay/combine) such writes. I do not think this is a desireable
>>>effect, for PCI config register accesses.
>>>
>>>
>>>
>>Good point. Fixed.
>>
>>
>
>Here I'm somehwat lost. Writes to uncacheable RAM will be in program
>order and never combined. The bridge itself should not post writes to
>config space. So it's a matter of pushing the write to the processor
>bus, a PCI read looks very heavy for this. Isn't there a more
>lightweight solution ?
>
>
I am not expert here. I know that PCI-E bridge completes its transaction
before data actually get to memory. Each intermediate bridge may do its
own buffering. Besides read, I know nothing that will make you sure data
reaches final destination. I'd appreciate if someone who knows better
will step in. Config write is not very often procedure, I don't think
extra read will make any difference. I'll look for qualified person
around, to consult on this issue.

Vladimir.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:59    [W:0.096 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site