From: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: "Corey Minyard" <cminyard@mvista.com>,
"Aleksandar Rikalo" <aleksandar.rikalo@syrmia.com>,
"Eduardo Habkost" <ehabkost@redhat.com>,
"Alistair Francis" <alistair@alistair23.me>,
"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
"Markus Armbruster" <armbru@redhat.com>,
"Jiaxun Yang" <jiaxun.yang@flygoat.com>,
qemu-devel@nongnu.org,
"Aleksandar Markovic" <aleksandar.qemu.devel@gmail.com>,
qemu-ppc@nongnu.org, "Cédric Le Goater" <clg@kaod.org>,
"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
"Huacai Chen" <chenhc@lemote.com>,
"Fred Konrad" <konrad@adacore.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"David Gibson" <david@gibson.dropbear.id.au>
Subject: Re: [RFC PATCH 1/3] hw/i2c/smbus_eeprom: Set QOM parent
Date: Fri, 26 Jun 2020 14:40:21 +0200 [thread overview]
Message-ID: <f7da6118-a27a-a09d-9c8f-92cbf2eca96f@amsat.org> (raw)
In-Reply-To: <alpine.BSF.2.22.395.2006261251480.94870@zero.eik.bme.hu>
+ Eduardo / Mark / Edgard / Alistair / Fred for QOM design.
On 6/26/20 12:54 PM, BALATON Zoltan wrote:
> On Fri, 26 Jun 2020, BALATON Zoltan wrote:
>> On Fri, 26 Jun 2020, Philippe Mathieu-Daudé wrote:
>>> Suggested-by: Markus Armbruster <armbru@redhat.com>
>>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>>> ---
>>> Aspeed change pending latest ARM pull-request, so meanwhile sending
>>> as RFC.
>>> ---
>>> include/hw/i2c/smbus_eeprom.h | 9 ++++++---
>>> hw/i2c/smbus_eeprom.c | 13 ++++++++++---
>>> hw/mips/fuloong2e.c | 2 +-
>>> hw/ppc/sam460ex.c | 2 +-
>>> 4 files changed, 18 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/include/hw/i2c/smbus_eeprom.h
>>> b/include/hw/i2c/smbus_eeprom.h
>>> index 68b0063ab6..037612bbbb 100644
>>> --- a/include/hw/i2c/smbus_eeprom.h
>>> +++ b/include/hw/i2c/smbus_eeprom.h
>>> @@ -26,9 +26,12 @@
>>> #include "exec/cpu-common.h"
>>> #include "hw/i2c/i2c.h"
>>>
>>> -void smbus_eeprom_init_one(I2CBus *bus, uint8_t address, uint8_t
>>> *eeprom_buf);
>>> -void smbus_eeprom_init(I2CBus *bus, int nb_eeprom,
>>> - const uint8_t *eeprom_spd, int size);
>>> +void smbus_eeprom_init_one(Object *parent_obj, const char *child_name,
>>> + I2CBus *smbus, uint8_t address,
>>> + uint8_t *eeprom_buf);
>>> +void smbus_eeprom_init(Object *parent_obj, const char
>>> *child_name_prefix,
>>> + I2CBus *smbus, int nb_eeprom,
>>> + const uint8_t *eeprom_spd, int eeprom_spd_size);
>>
>> Keeping I2CBus *smbus and uint8_t address as first parameters before
>> parent_obj and name looks better to me. These functions still operate
>> on an I2Cbus so could be regarded as methods of I2CBus therefore first
>> parameter should be that.
>
> Also isn't parent_obj is the I2Cbus itself? Why is that need to be
> passed? The i2c_init_bus() also takes parent and name params so both
> I2Cbus and it's parent should be available as parents of the new I2C
> device here without more parameters. What am I missing here?
This is where I'm confused too and what I want to resolve with this
RFC series :)
The SPD EEPROM is soldered on the DIMM module. The DIMM exposes the
memory address/data pins and the i2c pins. We plug DIMMs on a
(mother)board.
I see the DIMM module being the parent. As we don't model it in QOM,
I used the MemoryRegion (which is what the SPD is describing).
We could represent the DIMM as a container of DRAM + SPD EEPROM, but
it makes the modeling slightly more complex. The only benefit is a
clearer modeling.
I'm not sure why the I2C bus is expected to be the parent. Maybe an
old wrong assumption?
>> Regards,
>> BALATON Zoltan
>>
>>> enum sdram_type { SDR = 0x4, DDR = 0x7, DDR2 = 0x8 };
>>> uint8_t *spd_data_generate(enum sdram_type type, ram_addr_t size);
>>> diff --git a/hw/i2c/smbus_eeprom.c b/hw/i2c/smbus_eeprom.c
>>> index b7def9eeb8..879fd7c416 100644
>>> --- a/hw/i2c/smbus_eeprom.c
>>> +++ b/hw/i2c/smbus_eeprom.c
>>> @@ -165,7 +165,9 @@ static void smbus_eeprom_register_types(void)
>>>
>>> type_init(smbus_eeprom_register_types)
>>>
>>> -void smbus_eeprom_init_one(I2CBus *smbus, uint8_t address, uint8_t
>>> *eeprom_buf)
>>> +void smbus_eeprom_init_one(Object *parent_obj, const char *child_name,
>>> + I2CBus *smbus, uint8_t address,
>>> + uint8_t *eeprom_buf)
>>> {
>>> DeviceState *dev;
>>>
>>> @@ -173,10 +175,12 @@ void smbus_eeprom_init_one(I2CBus *smbus,
>>> uint8_t address, uint8_t *eeprom_buf)
>>> qdev_prop_set_uint8(dev, "address", address);
>>> /* FIXME: use an array of byte or block backend property? */
>>> SMBUS_EEPROM(dev)->init_data = eeprom_buf;
>>> + object_property_add_child(parent_obj, child_name, OBJECT(dev));
>>> qdev_realize_and_unref(dev, (BusState *)smbus, &error_fatal);
>>> }
>>>
>>> -void smbus_eeprom_init(I2CBus *smbus, int nb_eeprom,
>>> +void smbus_eeprom_init(Object *parent_obj, const char
>>> *child_name_prefix,
>>> + I2CBus *smbus, int nb_eeprom,
>>> const uint8_t *eeprom_spd, int eeprom_spd_size)
>>> {
>>> int i;
>>> @@ -189,8 +193,11 @@ void smbus_eeprom_init(I2CBus *smbus, int
>>> nb_eeprom,
>>> }
>>>
>>> for (i = 0; i < nb_eeprom; i++) {
>>> - smbus_eeprom_init_one(smbus, 0x50 + i,
>>> + char *name = g_strdup_printf("%s-%d", child_name_prefix, i);
>>> +
>>> + smbus_eeprom_init_one(parent_obj, name, smbus, 0x50 + i,
>>> eeprom_buf + (i * SMBUS_EEPROM_SIZE));
>>> + g_free(name);
>>> }
>>> }
>>>
>>> diff --git a/hw/mips/fuloong2e.c b/hw/mips/fuloong2e.c
>>> index 8ca31e5162..304a096c6a 100644
>>> --- a/hw/mips/fuloong2e.c
>>> +++ b/hw/mips/fuloong2e.c
>>> @@ -377,7 +377,7 @@ static void mips_fuloong2e_init(MachineState
>>> *machine)
>>>
>>> /* Populate SPD eeprom data */
>>> spd_data = spd_data_generate(DDR, machine->ram_size);
>>> - smbus_eeprom_init_one(smbus, 0x50, spd_data);
>>> + smbus_eeprom_init_one(OBJECT(machine->ram), "spd", smbus, 0x50,
>>> spd_data);
>>>
>>> mc146818_rtc_init(isa_bus, 2000, NULL);
>>>
>>> diff --git a/hw/ppc/sam460ex.c b/hw/ppc/sam460ex.c
>>> index 1a106a68de..064d07f4e2 100644
>>> --- a/hw/ppc/sam460ex.c
>>> +++ b/hw/ppc/sam460ex.c
>>> @@ -337,7 +337,7 @@ static void sam460ex_init(MachineState *machine)
>>> spd_data = spd_data_generate(ram_sizes[0] < 128 * MiB ? DDR : DDR2,
>>> ram_sizes[0]);
>>> spd_data[20] = 4; /* SO-DIMM module */
>>> - smbus_eeprom_init_one(i2c, 0x50, spd_data);
>>> + smbus_eeprom_init_one(OBJECT(machine->ram), "spd", i2c, 0x50,
>>> spd_data);
>>> /* RTC */
>>> i2c_create_slave(i2c, "m41t80", 0x68);
>>>
>>
next prev parent reply other threads:[~2020-06-26 12:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-26 10:27 [RFC PATCH 0/3] Use object_get_canonical_path_component to get child description Philippe Mathieu-Daudé
2020-06-26 10:27 ` [RFC PATCH 1/3] hw/i2c/smbus_eeprom: Set QOM parent Philippe Mathieu-Daudé
2020-06-26 10:47 ` BALATON Zoltan
2020-06-26 10:54 ` BALATON Zoltan
2020-06-26 12:40 ` Philippe Mathieu-Daudé [this message]
2020-06-26 14:03 ` BALATON Zoltan
2020-06-26 14:15 ` Philippe Mathieu-Daudé
2020-06-26 14:26 ` BALATON Zoltan
2020-06-26 14:37 ` Philippe Mathieu-Daudé
2020-07-09 20:05 ` Eduardo Habkost
2020-07-10 9:12 ` Philippe Mathieu-Daudé
2020-07-10 20:09 ` Eduardo Habkost
2020-06-26 10:27 ` [RFC PATCH 2/3] hw/i2c/smbus_eeprom: Add description based on child name Philippe Mathieu-Daudé
2020-06-26 11:00 ` BALATON Zoltan
2020-06-26 14:26 ` Philippe Mathieu-Daudé
2020-07-09 19:48 ` Eduardo Habkost
2020-07-10 9:05 ` Philippe Mathieu-Daudé
2020-07-10 17:40 ` Eduardo Habkost
2020-07-13 9:23 ` Markus Armbruster
2020-06-26 10:27 ` [RFC PATCH 3/3] hw/i2c/smbus_eeprom: Trace reset() event Philippe Mathieu-Daudé
2020-06-26 10:37 ` [RFC PATCH 0/3] Use object_get_canonical_path_component to get child description no-reply
2020-06-26 12:43 ` Philippe Mathieu-Daudé
2020-06-26 10:38 ` no-reply
2020-06-26 15:59 ` Aleksandar Markovic
2020-06-26 16:44 ` Philippe Mathieu-Daudé
2020-06-27 6:55 ` Markus Armbruster
2020-06-29 11:38 ` Philippe Mathieu-Daudé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f7da6118-a27a-a09d-9c8f-92cbf2eca96f@amsat.org \
--to=f4bug@amsat.org \
--cc=aleksandar.qemu.devel@gmail.com \
--cc=aleksandar.rikalo@syrmia.com \
--cc=alistair@alistair23.me \
--cc=armbru@redhat.com \
--cc=balaton@eik.bme.hu \
--cc=chenhc@lemote.com \
--cc=clg@kaod.org \
--cc=cminyard@mvista.com \
--cc=david@gibson.dropbear.id.au \
--cc=edgar.iglesias@gmail.com \
--cc=ehabkost@redhat.com \
--cc=jiaxun.yang@flygoat.com \
--cc=konrad@adacore.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).