On Thu, Oct 25, 2012 at 06:02:42PM +0200, Lars Poeschel wrote: > On Thursday 25 October 2012 at 16:00:13, Mark Brown wrote:
> > Why would you want to implement this as a bus? If you're not actually > > rendering things down into a register and value on the bus then you > > should be hooking in at the level before we do the marshalling since > > that's totally irrelevant. This should be done by making the > > marashalling pluggable. > Did you have a look at the code ? I want to render things down to registers No. > and values on the bus! In the one and only case a pin is set to be an output > and someone reads it's value, I don't want the bus to become active and > instead read the value from the regmap cache. Are you saying that whoever designed this USB device has done it so that it takes a byte stream with something like RRVV where RR is the register and VV is the value? That's the marshalling, as you'll have seen that's done before the buses see the data. > > What do you actually need to read back here? > Someone reads a gpio value register. To be able to decide if I really have to > do the read on the usb bus or if I can use a cached value, I have to know if > the pin in question is an output or an input. To get this information I have > to do another register read. If it's an output I give back the cached value, > if it's an input I do the register read. Is the I/O selection per GPIO or per device? > > So just invalidate the cache and it'll get restored next time we look at > > the register. > Yes, this is exactly what I gave as an alternative in my second to last mail. > But this invalidates the whole register map although I just want to update > one register value. So add that functionality to the core if it's not there.
signature.asc
Description: Digital signature
