SH7722 serial scif

SH7722 serial scif

[Michael Trimarchi]

Hi,

I find a problem releated to the scif serial device. Using scif2 on the MigoR, the kernel block on the second open of the device
when it try to register irq line. So in the shutdown sequence I add:

 sci_out(port, SCSCR, 0x00);

and in the startup squence:

 sci_out(port, SCSCR, SCSCR_INIT(port));

The version is 2.6.24.2 but I think is present in the latest release too.

My idea is to post a patch to register and enable and disable for the scif port on the SH7722. Can be a problem
for other micro?

Regards Michael

__________________________________________________
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi 
http://mail.yahoo.it 

Re: SH7722 serial scif

[Paul Mundt]

On Wed, Sep 24, 2008 at 02:52:05PM +0000, Michael Trimarchi wrote:
> I find a problem releated to the scif serial device. Using scif2 on the
> MigoR, the kernel block on the second open of the device when it try to
> register irq line. So in the shutdown sequence I add:
> 
>  sci_out(port, SCSCR, 0x00);
> 
> and in the startup squence:
> 
>  sci_out(port, SCSCR, SCSCR_INIT(port));
> 
> The version is 2.6.24.2 but I think is present in the latest release too.
> 
> My idea is to post a patch to register and enable and disable for the
> scif port on the SH7722. Can be a problem for other micro?
> 
I'm not entirely sure I follow what the problem is, so yes, a patch would
help. It sounds like you are running in to a problems trying to do multiple
opens on the same port where request_irq() returns -EBUSY or some such
thing? I don't immediately see how that would be happening, so perhaps
I'm misunderstanding your problem.

Re: SH7722 serial scif

[Michael Trimarchi]

Hi,



----- Messaggio originale -----
> Da: Paul Mundt <lethal@linux-sh.org>
> A: Michael Trimarchi <trimarchimichael@yahoo.it>
> Cc: linux-sh@vger.kernel.org
> Inviato: Mercoledì 24 settembre 2008, 17:49:01
> Oggetto: Re: SH7722 serial scif
> 
> On Wed, Sep 24, 2008 at 02:52:05PM +0000, Michael Trimarchi wrote:
> > I find a problem releated to the scif serial device. Using scif2 on the
> > MigoR, the kernel block on the second open of the device when it try to
> > register irq line. So in the shutdown sequence I add:
> > 
> >  sci_out(port, SCSCR, 0x00);
> > 
> > and in the startup squence:
> > 
> >  sci_out(port, SCSCR, SCSCR_INIT(port));
> > 
> > The version is 2.6.24.2 but I think is present in the latest release too.
> > 
> > My idea is to post a patch to register and enable and disable for the
> > scif port on the SH7722. Can be a problem for other micro?
> > 
> I'm not entirely sure I follow what the problem is, so yes, a patch would
> help. It sounds like you are running in to a problems trying to do multiple
> opens on the same port where request_irq() returns -EBUSY or some such
> thing? I don't immediately see how that would be happening, so perhaps
> I'm misunderstanding your problem.

The problem is much simple. The code does't exit from the request_irq. I suppose,
that kernel receive a very high number of interrupt requests. So this is the sequence:

---->uart_open(2)
           |
             \-------request_irq
          |
          \------- start_tx

The first time the code run without problem. ( I recevive a packet of one byte every 60ms)

The simple program exit without problem.

I run again the program with this result:
---->uart_open(2)
            |
           \------request_irq

Never exist. So I think is releated to the shutdown sequence and startup. Adding
the code above the problem disappear. 

Is ok now this description?

Regards Michael

__________________________________________________
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi 
http://mail.yahoo.it 

Re: SH7722 serial scif

[Paul Mundt]

On Wed, Sep 24, 2008 at 03:57:03PM +0000, Michael Trimarchi wrote:
> The problem is much simple. The code does't exit from the request_irq. I suppose,
> that kernel receive a very high number of interrupt requests. So this is the sequence:
> 
> ---->uart_open(2)
>            |
>              \-------request_irq
>           |
>           \------- start_tx
> 
> The first time the code run without problem. ( I recevive a packet of one byte every 60ms)
> 
> The simple program exit without problem.
> 
> I run again the program with this result:
> ---->uart_open(2)
>             |
>            \------request_irq
> 
> Never exist. So I think is releated to the shutdown sequence and startup. Adding
> the code above the problem disappear. 
> 
> Is ok now this description?
> 
Ok, that's interesting. There are a couple things to consider here:

	- startup/shutdown both set and clear the RX and TX IRQ enable
	  bits
	- the base SCSCR initialization is maintained across the lifetime
	  of the port, and is directly manipulated by the termios value.

We need the initialization in the set_termios path for things like the
system console, which can be suspended/resumed, as well as handling
rate changes directly (not related to the frequency notifier).

Given that, moving this out to the startup/shutdown path is definitely
not what we want to do, but we do need to figure out what your SCSCR
register state is at the time of startup and shutdown. There are a couple
of possibilities:

	- IRQ not properly acked and cleared at shutdown time, despite
	  the TX/RX bits being cleared.
	- Some bit setting in the SCSCR_INIT definition for your platform
	  that we need to be more careful in handling.

If we look at the setting for 7722, it's the usual mix of TE/RE/REIE and
nothing particularly exotic, so we can probably just swallow these up in
the sci_start_tx/rx()/sci_stop_tx/rx() pairs, and that should
subsequently get your SCSCR value pretty much back to 0 at shutdown time.

Re: SH7722 serial scif

[Michael Trimarchi]

Hi,

...


> Ok, that's interesting. There are a couple things to consider here:
> 
>     - startup/shutdown both set and clear the RX and TX IRQ enable
>       bits
>     - the base SCSCR initialization is maintained across the lifetime
>       of the port, and is directly manipulated by the termios value.
> 
> We need the initialization in the set_termios path for things like the
> system console, which can be suspended/resumed, as well as handling
> rate changes directly (not related to the frequency notifier).
> 
> Given that, moving this out to the startup/shutdown path is definitely
> not what we want to do, but we do need to figure out what your SCSCR
> register state is at the time of startup and shutdown. There are a couple
> of possibilities:
> 
>     - IRQ not properly acked and cleared at shutdown time, despite
>       the TX/RX bits being cleared.
>     - Some bit setting in the SCSCR_INIT definition for your platform
>       that we need to be more careful in handling.
> 
> If we look at the setting for 7722, it's the usual mix of TE/RE/REIE and
> nothing particularly exotic, so we can probably just swallow these up in
> the sci_start_tx/rx()/sci_stop_tx/rx() pairs, and that should
> subsequently get your SCSCR value pretty much back to 0 at shutdown time.

After revert my code, and take a look to the SCSCR register before
open and shutdown, this is the result. 

I found a SCSCR equal to 0x38 after and before, so the bit are not cleared but if I do an sci_out of 0
to the register, all seems to be ok.

It is very strange, it seems the SCSCR status does't change
after the sci_stop_tx e sci_stop_rx


Any idea?

Regards Michael

__________________________________________________
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi 
http://mail.yahoo.it 

Re: SH7722 serial scif

[Magnus Damm]

On Thu, Sep 25, 2008 at 6:17 PM, Michael Trimarchi
<trimarchimichael@yahoo.it> wrote:
>> Ok, that's interesting. There are a couple things to consider here:
>>
>>     - startup/shutdown both set and clear the RX and TX IRQ enable
>>       bits
>>     - the base SCSCR initialization is maintained across the lifetime
>>       of the port, and is directly manipulated by the termios value.
>>
>> We need the initialization in the set_termios path for things like the
>> system console, which can be suspended/resumed, as well as handling
>> rate changes directly (not related to the frequency notifier).
>>
>> Given that, moving this out to the startup/shutdown path is definitely
>> not what we want to do, but we do need to figure out what your SCSCR
>> register state is at the time of startup and shutdown. There are a couple
>> of possibilities:
>>
>>     - IRQ not properly acked and cleared at shutdown time, despite
>>       the TX/RX bits being cleared.
>>     - Some bit setting in the SCSCR_INIT definition for your platform
>>       that we need to be more careful in handling.
>>
>> If we look at the setting for 7722, it's the usual mix of TE/RE/REIE and
>> nothing particularly exotic, so we can probably just swallow these up in
>> the sci_start_tx/rx()/sci_stop_tx/rx() pairs, and that should
>> subsequently get your SCSCR value pretty much back to 0 at shutdown time.
>
> After revert my code, and take a look to the SCSCR register before
> open and shutdown, this is the result.
>
> I found a SCSCR equal to 0x38 after and before, so the bit are not cleared but if I do an sci_out of 0
> to the register, all seems to be ok.
>
> It is very strange, it seems the SCSCR status does't change
> after the sci_stop_tx e sci_stop_rx
>
>
> Any idea?

This may be far off, but is the MSTPCR clock stop bit setup properly
for your particular SCIF channel?

/ magnus