This reverts commit 7189eb9b8f.
It will use LPIB to get the DMA position on Broadwell HDMI Audio.
Signed-off-by: Libin Yang <libin.yang@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Broadwell HDMI can't use position buffer reliably, force to use LPIB
Signed-off-by: Libin Yang <libin.yang@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent Intel H97/Z97 chipsets need the similar setups like other
Intel chipsets for snooping, etc. Especially without snooping, the
audio playback stutters or gets corrupted. This fix patch just adds
the corresponding PCI ID entry with the proper flags.
Reported-and-tested-by: Arthur Borsboom <arthurborsboom@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We should prefer `const struct pci_device_id` over
`DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines.
This issue was reported by checkpatch.
A simplified version of the semantic patch that makes this change is as
follows (http://coccinelle.lip6.fr/):
// <smpl>
@@
identifier i;
declarer name DEFINE_PCI_DEVICE_TABLE;
initializer z;
@@
- DEFINE_PCI_DEVICE_TABLE(i)
+ const struct pci_device_id i[]
= z;
// </smpl>
It has been tested by compilation.
Signed-off-by: Benoit Taine <benoit.taine@lip6.fr>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Broadwell display controller has 3 stream DMA engines. DMA0 cannot update DMA
postion buffer properly while DMA1 and DMA2 can work well. So this patch masks
the buggy DMA0 by keeping it as opened.
This is a tentative workaround, so keep the change small as Takashi suggested.
Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent commit (ca460f8652) changed the CORB RP reset procedure to
follow the specification with a couple of sanity checks.
Unfortunately, Nvidia controller chips seem not following this way,
and spew the warning messages like:
snd_hda_intel 0000:00:10.1: CORB reset timeout#1, CORBRP = 0
This patch adds the workaround for such chips. It just skips the new
reset procedure for the known broken chips.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The full_reset argument to azx_init_chip() carries boolean rather than
numerical information, so update the type to reflect that.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The ops to read and write registers should take pointers labeled as
__iomem. Thanks to the sparse bot for catching this.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Using readl, writel, etc. resulted in some architectures, such as
s390, expanding the member names into zpci_writel. Obviously not the
intended result.
Fixes s390 build breakage introduced by "4083081 - ALSA: hda - Allow
different ops to read/write registers"
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Codec creation and stream initialization can be shared between
hda_intel and hda platform drivers. Move it and the static functions
it depends on to hda_controller.c.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This code will be reused by an hda_platform driver as it has no PCI
dependencies. This allows update_rirb to be static as all users are
now in hda_controller.c.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This op will be used by hda_intel to do the position check. Takashi
wisely suggested adding this before moving the interrupt handler to
common HDA code. Having this callback prevents the need to move the
hda_intel specific delayed interrupt handling with the irq.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Share more code from hda_intel. This moves the link control and
initialization to hda_controller. The code will also be used by an
hda platform driver.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Combining the call to alloc_cmd_io with the allocate pages function
removes an extra interface between hda_intel and hda_controller.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is done to allow an HDA platform driver to reuse the code.
A few of the interfaces added to hda_controller will disappear in
following commits as their users are also moved to hda_controller.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Moving the DSP loading functionality to hda_controller.c means that
the dsp lock doesn't need to be shared in hda_intel and
hda_controller. The forthcoming platform driver doesn't need the DSP
loading code, but sharing it doesn't hurt.
Tested on Chromebook Pixel's ca0132 that uses the DSP loader.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Pull allocation from first_init to a new function in hda_controller.c.
Short term this will allow the dsp loader to be moved as well. In
later commits it will allow the same allocation to be used by the
platform hda driver.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Pull the pcm_ops and the functions they use into a new hda_controller
file. This is done to allow for other hda implementations besides PCI
to use the same ops. The hda_controller file will house functionality
related to HDA but independent of the bus used to talk to the
controller.
This currently shares dsp locking across the two files. This will be
remedied in a following commit.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Adding this op allows the X86 specific mmap operation to help in
hda_intel without needing a CONFIG_X86 in future non-PCI hda drivers.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Break out the allocation of pages for DMA and PCM buffers to ops in
the chip structure. This is done to allow for architecture specific
work-arounds to be added. Currently mark_pages_wc is used by
hda_intel. This avoids needing to move that x86-specific code to a
common area shared with hda platform drivers.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Passing the max slots and power save arguments to codec_create will
allow for its reuse by an hda_platform driver. It makes the function
independent of the module params in hda_intel and ready to move to
hda_shared in a following commit.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Keeping a pointer to the jackpoll_ms array in the chip will allow
azx_codec_create to be shared between hda_intel and hda_platform
drivers. Also modify get_jackpoll_ms to make the jackpoll_ms member
optional, this way a platform driver can leave it out if it's not
needed.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Although the code was updated last year the "#if 0" surrounding it
dates back to the original git commit. The function will be moved to
a new file, no need to carry the dead code.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a PCI-only feature, but adding a callback for it in the chip
structure breaks the PCI dependency in the RIRB code allowing the
logic there to be re-used by the platform HDA driver.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This removes calls to get the device via PCI from other parts of the
code that will be able to be re-used by the platform driver.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This will allow for a platform hda driver to use it as well. It
removes the dependency on the module param from hda_intel, which will
allow for azx_setup_periods to be shared.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The forthcoming platform hda driver needs to override the way
registers are read and written. In preparation for that, introduce a
reg_ops struct that can be implemented differently by the new driver.
Change the existing macros to use the new structure, and move them to
hda_priv.h where they will be accessible to both PCI and platform
drivers.
Start with register access, but later commits will add more ops that
differ between PCI and platform.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Later commits adding support for hda platform drivers will want to use
the same defines and structures. Put them in a place reachable by both
hda_intel and the new platform driver.
This is a mostly a direct copy with a few whitespace and comment
changes to make checkpatch happy.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
According to the HDA spec, we must write 1 to bit 15 on a CORBRP
reset, read back 1, then write 0, then read back 0. This must be
done while the DMA is not running.
We accidentaly ended up writing back the 0 by using a writel
instead of a writew to CORBWP.
This caused occasional controller failure on Bay Trail hardware.
[replaced error messages with dev_err() by tiwai]
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Use dev_err() and co for messages from HD-audio controller and codec
drivers. The codec drivers are mostly bound with codec objects, so
some helper macros, codec_err(), codec_info(), etc, are provided.
They merely wrap the corresponding dev_xxx().
There are a few places still calling snd_printk() and its variants
as they are called without the codec or device context.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As the HD-audio is treated individually in each codec driver, it's
more convenient to assign an own struct device to each codec object.
Then we'll be able to use dev_err() more easily for each codec, for
example.
For achieving it, this patch just creates an object "hdaudioCxDy".
It belongs to sound class instead of creating a new bus, just for
simplicity, at this stage. No pm ops is implemented in the device
struct level but currently it's merely a container. The PCM and hwdep
devices are now children of this codec device.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Replace the lengthy #if defined(XXX) || defined(XXX_MODULE) with the
new IS_ENABLED() macro.
The patch still doesn't cover all ifdefs. For example, the dependency
on CONFIG_GAMEPORT is still open-coded because this also has an extra
dependency on MODULE. Similarly, an open-coded ifdef in pcm_oss.c and
some sequencer-related stuff are left untouched.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Since the commit [595fe1b702: ALSA: hda - Make
CONFIG_SND_HDA_CODEC_* tristate], the kconfig variables for the
generic parser and codec drivers can be "m" instead of boolean, but
some codes are left unchanged to check only #ifdef
CONFIG_SND_HDA_CODEC_XXX, which is no longer true for modules.
This patch fixes them by replacing with IS_ENABLED() macros.
Fixes: 595fe1b702 ('ALSA: hda - Make CONFIG_SND_HDA_CODEC_* tristate')
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70161
Signed-off-by: Takashi Iwai <tiwai@suse.de>
While looking into some spurious responses, I found that the addr value was
treated a bit inconsistent: values 8..0xf will be treated as codec 0 and
values 0..7 will be treated as no error regardless of whether there is a codec
there, or not.
With this patch, all non-existing codecs will be treated equally.
In addition, printing rp and wp could help figuring out if the wp value is
reported wrongly from the controller or if something else is wrong.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds the device ID for Intel Broadwell display HD-Audio controller,
and applies Haswell properties to this device.
Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It turned out that some AMD HDMI controllers still don't provide
proper values in GCAP register (all zero), and the driver assigns only
one stream in that case, although the connected codec chip supports
more than one stream.
In this patch, the default max number of streams for AMD HDMI
controllers is increased to 8, which should suffice for most use
cases. The overhead by this increase is more azx_dev struct and BDL
allocations, so it's negligible. Of course, if the controller
provides a proper GCAP register, the register value would be used.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
While enabling these machines, we found we would sometimes lose an
interrupt if we change hardware volume during playback, and that
disabling msi fixed this issue. (Losing the interrupt caused underruns
and crackling audio, as the one second timeout is usually bigger than
the period size.)
The machines were all machines from HP, running AMD Hudson controller,
and Realtek ALC282 codec.
Cc: stable@vger.kernel.org
BugLink: https://bugs.launchpad.net/bugs/1260225
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Sometimes the hardware reports LPIB being advanced than POSBUF.
When this happens, the driver adjusts to a positive value by adding
the buffer size. Then the driver detects it as an error (greater than
the period size), and stops the LPIB delay account from this point
on.
When I took a close look at these conditions, the values shown are all
very small numbers, and it'd be better to just ignore these values
instead of discontinuing the LPIB delay correction.
In this patch, the driver checks a negative delay value and ignores if
it's a significantly small error. Currently the threshold is set to
64 frames, but could be smaller.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
HD-audio devices tend to take long time for finishing the whole
probing procedure. In this patch, the time-consuming part of the
probing procedure, the codec probe and the rest initializations, are
moved in the work, so that they can be done asynchronously in parallel
with probes of other devices.
Since we already have this mechanism in the driver code for the
firmware and i915 request_symbol() stuff, we just need to enable it
always; the resultant patch even reduces more lines, which is an
additional bonus.
Credit goes to David Henningsson, who suggested this workaround.
Reported-by: Mengdong Lin <mengdong.lin@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When the probe of snd-hda-intel driver is deferred due to f/w loading
or the nested module loading, complete_all() should be also delayed
until the initialization really finished. Otherwise, vga-switcheroo
client would start switching before the actual init is done.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Now we fixed the long-standing bugs of runtime PM, let's enable
Panther Point again. The runtime PM was disabled in the HDMI codec
driver due to the S3 issue, and this should have been fixed now.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Use bus->power_keep_link_on instead. The controller shouldn't go to
D3 when the link isn't reset, so essentially avoiding the link reset
means avoiding the runtime PM.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
dmesg here has a 100+ consecutive lines of:
[ 1464.219446] hda-intel 0000:00:14.2: spurious response 0x0:0x0, last cmd=0x170500
[ 1464.219451] hda-intel 0000:00:14.2: spurious response 0x0:0x0, last cmd=0x170500
[ 1464.219454] hda-intel 0000:00:14.2: spurious response 0x0:0x0, last cmd=0x170500
...
Ratelimit the message to reduce the dmesg log noise.
Coalesce the format while at it.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
"HDA Intel MID" is no correct name for Haswell HDMI controllers.
Give them a better name, "HDA Intel HDMI".
Signed-off-by: Takashi Iwai <tiwai@suse.de>
