From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Kevin Hilman <khilman@deeprootsystems.com>
Cc: "Tony Lindgren" <tony@atomide.com>,
linux-omap@vger.kernel.org,
"Enric Balletbo i Serra" <eballetbo@iseebcn.com>,
"Gregory Clément" <gregory.clement@free-electrons.com>,
"Michael Opdenacker" <michael.opdenacker@free-electrons.com>,
"Maxime Ripard" <maxime.ripard@free-electrons.com>
Subject: Re: ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2
Date: Thu, 4 Oct 2012 22:11:18 +0200 [thread overview]
Message-ID: <20121004221118.4316181d@skate> (raw)
In-Reply-To: <87vcequpf7.fsf@deeprootsystems.com>
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.
Note: the 3.6 kernel is booted with the patch I posted earlier, but it
doesn't make it work any better.
Here is what I have :
3.6 (not working)
=================
name: dss_data4.dss_data4 (0x480020e4/0x0b4 = 0x0000), b ag24, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0
signals: dss_data4 | NA | uart3_rx_irrx | NA | gpio_74 | NA | NA | safe_mode
name: uart3_rx_irrx.uart3_rx_irrx (0x4800219e/0x16e = 0x0100), b h20, t NA
mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0
signals: uart3_rx_irrx | NA | NA | NA | gpio_165 | NA | NA | safe_mode
name: hsusb0_data1.hsusb0_data1 (0x480021ac/0x17c = 0x0100), b u28, t NA
mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0
signals: hsusb0_data1 | NA | uart3_rx_irrx | NA | gpio_130 | NA | NA | safe_mode
Complete boot log: http://code.bulix.org/76m2kn-82254?raw
3.2 (working)
=============
name: dss_data4.dss_data4 (0x480020e4/0x0b4 = 0x0000), b ag24, t NA
mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE0
signals: dss_data4 | NA | uart3_rx_irrx | NA | gpio_74 | NA | NA | safe_mode
name: uart3_rx_irrx.uart3_rx_irrx (0x4800219e/0x16e = 0x0100), b h20, t NA
mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0
signals: uart3_rx_irrx | NA | NA | NA | gpio_165 | NA | NA | safe_mode
name: hsusb0_data1.hsusb0_data1 (0x480021ac/0x17c = 0x0100), b u28, t NA
mode: OMAP_PIN_INPUT | OMAP_MUX_MODE0
signals: hsusb0_data1 | NA | uart3_rx_irrx | NA | gpio_130 | NA | NA | safe_mode
Complete boot log: http://code.bulix.org/kh0v71-82255?raw
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?
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2012-10-04 20:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-04 13:52 ttyO2 broken on IGEPv2 on 3.3, 3.4-rc5 or arm-soc/for-next, working on 3.2 Thomas Petazzoni
2012-05-04 16:27 ` Kevin Hilman
2012-05-04 17:51 ` Tony Lindgren
2012-05-04 23:46 ` Kevin Hilman
2012-10-04 16:07 ` Thomas Petazzoni
2012-10-04 17:18 ` Kevin Hilman
2012-10-04 20:11 ` Thomas Petazzoni [this message]
[not found] ` <CAKQ2WVp71=ULs_yK7Tkuo=8F4hATq0YCQ6RtV0ziJQQmnrib_g@mail.gmail.com>
2012-10-04 20:57 ` Thomas Petazzoni
2012-10-04 23:08 ` Kevin Hilman
2012-10-05 7:32 ` Javier Martinez Canillas
2012-10-05 8:10 ` Thomas Petazzoni
2012-10-05 10:01 ` Javier Martinez Canillas
2012-10-06 9:04 ` Enric Balletbò i Serra
2012-10-07 23:37 ` Javier Martinez Canillas
2012-10-04 23:06 ` Kevin Hilman
2012-10-05 8:06 ` Thomas Petazzoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121004221118.4316181d@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=eballetbo@iseebcn.com \
--cc=gregory.clement@free-electrons.com \
--cc=khilman@deeprootsystems.com \
--cc=linux-omap@vger.kernel.org \
--cc=maxime.ripard@free-electrons.com \
--cc=michael.opdenacker@free-electrons.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).