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

My fist intention was exactly same as yours, but if all access were done
through pci_dev...
Unfortunately, you can't store ioremap()'ed address for 4k within
pci_dev and then simply use it.
In all places around, config accessed through (bus,dev,fn) indexes.

If you want to keep virt. addr. footprint small, the only alternative to
fixmap is some kind of LRU cache for dozen of devices.
When choosing between fixmap and LRU cache, I would choose fixmaps. It
is very simple and clear, low virt. addr. and comparable overhead.

Vladimir.

Andi Kleen wrote:

>Vladimir Kondratiev <vladimir.kondratiev@intel.com> writes:
>
>
>>As alternative between 1 page and 256M, I see also lazy allocation on
>>per-bus basis: when bus is first accessed, ioremap 1Mb for it. On real
>>system, it is no more then 3-4 buses. This way, we will end with
>>several 1MB mappings. Finer granularity do not looks feasible, since
>>bus scanning procedure tries to access all devices.
>>
>>
>
>For bus scanning fixmaps are fine, but for the normal use of the
>config space in the driver just doing ioremap once (e.g. at
>pci_enable_device time) and caching it is preferable. The number of
>PCI-E devices in a given system should be bounded, so e.g. when you
>have 100 devices you will only lose 400kB of vmalloc space this way
>which is quite reasonable.
>
>I don't think dynamic fixmaps at each access would be a good idea.
>
>-Andi
>
>

-
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.026 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site