From: Yoshinori Sato <ysato@users.sourceforge.jp>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Thomas Huth" <thuth@redhat.com>,
"Magnus Damm" <magnus.damm@gmail.com>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
qemu-devel@nongnu.org,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [PATCH 1/2] hw/char/renesas_sci: Add fifo buffer to backend interface.
Date: Thu, 03 Feb 2022 22:38:32 +0900 [thread overview]
Message-ID: <87v8xw1353.wl-ysato@users.sourceforge.jp> (raw)
In-Reply-To: <CAFEAcA_eqh6An7u8uuBRevvFx3GOwbmzRAiGEcmRukGOzWsBhA@mail.gmail.com>
On Wed, 02 Feb 2022 03:54:45 +0900,
Peter Maydell wrote:
>
> On Tue, 1 Feb 2022 at 17:47, Yoshinori Sato <ysato@users.sourceforge.jp> wrote:
> >
> > On Tue, 01 Feb 2022 15:48:58 +0900,
> > Thomas Huth wrote:
> > >
> > > On 31/01/2022 10.42, Yoshinori Sato wrote:
> > > If you describe it like this, it sounds like you're now emulating a
> > > buffer that is not there with real hardware? Is that really what you
> > > want here, i.e. wouldn't this hide problems with the real hardware
> > > that are mitigated in QEMU with this buffer?
> >
> > There is no such buffer in the real hardware.
> > It's not possible with real hardware, but the chardev backend passes
> > data faster than the bitrate.
> > There is no problem if the received data is supplied at the timing when
> > it can be received, but since it is difficult to match the timing accurately,
> > we expect that the buffer will absorb the difference in timing.
>
> If you can't accept receiving more data from the chardev backend,
> your serial device model should be returning 0 from can_receive.
If 0 is returned, the character to be received will be dropped.
There is no problem if it is an interactive operation,
but when connecting to a socket and communicating continuously,
data will be lost if the timing does not match.
> I don't think we should model a FIFO that doesn't exist in
> the real hardware.
>
> thanks
> -- PMM
>
--
Yosinori Sato
prev parent reply other threads:[~2022-02-03 13:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-31 9:42 [PATCH 1/2] hw/char/renesas_sci: Add fifo buffer to backend interface Yoshinori Sato
2022-01-31 9:42 ` [PATCH 2/2] test/avocado: Update machibe_rx_gdbsim tests Yoshinori Sato
2022-02-01 6:48 ` [PATCH 1/2] hw/char/renesas_sci: Add fifo buffer to backend interface Thomas Huth
2022-02-01 15:52 ` Yoshinori Sato
2022-02-01 18:54 ` Peter Maydell
2022-02-03 13:38 ` Yoshinori Sato [this message]
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=87v8xw1353.wl-ysato@users.sourceforge.jp \
--to=ysato@users.sourceforge.jp \
--cc=f4bug@amsat.org \
--cc=magnus.damm@gmail.com \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.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.