Hi Simon,
On Sat, Aug 15, 2015 at 3:07 PM, Bin Meng <bmeng...@gmail.com> wrote:
> With driver model pci conversion, the call to FspNotify was dropped.
> Now add this call back as this is required by the FSP spec.
>
> Signed-off-by: Bin Meng <bmeng...@gmail.com>
> ---
>
> arch/x86/cpu/queensbay/tnc.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/cpu/queensbay/tnc.c b/arch/x86/cpu/queensbay/tnc.c
> index c465642..11f65ad 100644
> --- a/arch/x86/cpu/queensbay/tnc.c
> +++ b/arch/x86/cpu/queensbay/tnc.c
> @@ -80,5 +80,11 @@ void cpu_irq_init(void)
>
> int arch_misc_init(void)
> {
> - return pirq_init();
> + int ret;
> +
> + ret = pirq_init();
> + if (ret)
> + return ret;
> +
> + return fsp_init_phase_pci();
> }
> --
Unfortunately, this change breaks video graphics console on Intel
Crown Bay. I was not testing graphics (leave the LVDS interface open)
when I submitted this series. But when I got my LVDS panel connected
(during my attempt to support the PS/2 keyboard), the screen is just a
mess with funny colors. I've git bisected and confirmed this very last
commit breaks the video.
So, this test result is now supporting my previous worry, that we
should call FspNotify() immediately after PCI enumeration, before any
device driver touch PCI devices. This is what the FSP spec tells us
and we used to do this correctly before dm pci conversion. This issue
is unfortunately exposed by driver model PCI. With driver model, when
PCI bus gets enumerated is unknown to us. On Crown Bay, this happens
in initr_mmc() in board_r.c where MMC driver gets initialized. Then
vesa video driver runs the vbios and finally followed by
arch_misc_init() which calls FspNotify() and messes up the screen.
I moved the call to fsp_init_phase_pci() from arch_misc_init() to the
place in initr_mmc() that immediately follows mmc_initialize(), which
means call the FspNotify() as soon as PCI bus is enumerated. With this
change, video (graphics console) is working again. So during the
FspNotify() phase, FSP must have done something (eg: programming some
graphics hardware registers) and that unfortunately breaks the things.
I cannot find a good place in the generic dm pci driver to insert such
a call. So maybe we should just explicitly trigger the PCI bus
enumeration at least when CONFIG_HAVE_FSP. What do you think?
Regards,
Bin
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
