On 2011-06-09 18:40, Markus Armbruster wrote: > Jan Kiszka <jan.kis...@siemens.com> writes: > >> On 2011-06-08 13:33, Peter Maydell wrote: >>> At the moment you can't really implement one sysbus device by saying >>> that it's composed of a set of other sysbus devices. This patch adds >>> new functions sysbus_pass_mmio() and sysbus_pass_one_irq() which >>> allow a sysbus device to delegate an MMIO or IRQ to another sysbus >>> device (The approach is inspired by the existing sysbus_pass_irq() >>> which lets a sysbus device delegate all its IRQs at once). >>> >>> This works; the most obvious deficiency is that the subcomponent >>> device will still appear as its own device on the bus. >>> >>> So: is this a reasonable solution to the problem, or an unacceptable >>> hack? Comments welcome :-) >> >> Sounds more like a little hack. :) >> >> The relationships should be expressed via qdev, not yet another >> sysbus-specific extension. Generally, many services of sysbus should >> rather be generic qdev things. > > Examples?
Resource management, e.g. IRQs. That will be useful for other types of buses as well. > >> Is there anything that today prevents creating a local bus and attaching >> the component devices to that? If it's multi-bus support, that should to >> be added anyway. Passing-through of MMIO and IRQs is still a worthwhile >> generic service, then probably qbus associated. > > Do you mean making the container device a sysbus-sysbus-bridge, then > hanging the component devices off the inner sysbus? And how to apply this concept on a composed PCI device e.g.? Maybe we could define something like Linux' struct resource + a set of helper services for it. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
