Hi All,
Well forgive me for not being up on the lastest news but from building
2.5.4 kernel for my box, which uses the cs46xx.c sound driver, it would
appear that virt_to_bus and bus_to_virt has gone the way of the do-do.
What's the correct method now?
Be nice to get this cleaned up....
Regards,
Tom
--
Tom Gall - [embedded] [PPC64 | PPC32] Code Monkey
Peace, Love & "Where's the ka-boom? There was
Linux Technology Center supposed to be an earth
http://www.ibm.com/linux/ltc/ shattering ka-boom!"
(w) [email protected] -- Marvin Martian
(w) 507-253-4558
(h) [email protected]
Tom Gall wrote:
> Hi All,
>
> Well forgive me for not being up on the lastest news but from building
> 2.5.4 kernel for my box, which uses the cs46xx.c sound driver, it would
> appear that virt_to_bus and bus_to_virt has gone the way of the do-do.
>
> What's the correct method now?
>
> Be nice to get this cleaned up....
>
> Regards,
>
> Tom
Use pci_alloc_consistent() to allocate the buffer. This function
returns the right thing so that virt_to_bus() is no longer needed.
From what I read, it looks like pci_alloc_consistent returns a pci
address and a physical address (via dma_addr_t), so it should be simple
to change the code to use this function. However, I don't know where
the hell I'm supposed to find pci_dev -- I'll try rereading the
driver-model.txt code again :).
> Well forgive me for not being up on the lastest news but from building
> 2.5.4 kernel for my box, which uses the cs46xx.c sound driver, it would
> appear that virt_to_bus and bus_to_virt has gone the way of the do-do.
You need to switch to using pci_alloc_consistet, pci_map_* and friends. Its
been the case for a while that drivers should be using the PCI api, and its
needed on some non x86 platforms - now its enforced for 2.5
> address and a physical address (via dma_addr_t), so it should be simple
> to change the code to use this function. However, I don't know where
> the hell I'm supposed to find pci_dev -- I'll try rereading the
> driver-model.txt code again :).
For ISA devices pass NULL. For the PCI devices you get it when you do the
initial PCI probing. So for the cs46xx you'll see its passed to cs46xx_probe()
and saved in card->pci_dev for future use. So you can get it from there.
If you are going to hack on cs46xx.c please pick up the one from 2.4.18pre9
and use that not the one in 2.5 , unless someone also updated that to
match the 2.4 changes. The one in 2.5 seems to still have holes where any
user can oops the system that will get fixed by porting forward the current
driver
Alan
From: Alan Cox <[email protected]>
Date: Mon, 11 Feb 2002 18:10:04 +0000 (GMT)
For ISA devices pass NULL.
That is the recommended method for drivers that have to deal
with ISA and PCI variants of a chipset.
However, for "purely x86 ISA" devices one may use
isa_bus_to_virt and isa_virt_to_bus.
I hesitate to even mention this because what people should _not_ do is
just put "isa_" in front of the virt_to_bus et al. calls in all the
PCI drivers that stopped to link now.
There are other tangental issues I'd like to address and clarify in
this area. This includes the "what can be invoked from interrupt"
questions. Currently I think pci_{alloc,free}_consistent() should be
valid from an interrupt.
> However, for "purely x86 ISA" devices one may use
> isa_bus_to_virt and isa_virt_to_bus.
>
> I hesitate to even mention this because what people should _not_ do is
> just put "isa_" in front of the virt_to_bus et al. calls in all the
> PCI drivers that stopped to link now.
Would putting a range check and BUG() in the ISA macros for now help there.
Reminds me - we have a request_mem_region problem to address that is sort
of related to all this. Right now we reserve mem regions without knowing
properly about ISA mappings. That means drivers are reserving stuff like
0xD0000. Unfortunately on some non X86 boxes the ISA hole isnt at 640K-1M
so it appears we want an isa_request_mem_region and friends to handle those
platforms ?
>Would putting a range check and BUG() in the ISA macros for now help there.
>
>Reminds me - we have a request_mem_region problem to address that is sort
>of related to all this. Right now we reserve mem regions without knowing
>properly about ISA mappings. That means drivers are reserving stuff like
>0xD0000. Unfortunately on some non X86 boxes the ISA hole isnt at 640K-1M
>so it appears we want an isa_request_mem_region and friends to handle those
>platforms ?
>-
I'd rather provide a function to obtain the base address of the ISA hole,
while would also allow us to
- Return an error when it doesn't exist (a given kernel may or may not
have it depending on which box it's booted, it can't be a compile time
option)
- Eventually obtain a per-PCI bus ISA hole (the "legacy one" beeing
defined as bus or with a special constant) so multi domain machines
can use multiple VGA cards (eek eek ;)
With that, at least PPC don't require isa_xxx specific functions/macros
(but I can't tell about other archs).
Ben.
>
>I'd rather provide a function to obtain the base address of the ISA hole,
>while would also allow us to
> - Return an error when it doesn't exist (a given kernel may or may not
>have it depending on which box it's booted, it can't be a compile time
>option)
> - Eventually obtain a per-PCI bus ISA hole (the "legacy one" beeing
>defined as bus or with a special constant) so multi domain machines
>can use multiple VGA cards (eek eek ;)
Side note: even if we never intend to support multiple VGA cards in
separate domains, it still make sense to have a way to match an ISA
hole to it's hosting PCI bus (if any). The VGA card may not actually
be on the primary bus of a multiple-bus machine (and the very notion
of primary bus makes few sense in multi domain environements anyway)
Ben.
Alan Cox wrote:
>
> Reminds me - we have a request_mem_region problem to address that is sort
> of related to all this. Right now we reserve mem regions without knowing
> properly about ISA mappings. That means drivers are reserving stuff like
> 0xD0000. Unfortunately on some non X86 boxes the ISA hole isnt at 640K-1M
> so it appears we want an isa_request_mem_region and friends to handle those
> platforms ? ^^^^^^^^^^^^^^^^^^^^^^
Minor nit, but if we go that route, maybe make it request_isa_mem_region()
just to be consistent with all the other request_xxxx type functions ?
Paul.
> Minor nit, but if we go that route, maybe make it request_isa_mem_region()
> just to be consistent with all the other request_xxxx type functions ?
All the other bus functions start pci_ and isa_ 8)