On Tue, May 20, 2014 at 10:10:00AM +0200, Takashi Iwai wrote:
> > struct avsink_client {
> > const char *name; /* client name */
> > int type; /* client type*/
> > void *context;
> > struct module *module; /* top-level module for locking */
> >
> > struct avsink_client *peer; /* peer client */
> >
> > /* shared power wells */
> > struct avsink_power_well *power_well;
> > int num_power_wells;
>
> The "power well" is Intel-specific things. Better to use a more
> generic term. (And, I'm always confused what "power well disable"
> means :)
Given that runtime pm is a prevalent usage, wouldn't it make sense
to say that I am HDMI client so keep the resources on? This can be easily
managed if we are able to create the audio device as child of display
controller. That would be implementation agnostic and controller can do whatever
(power well or not) to keep it on/off
>
> >
> > /* endpoints, display outputs or audio inputs */
> > struct avsink_endpoint * endpoint;
> > int num_endpints;
> >
> > struct avsink_registers_ops *reg_ops; /* ops to access registers of a client */
>
> Use const for ops pointers in general (also other cases below).
>
>
> > void *private_data;
> > ...
> > };
> >
> > On system boots, the avsink module is loaded before the display and audio driver module. And the display and audio
> > driver may be loaded on parallel.
>
> For HD-audio HDMI, both controller and codec drivers would need the
> avsink access. So, both drivers will register the own client?
that sound logical here..
>
>
> > * If a specific display driver (eg. i915) supports avsink, it can create a display client, add power wells and display
> > outputs to the client, and then register the display client to the avsink core. Then it may look up if there is any
> > audio client registered, by name or type, and may find an audio client registered by some audio driver.
> >
> > * If an audio driver supports avsink, it usually should look up a registered display client by name or type at first,
> > because it may need the shared power well in GPU and check the display outputs' name to bind the audio inputs. If
> > the display client is not registered yet, the audio driver can choose to wait (maybe in a work queue) or return
> > -EAGAIN for a deferred probe. After the display client is found, the audio driver can register an audio client with
> > the display client's name as the peer name, the avsink core will bind the display and audio clients to each other.
>
> There is already "component" framework, BTW. Can we integrate it into
> avsink instead?
>
>
> > Open question:
> > If the display or audio driver is disabled by the black list, shall we introduce a time out to avoid waiting for the
> > other client registered endlessly?
>
> Yes, timeout sounds like a sensible option.
>
>
> > 2. Shared power wells (optional)
> >
> > The audio and display devices, maybe only part of them, may share a common power well (e.g. for Intel Haswell and
> > Broadwell). If so, the driver that controls the power well should define a power well object, implement the get/put ops,
> > and add it to its avsink client before registering the client to avsink core. Then the peer client can look up this
> > power well by its name, and get/put this power well as a user.
> >
> > A client can have multiple power well objects.
> >
> > struct avsink_power_well {
> > const char *name; /* name of the power well */
> > void *context; /* parameter of get/put ops, maybe device pointer for this power well */
> > struct avsink_power_well_ops *ops
> > };
> >
> > struct avsink_power_well_ops {
> > int (*get)(void *context);
> > int (*put)(void *context);
> > };
> >
> > API:
> > int avsink_new_power(struct avsink_client *client,
> > const char *power_name,
> > void * power_context,
> > struct avsink_power_well_ops *ops,
> > struct avsink_power_well **power_ret);
> >
> > struct avsink_power_well *avisnk_lookup_power(const char *name);
> >
> > int avsink_get_power(struct avsink_power_well *power); /* Reqesut the power */
> > int avsink_put_power(struct avsink_power_well *power); /* Release the power */
> >
> > For example, the i915 display driver can create a device for the shared power well in Haswell GPU, implement its PM
> > functions, and use the device pointer as the context when creating the power well object, like below
> >
> > struct avsink_power_well_ops i915_power_well_ops = {
> > .get = pm_runtime_get_sync;
> > .put = pm_runtime_put_sync;
> > };
>
> This needs function pointer cast, and it's not portable although it'd
> work practically.
>
>
> > ...
> > avsink_new_power ( display_client,
> > "i915_display_power_well",
> > pdev, /* pointer of the power well device */
> > &i915_power_well_ops,
> > ...)
> >
> > Power domain is not used here since a single device seems enough to represent a power well.
> >
> > 3. Display output and audio input endpoints
> >
> > A display client should register the display output endpoints and its audio peer client should register the audio input
> > endpoints. A client can have multiple endpoints. The avsink core will bind an audio input and a display output as peer
> > to each other. This is to allow the audio and display driver to synchronize with each other for each display pipeline.
> >
> > All endpoints should be added to a client before the client is registered to avsink core. Dynamic endpoints are not
> > supported now.
> >
> > A display out here represents a physical HDMI/DP output port. And as long as it's usable in the system (i.e. physically
> > connected to the HDMP/DP port on the machine board), the display output should be registered not matter the port is
> > connected to an external display device or not. And if HW and display driver can support DP1.2 daisy chain (multiple DP
> > display devices can be connected to a single port), multiple static displays outputs should be defined for the DP port
> > according to the HW capability. The port & display device number can be indicated by the name (e.g. "i915_DDI_B",
> > "i915_DDI_B_DEV0", "i915_DDI_B_DEV1", or "i915_DDI_B_DEV2"), defined by the display driver.
> >
> > The audio driver can check the endpoints of its peer display client and use an display endpoint's name, or a presumed
> > display endpoint name, as peer name when registering an audio endpoint, thus the avsink core will bind the two display
> > and audio endpoints as peers.
> >
> > struct avsink_endpoint {
> > const char *name; /*name of the endpoint */
> > int type; /* DISPLAY_OUTPUT or AUDIO_INPUT */
> > void *context; /* private data, used as parameter of the ops */
> > struct avsink_endpoint_ops *ops;
> >
> > struct avsink_endpoint *peer; /* peer endpoint */
> > };
> >
> > struct avsink_endpoint_ops {
> > int (*get_caps) (enum had_caps_list query_element,
> > void *capabilities,
> > void *context);
> > int (*set_caps) (enum had_caps_list set_element,
> > void *capabilities,
> > void *context);
> > int (*event_handler) (enum avsink_event_type event_type, void *context);
> > };
> >
> > API:
> > int avsink_new_endpoint (struct avsink_client *client,
> > const char *name,
> > int type, /* DISPLAY_OUTPUT or AUDIO_INPUT*/
> > void *context,
> > const char *peer_name, /* can be NULL if no clue */
> > avsink_endpoint_ops *ops,
> > struct avsink_endpoint **endpoint_ret);
> >
> > int avsink_endpoint_get_caps(struct avsink_endpoint *endpoint,
> > enum avsink_caps_list t get_element,
> > void *capabilities);
> > int avsink_endpoint_set_caps(struct avsink_endpoint *endpoint,
> > enum had_caps_list set_element,
> > void *capabilities);
> >
> > int avsink_endpoint_post_event(struct avsink_endpoint *endpoint,
> > enum avsink_event_type event_type);
> >
> > 4. Get/Set caps on an endpoint
> >
> > The display or audio driver can get or set capabilities on an endpoint. Depending on the capability ID, the avsink core
> > will call get_caps/set_caps ops of this endpoint, or call get_caps/set_caps ops of its peer endpoint and return the
> > result to the caller.
> >
> > enum avsink_caps_list {
> > /* capabilities for display output endpoints */
> > AVSINK_GET_DISPLAY_ELD = 1,
> > AVSINK_GET_DISPLAY_TYPE, /* HDMI or DisplayPort */
> > AVSINK_GET_DISPLAY_NAME, /* Hope to use display device name under /sys/class/drm, like "card0-DP-1", for user
> > * space to figure out which HDMI/DP output on the drm side corresponds to which audio
> > * stream device on the alsa side */
> > AVSINK_GET_DISPLAY_SAMPLING_FREQ, /* HDMI TMDS clock or DP link symbol clock, for audio driver to
> > * program N value
> > */
> > AVSINK_GET_DISPLAY_HDCP_STATUS,
> > AVSINK_GET_DISPLAY_AUDIO_STATUS, /* Whether audio is enabled */
> > AVSINK_SET_DISPLAY_ENABLE_AUDIO, /* Enable audio */
> > AVSINK_SET_DISPLAY_DISABLE_AUDIO, /* Disable audio */
> > AVSINK_SET_DISPLAY_ENABLE_AUDIO_INT, /* Enable audio interrupt */
> > AVSINK_SET_DISPLAY_DISABLE_AUDIO_INT, /* Disable audio interrupt */
> >
> > /* capabilities for audio input endpoints */
> > AVSINK_GET_AUDIO_IS_BUSY, /* Whether there is an active audio streaming */
> > OTHERS_TBD,
> > };
> >
> > For example, the audio driver can query ELD info on an audio input endpoint by using caps AVSINK_GET_DISPLAY_ELD, and
> > avsink core will call get_caps() on the peer display output endpoint and return the ELD info to the audio driver.
> >
> > Some audio driver may only use part of these caps. E.g. HD-Audio driver can use bus commands instead of the ops to
> > control the audio on gfx side, so it doesn't use caps like ENABLE/DISABLE_AUDIO or ENABLE/DISABLE_AUDIO.
> >
> > When the display driver want to disable a display pipeline for hot-plug, mode change or power saving, it can use caps
> > AVSINK_GET_AUDIO_IS_BUSY to check if the audio input is busy (active streaming) on this display pipeline. And if audio
> > is busy, the display driver can choose to wait or go ahead to disable display pipeline anyway. For the latter case, the
> > audio input endpoint will be notified by an event and should abort audio streaming.
> >
> > 5. Event handling of endpoints
> >
> > A driver can post events on an endpoint. Depending on the event type, the avsink core will call the endpoint's event
> > handler or pass the event to its peer endpoint and trigger the peer's event handler function if defined.
> >
> > int avsink_endpoint_post_event(struct avsink_endpoint *endpoint,
> > enum avsink_event_type event_type);
what would be the context of callback. Anything less that atomic would tend to
cause timing issues...
> >
> > Now we only defined event types which should be handled by the audio input endpoints. The event types can be extended
> > in the future.
> >
> > enum avsink_event_type {
> > AVSINK_EVENT_DISPLAY_DISABLE = 1, /* The display pipeline is disabled for hot-plug, mode change or
> > * suspend. Audio driver should stop any active streaming.
> > */
> > AVSINK_EVENT_DISPLAY_ENABLE, /* The display pipeline is enabled after hot-plug, mode change or
> > * resume. Audio driver can restore previously interrupted streaming
> > */
> > AVSINK_EVENT_DISPLAY_MODE_CHANGE, /* Display mode change event. At this time, the new display mode is
> > * configured but the display pipeline is not enabled yet. Audio driver
> > * can do some configurations such as programing N value */
> > AVSINK_EVENT_DISPLAY_AUDIO_BUFFER_DONE, /* Audio Buffer done interrupts. Only for audio drivers if DMA and
> > * interrupt are handled by GPU
> > */
> > AVSINK_EVENT_DISPLAY_AUDIO_BUFFER_UNDERRUN, /* Audio Buffer under run interrupts. Only for audio drivers if
> > * DMA and interrupt are handled by GPU
> > */
> > };
> >
> > So for a display driver, it can post an event on a display output endpoint and get processed by the peer audio input
> > endpoint. Or it can also directly post an event on a peer audio input endpoint, by using the 'peer' pointer on a
> > display output endpoint.
>
> Hm, one unclear thing to me is who handles this event by how.
> Suppose you issue GET_ELD on an audio endpoint. Then what would
> avsink does against the display client exactly?
I think above 4 examples are for async events reported by controller to clients.
For example buffer done, or hot plug which needs to be notified. Something like
GET_ELD doesn't need notification but should be a sync read.
--
~Vinod
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
