LG Optimus Black (P970) codename sniper support series (and driver-model issue)
Get series with b4
b4 am 1437928484.2629.6.camel@collinsVersions newest first
- v1 Latest0 of 12 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 12 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [PATCH 00/12] LG Optimus Black (P970) codename sniper support series (and driver-model issue)
Le lundi 20 juillet 2015 ? 15:17 +0200, Paul Kocialkowski a ?crit :
Quoted 3 lines
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!
Quoted 32 lines
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_TAGifdef check forget_board_revAt 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-nextHaving 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.
Quoted 8 lines
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 at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150726/2bbf39cf/attachment.sig>