On Fri, 10 Sep 2021, Mark Cave-Ayland wrote:
> On 01/09/2021 09:06, Mark Cave-Ayland wrote:
>
> > I'll have a go at some basic timer measurements using your patch to
> > see what sort of numbers I get for the latency here. Obviously QEMU
> > doesn't guarantee response times but over 20ms does s
On 01/09/2021 09:06, Mark Cave-Ayland wrote:
I'll have a go at some basic timer measurements using your patch to see what sort of
numbers I get for the latency here. Obviously QEMU doesn't guarantee response times
but over 20ms does seem high.
I was able to spend some time today looking at th
On 01/09/2021 08:57, Mark Cave-Ayland wrote:
I had a quick look at your via-timer branch at
https://github.com/fthain/qemu/commits/via-timer and spotted that your work is based
upon the v6.0 release. Before digging further into this, can you try using vanilla
git master or the v6.1 tag instead
On 31/08/2021 23:44, Finn Thain wrote:
You mentioned that the OS may compensate for the fact that the 6522
doesn't have an overflow flag: can you explain more as to how this works
in Linux? Is the problem here that even if you read the counter value in
the interrupt handler to work out the laten
On Tue, 31 Aug 2021, Mark Cave-Ayland wrote:
> You mentioned that the OS may compensate for the fact that the 6522
> doesn't have an overflow flag: can you explain more as to how this works
> in Linux?
When running on real hardware, Linux/mac68k does so by
- Elevating the interrupt priority o
On Tue, 31 Aug 2021, Mark Cave-Ayland wrote:
> On 28/08/2021 02:22, Finn Thain wrote:
>
> > > On 8/24/21 12:09 PM, Finn Thain wrote:
> > >
> > > > On a real Quadra, accesses to the SY6522 chips are slow because they are
> > > > synchronous with the 783360 Hz "phase 2" clock. In QEMU, they are sl
On 28/08/2021 02:22, Finn Thain wrote:
On 8/24/21 12:09 PM, Finn Thain wrote:
On a real Quadra, accesses to the SY6522 chips are slow because they are
synchronous with the 783360 Hz "phase 2" clock. In QEMU, they are slow
only because of the division operation in the timer count calculation.
On Wed, 25 Aug 2021, Mark Cave-Ayland wrote:
> On 24/08/2021 11:09, Finn Thain wrote:
>
> > This is a patch series that I started last year. The aim was to try to
> > get a monotonic clocksource for Linux/m68k guests. That aim hasn't been
> > achieved yet (for q800 machines) but I'm submitting th
On Tue, 24 Aug 2021, Philippe Mathieu-Daudé wrote:
> On 8/24/21 12:09 PM, Finn Thain wrote:
>
> > On a real Quadra, accesses to the SY6522 chips are slow because they are
> > synchronous with the 783360 Hz "phase 2" clock. In QEMU, they are slow
> > only because of the division operation in the
On 24/08/2021 11:09, Finn Thain wrote:
This is a patch series that I started last year. The aim was to try to
get a monotonic clocksource for Linux/m68k guests. That aim hasn't been
achieved yet (for q800 machines) but I'm submitting the patch series as
an RFC because,
- It does improve 6522
On Tue, Aug 24, 2021 at 08:09:36PM +1000, Finn Thain wrote:
> This is a patch series that I started last year. The aim was to try to
> get a monotonic clocksource for Linux/m68k guests. That aim hasn't been
> achieved yet (for q800 machines) but I'm submitting the patch series as
> an RFC becaus
On 8/24/21 12:09 PM, Finn Thain wrote:
> On a real Quadra, accesses to the SY6522 chips are slow because they are
> synchronous with the 783360 Hz "phase 2" clock. In QEMU, they are slow
> only because of the division operation in the timer count calculation.
>
> This patch series improves the
12 matches
Mail list logo
