struct tty_flip_buffer replacement in newer kernels

struct tty_flip_buffer replacement in newer kernels

[Dmitriy Alekseev]

Hello

I'm newbie, working under existed serial driver, adapting it for 2.6.32.
During the compilation I have had several problems, which I
succesfully solved except this one:
error: 'struct tty_struct' has no member named 'flip'
In particular, cound you advice correct replacement of "tty->flip.count"

Thanks
-- 
Best Regards,
Dmitriy Alekseev

Fwd: struct tty_flip_buffer replacement in newer kernels

[Jack Stone]

[Add CCs]

-------- Original Message --------
Subject: struct tty_flip_buffer replacement in newer kernels
Date: Tue, 22 May 2012 16:17:02 +0400
From: Dmitriy Alekseev <deathonfuneral@gmail.com>
To: linux-kernel@vger.kernel.org

Hello

I'm newbie, working under existed serial driver, adapting it for 2.6.32.
During the compilation I have had several problems, which I
succesfully solved except this one:
error: 'struct tty_struct' has no member named 'flip'
In particular, cound you advice correct replacement of "tty->flip.count"

Thanks
-- 
Best Regards,
Dmitriy Alekseev

Re: struct tty_flip_buffer replacement in newer kernels

[Alan Cox]

> I'm newbie, working under existed serial driver, adapting it for 2.6.32.
> During the compilation I have had several problems, which I
> succesfully solved except this one:
> error: 'struct tty_struct' has no member named 'flip'
> In particular, cound you advice correct replacement of "tty->flip.count"

Your driver shouldn't be looking in those areas. There isn't a correct
replacement. You will need to update it to use the flip buffers properly
not poke its nose in places it shouldn't have.

Perhaps the best thing would be to post a link to the driver ?

Alan

Re: struct tty_flip_buffer replacement in newer kernels

[Dmitriy Alekseev]

This is driver source I found:
http://www.codeforge.com/read/118181/st16c554_serial.c__html

It was written for quad uart st16c554 for arm chip s3c2410, which I tried to adapt for at91rm9200 board and newer kernel version.

Best regards,
Dmitriy Alekseev


----- Original Message -----
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jack Stone <jwjstone@fastmail.fm>
Cc: gregkh@linuxfoundation.org; alan@linux.intel.com; linux-serial@vger.kernel.org
Sent: Tuesday, May 22, 2012 6:10 PM
Subject: Re: struct tty_flip_buffer replacement in newer kernels

> I'm newbie, working under existed serial driver, adapting it for 2.6.32.
> During the compilation I have had several problems, which I
> succesfully solved except this one:
> error: 'struct tty_struct' has no member named 'flip'
> In particular, cound you advice correct replacement of "tty->flip.count"

Your driver shouldn't be looking in those areas. There isn't a correct
replacement. You will need to update it to use the flip buffers properly
not poke its nose in places it shouldn't have.

Perhaps the best thing would be to post a link to the driver ?

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: struct tty_flip_buffer replacement in newer kernels

[Alan Cox]

On Tue, 22 May 2012 07:38:28 -0700 (PDT)
Dmitriy Alekseev <alexeev6@yahoo.com> wrote:

> This is driver source I found:
> http://www.codeforge.com/read/118181/st16c554_serial.c__html
> 
> It was written for quad uart st16c554 for arm chip s3c2410, which I tried to adapt for at91rm9200 board and newer kernel version.

Why not use the in kernel 8250 driver (which will drive a stamdard
16540/550/554 as well ?)

To ressurect one you'll need to add kref handling, rework the termios code
and maybe some other bits too.

Take a look how other arm boards use struct plat_serial8250_port and the
serial8250 platform driver. You should just be able to declare the
structures and register the platform device.

Alan

Fw: struct tty_flip_buffer replacement in newer kernels

[Dmitriy Alekseev]

Hi, Alan.

Thank You very much for the answer!
So, if I understand correctly, I took for example this: arch/arm/mach-omap1/board-voiceblue.c
And made in my board specific file:
static struct plat_serial8250_port exar_ports[] = {
        {
                .mapbase        = (unsigned long)(0x30000300), // according to at91rm9200 CS2 memory map
                .flags          = UPF_BOOT_AUTOCONF | UPF_IOREMAP, // I don't know, what kind of flags is suitable for me
                .iotype         = UPIO_MEM, // similar problem
                .regshift       = 1, 
                .uartclk        = 14745600, // Our chip clock frequency
        },
        {
                .mapbase        = (unsigned long)(0x30000200),
                .flags          = UPF_BOOT_AUTOCONF | UPF_IOREMAP,
                .iotype         = UPIO_MEM,
                .regshift       = 1,
                .uartclk        = 14745600,
        },
        {
                .mapbase        = (unsigned long)(0x30000100),
                .flags          = UPF_BOOT_AUTOCONF | UPF_IOREMAP,
                .iotype         = UPIO_MEM,
                .regshift       = 1,
                .uartclk        = 14745600,
        },
        {
                .mapbase        = (unsigned long)(0x30000000),
                .flags          = UPF_BOOT_AUTOCONF | UPF_IOREMAP,
                .iotype         = UPIO_MEM,
                .regshift       = 1,
                .uartclk        = 14745600,
        },
        { },
};
static struct platform_device serial_device = {
.name                   = "serial8250",
        .id                     = PLAT8250_DEV_EXAR_ST16C554,
        .dev                    = {
                 .platform_data  = exar_ports,
         },
};

in my board __init func:
platform_device_register(&serial_device);

at .config I made:
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
# CONFIG_SERIAL_8250_SHARE_IRQ is not set
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_RSA is not set


dmesg gives:
[    0.695312] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled         


New devices in filesystem has been registered, but they didn't related with hardware chip yet.
#cat /proc/tty/driver/serial                                 
serinfo:1.0 driver revision:                                                    
0: uart:unknown mmio:0x30000000 irq:0                                           
1: uart:unknown port:00000000 irq:0                                             
2: uart:unknown port:00000000 irq:0                                             
3: uart:unknown port:00000000 irq:0    

What shoud I check, learn, do for solving this problem?


Very grateful,
Dmitriy Alekseev


----- Original Message -----
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Dmitriy Alekseev <alexeev6@yahoo.com>
Cc: "linux-serial@vger.kernel.org"
<linux-serial@vger.kernel.org>
Sent: Tuesday, May 22, 2012 8:27 PM
Subject: Re: struct tty_flip_buffer replacement in newer kernels

On Tue, 22 May 2012 07:38:28 -0700 (PDT)
Dmitriy Alekseev <alexeev6@yahoo.com> wrote:

> This is driver source I found:
> http://www.codeforge.com/read/118181/st16c554_serial.c__html
> 
> It was written for quad uart st16c554 for arm chip s3c2410, which I tried to adapt for at91rm9200 board and newer kernel version.

Why not use the in kernel 8250 driver (which will drive a stamdard
16540/550/554 as well ?)

To ressurect one you'll need to add kref handling, rework the termios code
and maybe some other bits too.

Take a look how other arm boards use struct plat_serial8250_port and the
serial8250 platform driver. You should just be able to declare the
structures and register the platform device.

Alan

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a
message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: struct tty_flip_buffer replacement in newer kernels

[Dmitriy Alekseev]

The link I gave is original source, which I afterwards changed according to my parameters - clock and processor memory map.

You right about offset 0x8, this is offset between ports in my 68 mode, I corrected, but it doesn't give any result.

 
Best regards,
Dmitriy Alekseev


----- Original Message -----
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Dmitriy Alekseev <alexeev6@yahoo.com>
Cc: 
Sent: Thursday, May 24, 2012 5:22 PM
Subject: Re: struct tty_flip_buffer replacement in newer kernels

On Thu, 24 May 2012 03:38:42 -0700 (PDT)
Dmitriy Alekseev <alexeev6@yahoo.com> wrote:

> Hi, Alan.
> 
> Thank You very much for the answer!
> So, if I understand correctly, I took for example this: arch/arm/mach-omap1/board-voiceblue.c
> And made in my board specific file:
> static struct plat_serial8250_port exar_ports[] = {
>         {
>                 .mapbase        = (unsigned long)(0x30000300), // according to at91rm9200 CS2 memory map
>                 .flags          = UPF_BOOT_AUTOCONF | UPF_IOREMAP, // I don't know, what kind of flags is suitable for me

That looks reasonable - UPF_IOREMAP tells the kernel to do the ioremap
for you, UPF_BOOT_AUTOCONF tries to autoconfigure the chip type

>                 .iotype         = UPIO_MEM, // similar problem
>                 .regshift       = 1, 

And this guides the register spacing (1 = byte spaced, 2 = word spaced, 3
= dword spaced etc)

>                 .uartclk        = 14745600, // Our chip clock frequency

UPIO_MEM is for MMIO, UPIO_PORT for port I/O

However the values don't look the same as the old driver you linked to -
that seems to be using 0x2800000 and then 8 byte spacing plus a 1843200
clock.

Alan

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: struct tty_flip_buffer replacement in newer kernels

[Alan Cox]

On Thu, 24 May 2012 08:05:12 -0700 (PDT)
Dmitriy Alekseev <alexeev6@yahoo.com> wrote:

> The link I gave is original source, which I afterwards changed according to my parameters - clock and processor memory map.
> 
> You right about offset 0x8, this is offset between ports in my 68 mode, I corrected, but it doesn't give any result.

You may have to stick some traces into drivers/tty/8250.c at this point
and see what is going on. It's clearly trying to do the set up right, and
created the ports but didn't believe the hardware. That usually implies
that a parameter is wrong somewhere.

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Fw: struct tty_flip_buffer replacement in newer kernels

[Dmitriy Alekseev]

Hi,

My st16c554 chip is connected with cpu (at91rm9200) in 68 (Motorola) mode, and formally works as 68c554.
Is 8250 driver supports the 68 mode?
I thought the driver maintains whole 16c554 IC, or it means only mode 16 is supported?

Thanks.

Best regards,
Dmitriy Alekseev

________________________________

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Dmitriy Alekseev <alexeev6@yahoo.com> 
Cc: "linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org> 
Sent: Thursday, May 24, 2012 8:00 PM
Subject: Re: struct tty_flip_buffer replacement in newer kernels

On Thu, 24 May 2012 08:05:12 -0700 (PDT)
Dmitriy Alekseev <alexeev6@yahoo.com> wrote:

> The link I gave is original source, which I afterwards changed according to my parameters - clock and processor memory map.
> 
> You right about offset 0x8, this is offset between ports in my 68 mode, I corrected, but it doesn't give any result.

You may have to stick some traces into drivers/tty/8250.c at this point
and see what is going on. It's clearly trying to do the set up right, and
created the ports but didn't believe the hardware. That usually implies
that a parameter is wrong somewhere.

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo
info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: struct tty_flip_buffer replacement in newer kernels

[Alan Cox]

On Mon, 28 May 2012 05:40:15 -0700 (PDT)
Dmitriy Alekseev <alexeev6@yahoo.com> wrote:

> Hi,
> 
> My st16c554 chip is connected with cpu (at91rm9200) in 68 (Motorola) mode, and formally works as 68c554.
> Is 8250 driver supports the 68 mode?
> I thought the driver maintains whole 16c554 IC, or it means only mode 16 is supported?

Not sure I understand the question

Re: struct tty_flip_buffer replacement in newer kernels

[Dmitriy Alekseev]

Sorry, that means, most probably I don't understand something. The IC ST16C554D combines the package interface modes of the 16C554 and 68C554 series on a single integrated chip. Earlier, I assumed, 8250.c is supporting both modes of the circuit. 
Unfortunately I didn't understand the code of 8250.c enough to realise is 68 mode supported or not.

Best regards,
Dmitriy Alekseev


----- Original Message -----
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Dmitriy Alekseev <alexeev6@yahoo.com>
Cc: "linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>; Юрий Зверев <yury.zverev@gmail.com>
Sent: Monday, May 28, 2012 9:12 PM
Subject: Re: struct tty_flip_buffer replacement in newer kernels

On Mon, 28 May 2012 05:40:15 -0700 (PDT)
Dmitriy Alekseev <alexeev6@yahoo.com> wrote:

> Hi,
> 
> My st16c554 chip is connected with cpu (at91rm9200) in 68 (Motorola) mode, and formally works as 68c554.
> Is 8250 driver supports the 68 mode?
> I thought the driver maintains whole 16c554 IC, or it means only mode 16 is supported?

Not sure I understand the question

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: struct tty_flip_buffer replacement in newer kernels

[Alan Cox]

On Mon, 28 May 2012 23:46:36 -0700 (PDT)
Dmitriy Alekseev <alexeev6@yahoo.com> wrote:

> Sorry, that means, most probably I don't understand something. The IC ST16C554D combines the package interface modes of the 16C554 and 68C554 series on a single integrated chip. Earlier, I assumed, 8250.c is supporting both modes of the circuit. 
> Unfortunately I didn't understand the code of 8250.c enough to realise is 68 mode supported or not.


Thats an electrical signal difference not an interface one as I understand
it (beyond the fact it might change the register offsets depending how
the board was wired)

I don't think it matters therefore.
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: struct tty_flip_buffer replacement in newer kernels

[Jack Stone]

[Re-adding original poster an LKML after I accidentally dropped them.
 Sorry about that]

On 05/22/2012 03:10 PM, Alan Cox wrote:
>> I'm newbie, working under existed serial driver, adapting it for 2.6.32.
>> During the compilation I have had several problems, which I
>> succesfully solved except this one:
>> error: 'struct tty_struct' has no member named 'flip'
>> In particular, cound you advice correct replacement of "tty->flip.count"
> 
> Your driver shouldn't be looking in those areas. There isn't a correct
> replacement. You will need to update it to use the flip buffers properly
> not poke its nose in places it shouldn't have.
> 
> Perhaps the best thing would be to post a link to the driver ?
> 
> Alan