Re: [PATCH] atmel_serial: update the powersave handler to match serial core

Haavard Skinnemoen wrote:
Michael Trimarchi <trimarchimichael@xxxxxxxx> 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.

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).


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


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

Relevant Pages

  • Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls
    ... For OMAP, those names can map one-to-one to integers. ... So the "gpio number" in AT91 would, as it turns out, also encode the line number in the lower 6 bits, and the controller number in the bits above that. ... Perhaps yet another reason why the gpio_request function might want to look at the hardware state--- so that drivers that aren't using the new API are still known to the GPIO resource manager by virtue of the signature they leave behind in the hardware configuration (you might not be able to detect that they're using a GPIO line, but you would be able to detect that a pin had been assigned to a non-GPIO function). ... HOW that is established is indeed explicitly left out of the driver itself, but it's awfully nice when there's a facility somewhere that can do it on the driver's behalf. ...
    (Linux-Kernel)
  • Re: [PATCH] atmel_serial: update the powersave handler to match serial core
    ... I think that a driver can do the request to a the gpio layer (may can be ... I don't think the gpio layer is supposed to touch the portmux. ... pin change interrupt. ... For waking up, we need to switch on the main oscillator, wait until it ...
    (Linux-Kernel)
  • [patch -mm 00/20] chardev: GPIO for SCx200 & PC8736x: Intro
    ... GPIO SUPPORT FOR SCx200 & PC8736x ... The patch-set reworks the 2.4 vintage scx200_gpio driver for modern ... The vintage driver expresses the pin capabilities with pin-mode ...
    (Linux-Kernel)
  • Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls
    ... driver can can talk to the attached external hardware. ... Updating the GPIO controller is always done in terms ... of a number mapping to some controller and a bit number, ... drivers never care about pins. ...
    (Linux-Kernel)
  • Re: how to design PIN diode driver - high voltage and high speed
    ... So i have to design the switch by myself. ... I am going to employ discrete MOSFET as driver. ... What's the carrier lifetime of the PIN switches you'll be using? ...
    (sci.electronics.design)