Hi Bin,
On 17 August 2015 at 05:08, Bin Meng <bmeng...@gmail.com> wrote:
> 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?
An ugly option would be to add the call to pci_uclass_post_probe().
No I don't think we should force enumeration.
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
