qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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;
> 



  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).