| Message ID | 1529240273-32045-4-git-send-email-bmeng.cn@gmail.com |
|---|---|
| State | Accepted |
| Commit | 6d02cf0562ead596b20ce23f102be5c3020c04f9 |
| Delegated to: | Bin Meng |
| Headers | show |
| Series | [U-Boot,1/5] x86: qemu: Change default vesa mode to 1024x768x32 | expand |
Hi Bin, On 17 June 2018 at 06:57, Bin Meng <bmeng.cn@gmail.com> wrote: > The generic efi payload currently does not enumerate the PCI bus, > which means peripherals on the PCI bus are not discovered by their > drivers. This uses board_early_init_r() to do the PCI enumeration. > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com> > --- > > board/efi/efi-x86_payload/Kconfig | 1 + > board/efi/efi-x86_payload/Makefile | 2 +- > board/efi/efi-x86_payload/payload.c | 18 ++++++++++++++++++ > 3 files changed, 20 insertions(+), 1 deletion(-) > create mode 100644 board/efi/efi-x86_payload/payload.c I would like to consider adding a mechanism to indicate that a uclass should be inited (and its devices probed) on startup. This would be used for things which provide essential peripherals, which otherwise would not be visible in the initial driver-model bind process. I am not sure whether this should be: - a flag in the uclass - a flag in the BOARD driver (assuming we have a BOARD uclass soon) - a function call into DM - something else But I think it is justified in the case of PCI, since some systems cannot find all their devices without scanning it. What do you think? Regards, Simon
Hi Simon, On Thu, Jun 21, 2018 at 1:51 AM, Simon Glass <sjg@chromium.org> wrote: > Hi Bin, > > On 17 June 2018 at 06:57, Bin Meng <bmeng.cn@gmail.com> wrote: >> The generic efi payload currently does not enumerate the PCI bus, >> which means peripherals on the PCI bus are not discovered by their >> drivers. This uses board_early_init_r() to do the PCI enumeration. >> >> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> >> --- >> >> board/efi/efi-x86_payload/Kconfig | 1 + >> board/efi/efi-x86_payload/Makefile | 2 +- >> board/efi/efi-x86_payload/payload.c | 18 ++++++++++++++++++ >> 3 files changed, 20 insertions(+), 1 deletion(-) >> create mode 100644 board/efi/efi-x86_payload/payload.c > > I would like to consider adding a mechanism to indicate that a uclass > should be inited (and its devices probed) on startup. This would be > used for things which provide essential peripherals, which otherwise > would not be visible in the initial driver-model bind process. > Good to know! > I am not sure whether this should be: > > - a flag in the uclass Only adding a flag to the uclass driver seems not working. On some systems like x86 UCLASS_PCI may be init at boot up, but on other systems this might not be the case. So we need find a place to tell DM to init the uclass driver if the uclass driver has the flag, but where? > - a flag in the BOARD driver (assuming we have a BOARD uclass soon) The concept of BOARD driver sounds interesting. So does the BOARD uclass driver intend to replace various config options like CONFIG_BOARD_EARLY_INIT_F, CONFIG_BOARD_EARLY_INIT_R, CONFIG_BOARD_LATE_INIT, etc? If we do that, how do we guarantee the init order with other components in board_f.c and board_r.c? > - a function call into DM Like uclass_first_device()? > - something else > > But I think it is justified in the case of PCI, since some systems > cannot find all their devices without scanning it. > Yes, this makes sense for PCI on x86. > What do you think? > Regards, Bin
Hi Bin, On 21 June 2018 at 05:19, Bin Meng <bmeng.cn@gmail.com> wrote: > Hi Simon, > > On Thu, Jun 21, 2018 at 1:51 AM, Simon Glass <sjg@chromium.org> wrote: >> Hi Bin, >> >> On 17 June 2018 at 06:57, Bin Meng <bmeng.cn@gmail.com> wrote: >>> The generic efi payload currently does not enumerate the PCI bus, >>> which means peripherals on the PCI bus are not discovered by their >>> drivers. This uses board_early_init_r() to do the PCI enumeration. >>> >>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> >>> --- >>> >>> board/efi/efi-x86_payload/Kconfig | 1 + >>> board/efi/efi-x86_payload/Makefile | 2 +- >>> board/efi/efi-x86_payload/payload.c | 18 ++++++++++++++++++ >>> 3 files changed, 20 insertions(+), 1 deletion(-) >>> create mode 100644 board/efi/efi-x86_payload/payload.c >> >> I would like to consider adding a mechanism to indicate that a uclass >> should be inited (and its devices probed) on startup. This would be >> used for things which provide essential peripherals, which otherwise >> would not be visible in the initial driver-model bind process. >> > > Good to know! > >> I am not sure whether this should be: >> >> - a flag in the uclass > > Only adding a flag to the uclass driver seems not working. On some > systems like x86 UCLASS_PCI may be init at boot up, but on other > systems this might not be the case. So we need find a place to tell DM > to init the uclass driver if the uclass driver has the flag, but > where? Yes I figured. Let's drop this idea. > >> - a flag in the BOARD driver (assuming we have a BOARD uclass soon) > > The concept of BOARD driver sounds interesting. So does the BOARD > uclass driver intend to replace various config options like > CONFIG_BOARD_EARLY_INIT_F, CONFIG_BOARD_EARLY_INIT_R, > CONFIG_BOARD_LATE_INIT, etc? If we do that, how do we guarantee the > init order with other components in board_f.c and board_r.c? That's a separate issue, but we could certainly ensure that after all devices are bound, we probe things like PCI, which would bind its devices. > >> - a function call into DM > > Like uclass_first_device()? That's what we have today. I was more thinking of something that tells DM (at the start) which uclasses should be probed. E.g. uclass_set_auto_probe(UCLASS_PCI, true); > >> - something else >> >> But I think it is justified in the case of PCI, since some systems >> cannot find all their devices without scanning it. >> > > Yes, this makes sense for PCI on x86. Anyway the patch is fine, but if you want to try something like the above, please go ahead. Reviewed-by: Simon Glass <sjg@chromium.org> Regards, Simon
On Fri, Jun 22, 2018 at 3:45 AM, Simon Glass <sjg@chromium.org> wrote: > Hi Bin, > > On 21 June 2018 at 05:19, Bin Meng <bmeng.cn@gmail.com> wrote: >> Hi Simon, >> >> On Thu, Jun 21, 2018 at 1:51 AM, Simon Glass <sjg@chromium.org> wrote: >>> Hi Bin, >>> >>> On 17 June 2018 at 06:57, Bin Meng <bmeng.cn@gmail.com> wrote: >>>> The generic efi payload currently does not enumerate the PCI bus, >>>> which means peripherals on the PCI bus are not discovered by their >>>> drivers. This uses board_early_init_r() to do the PCI enumeration. >>>> >>>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> >>>> --- >>>> >>>> board/efi/efi-x86_payload/Kconfig | 1 + >>>> board/efi/efi-x86_payload/Makefile | 2 +- >>>> board/efi/efi-x86_payload/payload.c | 18 ++++++++++++++++++ >>>> 3 files changed, 20 insertions(+), 1 deletion(-) >>>> create mode 100644 board/efi/efi-x86_payload/payload.c >>> >>> I would like to consider adding a mechanism to indicate that a uclass >>> should be inited (and its devices probed) on startup. This would be >>> used for things which provide essential peripherals, which otherwise >>> would not be visible in the initial driver-model bind process. >>> >> >> Good to know! >> >>> I am not sure whether this should be: >>> >>> - a flag in the uclass >> >> Only adding a flag to the uclass driver seems not working. On some >> systems like x86 UCLASS_PCI may be init at boot up, but on other >> systems this might not be the case. So we need find a place to tell DM >> to init the uclass driver if the uclass driver has the flag, but >> where? > > Yes I figured. Let's drop this idea. > >> >>> - a flag in the BOARD driver (assuming we have a BOARD uclass soon) >> >> The concept of BOARD driver sounds interesting. So does the BOARD >> uclass driver intend to replace various config options like >> CONFIG_BOARD_EARLY_INIT_F, CONFIG_BOARD_EARLY_INIT_R, >> CONFIG_BOARD_LATE_INIT, etc? If we do that, how do we guarantee the >> init order with other components in board_f.c and board_r.c? > > That's a separate issue, but we could certainly ensure that after all > devices are bound, we probe things like PCI, which would bind its > devices. > >> >>> - a function call into DM >> >> Like uclass_first_device()? > > That's what we have today. I was more thinking of something that tells > DM (at the start) which uclasses should be probed. E.g. > > uclass_set_auto_probe(UCLASS_PCI, true); > >> >>> - something else >>> >>> But I think it is justified in the case of PCI, since some systems >>> cannot find all their devices without scanning it. >>> >> >> Yes, this makes sense for PCI on x86. > > Anyway the patch is fine, but if you want to try something like the > above, please go ahead. > > Reviewed-by: Simon Glass <sjg@chromium.org> > applied to u-boot-x86, thanks!
diff --git a/board/efi/efi-x86_payload/Kconfig b/board/efi/efi-x86_payload/Kconfig index b6e57b9..08dd0c2 100644 --- a/board/efi/efi-x86_payload/Kconfig +++ b/board/efi/efi-x86_payload/Kconfig @@ -17,6 +17,7 @@ config SYS_TEXT_BASE config BOARD_SPECIFIC_OPTIONS # dummy def_bool y + select BOARD_EARLY_INIT_R imply SYS_NS16550 imply SCSI imply SCSI_AHCI diff --git a/board/efi/efi-x86_payload/Makefile b/board/efi/efi-x86_payload/Makefile index 6982340..00ef695 100644 --- a/board/efi/efi-x86_payload/Makefile +++ b/board/efi/efi-x86_payload/Makefile @@ -2,4 +2,4 @@ # # Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com> -obj-y += start.o +obj-y += start.o payload.o diff --git a/board/efi/efi-x86_payload/payload.c b/board/efi/efi-x86_payload/payload.c new file mode 100644 index 0000000..4eeb49a --- /dev/null +++ b/board/efi/efi-x86_payload/payload.c @@ -0,0 +1,18 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com> + */ + +#include <common.h> +#include <usb.h> + +int board_early_init_r(void) +{ + /* + * Make sure PCI bus is enumerated so that peripherals on the PCI bus + * can be discovered by their drivers + */ + pci_init(); + + return 0; +}
The generic efi payload currently does not enumerate the PCI bus, which means peripherals on the PCI bus are not discovered by their drivers. This uses board_early_init_r() to do the PCI enumeration. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> --- board/efi/efi-x86_payload/Kconfig | 1 + board/efi/efi-x86_payload/Makefile | 2 +- board/efi/efi-x86_payload/payload.c | 18 ++++++++++++++++++ 3 files changed, 20 insertions(+), 1 deletion(-) create mode 100644 board/efi/efi-x86_payload/payload.c