Re: [BK PATCH] USB update for 2.6.3

[Deepak Saxena]

On Feb 20 2004, at 17:03, Benjamin Herrenschmidt was caught saying:
> On Fri, 2004-02-20 at 16:58, Linus Torvalds wrote:
> > On Thu, 19 Feb 2004, Greg KH wrote:
> > > 
> > > Here are some USB patches for 2.6.3.  Here are the main types of changes:
> > > 	- switch usb code to use dmapools instead of pcipools which
> > > 	  makes the embedded people happy.
> > 
> > However, this makes the ppc64 people very unhappy.
> > 
> > I've just yesterday and today switched my main home machine to be ppc64, 
> > and this will not compile for me. Bad boy!
> > 
> > (And I haven't used ppc64 enough to be able to make sense of the DMA 
> > setup, so I can't even fix it myself yet. Aaarghh!)
> 
> Hehe ;)
> 
> Well, last I heard, people here were trying to make that work, but
> still, our dma mapping API will probably want the device passed in
> to be a pci_dev...
> 
> The problem with the generic API is that it makes it difficult
> for us to actually go back to the PCI device hosting the USB
> device we get passed in... Which we what we want (our IO MMU
> setup is based on what PCI device is there, for PCI at least,
> for VIO, it's a bit different, but the idea is the same).

Why can't you just do the following to  get to the PCI device?

if (dev->bus_type == &pci_bus_type) {
	struct pci_dev pci_usb_dev = to_pci_dev(dev);
	...
}

If you mean the USB target device itself, can't you walk the
tree until you find a device that is no longer on bus_type
usb to determine your root?

> A while ago, I've advertised making this API a set of function
> pointers attached to the struct device inherited from the bus
> parent, so the core code just set one for the root PCIs and
> everybody inherits them.... But of course, since x86 isn't
> affected, nobody cared ;)

You could stuff that into platform_data on PCI devices on your platforms.

> I think the "generic" DMA API is just not suitable at the moment
> to be really used. It gets passed "generic" struct device, which,
> due to the way Pat designed it, are almost useless alone (we
> can't quite match them to anything and don't have any kind of
> "inheritance" of methods via function pointers). There is no
> simple hook for archs to carry informations attached to struct
> devices neither, etc...

I think we're not quite there yet, but once you have the device
struct, in theory, you can walk up the tree to grab the platform_data
for say the device's parent and do any tweaks based on platform-specific
bus parameters.  With PCI, you could even stuff this into pci_bus->sysdata.

I think having a function pointer table for things like dma mapping
and ioremap on all devices would be a very good thing, but not sure
if the powers that be would allow that in 2.6.

~Deepak

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