| Message ID | 1404716892-15600-6-git-send-email-eric.auger@linaro.org |
|---|---|
| State | New |
| Headers | show |
On 07.07.14 09:08, Eric Auger wrote: > This method is meant to be called on sysbus device dynamic > instantiation (-device option). Devices that support this > kind of instantiation must implement this method. > > Signed-off-by: Eric Auger <eric.auger@linaro.org> For the reason I stated earlier, I don't think it's a good idea to put device tree code into our device models. Alex
On 07/08/2014 03:52 PM, Alexander Graf wrote: > > On 07.07.14 09:08, Eric Auger wrote: >> This method is meant to be called on sysbus device dynamic >> instantiation (-device option). Devices that support this >> kind of instantiation must implement this method. >> >> Signed-off-by: Eric Auger <eric.auger@linaro.org> > > For the reason I stated earlier, I don't think it's a good idea to put > device tree code into our device models. Hi Alex, I would propose we discuss that topic during next KVM call if you are available. Hope Peter will be available to join too. Because I feel stuck between not putting things in the machine file (1) - obviously we could put them in a helper module (2) - and not putting them in the device (3). Whatever the solution I fear we are going to pollute something: Any time a new device wants to support dynamic instantiation, we would need to modify the machine file or the helper module with 1 and 2 resp. In case we put it in the device we pollute this latter... My hope was that quite few QEMU platform devices would need to support that feature and hence would need to implement this dt node generation method. To me dynamic instantiation of platform device was not the mainstream solution. Then there is the fundamental question of technical feasibility of devising a generic PlatformParams that match all the specialization needs? Here I miss experience. In case we know the machine type and a small set of additional fields couldn't we do the adaptations you talked about, related to IRQs? Best Regards Eric > > > Alex >
On 23.07.14 17:33, Eric Auger wrote: > On 07/08/2014 03:52 PM, Alexander Graf wrote: >> On 07.07.14 09:08, Eric Auger wrote: >>> This method is meant to be called on sysbus device dynamic >>> instantiation (-device option). Devices that support this >>> kind of instantiation must implement this method. >>> >>> Signed-off-by: Eric Auger <eric.auger@linaro.org> >> For the reason I stated earlier, I don't think it's a good idea to put >> device tree code into our device models. > Hi Alex, > > I would propose we discuss that topic during next KVM call if you are > available. I lost track when that would be. Next week would work fine, the week after not :). > Hope Peter will be available to join too. Because I feel > stuck between not putting things in the machine file (1) - obviously we > could put them in a helper module (2) - and not putting them in the > device (3). > > Whatever the solution I fear we are going to pollute something: Any time > a new device wants to support dynamic instantiation, we would need to > modify the machine file or the helper module with 1 and 2 resp. In case > we put it in the device we pollute this latter... > > My hope was that quite few QEMU platform devices would need to support > that feature and hence would need to implement this dt node generation > method. To me dynamic instantiation of platform device was not the > mainstream solution. Quite frankly I don't think it'd be that many. I think we'll cover 99.9% of all use cases if we just enable it for the virt machines of e500 and arm. > Then there is the fundamental question of technical feasibility of > devising a generic PlatformParams that match all the specialization > needs? Here I miss experience. In case we know the machine type and a > small set of additional fields couldn't we do the adaptations you talked > about, related to IRQs? The problem is that I don't know all the boards and different things people come up with either. There's also no reason machine files have to stick to the "platform bus" model - they could just take those devices and stick them into an existing other virtual bus. I don't feel comfortable generalizing something where I'm pretty sure things will blow up sooner or later. Alex
On 07/24/2014 01:02 AM, Alexander Graf wrote: > > On 23.07.14 17:33, Eric Auger wrote: >> On 07/08/2014 03:52 PM, Alexander Graf wrote: >>> On 07.07.14 09:08, Eric Auger wrote: >>>> This method is meant to be called on sysbus device dynamic >>>> instantiation (-device option). Devices that support this >>>> kind of instantiation must implement this method. >>>> >>>> Signed-off-by: Eric Auger <eric.auger@linaro.org> >>> For the reason I stated earlier, I don't think it's a good idea to put >>> device tree code into our device models. >> Hi Alex, >> >> I would propose we discuss that topic during next KVM call if you are >> available. > > I lost track when that would be. Next week would work fine, the week > after not :). Hi Alex, Unfortunately I think the last one was this week. If you are available next week I would propose to setup a short call next week. Who are the required people in the call aside us and Peter? > >> Hope Peter will be available to join too. Because I feel >> stuck between not putting things in the machine file (1) - obviously we >> could put them in a helper module (2) - and not putting them in the >> device (3). >> >> Whatever the solution I fear we are going to pollute something: Any time >> a new device wants to support dynamic instantiation, we would need to >> modify the machine file or the helper module with 1 and 2 resp. In case >> we put it in the device we pollute this latter... >> >> My hope was that quite few QEMU platform devices would need to support >> that feature and hence would need to implement this dt node generation >> method. To me dynamic instantiation of platform device was not the >> mainstream solution. > > Quite frankly I don't think it'd be that many. I think we'll cover 99.9% > of all use cases if we just enable it for the virt machines of e500 and > arm. > >> Then there is the fundamental question of technical feasibility of >> devising a generic PlatformParams that match all the specialization >> needs? Here I miss experience. In case we know the machine type and a >> small set of additional fields couldn't we do the adaptations you talked >> about, related to IRQs? > > The problem is that I don't know all the boards and different things > people come up with either. There's also no reason machine files have to > stick to the "platform bus" model - they could just take those devices > and stick them into an existing other virtual bus. > > I don't feel comfortable generalizing something where I'm pretty sure > things will blow up sooner or later. ok Best Regards Eric > > > Alex >
On 24.07.14 09:36, Eric Auger wrote: > On 07/24/2014 01:02 AM, Alexander Graf wrote: >> On 23.07.14 17:33, Eric Auger wrote: >>> On 07/08/2014 03:52 PM, Alexander Graf wrote: >>>> On 07.07.14 09:08, Eric Auger wrote: >>>>> This method is meant to be called on sysbus device dynamic >>>>> instantiation (-device option). Devices that support this >>>>> kind of instantiation must implement this method. >>>>> >>>>> Signed-off-by: Eric Auger <eric.auger@linaro.org> >>>> For the reason I stated earlier, I don't think it's a good idea to put >>>> device tree code into our device models. >>> Hi Alex, >>> >>> I would propose we discuss that topic during next KVM call if you are >>> available. >> I lost track when that would be. Next week would work fine, the week >> after not :). > Hi Alex, > > Unfortunately I think the last one was this week. If you are available > next week I would propose to setup a short call next week. Sure! > Who are the > required people in the call aside us and Peter? It would be good if we could have one person on the call who has a very good understanding of cross-platform device trees. Scott Wood or Rob Herring come to my mind here. Scott, Rob, would either of you be available for a quick call on device tree abstraction levels in QEMU Tuesday next week? Alex
On Thu, Jul 24, 2014 at 6:25 AM, Alexander Graf <agraf@suse.de> wrote: > > On 24.07.14 09:36, Eric Auger wrote: >> >> On 07/24/2014 01:02 AM, Alexander Graf wrote: >>> >>> On 23.07.14 17:33, Eric Auger wrote: >>>> >>>> On 07/08/2014 03:52 PM, Alexander Graf wrote: >>>>> >>>>> On 07.07.14 09:08, Eric Auger wrote: >>>>>> >>>>>> This method is meant to be called on sysbus device dynamic >>>>>> instantiation (-device option). Devices that support this >>>>>> kind of instantiation must implement this method. >>>>>> >>>>>> Signed-off-by: Eric Auger <eric.auger@linaro.org> >>>>> >>>>> For the reason I stated earlier, I don't think it's a good idea to put >>>>> device tree code into our device models. >>>> >>>> Hi Alex, >>>> >>>> I would propose we discuss that topic during next KVM call if you are >>>> available. >>> >>> I lost track when that would be. Next week would work fine, the week >>> after not :). >> >> Hi Alex, >> >> Unfortunately I think the last one was this week. If you are available >> next week I would propose to setup a short call next week. > > > Sure! > > >> Who are the >> required people in the call aside us and Peter? > > > It would be good if we could have one person on the call who has a very good > understanding of cross-platform device trees. Scott Wood or Rob Herring come > to my mind here. > > Scott, Rob, would either of you be available for a quick call on device tree > abstraction levels in QEMU Tuesday next week? Yes, I can. Rob
diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c index aacc446..c1c0009 100644 --- a/hw/core/sysbus.c +++ b/hw/core/sysbus.c @@ -289,11 +289,23 @@ MemoryRegion *sysbus_address_space(SysBusDevice *dev) return get_system_memory(); } +/* + * to be specialized in susbus devices that support dynamic instantiation + */ +void sysbus_fdt_add_node(SysBusDevice *dev, void *data) +{ + error_report("Dynamic instantiation of Device %s" + " is not implemented", + qdev_fw_name(DEVICE(dev))); +} + static void sysbus_device_class_init(ObjectClass *klass, void *data) { DeviceClass *k = DEVICE_CLASS(klass); + SysBusDeviceClass *sbdevk = SYS_BUS_DEVICE_CLASS(klass); k->init = sysbus_device_init; k->bus_type = TYPE_SYSTEM_BUS; + sbdevk->fdt_add_node = sysbus_fdt_add_node; } static const TypeInfo sysbus_device_type_info = { diff --git a/include/hw/sysbus.h b/include/hw/sysbus.h index 533184a..df514f9 100644 --- a/include/hw/sysbus.h +++ b/include/hw/sysbus.h @@ -40,6 +40,7 @@ typedef struct SysBusDeviceClass { /*< public >*/ int (*init)(SysBusDevice *dev); + void (*fdt_add_node)(SysBusDevice *dev, void *data); } SysBusDeviceClass; struct SysBusDevice { @@ -73,6 +74,7 @@ void sysbus_mmio_map_overlap(SysBusDevice *dev, int n, hwaddr addr, void sysbus_add_io(SysBusDevice *dev, hwaddr addr, MemoryRegion *mem); void sysbus_del_io(SysBusDevice *dev, MemoryRegion *mem); +void sysbus_fdt_add_node(SysBusDevice *dev, void *mem); MemoryRegion *sysbus_address_space(SysBusDevice *dev); /* Legacy helper function for creating devices. */
This method is meant to be called on sysbus device dynamic instantiation (-device option). Devices that support this kind of instantiation must implement this method. Signed-off-by: Eric Auger <eric.auger@linaro.org> --- hw/core/sysbus.c | 12 ++++++++++++ include/hw/sysbus.h | 2 ++ 2 files changed, 14 insertions(+)