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