Re: serial.c fix: ELAN fix breaks others

[Matthew Locke <mlocke@mvista.com>]

Ed Vance wrote:

>On Mon, December 16, 2002 at 6:18 PM, Matthew Locke wrote:
>
>>Ed Vance wrote:
>>
>>>>From: Matthew Locke [mailto:mlocke@mvista.com]
>>>>
>>>On Mon, December 16, 2002 at 4:29 PM, Matthew Locke wrote:
>>>
>>>>Ed Vance wrote:
>>>>
>>>>>[ snip ]
>>>>>
>>>>>I avoided the #ifdef by applying the workaround only to 
>>>>>UARTs detected as the "simple" types. The AMD Elan's UARTs 
>>>>>detect as type 16550A. I don't know (yet) of any "simple" 
>>>>>UARTs that misbehave when exposed to the Elan work-around. 
>>>>>See the comments above the patch.
>>>>>
>>>>Ed,
>>>>
>>>>I think I have one.  In general I would prefer not to include 
>>>>workarounds for unaffected platforms.  In the embedded world, 
>>>>I always seem to run into the platform on which these 
>>>>workarounds cause problems:(  Can we add:
>>>>
>>>>#ifndef CONFIG_MELAN
>>>>define uart_transmit_ready 0
>>>>#endif
>>>>
>>>>to your patch?
>>>>
>>>Hi Matthew,
>>>
>>>Of course, I would prefer not to introduce an #ifdef that is 
>>>not necessary. However, running properly on the Elan platform 
>>>already requires rebuilding the kernel with CONFIG_MELAN 
>>>defined to express Elan specific kernel code. So, use of the 
>>>define in the serial driver would not cause anybody an extra 
>>>build step ... 
>>>
>>>If we have to introduce an #ifdef to get correct function on 
>>>unbroken hardware, then we should. Of course, we would want 
>>>to follow the coding guidelines about where to hide the #ifdef. 
>>>
>>>Please tell me:
>>>
>>>What UART flavor are you jousting with?
>>>
>>The TI OMAP on-chip 16650.
>>
>>>
>>>Which UART type does the serial driver detect?
>>>
>>Typically the serial driver doesn't "detect" the type for 
>>these on-chip devices.  Instead we pass in the type with 
>>the STD_SERIAL_PORT_DEFN defined in the arch code.  This 
>>one is a 16650 with a few special tweaks for OMAP.  So we 
>>setup a PORT_OMAP port type and guarantee the new type is 
>>greater than PORT_16550A.  However, I'm still concerned 
>>about chips that will report < 16550A port types and may 
>>have problems with the work around.
>>
>>>
>>>What is the specific errant behavior?
>>>
>>The same as described in your comments-  dropped xmit data.
>>
>
>Hi Matthew,
>
>I read the TI OMAP UART doc. It says the UART type emulated by the 
>OMAP is 16750 (type 8), instead of 16650. Even 16650 (type 6) is 
>out of the range exposed to the work-around. It does not yet sound 
>like this is a type 1 - 4 UART that the work-around breaks. The 
>issue seems to pivot on the default types defined in 
>STD_SERIAL_PORT_DEFN. 
>
oh, good.

>
>
>I would at least like to preserve the work-around code on the x86 
>architecture so a vanilla x86 distro or rescue disk would boot and 
>be at least minimally usable on the Elan with a serial console.
>
Absolutely.

>
>
>Which kernel source should I download and look at so I would see the 
>same defs that you are working with? 
>
We are still working on moving OMAP to the lastest kernel and cleaning 
up the port.  I believe there a snapshot at ftp://source.mvista.com.

>
>
>(I'm not saying no to an #ifdef. I just don't think I have completed 
>the due diligence yet.)
>
ok.  I'm going to use your fix and see what happens on some of our 
boards with on-chip 16550's.

>
>
>Best regards,
>Ed
>
>---------------------------------------------------------------- 
>Ed Vance              edv (at) macrolink (dot) com
>Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
>----------------------------------------------------------------
>
>