Re: f81216

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bruno,

I found the answer to my problem ages ago, just forgot to let you
know. The UART clock is coming from Platform Clock 1 from the Bay
Trail processor and by default this is disabled - simple as that :)

Cheers, Phil


On 10 December 2014 at 07:10, Bruno Prémont <bonbons@xxxxxxxxxxxxxxxxx> wrote:
> Hi Philip,
>
> On Tue, 9 Dec 2014 21:20:47 +0000 Philip Boucherat wrote:
>> Yes I think you're right, there is a problem with the BIOS.
>>
>> I think for now (until I can get the BIOS fixed) I can use your platform
>> driver and add the f81216_configure() routine below. Call this from the
>> __init routine and register the resources for each port, or I could add a
>> probe() function to do this. Does that sound like a good plan?
>
> The most important part is to advertise the UARTs. For that you will
> need to register your ports (serial8250_register_8250_port() from
> drivers/tty/serial/8250/8250_core.c).
>
> Take a look at the other 8250 drivers for usage samples.
>
> Though remember to reconfigure your ports on resume (and possibly
> disable them on suspend).
>
> Cheers,
> Bruno
>
>> Cheers, Phil
>>
>> /* Set up as per example in F81216 data sheet.
>>  * Clock in used 48MHz, UART 1-4 address(0x3f8, 0x2f8, 0x3e8, 0x2e8, IRQ(3,
>> 4, 5, 9)
>>  * Entry key is 0x77. Watchdog not enabled.
>>  */
>> void f81216_configure(void)
>> {
>> superio_enter();
>>
>> superio_outb(0x01, 0x25); //Set bit 0 to 1 select clock input to 48MHz
>>
>> superio_outb(0x00, 0x07); //Select LDN 0
>> superio_outb(0x03, 0x60); //Set UART 1 base address high byte to 0x03
>> superio_outb(0xf8, 0x61); //Set UART 1 base address low byte to 0xf8
>> superio_outb(0x03, 0x70); //Set UART 1 interrupt channel to IRQ 3
>> superio_outb(0x01, 0x30); //Enable UART 1 TODO: Disable legacy UART @ 0x3f8
>>
>> superio_outb(0x01, 0x07); //Select LDN 1
>> superio_outb(0x02, 0x60); //Set UART 2 base address high byte to 0x02
>> superio_outb(0xf8, 0x61); //Set UART 2 base address low byte to 0xf8
>> superio_outb(0x04, 0x70); //Set UART 2 interrupt channel to IRQ 4
>> superio_outb(0x01, 0x30); //Enable UART 2
>>
>> superio_outb(0x02, 0x07); //Select LDN 2
>> superio_outb(0x03, 0x60); //Set UART 3 base address high byte to 0x03
>> superio_outb(0xe8, 0x61); //Set UART 3 base address low byte to 0xe8
>> superio_outb(0x05, 0x70); //Set UART 3 interrupt channel to IRQ 5
>> superio_outb(0x01, 0x30); //Enable UART 3
>>
>> superio_outb(0x03, 0x07); //Select LDN 3
>> superio_outb(0x02, 0x60); //Set UART 4 base address high byte to 0x02
>> superio_outb(0xe8, 0x61); //Set UART 4 base address low byte to 0xe8
>> superio_outb(0x09, 0x70); //Set UART 4 interrupt channel to IRQ 9
>> superio_outb(0x01, 0x30); //Enable UART 4
>>  superio_exit();
>> }
>>
>>
>>
>> On 9 December 2014 at 07:06, Bruno Prémont <bonbons@xxxxxxxxxxxxxxxxx>
>> wrote:
>>
>> > Hi Philip,
>> >
>> > On Mon, 8 Dec 2014 20:41:12 +0000 Philip Boucherat wrote:
>> > > Thanks for replying. Not sure how to reply on the spinics.net mailing
>> > list,
>> > > but will update on archlinux mailing list.
>> >
>> > Reply-To-All should be sufficient. Mailinglist is @vger.kernel.org.
>> >
>> > > Anyway, am making some progress, I just ran your test program and the
>> > chip
>> > > is detected ok :
>> > >
>> > > Calling ioperm(4e, 2, 1): 0 (Success)
>> > >
>> > > Activating configuration mode.
>> > >
>> > > Global registers:
>> > >   Software Reset      (0x02): 0x0
>> > >   Logic Device Select (0x07): 0x3
>> > >   Device ID           (0x20, 0x21): 0x28
>> > >   Vendor ID           (0x23, 0x24): 0x1934
>> > >   Clock Source Select (0x25): 0x0
>> > >   Test mode           (0x2f): 0x0
>> > >
>> > > UART 1 registers:
>> > >   Logic Device Select (0x07): 0x0
>> > >   Device Enable       (0x30): 0x0
>> > >   I/O Port Select     (0x60, 0x61): 0x00
>> > >   IRQ Channel Select  (0x70): 0x0
>> > >   Clock Select        (0xf0): 0x0
>> > >   IR1 Control         (0xf1): 0x44
>> > >
>> > > UART 2 registers:
>> > >   Logic Device Select (0x07): 0x1
>> > >   Device Enable       (0x30): 0x0
>> > >   I/O Port Select     (0x60, 0x61): 0x00
>> > >   IRQ Channel Select  (0x70): 0x0
>> > >   Clock Select        (0xf0): 0x0
>> > >
>> > > UART 3 registers:
>> > >   Logic Device Select (0x07): 0x2
>> > >   Device Enable       (0x30): 0x0
>> > >   I/O Port Select     (0x60, 0x61): 0x00
>> > >   IRQ Channel Select  (0x70): 0x0
>> > >   Clock Select        (0xf0): 0x0
>> > >
>> > > UART 4 registers:
>> > >   Logic Device Select (0x07): 0x3
>> > >   Device Enable       (0x30): 0x0
>> > >   I/O Port Select     (0x60, 0x61): 0x00
>> > >   IRQ Channel Select  (0x70): 0x0
>> > >   Clock Select        (0xf0): 0x0
>> > > Leaving configuration mode.
>> >
>> > So everything is disabled/uninitialized...
>> >
>> > > 8250_pnp is not finding the ports, but I think that's because I can't
>> > seem
>> > > to change the BIOS settings on this board, there is an option to enable
>> > PnP
>> > > for these UARTs but if I change this setting it always reverts to
>> > disabled.
>> > > However, now I know the device is accessible, I should be able to do
>> > > something about it, but if you can give any more advice that would be
>> > great!
>> >
>> > Weird. In case it helps, in 3.18 there is a new driver for f81216a which
>> > at least aims at making RS485 features available/configurable.
>> > Looking at its code though it's depending on the ports being registered
>> > as PNP0501 devices.
>> >
>> > What do the PNP settings for the ports look like in BIOS interface?
>> > Does the manual tell something about them? It would be preferred to be able
>> > to enable them in BIOS! Maybe ask your mainboard vendor for help, if it's a
>> > BUG in their BIOS they might release a new BIOS revision (possibly
>> > without admitting the issue).
>> >
>> >
>> > Cheers,
>> > Bruno
>> >
>> >
>> > > Cheers, Phil
>> > >
>> > >
>> > > On 5 December 2014 at 11:57, Bruno Prémont wrote:
>> > > > Hi Philip,
>> > > >
>> > > > With that information I can, at best, only provide some very limited
>> > > > guidance.
>> > > >
>> > > > On 4 December 2014 at 23:26, Philip Boucherat wrote:
>> > > > > Sorry for the unsolicited email, but it seems like you may be able to
>> > > > help
>> > > > > me.
>> > > >
>> > > > Try to always CC subsystem mailing list, that way someone else hitting
>> > your
>> > > > issue will be able to find the solution or at least can chime in.
>> > > >
>> > > > > I am working with an x86_64 board which has got an F81216 quad UART
>> > > > > chip on it and I need to get these serial ports to work.
>> > > > >
>> > > > > I'm doing a arch linux build of the 3.17 kernel (I think) and have
>> > > > enabled
>> > > > > 8250_PNP or whatever it is (sorry, haven't got access to my dev
>> > machine
>> > > > at
>> > > > > the moment), but it is not detecting the serial ports.
>> > > > >
>> > > > > This is a Intel Atom E3800 and the lpc_ich module is loaded, PCU is
>> > > > > detected when I do lspci, so I'm kind of thinking it should all
>> > work, but
>> > > > > it's not. Ports not detected at all.
>> > > >
>> > > > If you could provide kernel log (dmesg) and a reference to the
>> > mainboard
>> > > > documentation that might already help.
>> > > > The CPU/SOC documentation is not that helpful.
>> > > >
>> > > > From the software side, your best bet would be to start poking at the
>> > IO
>> > > > space to see if the F81216 is responding/reachable.
>> > > > If it's not, maybe you need to power it up using some GPIO, though that
>> > > > information should hopefully be present in the mainboard's Datasheet.
>> > > >
>> > > > Datasheet of the F81216:
>> > > >   http://www.fintek.com.tw/files/productfiles/F81216_V035P.pdf
>> > > > My test code as written years ago:
>> > > >   https://bugzilla.kernel.org/show_bug.cgi?id=13008#c9
>> > > >   (also read comment #11 for the second  configuration address
>> > > >    and adjust text code accordingly when testing!)
>> > > >
>> > > > Please post the output from test program for both IO ports (0x4e and
>> > 0x2e).
>> > > >
>> > > > > Do I need to do some extra kernel config? Do I need to add your
>> > platform
>> > > > > driver to the kernel build?
>> > > >
>> > > > If BIOS/firmware has setup the mainboard and all resources you don't
>> > need
>> > > > any specific kernel config (except not limiting UART count too much):
>> > > >   CONFIG_SERIAL_8250_NR_UARTS
>> > > >   CONFIG_SERIAL_8250_RUNTIME_UARTS
>> > > >
>> > > > If the UARTs are not reported as PNP resources 8250_PNP will not find
>> > them
>> > > > and you will need some extra work to get them hooked up (probably a
>> > > > platform driver to write).
>> > > >
>> > > > Cheers,
>> > > > Bruno
>> > > >
>> > > >
>> > > > > Any help very much appreciated!
>> > > > >
>> > > > > Cheers Phil
>> > > >
>> >
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux