Message-ID: <CAErSpo6AFk71S38O6PAjbAO3P7JP2=D3THuatBhUq76unYV+tQ@mail.gmail.com>
Date:	Thu, 11 Aug 2011 15:49:18 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Jeff Chua <jeff.chua.linux@...il.com>
Cc:	Andrey Panin <pazke@...trinvest.ru>,
	lkml <linux-kernel@...r.kernel.org>,
	Matthew Garrett <mjg@...hat.com>
Subject: Re: How to access serial port that is set in BIOS as OS Controlled

On Thu, Aug 11, 2011 at 3:07 AM, Jeff Chua <jeff.chua.linux@...il.com> wrote:
>
>
> On Thu, Aug 11, 2011 at 12:46 AM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
>>
>> On Fri, Aug 5, 2011 at 7:02 PM, Jeff Chua <jeff.chua.linux@...il.com>
>
> wrote:
>>
>> Ping, just a reminder :)
>> I'm pretty sure Linux only runs _SRS when we actually *change* something,
>> which doesn't seem to follow the intent of the spec.  So if
>> we can get a little more evidence here, I think it'd be worth changing
>> Linux to call _SRS for every device when it enumerates it.
>
> I did some test and it seems "auto" didn't enable the port. With "auto",
> dmesg showed more info (io 0x3e8-0x3ef irq 6), but port still disabled.
>
> After "activate", then the port can be used.

Yep, that's what I would expect.  "auto" does some work in the kernel
to choose resources that look like they should work, but it doesn't
touch the firmware or the hardware itself.  "activate" evaluates the
ACPI _SRS method, which is how we tell the firmware what resources we
want.  The _SRS method would program those into the hardware.

> I've attached the DSDT.dat.dsl. I've reconfigured the kernel with
> CONFIG_PNP_DEBUG_MESSAGES=y, booting with "pnp.debug", but there were not a
> lot of messages in dmesg.

Oops, my mistake.  You now need "pnp.debug=1" to turn the extra debug
on (I just posted a patch to update
Documentation/kernel-parameters.txt).

> 00:0a PNP4972 (unknown)

> # cat /sys/bus/pnp/devices/00:0a/resources
> state = disabled
> io 0x3e8-0x3ef
> irq 6
>
> # setserial /dev/ttyS2 uart 16550a irq 6
> ttyS2: LSR safety check engaged!
> ttyS2: LSR safety check engaged!

Hmm, the fact that you need "setserial" is telling us there's another
Linux bug here.  PNP4972 is not one of the PNP IDs the 8250_pnp driver
knows about (I would have expected ACPI to supply a "compatible device
ID" of PNP0501 so we could fall back to the generic 8250_pnp driver),
so we currently don't have a path to get the I/O port address or the
IRQ info to the serial driver automatically.  On x86, the 8250 driver
has some hardcoded addresses compiled into it (ttyS2 at 0x3e8 being
one of them), and "setserial" is the manual way of changing the
default IRQ 4 to IRQ 6.

> # echo disable > /sys/bus/pnp/devices/00:0a/resources
>
> # dmesg
> pnp 00:0a: disabled
>
> # cat /sys/bus/pnp/devices/00:0a/resources
> state = disabled
>
> # echo activate > /sys/bus/pnp/devices/00:0a/resources
> -bash: echo: write error: Device or resource busy

This *should* work.  My guess is that it's failing because the I/O
ports at 0x3e8 are still reserved.  The PNP core doesn't actually
reserve anything, so it would have to be the 8250 driver.  It doesn't
mention those ports in dmesg, so maybe they get reserved when you do
the "setserial."  The 8250 driver has no idea that you disabled the
PNP device, so it would never release them.  Then when you try to
activate it again, they're still in use.  You can test this idea a
little bit by looking at /proc/ioports (1) immediately after boot, (2)
before "setserial", (3) after "setserial", and (4) after you disable
the PNP device.

I attached an experimental patch that add PNP4972 to the 8250_pnp
driver and tries to automatically activate devices.  Can you give it a
try (with "pnp.debug=1")?

Thanks,
  Bjorn

Download attachment "intermec-uart" of type "application/octet-stream" (1471 bytes)

Powered by blists - more mailing lists