[MinnowBoard] Need to disable both UART on LSE?

[Mika Westerberg]

On Sat, May 02, 2015 at 12:21:22PM -0300, Lucas De Marchi wrote:
> 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

Yes, there are cases where the BIOS either misconfigures pins or cannot
know all possible use cases. Minnowboard is good example of this, because
you can connect pretty much whatever you want to the "expansion" pin header.

That's the reason why we ended up relaxing those rules a bit (with
commit f8323b6).

The message itself is harmless but it allows us to see that some pin was
reconfigured against what the BIOS had (mis)configured previously.