Messages in this thread | | | Subject | Re: Problems with dma_alloc_coherent() | From | Benjamin Herrenschmidt <> | Date | Fri, 02 Apr 2004 11:22:34 +1000 |
| |
Ok, time to step in....
> Yes, after thinking about it, it made more sense to modify the "struct > bus_type" structure to have the bus memory map offset. We could then > have an OCP bus type, PLB bus type, etc. However, that would be a core > kernel change, and I don't know how easy it is to get those pushed back > into the mainline. > > Also, after looking at the kernel code more (I'm fairly new to 2.6, > which I'm sure you've deduced), it looks like most routines expect > instances of type "bus_type" to be enumeratable/hot-swappable, and many > of the busses I'd use in the embedded world wouldn't fit. I don't know > how easy or difficult it would be to use the bus_type code construct in > this fashion.
Please, bring this discussion to linux-kernel. The problem is similar to some issue I'm having on ppc64 with iommu. In a more general way, I want to be able to attach additional data to a struct device for use by the DMA code, that can be pointers to the actual DMA functions, pointer to the PHB structure, pointer to the iommu table, bus offset, etc....
Adding such things to bus_type isn't a good option. Especially since several platform may have different needs for the same bus type, or several _instances_ of a bus of a given type may have different needs (typically, the iommu info or DMA offset may be different for 2 busses of the same type).
What struct bus_type provides is actually the "class" of the device object in object terminology (which is yet different from struct "class" in the driver model terminology, I know, this is all quite confusing). That is, it defines the actual struct type that embeds that struct device. It does _not_ represent an instance of that bus.
There is a hook in the device model that can be used to add your own data to a device (typically to put something in device->platform_data).
This hook is called at device_register() and device_unregister() time, however, it is bogus for a simple reason: Lifetime rules. The struct device beeing a kobject, it can stay around after beeing unregistered, at least until the last reference to the kobkjet gets dropped. Theorically, we should also "remove" whatever we put in platform_data at this same deletion time, and not earlier, or we may race with something currently using the device.
This race is unlikely imho as I doubt we unregister devices that still have a driver attached, and the driver is probably the only thing that will actually use that platform data (indirectly via things like the DMA API) but still...
Ben.
- 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/
| |