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 > -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
