dri-devel October 2014

dri-devel@lists.freedesktop.org

139 participants
947 discussions

[git pull] drm i915 and nouveau fixes
by Dave Airlie 03 Oct '14

03 Oct '14

Hi Linus, Nothing too major or scary, one i915 regression fix, nouveau has a tmds regression fix, along with a regression fix for the runtime pm code for optimus laptops not restoring the display hw correctly. Dave. The following changes since commit fe82dcec644244676d55a1384c958d5f67979adb: Linux 3.17-rc7 (2014-09-28 14:29:07 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to eee0815dabbdd7d584bea8275f5758d25c97cb9b: Merge tag 'drm-intel-fixes-2014-10-02' of git://anongit.freedesktop.org/drm-intel into drm-fixes (2014-10-03 11:38:16 +1000) ---------------------------------------------------------------- Ben Skeggs (4): drm/nv50/disp: fix dpms regression on certain boards drm/nouveau: fix regression on original nv50 board drm/nouveau: punt fbcon resume out to a workqueue drm/nouveau: make sure display hardware is reinitialised on runtime resume Chris Wilson (1): drm/i915: Flush the PTEs after updating them before suspend Dave Airlie (2): Merge branch 'linux-3.17' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes Merge tag 'drm-intel-fixes-2014-10-02' of git://anongit.freedesktop.org/drm-intel into drm-fixes drivers/gpu/drm/i915/i915_gem_gtt.c | 14 ++++++- drivers/gpu/drm/nouveau/core/engine/disp/nv50.c | 3 +- drivers/gpu/drm/nouveau/nouveau_chan.c | 7 +++- drivers/gpu/drm/nouveau/nouveau_display.c | 23 ++++++----- drivers/gpu/drm/nouveau/nouveau_display.h | 5 +-- drivers/gpu/drm/nouveau/nouveau_drm.c | 51 +++++++------------------ drivers/gpu/drm/nouveau/nouveau_fbcon.c | 23 ++++++++--- drivers/gpu/drm/nouveau/nouveau_fbcon.h | 1 + 8 files changed, 65 insertions(+), 62 deletions(-)

1 0

About "Automatic" for "Broadcast RGB" in i915
by Tom Yan 03 Oct '14

03 Oct '14

http://lists.freedesktop.org/archives/dri-devel/2013-January/033572.html Dear All, Please, never do pointless stuff like that. I don't know what exactly are written in the "CEA guidelines" mentioned in the above posts (AFAIK one cannot get a copy of them for free legally), but no one should follow some "guidelines" like that when it make zero sense. Unlike colorspace, literally it's impossible to detect what RGB ranges can a monitor takes, so having an "Automatic" mechanism for it is very likely to be insane. Worsestill, using modes to determine the range is absurd. What does that imply? It implies within a same product line of monitors, models with different physical size (which is likely to have different optimal resolutions) should use different rgb ranges, and the range should also varies when we switch resolution ourselves. The only reason I can think of for those guidelines to exists is, it makes consumer products send limited range signal when it's likely video playback (coz that's how most video is stored), and full range for other usage (such as gameplay). But this mechanism could hardly apply to PC. IMO keeping Full as a default and allow Limited as an option is the only sane way for PC, especially when better HDTV nowadays is starting to accept full RGB range signal. But if you guys think that, people with some cheaper HDTV or some awkward PC monitors which doesn't even do what's aka "PC Level" should get more care, just make Limited as default then. But please, don't deceive users with some fake Automatic option/fix like that. It sucks. Regards, Tom Yan P.S. I am not a programmer or tech expert here, if there's anything wrong in this mail, I'm glad that you point it out to me.

1 0

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
by bugzilla-daemon＠freedesktop.org 02 Oct '14

02 Oct '14

https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #44 from Chernovsky Oleg <adonai(a)xaker.ru> --- (In reply to Alex Deucher from comment #40) > I found some time over the last couple of weekends to write up some > preliminary patches that should point you in the right direction; I just > need to run them by the IP team to make sure they are ok to release. I'd > like to avoid including reverse engineered stuff in the driver as it's a lot > harder for us to maintain. Alex, just reminding you of this bug, did the patch you mentioned passed the review? I'm inly waiting :) -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH v6 0/2] ASoC: tda998x: add a codec to the HDMI transmitter
by Jean-Francois Moine 02 Oct '14

02 Oct '14

The NXP TDA998x HDMI transmitter may transmit audio to the HDMI link from 2 different sources, I2S and S/PDIF. This patch set adds an interface between the HDMI transmitter and the HDMI CODEC. The interface is used by the TDA998x driver to update the audio constraints from the display characteristics (EDID) and by the audio subsystem to connect the chosen audio source to the HDMI link. v6: - extend the HDMI CODEC instead of using a specific CODEC v5: - use the TDA998x private data instead of a specific area for the CODEC interface - the CODEC is TDA998x specific (Mark Brown) v4: - remove all the TDA998x specific stuff from the CODEC - move the EDID scan from the CODEC to the TDA998x - move the CODEC to sound/soc (Mark Brown) - update the audio_sample_rate from the EDID (Andrew Jackson) v3: fix bad rate (Andrew Jackson) v2: check double stream start (Mark Brown) Jean-Francois Moine (2): ASoC:codecs: Add a transmitter interface to the HDMI CODEC drm/i2c:tda998x: Use the HDMI audio CODEC .../devicetree/bindings/drm/i2c/tda998x.txt | 18 ++ drivers/gpu/drm/i2c/Kconfig | 1 + drivers/gpu/drm/i2c/tda998x_drv.c | 299 +++++++++++++++++++-- include/sound/hdmi.h | 20 ++ sound/soc/codecs/hdmi.c | 174 +++++++++++- 5 files changed, 488 insertions(+), 24 deletions(-) create mode 100644 include/sound/hdmi.h -- 2.1.1

5 14

randconfig build error with next-20141001, in drivers/gpu/drm/i915
by Jim Davis 02 Oct '14

02 Oct '14

Building with the attached random configuration file, warning: (VIDEO_TIMBERDALE) selects TIMB_DMA which has unmet direct dependencies (DMADEVICES && MFD_TIMBERDALE) warning: (USB_OTG_FSM && FSL_USB2_OTG && USB_MV_OTG) selects USB_OTG which has unmet direct dependencies (USB_SUPPORT && USB && PM_RUNTIME) drivers/built-in.o: In function `intel_panel_setup_backlight': (.text+0x11855d): undefined reference to `backlight_device_register' drivers/built-in.o: In function `intel_panel_destroy_backlight': (.text+0x118624): undefined reference to `backlight_device_unregister' make: *** [vmlinux] Error 1

3 4

[PATCH 2/2] drm/radeon/kv: add uvd/vce info to dpm debugfs output
by Alex Deucher 02 Oct '14

02 Oct '14

Track whether UVD or VCE are enabled in debugfs. Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> --- drivers/gpu/drm/radeon/kv_dpm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/radeon/kv_dpm.c b/drivers/gpu/drm/radeon/kv_dpm.c index bffacd9..e50b636 100644 --- a/drivers/gpu/drm/radeon/kv_dpm.c +++ b/drivers/gpu/drm/radeon/kv_dpm.c @@ -2773,6 +2773,8 @@ void kv_dpm_debugfs_print_current_performance_level(struct radeon_device *rdev, tmp = (RREG32_SMC(SMU_VOLTAGE_STATUS) & SMU_VOLTAGE_CURRENT_LEVEL_MASK) >> SMU_VOLTAGE_CURRENT_LEVEL_SHIFT; vddc = kv_convert_8bit_index_to_voltage(rdev, (u16)tmp); + seq_printf(m, "uvd %sabled\n", pi->uvd_power_gated ? "dis" : "en"); + seq_printf(m, "vce %sabled\n", pi->vce_power_gated ? "dis" : "en"); seq_printf(m, "power level %d sclk: %u vddc: %u\n", current_index, sclk, vddc); } -- 1.8.3.1

1 0

[PATCH 1/2] drm/radeon/ci: add uvd/vce info to dpm debugfs output
by Alex Deucher 02 Oct '14

02 Oct '14

Track whether UVD or VCE are enabled in debugfs. Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> --- drivers/gpu/drm/radeon/ci_dpm.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c index cdefdf3..5d4cc5c 100644 --- a/drivers/gpu/drm/radeon/ci_dpm.c +++ b/drivers/gpu/drm/radeon/ci_dpm.c @@ -5267,9 +5267,13 @@ int ci_dpm_init(struct radeon_device *rdev) void ci_dpm_debugfs_print_current_performance_level(struct radeon_device *rdev, struct seq_file *m) { + struct ci_power_info *pi = ci_get_pi(rdev); + struct radeon_ps *rps = &pi->current_rps; u32 sclk = ci_get_average_sclk_freq(rdev); u32 mclk = ci_get_average_mclk_freq(rdev); + seq_printf(m, "uvd %sabled\n", pi->uvd_enabled ? "en" : "dis"); + seq_printf(m, "vce %sabled\n", rps->vce_active ? "en" : "dis"); seq_printf(m, "power level avg sclk: %u mclk: %u\n", sclk, mclk); } -- 1.8.3.1

1 0

[PULL] drm-intel-fixes
by Jani Nikula 02 Oct '14

02 Oct '14

Hi Dave, final regression fix for 3.17. BR, Jani. The following changes since commit fe82dcec644244676d55a1384c958d5f67979adb: Linux 3.17-rc7 (2014-09-28 14:29:07 -0700) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-10-02 for you to fetch changes up to 91e56499304f3d612053a9cf17f350868182c7d8: drm/i915: Flush the PTEs after updating them before suspend (2014-09-29 16:41:17 +0300) ---------------------------------------------------------------- Chris Wilson (1): drm/i915: Flush the PTEs after updating them before suspend drivers/gpu/drm/i915/i915_gem_gtt.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) -- Jani Nikula, Intel Open Source Technology Center

1 0

Re: [PATCH 00/22] new radeon info queries
by Alexandre Demers 02 Oct '14

02 Oct '14

May I suggest something more to add if available? It would be great to have the core and memory voltages. As an example of a specific application where it would have been usefull: it would have been easier to debug the problem with Cayman when vddci was not correctly set (it would have been higher or lower than expected or the value would have been nonsense). Thanks, Alexandre Demers

3 2

[PATCH] drm/nouveau: gk20a: Fix type of dividend in do_div()
by Thierry Reding 02 Oct '14

02 Oct '14

From: Thierry Reding <treding(a)nvidia.com> The semantics of do_div() are (see include/asm-generic/div64.h): uint32_t do_div(uint64_t *n, uint32_t base) Using a different type will therefore cause the following warning (as seen on xtensa/allmodconfig): CC [M] drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.o In file included from arch/xtensa/include/generated/asm/div64.h:1:0, from include/linux/kernel.h:124, from include/linux/list.h:8, from include/linux/preempt.h:10, from include/linux/spinlock.h:50, from include/linux/mmzone.h:7, from include/linux/gfp.h:5, from include/linux/slab.h:14, from drivers/gpu/drm/nouveau/core/os.h:5, from drivers/gpu/drm/nouveau/core/include/core/object.h:4, from drivers/gpu/drm/nouveau/core/include/core/device.h:4, from drivers/gpu/drm/nouveau/core/include/subdev/clock.h:4, from drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c:90: drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c: In function 'gk20a_pllg_calc_rate': include/asm-generic/div64.h:43:28: warning: comparison of distinct pointer types lacks a cast (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ ^ drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c:146:2: note: in expansion of macro 'do_div' do_div(rate, divider); ^ drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c:146:2: warning: right shift count >= width of type In file included from arch/xtensa/include/generated/asm/div64.h:1:0, from include/linux/kernel.h:124, from include/linux/list.h:8, from include/linux/preempt.h:10, from include/linux/spinlock.h:50, from include/linux/mmzone.h:7, from include/linux/gfp.h:5, from include/linux/slab.h:14, from drivers/gpu/drm/nouveau/core/os.h:5, from drivers/gpu/drm/nouveau/core/include/core/object.h:4, from drivers/gpu/drm/nouveau/core/include/core/device.h:4, from drivers/gpu/drm/nouveau/core/include/subdev/clock.h:4, from drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c:90: include/asm-generic/div64.h:48:11: warning: passing argument 1 of '__div64_32' from incompatible pointer type __rem = __div64_32(&(n), __base); \ ^ drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c:146:2: note: in expansion of macro 'do_div' do_div(rate, divider); ^ include/asm-generic/div64.h:35:17: note: expected 'uint64_t *' but argument is of type 'u32 *' extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor); Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c b/drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c index 425a8d5e9129..c571437afbd2 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c +++ b/drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c @@ -138,7 +138,7 @@ gk20a_pllg_read_mnp(struct gk20a_clock_priv *priv) static u32 gk20a_pllg_calc_rate(struct gk20a_clock_priv *priv) { - u32 rate; + u64 rate; u32 divider; rate = priv->parent_rate * priv->n; -- 2.1.0

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2014