Skip to main content

POD Ready Clarification Question

5 replies [Last post]
Joined: 2010-06-08

I would like to make a clarification request to understand
why the “POD Ready” status is being overloaded by the RI
stack to imply that the CableCARD and all of its resources
are fully operational. Unfortunately, there is little or no
documentation to clearly understand what is expected out of
the MPEOS POD interfaces.

Our interpretation of the “POD ready” event and status is
that it identifies the CARD as not only being inserted but
powered up and operational. Our definition of operational is
that the CARD has been successfully powered up, reset, and
has established a communication link with the Host. Based
on this interpretation, the platform would be responsible to
asynchronously notify the stack when new GFC, AI/MMI, and
CARD resource updates were available.

On the other hand, based on the RI stack implementation of
the POD module, I believe the RI stack expects the platform
to have the CARD data originating from multiple resources
sessions and APDUs to be available when the “POD Ready”
event is signaled. The one concern with this interpretation
of “POD Ready” is that there is no definition about which
set of resource sessions and data must be established before
the Host via the MPEOS can notify the stack that the CARD is

Any clarification and documentation reference on this would
be helpful.


Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2008-07-03

Just so I can help you get to the bottom of this faster, can you point me to the code that is overloading the POD Ready status?


Joined: 2010-06-08

These are the MPEOS definitions that are being referenced:

MPE_POD_EVENT_READY, /* CableCard inserted and ready for use */

* This structure is the main database container for all of the POD related information.
typedef struct
mpe_Mutex pod_mutex; /* Mutex for synchronous access */
mpe_Bool pod_isPresent; /* POD present flag (possibly not yet initialized). */
mpe_Bool pod_isReady; /* POD present & initialized flag. */
mpe_PODAppInfo *pod_appInfo; /* POD application information. */
mpe_PODFeatures *pod_features; /* POD generic feature list. */
mpe_PODFeatureParams pod_featureParams; /* POD generic feature parameters. */
uint32_t pod_maxElemStreams; /* how many Elementary streams the POD can decode at one time */
uint32_t pod_maxPrograms; /* how many programs the POD can decode at one time */
uint32_t pod_maxTransportStreams; /* how many transport streams the POD can decode at one time */
} mpe_PODDatabase;

Joined: 2008-07-03

The MPE layer manages a cache of the information available to applications via the APIs. This cache is represented by the mpe_PODDatabase structure you indicated above. There is only a single instance of this cache instantiated at system startup and changes to the cache are made via the MPEOS APIs (mpe_PODDatabase is passed to those APIs).

The MPE_POD_EVENT_READY event should only be sent when the MPEOS porting layer has fully populated the mpe_PODDatabase structure. This includes:

1) Connection to the Application Information resource and exchange of the application_info_req() and application_info_cnf() APDUs

2) Connection to the Generic Feature resource and exchange of all APDUs required to determine the list of supported features and the populate the mpe_PODDatabase with the values of each supported feature.

I believe that much should suffice. In the PC Platform port ($OCAPROOT/mpe/os/RI_Common/mpeos_pod.c), we grab the pointer the mpe_PODDatabase and hold onto it so we can update it when we receive asynchronous notifications from the POD (along with sending any appropriate events)


Joined: 2010-06-08

Thanks Greg. Another clarification:

A new dependency was added in the 1.1.4 release with regards to the “M-Mode Device Capability Discovery” because the stack now tries to manage the Conditional Access resource directly instead of having the platform do the management.

Does this imply that the MPEOS layer needs to now wait for the M-Mode capabilities to be fully discovered before the “POD ready” event is sent?

Would it be possible to add some clarification in the MPEOS header file to clarify the conditions under which the supported events and status should be updated?

How can we prevent the definition of the MPEOS “POD Ready” definition from being changed to include other resources or APDUs in the future?

Joined: 2008-07-03

Good call on the CA session... I missed that one. Actually, I would probably add to my list above by saying:

Once the POD_READY event is sent, the CableCARD stack should be sufficiently initialized such that all of the mpeos_pod* APIs can be called by the stack. This includes opening connections to the SAS, CA, and MMI resources

As far as "preventing" the POD READY definition from being changed. We really can't. If specification changes are introduced, we may have to change the definition. But that information could be conveyed in better documentation as you suggest.

As far getting the documentation in place, that is a whole other topic. All I can suggest to you at this point is to create a bug in IssueTracker and we will get to it when we can.