Stephen beat me to it. Look at how our other drivers do HW manipulation w/o bitfields and mimic them if you get stuck (SPI, MMC, etc.).
My take is that we'd be better off pushing a Harmony dts file first, since that seems to be the most used/available Tegra2 board out there AFAIK. And getting a dts file reviewed by U-Boot denizens isn't much help, since fdt/dts is new to U-Boot upstream. Better to have it looked over by Linux and/or devicetree experts first, as Stephen says. Tom _____________________________________________ From: Stephen Warren Sent: Friday, November 18, 2011 9:15 AM To: Mayuresh Kulkarni; Uboot-dev Cc: Pritesh Raithatha; Varun Wadekar; devicetree-discuss@lists.ozlabs.org Subject: RE: Need some advice on LCD driver in Chrome u-boot AIUI, yes you'll need to rewrite the LCD driver, but this should just be a manual replacement of the bit-twiddling macros with manually coded manipulations. I don't see much point upstreaming a .dts file that's completely untested; having it upstream before we're able to use it won't benefit us in any way, will it? Now, if we started initializing a bunch of stuff besides LCD from it, then it'd make sense. Please make sure you have the LCD bindings (and whole .dts file) reviewed on devicetree-discuss@lists.ozlabs.org<mailto:devicetree-discuss@lists.ozlabs.org>, since that's the main .dts review list. The .dts needs to be co-ordinated with other users such as the Linux kernel. _____________________________________________ From: Mayuresh Kulkarni Sent: Thursday, November 17, 2011 11:27 PM To: Uboot-dev Cc: Pritesh Raithatha; Varun Wadekar Subject: Need some advice on LCD driver in Chrome u-boot Hi All, I need advice on following points about up-streaming the LCD driver: - Chrome's u-boot implementation uses special bit-fields macros to implement the core display driver (for register read/writes). You can check this implementation in u-boot/arch/arm/cpu/armv7/tegra2/display.c. - As you might be aware, Pritesh is working on getting I2C driver up-stream which also uses bit-field macros in Chrome's u-boot. He has been given a comment that, this needs to be removed before up-streaming, as these macros are not accepted by Denx. - As I understand, this means that the display driver needs to be rewritten to use standard readl/writel APIs. Is this correct understanding? - If it needs to be rewritten, it is going to take some time. So is it OK if we push a reviewed copy of tegra2-ventana.dts (name could be decided upon) to Denx's master branch at this point of time? This commit will not be tested as there is no driver in master which would use this. Are such commits accepted? In general, how are such issues handled by the u-boot community? Mayuresh Kulkarni NVIDIA Graphics Pvt Ltd ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------
_______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
