On Tue, Apr 17, 2012 at 7:11 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> Hi,
>
> Few more comments below.
>
> * Raja, Govindraj <govindraj.raja@xxxxxx> [120411 04:53]:
> ...
>
>> +static int __init omap_serial_fill_default_pads(struct omap_board_data *bdata,
>> + struct omap_uart_state *uart)
>> +{
>> + struct omap_mux_partition *tx_partition = NULL, *rx_partition = NULL;
>> + struct omap_mux *rx_mux = NULL, *tx_mux = NULL;
>> + char *rx_fmt, *tx_fmt;
>> + int uart_nr = bdata->id + 1;
>> +
>> + if (bdata->id != 2) {
>> + rx_fmt = "uart%d_rx.uart%d_rx";
>> + tx_fmt = "uart%d_tx.uart%d_tx";
>> + } else {
>> + rx_fmt = "uart%d_rx_irrx.uart%d_rx_irrx";
>> + tx_fmt = "uart%d_tx_irtx.uart%d_tx_irtx";
>> + }
>> +
>> + snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, rx_fmt,
>> + uart_nr, uart_nr);
>> + snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, tx_fmt,
>> + uart_nr, uart_nr);
>
> This naming won't work for the fourth port on 3630 as there are no "uart4_rx"
> or "uart4_tx" mux entries, they are "gpmc_wait2.uart4_tx" and
> "gpmc_wait3.uart4_tx".
But uart4 is unused on 3630 boards and boards trying to use them
should configure them from board file.
(I thought we agreed on this approach where only if uarts are
available in mux mode0 those ports will be dynamically muxed for wakeup
others should use omap_serial_init_port)
>
>> @@ -289,8 +354,8 @@ void __init omap_serial_board_init(struct
>> omap_uart_port_info *info)
>> bdata.pads = NULL;
>> bdata.pads_cnt = 0;
>>
>> - if (cpu_is_omap44xx() || cpu_is_omap34xx())
>> - omap_serial_fill_default_pads(&bdata);
>> + if (omap_serial_fill_default_pads(&bdata, uart))
>> + continue;
>>
>> if (!info)
>> omap_serial_init_port(&bdata, NULL);
>
> Can't the omap_serial_board_init() now be just be omap_serial_init(void)
> as it's not used anywhere else?
Yes sure we can remove that.
>
> Anyways, this is getting too complex for the -rc series as at least 2430sdp
> is using alternative pins for the first uart. Let's patch to remove just
> the uart4 entry for 3630 for the -rc and then we can properly fix this
> for the next merge window.
Okay. in that case the earlier patch [1] should be fine to solve the
gpmc issue observed
and ehci issue on beagle-xm.
--
Thanks,
Govindraj.R
[1]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/090961.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
