dri-devel June 2015

dri-devel@lists.freedesktop.org

188 participants
1140 discussions

[PATCH] drm/amdkfd: Add missing properties to CZ device info
by Oded Gabbay 06 Jun '15

06 Jun '15

This patch adds two missing properties initializations to the device info structure of CZ. As we don't have CZ support yet, it isn't critical, but its important to fix this now instead of forgetting about it later. Signed-off-by: Oded Gabbay <oded.gabbay(a)gmail.com> --- drivers/gpu/drm/amd/amdkfd/kfd_device.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c b/drivers/gpu/drm/amd/amdkfd/kfd_device.c index 1d1e2e9..75312c8 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c @@ -44,7 +44,10 @@ static const struct kfd_device_info kaveri_device_info = { static const struct kfd_device_info carrizo_device_info = { .asic_family = CHIP_CARRIZO, .max_pasid_bits = 16, + /* max num of queues for CZ.TODO should be a dynamic value */ + .max_no_of_hqd = 24, .ih_ring_entry_size = 4 * sizeof(uint32_t), + .event_interrupt_class = &event_interrupt_class_cik, .num_of_watch_points = 4, .mqd_size_aligned = MQD_SIZE_ALIGNED }; -- 2.4.2

1 0

[PATCH] drm/amdkfd: do reset wavefronts per process per device
by Oded Gabbay 06 Jun '15

06 Jun '15

From: Ben Goz <ben.goz(a)amd.com> This commit moves the reset wavefront flag to per process per device data structure, so we can support multiple devices. Signed-off-by: Ben Goz <ben.goz(a)amd.com> Signed-off-by: Oded Gabbay <oded.gabbay(a)gmail.com> --- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 7 ++++--- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 10 +++++----- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 21 ++++++++++++++++----- 3 files changed, 25 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c index 547b0a5..4bb7f42 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c @@ -946,7 +946,7 @@ static int destroy_queues_cpsch(struct device_queue_manager *dqm, { int retval; enum kfd_preempt_type_filter preempt_type; - struct kfd_process *p; + struct kfd_process_device *pdd; BUG_ON(!dqm); @@ -981,8 +981,9 @@ static int destroy_queues_cpsch(struct device_queue_manager *dqm, retval = amdkfd_fence_wait_timeout(dqm->fence_addr, KFD_FENCE_COMPLETED, QUEUE_PREEMPT_DEFAULT_TIMEOUT_MS); if (retval != 0) { - p = kfd_get_process(current); - p->reset_wavefronts = true; + pdd = kfd_get_process_device_data(dqm->dev, + kfd_get_process(current)); + pdd->reset_wavefronts = true; goto out; } pm_release_ib(&dqm->packets); diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h index cb79046..d0d5f4b 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h +++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h @@ -463,6 +463,11 @@ struct kfd_process_device { /* Is this process/pasid bound to this device? (amd_iommu_bind_pasid) */ bool bound; + + /* This flag tells if we should reset all + * wavefronts on process termination + */ + bool reset_wavefronts; }; #define qpd_to_pdd(x) container_of(x, struct kfd_process_device, qpd) @@ -519,11 +524,6 @@ struct kfd_process { event_pages */ u32 next_nonsignal_event_id; size_t signal_event_count; - /* - * This flag tells if we should reset all wavefronts on - * process termination - */ - bool reset_wavefronts; }; /** diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c index 56b904f..8a1f999 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c @@ -173,7 +173,7 @@ static void kfd_process_wq_release(struct work_struct *work) pr_debug("Releasing pdd (topology id %d) for process (pasid %d) in workqueue\n", pdd->dev->id, p->pasid); - if (p->reset_wavefronts) + if (pdd->reset_wavefronts) dbgdev_wave_reset_wavefronts(pdd->dev, p); amd_iommu_unbind_pasid(pdd->dev->pdev, p->pasid); @@ -222,6 +222,7 @@ static void kfd_process_notifier_release(struct mmu_notifier *mn, struct mm_struct *mm) { struct kfd_process *p; + struct kfd_process_device *pdd = NULL; /* * The kfd_process structure can not be free because the @@ -240,6 +241,15 @@ static void kfd_process_notifier_release(struct mmu_notifier *mn, /* In case our notifier is called before IOMMU notifier */ pqm_uninit(&p->pqm); + /* Iterate over all process device data structure and check + * if we should reset all wavefronts */ + list_for_each_entry(pdd, &p->per_device_data, per_device_list) + if (pdd->reset_wavefronts) { + pr_warn("amdkfd: Resetting all wave fronts\n"); + dbgdev_wave_reset_wavefronts(pdd->dev, p); + pdd->reset_wavefronts = false; + } + mutex_unlock(&p->mutex); /* @@ -305,8 +315,6 @@ static struct kfd_process *create_process(const struct task_struct *thread) if (kfd_init_apertures(process) != 0) goto err_init_apretures; - process->reset_wavefronts = false; - return process; err_init_apretures: @@ -348,6 +356,7 @@ struct kfd_process_device *kfd_create_process_device_data(struct kfd_dev *dev, INIT_LIST_HEAD(&pdd->qpd.queues_list); INIT_LIST_HEAD(&pdd->qpd.priv_queue_list); pdd->qpd.dqm = dev->dqm; + pdd->reset_wavefronts = false; list_add(&pdd->per_device_list, &p->per_device_data); } @@ -409,10 +418,12 @@ void kfd_unbind_process_from_device(struct kfd_dev *dev, unsigned int pasid) kfd_dbgmgr_destroy(dev->dbgmgr); pqm_uninit(&p->pqm); - if (p->reset_wavefronts) - dbgdev_wave_reset_wavefronts(dev, p); pdd = kfd_get_process_device_data(dev, p); + if (pdd->reset_wavefronts) { + dbgdev_wave_reset_wavefronts(pdd->dev, p); + pdd->reset_wavefronts = false; + } /* * Just mark pdd as unbound, because we still need it to call -- 2.4.2

1 0

[PATCH] drm/amdkfd: avoid CONFIG_ prefix for non-Kconfig symbols
by Valentin Rothberg 06 Jun '15

06 Jun '15

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 <valentinrothberg(a)gmail.com> --- 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

2 1

[PATCH] drm/nouveau: Do not leak client objects
by Thierry Reding 06 Jun '15

06 Jun '15

From: Thierry Reding <treding(a)nvidia.com> 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 <treding(a)nvidia.com> --- 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 -- 2.1.2

2 2

Re: [PATCH v2 01/10] drm/i915: Initialize Color Manager
by Matt Roper 06 Jun '15

06 Jun '15

On Thu, Jun 04, 2015 at 07:12:32PM +0530, Kausal Malladi wrote: > From: Kausal Malladi <Kausal.Malladi(a)intel.com> > > 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 <shashank.sharma(a)intel.com> > Signed-off-by: Kausal Malladi <Kausal.Malladi(a)intel.com> > --- > 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 0000000..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 <shashank.sharma(a)intel.com> > + * Kausal Malladi <Kausal.Malladi(a)intel.com> > + */ > + > +#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 0000000..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 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 <shashank.sharma(a)intel.com> > + * Kausal Malladi <Kausal.Malladi(a)intel.com> > + */ > + > +#include <drm/drmP.h> > +#include <drm/drm_crtc_helper.h> > + > +/* Generic Function prototypes */ > +void intel_color_manager_init(struct drm_device *dev); While I personally don't mind creating a new header for prototypes, most of our other KMS-related stuff just gets thrown in intel_drv.h under a comment like "/* intel_foobar.c */" so this is a little inconsistent. Maybe we should keep these prototypes there as well since that's the file most developers are going to look for these in out of habit? > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > index 067b1de..2322dee 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -44,6 +44,7 @@ > #include <drm/drm_plane_helper.h> > #include <drm/drm_rect.h> > #include <linux/dma_remapping.h> > +#include "intel_color_manager.h" > > /* Primary plane formats for gen <= 3 */ > static const uint32_t i8xx_primary_formats[] = { > @@ -14673,6 +14674,8 @@ void intel_modeset_init(struct drm_device *dev) > if (INTEL_INFO(dev)->num_pipes == 0) > return; > > + intel_color_manager_init(dev); > + > intel_init_display(dev); > intel_init_audio(dev); > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h > index 3b4d8a4..2a75d7d 100644 > --- a/include/drm/drm_crtc.h > +++ b/include/drm/drm_crtc.h > @@ -1176,6 +1176,10 @@ struct drm_mode_config { > struct drm_property *suggested_x_property; > struct drm_property *suggested_y_property; > > + /* Color Management Properties */ > + struct drm_property *gamma_property; > + struct drm_property *csc_property; > + I notice you're adding these to a core DRM structure; is the expectation that other drivers will want to re-use these properties for their own color correction functionality? If the answer is yes, you'll definitely need to add documentation for the property to Documentation/DocBook/drm.tmpl which will get compiled into documentation like you see at http://people.freedesktop.org/~danvet/drm/drm-kms-properties.html#idp595631… (actually you'll want to add that documentation even if it's an i915-specific property, but it's especially important for anything we expect to be reusable by other drivers). If the answer is no, and you expect this to be i915-specific for the foreseeable future, then stashing the property in dev_priv might be a better choice to avoid growing the driver-independent structures. Matt > /* dumb ioctl parameters */ > uint32_t preferred_depth, prefer_shadow; > > -- > 2.4.2 > -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795

2 1

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

06 Jun '15

https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #91 from Oliver Winker <oliverml1(a)oli1170.net> --- Ufff - a complicated way to recognize that one day I actually put the mod-param radeon dpm=0 :-P ... while in the meanwhile dpm=1 actually works ;). Anyway, what a nice discovery: The fans are silent now! Great :)) !! -- You are receiving this mail because: You are the assignee for the bug.

1 0

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

06 Jun '15

https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #90 from Oliver Winker <oliverml1(a)oli1170.net> --- In fact it seems that controlling the fans on my card using the ADL Overdrive6 api doesn't work. But it works using Overdrive5. When I modify Olegs test-program to use ADL_Overdrive5_FanSpeed[Get|Set|ToDefault_Set]() api indeed my fans react. So the next thing I guess would be to check the mmio-traces. In fact for me personally already the equivalent of ADL_Overdrive5_FanSpeedToDefault_Set() would be sufficient, since it seems to put the fan automagically to a good minimum. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH] drm: fix writing to /sys/class/drm/*/status
by Russell King 05 Jun '15

05 Jun '15

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 <rmk+kernel(a)arm.linux.org.uk> --- 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

3 2

RE: Help on drmModeSetPlane
by Xie, William 05 Jun '15

05 Jun '15

I tried crtc (0, 0, 3200, 1800) src (0, 0, 3200<<16, 1800<<16) but get a crash, How can I enable scaling on overlay for video frame? William From: Xie, William Sent: Wednesday, April 15, 2015 4:49 PM To: DRI Development; DRI Development Subject: RE: Help on drmModeSetPlane To make it more specific, For example: 1: video frame size is 1280x720, 2: screen resolution is 3200x1800, How can I set crtc and src parameters? 1: crtc (0, 0, 3200, 1800) src (0, 0, 3200<<16, 1800<<16) 2: crtc (0, 0, 3200, 1800) src (0, 0, 1280<<16, 720<<16) Which one is correct? William From: Xie, William Sent: Wednesday, April 15, 2015 3:55 PM To: DRI Development; DRI Development Subject: Help on drmModeSetPlane Question please, could someone share the meaning of the parameters for drmModeSetPlane in libdrm? int drmModeSetPlane(int fd, uint32_t plane_id, uint32_t crtc_id, uint32_t fb_id, uint32_t flags, int32_t crtc_x, int32_t crtc_y, uint32_t crtc_w, uint32_t crtc_h, uint32_t src_x, uint32_t src_y, uint32_t src_w, uint32_t src_h) My problem is, whatever value I set, the video is not full screen mode, Anything I missed? Thanks William

2 2

Etnaviv DRM driver userspace support?
by Kimmo Saarela 05 Jun '15

05 Jun '15

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-2… Br, - Kimmo S.

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2015