Am 13.01.2016 um 18:38 schrieb Nishanth Menon <nm@xxxxxx>: > On 01/13/2016 11:12 AM, Grygorii Strashko wrote: >> On 01/13/2016 06:48 PM, Tony Lindgren wrote: > > [...] > >>> Care to dig up some more information on that? >> >> i can't find this report, sry - as i remember there was difference >> between some OMAP4 HS and GP SoCs. >> >> But links on commits for old 3.4 kernel below: >> http://omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=a7a516be9338eabc9a7682e7433fa34d86c1f208 >> http://omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=262669aebf4af4044a25e8292f0e27986e18445a >> >>> >>> I don't have anything against adding GPIO handling to the TWL driver >>> so it can be optionally specified. But that's clearly a separate patch >>> and should be done by somebody who knows more about the issue and has >>> a test case needing the GPIO logic for this pin. >>> >> >> > if it helps in anyways > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/170707.html >> Yes, the TRM has some mode bits marked as reserved, but that doesn't >> mean they don't work. It just means the documentation is squirreled >> away in the secure TRM addendum. Ok, now I understand why the "reserved" MUX_MODE1 could still be correct for OMAP5. And that I just have a "squirreled away" version of the TRM which made me wonder what is going on. >From this discussion I read that for X15 there is a different PMIC (Palmas derived, but not a twl6037) so that it needs something different. So my proposal would be to keep the MUX_MODE1 (because it works on OMAP5+TWL6037) as proposed by Tony. Maybe after adding a comment that MUX_MODE1 is a weakly documented feature. And the X15 board can "patch" it after using the omap5-board-common.dtsi to whatever it needs to fix it. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
