Am 13.01.2016 um 18:38 schrieb Nishanth Menon [off-list ref]:

On 01/13/2016 11:12 AM, Grygorii Strashko wrote:

quoted

On 01/13/2016 06:48 PM, Tony Lindgren wrote:

[...]

quoted

quoted

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

quoted

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

quoted

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