[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140805084011.GA14504@xps8300>
Date: Tue, 5 Aug 2014 11:40:11 +0300
From: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To: Alex Elder <elder@...aro.org>
Cc: Greg KH <gregkh@...uxfoundation.org>, david.daney@...ium.com,
loic.poulain@...el.com, linux-serial@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>,
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Subject: Re: dw8250_set_termios() questions
Hi Alex,
On Wed, Jul 23, 2014 at 08:34:11AM -0500, Alex Elder wrote:
> Heikki, ping.
Sorry for the delay, just came back from vacation.
> On 07/11/2014 07:57 AM, Alex Elder wrote:
> > Heikki, I have not been a subscriber of the linux-serial
> > mailing list and didn't see this patch go by:
> > serial: 8250_dw: clock rate handling for all ACPI platforms
> > http://www.spinics.net/lists/linux-serial/msg12861.html
> >
> > I had been working on doing something very similar for some
> > Broadcom device tree based devices and it might have been
> > helpful for me to have seen it. What I ended up with was
> > *very* similar to what you did. Here is the last version
> > of the patch I posted:
> > https://lkml.org/lkml/2014/7/1/323
> >
> > There *are* some differences, and I'd like to inquire about
> > them before I simply use the code you have for my purpose.
> >
> > These first two relate to whether I can use your
> > code as-is:
> > - Why do you skip setting the clock if a null "old"
> > pointer is supplied?
If there is no "old" the baud rate is not being changed.
> > - I don't believe it's necessary to surround the clock
> > rate change with clk_disable_unprepare() and
> > clk_prepare_enable(). Do you believe otherwise?
My clock has CLK_SET_RATE_GATE flag set, so I do need them.
> > This one is addressed to how your code is used now:
> > - Alan Cox had this question about my patch, and
> > it seems to apply to your code as well:
> > "This assumes an arbitarily configurable clock,
> > which is not I think the usual case."
> > https://lkml.org/lkml/2014/6/28/91
> > His point is that the clock, if adjustable, may
> > not support a rate that produces an acceptable
> > signal rate. Put another way, there may be a
> > better frequency than what the clock framework
> > selects that (in combination with the UART
> > divisor latch registers) produces the best--or
> > even a good--signal. Is there any chance any
> > ACPI platforms will suffer this problem?
No there is no such problems on any ACPI platforms. On all platforms
where the Designware UART is enumerated from ACPI we have adjustable
fractional divider generating the clock for it.
I understand the problem, but I think for now we can just limit this
solution to the platforms that we know it works with, like I do by
only using it with ACPI.
Thanks,
--
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists