Now that we disable audio while setting up the audio
hw, we should be able to set this up without hangs.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Disable audio around audio hw setup. This may avoid
hangs on certain asics.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Mark function r600_audio_set_dto() as static in drm/radeon/r600_hdmi.c
because it is not used outside this file.
This eliminates the following warning in drm/radeon/r600_hdmi.c:
drivers/gpu/drm/radeon/r600_hdmi.c:253:6: warning: no previous prototype for ‘r600_audio_set_dto’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
In order to have any realistic chance of calculating proper
ACR values, we need to be able to calculate both N and CTS,
not just CTS. We still aim for the ideal N as specified in
the HDMI spec though.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=69675
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The values were taken from the HDMI spec, but they assumed
exact x/1.001 clocks. Since we round the clocks, we also need
to calculate different N and CTS values.
Note that the N for 25.2/1.001 MHz at 44.1 kHz audio is out of
spec. Hopefully this mode is rarely used and/or HDMI sinks
tolerate overly large values of N.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=69675
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The current code writing SADs to the audio registers seems to assume
that there is at most a single SAD per audio format.
However, that is not the case. Especially for PCM it is somewhat common
for sinks to have two SADs, one for 8-channel and one for 2-channel
audio, which may have different supported sample rates (i.e. the sink
supports stereo audio at higher sample rates than multichannel audio).
Because of this, only the 2-channel SAD may be used if it appears before
the 8-channel SAD. Unless other SADs require otherwise, this may cause
the ALSA HDA driver to allow stereo playback only.
Fix the code to pick the PCM SAD with the highest number of channels,
while merging the rate masks of PCM SADs with lower amount of channels
into the additional stereo rate mask byte.
Technically there are even more cases to handle (multiple non-PCM SADs
of the same type, more than two PCM SADs with varying channel counts,
etc), but those have not actually been encountered in the field and
handling them would be non-trivial.
Example affected EDID from Onkyo TX-SR674 specifying 192kHz stereo
support and 96kHz 8-channel support (and other 8-channel compressed
formats):
00ffffffffffff003dcb010000000001
ffff0103800000780a0dc9a057479827
12484c00000001010101010101010101
010101010101011d8018711c1620582c
2500c48e2100009e011d007251d01e20
6e285500c48e2100001e000000fc0054
582d53523637342020202020000000fd
00313d0f2e08000a202020202020019b
02032f724f8504030f0e07069413121e
1d1615012f097f070f1f071707503707
503f07c0834f000066030c00ffff808c
0ad08a20e02d10103e9600c48e210000
18011d80d0721c1620102c2580c48e21
00009e011d00bc52d01e20b8285540c4
8e2100001e8c0ad090204031200c4055
00c48e210000180000000000000000a8
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Tested-by: Andre Heider <a.heider@gmail.com>
Cc: Rafał Miłecki <zajec5@gmail.com>
Acked-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Bit a bit -fixes pull request in the merge window than usual dua to two
feauture-y things:
- Display CRCs are now enabled on all platforms, including the odd DP case
on gm45/vlv. Since this is a testing-only feature it should ever hurt,
but I figured it'll help with regression-testing -fixes. So I left it
in and didn't postpone it to 3.14.
- Display power well refactoring from Imre. Would have caused major pain
conflict with the bdw stage 1 patches if I'd postpone this to -next.
It's only an relatively small interface rework, so shouldn't cause pain.
It's also been in my tree since almost 3 weeks already.
That accounts for about two thirds of the pull, otherwise just bugfixes:
- vlv backlight fix from Jesse/Jani
- vlv vblank timestamp fix from Jesse
- improved edp detection through vbt from Ville (fixes a vlv issue)
- eDP vdd fix from Paulo
- fixes for dvo lvds on i830M
- a few smaller things all over
Note: This contains a backmerge of v3.12. Since the -internal branch
always applied on top of -nightly I need that unified base to merge bdw
patches. So you'll get a conflict with radeon connector props when pulling
this (and nouveau/master will also conflict a bit when Ben doesn't
rebase). The backmerge itself only had conflicts in drm/i915.
There's also a tiny conflict between Jani's backlight fix and your sysfs
lifetime fix in drm-next.
* tag 'drm-intel-fixes-2013-11-07' of git://people.freedesktop.org/~danvet/drm-intel: (940 commits)
drm/i915/vlv: use per-pipe backlight controls v2
drm/i915: make backlight functions take a connector
drm/i915: move opregion asle request handling to a work queue
drm/i915/vlv: use PIPE_START_VBLANK interrupts on VLV
drm/i915: Make intel_dp_is_edp() less specific
drm/i915: Give names to the VBT child device type bits
drm/i915/vlv: enable HDA display audio for Valleyview2
drm/i915/dvo: call ->mode_set callback only when the port is running
drm/i915: avoid unclaimed registers when capturing the error state
drm/i915: Enable DP port CRC for the "auto" source on g4x/vlv
drm/i915: scramble reset support for DP port CRC on vlv
drm/i915: scramble reset support for DP port CRC on g4x
drm/i916: add "auto" pipe CRC source
...
Conflicts:
MAINTAINERS
drivers/gpu/drm/i915/intel_panel.c
drivers/gpu/drm/nouveau/core/subdev/mc/base.c
drivers/gpu/drm/radeon/atombios_encoders.c
drivers/gpu/drm/radeon/radeon_connectors.c
HW ACR support may have issues on some older chips, so
use SW ACR for now until we've tested further.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
CC: Rafał Miłecki <zajec5@gmail.com>
Use the hw generated values rather than calculating
them in the driver. There may be some older r6xx
asics where this doesn't work correctly. This remains
to be seen.
See bug:
https://bugs.freedesktop.org/show_bug.cgi?id=69675
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The drm code that calculates the 1001 clocks rounds up
rather than truncating. This allows the table to match
properly on those modes.
See bug:
https://bugs.freedesktop.org/show_bug.cgi?id=69675
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This updates the audio driver to the speaker allocation
block from the EDID. A similar change was just implemented
for DCE4-8.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Similar to DCE4/5, but supports multiple audio pins
which can be assigned per afmt block.
v2: rework the driver to handle more than one audio
pin.
v3: try different dto reg
v4: properly program dto
v5 (ck): change dto programming order
v6: program speaker allocation block
v7: rebase
v8: rebase on Rafał's changes
v9: integrated Rafał's comments, update to latest
drm_edid_to_speaker_allocation API
v10: add missing line break in error message
v11: add back audio enabled messages
v12: fix copy paste typo in r600_audio_enable
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Rafał Miłecki <zajec5@gmail.com>
Need to set the wallclock ratio and adjust the phase
and module registers appropriately. May fix problems
with audio timing at certain display timings.
v2: properly handle clocks below 24mhz
v3: rebase r600 changes
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
There are two audio dtos on radeon asics that you can
select between. Normally, dto0 is used for hdmi and
dto1 for DP, but it seems that the dto is somehow
tied to the encoders on DCE3 asics.
fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=67435
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
- remove adding 2 to checksum, this is incorrect.
This was incorrectly introduced in:
92db7f6c86http://lists.freedesktop.org/archives/dri-devel/2011-December/017717.html
However, the off by 2 was due to adding the version twice.
From the examples in the URL above:
[Rafał Miłecki][RV620] fglrx:
0x7454: 00 A8 5E 79 R600_HDMI_VIDEOINFOFRAME_0
0x7458: 00 28 00 10 R600_HDMI_VIDEOINFOFRAME_1
0x745C: 00 48 00 28 R600_HDMI_VIDEOINFOFRAME_2
0x7460: 02 00 00 48 R600_HDMI_VIDEOINFOFRAME_3
===================
(0x82 + 0x2 + 0xD) + 0x1F8 = 0x289
-0x289 = 0x77
However, the payload sum is not 0x1f8, it's 0x1f6.
00 + A8 + 5E + 00 +
00 + 28 + 00 + 10 +
00 + 48 + 00 + 28 +
00 + 48 =
0x1f6
Bits 25:24 of HDMI_VIDEOINFOFRAME_3 are the packet version, not part
of the payload. So the total would be:
(0x82 + 0x2 + 0xD) + 0x1f6 = 0x287
-0x287 = 0x79
- properly emit the AVI infoframe version. This was not being
emitted previous which is probably what caused the issue above.
This should fix blank screen when HDMI audio is enabled on
certain monitors.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Cc: Rafał Miłecki <zajec5@gmail.com>
Avoids overflows on DCE2.x devices. Also clarify the calculation
on other asics.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Register audio callbacks for asic where we support
audio. Cleans up the code and makes it easier to
add support for newer asics.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Split into DCE2/3 and DCE4/5 variants. Still todo is to
calculate the DTO dividers properly. Add proper formula
to the comments.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Use the generic HDMI infoframe helpers to get rid of the duplicate
implementation in the radeon driver.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Pull drm merge (part 1) from Dave Airlie:
"So first of all my tree and uapi stuff has a conflict mess, its my
fault as the nouveau stuff didn't hit -next as were trying to rebase
regressions out of it before we merged.
Highlights:
- SH mobile modesetting driver and associated helpers
- some DRM core documentation
- i915 modesetting rework, haswell hdmi, haswell and vlv fixes, write
combined pte writing, ilk rc6 support,
- nouveau: major driver rework into a hw core driver, makes features
like SLI a lot saner to implement,
- psb: add eDP/DP support for Cedarview
- radeon: 2 layer page tables, async VM pte updates, better PLL
selection for > 2 screens, better ACPI interactions
The rest is general grab bag of fixes.
So why part 1? well I have the exynos pull req which came in a bit
late but was waiting for me to do something they shouldn't have and it
looks fairly safe, and David Howells has some more header cleanups
he'd like me to pull, that seem like a good idea, but I'd like to get
this merge out of the way so -next dosen't get blocked."
Tons of conflicts mostly due to silly include line changes, but mostly
mindless. A few other small semantic conflicts too, noted from Dave's
pre-merged branch.
* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (447 commits)
drm/nv98/crypt: fix fuc build with latest envyas
drm/nouveau/devinit: fixup various issues with subdev ctor/init ordering
drm/nv41/vm: fix and enable use of "real" pciegart
drm/nv44/vm: fix and enable use of "real" pciegart
drm/nv04/dmaobj: fixup vm target handling in preparation for nv4x pcie
drm/nouveau: store supported dma mask in vmmgr
drm/nvc0/ibus: initial implementation of subdev
drm/nouveau/therm: add support for fan-control modes
drm/nouveau/hwmon: rename pwm0* to pmw1* to follow hwmon's rules
drm/nouveau/therm: calculate the pwm divisor on nv50+
drm/nouveau/fan: rewrite the fan tachometer driver to get more precision, faster
drm/nouveau/therm: move thermal-related functions to the therm subdev
drm/nouveau/bios: parse the pwm divisor from the perf table
drm/nouveau/therm: use the EXTDEV table to detect i2c monitoring devices
drm/nouveau/therm: rework thermal table parsing
drm/nouveau/gpio: expose the PWM/TOGGLE parameter found in the gpio vbios table
drm/nouveau: fix pm initialization order
drm/nouveau/bios: check that fixed tvdac gpio data is valid before using it
drm/nouveau: log channel debug/error messages from client object rather than drm client
drm/nouveau: have drm debugging macros build on top of core macros
...
Convert #include "..." to #include <path/...> in drivers/gpu/.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Dave Jones <davej@redhat.com>
Let's allow GCC to optimize better.
This exposed some five unused functions, but this patch doesn't remove them.
Signed-off-by: Lauri Kasanen <cand@gmx.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
1. It is really dangerous to have more than one
spinlock protecting the same information.
2. radeon_irq_set sometimes wasn't called with lock
protection, so it can happen that more than one
CPU would tamper with the irq regs at the same
time.
3. The pm.gui_idle variable was assuming that the 3D
engine wasn't becoming idle between testing the
register and setting the variable. So just remove
it and test the register directly.
v2: Also handle the hpd irq code the same way.
v3: Rename hpd parameter for clarification.
Signed-off-by: Christian Koenig <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
After recent changes HDMI code is ready to be enabled on DCE5. This
patch just changes conditions to execute already present code on DCE5.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Tested-by: Christian König <christian.koenig@amd.com>
Tested-by: Andre Heider <a.heider@gmail.com>
Tested-by: Zoltán Böszörményi <zboszor@pr.hu>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Many TVs and A/V receivers don't work with this bit set. Problem was
confirmed using: Onkyo TX-SR605, Sony BRAVIA KDL-52X3500, Sony BRAVIA
KDL-40S40xx. In theory this bit shouldn't affect audio engine when
feeding it with data, however it seems it does. Driver fglrx doesn't set
that bit in any of the above cases.
This fixes a regression introduced by 3.5-rc1.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Tested-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Christian König <deathsimple@vodafone.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If we want hdmi_offset to be relative to the first block, zero value can
be used also for enabled block.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Tested-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Christian König <deathsimple@vodafone.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
R6xx has routable blocks, but there's nothing wrong in assignment based
on dig_encoder. We didn't really need that algorithm.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Tested-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Christian König <deathsimple@vodafone.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Tested-by: Christian König <deathsimple@vodafone.de>
Reviewed-by: Christian König <deathsimple@vodafone.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
- add support for rs6xx
- add support for DCE4/5
- fixup 6xx/7xx
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
