From: "Cédric Le Goater" <clg@kaod.org>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>, qemu-arm@nongnu.org
Cc: <qemu-devel@nongnu.org>, Peter Maydell <peter.maydell@linaro.org>,
Joel Stanley <joel@jms.id.au>, Andrew Jeffery <andrew@aj.id.au>
Subject: Re: [PATCH 06/12] aspeed/smc: Wire CS lines at reset
Date: Wed, 31 May 2023 08:14:59 +0200 [thread overview]
Message-ID: <ad2ef68a-f308-db96-a668-58bfd457788c@kaod.org> (raw)
In-Reply-To: <ad016c90-238c-2654-d550-9823bcb2a395@linaro.org>
On 5/30/23 22:56, Philippe Mathieu-Daudé wrote:
> On 8/5/23 09:58, Cédric Le Goater wrote:
>> Currently, a set of default flash devices is created at machine init
>> and drives defined on the QEMU command line are associated to the FMC
>> and SPI controllers in sequence :
>>
>> -drive file<file>,format=raw,if=mtd
>> -drive file<file1>,format=raw,if=mtd
>>
>> The CS lines are wired in the same creation loop. This makes a strong
>> assumption on the ordering and is not very flexible since only a
>> limited set of flash devices can be defined : 1 FMC + 1 or 2 SPI,
>> which is less than what the SoC really supports.
>>
>> A better alternative would be to define the flash devices on the
>> command line using a blockdev attached to a CS line of a SSI bus :
>>
>> -blockdev node-name=fmc0,driver=file,filename=./flash.img
>> -device mx66u51235f,addr=0x0,bus=ssi.0,drive=fmc0
>>
>> However, user created flash devices are not correctly wired to their
>> SPI controller and consequently can not be used by the machine. Fix
>> that and wire the CS lines of all available devices when the SSI bus
>> is reset.
>>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> hw/arm/aspeed.c | 5 +----
>> hw/ssi/aspeed_smc.c | 8 ++++++++
>> 2 files changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
>> index b654513f35..9a15899cbc 100644
>> --- a/hw/arm/aspeed.c
>> +++ b/hw/arm/aspeed.c
>> @@ -299,17 +299,14 @@ void aspeed_board_init_flashes(AspeedSMCState *s, const char *flashtype,
>> for (i = 0; i < count; ++i) {
>> DriveInfo *dinfo = drive_get(IF_MTD, 0, unit0 + i);
>> - qemu_irq cs_line;
>> DeviceState *dev;
>> dev = qdev_new(flashtype);
>> if (dinfo) {
>> qdev_prop_set_drive(dev, "drive", blk_by_legacy_dinfo(dinfo));
>> }
>> + qdev_prop_set_uint32(dev, "addr", i);
>> qdev_realize_and_unref(dev, BUS(s->spi), &error_fatal);
>> -
>> - cs_line = qdev_get_gpio_in_named(dev, SSI_GPIO_CS, 0);
>> - qdev_connect_gpio_out_named(DEVICE(s), "cs", i, cs_line);
>> }
>> }
>> diff --git a/hw/ssi/aspeed_smc.c b/hw/ssi/aspeed_smc.c
>> index 7281169322..2a4001b774 100644
>> --- a/hw/ssi/aspeed_smc.c
>> +++ b/hw/ssi/aspeed_smc.c
>> @@ -692,6 +692,14 @@ static void aspeed_smc_reset(DeviceState *d)
>> memset(s->regs, 0, sizeof s->regs);
>> }
>> + for (i = 0; i < asc->cs_num_max; i++) {
>> + DeviceState *dev = ssi_get_cs(s->spi, i);
>> + if (dev) {
>> + qemu_irq cs_line = qdev_get_gpio_in_named(dev, SSI_GPIO_CS, 0);
>> + qdev_connect_gpio_out_named(DEVICE(s), "cs", i, cs_line);
>> + }
>> + }
>
> Why did you chose the DeviceReset handler?
> Shouldn't this be done in aspeed_smc_realize(), the DeviceRealize handler?
This looks weird, I agree, but the wiring needs to be done at reset time
to wire the user-created devices. I don't think there is another way.
Thanks,
C.
>
>> /* Unselect all peripherals */
>> for (i = 0; i < asc->cs_num_max; ++i) {
>> s->regs[s->r_ctrl0 + i] |= CTRL_CE_STOP_ACTIVE;
>
next prev parent reply other threads:[~2023-05-31 6:16 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-08 7:58 [PATCH 00/12] aspeed: fixes and extensions Cédric Le Goater
2023-05-08 7:58 ` [PATCH 01/12] aspeed/hace: Initialize g_autofree pointer Cédric Le Goater
2023-05-08 14:28 ` Francisco Iglesias
2023-05-30 21:30 ` Philippe Mathieu-Daudé
2023-05-08 7:58 ` [PATCH 02/12] aspeed: Introduce a boot_rom region at the machine level Cédric Le Goater
2023-05-08 14:27 ` Francisco Iglesias
2023-05-30 21:28 ` Philippe Mathieu-Daudé
2023-05-08 7:58 ` [PATCH 03/12] aspeed: Use the boot_rom region of the fby35 machine Cédric Le Goater
2023-05-30 21:27 ` Philippe Mathieu-Daudé
2023-05-31 5:57 ` Cédric Le Goater
2023-05-08 7:58 ` [PATCH 04/12] hw/ssi: Add an "addr" property to SSIPeripheral Cédric Le Goater
2023-05-30 20:33 ` Philippe Mathieu-Daudé
2023-05-31 5:58 ` Cédric Le Goater
2023-05-08 7:58 ` [PATCH 05/12] hw/ssi: Introduce a ssi_get_cs() helper Cédric Le Goater
2023-05-30 20:34 ` Philippe Mathieu-Daudé
2023-05-30 21:15 ` Philippe Mathieu-Daudé
2023-05-31 5:59 ` Cédric Le Goater
2023-05-31 6:17 ` Philippe Mathieu-Daudé
2023-05-31 6:36 ` Cédric Le Goater
2023-05-31 7:39 ` Philippe Mathieu-Daudé
2023-06-05 5:57 ` Bernhard Beschow
2023-06-05 16:21 ` Cédric Le Goater
2023-05-31 5:58 ` Cédric Le Goater
2023-05-08 7:58 ` [PATCH 06/12] aspeed/smc: Wire CS lines at reset Cédric Le Goater
2023-05-30 20:56 ` Philippe Mathieu-Daudé
2023-05-31 6:14 ` Cédric Le Goater [this message]
2023-05-08 7:58 ` [PATCH 07/12] hw/ssi: Check for duplicate addresses Cédric Le Goater
2023-05-30 21:05 ` Philippe Mathieu-Daudé
2023-05-31 6:20 ` Cédric Le Goater
2023-05-08 7:58 ` [PATCH 08/12] aspeed: Create flash devices only when defaults are enabled Cédric Le Goater
2023-05-08 7:58 ` [PATCH 09/12] m25p80: Introduce an helper to retrieve the BlockBackend of a device Cédric Le Goater
2023-05-30 21:14 ` Philippe Mathieu-Daudé
2023-05-31 6:48 ` Cédric Le Goater
2023-05-31 7:47 ` Philippe Mathieu-Daudé
2023-05-08 7:58 ` [PATCH 10/12] aspeed: Get the BlockBackend of FMC0 from the flash device Cédric Le Goater
2023-05-30 21:08 ` Philippe Mathieu-Daudé
2023-05-08 7:58 ` [PATCH 11/12] aspeed: Introduce a "uart" machine option Cédric Le Goater
2023-05-30 21:22 ` Philippe Mathieu-Daudé
2023-05-31 6:28 ` Cédric Le Goater
2023-05-31 7:50 ` Philippe Mathieu-Daudé
2023-05-31 8:47 ` Cédric Le Goater
2023-05-08 7:58 ` [PATCH 12/12] target/arm: Allow users to set the number of VFP registers Cédric Le Goater
2023-05-30 15:03 ` [PATCH 00/12] aspeed: fixes and extensions Cédric Le Goater
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=ad2ef68a-f308-db96-a668-58bfd457788c@kaod.org \
--to=clg@kaod.org \
--cc=andrew@aj.id.au \
--cc=joel@jms.id.au \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@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).