On Tue, Jul 18, 2017 at 11:06 AM, Alexander Graf agraf@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@suse.de wrote:
On 07/18/2017 04:00 PM, Simon Glass wrote:
Hi,
On 12 July 2017 at 05:52, Alexander Graf agraf@suse.de wrote:
On 25.06.17 01:05, Rob Clark wrote:
Signed-off-by: Rob Clark robdclark@gmail.com Cc: Alexander Graf agraf@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