[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/4] hw/sh4/Kconfig: Rename CONFIG_SH4 -> CONFIG_SH4_DEVICES
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: [PATCH 1/4] hw/sh4/Kconfig: Rename CONFIG_SH4 -> CONFIG_SH4_DEVICES |
Date: |
Sun, 21 Feb 2021 19:07:06 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 |
On 2/8/21 9:22 PM, Peter Maydell wrote:
> On Mon, 8 Feb 2021 at 20:04, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>
>> We want to be able to use the 'SH4' config for architecture
>> specific features. As CONFIG_SH4 is only used to select
>> peripherals, rename it CONFIG_SH4_DEVICES.
>>
>> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>> ---
>> hw/block/meson.build | 2 +-
>> hw/char/meson.build | 2 +-
>> hw/intc/meson.build | 2 +-
>> hw/sh4/Kconfig | 6 +++---
>> hw/timer/meson.build | 2 +-
>> 5 files changed, 7 insertions(+), 7 deletions(-)
>
> We could if we wished be more fine-grained about this, eg by
> adding new CONFIG options for each device:
> CONFIG_TC58128
> CONFIG_SH_SERIAL
> CONFIG_SH_INTC
> CONFIG_SH_TIMER
> CONFIG_SH_PCI
>
> and then in hw/sh4/Kconfig
> * config SH7750:
> add 'select SH_SERIAL', 'select SH_INTC', 'select SH_TIMER'
> * config R2D:
> add 'select SH7750' (it's a pre-existing bug that it doesn't, since
> r2d.c has a call to sh7750_init(). Harmless at the moment because
> nothing actually uses CONFIG_SH7750 -- hw/sh4/meson.build always
> compiles sh7750.c and sh7750_regnames.c unconditionally...)
> add 'select SH_PCI' (and make hw/sh4/meson.build build sh_pci.c
> only if it is set...)
> * config SHIX
> add 'select TC58128'
OK.
> Do we have a general preference for how fine-grained we go with the
> Kconfig switches ? Looking at the arm code, in some cases we have
> a CONFIG_ for the SoC that uses 'select' to turn on a separate
> CONFIG_ for each device (the STM32 SoCs are done this way), and
> in some cases we just have the meson.build use the SoC's CONFIG_*
> to control whether we compile its devices (the Xilinx and Exynos4
> SoCs are done this way). When reviewing new code it would be helpful
> to know whether to suggest doing it one way or the other :-)
My view is:
- Use fine granularity with shared/reusable models, so if someone
wants to build a QEMU for a single machine, it is possible (using
--without-default-devices and a specific target config.mak).
Example: STM32F205_SOC and STM32F405_SOC
- For some (family of) SoC, a single switch is acceptable. In
particular when all models are implemented in the same source file.
Example: ASPEED_SOC
- Do not look at hw/i386/Kconfig
I have an old branch where I was generating a .dot of the Kconfig tree
for easier visualization, fine granularity was helpful. I'll try to
update it.
Regards,
Phil.