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

Anti Sullin <anti.sullin@xxxxxxxxxxxxxx> wrote:
Haavard Skinnemoen wrote:
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.

You're right. It works, and it's documented. I don't think it's
guaranteed by the GPIO API, but as long as it's guaranteed on AT91 and
AVR32, we should be fine.

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

Yes, as long as you have some sort of timeout/retry mechanism in place,
it might be useful.

Haavard
--
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 -mm 20/20 RFC] chardev: GPIO for SCx200 & PC-8736x: add sysfs-GPIO interf
    ... We need a standard rep for GPIO in sysfs, ... GPIO hardware design appears to have 2 top-level factors; ... change will also exhibit in the port attr too. ... if a pin is output only, it shouldnt have an _output_enabled attr. ...
    (Linux-Kernel)
  • [patch -mm 20/20 RFC] chardev: GPIO for SCx200 & PC-8736x: add sysfs-GPIO interface
    ... We need a standard rep for GPIO in sysfs, ... GPIO hardware design appears to have 2 top-level factors; ... change will also exhibit in the port attr too. ... if a pin is input only, it shouldnt have an _output_enabled attr. ...
    (Linux-Kernel)
  • [RFC/PATCH] arch-neutral GPIO calls: AVR32 implementation [take 2]
    ... Even though it is possible to tell from the hardware whether a pin is ... set up for GPIO, I decided to use two allocation bitmasks per pio ... The pin configuration API is AVR32-specific for now. ... +int gpio_request ...
    (Linux-Kernel)
  • Re: [RFC/PATCH] arch-neutral GPIO calls: AVR32 implementation
    ... in terms of pin setup it's way nicer. ... MUX so that a given GPIO can get to a specified pin. ... since machines do that so differently. ...
    (Linux-Kernel)
  • 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)