Subject: P1394> 1212 Issues - was May 1394 PWG Definitions

From: Greg LeClair <[email-masked]>
Date: Wed, 27 May 1998 16:34:18 -0700

Others that have been involved in revisions work please comment.....

My understanding is that current 1212 definitions are an issue. See if the following applies:

Changes to Config ROM may be limited to new keys and or structures. 
Is this what you meant by "revise how config ROM is structured"?

And yes, there is legacy within 1212. The existing spec, it's inclusion as 
a reference in other specs and bus standards......

The compliance terminology on new items is an issue.

Regards,
Greg

-----Original Message-----
From:	Jeff Schnitzer [SMTP:[email-masked]]
Sent:	Wednesday, May 27, 1998 6:34 AM
To:	[email-masked]
Subject:	RE: P1394> May 1394 PWG Definitions

From: "Turner, Randy" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: P1394> May 1394 PWG Definitions
Date: Tue, 26 May 1998 10:29:44 -0700

I was assuming that "current 1212 definitions" would not be an issue,
and that p1212r would take our requirements into account and revise how
config ROM is structured? With the almost non-existent 1394 product
base, I'm also assuming there are no legacy 1212 issues do deal with.

Randy

	-----Original Message-----
	From:	Greg Shue [SMTP:[email-masked]]
	Sent:	Tuesday, May 26, 1998 10:11 AM
	To:	[email-masked]
	Cc:	[email-masked]
	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			[email-masked]
	----------------------------------------------------------------

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 27 May 1998 17:20:50 -0700

See my comments below...

Randy

	-----Original Message-----
	From:	Greg LeClair [SMTP:[email-masked]]
	Sent:	Wednesday, May 27, 1998 4:34 PM
	To:	[email-masked]
	Subject:	P1394> 1212 Issues - was May 1394 PWG
Definitions 

	Others that have been involved in revisions work please
comment.....

	My understanding is that current 1212 definitions are an issue.
See if the following applies:

	Changes to Config ROM may be limited to new keys and or
structures. 
	Is this what you meant by "revise how config ROM is structured"?

	Yes. But limiting changes to "structures" is not very limiting.
Our original proposal including the addition of a "function" directory
is just such a structure addition.

	And yes, there is legacy within 1212. The existing spec, it's
inclusion as 
	a reference in other specs and bus standards......

I was referring to "legacy" in the case of "legacy" SBP-2
implementations in shipping devices that would be used as "targets".

I think 1212R is just extending 1212 to cover other requirements that
have come up since original publication. Whatever "R" does should be
backwards compatible with the original 1212. Of course, I may be wrong
about this.

	Regards,
	Greg

	-----Original Message-----
	From:	Jeff Schnitzer [SMTP:[email-masked]]
	Sent:	Wednesday, May 27, 1998 6:34 AM
	To:	[email-masked]
	Subject:	RE: P1394> May 1394 PWG Definitions

	I was assuming that "current 1212 definitions" would not be an
issue,
	and that p1212r would take our requirements into account and
revise how
	config ROM is structured? With the almost non-existent 1394
product
	base, I'm also assuming there are no legacy 1212 issues do deal
with.

	Randy

		-----Original Message-----
		From:	Greg Shue [SMTP:[email-masked]]
		Sent:	Tuesday, May 26, 1998 10:11 AM
		To:	[email-masked]
		Cc:	[email-masked]
		Subject:	Re: P1394> May 1394 PWG Definitions

		> Under this circumstances and understanding, equating
units to drivers seemed

		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.  :-)

		> 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
[email-masked]

---

From: "Gregory A. LeClair" <[email-masked]>
Date: Wed, 27 May 1998 22:03:49 -0700

Okay. I understand your comments. 

In terms of change / addition to structure - the issues are key 
definitions in 1212r and a registry for the function class values. 

Cheers,
Greg

-----Original Message-----
From:	Turner, Randy [SMTP:[email-masked]]
Sent:	Wednesday, May 27, 1998 5:21 PM
To:	[email-masked]
Subject:	RE: P1394> 1212 Issues - was May 1394 PWG Definitions 

See my comments below...

Randy

	-----Original Message-----
	From:	Greg LeClair [SMTP:[email-masked]]
	Sent:	Wednesday, May 27, 1998 4:34 PM
	To:	[email-masked]
	Subject:	P1394> 1212 Issues - was May 1394 PWG
Definitions 

	Regards,
	Greg

	-----Original Message-----
	From:	Jeff Schnitzer [SMTP:[email-masked]]
	Sent:	Wednesday, May 27, 1998 6:34 AM
	To:	[email-masked]
	Subject:	RE: P1394> May 1394 PWG Definitions

	Randy

		-----Original Message-----
		From:	Greg Shue [SMTP:[email-masked]]
		Sent:	Tuesday, May 26, 1998 10:11 AM
		To:	[email-masked]
		Cc:	[email-masked]
		Subject:	Re: P1394> May 1394 PWG Definitions

		-- 
		Greg Shue
		Hewlett-Packard Company
		Office Products Division
[email-masked]