[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 05/24] aspeed: Don't create unwanted "cortex-a7-arm-cpu" devi
From: |
Cédric Le Goater |
Subject: |
Re: [PATCH 05/24] aspeed: Don't create unwanted "cortex-a7-arm-cpu" devices |
Date: |
Tue, 19 May 2020 11:35:34 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
On 5/19/20 7:46 AM, Markus Armbruster wrote:
> Joel Stanley <address@hidden> writes:
>
>> On Mon, 18 May 2020 at 12:24, Cédric Le Goater <address@hidden> wrote:
>>>
>>> On 5/18/20 7:03 AM, Markus Armbruster wrote:
>>>> The number of CPUs is controlled by property "num-cpus".
>>>> aspeed_soc_ast2600_init() creates the maximum supported number.
>>>> aspeed_soc_ast2600_realize() realizes only the wanted number. Works,
>>>> although it leaves unrealized devices hanging around in the QOM
>>>> composition tree. Affects machines ast2600-evb and tacoma-bmc.
>>>>
>>>> Make the init functions create only the wanted ones. Visible in "info
>>>> qom-tree"; here's the change for ast2600-evb:
>>>>
>>>> /machine (ast2600-evb-machine)
>>>> [...]
>>>> /soc (ast2600-a1)
>>>> [...]
>>>> /cpu[0] (cortex-a7-arm-cpu)
>>>> /unnamed-gpio-in[0] (irq)
>>>> /unnamed-gpio-in[1] (irq)
>>>> /unnamed-gpio-in[2] (irq)
>>>> /unnamed-gpio-in[3] (irq)
>>>> - /cpu[1] (cortex-a7-arm-cpu)
>>>> - /unnamed-gpio-in[0] (irq)
>>>> - /unnamed-gpio-in[1] (irq)
>>>> - /unnamed-gpio-in[2] (irq)
>>>> - /unnamed-gpio-in[3] (irq)
>>>> /ehci[0] (platform-ehci-usb)
>>>>
>>>> Cc: "Cédric Le Goater" <address@hidden>
>>>> Cc: Peter Maydell <address@hidden>
>>>> Cc: Andrew Jeffery <address@hidden>
>>>> Cc: Joel Stanley <address@hidden>
>>>> Cc: address@hidden
>>>> Signed-off-by: Markus Armbruster <address@hidden>
>>>
>>> Reviewed-by: Cédric Le Goater <address@hidden>
>>>
>>> Joel, Andrew,
>>>
>>> Shouldn't we enforce a default/min/max number of CPUs of 2 for the AST2600 ?
>>> That's the SoC definition. The fact it is configurable in the Aspeed model
>>> was nice to have during bringup but we are now done.
>>
>> Agreed, we want there to always be two CPUs for the 2600.
>
> Follow-up patch welcome!
I just sent a patch on this topic.
C.