cpm_uart non-console problem with write on 2nd open..
Vitaly Bordug
vbordug at ru.mvista.com
Thu Sep 14 23:37:51 EST 2006
On Thu, 14 Sep 2006 16:30:44 +0300
"Alexandros Kostopoulos" <akostop at inaccessnetworks.com> wrote:
> I'm experiencing a problem with the 2.6.13 cpm_uart driver. When opening
> the device for the second time after the driver was inserted, if only a
> few bytes are sent for transmission and the device is then closed, the
> tx_empty routine called by shutdown returns 0 and the latter hangs in the
> while loop with the call to cpm_uart_tx_empty. No bytes are actually
> transmitted from the uart.
>
It was addressed a while ago, fix should be in the latest stable kernel rev. for certain.
The snippet below was not the only thing to get problem completely resolved;
You may glance at the code within current kernel, if still experiencing problems.
Thanks, Vitaly
> I found out that the difference between the first and subsequent open
> calls is that during the first time (and until the first shutdown) the
> transmitter is enabled in GSMRL. From this point on, the transmitter is
> initially disabled on startup. Thus, if only a few bytes are queued for
> transmission before shutdown and a TX interrupt is not triggered, the
> bytes are never sent, and thus the shutdown function hangs on the
> cpm_uart_tx_empty loop.
>
> The fix that works for me is the following:
>
> Index: drivers/serial/cpm_uart/cpm_uart_core.c
> ===================================================================
> --- drivers/serial/cpm_uart/cpm_uart_core.c (revision 106)
> +++ drivers/serial/cpm_uart/cpm_uart_core.c (working copy)
>
> @@ -394,7 +394,7 @@ static int cpm_uart_startup(struct uart_
> pinfo->smcp->smc_smcmr |= SMCMR_REN;
> } else {
> pinfo->sccp->scc_sccm |= UART_SCCM_RX;
> - pinfo->sccp->scc_gsmrl |= (SCC_GSMRL_ENR);
> + pinfo->sccp->scc_gsmrl |= (SCC_GSMRL_ENR | SCC_GSMRL_ENT);
>
> }
>
> Any comments would be greatly appreciated
>
> thank you
>
> Alex
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
--
Sincerely,
Vitaly
More information about the Linuxppc-dev
mailing list