[git pull] drm fixes
Hi Linus, just two small fixes, one radeon, one amdkfd. Dave. The following changes since commit c65b99f046843d2455aa231747b5a07a999a9f3d: Linux 4.1-rc6 (2015-05-31 19:01:07 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to e08f28fdda4ef0df5254d47ef44397c0f99d32ea: Merge tag 'drm-amdkfd-fixes-2015-06-03' of git://people.freedesktop.org/~gabbayo/linux into drm-fixes (2015-06-04 12:29:04 +1000) Alex Deucher (1): drm/radeon: use proper ACR regisiter for DCE3.2 Alexey Skidanov (1): drm/amdkfd: fix topology bug with capability attr. Dave Airlie (2): Merge branch 'drm-fixes-4.1' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-amdkfd-fixes-2015-06-03' of git://people.freedesktop.org/~gabbayo/linux into drm-fixes drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 4 ++-- drivers/gpu/drm/radeon/dce3_1_afmt.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
[PATCH v2 00/10] Color Manager Implementation
HI Kausal, You don't need to send the entire series again . Just send the updated patch --in-reply-to to the last message. Otherwise the thread gets lost. You can send the entire series once the review is complete and you feel that the patches are too nested inside. Please keep sending the patches using --in-reply-to tag. Regards, Sonika -Original Message- From: Malladi, Kausal Sent: Thursday, June 4, 2015 7:13 PM To: Roper, Matthew D; Barnes, Jesse; Lespiau, Damien; Jindal, Sonika; R, Durgadoss; Purushothaman, Vijay A; intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org Cc: Vetter, Daniel; Sharma, Shashank; Kamath, Sunil; Mukherjee, Indranil; Matheson, Annie J; R, Dhanya p; Palleti, Avinash Reddy; Malladi, Kausal Subject: [PATCH v2 00/10] Color Manager Implementation From: Kausal Malladi This patch set adds color manager implementation in drm/i915 layer. Color Manager is an extension in i915 driver to support color correction/enhancement. Various Intel platforms support several color correction capabilities. Color Manager provides abstraction of these properties and allows a user space UI agent to correct/enhance the display. The first three patches add code for the framework, which will be common across all the Intel platforms. drm/i915: Initialize Color Manager drm/i915: Attach color properties to CRTC drm/i915: Add Set property interface for CRTC In the next patches, we are adding support for Gamma and CSC color properties. Please note that: 1. The current implementation is only limited for CHV/BSW platforms, and the support for other platforms will be following up soon. 2. The current patch set implements only the "set" part of the properties, "get" part will be following up soon. The design of color management on linux is done by: Jesse Barnes Sirisha Muppavarapu Shashank Sharma Susanta Bhattacharjee The complete design is explained in the design document, which is available at https://docs.google.com/document/d/1jyfNSAStKHEpmIUZd_1Gd68cPuyiyr8wmJXThSDb_2w/edit# v2: Addressed review comments from Sonika and Daniel Stone. Kausal Malladi (10): drm/i915: Initialize Color Manager drm/i915: Attach color properties to CRTC drm/i915: Add atomic set property interface for CRTC drm: Add Gamma correction structure drm: Add a new function for updating color blob drm: Avoid atomic commit path for CRTC property (Gamma) drm/i915: Add pipe level Gamma correction for CHV/BSW drm: Add CSC correction structure drm: Avoid atomic commit path for CSC property on CRTC drm/i915: Add CSC support for CHV/BSW drivers/gpu/drm/drm_atomic_helper.c| 18 +- drivers/gpu/drm/drm_crtc.c | 15 ++ drivers/gpu/drm/i915/Makefile | 3 + drivers/gpu/drm/i915/intel_atomic.c| 19 +- drivers/gpu/drm/i915/intel_color_manager.c | 348 + drivers/gpu/drm/i915/intel_color_manager.h | 122 ++ drivers/gpu/drm/i915/intel_display.c | 8 + drivers/gpu/drm/i915/intel_drv.h | 4 + include/drm/drm_crtc.h | 12 + include/uapi/drm/drm.h | 18 ++ 10 files changed, 563 insertions(+), 4 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_color_manager.c create mode 100644 drivers/gpu/drm/i915/intel_color_manager.h -- 2.4.2
[PATCH] drm: bridge/dw_hdmi: Return num_modes in dw_hdmi_connector_get_modes
Doug, å¨ 2015/6/5 2:04, Doug Anderson åé: > The dw_hdmi_connector_get_modes() function accidentally forgets to > return the number of modes it added, although it has this information > stored in a local variable. Let's fix that. > > Without this fix, drm_helper_probe_single_connector_modes_merge_bits() > could get confused and always call drm_add_modes_noedid(). That's not > right. > > Signed-off-by: Doug Anderson Test-by: Yakir Yang Thanks for your patch, it looks good to me. I And I test it on my 1080p TV, found that the 800x600 at 56Hz resolution which don't indicate in edid would no longer report, that is right :) 3331connectedHDMI-A510x2901731 modes: name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot) 800x600 60 800 840 968 1056 600 601 605 628 flags: phsync, pvsync; type: driver 800x600 56 800 824 896 1024 600 601 603 625 flags: phsync, pvsync; type: driver 640x480 60 640 656 752 800 480 490 492 525 flags: nhsync, nvsync; type: driver 640x480 60 640 656 752 800 480 489 492 525 flags: nhsync, nvsync; type: driver First detailed timing is preferred timing Established timings supported: 720x400 at 70Hz 640x480 at 60Hz 640x480 at 75Hz 800x600 at 60Hz 800x600 at 75Hz 1024x768 at 60Hz 1024x768 at 75Hz 1280x1024 at 75Hz Standard timings supported: 1152x864 at 75Hz 1280x1024 at 60Hz 1920x1080 at 60Hz Thanks ! - Yakir > --- > drivers/gpu/drm/bridge/dw_hdmi.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c > b/drivers/gpu/drm/bridge/dw_hdmi.c > index 594f84c..816d104 100644 > --- a/drivers/gpu/drm/bridge/dw_hdmi.c > +++ b/drivers/gpu/drm/bridge/dw_hdmi.c > @@ -1395,7 +1395,7 @@ static int dw_hdmi_connector_get_modes(struct > drm_connector *connector) > struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi, >connector); > struct edid *edid; > - int ret; > + int ret = 0; > > if (!hdmi->ddc) > return 0; > @@ -1412,7 +1412,7 @@ static int dw_hdmi_connector_get_modes(struct > drm_connector *connector) > dev_dbg(hdmi->dev, "failed to get edid\n"); > } > > - return 0; > + return ret; > } > > static enum drm_mode_status -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150605/4f01257f/attachment.html>
Etnaviv DRM driver userspace support?
I have tried to look through archives but couldn't find answer where I should look for userspace components (libdrm, mesa) for the etnaviv drm driver? At the moment I have kernel 4.1-rc6 running with these [1] imx-drm patches on riotBoard with custom lvds display, display is working fine, but only with SW rendering. dmesg shows that etnaviv-gpu has found GC320 and GC880 units. [1] http://www.home.arm.linux.org.uk/~rmk/cubox/hummingboard-cubox-i-v4.1-rc1-20150602/ Br, - Kimmo S. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150605/3020679e/attachment.html>
linux-next: manual merge of the drm tree with the drm-intel-fixes tree
On Fri, 05 Jun 2015, "mpe at ellerman.id.au" wrote:
> Hi Dave,
>
> Today's linux-next merge of the drm tree got a conflict in
> drivers/gpu/drm/i915/intel_ringbuffer.c between commit 4f47c99a9be7
> ("drm/i915:
> Move WaBarrierPerformanceFixDisable:skl to skl code from chv code") from the
> drm-intel-fixes tree and commit b62adbd1ea1f ("drm/i915/bxt: Move
> WaForceEnableNonCoherent to Skylake only") from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Our tree seems to have the if blocks the other way round. I don't think
it matters, but Ville, Damien, chime in if you think it does.
BR
Jani.
>
> cheers
>
> diff --cc drivers/gpu/drm/i915/intel_ringbuffer.c
> index 005b5e04de4d,d934f857394d..
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@@ -1017,13 -1030,17 +1023,24 @@@ static int skl_init_workarounds(struct
> WA_SET_BIT_MASKED(HIZ_CHICKEN,
> BDW_HIZ_POWER_COMPILER_CLOCK_GATING_DISABLE);
>
> +if (INTEL_REVID(dev) == SKL_REVID_C0 ||
> +INTEL_REVID(dev) == SKL_REVID_D0)
> +/* WaBarrierPerformanceFixDisable:skl */
> +WA_SET_BIT_MASKED(HDC_CHICKEN0,
> + HDC_FENCE_DEST_SLM_DISABLE |
> + HDC_BARRIER_PERFORMANCE_DISABLE);
> +
> + if (INTEL_REVID(dev) <= SKL_REVID_D0) {
> + /*
> + *Use Force Non-Coherent whenever executing a 3D context. This
> + * is a workaround for a possible hang in the unlikely event
> + * a TLB invalidation occurs during a PSD flush.
> + */
> + /* WaForceEnableNonCoherent:skl */
> + WA_SET_BIT_MASKED(HDC_CHICKEN0,
> + HDC_FORCE_NON_COHERENT);
> + }
> +
> return skl_tune_iz_hashing(ring);
> }
>
--
Jani Nikula, Intel Open Source Technology Center
[PATCH 1/2] drm/sti: hdmi fix CEA-861E video format timing error
HDMI analyzer tests showed that Vsync and Hsync signal were not compliant with the HDMI protocol. The first active pixel of a line is defined by HDMI_ACTIVE_VID_XMIN. The last active pixel of a line is defined by HDMI_ACTIVE_VID_XMAX. Signed-off-by: Vincent Abriou --- drivers/gpu/drm/sti/sti_hdmi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c index ae5424b..f28a4d5 100644 --- a/drivers/gpu/drm/sti/sti_hdmi.c +++ b/drivers/gpu/drm/sti/sti_hdmi.c @@ -192,8 +192,8 @@ static void hdmi_active_area(struct sti_hdmi *hdmi) u32 xmin, xmax; u32 ymin, ymax; - xmin = sti_vtg_get_pixel_number(hdmi->mode, 0); - xmax = sti_vtg_get_pixel_number(hdmi->mode, hdmi->mode.hdisplay - 1); + xmin = sti_vtg_get_pixel_number(hdmi->mode, 1); + xmax = sti_vtg_get_pixel_number(hdmi->mode, hdmi->mode.hdisplay); ymin = sti_vtg_get_line_number(hdmi->mode, 0); ymax = sti_vtg_get_line_number(hdmi->mode, hdmi->mode.vdisplay - 1); -- 1.9.1
[PATCH 1/1] drm/sti: VTG interrupt names are badly displayed
VTG interrupt names are badly displayed using "cat /proc/interrupts".
Simply use the VTG device name while registering the VTG interrupts
to fix it.
Signed-off-by: Vincent Abriou
---
drivers/gpu/drm/sti/sti_vtg.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_vtg.c b/drivers/gpu/drm/sti/sti_vtg.c
index 9564f25..eda62c8 100644
--- a/drivers/gpu/drm/sti/sti_vtg.c
+++ b/drivers/gpu/drm/sti/sti_vtg.c
@@ -311,7 +311,6 @@ static int vtg_probe(struct platform_device *pdev)
struct device_node *np;
struct sti_vtg *vtg;
struct resource *res;
- char irq_name[32];
int ret;
vtg = devm_kzalloc(dev, sizeof(*vtg), GFP_KERNEL);
@@ -342,13 +341,11 @@ static int vtg_probe(struct platform_device *pdev)
return vtg->irq;
}
- snprintf(irq_name, sizeof(irq_name), "vsync-%s",
- dev_name(vtg->dev));
-
RAW_INIT_NOTIFIER_HEAD(&vtg->notifier_list);
ret = devm_request_threaded_irq(dev, vtg->irq, vtg_irq,
- vtg_irq_thread, IRQF_ONESHOT, irq_name, vtg);
+ vtg_irq_thread, IRQF_ONESHOT,
+ dev_name(dev), vtg);
if (IS_ERR_VALUE(ret)) {
DRM_ERROR("Failed to register VTG interrupt\n");
return ret;
--
1.9.1
[PATCH 0/2] drm/sti: CEA-861E video format timing error
This set of patches fixes hdmi timing errors reported by an HDMI protocol analyser. Vincent Abriou (2): drm/sti: hdmi fix CEA-861E video format timing error drm/sti: vtg fix CEA-861E video format timing error drivers/gpu/drm/sti/sti_hdmi.c | 4 ++-- drivers/gpu/drm/sti/sti_vtg.c | 7 +-- 2 files changed, 7 insertions(+), 4 deletions(-) -- 1.9.1
[PATCH 2/2] drm/sti: vtg fix CEA-861E video format timing error
HDMI analyzer tests showed that Vsync and Hsync signal were not compliant with the HDMI protocol. HDMI_DELAY should be taken into account in the VTG Vsync programming to reflect the 6 pixels shift introduced in the VTG Hsync programming. Signed-off-by: Vincent Abriou --- drivers/gpu/drm/sti/sti_vtg.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/sti/sti_vtg.c b/drivers/gpu/drm/sti/sti_vtg.c index eda62c8..d21df0d 100644 --- a/drivers/gpu/drm/sti/sti_vtg.c +++ b/drivers/gpu/drm/sti/sti_vtg.c @@ -151,8 +151,11 @@ static void vtg_set_mode(struct sti_vtg *vtg, tmp |= 1; writel(tmp, vtg->regs + VTG_TOP_V_VD_1); writel(tmp, vtg->regs + VTG_BOT_V_VD_1); - writel(0, vtg->regs + VTG_TOP_V_HD_1); - writel(0, vtg->regs + VTG_BOT_V_HD_1); + + tmp = HDMI_DELAY << 16; + tmp |= HDMI_DELAY; + writel(tmp, vtg->regs + VTG_TOP_V_HD_1); + writel(tmp, vtg->regs + VTG_BOT_V_HD_1); /* prepare VTG set 2 for for HD DCS */ tmp = (mode->hsync_end - mode->hsync_start) << 16; -- 1.9.1
[PATCH] drm: bridge/dw_hdmi: Return num_modes in dw_hdmi_connector_get_modes
On Thu, Jun 04, 2015 at 11:04:36AM -0700, Doug Anderson wrote: > The dw_hdmi_connector_get_modes() function accidentally forgets to > return the number of modes it added, although it has this information > stored in a local variable. Let's fix that. > > Without this fix, drm_helper_probe_single_connector_modes_merge_bits() > could get confused and always call drm_add_modes_noedid(). That's not > right. > > Signed-off-by: Doug Anderson > --- > drivers/gpu/drm/bridge/dw_hdmi.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Applied, thanks. Thierry
[Bug 90869] Rendering bug in The Witcher
https://bugs.freedesktop.org/show_bug.cgi?id=90869 Bug ID: 90869 Summary: Rendering bug in The Witcher Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: sa at whiz.se QA Contact: dri-devel at lists.freedesktop.org Created attachment 116318 --> https://bugs.freedesktop.org/attachment.cgi?id=116318&action=edit Screenshot of bug Hi, I'm trying to run the game The Witcher (in Wine) it has rendering errors when drawing the rain. This bug is present in both git master (78395dbf9ff429d98523f8b4a340f7188d8b4db0) and in 10.5.5. I made an apitrace of the game and it renders without problem on i965. Running the trace on r600 results in this warning: 101172: glDebugOutputCallback: Medium severity API unknown issue 1, FBO incomplete: driver marked FBO as incomplete [-1] This is on a Redwood, Radeon HD 5670 1GB. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150605/e0495b6c/attachment.html>
[Bug 90869] Rendering bug in The Witcher
https://bugs.freedesktop.org/show_bug.cgi?id=90869 --- Comment #1 from Sven Arvidsson --- apitrace file: https://www.dropbox.com/s/3hmjqeil80d3x28/witcher.trace?dl=0 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150605/0f310a6c/attachment.html>
[PATCH v3 1/2] drm/bridge: dw-hdmi: support optional supply regulators
On Mon, Mar 23, 2015 at 07:17:49PM +0100, Heiko Stuebner wrote: > Hi Philipp, > > Am Donnerstag, 12. März 2015, 21:45:19 schrieb Heiko Stuebner: > > At least the Rockchip variant of the dw_hdmi can have controllable power > > supplies providing 1.0 and 1.8V. Therefore add the possibility for the > > generic bridge driver to enable supplies provided by the hw-specific > > drivers. > > > > Signed-off-by: Heiko Stuebner > > does this look ok now? > > And as we talked about in Chemnitz, who will be taking such bridge-related > changes, as you mentioned some last bridge-patches going through Thierry. Sorry, I had completely missed this. > > --- > > changes since v2: > > - rename supplies to the names found in the hdmi IP databook > > changes since v1: > > - follow suggestion from Russell King to keep regulator handling local > > to the rockchip implementation for the time being and only generalize > > when a real second implementation needs regulator handling > > > > .../devicetree/bindings/drm/bridge/dw_hdmi.txt | 5 > > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 32 > > +- 2 files changed, 36 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt > > b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt index > > a905c14..bb74640 100644 > > --- a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt > > +++ b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt > > @@ -22,6 +22,11 @@ Optional properties > > - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing > > - clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec" > > > > +Optional supplies: > > +rockchip,rk3288-dw-hdmi handles two optional power supplies: > > +- vp-supply: 1.0V power supply > > +- vph-supply: 1.8V power supply If this is specific to the Rockchip implementation, shouldn't this go into Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt? It could then simply go into the Rockchip DRM tree. Thierry
[Bug 90869] Rendering bug in The Witcher
https://bugs.freedesktop.org/show_bug.cgi?id=90869 Laurent carlier changed: What|Removed |Added Attachment #116318|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150605/9b18e43d/attachment.html>
[PATCH 01/27] drm/bridge: ptn3460: #include , depend on GPIOLIB
On Tue, May 05, 2015 at 06:32:17PM +0200, Geert Uytterhoeven wrote: > If GPIOLIB=n and asm-generic/gpio.h is not used: > > drivers/gpu/drm/bridge/ptn3460.c: In function âptn3460_pre_enableâ: > drivers/gpu/drm/bridge/ptn3460.c:135: error: implicit declaration of > function âgpiod_set_valueâ > drivers/gpu/drm/bridge/ptn3460.c: In function âptn3460_probeâ: > drivers/gpu/drm/bridge/ptn3460.c:333: error: implicit declaration of > function âdevm_gpiod_getâ > drivers/gpu/drm/bridge/ptn3460.c:333: warning: assignment makes pointer > from integer without a cast > drivers/gpu/drm/bridge/ptn3460.c:340: error: implicit declaration of > function âgpiod_direction_outputâ > drivers/gpu/drm/bridge/ptn3460.c:346: warning: assignment makes pointer > from integer without a cast > > Add the missing #include to fix this. > > As the resulting driver won't work with GPIOLIB=n anyway, make > DRM_PTN3460 depend on GPIOLIB || COMPILE_TEST. > > Signed-off-by: Geert Uytterhoeven > Cc: David Airlie > Cc: dri-devel at lists.freedesktop.org > --- > drivers/gpu/drm/bridge/Kconfig | 4 ++-- > drivers/gpu/drm/bridge/ptn3460.c | 1 + > 2 files changed, 3 insertions(+), 2 deletions(-) Applied, thanks. Note that I dropped the part about adding the GPIOLIB dependency because that had been attempted previously to fix this, but it causes recursive dependencies on PowerPC (ppc64_defconfig). I don't know of a way to untangle those (I tried and failed miserably), so I think adding the include is really as good as it'll get. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150605/42da27cd/attachment-0001.sig>
[PATCH 02/27] drm/bridge: ps8622: #include , depend on GPIOLIB
On Tue, May 05, 2015 at 06:32:18PM +0200, Geert Uytterhoeven wrote: > If GPIOLIB=n and asm-generic/gpio.h is not used: > > drivers/gpu/drm/bridge/ps8622.c: In function âps8622_pre_enableâ: > drivers/gpu/drm/bridge/ps8622.c:368: error: implicit declaration of > function âgpiod_set_valueâ > drivers/gpu/drm/bridge/ps8622.c: In function âps8622_probeâ: > drivers/gpu/drm/bridge/ps8622.c:584: error: implicit declaration of > function âdevm_gpiod_getâ > drivers/gpu/drm/bridge/ps8622.c:584: warning: assignment makes pointer > from integer without a cast > drivers/gpu/drm/bridge/ps8622.c:590: error: implicit declaration of > function âgpiod_direction_outputâ > drivers/gpu/drm/bridge/ps8622.c:596: warning: assignment makes pointer > from integer without a cast > > Add the missing #include to fix this. > > As the resulting driver won't work with GPIOLIB=n anyway, make > DRM_PS8622 depend on GPIOLIB || COMPILE_TEST. > > Signed-off-by: Geert Uytterhoeven > Cc: David Airlie > Cc: dri-devel at lists.freedesktop.org > --- > drivers/gpu/drm/bridge/Kconfig | 4 ++-- > drivers/gpu/drm/bridge/ps8622.c | 1 + > 2 files changed, 3 insertions(+), 2 deletions(-) Applied, thanks. With the same modifications as patch 1/27. I wonder if there's any reason to keep the linux/gpio.h include, since consumer.h seems to expose all the API that the drivers need. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150605/df669ea0/attachment.sig>
[PATCH] drm/cma: Fix 64-bit size_t build warnings
On Mon, May 04, 2015 at 04:16:19PM +0200, Geert Uytterhoeven wrote: > From: Magnus Damm > > Fix warnings related to size_t when building for 64-bit architectures: > > drivers/gpu/drm/drm_gem_cma_helper.c: In function âdrm_gem_cma_createâ: > drivers/gpu/drm/drm_gem_cma_helper.c:114:4: warning: format â%dâ expects > argument of type âintâ, but argument 3 has type âsize_tâ [-Wformat=] > size); > ^ > drivers/gpu/drm/drm_gem_cma_helper.c: In function âdrm_gem_cma_describeâ: > drivers/gpu/drm/drm_gem_cma_helper.c:393:4: warning: format â%dâ expects > argument of type âintâ, but argument 8 has type âsize_tâ [-Wformat=] > off, &cma_obj->paddr, cma_obj->vaddr, obj->size); > > Signed-off-by: Magnus Damm > Signed-off-by: Geert Uytterhoeven > --- > drivers/gpu/drm/drm_gem_cma_helper.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Thierry Reding Daniel, is this perhaps something you'd like to pick up into your misc branch? Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150605/11bd80ed/attachment.sig>
[PATCH] drm/nouveau/disp: Use NULL for pointers
On Mon, Oct 13, 2014 at 08:16:57PM +0100, Emil Velikov wrote: > On 13/10/14 12:47, Thierry Reding wrote: > > On Mon, Jul 21, 2014 at 02:02:58PM +0200, Thierry Reding wrote: > >> From: Thierry Reding > >> > >> The return type of exec_lookup() is struct nvkm_output *, so it should > >> return NULL rather than 0. > >> > >> Signed-off-by: Thierry Reding > >> --- > >> drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c > >> b/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c > >> index fa30d8196f35..ebf64e1d0a70 100644 > >> --- a/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c > >> +++ b/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c > >> @@ -939,7 +939,7 @@ exec_lookup(struct nv50_disp_priv *priv, int head, int > >> or, u32 ctrl, > >>case 0x0900: type = DCB_OUTPUT_DP; mask = 2; break; > >>default: > >>nv_error(priv, "unknown SOR mc 0x%08x\n", ctrl); > >> - return 0x; > >> + return NULL; > >>} > >>} > >> > > > > Ping? > > > > Thierry > > > I have an identical patch in a local branch, but with worse commit > message :) Fwiw the patch is > > Reviewed-by: Emil Velikov Ben, any chance you could pick this up? It should still apply as-is on recent trees, but I can resend if you prefer. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150605/1ca91b92/attachment.sig>
[PATCH] drm/nouveau: Do not leak client objects
On Thu, Oct 16, 2014 at 11:54:54AM +0200, Thierry Reding wrote: > From: Thierry Reding > > The memory allocated for a nouveau_cli object in nouveau_cli_create() is > never freed. Free the memory in nouveau_cli_destroy() to plug this leak. > > kmemleak recorded this after running a couple of nouveau test programs. > Note that kmemleak points at drm_open_helper() because for some reason > it thinks that skipping the first two stack frames is a good idea. > > Signed-off-by: Thierry Reding > --- > drivers/gpu/drm/nouveau/nouveau_drm.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c > b/drivers/gpu/drm/nouveau/nouveau_drm.c > index 57238076049f..6dc2c915ba6e 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_drm.c > +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c > @@ -126,6 +126,7 @@ nouveau_cli_destroy(struct nouveau_cli *cli) > nouveau_vm_ref(NULL, &nvkm_client(&cli->base)->vm, NULL); > nvif_client_fini(&cli->base); > usif_client_fini(cli); > + kfree(cli); > } > > static void Ben, any chance you could pick this up? Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150605/7bfd8e40/attachment.sig>
[PATCH 01/27] drm/bridge: ptn3460: #include , depend on GPIOLIB
Hi Thierry,
On Fri, Jun 5, 2015 at 1:20 PM, Thierry Reding
wrote:
> On Tue, May 05, 2015 at 06:32:17PM +0200, Geert Uytterhoeven wrote:
>> If GPIOLIB=n and asm-generic/gpio.h is not used:
>>
>> drivers/gpu/drm/bridge/ptn3460.c: In function âptn3460_pre_enableâ:
>> drivers/gpu/drm/bridge/ptn3460.c:135: error: implicit declaration of
>> function âgpiod_set_valueâ
>> drivers/gpu/drm/bridge/ptn3460.c: In function âptn3460_probeâ:
>> drivers/gpu/drm/bridge/ptn3460.c:333: error: implicit declaration of
>> function âdevm_gpiod_getâ
>> drivers/gpu/drm/bridge/ptn3460.c:333: warning: assignment makes pointer
>> from integer without a cast
>> drivers/gpu/drm/bridge/ptn3460.c:340: error: implicit declaration of
>> function âgpiod_direction_outputâ
>> drivers/gpu/drm/bridge/ptn3460.c:346: warning: assignment makes pointer
>> from integer without a cast
>>
>> Add the missing #include to fix this.
>>
>> As the resulting driver won't work with GPIOLIB=n anyway, make
>> DRM_PTN3460 depend on GPIOLIB || COMPILE_TEST.
>>
>> Signed-off-by: Geert Uytterhoeven
>> Cc: David Airlie
>> Cc: dri-devel at lists.freedesktop.org
>> ---
>> drivers/gpu/drm/bridge/Kconfig | 4 ++--
>> drivers/gpu/drm/bridge/ptn3460.c | 1 +
>> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> Applied, thanks. Note that I dropped the part about adding the GPIOLIB
> dependency because that had been attempted previously to fix this, but
> it causes recursive dependencies on PowerPC (ppc64_defconfig). I don't
> know of a way to untangle those (I tried and failed miserably), so I
> think adding the include is really as good as it'll get.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v2 04/10] drm: Add Gamma correction structure
On 6/4/2015 7:12 PM, Kausal Malladi wrote:
> From: Kausal Malladi
>
> This patch adds a new structure in DRM layer for Gamma color correction.
> This structure will be used by all user space agents to configure
> appropriate Gamma precision and Gamma level.
>
> struct drm_intel_gamma {
> __u32 gamma_level;
> (The gamma_level variable indicates if the Gamma correction is to be
Do you have any macro defines for these levels? Maybe an enum will be
better?
> applied on Pipe/plane)
> __u32 gamma_precision;
> (The Gamma precision indicates the Gamma mode to be applied)
>
> Supported precisions are -
> #define I915_GAMMA_PRECISION_UNKNOWN0
> #define I915_GAMMA_PRECISION_CURRENT0x
> #define I915_GAMMA_PRECISION_LEGACY (1 << 0)
> #define I915_GAMMA_PRECISION_10BIT (1 << 1)
> #define I915_GAMMA_PRECISION_12BIT (1 << 2)
> #define I915_GAMMA_PRECISION_14BIT (1 << 3)
> #define I915_GAMMA_PRECISION_16BIT (1 << 4)
>
> __u32 num_samples;
> (The num_samples indicates the number of Gamma correction
> coefficients)
> __u32 reserved;
You need this reserved?
> __u16 values[0];
> (An array of size 0, to accommodate the "num_samples" number of
> R16G16B16 pixels, dynamically)
> };
>
> v2: Addressing Daniel Stone's comment, added a variable sized array to
> carry Gamma correction values as blob property.
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
> ---
> include/drm/drm_crtc.h | 3 +++
> include/uapi/drm/drm.h | 10 ++
> 2 files changed, 13 insertions(+)
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 2a75d7d..bc44f27 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -483,6 +483,9 @@ struct drm_crtc {
>* acquire context.
>*/
> struct drm_modeset_acquire_ctx *acquire_ctx;
> +
Just trying to understand, why do we need to store the blob id separately?
> + /* Color Management Blob IDs */
> + u32 gamma_blob_id;
> };
>
> /**
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 3801584..fc2661c 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -829,6 +829,16 @@ struct drm_event_vblank {
> __u32 reserved;
> };
>
> +/* Color Management structure for Gamma */
> +struct drm_gamma {
> + __u32 flags;
> + __u32 gamma_level;
> + __u32 gamma_precision;
> + __u32 num_samples;
> + __u32 reserved;
> + __u16 values[0];
> +};
> +
> /* typedef area */
> #ifndef __KERNEL__
> typedef struct drm_clip_rect drm_clip_rect_t;
>
[PATCH v3 1/2] drm/bridge: dw-hdmi: support optional supply regulators
Hi Thierry Am Freitag, 5. Juni 2015, 13:02:01 schrieb Thierry Reding: > On Mon, Mar 23, 2015 at 07:17:49PM +0100, Heiko Stuebner wrote: > > Hi Philipp, > > > > Am Donnerstag, 12. März 2015, 21:45:19 schrieb Heiko Stuebner: > > > At least the Rockchip variant of the dw_hdmi can have controllable power > > > supplies providing 1.0 and 1.8V. Therefore add the possibility for the > > > generic bridge driver to enable supplies provided by the hw-specific > > > drivers. > > > > > > Signed-off-by: Heiko Stuebner > > > > does this look ok now? > > > > And as we talked about in Chemnitz, who will be taking such bridge-related > > changes, as you mentioned some last bridge-patches going through Thierry. > > Sorry, I had completely missed this. > > > > --- > > > changes since v2: > > > - rename supplies to the names found in the hdmi IP databook > > > changes since v1: > > > - follow suggestion from Russell King to keep regulator handling local > > > > > > to the rockchip implementation for the time being and only generalize > > > when a real second implementation needs regulator handling > > > > > > .../devicetree/bindings/drm/bridge/dw_hdmi.txt | 5 > > > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 32 > > > > > > +- 2 files changed, 36 insertions(+), 1 deletion(-) > > > > > > diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt > > > b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt index > > > a905c14..bb74640 100644 > > > --- a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt > > > +++ b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt > > > @@ -22,6 +22,11 @@ Optional properties > > > > > > - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing > > > - clocks, clock-names: phandle to the HDMI CEC clock, name should be > > > "cec" > > > > > > +Optional supplies: > > > +rockchip,rk3288-dw-hdmi handles two optional power supplies: > > > +- vp-supply: 1.0V power supply > > > +- vph-supply: 1.8V power supply > > If this is specific to the Rockchip implementation, shouldn't this go > into Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt? It > could then simply go into the Rockchip DRM tree. actually, we determined that the supply names are universal to the IP (both in imx and rockchip and probably more if there are more users out there). Just Russell requested that we don't pollute the generic code until necessary, as it looks like the supply of those is somehow handled internally on the imx. Heiko
[PATCH] drm/panel: add lg4573 driver
to_lg4573(panel);
> +
> + return lg4573_display_off(ctx);
> +}
> +
> +static int lg4573_enable(struct drm_panel *panel)
> +{
> + struct lg4573 *ctx = panel_to_lg4573(panel);
> + int ret;
> +
> + lg4573_init(ctx);
> +
> + ret = lg4573_power_on(ctx);
> +
> + return ret;
> +}
I think these should all propagate errors.
> +static int lg4573_get_modes(struct drm_panel *panel)
> +{
> + struct drm_connector *connector = panel->connector;
> + struct lg4573 *ctx = panel_to_lg4573(panel);
> + struct drm_display_mode *mode;
> +
> + mode = drm_mode_create(connector->dev);
> + if (!mode) {
> + DRM_ERROR("failed to create a new display mode\n");
> + return 0;
> + }
> +
> + drm_display_mode_from_videomode(&ctx->vm, mode);
> +
> + mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> + drm_mode_probed_add(connector, mode);
> +
> + return 1;
> +}
You can either use a hard-coded mode or use display timings along with
the helpers to convert the timings to a default mode. No need to parse
the information from DT.
> +static const struct drm_panel_funcs lg4573_drm_funcs = {
> + .disable = lg4573_disable,
> + .enable = lg4573_enable,
> + .get_modes = lg4573_get_modes,
> +};
> +
> +static int lg4573_parse_dt(struct lg4573 *ctx)
> +{
> + struct device *dev = ctx->dev;
> + struct device_node *np = dev->of_node;
> + int ret;
> +
> + ret = of_get_videomode(np, &ctx->vm, 0);
> + if (ret < 0)
> + return ret;
> +
> + of_property_read_u32(np, "power-on-delay", &ctx->power_on_delay);
> +
> + return 0;
> +}
> +
> +static int lg4573_probe(struct spi_device *spi)
> +{
> + struct device *dev = &spi->dev;
> + struct lg4573 *ctx;
> + int ret;
> +
> + ctx = devm_kzalloc(dev, sizeof(struct lg4573), GFP_KERNEL);
> + if (!ctx)
> + return -ENOMEM;
> +
> + spi_set_drvdata(spi, ctx);
> + ctx->dev = dev;
> +
> + ret = lg4573_parse_dt(ctx);
> + if (ret < 0)
> + return ret;
> +
> + spi->bits_per_word = 8;
> + ret = spi_setup(spi);
> + if (ret < 0) {
> + dev_err(dev, "spi setup failed.\n");
You might want to include the error code in the message. Also "SPI".
> +static const struct of_device_id lg4573_of_match[] = {
> + { .compatible = "lg,lg4573" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, lg4573_of_match);
> +
> +static struct spi_driver lg4573_driver = {
> + .probe = lg4573_probe,
> + .remove = lg4573_remove,
> + .driver = {
> + .name = "lg4573",
> + .owner = THIS_MODULE,
> + .of_match_table = lg4573_of_match,
> + },
No need for the padding. It's not consistent anyway.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150605/4df6ce60/attachment.sig>
[PATCH] drm/amdkfd: avoid CONFIG_ prefix for non-Kconfig symbols
The CONFIG_ prefix is reserved for Kconfig options in Make and CPP
syntax. Various static analysis tools rely on this naming convention
and check if CONFIG_ prefixed symbols are defined Kconfig. Hence add
yet another prefix AMD_ to CONFIG_REG_{BASE,END,SISE} to apply to this
convention and make static analysis tools happy.
Signed-off-by: Valentin Rothberg
---
drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c | 10 +-
drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.h | 6 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c
index 96153f28d73f..c34c393e9aea 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c
@@ -445,7 +445,7 @@ static int dbgdev_address_watch_diq(struct kfd_dbgdev
*dbgdev,
aw_reg_add_dword /= sizeof(uint32_t);
packets_vec[0].bitfields2.reg_offset =
- aw_reg_add_dword - CONFIG_REG_BASE;
+ aw_reg_add_dword - AMD_CONFIG_REG_BASE;
packets_vec[0].reg_data[0] = cntl.u32All;
@@ -458,7 +458,7 @@ static int dbgdev_address_watch_diq(struct kfd_dbgdev
*dbgdev,
aw_reg_add_dword /= sizeof(uint32_t);
packets_vec[1].bitfields2.reg_offset =
- aw_reg_add_dword - CONFIG_REG_BASE;
+ aw_reg_add_dword - AMD_CONFIG_REG_BASE;
packets_vec[1].reg_data[0] = addrHi.u32All;
aw_reg_add_dword =
@@ -470,7 +470,7 @@ static int dbgdev_address_watch_diq(struct kfd_dbgdev
*dbgdev,
aw_reg_add_dword /= sizeof(uint32_t);
packets_vec[2].bitfields2.reg_offset =
- aw_reg_add_dword - CONFIG_REG_BASE;
+ aw_reg_add_dword - AMD_CONFIG_REG_BASE;
packets_vec[2].reg_data[0] = addrLo.u32All;
/* enable watch flag if address is not zero*/
@@ -488,7 +488,7 @@ static int dbgdev_address_watch_diq(struct kfd_dbgdev
*dbgdev,
aw_reg_add_dword /= sizeof(uint32_t);
packets_vec[3].bitfields2.reg_offset =
- aw_reg_add_dword - CONFIG_REG_BASE;
+ aw_reg_add_dword - AMD_CONFIG_REG_BASE;
packets_vec[3].reg_data[0] = cntl.u32All;
status = dbgdev_diq_submit_ib(
@@ -690,7 +690,7 @@ static int dbgdev_wave_control_diq(struct kfd_dbgdev
*dbgdev,
packets_vec[1].header.opcode = IT_SET_CONFIG_REG;
packets_vec[1].header.type = PM4_TYPE_3;
packets_vec[1].bitfields2.reg_offset = SQ_CMD / (sizeof(uint32_t)) -
- CONFIG_REG_BASE;
+ AMD_CONFIG_REG_BASE;
packets_vec[1].bitfields2.vmid_shift = SQ_CMD_VMID_OFFSET;
packets_vec[1].bitfields2.insert_vmid = 1;
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.h
b/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.h
index 4b0dd5aa5306..03424c20920c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.h
@@ -48,9 +48,9 @@ enum {
/* CONFIG reg space definition */
enum {
- CONFIG_REG_BASE = 0x2000, /* in dwords */
- CONFIG_REG_END = 0x2B00,
- CONFIG_REG_SIZE = CONFIG_REG_END - CONFIG_REG_BASE
+ AMD_CONFIG_REG_BASE = 0x2000, /* in dwords */
+ AMD_CONFIG_REG_END = 0x2B00,
+ AMD_CONFIG_REG_SIZE = AMD_CONFIG_REG_END - AMD_CONFIG_REG_BASE
};
/* SH reg space definition */
--
2.4.2
linux-next: manual merge of the drm tree with the drm-intel-fixes tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/i915/intel_ringbuffer.c between commit 4f47c99a9be7 ("drm/i915:
Move WaBarrierPerformanceFixDisable:skl to skl code from chv code") from the
drm-intel-fixes tree and commit b62adbd1ea1f ("drm/i915/bxt: Move
WaForceEnableNonCoherent to Skylake only") from the drm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
cheers
diff --cc drivers/gpu/drm/i915/intel_ringbuffer.c
index 005b5e04de4d,d934f857394d..
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@@ -1017,13 -1030,17 +1023,24 @@@ static int skl_init_workarounds(struct
WA_SET_BIT_MASKED(HIZ_CHICKEN,
BDW_HIZ_POWER_COMPILER_CLOCK_GATING_DISABLE);
+ if (INTEL_REVID(dev) == SKL_REVID_C0 ||
+ INTEL_REVID(dev) == SKL_REVID_D0)
+ /* WaBarrierPerformanceFixDisable:skl */
+ WA_SET_BIT_MASKED(HDC_CHICKEN0,
+HDC_FENCE_DEST_SLM_DISABLE |
+HDC_BARRIER_PERFORMANCE_DISABLE);
+
+ if (INTEL_REVID(dev) <= SKL_REVID_D0) {
+ /*
+*Use Force Non-Coherent whenever executing a 3D context. This
+* is a workaround for a possible hang in the unlikely event
+* a TLB invalidation occurs during a PSD flush.
+*/
+ /* WaForceEnableNonCoherent:skl */
+ WA_SET_BIT_MASKED(HDC_CHICKEN0,
+ HDC_FORCE_NON_COHERENT);
+ }
+
return skl_tune_iz_hashing(ring);
}
[PATCH v2 1/2] clk: change clk_ops' ->round_rate() prototype
Hi Paul, On Thu, 4 Jun 2015 23:02:25 + (UTC) Paul Walmsley wrote: > Hi folks > > just a brief comment on this one: > > On Thu, 30 Apr 2015, Boris Brezillon wrote: > > > Clock rates are stored in an unsigned long field, but ->round_rate() > > (which returns a rounded rate from a requested one) returns a long > > value (errors are reported using negative error codes), which can lead > > to long overflow if the clock rate exceed 2Ghz. > > > > Change ->round_rate() prototype to return 0 or an error code, and pass the > > requested rate as a pointer so that it can be adjusted depending on > > hardware capabilities. > > ... > > > diff --git a/Documentation/clk.txt b/Documentation/clk.txt > > index 0e4f90a..fca8b7a 100644 > > --- a/Documentation/clk.txt > > +++ b/Documentation/clk.txt > > @@ -68,8 +68,8 @@ the operations defined in clk.h: > > int (*is_enabled)(struct clk_hw *hw); > > unsigned long (*recalc_rate)(struct clk_hw *hw, > > unsigned long parent_rate); > > - long(*round_rate)(struct clk_hw *hw, > > - unsigned long rate, > > + int (*round_rate)(struct clk_hw *hw, > > + unsigned long *rate, > > unsigned long *parent_rate); > > long(*determine_rate)(struct clk_hw *hw, > > unsigned long rate, > > I'd suggest that we should probably go straight to 64-bit rates. There > are already plenty of clock sources that can generate rates higher than > 4GiHz. Yep, that was something I was considering too. If Stephen agrees I'll change that in the next version. BTW, you're referring to the second version of this patch, but things have changed a bit: Stephen recommended to only modify the ->determine_rate() prototype and pass a structure instead of a list of arguments. Here is the last version of this series [1]. Best Regards, Boris [1]http://patchwork.linux-mips.org/patch/10092/ -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[PATCH v2 1/2] clk: change clk_ops' ->round_rate() prototype
On 05/06/15 00:02, Paul Walmsley wrote: > Hi folks > > just a brief comment on this one: > > On Thu, 30 Apr 2015, Boris Brezillon wrote: > >> Clock rates are stored in an unsigned long field, but ->round_rate() >> (which returns a rounded rate from a requested one) returns a long >> value (errors are reported using negative error codes), which can lead >> to long overflow if the clock rate exceed 2Ghz. >> >> Change ->round_rate() prototype to return 0 or an error code, and pass the >> requested rate as a pointer so that it can be adjusted depending on >> hardware capabilities. > > ... > >> diff --git a/Documentation/clk.txt b/Documentation/clk.txt >> index 0e4f90a..fca8b7a 100644 >> --- a/Documentation/clk.txt >> +++ b/Documentation/clk.txt >> @@ -68,8 +68,8 @@ the operations defined in clk.h: >> int (*is_enabled)(struct clk_hw *hw); >> unsigned long (*recalc_rate)(struct clk_hw *hw, >> unsigned long parent_rate); >> -long(*round_rate)(struct clk_hw *hw, >> -unsigned long rate, >> +int (*round_rate)(struct clk_hw *hw, >> +unsigned long *rate, >> unsigned long *parent_rate); >> long(*determine_rate)(struct clk_hw *hw, >> unsigned long rate, > > I'd suggest that we should probably go straight to 64-bit rates. There > are already plenty of clock sources that can generate rates higher than > 4GiHz. An alternative would be to introduce to a frequency "base" the default could be Hz (for backwards compatibility), but for CPUs we probably only care about MHz (or may be kHz) and so 32-bits would still suffice. Even if CPUs cared about Hz they could still use Hz, but in that case they probably don't care about GHz. Obviously, we don't want to break DT compatibility but may be the frequency base could be defined in DT and if it is missing then Hz is assumed. Just a thought ... Jon
[PATCH v2 00/10] Color Manager Implementation
Hi Sonika, Thanks for your suggestion. Will follow that from next time. Regards Kausal On Friday 05 June 2015 09:31 AM, Jindal, Sonika wrote: > HI Kausal, > > You don't need to send the entire series again . > Just send the updated patch --in-reply-to to the last message. > Otherwise the thread gets lost. > > You can send the entire series once the review is complete and you feel that > the patches are too nested inside. > Please keep sending the patches using --in-reply-to tag. > > Regards, > Sonika > > -Original Message- > From: Malladi, Kausal > Sent: Thursday, June 4, 2015 7:13 PM > To: Roper, Matthew D; Barnes, Jesse; Lespiau, Damien; Jindal, Sonika; R, > Durgadoss; Purushothaman, Vijay A; intel-gfx at lists.freedesktop.org; > dri-devel at lists.freedesktop.org > Cc: Vetter, Daniel; Sharma, Shashank; Kamath, Sunil; Mukherjee, Indranil; > Matheson, Annie J; R, Dhanya p; Palleti, Avinash Reddy; Malladi, Kausal > Subject: [PATCH v2 00/10] Color Manager Implementation > > From: Kausal Malladi > > This patch set adds color manager implementation in drm/i915 layer. > Color Manager is an extension in i915 driver to support color > correction/enhancement. Various Intel platforms support several color > correction capabilities. Color Manager provides abstraction of these > properties and allows a user space UI agent to correct/enhance the display. > > The first three patches add code for the framework, which will be common > across all the Intel platforms. >drm/i915: Initialize Color Manager >drm/i915: Attach color properties to CRTC >drm/i915: Add Set property interface for CRTC > > In the next patches, we are adding support for Gamma and CSC color > properties. Please note that: > 1. The current implementation is only limited for CHV/BSW platforms, and the > support for > other platforms will be following up soon. > 2. The current patch set implements only the "set" part of the properties, > "get" part will > be following up soon. > > The design of color management on linux is done by: > Jesse Barnes > Sirisha Muppavarapu > Shashank Sharma > Susanta Bhattacharjee > > The complete design is explained in the design document, which is available > at > https://docs.google.com/document/d/1jyfNSAStKHEpmIUZd_1Gd68cPuyiyr8wmJXThSDb_2w/edit# > > v2: Addressed review comments from Sonika and Daniel Stone. > > Kausal Malladi (10): >drm/i915: Initialize Color Manager >drm/i915: Attach color properties to CRTC >drm/i915: Add atomic set property interface for CRTC >drm: Add Gamma correction structure >drm: Add a new function for updating color blob >drm: Avoid atomic commit path for CRTC property (Gamma) >drm/i915: Add pipe level Gamma correction for CHV/BSW >drm: Add CSC correction structure >drm: Avoid atomic commit path for CSC property on CRTC >drm/i915: Add CSC support for CHV/BSW > > drivers/gpu/drm/drm_atomic_helper.c| 18 +- > drivers/gpu/drm/drm_crtc.c | 15 ++ > drivers/gpu/drm/i915/Makefile | 3 + > drivers/gpu/drm/i915/intel_atomic.c| 19 +- > drivers/gpu/drm/i915/intel_color_manager.c | 348 > + drivers/gpu/drm/i915/intel_color_manager.h | > 122 ++ > drivers/gpu/drm/i915/intel_display.c | 8 + > drivers/gpu/drm/i915/intel_drv.h | 4 + > include/drm/drm_crtc.h | 12 + > include/uapi/drm/drm.h | 18 ++ > 10 files changed, 563 insertions(+), 4 deletions(-) create mode 100644 > drivers/gpu/drm/i915/intel_color_manager.c > create mode 100644 drivers/gpu/drm/i915/intel_color_manager.h > > -- > 2.4.2 >
[PATCH v2 1/2] clk: change clk_ops' ->round_rate() prototype
Hi Jon, On Fri, 5 Jun 2015 09:46:09 +0100 Jon Hunter wrote: > > On 05/06/15 00:02, Paul Walmsley wrote: > > Hi folks > > > > just a brief comment on this one: > > > > On Thu, 30 Apr 2015, Boris Brezillon wrote: > > > >> Clock rates are stored in an unsigned long field, but ->round_rate() > >> (which returns a rounded rate from a requested one) returns a long > >> value (errors are reported using negative error codes), which can lead > >> to long overflow if the clock rate exceed 2Ghz. > >> > >> Change ->round_rate() prototype to return 0 or an error code, and pass the > >> requested rate as a pointer so that it can be adjusted depending on > >> hardware capabilities. > > > > ... > > > >> diff --git a/Documentation/clk.txt b/Documentation/clk.txt > >> index 0e4f90a..fca8b7a 100644 > >> --- a/Documentation/clk.txt > >> +++ b/Documentation/clk.txt > >> @@ -68,8 +68,8 @@ the operations defined in clk.h: > >>int (*is_enabled)(struct clk_hw *hw); > >>unsigned long (*recalc_rate)(struct clk_hw *hw, > >>unsigned long parent_rate); > >> - long(*round_rate)(struct clk_hw *hw, > >> - unsigned long rate, > >> + int (*round_rate)(struct clk_hw *hw, > >> + unsigned long *rate, > >>unsigned long *parent_rate); > >>long(*determine_rate)(struct clk_hw *hw, > >>unsigned long rate, > > > > I'd suggest that we should probably go straight to 64-bit rates. There > > are already plenty of clock sources that can generate rates higher than > > 4GiHz. > > An alternative would be to introduce to a frequency "base" the default > could be Hz (for backwards compatibility), but for CPUs we probably only > care about MHz (or may be kHz) and so 32-bits would still suffice. Even > if CPUs cared about Hz they could still use Hz, but in that case they > probably don't care about GHz. Obviously, we don't want to break DT > compatibility but may be the frequency base could be defined in DT and > if it is missing then Hz is assumed. Just a thought ... Yes, but is it really worth the additional complexity. You'll have to add the unit information anyway, so using an unsigned long for the value and another field for the unit (an enum ?) is just like using a 64 bit integer. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[PATCH v2 04/10] drm: Add Gamma correction structure
Hi Sonika,
Please find my responses inline.
Thanks,
Kausal
On Friday 05 June 2015 05:30 PM, Jindal, Sonika wrote:
>
>
> On 6/4/2015 7:12 PM, Kausal Malladi wrote:
>> From: Kausal Malladi
>>
>> This patch adds a new structure in DRM layer for Gamma color correction.
>> This structure will be used by all user space agents to configure
>> appropriate Gamma precision and Gamma level.
>>
>> struct drm_intel_gamma {
>> __u32 gamma_level;
>> (The gamma_level variable indicates if the Gamma correction is to be
> Do you have any macro defines for these levels? Maybe an enum will be
> better?
Yes, we have macro defines for these. There are only two possible levels
(pipe/plane).
>> applied on Pipe/plane)
>> __u32 gamma_precision;
>> (The Gamma precision indicates the Gamma mode to be applied)
>>
>> Supported precisions are -
>> #define I915_GAMMA_PRECISION_UNKNOWN0
>> #define I915_GAMMA_PRECISION_CURRENT0x
>> #define I915_GAMMA_PRECISION_LEGACY(1 << 0)
>> #define I915_GAMMA_PRECISION_10BIT(1 << 1)
>> #define I915_GAMMA_PRECISION_12BIT(1 << 2)
>> #define I915_GAMMA_PRECISION_14BIT(1 << 3)
>> #define I915_GAMMA_PRECISION_16BIT(1 << 4)
>>
>> __u32 num_samples;
>> (The num_samples indicates the number of Gamma correction
>> coefficients)
>> __u32 reserved;
> You need this reserved?
In case any future platforms require any additional checks, we can use
this member. Having said that, yes.. we are currently not using it.
>> __u16 values[0];
>> (An array of size 0, to accommodate the "num_samples" number of
>> R16G16B16 pixels, dynamically)
>> };
>>
>> v2: Addressing Daniel Stone's comment, added a variable sized array to
>> carry Gamma correction values as blob property.
>>
>> Signed-off-by: Shashank Sharma
>> Signed-off-by: Kausal Malladi
>> ---
>> include/drm/drm_crtc.h | 3 +++
>> include/uapi/drm/drm.h | 10 ++
>> 2 files changed, 13 insertions(+)
>>
>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>> index 2a75d7d..bc44f27 100644
>> --- a/include/drm/drm_crtc.h
>> +++ b/include/drm/drm_crtc.h
>> @@ -483,6 +483,9 @@ struct drm_crtc {
>>* acquire context.
>>*/
>> struct drm_modeset_acquire_ctx *acquire_ctx;
>> +
> Just trying to understand, why do we need to store the blob id
> separately?
Saving Blob ID allows us to do a lookup of the blob using ID. This will
be useful in get_property call.
>> +/* Color Management Blob IDs */
>> +u32 gamma_blob_id;
>> };
>>
>> /**
>> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
>> index 3801584..fc2661c 100644
>> --- a/include/uapi/drm/drm.h
>> +++ b/include/uapi/drm/drm.h
>> @@ -829,6 +829,16 @@ struct drm_event_vblank {
>> __u32 reserved;
>> };
>>
>> +/* Color Management structure for Gamma */
>> +struct drm_gamma {
>> +__u32 flags;
>> +__u32 gamma_level;
>> +__u32 gamma_precision;
>> +__u32 num_samples;
>> +__u32 reserved;
>> +__u16 values[0];
>> +};
>> +
>> /* typedef area */
>> #ifndef __KERNEL__
>> typedef struct drm_clip_rect drm_clip_rect_t;
>>
[PATCH v3 1/2] drm/bridge: dw-hdmi: support optional supply regulators
On Fri, Jun 05, 2015 at 02:16:40PM +0200, Heiko Stübner wrote: > Hi Thierry > > Am Freitag, 5. Juni 2015, 13:02:01 schrieb Thierry Reding: > > On Mon, Mar 23, 2015 at 07:17:49PM +0100, Heiko Stuebner wrote: > > > Hi Philipp, > > > > > > Am Donnerstag, 12. März 2015, 21:45:19 schrieb Heiko Stuebner: > > > > At least the Rockchip variant of the dw_hdmi can have controllable power > > > > supplies providing 1.0 and 1.8V. Therefore add the possibility for the > > > > generic bridge driver to enable supplies provided by the hw-specific > > > > drivers. > > > > > > > > Signed-off-by: Heiko Stuebner > > > > > > does this look ok now? > > > > > > And as we talked about in Chemnitz, who will be taking such bridge-related > > > changes, as you mentioned some last bridge-patches going through Thierry. > > > > Sorry, I had completely missed this. > > > > > > --- > > > > changes since v2: > > > > - rename supplies to the names found in the hdmi IP databook > > > > changes since v1: > > > > - follow suggestion from Russell King to keep regulator handling local > > > > > > > > to the rockchip implementation for the time being and only generalize > > > > when a real second implementation needs regulator handling > > > > > > > > .../devicetree/bindings/drm/bridge/dw_hdmi.txt | 5 > > > > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 32 > > > > > > > > +- 2 files changed, 36 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt > > > > b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt index > > > > a905c14..bb74640 100644 > > > > --- a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt > > > > +++ b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt > > > > @@ -22,6 +22,11 @@ Optional properties > > > > > > > > - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing > > > > - clocks, clock-names: phandle to the HDMI CEC clock, name should be > > > > "cec" > > > > > > > > +Optional supplies: > > > > +rockchip,rk3288-dw-hdmi handles two optional power supplies: > > > > +- vp-supply: 1.0V power supply > > > > +- vph-supply: 1.8V power supply > > > > If this is specific to the Rockchip implementation, shouldn't this go > > into Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt? It > > could then simply go into the Rockchip DRM tree. > > actually, we determined that the supply names are universal to the IP (both > in > imx and rockchip and probably more if there are more users out there). Just > Russell requested that we don't pollute the generic code until necessary, as > it looks like the supply of those is somehow handled internally on the imx. If it's universal then there should be no need to mention the Rockchip compatible specifically. Also, it might be better to submit this as two separate patches, one for the binding and another for the driver. I could extract the DT binding piece myself and apply only that, then somebody else can apply the Rockchip change to that driver separately. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150605/67ff55f7/attachment-0001.sig>
[PATCH] drm/panel: Add display timing for Okaya RS800480T-7X0GP
On Thu, May 28, 2015 at 05:37:46PM +0200, Gary Bisson wrote:
> Add support for the Okaya RS800480T-7X0GP to the DRM simple panel
> driver.
>
> The RS800480T-7X0GP is a WVGA (800x480) panel with an 18-bit parallel
> LCD interface. It supports pixel clocks in the range of 30-40 MHz.
>
> This panel details can be found at:
> http://boundarydevices.com/product/7-800x480-display/
>
> Signed-off-by: Gary Bisson
> ---
> Hi all,
>
> This patch is the follow-up of a request from Philipp to add the Okaya display
> to the simple panel driver.
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/346657.html
>
> Regards,
> Gary
> ---
> .../bindings/panel/okaya,rs800480t_7x0gp.txt | 7 ++
> .../devicetree/bindings/vendor-prefixes.txt| 1 +
> drivers/gpu/drm/panel/panel-simple.c | 27
> ++
> 3 files changed, 35 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/panel/okaya,rs800480t_7x0gp.txt
>
> diff --git
> a/Documentation/devicetree/bindings/panel/okaya,rs800480t_7x0gp.txt
> b/Documentation/devicetree/bindings/panel/okaya,rs800480t_7x0gp.txt
> new file mode 100644
> index 000..f7c729d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/okaya,rs800480t_7x0gp.txt
> @@ -0,0 +1,7 @@
> +OKAYA Electric America, Inc. RS800480T-7X0GP 7" WVGA LCD panel
> +
> +Required properties:
> +- compatible: should be "okaya,rs800480t_7x0gp"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 4f35a00..06ce91c 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -145,6 +145,7 @@ nintendo Nintendo
> nokiaNokia
> nvidia NVIDIA
> nxp NXP Semiconductors
> +okayaOKAYA Electric America, Inc.
> onnn ON Semiconductor Corp.
> opencoresOpenCores.org
> ortustechOrtus Technology Co., Ltd.
Can you split this change into a separate patch? It needs an Acked-by
from one of the device tree binding maintainers, so make sure to Cc them
when you repost. scripts/get_maintainer.pl will list them for you.
> +static const struct display_timing okaya_rs800480t_7x0gp_timing = {
> + .pixelclock = { 3000, 3000, 4000 },
> + .hactive = { 800, 800, 800 },
> + .hfront_porch = { 40, 40, 40 },
> + .hback_porch = { 40, 40, 40 },
> + .hsync_len = { 1, 48, 48 },
> + .vactive = { 480, 480, 480 },
> + .vfront_porch = { 13, 13, 13 },
> + .vback_porch = { 29, 29, 29 },
> + .vsync_len = { 3, 3, 3 },
It strikes me as odd that the porches and VSYNC width should be fixed
for the panel. Is this really the case?
Thierry
-- next part ------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150605/1937fb44/attachment.sig>
[PULL] drm-intel-fixes
Hi Dave, sorry I'm late with the fixes pull and I see you already sent yours forward to Linus too. If you get the vibes there might be a release this weekend, would be nice to get these in. Otherwise can wait until next week, and I might have a few more on top then. BR, Jani. The following changes since commit c65b99f046843d2455aa231747b5a07a999a9f3d: Linux 4.1-rc6 (2015-05-31 19:01:07 -0700) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-06-05 for you to fetch changes up to 4f47c99a9be7e9b90a7f3c2c4599ea6b7c2ec49d: drm/i915: Move WaBarrierPerformanceFixDisable:skl to skl code from chv code (2015-06-04 14:15:45 +0300) Ander Conselvan de Oliveira (1): drm/i915: Include G4X/VLV/CHV in self refresh status Arun Siluvery (1): drm/i915: Initialize HWS page address after GPU reset Jim Bride (1): drm/i915/hsw: Fix workaround for server AUX channel clock divisor Ville Syrjälä (2): drm/i915: Don't skip request retirement if the active list is empty drm/i915: Move WaBarrierPerformanceFixDisable:skl to skl code from chv code drivers/gpu/drm/i915/i915_debugfs.c | 5 - drivers/gpu/drm/i915/i915_gem.c | 3 --- drivers/gpu/drm/i915/intel_dp.c | 5 ++--- drivers/gpu/drm/i915/intel_lrc.c| 6 ++ drivers/gpu/drm/i915/intel_ringbuffer.c | 14 +++--- 5 files changed, 19 insertions(+), 14 deletions(-) -- Jani Nikula, Intel Open Source Technology Center
[GIT PULL] tilcdc DRM refactoring (again)
David, Please pull the contents of "Use DRM component API in tilcdc to connect to tda998x" patch series[1] from: https://github.com/jsarha/linux.git linux-4.1.0-rc6-tilcdc-refactor These are the same commits I sent a pull request for already sometime earlier. They have just been rebased on top of 4.1-rc6 and tested. This time there are no DTS patches slipped into the series and all apply to drm/tilcdc. The commits are all acked-by Tomi Valkeinen. The commits: c83ce67 drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT f717447 drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti,tilcdc,slave binding support ff61c6a drm/tilcdc: use pm_runtime_irq_safe() 55d5d04 drm/tilcdc: Add support for external tda998x encoder fa6710f drm/tilcdc: Remove tilcdc slave support for tda998x driver bfa2b83 drm/tilcdc: Fix module unloading The relevant patch review and patches can be found here: http://lists.freedesktop.org/archives/dri-devel/2015-May/083619.html Best regards, Jyri
Etnaviv DRM driver userspace support?
Hi 2015-06-05 9:36 GMT+02:00 Kimmo Saarela : > I have tried to look through archives but couldn't find answer where I > should look for userspace components (libdrm, mesa) for the etnaviv drm > driver? > At the moment there is only a ddx for the 2D core, which works very well. http://ftp.arm.linux.org.uk/cgit/xf86-video-armada.git/ (branch: unstable-devel) > At the moment I have kernel 4.1-rc6 running with these [1] imx-drm patches > on riotBoard with custom lvds display, display is working fine, but only > with SW rendering. > dmesg shows that etnaviv-gpu has found GC320 and GC880 units. > The mesa/libdrm stuff is in active development but currently not in any public git tree. I hope to see initial support for 3d to land in mesa/libdrm at the end of this year. greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner
[Bug 90873] GPU hang, TearFree On, Mate desktop environment
https://bugs.freedesktop.org/show_bug.cgi?id=90873 Bug ID: 90873 Summary: GPU hang, TearFree On, Mate desktop environment Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: neatnoise at gmail.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 116320 --> https://bugs.freedesktop.org/attachment.cgi?id=116320&action=edit dmesg Hello, I experience GPU hang while TearFree option is on. Logs are in the attachments. Without TearFree option is okay. I've tested TearFree when this feature was introduced in git version of xf86-video-ati-git and I didn't experience GPU hang back then. GPU: Radeon 7790 OS: Arch Linux, latest RC version kernel mesa-git, llvm-svn, xf86-video-ati-git Desktop environment: Mate 1.8 Best regards -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150605/5b1d54d6/attachment.html>
[Bug 90873] GPU hang, TearFree On, Mate desktop environment
https://bugs.freedesktop.org/show_bug.cgi?id=90873 --- Comment #1 from Tom --- Created attachment 116321 --> https://bugs.freedesktop.org/attachment.cgi?id=116321&action=edit xorg -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150605/3b390dd8/attachment.html>
[Bug 90873] GPU hang, TearFree On, Mate desktop environment
https://bugs.freedesktop.org/show_bug.cgi?id=90873 --- Comment #2 from Tom --- Created attachment 116322 --> https://bugs.freedesktop.org/attachment.cgi?id=116322&action=edit xorg.conf -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150605/94943175/attachment.html>
[PATCH v4 1/3] dt-bindings: describe dw_hdmi supplies
The Designware HDMI block has two supplies for 1.0 and 1.8V. Not all IP
implementations expose or want to use these, so they remain optional.
Signed-off-by: Heiko Stuebner
Acked-by: Philipp Zabel
---
changes since v3:
- split generic dt-bindings and rockchip implementation
- add Ack from Philipp Zabel
changes since v2:
- rename supplies to the names found in the hdmi IP databook
Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
index a905c14..ba42d89 100644
--- a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
+++ b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
@@ -22,6 +22,10 @@ Optional properties
- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec"
+Optional supplies:
+- vp-supply: 1.0V power supply
+- vph-supply: 1.8V power supply
+
Example:
hdmi: hdmi at 012 {
compatible = "fsl,imx6q-hdmi";
--
2.1.4
[PATCH v4 2/3] drm/rockchip: implement dw_hdmi supplies for the Rockchip implementation
The Rockchip implementation of the IP exposes the supplies outside and
expects them to be supplied by a pmic. So implement regulator handling
for them.
Signed-off-by: Heiko Stuebner
Acked-by: Philipp Zabel
---
changes since v3:
- split generic dt-bindings and rockchip implementation
- add Ack from Philipp Zabel
changes since v2:
- rename supplies to the names found in the hdmi IP databook
changes since v1:
- follow suggestion from Russell King to keep regulator handling local
to the rockchip implementation for the time being and only generalize
when a real second implementation needs regulator handling
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 32 -
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 80d6fc8..9c003fa 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -28,6 +29,9 @@ struct rockchip_hdmi {
struct device *dev;
struct regmap *regmap;
struct drm_encoder encoder;
+ struct regulator_bulk_data supplies[2];
+ int nsupplies;
+ bool supplies_enabled;
};
#define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
@@ -179,6 +183,12 @@ static struct drm_encoder_funcs
dw_hdmi_rockchip_encoder_funcs = {
static void dw_hdmi_rockchip_encoder_disable(struct drm_encoder *encoder)
{
+ struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
+
+ if (hdmi->nsupplies > 0 && hdmi->supplies_enabled) {
+ regulator_bulk_disable(hdmi->nsupplies, hdmi->supplies);
+ hdmi->supplies_enabled = false;
+ }
}
static bool
@@ -199,7 +209,16 @@ static void dw_hdmi_rockchip_encoder_commit(struct
drm_encoder *encoder)
{
struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
u32 val;
- int mux;
+ int mux, ret;
+
+ if (hdmi->nsupplies > 0 && !hdmi->supplies_enabled) {
+ ret = regulator_bulk_enable(hdmi->nsupplies, hdmi->supplies);
+ if (ret) {
+ dev_err(hdmi->dev, "could not enable hdmi analog
supplies\n");
+ return;
+ }
+ hdmi->supplies_enabled = true;
+ }
mux = rockchip_drm_encoder_get_mux_id(hdmi->dev->of_node, encoder);
if (mux)
@@ -275,6 +294,17 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
struct device *master,
if (!iores)
return -ENXIO;
+ hdmi->supplies[0].supply = "vp";
+ hdmi->supplies[1].supply = "vph";
+ hdmi->nsupplies = 2;
+
+ ret = devm_regulator_bulk_get(hdmi->dev,
+ hdmi->nsupplies, hdmi->supplies);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ if (ret)
+ hdmi->nsupplies = 0;
+
platform_set_drvdata(pdev, hdmi);
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
--
2.1.4
[PATCH v4 3/3] ARM: dts: rockchip: add hdmi analog power supplies to rk3288 boards
Add the recently added hdmi power supplies to evb and firefly boards.
Signed-off-by: Heiko Stuebner
---
changes since v3:
- add entries for popmetal board
arch/arm/boot/dts/rk3288-evb.dtsi | 2 ++
arch/arm/boot/dts/rk3288-firefly.dtsi | 2 ++
arch/arm/boot/dts/rk3288-popmetal.dts | 2 ++
3 files changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi
b/arch/arm/boot/dts/rk3288-evb.dtsi
index 844a6fb..a57fbe3 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -172,6 +172,8 @@
};
&hdmi {
ddc-i2c-bus = <&i2c5>;
+ vp-supply = <&vdd10_lcd>;
+ vph-supply = <&vcc18_lcd>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi
b/arch/arm/boot/dts/rk3288-firefly.dtsi
index 0b42372..68068d9 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
@@ -196,6 +196,8 @@
};
&hdmi {
ddc-i2c-bus = <&i2c5>;
+ vp-supply = <&vdd10_lcd>;
+ vph-supply = <&vcc18_lcd>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/rk3288-popmetal.dts
b/arch/arm/boot/dts/rk3288-popmetal.dts
index d582811..98f4d77 100644
--- a/arch/arm/boot/dts/rk3288-popmetal.dts
+++ b/arch/arm/boot/dts/rk3288-popmetal.dts
@@ -141,6 +141,8 @@
&hdmi {
ddc-i2c-bus = <&i2c5>;
+ vp-supply = <&vdd10_lcd>;
+ vph-supply = <&vcc18_lcd>;
status = "okay";
};
--
2.1.4
Help on drmModeSetPlane
On Thu, Jun 04, 2015 at 04:59:41AM +, Xie, William wrote: > Hi > Does anyone know what the result value of "-34" means returned by > drmModeSetPlane? > > William -34 is -ERANGE which generally gets raised if you request scaling that your hardware (or driver) can't support. Not all platforms are capable of performing scaling and those that do support it generally have limits. You can also get an -ERANGE return if your coordinates could cause an integer overflow (e.g., coordinates with values near INT_MAX). Matt -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795
[PATCH] drm/radeon: fix freeze for laptop with Turks/Thames GPU.
From: Jérôme Glisse
Laptop with Turks/Thames GPU will freeze if dpm is enabled. It seems
the SMC engine is relying on some state inside the CP engine. CP needs
to chew at least one packet for it to get in good state for dynamic
power management.
This patch simply disabled and re-enable DPM after the ring test which
is enough to avoid the freeze.
Signed-off-by: Jérôme Glisse
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_device.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index b7ca4c5..a7fdfa4 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1463,6 +1463,21 @@ int radeon_device_init(struct radeon_device *rdev,
if (r)
DRM_ERROR("ib ring test failed (%d).\n", r);
+ /*
+* Turks/Thames GPU will freeze whole laptop if DPM is not restarted
+* after the CP ring have chew one packet at least. Hence here we stop
+* and restart DPM after the radeon_ib_ring_tests().
+*/
+ if (rdev->pm.dpm_enabled &&
+ (rdev->pm.pm_method == PM_METHOD_DPM) &&
+ (rdev->family == CHIP_TURKS) &&
+ (rdev->flags & RADEON_IS_MOBILITY)) {
+ mutex_lock(&rdev->pm.mutex);
+ radeon_dpm_disable(rdev);
+ radeon_dpm_enable(rdev);
+ mutex_unlock(&rdev->pm.mutex);
+ }
+
if ((radeon_testing & 1)) {
if (rdev->accel_working)
radeon_test_moves(rdev);
--
1.7.1
[PATCH] drm: fix writing to /sys/class/drm/*/status
Writing to a file is supposed to return the number of bytes written.
Returning zero unfortunately causes bash to constantly spin trying
to write to the sysfs file, to such an extent that even ^c and ^z
have no effect. The only way out of that is to kill the shell and
log back in. This isn't nice behaviour.
Fix it by returning the number of characters written to sysfs files.
Signed-off-by: Russell King
---
drivers/gpu/drm/drm_sysfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index ffc305fc2076..e7e7edeee9fb 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -181,6 +181,8 @@ static ssize_t status_store(struct device *device,
old_status = connector->status;
+ ret = count;
+
if (sysfs_streq(buf, "detect")) {
connector->force = 0;
connector->status = connector->funcs->detect(connector, true);
@@ -193,7 +195,7 @@ static ssize_t status_store(struct device *device,
} else
ret = -EINVAL;
- if (ret == 0 && connector->force) {
+ if (ret >= 0 && connector->force) {
if (connector->force == DRM_FORCE_ON ||
connector->force == DRM_FORCE_ON_DIGITAL)
connector->status = connector_status_connected;
--
2.1.0
[Bug 90869] Rendering bug in The Witcher
https://bugs.freedesktop.org/show_bug.cgi?id=90869 --- Comment #2 from Matteo Bruni --- This is probably Wine bug 25696 / 34052. Read https://bugs.winehq.org/show_bug.cgi?id=34052#c42 for an explanation of that bug (essentially, the vertex shader reads out of bounds of a uniform array). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150605/05671137/attachment.html>
[PATCH] drm: fix writing to /sys/class/drm/*/status
On Fri, Jun 05, 2015 at 07:47:22PM +0100, Russell King wrote: > Writing to a file is supposed to return the number of bytes written. > Returning zero unfortunately causes bash to constantly spin trying > to write to the sysfs file, to such an extent that even ^c and ^z > have no effect. The only way out of that is to kill the shell and > log back in. This isn't nice behaviour. > > Fix it by returning the number of characters written to sysfs files. > > Signed-off-by: Russell King Oops. Fixes: c484f02d0f02fbbfc6decc945a69aae011041a27 Reviewed-by: Chris Wilson Dave, we need this for 4.1... -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH 29/88] drm/amdgpu: add amdgpu uapi header (v4)
On Tue, May 26, 2015 at 11:19:31PM -0400, Alex Deucher wrote: > This header defines the ioctl interface to the driver. > > v2: remove stale tiling defines > v3: add appropriate padding > v4: remove executable bits on header > > Acked-by: Christian König > Acked-by: Jammy Zhou > Signed-off-by: Alex Deucher > --- > include/uapi/drm/amdgpu_drm.h | 590 > ++ > 1 file changed, 590 insertions(+) > create mode 100644 include/uapi/drm/amdgpu_drm.h > > diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h > new file mode 100644 > index 000..9e771fb > --- /dev/null > +++ b/include/uapi/drm/amdgpu_drm.h > @@ -0,0 +1,590 @@ > +/* amdgpu_drm.h -- Public header for the amdgpu driver -*- linux-c -*- > + * > + * Copyright 2000 Precision Insight, Inc., Cedar Park, Texas. > + * Copyright 2000 VA Linux Systems, Inc., Fremont, California. > + * Copyright 2002 Tungsten Graphics, Inc., Cedar Park, Texas. > + * Copyright 2014 Advanced Micro Devices, Inc. > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > + * OTHER DEALINGS IN THE SOFTWARE. > + * > + * Authors: > + *Kevin E. Martin > + *Gareth Hughes > + *Keith Whitwell > + */ > + > +#ifndef __AMDGPU_DRM_H__ > +#define __AMDGPU_DRM_H__ > + > +#include > + > +#define DRM_AMDGPU_GEM_CREATE0x00 > +#define DRM_AMDGPU_GEM_MMAP 0x01 > +#define DRM_AMDGPU_CTX 0x02 > +#define DRM_AMDGPU_BO_LIST 0x03 > +#define DRM_AMDGPU_CS0x04 > +#define DRM_AMDGPU_INFO 0x05 > +#define DRM_AMDGPU_GEM_METADATA 0x06 > +#define DRM_AMDGPU_GEM_WAIT_IDLE 0x07 > +#define DRM_AMDGPU_GEM_VA0x08 > +#define DRM_AMDGPU_WAIT_CS 0x09 > +#define DRM_AMDGPU_GEM_OP0x10 > +#define DRM_AMDGPU_GEM_USERPTR 0x11 > + > +#define DRM_IOCTL_AMDGPU_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + > DRM_AMDGPU_GEM_CREATE, union drm_amdgpu_gem_create) > +#define DRM_IOCTL_AMDGPU_GEM_MMAPDRM_IOWR(DRM_COMMAND_BASE + > DRM_AMDGPU_GEM_MMAP, union drm_amdgpu_gem_mmap) > +#define DRM_IOCTL_AMDGPU_CTX DRM_IOWR(DRM_COMMAND_BASE + > DRM_AMDGPU_CTX, union drm_amdgpu_ctx) > +#define DRM_IOCTL_AMDGPU_BO_LIST DRM_IOWR(DRM_COMMAND_BASE + > DRM_AMDGPU_BO_LIST, union drm_amdgpu_bo_list) > +#define DRM_IOCTL_AMDGPU_CS DRM_IOWR(DRM_COMMAND_BASE + > DRM_AMDGPU_CS, union drm_amdgpu_cs) > +#define DRM_IOCTL_AMDGPU_INFODRM_IOW(DRM_COMMAND_BASE + > DRM_AMDGPU_INFO, struct drm_amdgpu_info) > +#define DRM_IOCTL_AMDGPU_GEM_METADATADRM_IOWR(DRM_COMMAND_BASE + > DRM_AMDGPU_GEM_METADATA, struct drm_amdgpu_gem_metadata) > +#define DRM_IOCTL_AMDGPU_GEM_WAIT_IDLE DRM_IOWR(DRM_COMMAND_BASE + > DRM_AMDGPU_GEM_WAIT_IDLE, union drm_amdgpu_gem_wait_idle) > +#define DRM_IOCTL_AMDGPU_GEM_VA DRM_IOWR(DRM_COMMAND_BASE + > DRM_AMDGPU_GEM_VA, union drm_amdgpu_gem_va) > +#define DRM_IOCTL_AMDGPU_WAIT_CS DRM_IOWR(DRM_COMMAND_BASE + > DRM_AMDGPU_WAIT_CS, union drm_amdgpu_wait_cs) > +#define DRM_IOCTL_AMDGPU_GEM_OP DRM_IOWR(DRM_COMMAND_BASE + > DRM_AMDGPU_GEM_OP, struct drm_amdgpu_gem_op) > +#define DRM_IOCTL_AMDGPU_GEM_USERPTR DRM_IOWR(DRM_COMMAND_BASE + > DRM_AMDGPU_GEM_USERPTR, struct drm_amdgpu_gem_userptr) > + > +#define AMDGPU_GEM_DOMAIN_CPU0x1 > +#define AMDGPU_GEM_DOMAIN_GTT0x2 > +#define AMDGPU_GEM_DOMAIN_VRAM 0x4 > +#define AMDGPU_GEM_DOMAIN_GDS0x8 > +#define AMDGPU_GEM_DOMAIN_GWS0x10 > +#define AMDGPU_GEM_DOMAIN_OA 0x20 Can we get a description on this new domains (GDS, GWS, OA) ? > + > +#define AMDGPU_GEM_DOMAIN_MASK 0x3F > + > +/* Flag that CPU access will be required for the case of VRAM domain */ > +#define AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED(1 << 0) > +/* Flag that CPU access will not
[pull] amdgpu drm-next-4.2
On Wed, Jun 03, 2015 at 09:48:31PM -0400, Alex Deucher wrote: > Hi Dave, > > This is the big pull request for amdgpu, the new driver for VI+ AMD > asics. I currently supports Tonga, Iceland, and Carrizo and also > contains a Kconfig option to build support for CI parts for testing. > > All major functionality is supported (displays, gfx, compute, dma, > video decode/encode, etc.). Power management is working on Carrizo, > but is still being worked on for Tonga and Iceland. I commented on the user api bit (ioctl) and i would like to have fixes for my comment, i mean it's mostly missing definition. All entry point seems to properly safety check ioctl parameters. So it looks good on that front. Also, like on radeon, this does not seems to be safe against fence seq wrap around. I know 64bits require a long uptime. But this might be something we will want to fix. I like the bo_list thing a lot and i would probably have avoided the chunk stuff for cs. But otherwise it mostly looks good from reading the code. Cheers, Jérôme > > The usermode bits are available in the following repositories: > libdrm: > http://cgit.freedesktop.org/~agd5f/drm/log/?h=amdgpu > mesa: > http://cgit.freedesktop.org/~agd5f/mesa/log/?h=amdgpu > ddx: > http://cgit.freedesktop.org/xorg/driver/xf86-video-amdgpu > > The following changes since commit 63e1456122761745082d325329ccce749a426059: > > Merge branch 'virtio-gpu-drm-next' of git://git.kraxel.org/linux into > drm-next (2015-06-04 09:36:39 +1000) > > are available in the git repository at: > > > git://people.freedesktop.org/~agd5f/linux drm-next-4.2-amdgpu > > for you to fetch changes up to 3ccec53c294cbec2af44b6b24f70349637c45428: > > drm/amdgpu: only support IBs in the buffer list (v2) (2015-06-03 21:04:05 > -0400) > > > Alex Deucher (52): > drm/amdgpu: add BIF 4.1 register headers > drm/amdgpu: add BIF 5.0 register headers > drm/amdgpu: add BIF 5.1 register headers > drm/amdgpu: add DCE 8.0 register headers > drm/amdgpu: add DCE 10.0 register headers > drm/amdgpu: add DCE 11.0 register headers > drm/amdgpu: add GCA 7.0 register headers > drm/amdgpu: add GCA 7.2 register headers > drm/amdgpu: add GCA 8.0 register headers > drm/amdgpu: add GMC 7.0 register headers > drm/amdgpu: add GMC 7.1 register headers > drm/amdgpu: add GMC 8.1 register headers > drm/amdgpu: add GMC 8.2 register headers > drm/amdgpu: add OSS 2.0 register headers > drm/amdgpu: add OSS 2.4 register headers > drm/amdgpu: add OSS 3.0 register headers > drm/amdgpu: add OSS 3.0.1 register headers > drm/amdgpu: add SMU 7.0.0 register headers > drm/amdgpu: add SMU 7.0.1 register headers > drm/amdgpu: add SMU 7.1.0 register headers > drm/amdgpu: add SMU 7.1.1 register headers > drm/amdgpu: add SMU 7.1.2 register headers > drm/amdgpu: add SMU 8.0 register headers > drm/amdgpu: add UVD 4.2 register headers > drm/amdgpu: add UVD 5.0 register headers > drm/amdgpu: add UVD 6.0 register headers > drm/amdgpu: add VCE 2.0 register headers > drm/amdgpu: add VCE 3.0 register headers > drm/amdgpu: add amdgpu uapi header (v4) > drm/amdgpu: add atombios headers > drm/amdgpu: add clearstate_defs.h > drm/amdgpu: add ppsmc.h > drm/amdgpu: add amdgpu_family.h > drm/amdgpu: add amdgpu.h (v2) > drm/amdgpu: add core driver (v4) > drm/amdgpu: fix const warnings in amdgpu_connectors.c > drm/amdgpu: Do not directly dereference pointers to BIOS area. > drm/amdgpu: Add support for CIK parts > drm/amdgpu: Add initial VI support > drm/amdgpu: add CIK pci ids > drm/amdgpu: add VI pci ids > drm/amdgpu: drop ttm two ended allocation > drm/amdgpu: fix error handling in cz_dpm_hw_fini/cz_dpm_suspend > drm/amdgpu: memset gds_info struct in info ioctl > drm/amdgpu: add new bonaire pci id > drm/amdgpu: add some new tonga pci ids > drm/amdgpu: take the mode_config mutex when handling hpds > drm/amdgpu: make some DP parameters const > drm/amdgpu: simplify DPCD debug output > drm/amdgpu: retry dcpd fetch > drm/amdgpu: remove unused TRACE_SYSTEM_STRING define > drm/amdgpu: fix description of vm_size module parameter (v2) > > Christian König (15): > drm/amdgpu: fix userptr lockup > drm/amdgpu: always emit GDS switch > drm/amdgpu: cleanup HDP flush handling > drm/amdgpu: fix dereference before check > drm/amdgpu: fix context switch > drm/amdgpu: fix VM_CONTEXT*_PAGE_TABLE_END_ADDR handling > drm/amdgpu: enforce AMDGPU_GEM_CREATE_NO_CPU_ACCESS > drm/amdgpu: validate amdgpu_vm_bo_map parameters > drm/amdgpu: actually use the VM map parameters > drm/amdgpu: port fault_reserve_notify changes from radeon >
[PATCH] drm: fix writing to /sys/class/drm/*/status
On Fri, Jun 05, 2015 at 07:56:38PM +0100, Chris Wilson wrote: > On Fri, Jun 05, 2015 at 07:47:22PM +0100, Russell King wrote: > > Writing to a file is supposed to return the number of bytes written. > > Returning zero unfortunately causes bash to constantly spin trying > > to write to the sysfs file, to such an extent that even ^c and ^z > > have no effect. The only way out of that is to kill the shell and > > log back in. This isn't nice behaviour. > > > > Fix it by returning the number of characters written to sysfs files. > > > > Signed-off-by: Russell King > > Oops. > > Fixes: c484f02d0f02fbbfc6decc945a69aae011041a27 > Reviewed-by: Chris Wilson > > Dave, we need this for 4.1... Viro suggests an alternative, simpler fix: diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c index ffc305fc2076..eb7e61078a5b 100644 --- a/drivers/gpu/drm/drm_sysfs.c +++ b/drivers/gpu/drm/drm_sysfs.c @@ -217,7 +217,7 @@ static ssize_t status_store(struct device *device, mutex_unlock(&dev->mode_config.mutex); - return ret; + return ret ? ret : count; } static ssize_t status_show(struct device *device, Would you prefer this one? -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
[PATCH 1/3] drm/nouveau: Use drm_vblank_on/off consistently
On 05/29/2015 07:35 PM, Daniel Vetter wrote: > On Fri, May 29, 2015 at 07:23:35PM +0200, Mario Kleiner wrote: >> >> >> On 05/29/2015 07:19 PM, Daniel Vetter wrote: >>> On Fri, May 29, 2015 at 06:50:06PM +0200, Mario Kleiner wrote: On 05/27/2015 11:04 AM, Daniel Vetter wrote: > In > > commit 9cba5efab5a8145ae6c52ea273553f069c294482 > Author: Mario Kleiner > Date: Tue Jul 29 02:36:44 2014 +0200 > > drm/nouveau: Dis/Enable vblank irqs during suspend/resume > > drm_vblank_on/off calls where added around suspend/resume to make sure > vblank stay doesn't go boom over that transition. But nouveau already > used drm_vblank_pre/post_modeset over modesets. Instead use > drm_vblank_on/off everyhwere. The slight change here is that after > _off drm_vblank_get will refuse to work right away, but nouveau > doesn't seem to depend upon that anywhere outside of the pageflip > paths. > > The longer-term plan here is to switch all kms drivers to > drm_vblank_on/off so that common code like pending event cleanup can > be done there, while drm_vblank_pre/post_modeset will be purely > drm internal for the old UMS ioctl. > > Note that the drm_vblank_off still seems required in the suspend path > since nouveau doesn't explicitly disable crtcs. But on the resume side > drm_helper_resume_force_mode should end up calling drm_vblank_on > through the nouveau crtc hooks already. Hence remove the call in the > resume code. > > Cc: Mario Kleiner > Cc: Ben Skeggs > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_display.c | 4 > 2 files changed, 2 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c > b/drivers/gpu/drm/nouveau/dispnv04/crtc.c > index 3d96b49fe662..dab24066fa21 100644 > --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c > +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c > @@ -708,7 +708,7 @@ static void nv_crtc_prepare(struct drm_crtc *crtc) > if (nv_two_heads(dev)) > NVSetOwner(dev, nv_crtc->index); > > - drm_vblank_pre_modeset(dev, nv_crtc->index); > + drm_vblank_off(dev, nv_crtc->index); > funcs->dpms(crtc, DRM_MODE_DPMS_OFF); > > NVBlankScreen(dev, nv_crtc->index, true); > @@ -740,7 +740,7 @@ static void nv_crtc_commit(struct drm_crtc *crtc) > #endif > > funcs->dpms(crtc, DRM_MODE_DPMS_ON); > - drm_vblank_post_modeset(dev, nv_crtc->index); > + drm_vblank_on(dev, nv_crtc->index); > } The above hunk is probably correct, but i couldn't test it without sufficiently old pre-nv 50 hardware. > > static void nv_crtc_destroy(struct drm_crtc *crtc) > diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c > b/drivers/gpu/drm/nouveau/nouveau_display.c > index 8670d90cdc11..d824023f9fc6 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_display.c > +++ b/drivers/gpu/drm/nouveau/nouveau_display.c > @@ -620,10 +620,6 @@ nouveau_display_resume(struct drm_device *dev, bool > runtime) > nv_crtc->lut.depth = 0; > } > > - /* Make sure that drm and hw vblank irqs get resumed if needed. */ > - for (head = 0; head < dev->mode_config.num_crtc; head++) > - drm_vblank_on(dev, head); > - > /* This should ensure we don't hit a locking problem when > someone >* wakes us up via a connector. We should never go into suspend >* while the display is on anyways. > Tested this one and this hunk breaks suspend/resume. After a suspend/resume cycle, all OpenGL apps and composited desktop are dead, as the core can't get any vblank irq's enabled anymore. So the drm_vblank_on() is still needed here. >>> >>> Hm that's very surprising. As mentioned above the force_mode_restore >>> should be calling nv_crtc_prepare already and fix this all up for us. I >>> guess I need to dig out my nv card and trace what's really going on here. >>> >>> Enabling interrupts when the crtc is off isn't a good idea. >>> -Daniel >>> >> >> I think the nv_crtc_prepare() path modified in your first hunk is only for >> the original nv04 display engine for very old cards. nv50+ (GeForce-8 and >> later) take different paths. > > Oh right totally missed the nv50+ code. I only grepped for > pre/post_modeset ... > > Below untested diff should help. I also realized that the pre-nv50 code > lacks drm_vblank_on/off in the dpms callback, so there's more work to do > anyway for this one here. > > Thanks, Daniel > The diff on top of your patch is now tested and helps. suspend->resume is now fine on nv50. In your patch, nouveau_display_resume() would also need to get a now unused "int head"
[PATCH v2 01/10] drm/i915: Initialize Color Manager
On Thu, Jun 04, 2015 at 07:12:32PM +0530, Kausal Malladi wrote:
> From: Kausal Malladi
>
> Color Manager is an extension in i915 driver to handle color correction
> and enhancements across various Intel platforms.
>
> This patch initializes color manager framework by :
> 1. Adding two new files, intel_color_manager(.c/.h)
> 2. Introducing new pointers in DRM mode_config structure to
>carry CSC and Gamma color correction properties.
> 3. Creating these DRM properties in Color Manager initialization
>sequence.
>
> v2: Addressing Sonika's review comment.
> 1. Made intel_color_manager_init void
> 2. Moved init after NUM_PIPES check
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
> ---
> drivers/gpu/drm/i915/Makefile | 3 ++
> drivers/gpu/drm/i915/intel_color_manager.c | 48
> ++
> drivers/gpu/drm/i915/intel_color_manager.h | 32
> drivers/gpu/drm/i915/intel_display.c | 3 ++
> include/drm/drm_crtc.h | 4 +++
> 5 files changed, 90 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/intel_color_manager.c
> create mode 100644 drivers/gpu/drm/i915/intel_color_manager.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index b7ddf48..c62d048 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -89,6 +89,9 @@ i915-y += i915_vgpu.o
> # legacy horrors
> i915-y += i915_dma.o
>
> +# Color Management
> +i915-y += intel_color_manager.o
> +
> obj-$(CONFIG_DRM_I915) += i915.o
>
> CFLAGS_i915_trace_points.o := -I$(src)
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
> b/drivers/gpu/drm/i915/intel_color_manager.c
> new file mode 100644
> index 000..f7e2380
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -0,0 +1,48 @@
> +/*
> + * Copyright © 2015 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + * Shashank Sharma
> + * Kausal Malladi
> + */
> +
> +#include "intel_color_manager.h"
> +
> +void intel_color_manager_init(struct drm_device *dev)
> +{
> + struct drm_mode_config *config = &dev->mode_config;
> +
> + /* Create Gamma and CSC properties */
> + config->gamma_property = drm_property_create(dev,
> + DRM_MODE_PROP_BLOB, "gamma_property", 0);
> + if (!config->gamma_property)
> + DRM_ERROR("Gamma property creation failed\n");
> + else
> + DRM_DEBUG_DRIVER("Created Gamma property\n");
> +
> + config->csc_property = drm_property_create(dev,
> + DRM_MODE_PROP_BLOB, "csc_property", 0);
> + if (!config->csc_property)
> + DRM_ERROR("CSC property creation failed\n");
> + else
> + DRM_DEBUG_DRIVER("Created CSC property\n");
> +}
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
> b/drivers/gpu/drm/i915/intel_color_manager.h
> new file mode 100644
> index 000..154bf16
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_color_manager.h
> @@ -0,0 +1,32 @@
> +/*
> + * Copyright © 2015 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS O
[PATCH v2 04/10] drm: Add Gamma correction structure
On Thu, Jun 04, 2015 at 07:12:35PM +0530, Kausal Malladi wrote:
> From: Kausal Malladi
>
> This patch adds a new structure in DRM layer for Gamma color correction.
> This structure will be used by all user space agents to configure
> appropriate Gamma precision and Gamma level.
>
> struct drm_intel_gamma {
>__u32 gamma_level;
> (The gamma_level variable indicates if the Gamma correction is to be
> applied on Pipe/plane)
I'm not sure I understand the need for this one...you're getting the
set_property call against a specific DRM object, so I don't think there
should be any confusion at that point about what the values apply to?
>__u32 gamma_precision;
> (The Gamma precision indicates the Gamma mode to be applied)
>
> Supported precisions are -
> #define I915_GAMMA_PRECISION_UNKNOWN0
> #define I915_GAMMA_PRECISION_CURRENT0x
> #define I915_GAMMA_PRECISION_LEGACY (1 << 0)
> #define I915_GAMMA_PRECISION_10BIT (1 << 1)
> #define I915_GAMMA_PRECISION_12BIT (1 << 2)
> #define I915_GAMMA_PRECISION_14BIT (1 << 3)
> #define I915_GAMMA_PRECISION_16BIT (1 << 4)
I feel like the precision would work better as a separate enum property
rather than being part of your blob; I think it would be cleaner if your
blob only held the actual values if possible.
>
> __u32 num_samples;
> (The num_samples indicates the number of Gamma correction
> coefficients)
> __u32 reserved;
> __u16 values[0];
> (An array of size 0, to accommodate the "num_samples" number of
> R16G16B16 pixels, dynamically)
> };
>
> v2: Addressing Daniel Stone's comment, added a variable sized array to
> carry Gamma correction values as blob property.
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
> ---
> include/drm/drm_crtc.h | 3 +++
> include/uapi/drm/drm.h | 10 ++
> 2 files changed, 13 insertions(+)
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 2a75d7d..bc44f27 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -483,6 +483,9 @@ struct drm_crtc {
>* acquire context.
>*/
> struct drm_modeset_acquire_ctx *acquire_ctx;
> +
> + /* Color Management Blob IDs */
> + u32 gamma_blob_id;
> };
>
> /**
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 3801584..fc2661c 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -829,6 +829,16 @@ struct drm_event_vblank {
> __u32 reserved;
> };
>
> +/* Color Management structure for Gamma */
> +struct drm_gamma {
> + __u32 flags;
The flags aren't described in your commit message...what are they used
for? I guess it will become more clear as I read farther through your
patch series.
Matt
> + __u32 gamma_level;
> + __u32 gamma_precision;
> + __u32 num_samples;
> + __u32 reserved;
> + __u16 values[0];
> +};
> +
> /* typedef area */
> #ifndef __KERNEL__
> typedef struct drm_clip_rect drm_clip_rect_t;
> --
> 2.4.2
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
[PATCH v2 05/10] drm: Add a new function for updating color blob
On Thu, Jun 04, 2015 at 07:12:36PM +0530, Kausal Malladi wrote:
> From: Kausal Malladi
>
> This patch adds a new function to update color blob properties
> and exports it.
>
> v2: Addressing Sonika's comment,
> 1. Moved this function to a separate patch
> 2. Removed one input parameter to the function
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
This function is basically just a pass-through. Can we just un-static
drm_property_replace_global_blob() so that it can be called directly
instead?
Matt
> ---
> drivers/gpu/drm/drm_crtc.c | 15 +++
> include/drm/drm_crtc.h | 4
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 77f87b2..f6fa147 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -4691,6 +4691,21 @@ int drm_mode_connector_set_tile_property(struct
> drm_connector *connector)
> }
> EXPORT_SYMBOL(drm_mode_connector_set_tile_property);
>
> +int drm_mode_crtc_update_color_property(struct drm_property_blob **blob,
> + size_t length, const void *color_data,
> + struct drm_mode_object *obj_holds_id,
> + struct drm_property *prop_holds_id)
> +{
> + struct drm_device *dev = prop_holds_id->dev;
> + int ret;
> +
> + ret = drm_property_replace_global_blob(dev,
> + blob, length, color_data, obj_holds_id, prop_holds_id);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_mode_crtc_update_color_property);
> +
> /**
> * drm_mode_connector_update_edid_property - update the edid property of a
> connector
> * @connector: drm connector
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index bc44f27..31b52cb 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1343,6 +1343,10 @@ extern void drm_mode_config_cleanup(struct drm_device
> *dev);
>
> extern int drm_mode_connector_set_path_property(struct drm_connector
> *connector,
> const char *path);
> +extern int drm_mode_crtc_update_color_property(struct drm_property_blob
> **blob,
> + size_t length, const void *color_data,
> + struct drm_mode_object *obj_holds_id,
> + struct drm_property *prop_holds_id);
> int drm_mode_connector_set_tile_property(struct drm_connector *connector);
> extern int drm_mode_connector_update_edid_property(struct drm_connector
> *connector,
> const struct edid *edid);
> --
> 2.4.2
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
[PATCH v2 06/10] drm: Avoid atomic commit path for CRTC property (Gamma)
On Thu, Jun 04, 2015 at 07:12:37PM +0530, Kausal Malladi wrote:
> From: Kausal Malladi
>
> The atomic CRTC set infrastructure is not available yet. So, the atomic
> check path throws error for any non-plane property.
>
> This patch adds a diversion to avoid commit path for DRM atomic set Gamma
> property, until atomic CRTC infrastructure is ready.
This doesn't look right, but I don't quite understand what you're trying
to do from the commit message.
This function is what will implement legacy set_property ioctl's of a
CRTC on an atomic-based driver. The idea is that when the ioctl is
issued, we should get (i.e., make a duplicate of) the current CRTC
state, change some of the values in that state (which is what the
.atomic_set_property function takes care of), and then submit that
modified state to the driver for checking and hw-programming.
Okay, I just took a quick peek ahead in your patch set and I think I
understand the confusion now...it looks like you're trying to actually
perform the full hardware update in the .atomic_set_property call chain,
which isn't what we want to be doing in an atomic driver.
.atomic_set_property() is just a matter of updating the state structures
to reflect the changes you *want* to make (but not actually performing
those changes right away). It isn't until drm_atomic_commit() gets
called that we validate the new state structure and then write it to the
hardware if it looks okay.
Keep in mind that the overall goal behind atomic is that we want to be
able to supply several items to be updated (e.g., mode, CSC, gamma,
etc.) via the atomic ioctl and then have them all accepted (and
programmed) by the driver, or all rejected (so none get programmed) if
any of them are invalid. Also, if the collection of properties that
you're updating fall within the "nuclear pageflip" subset of
functionality, you'll also get a guarantee that those items all get
updated within the same vblank; updates that straddle a vblank could
cause unwanted flickering or other artifacts. The helper function
you're updating here only happens to update a single state value at a
time, but the same .atomic_set_property() is also used by the atomic
ioctl, so we need to make sure it's following the expected design.
Finally, keep in mind that the function you're updating here is a DRM
core function. Even though i915 isn't quite ready for full atomic yet
and might have a bit of brain damage in areas, other vendors' drivers do
have complete atomic modesetting support (I think?), so adding
i915-specific workarounds like this to the core function could actually
hamper them.
Matt
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index a900858..37dba55 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1696,6 +1696,8 @@ drm_atomic_helper_crtc_set_property(struct drm_crtc
> *crtc,
> {
> struct drm_atomic_state *state;
> struct drm_crtc_state *crtc_state;
> + struct drm_device *dev = crtc->dev;
> + struct drm_mode_config *config = &dev->mode_config;
> int ret = 0;
>
> state = drm_atomic_state_alloc(crtc->dev);
> @@ -1716,9 +1718,18 @@ retry:
> if (ret)
> goto fail;
>
> - ret = drm_atomic_commit(state);
> - if (ret != 0)
> - goto fail;
> + /**
> + * FIXME : This is a hack, to avoid atomic commit
> + * for CRTC, because i915 supports only
> + * atomic plane operations at the moment
> + */
> + if (property == config->gamma_property)
> + ret = 0;
> + else {
> + ret = drm_atomic_commit(state);
> + if (ret != 0)
> + goto fail;
> + }
>
> /* Driver takes ownership of state on successful commit. */
> return 0;
> --
> 2.4.2
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
git pull] drm for v4.1-rc1
over git bisect bad e0d6149b3debce1a7e17dfda7c2829935917dc58 # bad: [08d9bc920d465d762cac9383249c19bf69a2] drm/i915: Allocate connector state together with the connectors git bisect bad 08d9bc920d465d762cac9383249c19bf69a2 # first bad commit: [08d9bc920d465d762cac9383249c19bf69a2] drm/i915: Allocate connector state together with the connectors Reverting just this commit on top of yesterday evening's v4.1-rc6-52-gff25ea8 avoids the problem for me. Using the very same kernel, other i915 based systems are fine for me: DP && HDMI: 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0162] (rev 09) DVI:00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0152] (rev 09) headless: 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0152] (rev 09) headless: 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display [8086:0f31] (rev 0e) HDMI: 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0122] (rev 09) LVDS: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE Express Integrated Graphics Controller [8086:27ae] (rev 03) headless: 00:02.0 VGA compatible controller [0300]: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device [8086:2562] (rev 01) Regards Stefan Lippers-Hollmann [1] http://www.intel.com/support/motherboards/desktop/d945gclf2/sb/CS-029540.htm -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: Digitale Signatur von OpenPGP URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150605/2bec970a/attachment-0001.sig>
