05 Aug, 2020

1 commit

  • A variable dma_stop_delay is added as a new member in hdac_bus
    structure to avoid memory decode error incase DMA RUN bit is not
    disabled in the given timeout from snd_hdac_stream_sync function and
    followed by stream reset which results in memory decode error between
    reset set and clear operation.

    Signed-off-by: Mohan Kumar
    Link: https://lore.kernel.org/r/20200805095221.5476-3-mkumard@nvidia.com
    Signed-off-by: Takashi Iwai

    Mohan Kumar
     

04 May, 2020

1 commit

  • Stripe control programming is governed by following formula, which is
    referenced from the HD Audio specification(Revision 1.0a).
    { ((num_channels * bits_per_sample) / number of SDOs) >= 8 }

    Currently above is implemented in snd_hdac_get_stream_stripe_ctl().
    This patch introduces a structure member to store the default factor
    of '8'. If any HW wants to use a different value, this member can be
    easily updated.

    Signed-off-by: Sameer Pujar
    Link: https://lore.kernel.org/r/1588580176-2801-3-git-send-email-spujar@nvidia.com
    Signed-off-by: Takashi Iwai

    Sameer Pujar
     

28 Jan, 2020

1 commit

  • Tegra HDA has FIFO size which can hold upto 10 audio frames to support
    DVFS. When HDA DMA RUN bit is set to 0 to stop the stream, the DMA RUN
    bit will be cleared to 0 only after transferring all the remaining audio
    frames queued up in the fifo. This is not in sync with spec which states
    the controller will stop transmitting(output) in the beginning of the
    next frame for the relevant stream.

    The above behavior with Tegra HDA was resulting in machine check error
    during the system suspend flow with active audio playback with below kernel
    error logs.
    [ 33.524583] mc-err: [mcerr] (hda) csr_hdar: EMEM address decode error
    [ 33.531088] mc-err: [mcerr] status = 0x20000015; addr = 0x00000000
    [ 33.537431] mc-err: [mcerr] secure: no, access-type: read, SMMU fault: none

    This was due to the fifo has more than one audio frame when the DMA
    RUN bit is set to 0 during system suspend flow and the timeout handling in
    snd_hdac_stream_sync() was not designed to handle this scenario. So the
    DMA will continue running even after timeout hit until all remaining
    audio frames in the fifo are transferred, but the suspend flow will try
    to reset the controller and turn off the hda clocks without the knowledge
    of the DMA is still running and could result in mc-err.

    The above issue can be resolved by doing stream reset with the help of
    snd_hdac_stream_reset() which would ensure the DMA RUN bit is cleared
    if the timeout was hit in snd_hdac_stream_sync().

    Signed-off-by: Mohan Kumar
    Link: https://lore.kernel.org/r/20200128051508.26064-1-mkumard@nvidia.com
    Signed-off-by: Takashi Iwai

    Mohan Kumar
     

14 Jan, 2020

1 commit


15 Dec, 2019

1 commit

  • The commit e38e486d66e2 ("ALSA: hda: Modify stream stripe mask only
    when needed") tried to address the regression by the unconditional
    application of the stripe mask, but this caused yet another
    regression for the previously working devices. Namely, the patch
    clears the azx_dev->stripe flag at snd_hdac_stream_clear(), but this
    may be called multiple times before restarting the stream, so this
    ended up with clearance of the flag for the whole time.

    This patch fixes the regression by moving the azx_dev->stripe flag
    clearance at the counter-part, the close callback of HDMI codec
    driver instead.

    Fixes: e38e486d66e2 ("ALSA: hda: Modify stream stripe mask only when needed")
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205855
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204477
    Cc:
    Link: https://lore.kernel.org/r/20191214175217.31852-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

03 Dec, 2019

1 commit

  • The recent commit in HD-audio stream management for changing the
    stripe control seems causing a regression on some platforms. The
    stripe control is currently used only by HDMI codec, and applying the
    stripe mask unconditionally may lead to scratchy and static noises as
    seen on some MacBooks.

    For addressing the regression, this patch changes the stream
    management code to apply the stripe mask conditionally only when the
    codec driver requested.

    Fixes: 9b6f7e7a296e ("ALSA: hda: program stripe bits for controller")
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204477
    Tested-by: Michael Pobega
    Cc:
    Link: https://lore.kernel.org/r/20191202074947.1617-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

13 Aug, 2019

1 commit

  • Currently we set hdac_stream.fifo_size field only for the playback
    stream by some odd reason I forgot, while this field isn't referred in
    any places. Actually this fifo_size field would have been required in
    the position report correction for VIA chipset, but due to the lack of
    the fifo_size set for capture streams, snd-hda-intel driver fetches
    the register by itself.

    This patch straightens and simplifies the code by setting the
    fifo_size field for both playback and capture streams, and use it in
    the HD-audio controller driver.

    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

08 Aug, 2019

1 commit

  • The HD-audio core allocates and releases pages via driver's specific
    dma_alloc_pages and dma_free_pages ops defined in bus->io_ops. This
    was because some platforms require the uncached pages and the handling
    of page flags had to be done locally in the driver code.

    Since the recent change in ALSA core memory allocator, we can simply
    pass SNDRV_DMA_TYPE_DEV_UC for the uncached pages, and the only
    difference became about this type to be passed to the core allocator.
    That is, it's good time for cleaning up the mess.

    This patch changes the allocation code in HD-audio core to call the
    core allocator directly so that we get rid of dma_alloc_pages and
    dma_free_pages io_ops. If a driver needs the uncached pages, it has
    to set bus->dma_type right after the bus initialization.

    This is merely a code refactoring and shouldn't bring any behavior
    changes.

    Reviewed-by: Pierre-Louis Bossart
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

21 May, 2019

1 commit

  • Add SPDX license identifiers to all files which:

    - Have no license information of any form

    - Have EXPORT_.*_SYMBOL_GPL inside which was used in the
    initial scan/conversion to ignore the file

    These files fall under the project license, GPL v2 only. The resulting SPDX
    license identifier is:

    GPL-2.0-only

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

13 Mar, 2019

1 commit


15 Jan, 2019

2 commits

  • Platforms having multiple SORs and hdmi/dp sinks require higher
    bandwidth to support simultaneous playbacks of higher resolution.
    If hda controller supports multiple SDO lines, STRIPE can be used
    to indicate how many of the SDO lines the stream should be striped
    across.

    During stream start stripe control bits are programmed to use given
    number of sdo lines and the same is cleared during stream stop.

    Signed-off-by: Sameer Pujar
    Reviewed-by: Mohan Kumar D
    Reviewed-by: Ravindra Lokhande
    Reviewed-by: Pierre-Louis Bossart
    Signed-off-by: Takashi Iwai

    Sameer Pujar
     
  • Controllers and codecs can support striping of audio out across
    multiple SDO lines. The number of supported SDO lines can be
    specific to chip. GCAP register can be read to know the maximum
    supported SDO lines.

    snd_hdac_get_stream_stripe_ctl() is exposed to program stripe bits
    on controller and codec side.
    stripe value: 0 for 1SDO, 1 for 2SDO, 2 for 4SDO lines, etc.,

    Signed-off-by: Sameer Pujar
    Reviewed-by: Mohan Kumar D
    Reviewed-by: Ravindra Lokhande
    Reviewed-by: Pierre-Louis Bossart
    Signed-off-by: Takashi Iwai

    Sameer Pujar
     

09 Jan, 2019

1 commit


27 Jul, 2018

1 commit

  • The BDL pointer used in snd_hdac_dsp_prepare() should be declared as
    __le32, as warned by sparse:
    sound/hda/hdac_stream.c:655:47: warning: incorrect type in argument 4 (different base types)
    sound/hda/hdac_stream.c:655:47: expected restricted __le32 [usertype] **bdlp
    sound/hda/hdac_stream.c:655:47: got unsigned int [usertype] **

    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

03 Apr, 2017

1 commit

  • The macros _snd_hdac_chip_read() and *_write() expand to different
    types (b,w,l) per their argument. They were thought to be used only
    internally for other snd_hdac_chip_*() macros, but in some situations
    we need to call these directly, and they are way too ugly.

    Instead of saving a few lines, we just write these macros explicitly
    with the types, so that they can be used in a saner way.

    Acked-by: Vinod Koul
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

25 Dec, 2016

1 commit


28 Oct, 2015

1 commit


23 Aug, 2015

1 commit

  • Add a helper to find the stream using stream tag and direction.
    This is useful for drivers to query stream based on stream tag
    and direction, fox example while downloading FW thru DSP loader
    code

    Signed-off-by: Jeeja KP
    Signed-off-by: Vinod Koul
    Signed-off-by: Takashi Iwai

    Jeeja KP
     

19 May, 2015

1 commit

  • The CA0132 DSP loader leads to NULL deference since the recent
    transition to HDA core code, as it unconditionally accesses
    hdac_stream->substream->runtime. For DSP loading, the substream
    shouldn't be assigned.

    This patch addresses the NULL dereference above in addition to assure
    the substream is cleared while DSP loading.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=98151
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

18 May, 2015

1 commit


17 Apr, 2015

1 commit


16 Apr, 2015

4 commits