All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@deeprootsystems.com>
To: Thomas Petazzoni <thomas.petazzoni@free-electrons.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, 04 Oct 2012 10:18:04 -0700	[thread overview]
Message-ID: <87vcequpf7.fsf@deeprootsystems.com> (raw)
In-Reply-To: <20121004180747.3b342904@skate> (Thomas Petazzoni's message of "Thu, 4 Oct 2012 18:07:47 +0200")

Hi Thomas,

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

> Kevin,
>
> Reviving an old thread.
>
> On Fri, 04 May 2012 16:46:32 -0700, Kevin Hilman wrote:
>
>> >> Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>> >> 
>> >> > I have an IGEPv2 revision 6 board, which uses the DM3730 OMAP3.
>> >> > With 3.2 omap2plus_defconfig, the system boots fine and have a
>> >> > working shell on ttyO2. On either 3.3, 3.4-rc5 or
>> >> > arm-soc/for-next from Arnd, the system boots all the way up to
>> >> > showing the shell prompt, but I can't type any character, as if
>> >> > UART RX was broken.
>> >> 
>> >> On v3.4-rc, can you see if reverting
>> >> bce492c04ba8fc66a4ea0a52b181ba255daaaf54 has any effect?
>> >> 
>> >> That patch had some unfortunate side effects, but I haven't seen
>> >> the problem you see, so I'm not sure if it's related.
>> >
>> > Reverting bce492c04ba8fc66a4ea0a52b181ba255daaaf54 is a broken
>> > solution like you mentioned. But if it helps, then the proper fix
>> > is to add muxing to board-*.c files for the uart pins and use
>> > omap_serial_init_port for each uart instead of omap_serial_init.
>> > That should fix the wake-up issues too.
>> 
>> I agree on the final solution, but just wanted to see if the missing
>> mux (and thus disabled runtime PM) is what's causing the problem.
>
> FWIW, I tried the recently released 3.6 kernel on this platform
> (IGEPv2, OMAP3-based), and I still see the same problem. Upon Tony's
> suggestion, I tried to add some code in board-igep0020.c similar to the
> one in board-n8x0.c to do the appropriate UART2 muxing, but it doesn't
> seem to improve the situation. I did the following change (note that I
> tried with both .name = "uart2_rx_irrx.uart2_rx_irrx" and .name =
> "uart3_rx_irrx.uart3_rx_irrx"). On this board, the console is on ttyO2.
> This is with the plain omap2plus_defconfig, so CONFIG_OMAP_MUX is
> enabled.
>
> Any idea of things to try? This board has been broken since 3.2, so I'd
> like to get it fixed at some point :-)

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.

Kevin

[1] http://www.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZV.zip

> diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
> index 2821448..568f13e 100644
> --- a/arch/arm/mach-omap2/board-igep0020.c
> +++ b/arch/arm/mach-omap2/board-igep0020.c
> @@ -558,6 +558,43 @@ static struct omap_board_mux board_mux[] __initdata = {
>  	OMAP3_MUX(MCSPI1_CS2, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
>  	{ .reg_offset = OMAP_MUX_TERMINATOR },
>  };
> +
> +static struct omap_device_pad serial2_pads[] __initdata = {
> +	{
> +		.name	= "uart2_rx_irrx.uart2_rx_irrx",
> +		.flags	= OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
> +		.enable	= OMAP_MUX_MODE0,
> +		.idle	= OMAP_MUX_MODE3	/* Mux as GPIO for idle */
> +	},
> +};
> +
> +static inline void board_serial_init(void)
> +{
> +	struct omap_board_data bdata;
> +
> +	bdata.flags = 0;
> +	bdata.pads = NULL;
> +	bdata.pads_cnt = 0;
> +
> +	bdata.id = 0;
> +	omap_serial_init_port(&bdata, NULL);
> +
> +	bdata.id = 1;
> +	omap_serial_init_port(&bdata, NULL);
> +
> +	bdata.id = 2;
> +	bdata.pads = serial2_pads;
> +	bdata.pads_cnt = ARRAY_SIZE(serial2_pads);
> +	omap_serial_init_port(&bdata, NULL);
> +}
> +
> +#else
> +
> +static inline void board_serial_init(void)
> +{
> +	omap_serial_init();
> +}
> +
>  #endif
>  
>  #if defined(CONFIG_LIBERTAS_SDIO) || defined(CONFIG_LIBERTAS_SDIO_MODULE)
> @@ -621,7 +658,7 @@ static void __init igep_init(void)
>  	/* Register I2C busses and drivers */
>  	igep_i2c_init();
>  	platform_add_devices(igep_devices, ARRAY_SIZE(igep_devices));
> -	omap_serial_init();
> +	board_serial_init();
>  	omap_sdrc_init(m65kxxxxam_sdrc_params,
>  				  m65kxxxxam_sdrc_params);
>  	usb_musb_init(NULL);

  reply	other threads:[~2012-10-04 17:18 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 [this message]
2012-10-04 20:11           ` Thomas Petazzoni
     [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=87vcequpf7.fsf@deeprootsystems.com \
    --to=khilman@deeprootsystems.com \
    --cc=eballetbo@iseebcn.com \
    --cc=gregory.clement@free-electrons.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=maxime.ripard@free-electrons.com \
    --cc=michael.opdenacker@free-electrons.com \
    --cc=thomas.petazzoni@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.