[PATCH 2/2] drm: make unplugged flag specific to udl driver

Hi On Wed, Feb 10, 2016 at 11:02 PM, Stéphane Marchesin wrote: > On Wed, Feb 10, 2016 at 1:54 PM, David Herrmann > wrote: If a device is unplugged, you should consider all your resources to be destroyed. There is no reason to release them manually. User-space *must* be able to

[PATCH] mm: fix pfn_t vs highmem

On 2/10/2016 10:18 PM, Dan Williams wrote: > The pfn_t type uses an unsigned long to store a pfn + flags value. On a > 64-bit platform the upper 12 bits of an unsigned long are never used for > storing the value of a pfn. However, this is not true on highmem > platforms, all 32-bits of a pfn

[PATCH 2/2] drm: make unplugged flag specific to udl driver

Hi On Wed, Feb 10, 2016 at 10:46 PM, Stéphane Marchesin wrote: > On Wed, Feb 10, 2016 at 1:38 PM, David Herrmann > wrote: >> Hi >> >> On Wed, Feb 10, 2016 at 9:39 PM, Haixia Shi wrote: >>> + if (udl_device_is_unplugged(dev) && + nr !=

[PATCH 2/2] drm: make unplugged flag specific to udl driver

Hi On Wed, Feb 10, 2016 at 10:38 PM, Haixia Shi wrote: > David > > I am having trouble getting the reference to "drm_global_mutex" to link > correctly in drm/udl. The error is > > ERROR: "drm_global_mutex" [drivers/gpu/drm/udl/udl.ko] undefined! > make[1]: *** [__modpost] Error 1 > make: ***

[PATCH 2/2] drm: make unplugged flag specific to udl driver

Hi On Wed, Feb 10, 2016 at 9:39 PM, Haixia Shi wrote: > >> + if (udl_device_is_unplugged(dev) && >> + nr != DRM_IOCTL_NR(DRM_IOCTL_MODE_SETCRTC) && >> + nr != DRM_IOCTL_NR(DRM_IOCTL_MODE_RMFB) && >> + nr !=

[PATCH 2/2] drm: make unplugged flag specific to udl driver

Hi On Wed, Feb 10, 2016 at 9:51 PM, Haixia Shi wrote: >> This should rather be: >> >> drm_release(inode, filp); >> mutex_lock(_global_mutex); >> if (!dev->open_count && udl_device_is_unplugged(dev)) >> drm_put_dev(dev); >>

[PATCH 2/2] drm: make unplugged flag specific to udl driver

Hi On Wed, Feb 10, 2016 at 10:00 PM, Haixia Shi wrote: > Also note that it is not currently feasible for UDL code to access > drm_global_mutex. Then change this. > Please also refer to the similar comments ("FIXME: open_count is protected > by drm_global_mutex but that would lead to locking

[PATCH 5/6] drm: Prevent vblank counter jumps with timestamp based update method.

On Wed, Feb 10, 2016 at 7:36 PM, Mario Kleiner wrote: > On 02/10/2016 06:17 PM, Daniel Vetter wrote: >> >> On Wed, Feb 10, 2016 at 5:28 PM, Mario Kleiner >> wrote: >>> >>> There's another scenario where this zero-ts case can be hit. If the >>> driver >>> drm_vblank_init()'s - setting all

[Bug 92258] [regression] Opening menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash

attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160210/d0476346/attachment.html>

[Bug 92258] [regression] Opening menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash

are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160210/079ca398/attachment.html>

[PATCH 5/6] drm: Prevent vblank counter jumps with timestamp based update method.

On 02/10/2016 06:17 PM, Daniel Vetter wrote: > On Wed, Feb 10, 2016 at 5:28 PM, Mario Kleiner > wrote: >> There's another scenario where this zero-ts case can be hit. If the driver >> drm_vblank_init()'s - setting all timestamps to zero - and then code starts >> using vblanks (drm_vblank_get())

ttm_bo_add_to_lru mystery

On 10.02.2016 18:28, Michel Dänzer wrote: > > I recently came to realize that nothing seems to be ensuring that BOs > which are unpinned in the amdgpu/radeon drivers get added to the TTM > LRU list. I thought that should be easy enough to fix, but I ran into > an issue that has me scratching my

[PATCH v2 2/2] drm/i915/gen9: Add support for pipe background color (v2)

Gen9 platforms allow CRTC's to be programmed with a background/canvas color below the programmable planes. Let's expose this as a property to allow userspace to program a desired value. This patch is based on earlier work by Chandra Konduru; unfortunately the driver has evolved so much since his

[PATCH v2 1/2] drm: Add infrastructure for CRTC background color property (v2)

To support CRTC background color, we need a way of communicating RGB color values to the DRM. However there is often a mismatch between how userspace wants to represent the color value vs how it must be programmed into the hardware; this mismatch can easily lead to non-obvious bugs. Let's create

ttm_bo_add_to_lru mystery

oftware enthusiast | Mesa and X developer -- next part -- A non-text attachment was scrubbed... Name: ttm_bo_add_lru.diff Type: text/x-patch Size: 1424 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160210/78f05727/attachment-0001.bin>

[PATCH] mm: fix pfn_t vs highmem

The pfn_t type uses an unsigned long to store a pfn + flags value. On a 64-bit platform the upper 12 bits of an unsigned long are never used for storing the value of a pfn. However, this is not true on highmem platforms, all 32-bits of a pfn value are used to address a 44-bit physical address

[PATCH 5/6] drm: Prevent vblank counter jumps with timestamp based update method.

On Wed, Feb 10, 2016 at 5:28 PM, Mario Kleiner wrote: > There's another scenario where this zero-ts case can be hit. If the driver > drm_vblank_init()'s - setting all timestamps to zero - and then code starts > using vblanks (drm_vblank_get()) without drm_vblank_on beforehand, which is > afaics

[PATCH 5/6] drm: Prevent vblank counter jumps with timestamp based update method.

On 02/09/2016 04:03 PM, Daniel Vetter wrote: > On Tue, Feb 09, 2016 at 04:11:49PM +0200, Ville Syrjälä wrote: >> On Tue, Feb 09, 2016 at 02:53:30PM +0100, Mario Kleiner wrote: >>> On 02/09/2016 11:09 AM, Daniel Vetter wrote: On Mon, Feb 08, 2016 at 02:13:28AM +0100, Mario Kleiner wrote:

[Bug 93663] Stuck on screen blanking/dmps/monitor turned off/on

-- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160210/27eec371/attachment.html>

[PATCH] drm/bridge: removed dummy mode_fixup function from dw-hdmi.

Other bridge drivers don't implement this optional function. Removed dummy code from dw-hdmi brigde driver. Signed-off-by: Carlos Palminha --- drivers/gpu/drm/bridge/dw-hdmi.c | 8 1 file changed, 8 deletions(-) diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c

[PATCH] drm: fixes when i2c encoder slave mode_fixup is null.

On Wed, 10 Feb 2016, Daniel Vetter wrote: > On Wed, Feb 10, 2016 at 12:08:38PM +, Carlos Palminha wrote: >> Avoid i2c slave encoder drivers to copy/paste code to implement functions >> that will >> only return true. >> >> Signed-off-by: Carlos Palminha > > lgtm, applied to drm-misc.

[PATCH v2 2/2] drm/i2c/tda998x: removed unnecessary code, mode_fixup is now optional.

Removed dummy mode_fixup. Signed-off-by: Carlos Palminha --- drivers/gpu/drm/i2c/tda998x_drv.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index 34e3874..b61282d 100644 --- a/drivers/gpu/drm/i2c/tda998x_drv.c

[PATCH v2 1/2] drm/i2c/sil164: removed unnecessary code, mode_fixup is now optional.

Removed dummy mode_fixup. Signed-off-by: Carlos Palminha --- drivers/gpu/drm/i2c/sil164_drv.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/i2c/sil164_drv.c b/drivers/gpu/drm/i2c/sil164_drv.c index c400428..db0b03f 100644 --- a/drivers/gpu/drm/i2c/sil164_drv.c +++

[PATCH v2 0/2] drm/i2c : removed unnecessary code, mode_fixup is now optional.

With patch http://patchwork.freedesktop.org/patch/msgid/1455106118-32145-1-git-send-email-palminha at synopsys.com i2c slave encoder drivers no longer need to implement dummy mode_fixup function. This patch set nukes the dummy functions from i2c slave encoder drivers. (changes made on top of

[PATCH v2 2/2] drm: remove drm_device_is_unplugged checks in common drm code.

When USB cable is disconnected, we mark udl device as unplugged so that udl_detect reports connector status as disconnected, but still keep the drm device alive until user-space closes it. Signed-off-by: Haixia Shi Reviewed-by: Stéphane Marchesin --- drivers/gpu/drm/drm_drv.c | 6

[PATCH 03/12] drm/tilcdc: verify fb pitch

On 12/16/15 10:37, Daniel Vetter wrote: > On Tue, Dec 15, 2015 at 09:03:14PM +0200, Jyri Sarha wrote: >> >From: Tomi Valkeinen >> > >> >LCDC hardware does not support fb pitch that is different (i.e. larger) >> >than the screen size. The driver currently does no checks for this, and >> >the

[PATCH 2/2] drm/i2c/tda998x: removed unnecessary code, mode_fixup is now optional.

Removed dummy mode_fixup. Signed-off-by: Carlos Palminha --- drivers/gpu/drm/i2c/tda998x_drv.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index 34e3874..b61282d 100644 --- a/drivers/gpu/drm/i2c/tda998x_drv.c

[PATCH 1/2] drm/i2c/sil164: removed unnecessary code, mode_fixup is now optional.

Removed dummy mode_fixup. Signed-off-by: Carlos Palminha --- drivers/gpu/drm/i2c/sil164_drv.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/i2c/sil164_drv.c b/drivers/gpu/drm/i2c/sil164_drv.c index c400428..db0b03f 100644 --- a/drivers/gpu/drm/i2c/sil164_drv.c +++

No subject

With patch http://patchwork.freedesktop.org/patch/msgid/1455106118-32145-1-git-send-email-palminha at synopsys.com i2c slave encoder drivers no longer need to implement dummy mode_fixup function. This patch set nukes the dummy functions from i2c slave encoder drivers. (changes made on top of

[PATCH v2 2/2] drm: remove drm_device_is_unplugged checks in common drm code.

When USB cable is disconnected, we mark udl device as unplugged so that udl_detect reports connector status as disconnected, but still keep the drm device alive until user-space closes it. Signed-off-by: Haixia Shi Reviewed-by: Stéphane Marchesin --- drivers/gpu/drm/drm_drv.c | 6

linux-next: build failure after merge of the drm-misc tree

On Wed, Feb 10, 2016 at 02:17:41PM +0100, Lukas Wunner wrote: > Hi, > > On Wed, Feb 10, 2016 at 09:41:38AM +0100, Lukas Wunner wrote: > > On Wed, Feb 10, 2016 at 12:24:51PM +1100, Stephen Rothwell wrote: > > > Hi all, > > > > > > After merging the drm-misc tree, today's linux-next build (arm > >

[PATCH 03/12] drm/tilcdc: verify fb pitch

On Wed, Feb 10, 2016 at 03:18:01PM +0200, Jyri Sarha wrote: > On 12/16/15 10:37, Daniel Vetter wrote: > >On Tue, Dec 15, 2015 at 09:03:14PM +0200, Jyri Sarha wrote: > >>>From: Tomi Valkeinen > >>> > >>>LCDC hardware does not support fb pitch that is different (i.e. larger) > >>>than the screen

linux-next: build failure after merge of the drm-misc tree

Hi, On Wed, Feb 10, 2016 at 09:41:38AM +0100, Lukas Wunner wrote: > On Wed, Feb 10, 2016 at 12:24:51PM +1100, Stephen Rothwell wrote: > > Hi all, > > > > After merging the drm-misc tree, today's linux-next build (arm > > multi_v7_defconfig) failed like this: > > > > In file included from

[pull] radeon and amdgpu drm-fixes-4.5

Hi Dave, radeon and amdgpu fixes for 4.5. Highlights: - powerplay fixes for amdgpu - race fixes in the sub-allocator in radeon and amdgpu - hibernate fix for amdgpu - fix a possible circular locking in userptr handling in amdgpu The following changes since commit

[Bug 35457] [rs690m] Graphics corruption with ati x1200

. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160210/e4ea15f6/attachment.html>

[Bug 89686] x1250 rs600m graphic problems / unreadable fonts in (gl?)- games

tps://lists.freedesktop.org/archives/dri-devel/attachments/20160210/b86cabc8/attachment.html>

[Bug 35998] RS600: Texture alignment issues under Gnome Shell

nts/20160210/0739415e/attachment.html>

[Bug 89686] x1250 rs600m graphic problems / unreadable fonts in (gl?)- games

|Mesa -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160210/47498be5/attachment.html>

[PATCH 2/2] drm: make unplugged flag specific to udl driver

On Wed, Feb 10, 2016 at 1:54 PM, David Herrmann wrote: > Hi > > On Wed, Feb 10, 2016 at 10:46 PM, Stéphane Marchesin > wrote: >> On Wed, Feb 10, 2016 at 1:38 PM, David Herrmann >> wrote: >>> Hi >>> >>> On Wed, Feb 10, 2016 at 9:39 PM, Haixia Shi wrote: > + if

[PATCHv12 17/17] vivid: add CEC emulation

From: Hans Verkuil The vivid driver has been extended to provide CEC adapters for the HDMI input and HDMI outputs in order to test CEC applications. This CEC emulation is faithful to the CEC timings (i.e., it all at a snail's pace). Signed-off-by: Hans Verkuil ---

[PATCHv12 16/17] cec: s5p-cec: Add s5p-cec driver

From: Kamil Debski Add CEC interface driver present in the Samsung Exynos range of SoCs. The following files were based on work by SangPil Moon: - exynos_hdmi_cec.h - exynos_hdmi_cecctl.c Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil ---

[PATCHv12 15/17] cobalt: add cec support

From: Hans Verkuil Add CEC support to the cobalt driver. Signed-off-by: Hans Verkuil --- drivers/media/pci/cobalt/Kconfig | 1 + drivers/media/pci/cobalt/cobalt-driver.c | 115 +++- drivers/media/pci/cobalt/cobalt-driver.h | 2 +

[PATCHv12 14/17] cec: adv7511: add cec support.

From: Hans Verkuil Add CEC support to the adv7511 driver. Signed-off-by: Hans Verkuil [k.debski at samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- drivers/media/i2c/adv7511.c | 384

[PATCHv12 13/17] cec: adv7842: add cec support

From: Hans Verkuil Add CEC support to the adv7842 driver. Signed-off-by: Hans Verkuil --- drivers/media/i2c/adv7842.c | 268 +--- 1 file changed, 251 insertions(+), 17 deletions(-) diff --git a/drivers/media/i2c/adv7842.c

[PATCHv12 12/17] cec: adv7604: add cec support.

From: Hans Verkuil Add CEC support to the adv7604 driver. Signed-off-by: Hans Verkuil [k.debski at samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] [k.debski at samsung.com: add missing methods cec/io_write_and_or] [k.debski at samsung.com: change

[PATCHv12 11/17] v4l2-subdev: add HDMI CEC ops

From: Hans Verkuil Add CEC callbacks to the new v4l2_subdev_cec_ops struct. These are the low-level CEC ops that subdevs that support CEC have to implement. Signed-off-by: Hans Verkuil [k.debski at samsung.com: Merged changes from CEC Updates commit by Hans Verkuil]

[PATCHv12 10/17] DocBook/media: add CEC documentation

From: Hans Verkuil Add DocBook documentation for the CEC API. Signed-off-by: Hans Verkuil [k.debski at samsung.com: add documentation for passthrough mode] [k.debski at samsung.com: minor fixes and change of reserved field sizes] Signed-off-by: Kamil Debski

[PATCHv12 09/17] cec.txt: add CEC framework documentation

From: Hans Verkuil Document the new HDMI CEC framework. Signed-off-by: Hans Verkuil [k.debski at samsung.com: add DocBook documentation by Hans Verkuil, with Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- Documentation/cec.txt | 359

[PATCHv12 08/17] cec: add compat32 ioctl support

From: Hans Verkuil The CEC ioctls didn't have compat32 support, so they returned -ENOTTY when used in a 32 bit application on a 64 bit kernel. Since all the CEC ioctls are 32-bit compatible adding support for this API is trivial. Signed-off-by: Hans Verkuil ---

[PATCHv12 07/17] cec: add HDMI CEC framework

From: Hans Verkuil The added HDMI CEC framework provides a generic kernel interface for HDMI CEC devices. Signed-off-by: Hans Verkuil [k.debski at samsung.com: Merged CEC Updates commit by Hans Verkuil] [k.debski at samsung.com: Merged Update author commit by Hans Verkuil]

[PATCHv12 06/17] rc: Add HDMI CEC protocol handling

From: Kamil Debski Add handling of remote control events coming from the HDMI CEC bus. This patch includes a new keymap that maps values found in the CEC messages to the keys pressed and released. Also, a new protocol has been added to the core. Signed-off-by: Kamil Debski

[PATCHv12 05/17] HID: add HDMI CEC specific keycodes

From: Kamil Debski Add HDMI CEC specific keycodes to the keycodes definition. Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- include/uapi/linux/input-event-codes.h | 28 1 file changed, 28 insertions(+) diff --git

[PATCHv12 04/17] input.h: add BUS_CEC type

From: Hans Verkuil Inputs can come in over the HDMI CEC bus, so add a new type for this. Signed-off-by: Hans Verkuil Acked-by: Dmitry Torokhov --- include/uapi/linux/input.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/input.h

[PATCHv12 03/17] dts: exynos4412-odroid*: enable the HDMI CEC device

From: Kamil Debski Add a dts node entry and enable the HDMI CEC device present in the Exynos4 family of SoCs. Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil Acked-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 1 file changed,

[PATCHv12 02/17] dts: exynos4: add node for the HDMI CEC device

From: Kamil Debski This patch adds HDMI CEC node specific to the Exynos4210/4x12 SoC series. Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil Acked-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos4.dtsi | 12 1 file changed, 12 insertions(+) diff

[PATCHv12 01/17] dts: exynos4*: add HDMI CEC pin definition to pinctrl

From: Kamil Debski Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and Exynos4x12 SoCs. These are required by the HDMI CEC device. Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil Acked-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos4210-pinctrl.dtsi

[PATCHv12 00/17] HDMI CEC framework

From: Hans Verkuil Hi all, The twelfth version of this patchset addresses the remaining comment I made when I posted the previous version and it makes some improvements to the tx_status after re-reading the CEC specification. See the changelog below. The cec-ctl and

[PATCH 2/2] drm: make unplugged flag specific to udl driver

On Wed, Feb 10, 2016 at 1:38 PM, David Herrmann wrote: > Hi > > On Wed, Feb 10, 2016 at 9:39 PM, Haixia Shi wrote: >> >>> + if (udl_device_is_unplugged(dev) && >>> + nr != DRM_IOCTL_NR(DRM_IOCTL_MODE_SETCRTC) && >>> + nr != DRM_IOCTL_NR(DRM_IOCTL_MODE_RMFB) &&

[PATCH 2/2] drm: make unplugged flag specific to udl driver

ease(). It is > completely bogus. You rather confuse generic user-space that calls > close(), than getting any benefit out of it. > > But TBH, I don't care. Feel free to forward the return value. But > still, please change the order of the calls as I did. > > Thanks > David > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160210/ccab7639/attachment.html>

[PATCH] drm: fixes crct set_mode when encoder mode_fixup is null.

On Wed, Feb 10, 2016 at 12:15:22PM +, Carlos Palminha wrote: > Avoids null crash when encoders don't implement mode_fixup. > > Signed-off-by: Carlos Palminha One more thing I've forgotten: With these changes the kerneldoc in include/drm/drm_modeset_helper_vtables.h is now no longer

[PATCH] drm: fixes crct set_mode when encoder mode_fixup is null.

On Wed, Feb 10, 2016 at 12:15:22PM +, Carlos Palminha wrote: > Avoids null crash when encoders don't implement mode_fixup. > > Signed-off-by: Carlos Palminha btw we could do the same game for drm_crtc_helper_funcs->mode_fixup. More dummy functions to nuke! -Daniel > --- >

[PATCH] drm: fixes crct set_mode when encoder mode_fixup is null.

On Wed, Feb 10, 2016 at 12:15:22PM +, Carlos Palminha wrote: > Avoids null crash when encoders don't implement mode_fixup. > > Signed-off-by: Carlos Palminha > --- > drivers/gpu/drm/drm_crtc_helper.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git

[PATCH] drm: fixes when i2c encoder slave mode_fixup is null.

On Wed, Feb 10, 2016 at 12:08:38PM +, Carlos Palminha wrote: > Avoid i2c slave encoder drivers to copy/paste code to implement functions > that will > only return true. > > Signed-off-by: Carlos Palminha lgtm, applied to drm-misc. sil164_drv.c seems to have a dummy mode_fixup function

[PATCH 2/2] drm: make unplugged flag specific to udl driver

Hi On Tue, Feb 9, 2016 at 10:05 PM, Haixia Shi wrote: > Remove the general drm_device_is_unplugged() checks, and move the unplugged > flag handling logic into drm/udl. In general we want to keep driver-specific > logic out of common drm code. > > Signed-off-by: Haixia Shi > Reviewed-by:

[PATCH v2] drm: fixes when bridge mode_fixup is null.

On Wed, Feb 10, 2016 at 11:21:16AM +, Carlos Palminha wrote: > Avoid drivers to copy/past code to implement functions that will only return > true. > > Changes v1->v2: > * Added Signed off by > > Signed-off-by: Carlos Palminha > --- > drivers/gpu/drm/drm_bridge.c | 2 ++ > 1 file changed,

[PATCH] adv7511: Added mode_fixup function.

On Wed, Feb 10, 2016 at 10:19:21AM +, Carlos Palminha wrote: > Hi guys, > > I agree that this should be fixed in the helper library. > There are already a lot of drivers that copy/paste code and several helper > functions that do not avoid it. > > I will start sending some patches to fix

[PATCH 2/2] drm: make unplugged flag specific to udl driver

tl(struct file *filp, unsigned int cmd, unsigned long >> arg) >> > +{ >> > + struct drm_file *file_priv = filp->private_data; >> > + struct drm_device *dev = file_priv->minor->dev; >> > + unsigned int nr = DRM_IOCTL_NR(cmd); >> > + >> > + if (udl_device_is_unplugged(dev) && >> > + nr != DRM_IOCTL_NR(DRM_IOCTL_MODE_SETCRTC) && >> > + nr != DRM_IOCTL_NR(DRM_IOCTL_MODE_RMFB) && >> > + nr != DRM_IOCTL_NR(DRM_IOCTL_MODE_DESTROY_DUMB)) >> > + return -ENODEV; >> >> Why? >> >> Just do: >> >> if (udl_device_is_unplugged(dev)) >> return -ENODEV; >> >> Why this complex logic here? >> >> Thanks >> David >> >> > + >> > + return drm_ioctl(filp, cmd, arg); >> > +} >> > + >> > +void udl_device_set_unplugged(struct drm_device *dev) >> > +{ >> > + struct udl_device *udl = dev->dev_private; >> > + smp_wmb(); >> > + atomic_set(>unplugged, 1); >> > +} >> > + >> > +int udl_device_is_unplugged(struct drm_device *dev) >> > +{ >> > + struct udl_device *udl = dev->dev_private; >> > + int ret = atomic_read(>unplugged); >> > + smp_rmb(); >> > + return ret; >> > +} >> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h >> > index d7162cf..40c6099 100644 >> > --- a/include/drm/drmP.h >> > +++ b/include/drm/drmP.h >> > @@ -748,7 +748,6 @@ struct drm_device { >> > struct drm_minor *control; /**< Control node */ >> > struct drm_minor *primary; /**< Primary node */ >> > struct drm_minor *render; /**< Render node */ >> > - atomic_t unplugged; /**< Flag whether dev >> is dead */ >> > struct inode *anon_inode; /**< inode for private >> address-space */ >> > char *unique; /**< unique name of the >> device */ >> > /*@} */ >> > @@ -879,19 +878,6 @@ static __inline__ int >> drm_core_check_feature(struct drm_device *dev, >> > return ((dev->driver->driver_features & feature) ? 1 : 0); >> > } >> > >> > -static inline void drm_device_set_unplugged(struct drm_device *dev) >> > -{ >> > - smp_wmb(); >> > - atomic_set(>unplugged, 1); >> > -} >> > - >> > -static inline int drm_device_is_unplugged(struct drm_device *dev) >> > -{ >> > - int ret = atomic_read(>unplugged); >> > - smp_rmb(); >> > - return ret; >> > -} >> > - >> > static inline bool drm_is_render_client(const struct drm_file >> *file_priv) >> > { >> > return file_priv->minor->type == DRM_MINOR_RENDER; >> > -- >> > 2.7.0.rc3.207.g0ac5344 >> > >> > > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160210/090990a7/attachment-0001.html>

[PATCH 2/2] drm: make unplugged flag specific to udl driver

if (udl_device_is_unplugged(dev)) > return -ENODEV; > > Why this complex logic here? > > Thanks > David > > > + > > + return drm_ioctl(filp, cmd, arg); > > +} > > + > > +void udl_device_set_unplugged(struct drm_device *dev) > > +{ > > + struct udl_device *udl = dev->dev_private; > > + smp_wmb(); > > + atomic_set(>unplugged, 1); > > +} > > + > > +int udl_device_is_unplugged(struct drm_device *dev) > > +{ > > + struct udl_device *udl = dev->dev_private; > > + int ret = atomic_read(>unplugged); > > + smp_rmb(); > > + return ret; > > +} > > diff --git a/include/drm/drmP.h b/include/drm/drmP.h > > index d7162cf..40c6099 100644 > > --- a/include/drm/drmP.h > > +++ b/include/drm/drmP.h > > @@ -748,7 +748,6 @@ struct drm_device { > > struct drm_minor *control; /**< Control node */ > > struct drm_minor *primary; /**< Primary node */ > > struct drm_minor *render; /**< Render node */ > > - atomic_t unplugged; /**< Flag whether dev is > dead */ > > struct inode *anon_inode; /**< inode for private > address-space */ > > char *unique; /**< unique name of the > device */ > > /*@} */ > > @@ -879,19 +878,6 @@ static __inline__ int drm_core_check_feature(struct > drm_device *dev, > > return ((dev->driver->driver_features & feature) ? 1 : 0); > > } > > > > -static inline void drm_device_set_unplugged(struct drm_device *dev) > > -{ > > - smp_wmb(); > > - atomic_set(>unplugged, 1); > > -} > > - > > -static inline int drm_device_is_unplugged(struct drm_device *dev) > > -{ > > - int ret = atomic_read(>unplugged); > > - smp_rmb(); > > - return ret; > > -} > > - > > static inline bool drm_is_render_client(const struct drm_file > *file_priv) > > { > > return file_priv->minor->type == DRM_MINOR_RENDER; > > -- > > 2.7.0.rc3.207.g0ac5344 > > > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160210/0c13b13d/attachment-0001.html>

[Bug 35457] [rs690m] Graphics corruption with ati x1200

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160210/5dbe2f32/attachment.html>

[Bug 35457] [rs690m] Graphics corruption with ati x1200

dri-devel/attachments/20160210/f68f61b6/attachment-0001.html>

[Bug 89686] x1250 rs600m graphic problems / unreadable fonts in (gl?)- games

are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160210/55f303a1/attachment.html>

[PATCH 2/2] drm: make unplugged flag specific to udl driver

t; Why? > > Just do: > > if (udl_device_is_unplugged(dev)) > return -ENODEV; > > Why this complex logic here? > > Thanks > David > > > + > > + return drm_ioctl(filp, cmd, arg); > > +} > > + > > +void udl_device_set_unplugged(struct drm_device *dev) > > +{ > > + struct udl_device *udl = dev->dev_private; > > + smp_wmb(); > > + atomic_set(>unplugged, 1); > > +} > > + > > +int udl_device_is_unplugged(struct drm_device *dev) > > +{ > > + struct udl_device *udl = dev->dev_private; > > + int ret = atomic_read(>unplugged); > > + smp_rmb(); > > + return ret; > > +} > > diff --git a/include/drm/drmP.h b/include/drm/drmP.h > > index d7162cf..40c6099 100644 > > --- a/include/drm/drmP.h > > +++ b/include/drm/drmP.h > > @@ -748,7 +748,6 @@ struct drm_device { > > struct drm_minor *control; /**< Control node */ > > struct drm_minor *primary; /**< Primary node */ > > struct drm_minor *render; /**< Render node */ > > - atomic_t unplugged; /**< Flag whether dev is > dead */ > > struct inode *anon_inode; /**< inode for private > address-space */ > > char *unique; /**< unique name of the > device */ > > /*@} */ > > @@ -879,19 +878,6 @@ static __inline__ int drm_core_check_feature(struct > drm_device *dev, > > return ((dev->driver->driver_features & feature) ? 1 : 0); > > } > > > > -static inline void drm_device_set_unplugged(struct drm_device *dev) > > -{ > > - smp_wmb(); > > - atomic_set(>unplugged, 1); > > -} > > - > > -static inline int drm_device_is_unplugged(struct drm_device *dev) > > -{ > > - int ret = atomic_read(>unplugged); > > - smp_rmb(); > > - return ret; > > -} > > - > > static inline bool drm_is_render_client(const struct drm_file > *file_priv) > > { > > return file_priv->minor->type == DRM_MINOR_RENDER; > > -- > > 2.7.0.rc3.207.g0ac5344 > > > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160210/5d822564/attachment-0001.html>

[PATCH] drm/exynos: support exynos5422 mipi-dsi

Hi Chanho Park On 30 January 2016 at 14:11, Chanho Park wrote: > --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c > static struct of_device_id exynos_dsi_of_match[] = { If you feel extra gracious you can constify the array and all of it's entries,

[Bug 92806] 1 second freezes during new effects UT4

tps://lists.freedesktop.org/archives/dri-devel/attachments/20160210/46ac0d42/attachment.html>

[PATCH] drm: fixes when i2c encoder slave mode_fixup is null.

thanks daniel. I'll check all i2c slave encoders and submit a patch set. On 10-02-2016 12:25, Daniel Vetter wrote: > On Wed, Feb 10, 2016 at 12:08:38PM +, Carlos Palminha wrote: >> Avoid i2c slave encoder drivers to copy/paste code to implement functions >> that will >> only return true. >>

[PATCH v2] drm: fixes when bridge mode_fixup is null.

I'll send a v3 patch with the removal for dw-hdmi On 10-02-2016 12:22, Daniel Vetter wrote: > On Wed, Feb 10, 2016 at 11:21:16AM +, Carlos Palminha wrote: >> Avoid drivers to copy/past code to implement functions that will only return >> true. >> >> Changes v1->v2: >> * Added Signed off by >>

linux-next: build failure after merge of the drm-misc tree

Hi all, After merging the drm-misc tree, today's linux-next build (arm multi_v7_defconfig) failed like this: In file included from drivers/gpu/drm/nouveau/nouveau_drm.c:25:0: include/linux/apple-gmux.h: In function 'apple_gmux_present': include/linux/apple-gmux.h:36:42: error: implicit

[PATCH] drm: fixes crct set_mode when encoder mode_fixup is null.

Avoids null crash when encoders don't implement mode_fixup. Signed-off-by: Carlos Palminha --- drivers/gpu/drm/drm_crtc_helper.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index

[PATCH] drm: fixes when i2c encoder slave mode_fixup is null.

Avoid i2c slave encoder drivers to copy/paste code to implement functions that will only return true. Signed-off-by: Carlos Palminha --- drivers/gpu/drm/drm_encoder_slave.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_encoder_slave.c

[PATCH v2] drm: fixes when bridge mode_fixup is null.

Avoid drivers to copy/past code to implement functions that will only return true. Changes v1->v2: * Added Signed off by Signed-off-by: Carlos Palminha --- drivers/gpu/drm/drm_bridge.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_bridge.c

[PATCH] drm: fixes when bridge mode_fixup is null.

Avoid drivers to copy/past code to implement functions that will only return true. --- drivers/gpu/drm/drm_bridge.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c index bd93453..4133e51 100644 --- a/drivers/gpu/drm/drm_bridge.c

PROBLEM: Intel HDMI output busticated on 4.4 (regression)

On Tue, 09 Feb 2016, Nick Bowler wrote: > On 2/9/16, Ville Syrjälä wrote: >> BTW I'm not at all convinced about the current live status bit defines >> we have for g4x. Supposedly someone tested them and found that they >> don't match the spec, but IIRC when I tried them on one g4x machine >>

[PATCH 2/5] drm/i915: fix error path in intel_setup_gmbus()

On Tue, 09 Feb 2016, Jani Nikula wrote: > On Tue, 09 Feb 2016, Rasmus Villemoes wrote: >> This fails to undo the setup for pin==0; moreover, something >> interesting happens if the setup failed already at pin==0. >> >> Signed-off-by: Rasmus Villemoes >> --- >> drivers/gpu/drm/i915/intel_i2c.c

[Bug 70514] Unresponsive system on boot with radeon + FireGL v7700

tps://lists.freedesktop.org/archives/dri-devel/attachments/20160210/c3d6fb4f/attachment.html>

[Bug 70514] Unresponsive system on boot with radeon + FireGL v7700

ent was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160210/548c8d1f/attachment.html>

[PATCH] adv7511: Added mode_fixup function.

Hi guys, I agree that this should be fixed in the helper library. There are already a lot of drivers that copy/paste code and several helper functions that do not avoid it. I will start sending some patches to fix this type of issue in several places of DRM helper functions. Regards,

[PATCH] drm/exynos: support exynos5422 mipi-dsi

On 01/30/2016 03:11 PM, Chanho Park wrote: > From: Chanho Park > > This patch supports mipi dsi for exynos5422. The dsi register > offsets of the exynos5422 are similar with exynos5433. However, > the values of the registers are quite different from the > exynos5433. For example, the exynos5422

linux-next: build failure after merge of the drm-misc tree

[cc += Rafael J. Wysocki, linux-acpi] Hi Stephen, On Wed, Feb 10, 2016 at 12:24:51PM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the drm-misc tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > In file included from

[PATCH] drm: fixes when bridge mode_fixup is null.

On Wed, Feb 10, 2016 at 9:03 AM, Carlos Palminha wrote: > Avoid drivers to copy/past code to implement functions that will only return > true. > --- You missed your Signed-off-by.

[PATCH 1/5] drm/gma500: fix error path in gma_intel_setup_gmbus()

On Tue, Feb 9, 2016 at 10:11 PM, Rasmus Villemoes wrote: > The current code fails to call i2c_del_adapter on > dev_prev->gmbus[0].adapter, and if the for loop above failed already > at i==0, all hell breaks loose when we do the loop body for > i = -1,-2,... > Reviewed-by: Andy Shevchenko >

[PATCH 1/5] drm/gma500: fix error path in gma_intel_setup_gmbus()

On Wed, Feb 10, 2016 at 08:41:17AM +0200, Andy Shevchenko wrote: > On Tue, Feb 9, 2016 at 10:11 PM, Rasmus Villemoes > wrote: > > The current code fails to call i2c_del_adapter on > > dev_prev->gmbus[0].adapter, and if the for loop above failed already > > at i==0, all hell breaks loose when we

linux-next: build failure after merge of the drm-misc tree

On Wed, Feb 10, 2016 at 12:24:51PM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the drm-misc tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > In file included from drivers/gpu/drm/nouveau/nouveau_drm.c:25:0: > include/linux/apple-gmux.h: In function

[PATCH 2/2] drm: make unplugged flag specific to udl driver

On Tue, Feb 09, 2016 at 01:05:43PM -0800, Haixia Shi wrote: > Remove the general drm_device_is_unplugged() checks, and move the unplugged > flag handling logic into drm/udl. In general we want to keep driver-specific > logic out of common drm code. > > Signed-off-by: Haixia Shi > Reviewed-by:

PROBLEM: Intel HDMI output busticated on 4.4 (regression)

I checked locally in BDC, Seems we don't have these boards available with us (in working state). Regards Shashank -Original Message- From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] Sent: Tuesday, February 09, 2016 11:53 PM To: Sharma, Shashank Cc: Nick Bowler; Daniel