adding 16550 UART to RM9200

[Bernd Walter]

On Tue, Apr 03, 2007 at 10:07:32AM -0600, Warner Losh wrote:
> From: Bernd Walter <ticso at cicely12.cicely.de>
> Subject: adding 16550 UART to RM9200
> Date: Tue, 3 Apr 2007 17:48:58 +0200
> I'd consider creating a puc device that attaches to the atmelarm bus.
> This device would need to manage the resources for the sub devices in
> a minimal way (take a look at pccard_puc for a simple example).  The
> advantage to doing this is that you also get the clock frequency as a
> parameter for free.  You'll likely need to have a custom ISR routine,
> depending on the details of the interrupt structure.  If there's no
> external way to know quickly which of the parts interrupted, you may
> be OK with the default one.

puc looks like a good idea - it has almost everything I need.

The hardware is more complex than the simplification I described.
The board will get a SMC buffer with 5V translation plus subaddress
decoding added.
Up to 6 daughter boards can be added via short ribbon cable containing
8 ports each.
Having a puc attachment per daugther board sounds most reasonable.
I thought about an interrupt location register, but the distributed
system makes it a bit difficult.
The easiest thing seem to be adding a register per daughter board,
which holds the bits of the 8 ports.
This still requires polling up to 6 registers per interrupt though, but
it is much better than polling 48.
I might consider running only 3 boards on IRQ0 and the other 3 on IRQ3.
Although the RM9200 has 7 external interrupts (not counting FIQ), the
remaining IRQ* all collide :(
- IRQ0  unshared
- IRQ1	TWCK needed for my external RTC
- IRQ2  TWD same as above
- IRQ3  TXD2 I can easily accept loosing this UART with the new ones
- IRQ4	SPCK needed for dataflash booting and I don't want to switch to
	iic-eeprom for booting
- IRQ5 	NPCS0 same as above
- IRQ6	Ethernet MDIO

I could free 2 IRQ if I either run without IIC or SPI, but this still
wouldn't give me the ideal of 6 lines.

> > - How can I configure NCS2 range as being uncacheable?
> > I asume this has to be done somehow in the kernel.
> 
> Others will have to answer this question, since all the pmap_* and
> vm_* routines make my head spin...  I'm guessing it will be similar to
> how we map the ohci device in kb920x_machdep.c:
> 
> 	/*
> 	 * We can't just map the OHCI registers VA == PA, because
> 	 * AT91RM92_OHCI_BASE belongs to the userland address space.
> 	 * We could just choose a different virtual address, but a better
> 	 * solution would probably be to just use pmap_mapdev() to allocate
> 	 * KVA, as we don't need the OHCI controller before the vm
> 	 * initialization is done. However, the AT91 resource allocation
> 	 * system doesn't know how to use pmap_mapdev() yet.
> 	 */

Is pmap_mapdev useable as Olivier wrote and this comment is outdated?
Or is there still a problem with AT91?
All in all this is just a single page to be mapped, which won't hurt,
so pmap_mapdev sounds good.

> I'm starting to think that we may be getting to the point where we
> need to do better board support in this subport.  You are making too
> many of them too quickly and it is straining the infrastructure :-)

Consider, that the daughter boards all get generic bus access and don't
really have to be UART ones...

-- 
B.Walter                http://www.bwct.de      http://www.fizon.de
bernd at bwct.de           info at bwct.de            support at fizon.de