On Tue, Jul 18, 2017 at 11:06 AM, Alexander Graf <ag...@suse.de> wrote: > On 07/18/2017 04:54 PM, Simon Glass wrote: >> >> Hi Alex, >> >> On 18 July 2017 at 07:47, Alexander Graf <ag...@suse.de> wrote: >>> >>> On 07/18/2017 04:00 PM, Simon Glass wrote: >>>> >>>> Hi, >>>> >>>> On 12 July 2017 at 05:52, Alexander Graf <ag...@suse.de> wrote: >>>>> >>>>> >>>>> On 25.06.17 01:05, Rob Clark wrote: >>>>>> >>>>>> Signed-off-by: Rob Clark <robdcl...@gmail.com> >>>>>> Cc: Alexander Graf <ag...@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 > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
