[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH V2 2/6] hw/mdio: Generalize etraxfs MDIO bitbang
From: |
Edgar E. Iglesias |
Subject: |
Re: [Qemu-devel] [PATCH V2 2/6] hw/mdio: Generalize etraxfs MDIO bitbanging emulation (fwd) |
Date: |
Sat, 26 Jan 2013 22:33:56 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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.