[U-Boot] [PATCH 8/8] x86: queensbay: Call fsp_init_phase_pci() again

[Bin Meng]

Hi Simon,

On Tue, Aug 18, 2015 at 9:59 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi Bin,
>
> On 17 August 2015 at 05:08, Bin Meng <bmeng.cn at gmail.com> wrote:
>> Hi Simon,
>>
>> On Sat, Aug 15, 2015 at 3:07 PM, Bin Meng <bmeng.cn at 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.cn at 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.
>

That's really ugly. But I don't see a good place too..

Regards,
Bin