possible serial driver fixup for au1x00 in 2.6?

possible serial driver fixup for au1x00 in 2.6?

[rolf liu]

Basically, au1x00_uart.c is doing the same thing as 8250.c. If I want
to add extra serial port support by 8250.c. There could be some
problem. Any idea?

Correct me if I am wrong

Re: possible serial driver fixup for au1x00 in 2.6?

[Pete Popov]

On Fri, 2005-07-01 at 17:56 -0700, rolf liu wrote:
> Basically, au1x00_uart.c is doing the same thing as 8250.c. 

Basically.

> If I want
> to add extra serial port support by 8250.c. There could be some
> problem. Any idea?

Don't know, haven't tried it. In general, the au1x00 serial driver needs
to be rewritten.

Pete

Re: possible serial driver fixup for au1x00 in 2.6?

[rolf liu]

Pete,
To try if 8250.c can work under db1550/linux 2.6.12, I turn off the
au1x00_uart.c config and just compiled in the 8250 support. When I
boot the kernel, nothing comes up through the console, which should be
provided by 8250 support, by 8250_early.c?

Any idea?

On 7/1/05, Pete Popov <ppopov@embeddedalley.com> wrote:
> On Fri, 2005-07-01 at 17:56 -0700, rolf liu wrote:
> > Basically, au1x00_uart.c is doing the same thing as 8250.c.
> 
> Basically.
> 
> > If I want
> > to add extra serial port support by 8250.c. There could be some
> > problem. Any idea?
> 
> Don't know, haven't tried it. In general, the au1x00 serial driver needs
> to be rewritten.
> 
> Pete
> 
>

Re: possible serial driver fixup for au1x00 in 2.6?

[Michael Stickel]

rolf liu wrote:

>Pete,
>To try if 8250.c can work under db1550/linux 2.6.12, I turn off the
>au1x00_uart.c config and just compiled in the 8250 support. When I
>boot the kernel, nothing comes up through the console, which should be
>provided by 8250 support, by 8250_early.c?
>
You can't just enable the serial.c (8250). The UARTs for the Au1x00 are 
memory mapped, but are accessed thru the functions au_readx and 
au_writex. If you take a look at the au1x00_uart.c you can see that the 
functions for serial register access contains access to the au1x00 
registers thru au_readl and au_writel. The serial.c does some more 
things, that does not belong to 8250 (and successors), but to the way 
how the chips are attached to the bus. I see the need to write a more 
modular structure:

One 8250.c that does only the serial chip stuff and one module per 
chip-access-method (serial_io.c, serial_pci.c, serial_mm.c, 
serial_au1x00.c, ...). These modules must know how to access the 
registers, but not what they mean. 8250.c does not know how to access 
the registers, but what to do with it.

Thats teamwork.

That could be adopted to more chips that have a registers to access. I 
think about the i8255 3-port io chip or the i8254-CTC and there are many 
more.

There must be a callback for interrupts like it exists for the parallel 
port stuff.

Could look like that:
struct register_access_s
{
  void (*delete_resource) (struct register_access_s *);
  ...
  int (*writel) (struct register_access_s *bus, long reg, u32 value);
  int (*writew) (struct register_access_s *bus, long reg, u16 value);
  int (*writeb) (struct register_access_s *bus, long reg, u8 value);
  ...
  int (*readl) (struct register_access_s *bus, long reg, u32 *value);
  int (*readw) (struct register_access_s *bus, long reg, u16 *value);
  int (*readb) (struct register_access_s *bus, long reg, u8 *value);
  ...
  void *private;
};

struct register_access_s *create_au1x00_register_access (u32 
au1x00_register_address, size_t size, u32 irq);
struct register_access_s *create_io_register_access (u16 io_address, 
size_t size, u32 irq);
struct register_access_s *create_mm_register_access (void *vaddress, 
size_t size, u32 irq);

struct register_access_s *au1x00_uart0_regs = 
create_au1x00_register_access (UART0_ADDR, 8, AU1000_UART0_INT);
struct register_access_s *uart0_regs = create_io_register_access (0x3E0, 
8, 4);

register_8250 (au1x00_uart0_regs, ...);
register_8250 (uart0_regs, ...);

au1x00_uart0_regs->delete_resource (au1x00_uart0_regs);
...
uart3_regs->delete_resource (uart3_regs);

May be a chip can have more than one interrupts and does not have even one.

Michael

Re: possible serial driver fixup for au1x00 in 2.6?

[rolf liu]

Mike,
Thanks for the comments.
Your way is foundamental change. Currently I just want to try if the
8250.c and au1x00_uart.c can work under the same system--both on-chip
uarts and exar uarts are available without too much coding.  Any
suggestions?


On 7/5/05, Michael Stickel <michael@cubic.org> wrote:
> rolf liu wrote:
> 
> >Pete,
> >To try if 8250.c can work under db1550/linux 2.6.12, I turn off the
> >au1x00_uart.c config and just compiled in the 8250 support. When I
> >boot the kernel, nothing comes up through the console, which should be
> >provided by 8250 support, by 8250_early.c?
> >
> You can't just enable the serial.c (8250). The UARTs for the Au1x00 are
> memory mapped, but are accessed thru the functions au_readx and
> au_writex. If you take a look at the au1x00_uart.c you can see that the
> functions for serial register access contains access to the au1x00
> registers thru au_readl and au_writel. The serial.c does some more
> things, that does not belong to 8250 (and successors), but to the way
> how the chips are attached to the bus. I see the need to write a more
> modular structure:
> 
> One 8250.c that does only the serial chip stuff and one module per
> chip-access-method (serial_io.c, serial_pci.c, serial_mm.c,
> serial_au1x00.c, ...). These modules must know how to access the
> registers, but not what they mean. 8250.c does not know how to access
> the registers, but what to do with it.
> 
> Thats teamwork.
> 
> That could be adopted to more chips that have a registers to access. I
> think about the i8255 3-port io chip or the i8254-CTC and there are many
> more.
> 
> There must be a callback for interrupts like it exists for the parallel
> port stuff.
> 
> Could look like that:
> struct register_access_s
> {
>  void (*delete_resource) (struct register_access_s *);
>  ...
>  int (*writel) (struct register_access_s *bus, long reg, u32 value);
>  int (*writew) (struct register_access_s *bus, long reg, u16 value);
>  int (*writeb) (struct register_access_s *bus, long reg, u8 value);
>  ...
>  int (*readl) (struct register_access_s *bus, long reg, u32 *value);
>  int (*readw) (struct register_access_s *bus, long reg, u16 *value);
>  int (*readb) (struct register_access_s *bus, long reg, u8 *value);
>  ...
>  void *private;
> };
> 
> struct register_access_s *create_au1x00_register_access (u32
> au1x00_register_address, size_t size, u32 irq);
> struct register_access_s *create_io_register_access (u16 io_address,
> size_t size, u32 irq);
> struct register_access_s *create_mm_register_access (void *vaddress,
> size_t size, u32 irq);
> 
> struct register_access_s *au1x00_uart0_regs =
> create_au1x00_register_access (UART0_ADDR, 8, AU1000_UART0_INT);
> struct register_access_s *uart0_regs = create_io_register_access (0x3E0,
> 8, 4);
> 
> register_8250 (au1x00_uart0_regs, ...);
> register_8250 (uart0_regs, ...);
> 
> au1x00_uart0_regs->delete_resource (au1x00_uart0_regs);
> ...
> uart3_regs->delete_resource (uart3_regs);
> 
> May be a chip can have more than one interrupts and does not have even one.
> 
> Michael
> 
> 
> 
>

Re: possible serial driver fixup for au1x00 in 2.6?

[Pete Popov]

On Tue, 2005-07-05 at 12:40 -0700, rolf liu wrote:
> Pete,
> To try if 8250.c can work under db1550/linux 2.6.12, I turn off the
> au1x00_uart.c config and just compiled in the 8250 support. When I
> boot the kernel, nothing comes up through the console, which should be
> provided by 8250 support, by 8250_early.c?
> 
> Any idea?

Yes. The 8250.c won't work with the au1x uart. I know I said in a
previous email that the 8250 "basically" does the same thing as the au1x
uart driver, but if the 8250 worked with the Au1x SoCs, why would we
even have the au1x serial driver in place?

Pete

> 
> On 7/1/05, Pete Popov <ppopov@embeddedalley.com> wrote:
> > On Fri, 2005-07-01 at 17:56 -0700, rolf liu wrote:
> > > Basically, au1x00_uart.c is doing the same thing as 8250.c.
> > 
> > Basically.
> > 
> > > If I want
> > > to add extra serial port support by 8250.c. There could be some
> > > problem. Any idea?
> > 
> > Don't know, haven't tried it. In general, the au1x00 serial driver needs
> > to be rewritten.
> > 
> > Pete
> > 
> >
> 

Re: possible serial driver fixup for au1x00 in 2.6?

[rolf liu]

Hi Pete,
I just give 8250.c a dirty hack, letting it just manage the additional
serial ports. So there are two serial driver in the system at the same
time :(  Sound funny.

thanks for your comments. I will give the feadback when I get more :)


On 7/6/05, Pete Popov <ppopov@embeddedalley.com> wrote:
> On Tue, 2005-07-05 at 12:40 -0700, rolf liu wrote:
> > Pete,
> > To try if 8250.c can work under db1550/linux 2.6.12, I turn off the
> > au1x00_uart.c config and just compiled in the 8250 support. When I
> > boot the kernel, nothing comes up through the console, which should be
> > provided by 8250 support, by 8250_early.c?
> >
> > Any idea?
> 
> Yes. The 8250.c won't work with the au1x uart. I know I said in a
> previous email that the 8250 "basically" does the same thing as the au1x
> uart driver, but if the 8250 worked with the Au1x SoCs, why would we
> even have the au1x serial driver in place?
> 
> Pete
> 
> >
> > On 7/1/05, Pete Popov <ppopov@embeddedalley.com> wrote:
> > > On Fri, 2005-07-01 at 17:56 -0700, rolf liu wrote:
> > > > Basically, au1x00_uart.c is doing the same thing as 8250.c.
> > >
> > > Basically.
> > >
> > > > If I want
> > > > to add extra serial port support by 8250.c. There could be some
> > > > problem. Any idea?
> > >
> > > Don't know, haven't tried it. In general, the au1x00 serial driver needs
> > > to be rewritten.
> > >
> > > Pete
> > >
> > >
> >
> 
>

Re: possible serial driver fixup for au1x00 in 2.6?

[Matej Kupljen]

Hi

> I just give 8250.c a dirty hack, letting it just manage the additional
> serial ports. So there are two serial driver in the system at the same
> time :(  Sound funny.

Can we see the hack, please ? :-)

BR,
Matej