mbox series

[v2,0/5] Stripe control functionality

Message ID 1547227328-32558-1-git-send-email-spujar@nvidia.com (mailing list archive)
Headers show
Series Stripe control functionality | expand

Message

Sameer Pujar Jan. 11, 2019, 5:22 p.m. UTC
Background
==========

Azalia Controller fetches command and audio data via DMA and send them
to codec through SDO(Serial Data Out) lines. SDO is for outboung and it
broadcasts to all codecs. There is atleast one SDO line present, but
there can be multiple SDO lines supported for extended bandwidth. This
is essential when a platform supports multiple hdmi/dp sinks and there
is a requirement for higher resolution audio playback. In such cases
simultaneous audio playback data can be striped across multiple SDOs.

Global Capabilities(GCAP) Register indicates the capabilities of the
controller. Bits 2:1 of GCAP can be read to know the number of supported
SDO lines (below is from HD audio spec)
  00: 1 SDO
  01: 2 SDO
  10: 4 SDO
  11: Reserved

Stripe control verb reports and controls the stripe capability of an
Audio Output Converter. This verb needs to be implemented only for an
audio output converter and only if the stripe bit of the Audio Widget
Capabilities parameter is 1. 
Stripe control: get code(0xf24) and set code(0x724)

Change log
==========

v1-->v2:
-------- 
  Patch 1: "ALSA: hda: add verbs for stripe control"
    * no change

  Patch 2: "ALSA: hda: Add api to program stripe control bits"
    * no change

  Patch 3: "ALSA: hda: add register offset for stripe control"
    * added mask for stripe control programming

  Patch 4: "ALSA: hda: program stripe bits for controller"
    * used stripe control mask instead of hard coded value

  Patch 5: "ALSA: hda: program stripe control for codec"
    * added conditional check to know if striping is supported.
      If supported, then only stripe verb is implemented.

===========

Sameer Pujar (5):
  ALSA: hda: add verbs for stripe control
  ALSA: hda: Add api to program stripe control bits
  ALSA: hda: add register offset for stripe control
  ALSA: hda: program stripe bits for controller
  ALSA: hda: program stripe control for codec

 include/sound/hda_register.h |  2 ++
 include/sound/hda_verbs.h    |  2 ++
 include/sound/hdaudio.h      |  3 +++
 sound/hda/hdac_stream.c      | 40 ++++++++++++++++++++++++++++++++++++++++
 sound/pci/hda/patch_hdmi.c   | 10 +++++++++-
 5 files changed, 56 insertions(+), 1 deletion(-)

Comments

Pierre-Louis Bossart Jan. 11, 2019, 6:02 p.m. UTC | #1
On 1/11/19 11:22 AM, Sameer Pujar wrote:
> Background
> ==========
>
> Azalia Controller fetches command and audio data via DMA and send them
> to codec through SDO(Serial Data Out) lines. SDO is for outboung and it
> broadcasts to all codecs. There is atleast one SDO line present, but
> there can be multiple SDO lines supported for extended bandwidth. This
> is essential when a platform supports multiple hdmi/dp sinks and there
> is a requirement for higher resolution audio playback. In such cases
> simultaneous audio playback data can be striped across multiple SDOs.
>
> Global Capabilities(GCAP) Register indicates the capabilities of the
> controller. Bits 2:1 of GCAP can be read to know the number of supported
> SDO lines (below is from HD audio spec)
>    00: 1 SDO
>    01: 2 SDO
>    10: 4 SDO
>    11: Reserved
>
> Stripe control verb reports and controls the stripe capability of an
> Audio Output Converter. This verb needs to be implemented only for an
> audio output converter and only if the stripe bit of the Audio Widget
> Capabilities parameter is 1.
> Stripe control: get code(0xf24) and set code(0x724)

the series look ok (one minor comment on operator precedence) and 
aligned with my understanding of the HDaudio 1.0a spec.

That said you made no mention of the Stripe bit  (figure 86) and fields 
22:20 (Stripe capability) in Figure 75, so it's not clear to me if the 
support added in this patchset is sufficient or if there is additional 
logic to be set.

There is also a difference between what the controller supports and the 
actual board layout, so it's not clear if the GCAP are really the raw 
capabilities or the ones filtered by BIOS folks to reflect the actual 
platform hardware implementation.

-Pierre
Sameer Pujar Jan. 12, 2019, 6:31 a.m. UTC | #2
On 1/11/2019 11:32 PM, Pierre-Louis Bossart wrote:
>
> On 1/11/19 11:22 AM, Sameer Pujar wrote:
>> Background
>> ==========
>>
>> Azalia Controller fetches command and audio data via DMA and send them
>> to codec through SDO(Serial Data Out) lines. SDO is for outboung and it
>> broadcasts to all codecs. There is atleast one SDO line present, but
>> there can be multiple SDO lines supported for extended bandwidth. This
>> is essential when a platform supports multiple hdmi/dp sinks and there
>> is a requirement for higher resolution audio playback. In such cases
>> simultaneous audio playback data can be striped across multiple SDOs.
>>
>> Global Capabilities(GCAP) Register indicates the capabilities of the
>> controller. Bits 2:1 of GCAP can be read to know the number of supported
>> SDO lines (below is from HD audio spec)
>>    00: 1 SDO
>>    01: 2 SDO
>>    10: 4 SDO
>>    11: Reserved
>>
>> Stripe control verb reports and controls the stripe capability of an
>> Audio Output Converter. This verb needs to be implemented only for an
>> audio output converter and only if the stripe bit of the Audio Widget
>> Capabilities parameter is 1.
>> Stripe control: get code(0xf24) and set code(0x724)
>
> the series look ok (one minor comment on operator precedence) and 
> aligned with my understanding of the HDaudio 1.0a spec.
>
> That said you made no mention of the Stripe bit  (figure 86) and 
> fields 22:20 (Stripe capability) in Figure 75, so it's not clear to me 
> if the support added in this patchset is sufficient or if there is 
> additional logic to be set.
>
Stripe bit is part of Audio Widget Capability parameter and is mentioned 
above in the last section of background. Patch-5(v2) checks for the 
stripe bit, before sending stripe control verb.
As far as stripe control register is concerned (22:20), I don't think 
any SW programming is required for this.
> There is also a difference between what the controller supports and 
> the actual board layout, so it's not clear if the GCAP are really the 
> raw capabilities or the ones filtered by BIOS folks to reflect the 
> actual platform hardware implementation.
>
> -Pierre
>
>
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
Pierre-Louis Bossart Jan. 14, 2019, 5:40 p.m. UTC | #3
>>> Stripe control verb reports and controls the stripe capability of an
>>> Audio Output Converter. This verb needs to be implemented only for an
>>> audio output converter and only if the stripe bit of the Audio Widget
>>> Capabilities parameter is 1.
>>> Stripe control: get code(0xf24) and set code(0x724)
>>
>> the series look ok (one minor comment on operator precedence) and 
>> aligned with my understanding of the HDaudio 1.0a spec.
>>
>> That said you made no mention of the Stripe bit  (figure 86) and 
>> fields 22:20 (Stripe capability) in Figure 75, so it's not clear to 
>> me if the support added in this patchset is sufficient or if there is 
>> additional logic to be set.
>>
> Stripe bit is part of Audio Widget Capability parameter and is 
> mentioned above in the last section of background. Patch-5(v2) checks 
> for the stripe bit, before sending stripe control verb.

Ah yes, I thought this patchset added stripe control starting from 
scratch but some definitions were already present. Thanks for the precision.

> As far as stripe control register is concerned (22:20), I don't think 
> any SW programming is required for this.

Yes correct. this is on GET only so something the codec needs to worry 
about, not the driver.