[U-Boot] [PATCH 4/5] efi_loader: gop: fixes for CONFIG_DM_VIDEO without CONFIG_LCD

[Rob Clark]

On Tue, Jul 18, 2017 at 11:06 AM, Alexander Graf <agraf at suse.de> wrote:
> On 07/18/2017 04:54 PM, Simon Glass wrote:
>>
>> Hi Alex,
>>
>> On 18 July 2017 at 07:47, Alexander Graf <agraf at suse.de> wrote:
>>>
>>> On 07/18/2017 04:00 PM, Simon Glass wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 12 July 2017 at 05:52, Alexander Graf <agraf at suse.de> wrote:
>>>>>
>>>>>
>>>>> On 25.06.17 01:05, Rob Clark wrote:
>>>>>>
>>>>>> Signed-off-by: Rob Clark <robdclark at gmail.com>
>>>>>> Cc: Alexander Graf <agraf at suse.de>
>>>>>
>>>>>
>>>>> Looks reasonable to me, but could probably use a commit message ;).
>>>>> Also
>>>>> please make sure to CC Simon on all things DM.
>>>>>
>>>> Can we drop the CONFIG_LCD support entirely? This is legacy code at
>>>> this point. What boards use it?
>>>
>>>
>>> Sounds like someone would first need to convert a bunch of boards :).
>>>
>>> $ for i in $(grep CONFIG_LCD configs/* | cut -d : -f 1); do grep -q
>>> DM_VIDEO
>>> $i || echo $i; done
>>> configs/at91sam9261ek_dataflash_cs0_defconfig
>>> configs/at91sam9261ek_dataflash_cs3_defconfig
>>> configs/at91sam9261ek_nandflash_defconfig
>>> configs/at91sam9263ek_dataflash_cs0_defconfig
>>> configs/at91sam9263ek_dataflash_defconfig
>>> configs/at91sam9263ek_nandflash_defconfig
>>> configs/at91sam9263ek_norflash_boot_defconfig
>>> configs/at91sam9263ek_norflash_defconfig
>>> configs/at91sam9g10ek_dataflash_cs0_defconfig
>>> configs/at91sam9g10ek_dataflash_cs3_defconfig
>>> configs/at91sam9g10ek_nandflash_defconfig
>>> configs/at91sam9m10g45ek_mmc_defconfig
>>> configs/at91sam9m10g45ek_nandflash_defconfig
>>> configs/at91sam9n12ek_mmc_defconfig
>>> configs/at91sam9n12ek_nandflash_defconfig
>>> configs/at91sam9n12ek_spiflash_defconfig
>>> configs/at91sam9rlek_dataflash_defconfig
>>> configs/at91sam9rlek_mmc_defconfig
>>> configs/at91sam9rlek_nandflash_defconfig
>>> configs/at91sam9x5ek_dataflash_defconfig
>>> configs/at91sam9x5ek_mmc_defconfig
>>> configs/at91sam9x5ek_nandflash_defconfig
>>> configs/at91sam9x5ek_spiflash_defconfig
>>> configs/brppt1_mmc_defconfig
>>> configs/brppt1_nand_defconfig
>>> configs/brppt1_spi_defconfig
>>> configs/brxre1_defconfig
>>> configs/cm_t3517_defconfig
>>> configs/cm_t35_defconfig
>>> configs/picosam9g45_defconfig
>>> configs/pm9261_defconfig
>>> configs/pm9263_defconfig
>>> configs/sama5d36ek_cmp_mmc_defconfig
>>> configs/sama5d36ek_cmp_nandflash_defconfig
>>> configs/sama5d36ek_cmp_spiflash_defconfig
>>> configs/sama5d3xek_mmc_defconfig
>>> configs/sama5d3xek_nandflash_defconfig
>>> configs/sama5d3xek_spiflash_defconfig
>>> configs/sama5d4ek_mmc_defconfig
>>> configs/sama5d4ek_nandflash_defconfig
>>> configs/sama5d4ek_spiflash_defconfig
>>> configs/zipitz2_defconfig
>>
>> Not really. I suspect none of those uses EFI_LOADER
>
>
> Why not? I really don't want to limit EFI_LOADER to something I consider
> good. It's supposed to be the *one* interface that just works for everyone.

So, thinking about this a bit.. I'd argue that EFI_LOADER doesn't
actually work (for everyone.. or perhaps anyone) in it's current state
(I assume opensuse must have some grub patches, grub master fails to
grok the devicepaths EFI_LOADER creates).

In particular, we currently get devicepaths that look like:

  /File(usb_mass_storage.lun0)/EndEntire

But they should really include parent devices / bus in the path.
Currently this prevents grub from finding and automatically loading
grub.cfg.  (It "works" if you manually enter some grub commands.. but
I don't really consider that "working".)

(If you have a board where it actually works with mainline grub,
please apply that hack/workaround patch I sent yesterday to not crash
grub's lsefi command and send me the output of lsefi.. I'm actually
curious how this worked for anyone.)

I have some wip patches to map u-boots device model to more complete
EFI devicepaths.  The legacy case is somewhat in the way.  (Currently
I'm just trying to make sure the legacy case doesn't suck worse than
it currently does.. but it would be nice to be able to blow it away.)

And tbh, my personal opinion (as someone who spends most time working
on stuff other than u-boot), the legacy cases make the code much
harder to understand for a newbie.. if it isn't going to go away real
soon now, I'd say there is an argument for forking a legacy u-boot
branch, then stripping out the core legacy bits and marking
drivers/boards that aren't converted as depends on BROKEN on master.

BR,
-R

>> There is video driver for atmel which is most of the boards in that
>> list, but we can disable EFI_LOADER until they are converted.
>
>
> No, I won't disable EFI_LOADER on any board because it's not converted. I'd
> rather add support to EFI_LOADER to support more boards that are not
> converted to DM ;).
>
>> We should avoid adding new features to legacy code paths as it makes
>> DM conversion harder and less likely to complete.
>
>
> I agree, but the solution is not to disable EFI_LOADER, it's to convert
> boards.
>
>
> Alex
>