[Bug 97681] !Aleppo! Hp Printer(1844)(305)(5565)Support Phone Number Massachusetts,New Jersey,Connecticut,Vermont

Component|DRM/amdkfd |/dev/null -- 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/20160908/5f117cf4/attachment.html>

[Bug 97681] !Aleppo! Hp Printer(1844)(305)(5565)Support Phone Number Massachusetts,New Jersey,Connecticut,Vermont

You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/0ec6fe45/attachment.html>

[PATCH v2 0/9] drm/sun4i: Introduce A33 display driver

ists.freedesktop.org/archives/dri-devel/attachments/20160908/3317dcfb/attachment.sig>

[PATCH] drm/radeon: add missing header dependencies

We get a few warnings when building kernel with W=1: drivers/gpu/drm/radeon/radeon_clocks.c:35:10: warning: no previous prototype for 'radeon_legacy_get_engine_clock' [-Wmissing-prototypes] drivers/gpu/drm/radeon/atombios_encoders.c:75:1: warning: no previous prototype for

[PATCH] drm/tilcdc: mark symbols static where possible

We get 3 warnings when building kernel with W=1: drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c:142:29: warning: no previous prototype for 'tilcdc_get_overlay' [-Wmissing-prototypes] drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c:198:13: warning: no previous prototype for 'tilcdc_convert_slave_node'

[PATCH] drm/tilcdc: add missing header dependencies

We get 4 warnings when building kernel with W=1: drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:393:12: warning: no previous prototype for 'tilcdc_tfp410_init' [-Wmissing-prototypes] drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:398:13: warning: no previous prototype for 'tilcdc_tfp410_fini'

[PATCH] drm/vc4: mark vc4_bo_cache_purge() static

We get 1 warning when building kernel with W=1: drivers/gpu/drm/vc4/vc4_bo.c:147:6: warning: no previous prototype for 'vc4_bo_cache_purge' [-Wmissing-prototypes] In fact, this function is only used in the file in which it is declared and don't need a declaration, but can be made static. So this

[PATCH] drm/sun4i: add missing header dependencies

We get 5 warnings when building kernel with W=1: drivers/gpu/drm/sun4i/sun4i_framebuffer.c:33:23: warning: no previous prototype for 'sun4i_framebuffer_init' [-Wmissing-prototypes] drivers/gpu/drm/sun4i/sun4i_framebuffer.c:47:6: warning: no previous prototype for 'sun4i_framebuffer_free'

[PATCH] drm/radeon: mark symbols static where possible

We get 4 warnings when building kernel with W=1: drivers/gpu/drm/radeon/si.c:7868:5: warning: no previous prototype for 'si_vce_send_vcepll_ctlreq' [-Wmissing-prototypes] drivers/gpu/drm/radeon/radeon_dp_mst.c:226:21: warning: no previous prototype for 'radeon_mst_best_encoder'

[PATCH] gpu: Remove depends on RESET_CONTROLLER when not a provider

These GPU drivers only depend on the RESET_CONTROLLER config option to fix build issues that existed when there weren't stub reset APIs for reset controller consumers. Given that these drivers aren't providing any reset controllers themselves, they don't actually depend on the API to build (just

[PATCH v3 08/15] drm: hdlcd: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()

Hi Liviu, On Monday 25 Jul 2016 12:10:24 Liviu Dudau wrote: > On Thu, Jun 09, 2016 at 10:01:40AM +0100, Liviu Dudau wrote: > > On Thu, Jun 09, 2016 at 02:32:12AM +0300, Laurent Pinchart wrote: > > > The driver needs the number of bytes per pixel, not the bpp and depth > > > info meant for fbdev

[PATCH v4 14/14] drm: Don't export the drm_fb_get_bpp_depth() function

The function is only used by the drm_helper_mode_fill_fb_struct() core function to fill the drm_framebuffer bpp and depth fields, used by drivers that haven't been converted to use pixel formats directly yet. It should not be used by new drivers, so inline it in its only caller. Signed-off-by:

[PATCH v4 13/14] drm/arm: mali-dp: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()

The driver doesn't need the color depth, only the number of bits per pixel. Use the right API. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/arm/malidp_hw.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/gpu/drm/arm/malidp_hw.c

[PATCH v4 12/14] drm: vmwgfx: Replace drm_fb_get_bpp_depth() with drm_format_info()

The driver is the last users of the drm_fb_get_bpp_depth() function. It should ideally be converted to use struct drm_mode_fb_cmd2 instead of the legacy struct drm_mode_fb_cmd internally, but that will require broad changes across the code base. As a first step, replace drm_fb_get_bpp_depth() with

[PATCH v4 11/14] drm: radeon: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()

The driver needs the number of bytes per pixel, not the bpp and depth info meant for fbdev compatibility. Use the right API. Signed-off-by: Laurent Pinchart --- Changes since v3: - Renamed bpp to cpp --- drivers/gpu/drm/radeon/radeon_fb.c | 20 ++--

[PATCH v4 10/14] drm: amdgpu: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()

The driver needs the number of bytes per pixel, not the bpp and depth info meant for fbdev compatibility. Use the right API. Signed-off-by: Laurent Pinchart --- Changes since v3: - Renamed bpp to cpp --- drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 14 +++---

[PATCH v4 09/14] drm: gma500: Replace drm_fb_get_bpp_depth() with drm_format_info()

The driver uses drm_fb_get_bpp_depth() to check whether it can support the format requested by userspace when creating a framebuffer. This isn't the right API, as it doesn't differentiate between RGB formats other than on a depth and bpp basis. Fixing this requires non trivial changes to the

[PATCH v4 08/14] drm: cirrus: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()

The driver doesn't need the color depth, only the number of bits per pixel. Use the right API. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/cirrus/cirrus_fbdev.c | 6 +++--- drivers/gpu/drm/cirrus/cirrus_main.c | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) Cc: Dave Airlie

[PATCH v4 07/14] drm: tilcdc: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()

The driver needs the number of bytes per pixel, not the bpp and depth info meant for fbdev compatibility. Use the right API. In the tilcdc_crtc_mode_set() function compute the hardware register value directly from the pixel format instead of computing the number of bits per pixels first.

[PATCH v4 06/14] drm: hdlcd: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()

The driver needs the number of bytes per pixel, not the bpp and depth info meant for fbdev compatibility. Use the right API. Signed-off-by: Laurent Pinchart Acked-by: Liviu Dudau --- drivers/gpu/drm/arm/hdlcd_crtc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) Cc: Liviu Dudau

[PATCH v4 05/14] drm: sti: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()

The driver needs the number of bytes per pixel, not the bpp and depth info meant for fbdev compatibility. Use the right API. Signed-off-by: Laurent Pinchart Acked-by: Vincent Abriou --- drivers/gpu/drm/sti/sti_gdp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Cc: Benjamin

[PATCH v4 04/14] drm: WARN when calling drm_format_info() for an unsupported format

The format helpers have historically treated unsupported formats as part of the default case, returning values that are likely wrong. We can't change this behaviour now without risking breaking drivers in difficult to detect ways, but we can WARN on unsupported formats to catch faulty callers.

[PATCH v4 03/14] drm: Use drm_format_info() in DRM core code

Replace calls to the drm_format_*() helper functions with direct use of the drm_format_info structure. This improves efficiency by removing duplicate lookups. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/drm_fb_cma_helper.c | 23 drivers/gpu/drm/drm_framebuffer.c | 102

[PATCH v4 02/14] drm: Implement the drm_format_*() helpers as drm_format_info() wrappers

Turn the drm_format_*() helpers into wrappers around the drm_format_info lookup function to centralize all format information in a single place. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/drm_fourcc.c | 186 +-- 1 file changed, 37 insertions(+),

[PATCH v4 01/14] drm: Centralize format information

Various pieces of information about DRM formats (number of planes, color depth, chroma subsampling, ...) are scattered across different helper functions in the DRM core. Callers of those functions often need to access more than a single parameter of the format, leading to inefficiencies due to

[PATCH v4 00/14] Centralize format information

Hello, Various pieces of information about DRM formats (number of planes, color depth, chroma subsampling, ...) are scattered across different helper functions in the DRM core. Callers of those functions often need to access more than a single parameter of the format, leading to inefficiencies

[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.

On Thu, Sep 08, 2016 at 05:21:42PM +0200, Mario Kleiner wrote: > On 09/08/2016 08:30 AM, Chris Wilson wrote: > >On Thu, Sep 08, 2016 at 02:14:43AM +0200, Mario Kleiner wrote: > >>amdgpu-kms uses shared fences for its prime exported dmabufs, > >>instead of an exclusive fence. Therefore we need to

[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.

On 09/08/2016 08:30 AM, Chris Wilson wrote: > On Thu, Sep 08, 2016 at 02:14:43AM +0200, Mario Kleiner wrote: >> amdgpu-kms uses shared fences for its prime exported dmabufs, >> instead of an exclusive fence. Therefore we need to wait for >> all fences of the dmabuf reservation object to prevent >>

[Bug 97471] kworker consumes 100% of a cpu core when screen sleeps with amdgpu kernel driver.

if that will help. -- 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/20160908/6e3dd999/attachment.html>

[PATCH v3 02/15] drm: Centralize format information

Hello Daniel and Ville, On Thursday 09 Jun 2016 17:13:15 Ville Syrjälä wrote: > On Thu, Jun 09, 2016 at 03:29:10PM +0200, Daniel Vetter wrote: > > On Thu, Jun 09, 2016 at 04:05:11PM +0300, Ville Syrjälä wrote: > >> On Thu, Jun 09, 2016 at 02:40:28PM +0200, Daniel Vetter wrote: > >>> On Thu,

[PATCH v6 2/4] drm: Add API for capturing frame CRCs

On 8 September 2016 at 15:24, Emil Velikov wrote: > Hi Tomeu, > > A couple of small nitpicks and a rather nasty looking bug, related to > your earlier question. > > On 7 September 2016 at 11:27, Tomeu Vizoso > wrote: > >> +static ssize_t crc_control_write(struct file *file, const char __user

[Intel-gfx] [PATCH v6 3/4] drm/i915: Use new CRC debugfs API

On 8 September 2016 at 15:35, Emil Velikov wrote: > Hi Tomeu, > > Just a couple of nitpicks. Nothing that has to be fixed or (if you > agree) cannot be done on top/later on. > > On 7 September 2016 at 11:27, Tomeu Vizoso > wrote: >> The core provides now an ABI to userspace for generation of

[PATCH v7 4/4] drm/i915: Put "cooked" vlank counters in frame CRC lines

Use drm_accurate_vblank_count so we have the full 32 bit to represent the frame counter and userspace has a simpler way of knowing when the counter wraps around. Signed-off-by: Tomeu Vizoso Reviewed-by: Emil Velikov --- drivers/gpu/drm/i915/i915_irq.c | 6 +++--- 1 file changed, 3

[PATCH v7 3/4] drm/i915: Use new CRC debugfs API

The core provides now an ABI to userspace for generation of frame CRCs, so implement the ->set_crc_source() callback and reuse as much code as possible with the previous ABI implementation. When handling the pageflip interrupt, we skip 1 or 2 frames depending on the HW because they contain wrong

[PATCH v7 2/4] drm: Add API for capturing frame CRCs

Adds files and directories to debugfs for controlling and reading frame CRCs, per CRTC: dri/0/crtc-0/crc dri/0/crtc-0/crc/control dri/0/crtc-0/crc/data Drivers can implement the set_crc_source callback() in drm_crtc_funcs to start and stop generating frame CRCs and can add entries to the output

[PATCH v7 1/4] drm/i915/debugfs: Move out pipe CRC code

In preparation to using a generic API in the DRM core for continuous CRC generation, move the related code out of i915_debugfs.c into a new file. Eventually, only the Intel-specific code will remain in this new file. v2: Rebased. v6: Rebased. v7: Fix whitespace issue. Signed-off-by: Tomeu

[PATCH v7 0/4] New debugfs API for capturing CRC of frames

Hi, this series basically takes the facility for continuously capturing CRCs of frames from the i915 driver and into the DRM core. The idea is that test suites such as IGT use this information to check that frames that are exected to be identical, also have identical CRC values. Other drivers

[PATCH v6 2/4] drm: Add API for capturing frame CRCs

On 8 September 2016 at 15:49, Tomeu Vizoso wrote: > On 8 September 2016 at 15:24, Emil Velikov > wrote: >> Hi Tomeu, >> >> A couple of small nitpicks and a rather nasty looking bug, related to >> your earlier question. >> >> On 7 September 2016 at 11:27, Tomeu Vizoso >> wrote: >> >>> +static

[PATCH v8 04/12] drm: Helper to read max bits per component

On Wed, Aug 17, 2016 at 01:49:40PM +0300, Mika Kahola wrote: > Helper routine to read out maximum supported bits per > component for DisplayPort legay converters. > > v2: Return early if detailed port cap info is not available. > Replace if-else ladder with switch-case (Ville) > >

[PATCH v8 03/12] drm: Helper to read max clock rate

On Wed, Aug 17, 2016 at 01:49:39PM +0300, Mika Kahola wrote: > Helper routine to read out maximum supported pixel rate > for DisplayPort legay VGA converter or TMDS clock rate > for other digital legacy converters. The helper returns > clock rate in kHz. > > v2: Return early if detailed port cap

[PATCH] drm/tilcdc: mark symbols static where possible

On 09/08/16 14:29, Baoyou Xie wrote: > We get 3 warnings when building kernel with W=1: > drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c:142:29: warning: no previous > prototype for 'tilcdc_get_overlay' [-Wmissing-prototypes] > drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c:198:13: warning: no

[PATCH] drm/tilcdc: add missing header dependencies

On 09/08/16 14:08, Baoyou Xie wrote: > We get 4 warnings when building kernel with W=1: > drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:393:12: warning: no previous prototype > for 'tilcdc_tfp410_init' [-Wmissing-prototypes] > drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:398:13: warning: no previous prototype

[Bug 69076] [r300g] RS690: triangle flickering

-- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/502e205c/attachment-0001.html>

[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

On Thu, Sep 08, 2016 at 01:09:23PM +0200, Martin van Es wrote: > On donderdag 8 september 2016 13:18:41 CEST Ville Syrjälä wrote: > > On Thu, Sep 08, 2016 at 12:04:39PM +0200, Martin van Es wrote: > > > On dinsdag 6 september 2016 21:40:48 CEST Ville Syrjälä wrote: > > > > On Tue, Sep 06, 2016

[PATCH v2 1/2] mm: fix cache mode of dax pmd mappings

On Wed, 07 Sep 2016 15:26:14 -0700 Dan Williams wrote: > track_pfn_insert() in vmf_insert_pfn_pmd() is marking dax mappings as > uncacheable rendering them impractical for application usage. DAX-pte > mappings are cached and the goal of establishing DAX-pmd mappings is to > attain more

[PATCH v8 12/12] drm/i915: Check TMDS clock DP to HDMI dongle

On Wed, Aug 17, 2016 at 01:49:49PM +0300, Mika Kahola wrote: > Respect max TMDS clock frequency from DPCD for active > DP to HDMI adapters. > > Signed-off-by: Mika Kahola > --- > drivers/gpu/drm/i915/intel_drv.h | 3 +++ > drivers/gpu/drm/i915/intel_hdmi.c | 27 +++ >

[PATCH 2/2] drm/ttm: move placement structures into ttm_placement.h

From: Christian König Makes more sense to keep that together. Signed-off-by: Christian König --- include/drm/ttm/ttm_bo_api.h| 32 +--- include/drm/ttm/ttm_placement.h | 35 +++ 2 files changed, 36

[PATCH 1/2] drm/ttm: remove unused placement flags

From: Christian König Either never used or not used in quite a while. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c| 2 +- include/drm/ttm/ttm_placement.h | 19 --- 2 files changed, 1 insertion(+), 20 deletions(-) diff --git

[Intel-gfx] [PATCH 1/1] drm/i915/dsi: silence a warning about uninitialized return value

On 08/09/16 00:02, Nicolas Iooss wrote: > On 07/09/16 18:03, Dave Gordon wrote: >> On 06/09/16 21:36, Nicolas Iooss wrote: >>> On 06/09/16 12:21, Dave Gordon wrote: On 04/09/16 19:58, Nicolas Iooss wrote: > When building the kernel with clang and some warning flags, the > compiler

[PATCH v3] drm: modify drm_global_item_ref to avoid two times of writing ref->object

On Thu, Sep 08, 2016 at 02:36:06PM +0800, Chris Wilson wrote: > On Wed, Sep 07, 2016 at 10:07:57PM -0400, Huang Rui wrote: > > In previous drm_global_item_ref, there are two times of writing > > ref->object if item->refcount is 0. So this patch does a minor update > > to put alloc and init ref

[PATCH] drm/sun4i: add missing header dependencies

-- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/1db356f3/attachment.sig>

[Intel-gfx] [PATCH v6 0/4] New debugfs API for capturing CRC of frames

On 7 September 2016 at 11:27, Tomeu Vizoso wrote: > Hi, > > this series basically takes the facility for continuously capturing CRCs > of frames from the i915 driver and into the DRM core. > > The idea is that test suites such as IGT use this information to check > that frames that are exected

[Intel-gfx] [PATCH v6 3/4] drm/i915: Use new CRC debugfs API

Hi Tomeu, Just a couple of nitpicks. Nothing that has to be fixed or (if you agree) cannot be done on top/later on. On 7 September 2016 at 11:27, Tomeu Vizoso wrote: > The core provides now an ABI to userspace for generation of frame CRCs, > so implement the ->set_crc_source() callback and

[PATCH v6 2/4] drm: Add API for capturing frame CRCs

Hi Tomeu, A couple of small nitpicks and a rather nasty looking bug, related to your earlier question. On 7 September 2016 at 11:27, Tomeu Vizoso wrote: > +static ssize_t crc_control_write(struct file *file, const char __user *ubuf, > +size_t len, loff_t *offp)

[PATCH v3 4/4] ARM: sunxi: Enable VGA bridge

Enable the VGA bridge used on the A13-Olinuxino in the sunxi defconfig Signed-off-by: Maxime Ripard --- arch/arm/configs/sunxi_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig index 714da336ec86..d830e258db59

[PATCH v3 3/4] ARM: multi_v7: enable VGA bridge

Enable the RGB to VGA bridge driver in the defconfig Signed-off-by: Maxime Ripard --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 2c8665cd9dc5..22ef41afc658 100644 ---

[PATCH v3 2/4] ARM: sun5i: a13-olinuxino: Enable VGA bridge

Now that we have support for the VGA bridges using our DRM driver, enable the display engine for the Olimex A13-Olinuxino. Signed-off-by: Maxime Ripard --- arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 60 +++ 1 file changed, 60 insertions(+) diff --git

[PATCH v3 1/4] drm/bridge: Add RGB to VGA bridge support

Some boards have an entirely passive RGB to VGA bridge, based on either DACs or resistor ladders. Those might or might not have an i2c bus routed to the VGA connector in order to access the screen EDIDs. Add a bridge that doesn't do anything but expose the modes available on the screen, either

[PATCH v3 0/4] drm: Add Support for Passive RGB to VGA bridges

Hi, This serie is about adding support for the RGB to VGA bridge found in the A13-Olinuxino and the CHIP VGA adapter. Both these boards rely on an entirely passive bridge made out of resitor ladders that do not require any initialisation. The only thing needed is to get the timings from the

[PATCH 1/2] libdrm: add etnaviv drm support

On Thu, Sep 8, 2016 at 1:52 PM, Rob Herring wrote: > On Thu, Sep 1, 2016 at 2:08 PM, Christian Gmeiner > wrote: >> Hi Emil, >> >> thanks a lot for the review. >> >> 2016-08-30 15:03 GMT+02:00 Emil Velikov : >>> On 30 August 2016 at 08:14, Christian Gmeiner >>> wrote: From: The etnaviv

[PATCH 1/2] libdrm: add etnaviv drm support

On Thu, Sep 1, 2016 at 2:08 PM, Christian Gmeiner wrote: > Hi Emil, > > thanks a lot for the review. > > 2016-08-30 15:03 GMT+02:00 Emil Velikov : >> On 30 August 2016 at 08:14, Christian Gmeiner >> wrote: >>> From: The etnaviv authors >>> >>> Add the libdrm_etnaviv helper library to

[Bug 97639] Intermittent flickering artifacts with AMD R7 260x

... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/0e0363fb/attachment.html>

[Bug 97639] Intermittent flickering artifacts with AMD R7 260x

xserver v1.17.4 KDE Plasma 5 (kwin) If you need any further info please ask. -- 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

[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

On Thu, Sep 08, 2016 at 12:04:39PM +0200, Martin van Es wrote: > On dinsdag 6 september 2016 21:40:48 CEST Ville Syrjälä wrote: > > On Tue, Sep 06, 2016 at 01:56:20PM +0300, Ville Syrjälä wrote: > > > Actually I just cooked up another branch [2]. It just throws in some > > > memory barriers to

[PATCH v8 03/12] drm: Helper to read max clock rate

> -Original Message- > From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com] > Sent: Thursday, September 8, 2016 4:02 PM > To: Kahola, Mika > Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; > jim.bride at linux.intel.com; daniel.vetter at ffwll.ch >

[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

On donderdag 8 september 2016 13:18:41 CEST Ville Syrjälä wrote: > On Thu, Sep 08, 2016 at 12:04:39PM +0200, Martin van Es wrote: > > On dinsdag 6 september 2016 21:40:48 CEST Ville Syrjälä wrote: > > > On Tue, Sep 06, 2016 at 01:56:20PM +0300, Ville Syrjälä wrote: > > > > Actually I just

[PATCH] drm: Fix error path in drm_mode_page_flip_ioctl()

On 08/09/16 02:23 AM, Imre Deak wrote: > This fixes the error path for platforms that don't define the new > page_flip_target() hook. > > Fixes: c229bfbbd04 ("drm: Add page_flip_target CRTC hook v2") > Testcase: igt/kms_flip/basic-flip-vs-dpms > CC: Michel Dänzer > Signed-off-by: Imre Deak >

[PATCH 6/6] drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags v2

idea has support! Thanks, pq > I'd like to add that the X11 Present extension specification already > includes support for specifying a target time instead of a target > refresh cycle. This isn't implemented yet though, but it should be > relatively straightforward to implement using the kind of kernel API you > describe. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/060525fe/attachment.sig>

[PULL] topic/drm-misc

Hi Dave - Here's a drm-misc pull request mainly to get some fixes moving forward. BR, Jani. The following changes since commit 2b2fd56d7e92f134ecaae5c89e20f64dd0f95aa2: Revert "drm: make DRI1 drivers depend on BROKEN" (2016-09-01 06:16:12 +1000) are available in the git repository at:

[PATCH v8 10/12] drm/i915: Update bits per component for display info

Thanks for the review. I'll fix those indentations. > -Original Message- > From: Jim Bride [mailto:jim.bride at linux.intel.com] > Sent: Thursday, September 8, 2016 12:27 AM > To: Kahola, Mika > Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; > ville.syrjala

[PATCH v2] drm: Move property validation to a helper, v2.

Property lifetimes are equal to the device lifetime, so the separate drm_property_find is not needed. The pointer can be retrieved from the properties member, which saves us some locking and a extra lookup. The lifetime for properties is until the device is destroyed, which happens late in the

[PATCH 001/001] drivers/gpu/radeon: NULL pointer deference workaround

Am 08.09.2016 um 11:09 schrieb Mark Fortescue: > Hi Christian, > > Thank you for the feedback. > > On 08/09/16 08:14, Christian König wrote: >> Am 07.09.2016 um 19:38 schrieb Mark Fortescue: >>> >>> On an LV-683 (AMD Dual-core G-T56N) Mini-ITX board, I get a Kernel >>> Oops because Connector 0

[PULL] drm-intel-fixes

Hi Dave, some i915 fixes for v4.8. BR, Jani. The following changes since commit 3eab887a55424fc2c27553b7bfe32330df83f7b8: Linux 4.8-rc4 (2016-08-28 15:04:33 -0700) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-09-08 for you to

[PATCH 001/001] drivers/gpu/radeon: NULL pointer deference workaround

On 08/09/16 11:25, Christian König wrote: > Am 08.09.2016 um 11:09 schrieb Mark Fortescue: >> Hi Christian, >> >> Thank you for the feedback. >> >> On 08/09/16 08:14, Christian König wrote: >>> Am 07.09.2016 um 19:38 schrieb Mark Fortescue: On an LV-683 (AMD Dual-core G-T56N) Mini-ITX

[Intel-gfx] [PATCH] drm: Fix error path in drm_mode_page_flip_ioctl()

On Thu, 08 Sep 2016, Michel Dänzer wrote: > On 08/09/16 02:23 AM, Imre Deak wrote: >> This fixes the error path for platforms that don't define the new >> page_flip_target() hook. >> >> Fixes: c229bfbbd04 ("drm: Add page_flip_target CRTC hook v2") >> Testcase: igt/kms_flip/basic-flip-vs-dpms >>

linux-next: manual merge of the drm-intel tree with Linus' tree

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in: drivers/gpu/drm/i915/intel_pm.c between commit: 9909113cc48a ("drm/i915/gen9: Only copy WM results for changed pipes to skl_hw") from Linus' tree and commits: 2722efb90b34 ("drm/i915/gen9: Only copy WM results

[PATCH] drm/sti: mark symbols static where possible

Acked-by: Benjamin Gaignard 2016-09-07 13:05 GMT+02:00 Baoyou Xie : > We get 2 warnings when building kernel with W=1: > drivers/gpu/drm/sti/sti_mixer.c:361:6: warning: no previous prototype for > 'sti_mixer_set_matrix' [-Wmissing-prototypes] > drivers/gpu/drm/sti/sti_dvo.c:109:5: warning: no

[PATCH 1/1] drm: i915: don't use OpRegion for XPS 13 IvyBridge

On dinsdag 6 september 2016 21:40:48 CEST Ville Syrjälä wrote: > On Tue, Sep 06, 2016 at 01:56:20PM +0300, Ville Syrjälä wrote: > > Actually I just cooked up another branch [2]. It just throws in some > > memory barriers to the opregion code, and adds a a new debug print so > > to show the

[PATCH 5/6] ARM: dts: Add NextThing GR8 dtsi

ocuments the underscore as being a valid character for the node names. I'll change the few inconsistencies though. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/aae07d1e/attachment.sig>

[PATCH 5/6] ARM: dts: Add NextThing GR8 dtsi

art -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/d7268678/attachment-0001.sig>

[PATCH] drm/sti: mark symbols static where possible

On Thursday, September 8, 2016 10:35:17 AM CEST Emil Velikov wrote: > On 7 September 2016 at 12:05, Baoyou Xie wrote: > > We get 2 warnings when building kernel with W=1: > As you're going through DRM I was wondering if you have a rough number > of warnings we get at the various W levels 1,2,...

[PATCH v8 08/12] drm/i915: Read DP branch device SW revision

> -Original Message- > From: Jim Bride [mailto:jim.bride at linux.intel.com] > Sent: Thursday, September 8, 2016 12:20 AM > To: Kahola, Mika > Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; > ville.syrjala at linux.intel.com; daniel.vetter at ffwll.ch >

[PATCH v2 2/2] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

Make sure the request PSR state could effect in analogix_dp_send_psr_spd() function, or printing the error Sink PSR state if we failed to effect the request PSR setting. Signed-off-by: Yakir Yang --- Changes in v2: - A bunch of good fixes from Sean

[PATCH v2 1/2] drm/bridge: analogix_dp: Remove duplicated code v2

From: Tomeu Vizoso Remove code for reading the EDID and DPCD fields and use the helpers instead. Besides the obvious code reduction, other helpers are being added to the core that could be used in this driver and will be good to be able to use them instead of

[Bug 69076] [r300g] RS690: triangle flickering

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

[Bug 95306] Random Blank(black) screens on "Carrizo"

-- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/6f5680a0/attachment-0001.html>

[Bug 97635] radeon fails to initialize some DisplayPort monitors

eens-0-5-good in such a case. Let me know what else I can do to help. -- 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/2

[PATCH v4] dt-bindings: Add jdi lt070me05000 panel bindings

Add documentation for lt070me05000 panel Cc: Archit Taneja Cc: John Stultz Cc: Thierry Reding Cc: Sumit Semwal Signed-off-by: Vinay Simha BN Acked-by: Rob Herring --- v2: * incorporated rob herring and thierry reviews gpio to gpios, gpio to regulator using fixed regulators and pwm

[PATCH] drm/sti: mark symbols static where possible

[Trimming down the CC list] Hi Baoyou, On 7 September 2016 at 12:05, Baoyou Xie wrote: > We get 2 warnings when building kernel with W=1: As you're going through DRM I was wondering if you have a rough number of warnings we get at the various W levels 1,2,... Hope you'll have the time/interest

[PATCH 6/4] arm: dts: qcom: apq8064-nexus7: Add DSI and panel nodes

Regards, vinay simha On Thu, Sep 8, 2016 at 5:02 AM, John Stultz wrote: > Tagging on to Archit's patchset here. > > Add DSI and panel nodes to get graphics up and running > on the Nexus7. > > This still depends on the panel driver being present > (currently under review) along with the rpmclk

[RFC][PATCH 5/4] arm: dts: qcom: apq8064: Add dsi, gpu and iommu nodes

Regards, vinay simha On Thu, Sep 8, 2016 at 5:02 AM, John Stultz wrote: > > Sort of tagging on to Archit's patchset here. > > Adds the core gpu, and dsi nodes for the apq8064 needed > to get graphics working on the nexus7 and other devices. > > Feedback would be greatly appreciated! > > Cc:

[PATCH v2 2/2] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

On Wed, Sep 7, 2016 at 11:48 PM, Yakir Yang wrote: > Make sure the request PSR state could effect in analogix_dp_send_psr_spd() > function, or printing the error Sink PSR state if we failed to effect > the request PSR setting. > Let's change to: Make sure the request PSR state takes effect in

[PATCH v2 0/9] drm/sun4i: Introduce A33 display driver

Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attach

[PATCH 001/001] drivers/gpu/radeon: NULL pointer deference workaround

Hi Christian, Thank you for the feedback. On 08/09/16 08:14, Christian König wrote: > Am 07.09.2016 um 19:38 schrieb Mark Fortescue: >> >> On an LV-683 (AMD Dual-core G-T56N) Mini-ITX board, I get a Kernel >> Oops because Connector 0 (LCD Panel interface) does not have DDC. > > I'm not an

[PATCH v2 1/2] drm/bridge: analogix_dp: Remove duplicated code v2

On Wed, Sep 7, 2016 at 11:48 PM, Yakir Yang wrote: > From: Tomeu Vizoso > > Remove code for reading the EDID and DPCD fields and use the helpers > instead. > > Besides the obvious code reduction, other helpers are being added to the > core that could be used in this driver and will be good to be

[PATCH v3] drm: modify drm_global_item_ref to avoid two times of writing ref->object

Am 08.09.2016 um 09:35 schrieb Chris Wilson: > On Thu, Sep 08, 2016 at 03:22:48PM +0800, Huang Rui wrote: >> On Thu, Sep 08, 2016 at 02:36:06PM +0800, Chris Wilson wrote: >>> On Wed, Sep 07, 2016 at 10:07:57PM -0400, Huang Rui wrote: In previous drm_global_item_ref, there are two times of

[PATCH v2 2/9] drm/sun4i: support A33 tcon

after fixing it. I did while applying, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160908/eeaaa040/attachment.sig>

[Bug 97634] [amdgpu SI] multigpu setup crashes during boot when dpm=1

ing 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/20160908/b2e1ad29/attachment.html>

[PATCH v3] drm: modify drm_global_item_ref to avoid two times of writing ref->object

Am 08.09.2016 um 04:07 schrieb Huang Rui: > In previous drm_global_item_ref, there are two times of writing > ref->object if item->refcount is 0. So this patch does a minor update > to put alloc and init ref firstly, and then to modify the item of glob > array. Use "else" to avoid two times of

[PATCH 001/001] drivers/gpu/radeon: NULL pointer deference workaround

Am 07.09.2016 um 19:38 schrieb Mark Fortescue: > > On an LV-683 (AMD Dual-core G-T56N) Mini-ITX board, I get a Kernel > Oops because Connector 0 (LCD Panel interface) does not have DDC. I'm not an expert on this, but that is really odd cause even LCD Panels should have a DDC interface. > >

  1   2   >