On Wed, 26 Jan 2005 15:22:52 -0500
Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> On Wed, 26 Jan 2005 23:07:12 +0300, Evgeniy Polyakov
> <[EMAIL PROTECTED]> wrote:
> >
> > Chip driver provides access methods to the attached logical devices.
> > It probes and activates them, if appropriate module is loaded.
> >
> > Your example again is not suitable for superio case.
> >
> > With superio you have several identical logical devices, access to which
> > is absolutely standard in second level(logic befind access),
> > but in first one(physicall access) it can differ.
> >
> > So here is the real example of superio usage:
> >
> > userspace
> > |
> > superio core
> > ......
> >
> > GPIO
> > |----| |--|
> > pc87366 sc1100
> > |----| |---|
> > WDT
> >
> > Logical device GPIO is accessed by read/write methods, which only have
> > pin number(it is not how this methods are exactly implemeted though)
> > as parameter.
> >
> > For example userspace accesses GPIO at sc1100 - it will be translated
> > into read methods called from appropriate superio chip with appropriate
> > parameters.
> >
> > When we have multiple GPIO logical devices(each in it's own superio chip)
> > it is more convenient to use just the same object.
>
> I take an exception to that. I think useroace is not concerned with
> topology and ownership of logical devices, the data is more important.
> I.e. you need to know that some pin respons to CPU temperature but you
> don't really care that it connected to it87 as opposed to some other
> chip. Therefore I think that ldev should translate to exactly the same
> underlying object. Consider the picture below:
>
> GPIO0 GPIO1 GPIO2 GPIO3
> | | | |
> pc87266 sc1100 blah123
> | |
> WDT0 WDT1
>
> This will allow:
> - map every hardware piece (not entire chip, separate functions) to a
> device file to userspace can use standard read/write/select/poll if
> choses so.
> - easily represent them in sysfs and also allow userspace access to
> individual bits through sysfs attributes.
> - will not give headaches with poer management when half of device is
> powered down and half is active.
> - provided that there are alternative interfaces outlined above
> superio can be decoupled from the connector.
With presented design we already have above links.
Each superio chip has a list of chain objects, each of which points to
the connected logical device.
Logical device usage must be done using provided logical device methods
(like read/write/control).
>From that point of view noone even knows, that above GPIO0 and GPIO1
(on the picture) are actually the same object(if they are not clones,
but if they are, then picture becomes 100% real).
> I wonder if it should be called "gpio" bus as opposed to superio
> because only chips are "super", the bus consists of very simple
> devices and drivers.
I can not agree that it is a bus.
Bus abstraction can be _only_ applied to hierarchy in the only one
superio chip.
> > I did not understand you from the beginning...
>
> We are getting there I believe ;)
>
> --
> Dmitry
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
