Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2

[Kevin Hilman <khilman@deeprootsystems.com>]

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

> Kevin,
>
> On Thu, 04 Oct 2012 10:18:04 -0700, Kevin Hilman wrote:
>
>> Can you dump the UART mux registers on a working kernel and compare
>> them to the broken one? (Table 7-4 in the 34xx public TRM[1] will
>> list all the mux registers.)  Maybe the bootloader code for that
>> board will shed some light as well since it will be setting the
>> muxing too.
>> 
>> If the console uart is ttyO2 (UART3 in TI docs), then the interesting
>> registers will be any of the padconf registers in that table that
>> contain 'uart3'.  e.g. for UART3 RX:
>> 
>> CONTROL_PADCONF_DSS_DATA4 (mode 2)
>> CONTROL_PADCONF_UART3_RTS_SD (mode 0)
>> CONTROL_PADCONF_HSUSB0_DATA1  (mode 2)
>>                               
>> omap_mux has some useful debugfs output under <debugfs>/omap_mux.  For
>> example:
>> 
>> # cd /sys/kernel/debug/omap_mux
>> # cat dss_data4
>> # cat uart3_rx_irrx
>> # cat hsusb0_data1
>> 
>> would provide a very useful comparison between a working kernel and a
>> non-working one.
>
> It seems they are exactly the same, unless my eyes missed something, of course.

The example I gave was only for the UART3 RX, you should dump the UART3
TX pins as.  Using the omap_mux debugfs, you can see all of the
potential pins where uart3_tx can be routed:

# cd /sys/kernel/debug/omap_mux
# grep -H uart3_tx * |grep signal
dss_data5:signals: dss_data5 | NA | uart3_tx_irtx | NA | gpio_75 | NA | NA | safe_mode
hsusb0_data0:signals: hsusb0_data0 | NA | uart3_tx_irtx | NA | gpio_125 | NA | NA | safe_mode
uart3_tx_irtx:signals: uart3_tx_irtx | NA | NA | NA | gpio_166 | NA | NA | safe_mode

So a 'cat' on dss_data, hsusb0_data0 and uart3_tx_irtx on a working an
non-working kernel should point us in the right direction (assuming of
course, that it's acutally a muxing problem that we're after.)

[...]

> Regarding the bootloader, I am not 100% sure what are the relevant
> bits, but the UART3 related muxing for this board, done in U-Boot seems
> to be:
>
>         MUX_VAL(CP(UART3_TX_IRTX),  (IDIS | PTD | DIS | M0)) /* UART3_TX */\
>         MUX_VAL(CP(UART3_RX_IRRX),  (IEN  | PTD | DIS | M0)) /* UART3_RX */\
>
> Does this helps?
>

Yes, that tells me where UART3 is expected to be mux'd on the board.  So
you can ignore the dss_data* and husb_data* files above and focus on
uart3*

So to summarize, in /sys/kernel/debug/omap_mux, just do a 'cat uart3*'
on a working and non-working board and see if there are any differences.

Kevin