On Fri, Jan 25, 2013 at 06:00:36PM +0000, Paul Brook wrote: > > To be able to create generic GPIO devices or other devices that have GPIO > > like pins (e.g MDIO), and hook those up to external buses through common > > frameworks, we need agreement on how to model tristate pins. > > A tristate pin model, or at least agreement on how to model these with > > multiple qemu_irqs. > > > > hmm, feels like we've opened a can of worms... > > Probably. I'm not going to insist you use/implement generic GPIO for MDIO, > but > I still think separation between the PHY register interface and the bitbang > code is good (i.e. same as bitbang_i2c).
Sounds, good. > > > Anyway, how would such a qemu_tristate_pin be modelled? > [point 1 moved later so my answers read in a sensible order] > > > 2. Every connection point provides an output/value and an output_enable. > > I think we'd be better providing a single state i.e. an output of 0, 1 or Z. > > Possibly additional Z0/Z1 states to represent high-impedance with > pull-up/down > resistors. Makes sense, the output output-enable are parts of the user of the tristate_pin.. > > > 3. There is a mean for reading the pin value, which is computed based on > > all connection points outputs and output_enables (can be cached). > > For MDIO being able to read the value is sufficient. However in general we > don't want to have to poll it. We want to be told when it changes. Agreed > > > 4. The pin value can be invalid (multiple drivers or no drivers), 0 or 1. > > I can't think of any cases where this is important. In most cases it's > undefined, in the rest it causes physical damage. I thought it might be useful for debugging, not sure how valueable it would be though... > > > 1. It's not point-to-point, has an arbitrary nr of connection points. > > QoM currently only does asymmetric 1-1 connections between objects. However > I > don't think this is a fatal problem. We can still retain an asymmetric API > (effectively equivalent to male and female physical connectors), adding > virtual "wire" objects where they don't match up. It should be possible to > implement this as a backward compatible extension to qemu_irq[1]. In most > cases the additional wire should not be needed. > > For simple output->input (i.e. all existing code) we just need to ignore Z > states. Preferably before they get to the input device. > > For simple bidirectional point-point lines (which should include bitbang-i2c > and bitbang-mdio) the bitbang object controls the value when subject to a Z > output. > > For arbitrary pin connections they all connect to a set of ports on a virtual > wire device. It takes care of arbitrating line state and sending > notifications to the connected devices. > > There are a couple of technical issues: > > Fristly qemu_irq is currently stateless[2]. Giving it state is fine in > principle, but means a lot of load/save code needs fixing. In pactice we can > probably avoid this, but there are some nice benefits from keeping state in > qemu_irq. > > Secondly, the [parent of the] qemu_irq object needs to be able to signal > value > changes to the object on the other side of the link. Currently QoM allows a > property to be linked to an object, but provides no way for the object to > identify/communicate with the property/device linked to it. Thanks for clarifying Cheers, Edgar > > > Paul > > [1] I've no particular attachment to the name qemu_irq. But I really don't > want to have to make anything other than purely mechanical changes to all its > users. > [2] More precicely it has no state that changes over its lifetime.
