qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v1] nrf51: Fix last GPIO CNF address


From: Andrew Jeffery
Subject: Re: [PATCH v1] nrf51: Fix last GPIO CNF address
Date: Fri, 10 Apr 2020 13:12:06 +0930
User-agent: Cyrus-JMAP/3.1.7-1104-g203475c-fmstable-20200408v2


On Tue, 7 Apr 2020, at 18:20, Peter Maydell wrote:
> On Tue, 7 Apr 2020 at 09:45, Joel Stanley <address@hidden> wrote:
> > On Tue, 7 Apr 2020 at 08:41, Peter Maydell <address@hidden> wrote:
> > > Do you have a link to this patch, please? I had a quick search through
> > > my mailing list articles but couldn't see anything obviously relevant.
> >
> > There is a reference in this thread:
> >
> > https://lore.kernel.org/qemu-devel/address@hidden/
> >
> > The patch is here:
> >
> > https://lore.kernel.org/qemu-devel/address@hidden/
> 
> Oh, that's from 2017, no wonder I couldn't find it!

Yeah, I never quite got back to finishing it :(

It's development was driven by development of the ASPEED ADC model,
which I hacked up in the interest of getting the ASPEED SDK booting
under qemu (the SDK kernel had an infinite spin waiting for the ADC-ready
bit).

IIRC Phil wanted to enable sub-word accesses to the sample value
registers but I didn't want to spread logic dealing with different access
widths through the model. We already had a mechanism to describe the
model's  supported access sizes (as opposed to the valid access sizes
allowed by hardware) in the `impl` member of the MemoryRegionOps, so
I was trying to use that, but it didn't work as I needed.

The accesses generated at the point of the guest MMIO need to be
expanded to the access width supported by the model and then the
resulting data trimmed again upon returning the data (in the case of a
read) via the MMIO operation.

So the intent was less about unaligned accesses than enabling models
implementations that only have to handle certain-sized access widths.
It happens to help the unaligned access case as well.

> 
> Does somebody who's already reviewed the patch want to summarize
> what the effects on devices are -- i.e. what calls the device's read/write
> methods used to get if the guest did an unaligned access, including an
> unaligned access half off-the-end of the memory region, and what
> calls the read/write methods get after the patch ? The patch's commit
> message doesn't really describe what it's doing...

Honestly any of that information has well left my memory at this point, I'd
have to analyse the patch to recover it.

I was hoping that my turn-around time would be shorter than 3 years but
there hasn't been a shortage of fires to put out in the mean time.

Andrew



reply via email to

[Prev in Thread] Current Thread [Next in Thread]