[U-Boot] [PATCH 00/12] LG Optimus Black (P970) codename sniper support series (and driver-model issue)
Paul Kocialkowski
contact at paulk.fr
Mon Jul 20 15:17:06 CEST 2015
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.
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-next
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.
More information about the U-Boot
mailing list