In current implementation, sequence of syt offset and the number of data
blocks is generated when packets for outgoing stream are going to be
queued.

This commit generates and pools the sequence independently of the
processing of outgoing packets for future extension.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-10-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>

For future extension, storage is required to store packet sequence in
incoming AMDTP stream to recover media clock for outgoing AMDTP stream.

This commit adds the storage to AMDTP domain for this purpose. The
packet sequence is represented by 'struct seq_desc' which has two
members; syt_offset and the number of data blocks. The size of storage
is decided according to the size of packet queue.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-9-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>

When calculating the number of data blocks per packet, some states are
stored in AMDTP stream structure. This is inconvenient when reuse the
calculation from non-stream structure.

This commit applies refactoring to helper function for the calculation
so that the function doesn't touch AMDTP stream structure.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-8-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>

When calculating syt offset, some states are stored in AMDTP stream
structure. This is inconvenient when reuse the calculation from
non-stream structure.

This commit applies refactoring to helper function for the calculation
so that the function doesn't touch AMDTP stream structure.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-7-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>

In current implementation for outgoing AMDTP packet, the value of syt
field in CIP header is computed when calculating syt offset. For
future extension, it's convenient to split the computation and
calculation.

This commit splits them.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-6-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>

Although the parameter for packet queue and IRQ timing is calculated when
AMDTP stream starts, the calculated parameters are the same between
streams in AMDTP domain.

This commit moves the calculation and decide the parameters when AMDTP
domain starts.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-5-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>

In current implementation, AMDTP domain structure and AMDTP stream
structure has one way of reference from the former to the latter. For
future extension, bidirectional reference is needed.

This commit adds a member into stream structure to refer to domain
structure to which the stream belongs.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-4-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>

In descriptor of isochronous context in 1394 OHCI, the field of second
has 3 bit, thus the maximum value is 8. The value is used for correct
cycle calculation.

This commit replaces hard-coded value with macro to obsolete magic
number.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-3-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>

Although the value of FDF is used just for outgoing stream, the assignment
to union member is done for both directions of stream. At present this
causes no issue because the value of same position is reassigned later for
opposite stream. However, it's better to add if statement.

Fixes: d3d10a4a ("ALSA: firewire-lib: use union for directional parameters")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200508043635.349339-2-o-takashi@sakamocchi.jpSigned-off-by: Takashi Iwai <tiwai@suse.de>

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200507185245.GA14270@embeddedorSigned-off-by: Takashi Iwai <tiwai@suse.de>

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20200507192223.GA16335@embeddedorSigned-off-by: Takashi Iwai <tiwai@suse.de>

Update intel-dspcfg with FLAG_SST_ONLY_IF_DMIC option and use it for
Skylake and Kabylake platforms when DMIC is present.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200506203951.6369-1-cezary.rojewski@intel.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

Fix the following coccinelle warning:

sound/drivers/portman2x4.c:460:34-35: WARNING: sum of probable bitmasks, consider |
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Samuel Zou <zou_wei@huawei.com>
Link: https://lore.kernel.org/r/1588834135-14842-1-git-send-email-zou_wei@huawei.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

Fix the following coccinelle warnings:

sound/ppc/pmac.c:729:57-58: WARNING: sum of probable bitmasks, consider |
sound/ppc/pmac.c:229:37-38: WARNING: sum of probable bitmasks, consider |
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Samuel Zou <zou_wei@huawei.com>
Link: https://lore.kernel.org/r/1588823647-12480-1-git-send-email-zou_wei@huawei.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

Fix the following coccicheck warning:

include/sound/hdaudio.h:210:73-74: WARNING: return of 0/1 in function
'snd_hdac_is_in_pm' with return type bool
include/sound/hdaudio.h:211:76-77: WARNING: return of 0/1 in function
'snd_hdac_is_power_on' with return type bool
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Link: https://lore.kernel.org/r/20200506061716.19209-1-yanaijie@huawei.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

Use hdac_to_hda_codec() instead of container_of().

No functional change intended.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200505030357.28004-2-kai.heng.feng@canonical.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

Use dev_to_hdac_dev() instead of container_of().

No functional change intended.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200505030357.28004-1-kai.heng.feng@canonical.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

Tegra194 has 4 SDO lines and with this configuration playback fails
for 44.1K/48K, 2-channel and 16-bps. It results in below print,
  "aplay: pcm_write:2011: write error: Input/output error"

Below relation is used to derive stripe control and is referenced
from HD Audio Specification: Revision 1.0a.
  { ((num_channels * bits_per_sample) / number of SDOs) >= 8 }

Due to a legacy HW design problem, playback issue is hit while using
a stripe value resulting from above formula when ratio is '8'. Thus
it is recommended that the ratio must be greater than '8'. Since the
number of SDO lines is in powers of 2, next available ratio '16' is
used as a limiting factor on Tegra194 to workaround the problem.
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/1588580176-2801-4-git-send-email-spujar@nvidia.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

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 <spujar@nvidia.com>
Link: https://lore.kernel.org/r/1588580176-2801-3-git-send-email-spujar@nvidia.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

Tegra194 supports 4 SDO lines but GCAP register indicates 2 lines. Thus it
does not reflect the true capability of the HW. This patch presents a
workaround by updating NSDO value accordingly in T_AZA_DBG_CFG_2 register.
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/1588580176-2801-2-git-send-email-spujar@nvidia.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

At least POD HD500 uses message-based communication, both sides can
send messages. Add poll callback so application can wait for device
messages without using busy loop.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Link: https://lore.kernel.org/r/20200502193120.79115-3-anarsoul@gmail.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

Currently line6 hwdep interface ignores O_NONBLOCK flag when
opening device and it renders it somewhat useless when using poll.

Check for O_NONBLOCK flag when opening device and don't block read()
if it is set.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Link: https://lore.kernel.org/r/20200502193120.79115-2-anarsoul@gmail.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

The "header->number" comes from the ioctl and it needs to be clamped to
prevent out of bounds writes.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20200501094011.GA960082@mwandaSigned-off-by: Takashi Iwai <tiwai@suse.de>

Cover with a proper ifdef around the variable declaration for fixing
the following compilation warning without CONFIG_LEDS_TRIGGER_AUDIO:
  sound/pci/hda/patch_realtek.c: In function 'alc_fixup_hp_gpio_led':
  sound/pci/hda/patch_realtek.c:4134:6: warning: unused variable 'err' [-Wunused-variable]
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Fixes: 87dc3648 ("ALSA: hda/realtek - Add LED class support for micmute LED")
Link: https://lore.kernel.org/r/20200501072857.13720-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

Currently DMIC controls micmute LED via "audio mute LED trigger".

However, unlike Dell and Lenovo platforms, HP platforms don't provide a
way to control micmute LED via ACPI, it's controlled by HDA codec
instead.

So let's register an LED class for micmute so other subsystems like DMIC
can facilitate the codec-controlled LED.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200430135209.14703-1-kai.heng.feng@canonical.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

Though the system uses DMIC, headset mic still uses the HDA, let's use
GPIO 0x1 to control the micmute LED.

The micmute LED GPIO has a different polarity to the mute LED GPIO, we
can use the newly added micmute_led_polarity to indicate that.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200430083255.5093-2-kai.heng.feng@canonical.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

Currently mute LED and micmute LED share the same GPIO polarity.

So split the polarity for mute and micmute, in case they have different
polarities.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20200430083255.5093-1-kai.heng.feng@canonical.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

There's no callers in-tree.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20200429132805.18712-1-yuehaibing@huawei.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

The linked list entry from FIFO is peeked at
queue_pending_output_urbs() but the actual element pop-out is
performed outside the spinlock, and it's potentially racy.

Do delete the link at the right place inside the spinlock.

Fixes: 8fdff6a3 ("ALSA: snd-usb: implement new endpoint streaming model")
Link: https://lore.kernel.org/r/20200424074016.14301-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

Frame size computation has been fixed and the workaround is no longer
needed.
Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
Link: https://lore.kernel.org/r/20200424022449.14972-2-alexander@tsoy.meSigned-off-by: Takashi Iwai <tiwai@suse.de>

For computation of the the next frame size current value of fs/fps and
accumulated fractional parts of fs/fps are used, where values are stored
in Q16.16 format. This is quite natural for computing frame size for
asynchronous endpoints driven by explicit feedback, since in this case
fs/fps is a value provided by the feedback endpoint and it's already in
the Q format. If an error is accumulated over time, the device can
adjust fs/fps value to prevent buffer overruns/underruns.

But for synchronous endpoints the accuracy provided by these computations
is not enough. Due to accumulated error the driver periodically produces
frames with incorrect size (+/- 1 audio sample).

This patch fixes this issue by implementing a different algorithm for
frame size computation. It is based on accumulating of the remainders
from division fs/fps and it doesn't accumulate errors over time. This
new method is enabled for synchronous and adaptive playback endpoints.
Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
Link: https://lore.kernel.org/r/20200424022449.14972-1-alexander@tsoy.meSigned-off-by: Takashi Iwai <tiwai@suse.de>

Back-merge 5.7-rc devel branch for further changes.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

The commit 3c6fd1f0 ("ALSA: hda: Add driver blacklist") added a
new blacklist for the devices that are known to have empty codecs, and
one of the entries was ASUS ROG Zenith II (PCI SSID 1043:874f).
However, it turned out that the very same PCI SSID is used for the
previous model that does have the valid HD-audio codecs and the change
broke the sound on it.

Since the empty codec problem appear on the certain AMD platform (PCI
ID 1022:1487), this patch changes the blacklist matching to both PCI
ID and SSID using pci_match_id().  Also, the entry that was removed by
the previous fix for ASUS ROG Zenigh II is re-added.

Link: https://lore.kernel.org/r/20200424061222.19792-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

Merge NHLT init cleanup.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

NHLT fetch based on _DSM prevents ACPI table override mechanism from
being utilized. Make use of acpi_get_table to enable it and get rid of
redundant code. In consequence, NHLT can be overridden just like any
other ACPI table, e.g.: DSDT or SSDT.

Change has been verified on all Intel AVS architecture platforms, RVP
and production laptops both.

Change possible due to addition of NHLT signature to the list of
standard ACPI tables:
https://patchwork.kernel.org/patch/11463235/

Override helps not only with debug purposes but also allows user for
table adjustment when one found on their production hardware is invalid.
Shared official NHLT spec is now available to community at:
https://01.org/blogs/intel-smart-sound-technology-audio-dsp

NHLT support for iASL is still ongoing subject but should be available
in nearest future.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20200423160310.28019-1-cezary.rojewski@intel.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

HD-audio codec driver applies a tricky procedure to forcibly perform
the runtime resume by mimicking the usage count even if the device has
been runtime-suspended beforehand.  This was needed to assure to
trigger the jack detection update after the system resume.

And recently we also applied the similar logic to the HD-audio
controller side.  However this seems leading to some inconsistency,
and eventually PCI controller gets screwed up.

This patch is an attempt to fix and clean up those behavior: instead
of the tricky runtime resume procedure, the existing jackpoll work is
scheduled when such a forced codec resume is required.  The jackpoll
work will power up the codec, and this alone should suffice for the
jack status update in usual cases.  If the extra polling is requested
(by checking codec->jackpoll_interval), the manual update is invoked
after that, and the codec is powered down again.

Also, we filter the spurious wake up of the codec from the controller
runtime resume by checking codec->relaxed_resume flag.  If this flag
is set, basically we don't need to wake up explicitly, but it's
supposed to be done via the audio component notifier.

Fixes: c4c8dd6e ("ALSA: hda: Skip controller resume if not needed")
Link: https://lore.kernel.org/r/20200422203744.26299-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

Enable new codec supported for ALC245.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/8c0804738b2c42439f59c39c8437817f@realtek.comSigned-off-by: Takashi Iwai <tiwai@suse.de>

snd_microii_spdif_default_get() invokes snd_usb_lock_shutdown(), which
increases the refcount of the snd_usb_audio object "chip".

When snd_microii_spdif_default_get() returns, local variable "chip"
becomes invalid, so the refcount should be decreased to keep refcount
balanced.

The reference counting issue happens in several exception handling paths
of snd_microii_spdif_default_get(). When those error scenarios occur
such as usb_ifnum_to_if() returns NULL, the function forgets to decrease
the refcnt increased by snd_usb_lock_shutdown(), causing a refcnt leak.

Fix this issue by jumping to "end" label when those error scenarios
occur.

Fixes: 447d6275 ("ALSA: usb-audio: Add sanity checks for endpoint accesses")
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1587617711-13200-1-git-send-email-xiyuyang19@fudan.edu.cnSigned-off-by: Takashi Iwai <tiwai@suse.de>

It turned out that ALC1220-VB USB-audio device gives the interrupt
event to some PCM terminals while those don't allow the connector
state request but only the actual I/O terminals return the request.
The recent commit 7dc3c5a0 ("ALSA: usb-audio: Don't create jack
controls for PCM terminals") excluded those phantom terminals, so
those events are ignored, too.

My first thought was that this could be easily deduced from the
associated terminals, but some of them have even no associate terminal
ID, hence it's not too trivial to figure out.

Since the number of such terminals are small and limited, this patch
implements another quirk table for the simple mapping of the
connectors.  It's not really scalable, but let's hope that there will
be not many such funky devices in future.

Fixes: 7dc3c5a0 ("ALSA: usb-audio: Don't create jack controls for PCM terminals")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206873
Link: https://lore.kernel.org/r/20200422113320.26664-1-tiwai@suse.deSigned-off-by: Takashi Iwai <tiwai@suse.de>

Fix the following coccicheck warning:

sound/pci/oxygen/xonar_pcm179x.c:463:1-17: WARNING: Assignment of 0/1 to
bool variable
sound/pci/oxygen/xonar_pcm179x.c:505:1-17: WARNING: Assignment of 0/1 to
bool variable
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Link: https://lore.kernel.org/r/20200422071646.48436-1-yanaijie@huawei.comSigned-off-by: Takashi Iwai <tiwai@suse.de>