I think you may be touching on a couple of points here that tie into
what we want to put into Config ROM and the location - in a Unit dir
or in the 'Function' branch.
Some clarifications though:
"Equating *_SW_VERSION with a monolithic driver "
- 1212 states 'I/O driver software'
"all other layers would have to be queried using the identified driver"
- Or assumed based on other info in the Config ROM - just using R/W transactions
"And this makes sense when we remember that 1212 is a Control and Status REGISTER
Architecture. Now we're trying to encode things well beyond the register layer."
- See page 15, Section 2.1 - item d. Are we out of scope?
ISSUES:
1. Function is something which doesn't consistently map to existing 1212 structure (Y/N)
- If yes, what is the 1212 structure?
- If no, what should the structure be in 1212r (FDS?)
2. How much function info SHALL be required in the Config ROM for an implementation.
- Fixed for all device classes
- Common subset with vendor or organization unique extensions.
Comments?
Regards,
Greg LeClair
-----Original Message-----
From: Greg Shue [SMTP:gregs@sdd.hp.com]
Sent: Tuesday, May 26, 1998 10:11 AM
To: Atsushi Nakamura
Cc: p1394@pwg.org
Subject: Re: P1394> May 1394 PWG Definitions
Ats wrote:
> I do not intend to take this up as a problem, but I feel 1394 protocols
> (current actual usage) do not equate units with functions, but as
> protocols. (ex. AV/C unit, SBP-2 unit, etc.)
> Under this circumstances and understanding, equating units to drivers seemed
> to fit.
The big struggle I have with current 1212 definitions is that
they do equate *_SW_VERSION with a monolithic driver (where *
could be either Module, Node, or Unit), and they don't provide a
way of encoding arbitrary number of layers of drivers into the
Config ROM. Under this idea, all other layers would have to
be queried using the identified driver. And this makes sense
when we remember that 1212 is a Control and Status REGISTER
Architecture. Now we're trying to encode things well beyond
the register layer. :-)
> Greg said :
> >I think we need to expand the idea of function : unit on a 1:1 ratio
>
> True. Another point is
> 1) function : unit on a 1:n ratio......1 function using/supported by one or more protocols
> (unit dir level)
> 2) function : unit on a n:1 ratio......one or more functions supported by 1 protocol.
> (unit dir level)
>
> Though the PWG profile may allow only 1), both have to be allowed
> looking from the point of 1212 (and any protocols).
We may also need to look at the problem of how to encode multiple
layers of protocols needed to access a function.
-- Greg Shue Hewlett-Packard Company Office Products Division gregs@sdd.hp.com ----------------------------------------------------------------