dw8250_set_termios() questions

dw8250_set_termios() questions

[Alex Elder]

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?
- 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?

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?

Thanks.

					-Alex

Re: dw8250_set_termios() questions

[Alex Elder]

Heikki, ping.

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?
> - 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?
> 
> 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?
> 
> Thanks.
> 
> 					-Alex
> 

Re: dw8250_set_termios() questions

[Heikki Krogerus]

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