Le lundi 20 juillet 2015 à 15:17 +0200, Paul Kocialkowski a écrit :
This patch series adds support for the LG Optimus Black (P970) codename sniper, see the commit that introduces the board and config files for a short description of the device.
Any comment on this series? I would really like to get that new device merged before the merge window ends.
Thanks!
This should be applied on top of patches that I have submitted to the list but were not merged yet, especially:
- omap-common: Common boot code OMAP3 support and cleanup
- omap3: CONFIG_REVISION_TAG ifdef check for get_board_rev
At this point, support as submitted as this point is minimalistic. It is not ready for daily use, but introduces the basic elements that are needed to have a sane base upon which the rest of the device support will be introduced.
In particular, the device is currently headless, mainly because the display backlight is not enabled. Other important features such as the MUIC are not enabled, so USB will only work in U-Boot when the device boots with an USB cable already attached. In addition, the external MMC is not supported in U-Boot either, as it requires support for a separate PMIC.
A work in progress commit introduces support for (some of) those bits in a dirty and non-mergeable way is available at: http://git.code.paulk.fr/gitweb/?p=u-boot.git;a=shortlog;h=refs/heads/sniper...
Having those bits written correctly would require writing some drivers using the power framework. In the long run, those would have to use the driver model API, which would involve converting the I2C driver to DM as well. This is too much overhead for now, but it will be done eventually.
The main problem I see with doing that work now is that I2C DM seems to heavily rely on device-tree. Other parts of the OMAP platform support were converted to DM but use platform data defined in each board. That solution looks good to me, but doesn't work with I2C. Thus, we could either modify the I2C driver to cope with the lack of device-tree or make the use of device-tree a hard requirement for driver model, implying that each omap3 boards would have to provide a device-tree file as well.
Both solutions look good to me and I'll let experts decide what to do. Either way, I need to know what the right solution to this problem is to be able to move forward.
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot