dri-devel April 2013

dri-devel@lists.freedesktop.org

142 participants
765 discussions

[PATCH] drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900
by Christian Lamparter 03 Apr '13

03 Apr '13

The "Mobile Sandy Bridge CPUs" in the Fujitsu Esprimo Q900 mini desktop PCs are probably misleading the LVDS detection code in intel_lvds_supported. Nothing is connected to the LVDS ports in these systems. Signed-off-by: Christian Lamparter <chunkeey(a)googlemail.com> --- drivers/gpu/drm/i915/intel_lvds.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index 3d1d974..65893b0 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c @@ -850,6 +850,14 @@ static const struct dmi_system_id intel_no_lvds[] = { DMI_MATCH(DMI_PRODUCT_NAME, "X7SPA-H"), }, }, + { + .callback = intel_no_lvds_dmi_callback, + .ident = "Fujitsu Esprimo Q900", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"), + DMI_MATCH(DMI_PRODUCT_NAME, "ESPRIMO Q900"), + }, + }, { } /* terminating entry */ }; -- 1.7.10.4

2 1

Re: UVD fails to init on rv790
by K. Schnass 03 Apr '13

03 Apr '13

> Thanks AMD for getting this out :-) +1 > I have an issue, though. ;( +1 Exactly the same problem but on a RV770! Noticed that the RV710_uvd.bin is some 20kb bigger than the RV770 one so maybe that is the problem? lspci -nnv: 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RV770 [Radeon HD 4850] [1002:9442] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Device [174b:e104] Flags: bus master, fast devsel, latency 0, IRQ 43 Memory at d0000000 (64-bit, prefetchable) [size=256M] Memory at feaf0000 (64-bit, non-prefetchable) [size=64K] I/O ports at d000 [size=256] Expansion ROM at feac0000 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Kernel driver in use: radeon

1 0

[PATCH RESEND] drm: fix drm_local_map allocation size
by Jani Nikula 03 Apr '13

03 Apr '13

list->map is struct drm_local_map *, not struct drm_map_list *. Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> --- Found this small snippet laying around, I guess it fell between the cracks. --- drivers/gpu/drm/drm_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 24efae4..6337edd 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -343,7 +343,7 @@ drm_gem_create_mmap_offset(struct drm_gem_object *obj) /* Set the object up for mmap'ing */ list = &obj->map_list; - list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL); + list->map = kzalloc(sizeof(*list->map), GFP_KERNEL); if (!list->map) return -ENOMEM; -- 1.7.9.5

1 1

linux-next: manual merge of the drm-intel tree with Linus' tree
by Stephen Rothwell 03 Apr '13

03 Apr '13

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in drivers/gpu/drm/i915/intel_panel.c between commit b1289371fcd5 ("Revert "drm/i915: write backlight harder"") from Linus' tree and commit 31ad8ec6a614 ("drm/i915: group backlight related stuff into a struct") from the drm-intel tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwell sfr(a)canb.auug.org.au diff --cc drivers/gpu/drm/i915/intel_panel.c index bee8cb6,0e7e873..0000000 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@@ -318,9 -321,16 +321,13 @@@ void intel_panel_enable_backlight(struc { struct drm_i915_private *dev_priv = dev->dev_private; - if (dev_priv->backlight_level == 0) - dev_priv->backlight_level = intel_panel_get_max_backlight(dev); + if (dev_priv->backlight.level == 0) { + dev_priv->backlight.level = intel_panel_get_max_backlight(dev); + if (dev_priv->backlight.device) + dev_priv->backlight.device->props.brightness = + dev_priv->backlight.level; + } - dev_priv->backlight.enabled = true; - intel_panel_actually_set_backlight(dev, dev_priv->backlight.level); - if (INTEL_INFO(dev)->gen >= 4) { uint32_t reg, tmp; @@@ -356,12 -366,12 +363,12 @@@ } set_level: - /* Check the current backlight level and try to set again if it's zero. - * On some machines, BLC_PWM_CPU_CTL is cleared to zero automatically - * when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 are written. + /* Call below after setting BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1. + * BLC_PWM_CPU_CTL may be cleared to zero automatically when these + * registers are set. */ - dev_priv->backlight_enabled = true; - intel_panel_actually_set_backlight(dev, dev_priv->backlight_level); - if (!intel_panel_get_backlight(dev)) - intel_panel_actually_set_backlight(dev, dev_priv->backlight.level); ++ dev_priv->backlight.enabled = true; ++ intel_panel_actually_set_backlight(dev, dev_priv->backlight.level); } static void intel_panel_init_backlight(struct drm_device *dev)

2 1

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
by bugzilla-daemon＠freedesktop.org 03 Apr '13

03 Apr '13

https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #60 from Austin Lund <austin.lund(a)gmail.com> --- It does look like commit 547b52463 did introduce the problem (tho I didn't finish bisecting). The patch set does fix the issue for me. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
by bugzilla-daemon＠freedesktop.org 03 Apr '13

03 Apr '13

https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #59 from Alex Deucher <agd5f(a)yahoo.com> --- Possibly fixed by this patch set: https://patchwork.kernel.org/patch/2344041/ -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
by bugzilla-daemon＠freedesktop.org 03 Apr '13

03 Apr '13

https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #58 from Austin Lund <austin.lund(a)gmail.com> --- This still doesn't work for 3.9-rc5. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[git pull] drm fixes
by Dave Airlie 02 Apr '13

02 Apr '13

Hi Linus, two core fixes, both regressions, along with some intel and some nouveau fixes for regressions and oopses. Dave. The following changes since commit 2dc958fa2fe6987e7ab106bd97029a09a82fcd8d: ipc: set msg back to -EAGAIN if copy wasn't performed (2013-04-02 10:09:01 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to a8ec3a662921220fc058ed6f7f3674697876d218: drm: correctly restore mappings if drm_open fails (2013-04-03 06:44:38 +1000) ---------------------------------------------------------------- Adam Jackson (1): drm/i915: Be sure to turn hsync/vsync back on at crt enable (v2) Daniel Vetter (2): drm/i915: duct-tape locking when eDP init fails drm: don't unlock in the addfb error paths Dave Airlie (2): Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next Merge branch 'drm-nouveau-fixes-3.9' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next Ilija Hadzic (1): drm: correctly restore mappings if drm_open fails Lauri Kasanen (1): drm/i915: Fix build failure Maarten Lankhorst (2): drm/nouveau: fix handling empty channel list in ioctl's drm/nouveau: fix NULL ptr dereference from nv50_disp_intr() drivers/gpu/drm/drm_crtc.c | 2 -- drivers/gpu/drm/drm_fops.c | 6 +++-- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +- drivers/gpu/drm/i915/intel_crt.c | 40 +++++++++++++----------------- drivers/gpu/drm/i915/intel_dp.c | 3 +++ drivers/gpu/drm/nouveau/nouveau_abi16.c | 18 ++++++++------ drivers/gpu/drm/nouveau/nouveau_drm.c | 32 +++++++++++++++--------- drivers/gpu/drm/nouveau/nouveau_drm.h | 2 +- 8 files changed, 56 insertions(+), 49 deletions(-)

1 0

Re: [Intel-gfx] [PATCH] drm/i915: Add i915.dp_limit_max_lane_count driver option.
by Daniel Vetter 02 Apr '13

02 Apr '13

On Tue, Mar 26, 2013 at 4:40 PM, Michal Srb <msrb(a)suse.com> wrote: > Since 2514bc510d0c3aadcc5204056bb440fa36845147, the intel_dp_mode_fixup > function prefers lane count over frequency. That causes problems on > hardware that has less working lanes than it reports. This option allows > to workaround such hardware bugs. > > Signed-off-by: Michal Srb <msrb(a)suse.com> > --- > This is workaround for hardware issues uncovered by this commit: > > commit 2514bc510d0c3aadcc5204056bb440fa36845147 > Author: Jesse Barnes <jbarnes(a)virtuousgeek.org> > Date: Thu Jun 21 15:13:50 2012 -0700 > > drm/i915: prefer wide & slow to fast & narrow in DP configs > > High frequency link configurations have the potential to cause trouble > with long and/or cheap cables, so prefer slow and wide configurations > instead. This patch has the potential to cause trouble for eDP > configurations that lie about available lanes, so if we run into that we > can make it conditional on eDP. > > I have IBM POS machine (4852-570 Truman) that has internal monitor > connected over display port. It reports to have 2 lanes, but only 1 > lane works reliably. With 2 lanes used, the monitor sometimes doesn't > turn on. It seems that this is hardware issue specific for this model. > > From discussion that was around the 2514bc510d0c3aadcc5204056bb440fa36845147 > commit I understand there are more machines that have similar problems. > This option can be used to solve them. It sounds like we need to start with a DPCD quirk database ... Ajax? -Daniel > --- > > drivers/gpu/drm/i915/i915_drv.c | 6 ++++++ > drivers/gpu/drm/i915/i915_drv.h | 1 + > drivers/gpu/drm/i915/intel_dp.c | 15 +++++++++++++-- > 3 files changed, 20 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 6c4b13c..5949d7c 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -123,6 +123,12 @@ module_param_named(preliminary_hw_support, > i915_preliminary_hw_support, int, 060 > MODULE_PARM_DESC(preliminary_hw_support, > "Enable preliminary hardware support. (default: false)"); > > +int i915_dp_limit_max_lane_count __read_mostly = -1; > +module_param_named(dp_limit_max_lane_count, i915_dp_limit_max_lane_count, > int, 0600); > +MODULE_PARM_DESC(dp_limit_max_lane_count, > + "Limit the maximal number of used display port lanes. " > + "(default: -1 (no limit))"); > + > static struct drm_driver driver; > extern int intel_agp_enabled; > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 1657d873..646e400 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1398,6 +1398,7 @@ extern int i915_enable_fbc __read_mostly; > extern bool i915_enable_hangcheck __read_mostly; > extern int i915_enable_ppgtt __read_mostly; > extern unsigned int i915_preliminary_hw_support __read_mostly; > +extern int i915_dp_limit_max_lane_count __read_mostly; > > extern int i915_suspend(struct drm_device *dev, pm_message_t state); > extern int i915_resume(struct drm_device *dev); > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 662a185..3812773 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -132,6 +132,17 @@ intel_edp_target_clock(struct intel_encoder > *intel_encoder, > return mode->clock; > } > > +static inline u8 > +intel_dp_max_lane_count(u8 dpcd[DP_RECEIVER_CAP_SIZE]) > +{ > + u8 max_lane_count = drm_dp_max_lane_count(dpcd); > + > + if(i915_dp_limit_max_lane_count != -1 && max_lane_count > > i915_dp_limit_max_lane_count) > + max_lane_count = i915_dp_limit_max_lane_count; > + > + return max_lane_count; > +} > + > static int > intel_dp_max_link_bw(struct intel_dp *intel_dp) > { > @@ -184,7 +195,7 @@ intel_dp_adjust_dithering(struct intel_dp *intel_dp, > { > int max_link_clock = > drm_dp_bw_code_to_link_rate(intel_dp_max_link_bw(intel_dp)); > - int max_lanes = drm_dp_max_lane_count(intel_dp->dpcd); > + int max_lanes = intel_dp_max_lane_count(intel_dp->dpcd); > int max_rate, mode_rate; > > mode_rate = intel_dp_link_required(mode->clock, 24); > @@ -697,7 +708,7 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, > struct intel_dp *intel_dp = enc_to_intel_dp(encoder); > struct intel_connector *intel_connector = intel_dp->attached_connector; > int lane_count, clock; > - int max_lane_count = drm_dp_max_lane_count(intel_dp->dpcd); > + int max_lane_count = intel_dp_max_lane_count(intel_dp->dpcd); > int max_clock = intel_dp_max_link_bw(intel_dp) == DP_LINK_BW_2_7 ? 1 : 0; > int bpp, mode_rate; > static int bws[2] = { DP_LINK_BW_1_62, DP_LINK_BW_2_7 }; > -- > 1.7.7 > > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx(a)lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

2 1

drm/tilcdc: LCD panels clocks initialization and earlier backlight initialization
by Michal Bachraty 02 Apr '13

02 Apr '13

Hi, I'm trying to use tilcdc driver for KWH050TG08 LCD panel connected to AM335x processor (3.9 rc1 kernel). I have prepared DT bindings for that (listed bellow). I see fb0 device but I have no clocks going from cpu to LCD. My clocks for LCD seems not properly to be set ... virt_25000000_ck 1 1 25000000 sys_clkin_ck 8 19 25000000 dpll_disp_ck 0 1 25000000 dpll_disp_m2_ck 0 1 25000000 lcd_gclk 0 1 25000000 and tilcdc_crtc is not called. I also set lcd_gclk to 300MHz, but I got same result. The question is there any way how to properly set clocks for LCD? There is also one issue with backlight panel driver initialization in tilcdc driver. This problem seems to depend on DT and I2c driver deferried initialization and then also tps65217-bl driver. Therefore tilcdc is initialized earlier than backlight driver. The question is: is there any way to switch order for loading drivers and how can be that done? My short dmesg listing is as follows: ... [ 3.330046] pinctrl-single 44e10800.pinmux: request pin 41 (44e108a4) for lcd_panel.15 [ 3.338390] pinctrl-single 44e10800.pinmux: request pin 40 (44e108a0) for lcd_panel.15 [ 3.346707] pinctrl-single 44e10800.pinmux: enabling pinmux_lcd_pins function6 [ 3.354387] panel lcd_panel.15: obtain a copy of previously claimed pinctrl [ 3.368248] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 3.375202] [drm] No driver support for vblank timestamp query. [ 3.386253] tilcdc 4830e000.fb: fb0: frame buffer device [ 3.392015] tilcdc 4830e000.fb: registered panic notifier [ 3.397781] [drm] Initialized tilcdc 1.0.0 20121205 on minor 0 [ 3.405347] pinctrl core: add 1 pinmux maps [ 3.409879] pinctrl-single 44e10800.pinmux: found group selector 7 for pinmux_i2c1_pins [ 3.418347] pinctrl-single 44e10800.pinmux: request pin 98 (44e10988) for 44e0b000.i2c [ 3.426662] pinctrl-single 44e10800.pinmux: request pin 99 (44e1098c) for 44e0b000.i2c [ 3.435014] pinctrl-single 44e10800.pinmux: enabling pinmux_i2c1_pins function7 [ 3.442900] omap_i2c 44e0b000.i2c: obtain a copy of previously claimed pinctrl [ 3.453107] omap_i2c 44e0b000.i2c: bus 1 rev0.11 at 400 kHz [ 3.462980] tps65217-pmic tps65217-pmic: no of_node; not parsing pinctrl DT [ 3.473866] DCDC1: 925 <--> 1800 mV at 1800 mV [ 3.480899] vdd_mpu: 925 <--> 1325 mV at 1100 mV [ 3.487935] vdd_core: 925 <--> 1150 mV at 1100 mV [ 3.494958] LDO1: 1000 <--> 3300 mV at 1800 mV [ 3.501814] LDO2: 900 <--> 3300 mV at 3300 mV [ 3.508447] LDO3: 1800 <--> 3300 mV at 3300 mV [ 3.515238] LDO4: 1800 <--> 3300 mV at 3300 mV [ 3.521270] tps65217-bl tps65217-bl: no of_node; not parsing pinctrl DT [ 3.531348] tps65217 1-0024: TPS65217 ID 0xf version 1.1 With older version of kernel (3.7 ) I uses to use da8xx driver (with some patches for DT support and hack for proper clock setup) and this configuration works fine. Best regards, Michal Bachraty device tree: am3358_pinmux: pinmux@44e10800 { lcdc_pins: pinmux_lcd_pins { pinctrl-single,pins = < /* pin-name -> function (name)*/ 0xec 0x00 /* lcd_ac_bias_en ->lcd_ac_bias_en (LCD_EN)- out */ 0xe4 0x00 /* lcd_hsync -> lcd_hsync (LCD_HSYNC) -out */ 0xe0 0x00 /* lcd_vsync -> lcd_vsync (LCD_VSYNC) -out */ 0xe8 0x00 /* lcd_pclk -> lcd_pclk (LCD_PCLK) -out */ 0xdc 0x00 /* lcd_data15 -> lcd_data15 (LCD_DATA15) -out */ 0xd8 0x00 /* lcd_data14 -> lcd_data14 (LCD_DATA14) -out */ 0xd4 0x00 /* lcd_data13 -> lcd_data13 (LCD_DATA13) -out */ 0xd0 0x00 /* lcd_data12 -> lcd_data12 (LCD_DATA12) -out */ 0xcc 0x00 /* lcd_data11 -> lcd_data11 (LCD_DATA11) -out */ 0xc8 0x00 /* lcd_data10 -> lcd_data10 (LCD_DATA10) -out */ 0xc4 0x00 /* lcd_data9 -> lcd_data9 (LCD_DATA9) -out */ 0xc0 0x00 /* lcd_data8 -> lcd_data8 (LCD_DATA8) -out */ 0xbc 0x00 /* lcd_data7 -> lcd_data7 (LCD_DATA7) -out */ 0xb8 0x00 /* lcd_data6 -> lcd_data6 (LCD_DATA6) -out */ 0xb4 0x00 /* lcd_data5 -> lcd_data5 (LCD_DATA5) -out */ 0xb0 0x00 /* lcd_data4 -> lcd_data4 (LCD_DATA4) -out */ 0xac 0x00 /* lcd_data3 -> lcd_data3 (LCD_DATA3) -out */ 0xa8 0x00 /* lcd_data2 -> lcd_data2 (LCD_DATA2) -out */ 0xa4 0x00 /* lcd_data1 -> lcd_data1 (LCD_DATA1) -out */ 0xa0 0x00 /* lcd_data0 -> lcd_data0 (LCD_DATA0) -out */ >; }; }; }; fb: fb@4830e000 { compatible = "ti,am33xx-tilcdc"; reg = <0x4830e000 0x1000>; interrupt-parent = <&intc>; interrupts = <36>; ti,hwmods = "lcdc"; }; lcd_panel { compatible = "ti,tilcdc,panel"; pinctrl-names = "default"; pinctrl-0 = <&lcdc_pins>; panel-info { ac-bias = <255>; ac-bias-intrpt = <0>; dma-burst-sz = <16>; bpp = <16>; fdd = <0x80>; sync-edge = <0>; sync-ctrl = <1>; raster-order = <0>; fifo-th = <0>; }; display-timings { native-mode = <&timing_0>; timing_0: 800x480px { /* 800x480 */ clock-frequency = <50000000>; hactive = <800>; vactive = <480>; hfront-porch = <87>; hback-porch = <0>; hsync-len = <0>; vback-porch = <0>; vfront-porch = <32>; vsync-len = <0>; hsync-active = <0>; vsync-active = <0>; }; }; }; &tps { backlight { fdim = <100>; /* 100Hz,200Hz,500Hz,1000Hz */ isel = <1>; /* 1 = TPS65217_BL_ISET1, 2 = TPS65217_BL_ISET2*/ }; };

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2013