* [Qemu-devel] [PATCH] hw/char/stm32f2xx_usart: improve TXE/TC bit handling @ 2018-02-04 20:41 Richard Braun 2018-02-08 14:58 ` Peter Maydell 0 siblings, 1 reply; 9+ messages in thread From: Richard Braun @ 2018-02-04 20:41 UTC (permalink / raw) To: qemu-devel Consider that data is always immediately sent. As a result, keep the SR_TXE and SR_TC bits always set. In addition, fix the reset value of the USART status register. Signed-off-by: Richard Braun <rbraun@sceen.net> --- hw/char/stm32f2xx_usart.c | 4 ---- include/hw/char/stm32f2xx_usart.h | 7 ++++++- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/hw/char/stm32f2xx_usart.c b/hw/char/stm32f2xx_usart.c index 07b462d4b6..a914f98a2a 100644 --- a/hw/char/stm32f2xx_usart.c +++ b/hw/char/stm32f2xx_usart.c @@ -96,12 +96,10 @@ static uint64_t stm32f2xx_usart_read(void *opaque, hwaddr addr, switch (addr) { case USART_SR: retvalue = s->usart_sr; - s->usart_sr &= ~USART_SR_TC; qemu_chr_fe_accept_input(&s->chr); return retvalue; case USART_DR: DB_PRINT("Value: 0x%" PRIx32 ", %c\n", s->usart_dr, (char) s->usart_dr); - s->usart_sr |= USART_SR_TXE; s->usart_sr &= ~USART_SR_RXNE; qemu_chr_fe_accept_input(&s->chr); qemu_set_irq(s->irq, 0); @@ -151,8 +149,6 @@ static void stm32f2xx_usart_write(void *opaque, hwaddr addr, /* XXX this blocks entire thread. Rewrite to use * qemu_chr_fe_write and background I/O callbacks */ qemu_chr_fe_write_all(&s->chr, &ch, 1); - s->usart_sr |= USART_SR_TC; - s->usart_sr &= ~USART_SR_TXE; } return; case USART_BRR: diff --git a/include/hw/char/stm32f2xx_usart.h b/include/hw/char/stm32f2xx_usart.h index 9d03a7527c..bbba3965a1 100644 --- a/include/hw/char/stm32f2xx_usart.h +++ b/include/hw/char/stm32f2xx_usart.h @@ -37,7 +37,12 @@ #define USART_CR3 0x14 #define USART_GTPR 0x18 -#define USART_SR_RESET 0x00C00000 +/* + * XXX The reset value mentioned in 24.6.1 Status register seems bogus. + * Looking at Table 98 USART register map and reset values, it seems it + * should be 0xc0, and that's how real hardware behaves. + */ +#define USART_SR_RESET (USART_SR_TXE | USART_SR_TC) #define USART_SR_TXE (1 << 7) #define USART_SR_TC (1 << 6) -- 2.11.0 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH] hw/char/stm32f2xx_usart: improve TXE/TC bit handling 2018-02-04 20:41 [Qemu-devel] [PATCH] hw/char/stm32f2xx_usart: improve TXE/TC bit handling Richard Braun @ 2018-02-08 14:58 ` Peter Maydell 2018-02-08 23:33 ` Alistair Francis 2018-02-09 9:23 ` [Qemu-devel] [PATCH] hw/char/stm32f2xx_usart: improve " Richard Braun 0 siblings, 2 replies; 9+ messages in thread From: Peter Maydell @ 2018-02-08 14:58 UTC (permalink / raw) To: Richard Braun; +Cc: QEMU Developers, Alistair Francis On 4 February 2018 at 20:41, Richard Braun <rbraun@sceen.net> wrote: > Consider that data is always immediately sent. As a result, keep > the SR_TXE and SR_TC bits always set. In addition, fix the reset value > of the USART status register. Do you know what the data sheet means when it says that TC can be cleared by "a read from the USART_SR register followed by a write to the USART_DR register" ? If we supported interrupts properly (which we don't seem to) I suspect we'd need something more than "TXE and TC are always set", or the guest would probably never clear the TXE and TC interrupts. cc'ing Alistair, who wrote the stm32 USART code. > Signed-off-by: Richard Braun <rbraun@sceen.net> > --- > hw/char/stm32f2xx_usart.c | 4 ---- > include/hw/char/stm32f2xx_usart.h | 7 ++++++- > 2 files changed, 6 insertions(+), 5 deletions(-) > > diff --git a/hw/char/stm32f2xx_usart.c b/hw/char/stm32f2xx_usart.c > index 07b462d4b6..a914f98a2a 100644 > --- a/hw/char/stm32f2xx_usart.c > +++ b/hw/char/stm32f2xx_usart.c > @@ -96,12 +96,10 @@ static uint64_t stm32f2xx_usart_read(void *opaque, hwaddr addr, > switch (addr) { > case USART_SR: > retvalue = s->usart_sr; > - s->usart_sr &= ~USART_SR_TC; > qemu_chr_fe_accept_input(&s->chr); > return retvalue; > case USART_DR: > DB_PRINT("Value: 0x%" PRIx32 ", %c\n", s->usart_dr, (char) s->usart_dr); > - s->usart_sr |= USART_SR_TXE; > s->usart_sr &= ~USART_SR_RXNE; > qemu_chr_fe_accept_input(&s->chr); > qemu_set_irq(s->irq, 0); > @@ -151,8 +149,6 @@ static void stm32f2xx_usart_write(void *opaque, hwaddr addr, > /* XXX this blocks entire thread. Rewrite to use > * qemu_chr_fe_write and background I/O callbacks */ > qemu_chr_fe_write_all(&s->chr, &ch, 1); > - s->usart_sr |= USART_SR_TC; > - s->usart_sr &= ~USART_SR_TXE; The guest can clear the TC and TXE bits by writing to the USART_SR directly, so this code should set both of them, I think ? > } > return; > case USART_BRR: > diff --git a/include/hw/char/stm32f2xx_usart.h b/include/hw/char/stm32f2xx_usart.h > index 9d03a7527c..bbba3965a1 100644 > --- a/include/hw/char/stm32f2xx_usart.h > +++ b/include/hw/char/stm32f2xx_usart.h > @@ -37,7 +37,12 @@ > #define USART_CR3 0x14 > #define USART_GTPR 0x18 > > -#define USART_SR_RESET 0x00C00000 > +/* > + * XXX The reset value mentioned in 24.6.1 Status register seems bogus. > + * Looking at Table 98 USART register map and reset values, it seems it > + * should be 0xc0, and that's how real hardware behaves. > + */ > +#define USART_SR_RESET (USART_SR_TXE | USART_SR_TC) > > #define USART_SR_TXE (1 << 7) > #define USART_SR_TC (1 << 6) Yep, I agree that the previous reset value was wrong. thanks -- PMM ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH] hw/char/stm32f2xx_usart: improve TXE/TC bit handling 2018-02-08 14:58 ` Peter Maydell @ 2018-02-08 23:33 ` Alistair Francis 2018-02-09 9:36 ` Richard Braun 2018-02-09 9:23 ` [Qemu-devel] [PATCH] hw/char/stm32f2xx_usart: improve " Richard Braun 1 sibling, 1 reply; 9+ messages in thread From: Alistair Francis @ 2018-02-08 23:33 UTC (permalink / raw) To: Peter Maydell; +Cc: Richard Braun, Alistair Francis, QEMU Developers On Thu, Feb 8, 2018 at 6:58 AM, Peter Maydell <peter.maydell@linaro.org> wrote: > On 4 February 2018 at 20:41, Richard Braun <rbraun@sceen.net> wrote: >> Consider that data is always immediately sent. As a result, keep >> the SR_TXE and SR_TC bits always set. In addition, fix the reset value >> of the USART status register. > > Do you know what the data sheet means when it says that TC > can be cleared by "a read from the USART_SR register followed > by a write to the USART_DR register" ? I'm not sure if they have to be consecutive or as long as they eventually happen it's fine. I no longer have HW to test on so it's hard to say. > > If we supported interrupts properly (which we don't seem to) > I suspect we'd need something more than "TXE and TC are always set", > or the guest would probably never clear the TXE and TC interrupts. > > cc'ing Alistair, who wrote the stm32 USART code. > >> Signed-off-by: Richard Braun <rbraun@sceen.net> >> --- >> hw/char/stm32f2xx_usart.c | 4 ---- >> include/hw/char/stm32f2xx_usart.h | 7 ++++++- >> 2 files changed, 6 insertions(+), 5 deletions(-) >> >> diff --git a/hw/char/stm32f2xx_usart.c b/hw/char/stm32f2xx_usart.c >> index 07b462d4b6..a914f98a2a 100644 >> --- a/hw/char/stm32f2xx_usart.c >> +++ b/hw/char/stm32f2xx_usart.c >> @@ -96,12 +96,10 @@ static uint64_t stm32f2xx_usart_read(void *opaque, hwaddr addr, >> switch (addr) { >> case USART_SR: >> retvalue = s->usart_sr; >> - s->usart_sr &= ~USART_SR_TC; This does seem to be the wrong behavior. It should be cleared after writing to the USART_DR register (and after this read). >> qemu_chr_fe_accept_input(&s->chr); >> return retvalue; >> case USART_DR: >> DB_PRINT("Value: 0x%" PRIx32 ", %c\n", s->usart_dr, (char) s->usart_dr); >> - s->usart_sr |= USART_SR_TXE; Doesn't software expect this to be set? Maybe this was just a nasty workaround to ensure it was set at some point. >> s->usart_sr &= ~USART_SR_RXNE; >> qemu_chr_fe_accept_input(&s->chr); >> qemu_set_irq(s->irq, 0); >> @@ -151,8 +149,6 @@ static void stm32f2xx_usart_write(void *opaque, hwaddr addr, >> /* XXX this blocks entire thread. Rewrite to use >> * qemu_chr_fe_write and background I/O callbacks */ >> qemu_chr_fe_write_all(&s->chr, &ch, 1); >> - s->usart_sr |= USART_SR_TC; >> - s->usart_sr &= ~USART_SR_TXE; > > The guest can clear the TC and TXE bits by writing to the USART_SR > directly, so this code should set both of them, I think ? Shouldn't this clear both? TXE: "It is cleared by a write to the USART_DR register." TC: "a read from the USART_SR register followed by a write to the USART_DR register" I guess the TC should only clear after a read though. > >> } >> return; >> case USART_BRR: >> diff --git a/include/hw/char/stm32f2xx_usart.h b/include/hw/char/stm32f2xx_usart.h >> index 9d03a7527c..bbba3965a1 100644 >> --- a/include/hw/char/stm32f2xx_usart.h >> +++ b/include/hw/char/stm32f2xx_usart.h >> @@ -37,7 +37,12 @@ >> #define USART_CR3 0x14 >> #define USART_GTPR 0x18 >> >> -#define USART_SR_RESET 0x00C00000 >> +/* >> + * XXX The reset value mentioned in 24.6.1 Status register seems bogus. >> + * Looking at Table 98 USART register map and reset values, it seems it >> + * should be 0xc0, and that's how real hardware behaves. >> + */ >> +#define USART_SR_RESET (USART_SR_TXE | USART_SR_TC) >> >> #define USART_SR_TXE (1 << 7) >> #define USART_SR_TC (1 << 6) > > Yep, I agree that the previous reset value was wrong. Ah, that is confusing that it's different in different places. The new one looks fine though. Alistair > > thanks > -- PMM > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH] hw/char/stm32f2xx_usart: improve TXE/TC bit handling 2018-02-08 23:33 ` Alistair Francis @ 2018-02-09 9:36 ` Richard Braun 2018-02-13 20:54 ` [Qemu-devel] [PATCH v2] hw/char/stm32f2xx_usart: fix " Richard Braun 0 siblings, 1 reply; 9+ messages in thread From: Richard Braun @ 2018-02-09 9:36 UTC (permalink / raw) To: Alistair Francis; +Cc: Peter Maydell, Alistair Francis, QEMU Developers On Thu, Feb 08, 2018 at 03:33:32PM -0800, Alistair Francis wrote: > >> @@ -96,12 +96,10 @@ static uint64_t stm32f2xx_usart_read(void *opaque, hwaddr addr, > >> switch (addr) { > >> case USART_SR: > >> retvalue = s->usart_sr; > >> - s->usart_sr &= ~USART_SR_TC; > > This does seem to be the wrong behavior. It should be cleared after > writing to the USART_DR register (and after this read). Writing to DR being synchronous, the transmission is complete immediately after doing it, making that bit set again. > >> case USART_DR: > >> DB_PRINT("Value: 0x%" PRIx32 ", %c\n", s->usart_dr, (char) s->usart_dr); > >> - s->usart_sr |= USART_SR_TXE; > > Doesn't software expect this to be set? Maybe this was just a nasty > workaround to ensure it was set at some point. This bit should always be set in the current implementation. It may be cleared and set the day I/O threads are used, since then, the transient state will be visible to software. > >> @@ -151,8 +149,6 @@ static void stm32f2xx_usart_write(void *opaque, hwaddr addr, > >> /* XXX this blocks entire thread. Rewrite to use > >> * qemu_chr_fe_write and background I/O callbacks */ > >> qemu_chr_fe_write_all(&s->chr, &ch, 1); > >> - s->usart_sr |= USART_SR_TC; > >> - s->usart_sr &= ~USART_SR_TXE; > > > > The guest can clear the TC and TXE bits by writing to the USART_SR > > directly, so this code should set both of them, I think ? > > Shouldn't this clear both? > > TXE: "It is cleared by a write to the USART_DR register." > TC: "a read from the USART_SR register followed by a write to the > USART_DR register" > > I guess the TC should only clear after a read though. We're not aiming at a full emulation of the device here, we only want to emulate visible states. As mentioned above, software should always see the TXE bit set, since writes are synchronous. TC should be set though, because it may be cleared by an explicit write to SR setting it to 0. I'll post a new version of the patch soon. -- Richard Braun ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] [PATCH v2] hw/char/stm32f2xx_usart: fix TXE/TC bit handling 2018-02-09 9:36 ` Richard Braun @ 2018-02-13 20:54 ` Richard Braun 2018-02-15 22:27 ` Alistair Francis 0 siblings, 1 reply; 9+ messages in thread From: Richard Braun @ 2018-02-13 20:54 UTC (permalink / raw) To: qemu-devel; +Cc: Peter Maydell, Alistair Francis I/O currently being synchronous, there is no reason to ever clear the SR_TXE bit. However the SR_TC bit may be cleared by software writing to the SR register, so set it on each write. In addition, fix the reset value of the USART status register. Signed-off-by: Richard Braun <rbraun@sceen.net> --- hw/char/stm32f2xx_usart.c | 12 ++++++++---- include/hw/char/stm32f2xx_usart.h | 7 ++++++- 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/hw/char/stm32f2xx_usart.c b/hw/char/stm32f2xx_usart.c index 07b462d4b6..032b5fda13 100644 --- a/hw/char/stm32f2xx_usart.c +++ b/hw/char/stm32f2xx_usart.c @@ -96,12 +96,10 @@ static uint64_t stm32f2xx_usart_read(void *opaque, hwaddr addr, switch (addr) { case USART_SR: retvalue = s->usart_sr; - s->usart_sr &= ~USART_SR_TC; qemu_chr_fe_accept_input(&s->chr); return retvalue; case USART_DR: DB_PRINT("Value: 0x%" PRIx32 ", %c\n", s->usart_dr, (char) s->usart_dr); - s->usart_sr |= USART_SR_TXE; s->usart_sr &= ~USART_SR_RXNE; qemu_chr_fe_accept_input(&s->chr); qemu_set_irq(s->irq, 0); @@ -137,7 +135,9 @@ static void stm32f2xx_usart_write(void *opaque, hwaddr addr, switch (addr) { case USART_SR: if (value <= 0x3FF) { - s->usart_sr = value; + /* I/O being synchronous, TXE is always set. In addition, it may + only be set by hardware, so keep it set here. */ + s->usart_sr = value | USART_SR_TXE; } else { s->usart_sr &= value; } @@ -151,8 +151,12 @@ static void stm32f2xx_usart_write(void *opaque, hwaddr addr, /* XXX this blocks entire thread. Rewrite to use * qemu_chr_fe_write and background I/O callbacks */ qemu_chr_fe_write_all(&s->chr, &ch, 1); + /* XXX I/O are currently synchronous, making it impossible for + software to observe transient states where TXE or TC aren't + set. Unlike TXE however, which is read-only, software may + clear TC by writing 0 to the SR register, so set it again + on each write. */ s->usart_sr |= USART_SR_TC; - s->usart_sr &= ~USART_SR_TXE; } return; case USART_BRR: diff --git a/include/hw/char/stm32f2xx_usart.h b/include/hw/char/stm32f2xx_usart.h index 9d03a7527c..7ea7448813 100644 --- a/include/hw/char/stm32f2xx_usart.h +++ b/include/hw/char/stm32f2xx_usart.h @@ -37,7 +37,12 @@ #define USART_CR3 0x14 #define USART_GTPR 0x18 -#define USART_SR_RESET 0x00C00000 +/* + * XXX The reset value mentioned in "24.6.1 Status register" seems bogus. + * Looking at "Table 98 USART register map and reset values", it seems it + * should be 0xc0, and that's how real hardware behaves. + */ +#define USART_SR_RESET (USART_SR_TXE | USART_SR_TC) #define USART_SR_TXE (1 << 7) #define USART_SR_TC (1 << 6) -- 2.11.0 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH v2] hw/char/stm32f2xx_usart: fix TXE/TC bit handling 2018-02-13 20:54 ` [Qemu-devel] [PATCH v2] hw/char/stm32f2xx_usart: fix " Richard Braun @ 2018-02-15 22:27 ` Alistair Francis 2018-02-22 11:18 ` Peter Maydell 0 siblings, 1 reply; 9+ messages in thread From: Alistair Francis @ 2018-02-15 22:27 UTC (permalink / raw) To: Richard Braun Cc: qemu-devel@nongnu.org Developers, Peter Maydell, Alistair Francis On Tue, Feb 13, 2018 at 12:54 PM, Richard Braun <rbraun@sceen.net> wrote: > I/O currently being synchronous, there is no reason to ever clear the > SR_TXE bit. However the SR_TC bit may be cleared by software writing > to the SR register, so set it on each write. > > In addition, fix the reset value of the USART status register. > > Signed-off-by: Richard Braun <rbraun@sceen.net> Reviewed-by: Alistair Francis <alistair.francis@xilinx.com> Alistair > --- > hw/char/stm32f2xx_usart.c | 12 ++++++++---- > include/hw/char/stm32f2xx_usart.h | 7 ++++++- > 2 files changed, 14 insertions(+), 5 deletions(-) > > diff --git a/hw/char/stm32f2xx_usart.c b/hw/char/stm32f2xx_usart.c > index 07b462d4b6..032b5fda13 100644 > --- a/hw/char/stm32f2xx_usart.c > +++ b/hw/char/stm32f2xx_usart.c > @@ -96,12 +96,10 @@ static uint64_t stm32f2xx_usart_read(void *opaque, hwaddr addr, > switch (addr) { > case USART_SR: > retvalue = s->usart_sr; > - s->usart_sr &= ~USART_SR_TC; > qemu_chr_fe_accept_input(&s->chr); > return retvalue; > case USART_DR: > DB_PRINT("Value: 0x%" PRIx32 ", %c\n", s->usart_dr, (char) s->usart_dr); > - s->usart_sr |= USART_SR_TXE; > s->usart_sr &= ~USART_SR_RXNE; > qemu_chr_fe_accept_input(&s->chr); > qemu_set_irq(s->irq, 0); > @@ -137,7 +135,9 @@ static void stm32f2xx_usart_write(void *opaque, hwaddr addr, > switch (addr) { > case USART_SR: > if (value <= 0x3FF) { > - s->usart_sr = value; > + /* I/O being synchronous, TXE is always set. In addition, it may > + only be set by hardware, so keep it set here. */ > + s->usart_sr = value | USART_SR_TXE; > } else { > s->usart_sr &= value; > } > @@ -151,8 +151,12 @@ static void stm32f2xx_usart_write(void *opaque, hwaddr addr, > /* XXX this blocks entire thread. Rewrite to use > * qemu_chr_fe_write and background I/O callbacks */ > qemu_chr_fe_write_all(&s->chr, &ch, 1); > + /* XXX I/O are currently synchronous, making it impossible for > + software to observe transient states where TXE or TC aren't > + set. Unlike TXE however, which is read-only, software may > + clear TC by writing 0 to the SR register, so set it again > + on each write. */ > s->usart_sr |= USART_SR_TC; > - s->usart_sr &= ~USART_SR_TXE; > } > return; > case USART_BRR: > diff --git a/include/hw/char/stm32f2xx_usart.h b/include/hw/char/stm32f2xx_usart.h > index 9d03a7527c..7ea7448813 100644 > --- a/include/hw/char/stm32f2xx_usart.h > +++ b/include/hw/char/stm32f2xx_usart.h > @@ -37,7 +37,12 @@ > #define USART_CR3 0x14 > #define USART_GTPR 0x18 > > -#define USART_SR_RESET 0x00C00000 > +/* > + * XXX The reset value mentioned in "24.6.1 Status register" seems bogus. > + * Looking at "Table 98 USART register map and reset values", it seems it > + * should be 0xc0, and that's how real hardware behaves. > + */ > +#define USART_SR_RESET (USART_SR_TXE | USART_SR_TC) > > #define USART_SR_TXE (1 << 7) > #define USART_SR_TC (1 << 6) > -- > 2.11.0 > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH v2] hw/char/stm32f2xx_usart: fix TXE/TC bit handling 2018-02-15 22:27 ` Alistair Francis @ 2018-02-22 11:18 ` Peter Maydell 0 siblings, 0 replies; 9+ messages in thread From: Peter Maydell @ 2018-02-22 11:18 UTC (permalink / raw) To: Alistair Francis Cc: Richard Braun, qemu-devel@nongnu.org Developers, Alistair Francis On 15 February 2018 at 22:27, Alistair Francis <alistair23@gmail.com> wrote: > On Tue, Feb 13, 2018 at 12:54 PM, Richard Braun <rbraun@sceen.net> wrote: >> I/O currently being synchronous, there is no reason to ever clear the >> SR_TXE bit. However the SR_TC bit may be cleared by software writing >> to the SR register, so set it on each write. >> >> In addition, fix the reset value of the USART status register. >> >> Signed-off-by: Richard Braun <rbraun@sceen.net> > > Reviewed-by: Alistair Francis <alistair.francis@xilinx.com> Applied to target-arm.next, thanks. -- PMM ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH] hw/char/stm32f2xx_usart: improve TXE/TC bit handling 2018-02-08 14:58 ` Peter Maydell 2018-02-08 23:33 ` Alistair Francis @ 2018-02-09 9:23 ` Richard Braun 2018-02-09 9:35 ` Richard Braun 1 sibling, 1 reply; 9+ messages in thread From: Richard Braun @ 2018-02-09 9:23 UTC (permalink / raw) To: Peter Maydell; +Cc: QEMU Developers, Alistair Francis On Thu, Feb 08, 2018 at 02:58:29PM +0000, Peter Maydell wrote: > On 4 February 2018 at 20:41, Richard Braun <rbraun@sceen.net> wrote: > > Consider that data is always immediately sent. As a result, keep > > the SR_TXE and SR_TC bits always set. In addition, fix the reset value > > of the USART status register. > > Do you know what the data sheet means when it says that TC > can be cleared by "a read from the USART_SR register followed > by a write to the USART_DR register" ? It's meant for software either polling the TC bit or waiting for a transmission complete interrupt. Once the bit is seen, the next transmission automatically clears it. > If we supported interrupts properly (which we don't seem to) > I suspect we'd need something more than "TXE and TC are always set", > or the guest would probably never clear the TXE and TC interrupts. That's the idea of the patch. Since everything is currently synchronous, there is no need for these transient states to even exist. > The guest can clear the TC and TXE bits by writing to the USART_SR > directly, so this code should set both of them, I think ? Right, nice catch. -- Richard Braun ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH] hw/char/stm32f2xx_usart: improve TXE/TC bit handling 2018-02-09 9:23 ` [Qemu-devel] [PATCH] hw/char/stm32f2xx_usart: improve " Richard Braun @ 2018-02-09 9:35 ` Richard Braun 0 siblings, 0 replies; 9+ messages in thread From: Richard Braun @ 2018-02-09 9:35 UTC (permalink / raw) To: Peter Maydell; +Cc: QEMU Developers, Alistair Francis On Fri, Feb 09, 2018 at 10:23:13AM +0100, Richard Braun wrote: > On Thu, Feb 08, 2018 at 02:58:29PM +0000, Peter Maydell wrote: > > The guest can clear the TC and TXE bits by writing to the USART_SR > > directly, so this code should set both of them, I think ? > > Right, nice catch. Although, after reading the manual again, TXE is actually read-only and only set by hardware. -- Richard Braun ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-02-22 11:19 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-02-04 20:41 [Qemu-devel] [PATCH] hw/char/stm32f2xx_usart: improve TXE/TC bit handling Richard Braun 2018-02-08 14:58 ` Peter Maydell 2018-02-08 23:33 ` Alistair Francis 2018-02-09 9:36 ` Richard Braun 2018-02-13 20:54 ` [Qemu-devel] [PATCH v2] hw/char/stm32f2xx_usart: fix " Richard Braun 2018-02-15 22:27 ` Alistair Francis 2018-02-22 11:18 ` Peter Maydell 2018-02-09 9:23 ` [Qemu-devel] [PATCH] hw/char/stm32f2xx_usart: improve " Richard Braun 2018-02-09 9:35 ` Richard Braun
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.