lkml.org 
[lkml]   [2008]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] atmel_serial: update the powersave handler to match serial core
Hi,

----- Messaggio originale -----
> Da: Anti Sullin <anti.sullin@artecdesign.ee>
> A: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
> Cc: Michael Trimarchi <trimarchimichael@yahoo.it>; linux-serial@vger.kernel.org; linux-kernel@vger.kernel.org; Andrew Victor <linux@maxim.org.za>
> Inviato: Venerdì 19 settembre 2008, 23:49:29
> Oggetto: Re: [PATCH] atmel_serial: update the powersave handler to match serial core
>
> Haavard Skinnemoen wrote:
> > Michael Trimarchi wrote:
> >
> >>> I agree it would be useful. It would require changing the port mux
> >>> configuration from the driver though, and there's no standardized
> >>> interface for doing that. Maybe this is a good motivation to come up
> >>> with one?
> >>>
> >>>
> >> I think that a driver can do the request to a the gpio layer (may can be
> implemented
> >> by the gpio-lib ) and give it only the gpio. The "gpio-lib" can save and
> restore
> >> the status of the gpio, and request the handler, passing the gpio-id as
> >> a data. So when the handler fire, we can now which peripheral is
> >> interested on the wake-up event.
> >>
> >
> > I don't think the gpio layer is supposed to touch the portmux. David
> > has always been very clear about that. But if we somehow manage to get
> > the pin configured as a GPIO, we can use the GPIO layer to request a
> > pin change interrupt.
> >
> > It _might_ work even if you don't reconfigure the pin as a GPIO...but
> > then I think we'd be relying on undocumented behaviour.
> >
> I believe that you don't need to reconfigure the pin. The gpio hw does
> not require the pin to be multiplexed to any given state, so does not
> request_irq (correct?).
> I did this trick in my [2/3] MCI driver patch I sent to arm-linux-kernel at
> 18.03.2008 (the
> e-mail subject line was wrong, [1/3], though) and I'm using that patch still on
> my
> production devices to avoid some rare but critical SD data corruption (mainline
> kernel still
> screws up the filesystem on SD sometimes). The same should be easily usable on
> serial port, too.
>

I must to check this point. I do it few months ago, and if I remember I change
the serial configuration on rx line to a gpio and request and interrupt. I don't
have the hardware to recheck.

> >
> >>> Btw, I assume the first character you receive will be lost when you do
> >>> this, right?
> >>>
> >>>
> >> Yes, I haven't done a lot of test to see how many chars are lost (sure one I
> think).
> >> Depends on the time spent after
> >>
> >> /* Wait for interrupt to wake us up */
> >> mcr p15, 0, r0, c7, c0, 4
> >>
> >
> > Yes, we need to reach the atmel_serial resume handler before the UART
> > gets any chance to recognize the character. It's probably too late for
> > the first one, but it may catch the next one assuming the baud rate
> > isn't too high.
> >
> I believe, that we loose quite many characters. We are running at 32/16kHz
> (switching the master clock divider /2 off proved unstable) and
> this is not enough to even receive 9600 baud until we have the fast clock
> running again.
>
> Some quick calculations:
> For waking up, we need to switch on the main oscillator, wait until it
> stabilizes (default should be max: ~60ms), switch on plla, wait until it
> locks (2ms), switch on pllb, wait until it locks (2ms), switch system to PLLA...
> And then set up the drivers again... On 115200 baud, this is almost 1kB!
>
> So in many applications we could not use this. But this might still come handy
> in a lot of cases we can poll and find out what caused the data on the serial
> port etc. Or on applications, where this loss of data does not matter (like
> debug
> console where the resume is usable even if it does not wake up on the first
> byte).

Of course, but it is the same for all devices when you do a suspend with a
slow clock.

>
>
> --
> Anti Sullin
> Embedded Software Engineer
> Artec Design LLC
> Akadeemia tee 23A, 12618, Tallinn, Estonia
> http://www.artecdesign.ee

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2008-09-20 11:35    [W:0.041 / U:0.616 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site