All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc St-Jean <Marc_St-Jean@pmc-sierra.com>
To: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Alan <alan@lxorguk.ukuu.org.uk>,
	linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
	linux-mips@linux-mips.org
Subject: Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git mast er
Date: Wed, 24 Jan 2007 13:10:12 -0800	[thread overview]
Message-ID: <45B7CB34.60209@pmc-sierra.com> (raw)

Sergei Shtylyov wrote:
> Hello.
> 
> Marc St-Jean wrote:
> 
>  >> >>This I would hope you can hide in the platform specific
>  >> >>serial_in/serial_out functions. If you write the UART_LCR save it in
>  >> >>serial_out(), if you read IER etc.
> 
>  >> > I couldn't find hooks for platform specific serial_in/out functions.
> 
>  >>    It's because there are none. :-)
> 
>  >> > Do you mean using the up->port.iotype's in serial_in/out from 8250.c?
> 
>  >>    Not sure what Alan meant, but this seems the only option for now.
> 
>  > That's the conclusion I came to. I've rewritten the patch to use 
> port.type
>  > instead of iotype since one of the fix is SoC and not UART specific. 
> I guess
> 
>     I failed to folkow your logic. :-)

No longer matters as I can't use port.type. See next comment.

>  > I could use both iotype and type with a test on each for the appropriate
>  > bug, what do you recommend?
> 
>     I think iotype would be enough. You can't pass type for platform 
> devices
> anyway, IIRC (the thing I don't quite like).

I just found that out the hard way, it get's overwritten during autoconfig* and
ends up back at PORT_16550A.

I'm now trying to use my own iotype = UPIO_DWAPB and I've added it to all cases
that check for UPIO_MEM. However at boot time I'm getting:
	"serial8250: ttyS0 at *unknown* (irq = 27) is a 16550A".
It looks like something outside of 8250.c must be checking for UPIO_MEM, I'm
looking into it.

> 
>  >>  >>And we might want to add a void * for board specific insanity to 
> the 8250
>  >> >>structures if we really have to so you can hang your brain damage
>  >> >>privately off that ?
> 
>  >> > Sounds good to me, it would give us a location to store the 
> address of the
>  >> > UART_STATUS_REG required by this UART variant.
> 
>  >>    I doubt we really need to *store* it somewhere. Isn't it an fixed 
> offset
>  >>from UART's base (I haven't seen the header)?
> 
>  > Unfortunately it's not a constant offset from the UART in the SoC 
> register
> 
>     Hm...
> 
>  > space. I've used Alan suggestion and added a classic, on some other 
> OSes %-|,
>  > void "user" pointer.
> 
>     Only do not do it under #ifdef.

Understood, getting rid of them is why I started this thread.

Marc

             reply	other threads:[~2007-01-24 21:11 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-24 21:10 Marc St-Jean [this message]
2007-01-25 14:29 ` [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git mast er Sergei Shtylyov
  -- strict thread matches above, loose matches on Subject: below --
2007-02-16 17:06 Marc St-Jean
2007-02-16 17:21 ` Sergei Shtylyov
2007-02-16 16:30 Marc St-Jean
2007-02-13 22:11 Marc St-Jean
2007-02-12 17:46 Marc St-Jean
2007-02-12 17:56 ` Sergei Shtylyov
2007-02-09 19:39 Marc St-Jean
2007-02-10 17:30 ` Sergei Shtylyov
2007-02-07 20:50 Marc St-Jean
2007-02-06 16:52 Marc St-Jean
2007-01-27  0:28 Marc St-Jean
2007-01-25 23:10 Marc St-Jean
2007-01-26 13:58 ` Sergei Shtylyov
2007-01-24 16:48 Marc St-Jean
2007-01-24 20:38 ` Sergei Shtylyov
2007-01-24 16:40 Marc St-Jean
2007-01-24 19:40 ` Sergei Shtylyov
2007-01-23 22:37 Marc St-Jean
2007-01-23 23:41 ` Alan
2007-01-24 15:33 ` Sergei Shtylyov
2007-01-22 20:35 Marc St-Jean
2007-01-22 20:34 Marc St-Jean
2007-01-22 19:07 Marc St-Jean
2007-01-22 18:11 Marc St-Jean
2007-01-22 18:11 ` Marc St-Jean
2007-01-22 18:11 ` Marc St-Jean
2007-01-22 20:23 ` Sergei Shtylyov
2007-01-24 15:25   ` Sergei Shtylyov
2007-01-19 18:40 Marc St-Jean
2007-01-19 17:33 Marc St-Jean

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45B7CB34.60209@pmc-sierra.com \
    --to=marc_st-jean@pmc-sierra.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=sshtylyov@ru.mvista.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.