[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH-for-5.2 0/4] hw/char/serial: Use the Clock API to feed the UA
Re: [PATCH-for-5.2 0/4] hw/char/serial: Use the Clock API to feed the UART reference clock
Wed, 2 Sep 2020 12:41:47 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
On 9/1/20 7:02 PM, Paolo Bonzini wrote:
> On 06/08/20 15:03, Philippe Mathieu-Daudé wrote:
>> This series improve tracing of multiple UART device in the same
>> chipset, and allow to use the Clock API to feed each device with
>> an (updatable) input clock.
>> Based-on: <firstname.lastname@example.org>
>> "hw/char: Remove TYPE_SERIAL_IO"
>> Philippe Mathieu-Daudé (4):
>> hw/char/serial: Replace commented DPRINTF() by trace event
>> hw/char/serial: Remove old DEBUG_SERIAL commented code
>> hw/char/serial: Let SerialState have an 'id' field
>> hw/char/serial: Use the Clock API to feed the UART reference clock
>> include/hw/char/serial.h | 4 +++
>> hw/char/serial.c | 55 +++++++++++++++++++++++-----------------
>> hw/char/trace-events | 5 ++--
>> 3 files changed, 39 insertions(+), 25 deletions(-)
> Acked-by: Paolo Bonzini <email@example.com>
> Are you planning to deprecate the baudbase property, and instead setting
> up the clock already in serial_mm_init?
I'd love to get there, but unfortunately most of serial_mm_init() have
the baudrate/frequency argument wrong, because it has never been very
clear it was the uart input clock, so most users sets the default
baudrate expected by their guest.
Maybe a sane way to get this slowly fixed is to add a new
serial_mm_init2() documenting it expects an input clock rate
argument (or even better, a connected clock), use it where possible,
deprecate serial_mm_init(), let the maintainer eventually adapt...
I'm not comfortable adding yet another deprecation that will stay