[MinnowBoard] Need to disable both UART on LSE?

Lucas De Marchi lucas.de.marchi at gmail.com
Sat May 2 15:21:22 UTC 2015


On Fri, May 1, 2015 at 1:52 AM, Wei, David <david.wei at intel.com> wrote:
> From below error message, I assume you were trying to sue GPIO 74 on GPIO controller INT33FC.
> Actually this GPIO does NOT connect to Pin12 of MinnowBoard Max Low Speed Expander. It actually connects to pin 19 of MinnowBoard Max Low Speed Expander, which is shared by GPIO_S0_SC[074] and SIO_UART2_RXD.

this would be surprising because all I was doing was using the numbers
in Minnow Max wiki. And there the number 484 is the gpio number for
pin 12, which triggers this message.

> So that's why you have to disable UART2 to get this GPIO work.
>
> Pin 12 of LSE is connected to SIO_UART1_RTS# (or GPIO_S0_SC[072] ). It is GPIO 72 of GPIO controller INT33FC.

Also, in kernel 4.0 it's "working". The commit that makes it to work is:

f8323b6 pinctrl: baytrail: Relax GPIO request rules

It actually looks like a workaround for firmware bug. CC'ing Mika
here. It does gives me the warning the commit says:

Hardware name: Intel Corp. VALLEYVIEW A0 PLATFORM/NOTEBOOK, BIOS
MNW2CRB1.X64.0071.R30.1408131301 08/13/2014
 ffffffff81cf7f58 ffff8800712f7d28 ffffffff818e6b26 0000000080000000
 0000000000000000 ffff8800712f7d68 ffffffff8107408a ffff8800712f7d58
 ffffc9000003c060 ffff880077b22618 0000000000000001 000000000000004a
Call Trace:
 [<ffffffff818e6b26>] dump_stack+0x4f/0x7b
 [<ffffffff8107408a>] warn_slowpath_common+0x8a/0xc0
 [<ffffffff8107417a>] warn_slowpath_null+0x1a/0x20
 [<ffffffff8133f521>] byt_gpio_request+0x91/0xe0
 [<ffffffff81340287>] __gpiod_request+0x87/0x110
 [<ffffffff813426a3>] gpiod_request+0x53/0x90
 [<ffffffff818ee6c8>] ? _raw_spin_unlock_irqrestore+0x18/0x30
 [<ffffffff81343658>] export_store+0x48/0xe0
 [<ffffffff8118ae4e>] ? __kmalloc+0x2e/0x1b0
 [<ffffffff814d69bb>] class_attr_store+0x1b/0x30
 [<ffffffff8120201a>] sysfs_kf_write+0x3a/0x50
 [<ffffffff81201b37>] kernfs_fop_write+0x127/0x180
 [<ffffffff81192663>] vfs_write+0xb3/0x1d0
 [<ffffffff811931d6>] SyS_write+0x46/0xb0
 [<ffffffff81044e9c>] ? do_page_fault+0xc/0x10
 [<ffffffff818ef0b2>] system_call_fastpath+0x12/0x17
---[ end trace 1d825647609cd5ed ]---
byt_gpio INT33FC:00: pin 74 forcibly re-configured as GPIO


Here is what I have just after boot in /sys/kernel/debug/gpio:

with the patch (just after booting):
 gpio-74  (Unrequested         ) in     lo pad-6   offset:0x060 mux:1
                up   20k

with the patch (after exporting gpio 484, which should be pin 12
according to the wiki):
 gpio-74  (sysfs               ) in     hi pad-6   offset:0x060 mux:0
                up   20k

3.19.5, without the patch (the same after the failed export):
 gpio-74  (Unrequested         ) in     lo pad-6   offset:0x060 mux:1
                up   20k

I'm leaving the rest of the thread below so Mika can take a look

thanks

-- 
Lucas De Marchi

>
>
> [   11.943332] byt_gpio INT33FC:00: pin 74 cannot be used as GPIO.
> -bash: echo: write error: Invalid argument
>
> Thanks,
> David | SSG BIOS
>
>
>
>
>
>
> -----Original Message-----
> From: elinux-MinnowBoard [mailto:elinux-minnowboard-bounces at lists.elinux.org] On Behalf Of Lucas De Marchi
> Sent: Wednesday, April 29, 2015 6:28 AM
> To: MinnowBoard Development and Community Discussion
> Subject: [MinnowBoard] Need to disable both UART on LSE?
>
> Hi,
>
> Do I need to disable both UART1 and UART2 in UEFI in order to be able to use pin 12 in the LSE (GPIO_UART1_RTS)?  If I disable only UART1 I still can't use it:
>
> [root at localhost ~]# echo 484 > /sys/class/gpio/export
> [   11.943332] byt_gpio INT33FC:00: pin 74 cannot be used as GPIO.
> -bash: echo: write error: Invalid argument
>
> Pin 10 works fine though.
>
> The only way I'm able to use pin 12 as GPIO is if I disable both UART1
> *and* UART2.
>
> Also I'm surprised I actually have to disable any of them since pin 12 is RTS. Wouldn't it be sufficient to disable flow control?
>
> Here I have kernel 3.19.5 and firmware 0.77.  I also tried updating to
> 0.79 with no difference in behavior.
>
>
> thanks
>
> --
> Lucas De Marchi
> _______________________________________________
> elinux-MinnowBoard mailing list
> elinux-MinnowBoard at lists.elinux.org
> http://lists.elinux.org/mailman/listinfo/elinux-minnowboard
> _______________________________________________
> elinux-MinnowBoard mailing list
> elinux-MinnowBoard at lists.elinux.org
> http://lists.elinux.org/mailman/listinfo/elinux-minnowboard


More information about the elinux-MinnowBoard mailing list