[Intel-gfx] [PATCH v6 14/23] drm/i915: CHV: Pipe level degamma correction

Unless legacy mode enables it of course. Thanks Gary "Smith, Gary K" wrote: Bear in mind that it will only happen after the property has been set. Initially there will be no clients setting the property - so I think it should be OK. Thanks Gary Daniel Vetter wrote: On Mon, Oct 19, 2015

[Intel-gfx] [PATCH v6 14/23] drm/i915: CHV: Pipe level degamma correction

Bear in mind that it will only happen after the property has been set. Initially there will be no clients setting the property - so I think it should be OK. Thanks Gary Daniel Vetter wrote: On Mon, Oct 19, 2015 at 08:39:54PM +, Bish, Jim wrote: > > > On 10/19/2015 11:54 AM, Daniel

[PATCH] drm/vmwgfx: switch from ioremap_cache to memremap

On Tue, 2015-10-13 at 20:52 +0200, Thomas Hellstrom wrote: > > Ok, I'll make local read_fifo() and write_fifo() macros to make this > > explicit. Are these names ok with you? > > Sure. > So I ended up just leaving the __iomem annotation on mmio_virt for now until the implementation can be

[PATCH 6/9] drm/exynos: switch to new buffer allocation

Hi, How about combining patch 5 and 6? Patch 5 just introduces new internal API but these API aren't used anywhere in patch 5. Thanks, Inki Dae 2015년 10월 13일 16:00에 Joonyoung Shim 이(가) 쓴 글: > The buffer allocation using DMA mapping API can't support non-continuous > buffer on

[PATCH 00/10] drm/exynos: add pm_runtime support

Hi Gustavo, Please ping~ and re-base on top of exynos-drm-next. Thanks, Inki Dae 2015년 09월 05일 05:15에 Gustavo Padovan 이(가) 쓴 글: > From: Gustavo Padovan > > Hi, > > This series adds proper runtime PM suport to CRTCs and Encoders, so > now instead of relying on 'suspended' or

[Intel-gfx] [PATCH v6 14/23] drm/i915: CHV: Pipe level degamma correction

On Mon, Oct 19, 2015 at 06:08:52PM +, Smith, Gary K wrote: > FYI - this shouldn't block the commits, but should be optimized later (fairly > soon). > > I believe the current implementation ends up executing > while (count < CHV_DEGAMMA_MAX_VALS) { > //

[Intel-gfx] [PATCH v6 14/23] drm/i915: CHV: Pipe level degamma correction

On 10/19/2015 11:54 AM, Daniel Vetter wrote: > On Mon, Oct 19, 2015 at 06:08:52PM +, Smith, Gary K wrote: >> FYI - this shouldn't block the commits, but should be optimized later >> (fairly soon). >> >> I believe the current implementation ends up executing >> while (count <

[GIT PULL] On-demand device probing

Hello, On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote: > It's a bit ironic that you've chosen GPIO as an example there. The > "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the > gpio descriptor. There's no of_* method. Without following all that

[Bug 106291] New: amdgpu fails GPU reset when resuming from suspend

https://bugzilla.kernel.org/show_bug.cgi?id=106291 Bug ID: 106291 Summary: amdgpu fails GPU reset when resuming from suspend Product: Drivers Version: 2.5 Kernel Version: 4.2.3 Hardware: x86-64 OS: Linux

[GIT PULL] On-demand device probing

On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-König wrote: > Hello, > > On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote: > > It's a bit ironic that you've chosen GPIO as an example there. The > > "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the

[Bug 92524] system hang on "radeon_hwmon_get_pwm1_enable"

use my distro tools to recompile the kernel and do it cleanly, applying the patch on the official Ubuntu kernel tree. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop

[Bug 92544] Tonga fails second resume from mem sleep.

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/7abddf13/attachment-0001.html>

[GIT PULL] On-demand device probing

Hi Russell, On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux wrote: >> > What you can do is print those devices which have failed to probe at >> > late_initcall() time - possibly augmenting that with reports from >> > subsystems showing what resources are not available, but that's only

[PATCH v6 14/23] drm/i915: CHV: Pipe level degamma correction

FYI - this shouldn't block the commits, but should be optimized later (fairly soon). I believe the current implementation ends up executing while (count < CHV_DEGAMMA_MAX_VALS) { // Do lots of caclulation

[GIT PULL] On-demand device probing

On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki wrote: > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote: >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse >> wrote: >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote: >> >> > But the point I'm making is that we are working

[Intel-gfx] [PATCH 1/3] drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings

On Fri, Oct 09, 2015 at 01:54:58PM +0300, Jani Nikula wrote: > On Thu, 08 Oct 2015, Daniel Vetter wrote: > > On Thu, Oct 08, 2015 at 12:22:31PM -0400, Adam Jackson wrote: > >> On Thu, 2015-10-08 at 11:43 +0300, ville.syrjala at linux.intel.com wrote: > >> > From: Ville Syrjälä > >> > > >> >

[PATCH] drm/mgag200: don't pass NULL file_priv to drm_gem_object_lookup()

On Mon, Oct 19, 2015 at 04:27:18AM -0600, Jan Beulich wrote: > Commit bf89209a6d ("drm/mga200g: Hold a proper reference for > cursor_set") clearly didn't take the call site in > drm_fb_helper.c:restore_fbdev_mode() into account, which passes NULL > for file_priv and hence causes

[GIT PULL] On-demand device probing

On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote: > Hi Russell, > > On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux > wrote: > >> > What you can do is print those devices which have failed to probe at > >> > late_initcall() time - possibly augmenting that with reports

[Bug 106271] Switch between AMD hybrid graphics (HD 8650G / HD 8970M) makes hardware reset.

https://bugzilla.kernel.org/show_bug.cgi?id=106271 --- Comment #2 from Aneroid --- Created attachment 190551 --> https://bugzilla.kernel.org/attachment.cgi?id=190551=edit dmesg -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 106271] Switch between AMD hybrid graphics (HD 8650G / HD 8970M) makes hardware reset.

https://bugzilla.kernel.org/show_bug.cgi?id=106271 --- Comment #1 from Aneroid --- Created attachment 190541 --> https://bugzilla.kernel.org/attachment.cgi?id=190541=edit glxinfo -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 106271] New: Switch between AMD hybrid graphics (HD 8650G / HD 8970M) makes hardware reset.

https://bugzilla.kernel.org/show_bug.cgi?id=106271 Bug ID: 106271 Summary: Switch between AMD hybrid graphics (HD 8650G / HD 8970M) makes hardware reset. Product: Drivers Version: 2.5 Kernel Version: 4.2.3 Hardware:

[GIT PULL] On-demand device probing

y we're going to get some parallel ACPI code added to the subsystems for parsing their bindings. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/d5d6cbee/attachment-0001.sig>

[GIT PULL] On-demand device probing

On 19 October 2015 at 16:30, Russell King - ARM Linux wrote: > On Mon, Oct 19, 2015 at 04:10:56PM +0200, Tomeu Vizoso wrote: >> On 19 October 2015 at 15:18, Russell King - ARM Linux >> wrote: >> > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote: >> >> ... If a device is available

[GIT PULL] On-demand device probing

On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote: > I don't know that there *is* a coherent plan here to address it all. > > Certainly, we *will* need subsystems to have firmware-specific > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to > describe GPIO, and

[RFC PATCH v2 1/4] drm: Introduce generic probe function for component based masters.

On Mon, Oct 19, 2015 at 02:26:38PM +0100, Russell King - ARM Linux wrote: > On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote: > > On Mon, Oct 19, 2015 at 01:25:37PM +0100, Russell King - ARM Linux wrote: > > > Please don't move this into here, it's completely inappropriate. Just > > >

[GIT PULL] On-demand device probing

On Mon, Oct 19, 2015 at 05:00:54PM +0200, Tomeu Vizoso wrote: > On 19 October 2015 at 16:30, Russell King - ARM Linux > wrote: > > I typically see one or two, maybe five maximum on the platforms I have > > here, but normally zero. > > Hmm, I have given a look at our lava farm and have seen 2

[PATCH] drm: correctly check failed allocation

drm_property_create_range can be failed in memory pressure Therefore, check return value and handle an error Signed-off-by: Insu Yun --- drivers/gpu/drm/drm_crtc.c | 30 ++ 1 file changed, 30 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c

[GIT PULL] On-demand device probing

crubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/f1e07573/attachment.bin>

[RFC PATCH v3 4/4] drm/armada: Convert the probe function to the generic drm_of_component_probe()

On Mon, Oct 19, 2015 at 04:17:14PM +0100, Russell King - ARM Linux wrote: > On Mon, Oct 19, 2015 at 04:07:50PM +0100, Liviu Dudau wrote: > > The armada DRM driver keeps some old platform data compatibility in the > > probe function that makes moving to the generic drm_of_component_probe() > > a

[RFC PATCH v2 1/4] drm: Introduce generic probe function for component based masters.

On Mon, Oct 19, 2015 at 04:04:27PM +0100, Emil Velikov wrote: > Unlike Daniel, I carry little to no weight here, yet bashing on people > if they don't get things correct the first time is inconsiderable. > We are people - we can misread/misinterpret things, have a headache > and/or just a bad day.

[regression] [git pull] drm for 4.3

On Wed, Sep 30, 2015 at 08:56:26AM +0200, Daniel Vetter wrote: > > The warning on boot seems to be gone as of rc3, but I can now trigger this > > pretty easily.. > > http://patchwork.freedesktop.org/patch/60618/ Back from several weeks of travel.. I tried again with rc6, and I'm still

[RFC PATCH v3 4/4] drm/armada: Convert the probe function to the generic drm_of_component_probe()

On Mon, Oct 19, 2015 at 04:07:50PM +0100, Liviu Dudau wrote: > The armada DRM driver keeps some old platform data compatibility in the > probe function that makes moving to the generic drm_of_component_probe() > a bit more complicated that it should. Refactor the probe function to do > the

[RFC PATCH v3 2/4] drm/imx: Convert the probe function to the generic drm_of_component_probe()

On Mon, Oct 19, 2015 at 04:07:48PM +0100, Liviu Dudau wrote: > The generic function is functionally equivalent to the driver's > imx_drm_platform_probe(). Use the generic function and reduce the > overall code size. Looks fine, thanks. Acked-by: Russell King --

[RFC PATCH v3 1/4] drm: Introduce generic probe function for component based masters.

On Mon, Oct 19, 2015 at 04:07:47PM +0100, Liviu Dudau wrote: > A lot of component based DRM drivers use a variant of the same code > as the probe function. They bind the crtc ports in the first iteration > and then scan through the child nodes and bind the encoders attached > to the remote

[GIT PULL] On-demand device probing

On 19 October 2015 at 15:18, Russell King - ARM Linux wrote: > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote: >> ... If a device is available and has >> a compatible driver, but it cannot be probed because a dependency >> isn't going to be available, that's an error and is going to

HDMI codec, way forward?

On 10/16/15 16:51, Arnaud Pouliquen wrote: >> After reading the ELCE Audio mini conf minutes [1] I gather that HDMI >> audio was not discussed after all. >> >> My conclusion from the Lars-Peter's latest mail [2] related to the >> subject is that the wind is currently blowing slightly in favour of

[RFC PATCH v3 4/4] drm/armada: Convert the probe function to the generic drm_of_component_probe()

The armada DRM driver keeps some old platform data compatibility in the probe function that makes moving to the generic drm_of_component_probe() a bit more complicated that it should. Refactor the probe function to do the platform_data processing after the generic probe (and only if that fails).

[RFC PATCH v3 3/4] drm/rockchip: Convert the probe function to the generic drm_of_component_probe()

Use the generic drm_of_component_probe() function to probe for components. Signed-off-by: Liviu Dudau --- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 81 +++-- 1 file changed, 6 insertions(+), 75 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c

[RFC PATCH v3 2/4] drm/imx: Convert the probe function to the generic drm_of_component_probe()

The generic function is functionally equivalent to the driver's imx_drm_platform_probe(). Use the generic function and reduce the overall code size. Signed-off-by: Liviu Dudau --- drivers/gpu/drm/imx/imx-drm-core.c | 55 +++--- 1 file changed, 4 insertions(+), 51

[RFC PATCH v3 1/4] drm: Introduce generic probe function for component based masters.

A lot of component based DRM drivers use a variant of the same code as the probe function. They bind the crtc ports in the first iteration and then scan through the child nodes and bind the encoders attached to the remote endpoints. Factor the common code into a separate function called

[RFC PATCH v3 0/4] drm: Cleanup probe function for component based masters.

Changelog: v3: Removed the call to dma_set_coherent_mask() from the generic drm_of_component_probe(). Also changes to shorten lines over 80 chars long. v2: Rebased the patchset on top of drm-next rather than Linus' latest -rc A few drivers in drivers/gpu/drm are component-enabled and use

[RFC PATCH v2 1/4] drm: Introduce generic probe function for component based masters.

On Mon, Oct 19, 2015 at 03:50:27PM +0100, Russell King - ARM Linux wrote: > On Mon, Oct 19, 2015 at 04:42:25PM +0200, Daniel Vetter wrote: > > On Mon, Oct 19, 2015 at 02:26:38PM +0100, Russell King - ARM Linux wrote: > > > On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote: > > > > On

[RFC PATCH v2 1/4] drm: Introduce generic probe function for component based masters.

On 19 October 2015 at 15:50, Russell King - ARM Linux wrote: > On Mon, Oct 19, 2015 at 04:42:25PM +0200, Daniel Vetter wrote: >> On Mon, Oct 19, 2015 at 02:26:38PM +0100, Russell King - ARM Linux wrote: >> > On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote: >> > > On Mon, Oct 19, 2015

i.MX IPU2 video out

use rate ipu1_di0 clk 1 14850 ipu1_di1 clk 1 137142857 ipu2_di0 clk 0 4950 ipu2_di1 clk 0 4950 Thanks, Akshay -- next

[RFCv0 0/8] gallium: add support for NIR as alternate IR

On Mon, Oct 19, 2015 at 3:47 PM, Rob Clark wrote: > Also, there is some trivial shader variant handling in mesa st which > would have to be ported to NIR. Or, perhaps, just somehow expose the > shader key to the driver. (Currently most drivers are doing much more > variant handling within the

[GIT PULL] On-demand device probing

plication/pgp-signature Size: 473 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/b4bad635/attachment-0001.sig>

[RFC PATCH v2 1/4] drm: Introduce generic probe function for component based masters.

On Mon, Oct 19, 2015 at 04:42:25PM +0200, Daniel Vetter wrote: > On Mon, Oct 19, 2015 at 02:26:38PM +0100, Russell King - ARM Linux wrote: > > On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote: > > > On Mon, Oct 19, 2015 at 01:25:37PM +0100, Russell King - ARM Linux wrote: > > > > Please

[RFCv0 8/8] freedreno/ir3: hack for mismatch on varying slots for glsl->tgsi->nir vs glsl->nir

Complete hack just for debugging. It isn't intended that mixing and matching glsl->tgsi->nir vs glsl->nir between shader stages should actually work. --- src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c | 6 ++ 1 file changed, 6 insertions(+) diff --git

[RFCv0 7/8] freedreno/ir3: fix const_index handling for uniforms

When coming directly from glsl_to_nir (rather than via TGSI where information about, for example, mat4's is lost), both const_index fields will be used (vs. tgsi_to_nir where the 2nd is always zero). For example: decl_var uniform INTERP_QUALIFIER_NONE mat4 ModelViewProjectionMatrix (0, 0)

[RFCv0 6/8] freedreno/ir3: add support for NIR as preferred IR

For now under debug flag, since only suitable for debugging/testing. --- src/gallium/drivers/freedreno/freedreno_screen.c | 5 +++- src/gallium/drivers/freedreno/freedreno_util.h | 1 + .../drivers/freedreno/ir3/ir3_compiler_nir.c | 15 ++-

[RFCv0 5/8] freedreno/ir3: drop tokens arg

We can get the tokens from variant->shader so drop the extra arg. This will make things easier to support either getting TGSI or NIR as input. --- src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git

[RFCv0 4/8] mesa/st: add support for NIR as possible driver IR

--- src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 223 - src/mesa/state_tracker/st_program.c| 43 +- 2 files changed, 260 insertions(+), 6 deletions(-) diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp

[RFCv0 3/8] gallium: add NIR as a possible IR

--- src/gallium/include/pipe/p_defines.h | 1 + src/gallium/include/pipe/p_state.h | 1 + 2 files changed, 2 insertions(+) diff --git a/src/gallium/include/pipe/p_defines.h b/src/gallium/include/pipe/p_defines.h index 29b0bfb..0dbc54c 100644 --- a/src/gallium/include/pipe/p_defines.h +++

[RFCv0 2/8] gallium: refactor pipe_shader_state to support multiple IR's

The goal is to allow the pipe driver to request something other than TGSI, but detect whether what is getting is TGSI vs what it requested. The pipe drivers will always have to support TGSI (and convert that into whatever it is that they prefer), but in some cases we should be able to skip the

[PATCH 1/8] nir: add nir_var_all enum

Otherwise, passing -1 gets you: error: invalid conversion from 'int' to 'nir_variable_mode' [-fpermissive] Signed-off-by: Rob Clark --- src/glsl/nir/nir.c | 4 src/glsl/nir/nir.h | 1 + src/glsl/nir/nir_lower_io.c | 2 +-

[RFCv0 0/8] gallium: add support for NIR as alternate IR

From: Rob Clark Still quite rough around the edges, but now it's at the point of sorta- kinda-working-sometimes. So I guess time to get wider feedback. The initial goal is to figure out things that glsl_to_nir does differently from tgsi_to_nir, so we can fix them up

[Bug 92524] system hang on "radeon_hwmon_get_pwm1_enable"

s mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/9e75e6b5/attachment.html>

[Bug 92524] system hang on "radeon_hwmon_get_pwm1_enable"

n). On which source tree this patch must be applied? -- Thomas DEBESSE -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2

[PATCH] drm/core: Fix error condition in __setplane_internal.

On Mon, Oct 19, 2015 at 03:14:52PM +0200, Maarten Lankhorst wrote: > Just like the other checks the crtc coordinates need to use goto out. > > This fixes a framebuffer leak introduced by commit 3968be946a057baa. > "drm: Make integer overflow checking cover universal cursor updates (v2)" > > Cc:

[PULL] topic/drm-misc

Hi Dave, More drm-misc for 4.4. - fb refcount fix in atomic fbdev - various locking reworks to reduce drm_global_mutex and dev->struct_mutex - rename docbook to gpu.tmpl and include vga_switcheroo stuff, plus more vga_switcheroo (Lukas Wunner) - viewport check fixes for atomic drivers from

[alsa-devel] HDMI codec, way forward?

On Sun, 18 Oct 2015 19:16:42 +0200, Russell King - ARM Linux wrote: > > On Sun, Oct 18, 2015 at 09:43:29PM +0530, Vinod Koul wrote: > > Right but can I ask why you didn't try making video as component and then > > CEC, audio and others receive the notification over this. > > Okay, I think I see

[PULL] drm-intel-next

Hi Dave, drm-intel-next-2015-10-10: - dmc fixes from Animesh (not yet all) for deeper sleep states - piles of prep patches from Ville to make mmio functions type-safe - more fbc work from Paulo all over - w/a shuffling from Arun Siluvery - first part of atomic watermark updates from Matt and

[PATCH] drm/core: Fix error condition in __setplane_internal.

Just like the other checks the crtc coordinates need to use goto out. This fixes a framebuffer leak introduced by commit 3968be946a057baa. "drm: Make integer overflow checking cover universal cursor updates (v2)" Cc: Matt Roper Fixes: 3968be946a057baa Signed-off-by: Maarten Lankhorst --- diff

[RFC PATCH v2 1/4] drm: Introduce generic probe function for component based masters.

On Mon, Oct 19, 2015 at 02:32:55PM +0100, Liviu Dudau wrote: > On Mon, Oct 19, 2015 at 02:26:38PM +0100, Russell King - ARM Linux wrote: > > On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote: > > > On Mon, Oct 19, 2015 at 01:25:37PM +0100, Russell King - ARM Linux wrote: > > > > Please

[GIT PULL] On-demand device probing

On 18 October 2015 at 21:53, Mark Brown wrote: > On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote: >> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote: >> > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote: > >> > > I can't see adding calls like this

[RFC PATCH v2 1/4] drm: Introduce generic probe function for component based masters.

On Mon, Oct 19, 2015 at 02:26:38PM +0100, Russell King - ARM Linux wrote: > On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote: > > On Mon, Oct 19, 2015 at 01:25:37PM +0100, Russell King - ARM Linux wrote: > > > Please don't move this into here, it's completely inappropriate. Just > > >

HDMI codec, way forward?

On Mon, Oct 19, 2015 at 04:10:32PM +0300, Jyri Sarha wrote: > On 10/16/15 16:51, Arnaud Pouliquen wrote: > >- For IEC standard controls (could be added in core/pcm_iec958.c) > > > > Oh, I did not even realize that there are predefined special kcontrols for > handling the status bits. Adding those

[RFC PATCH v2 1/4] drm: Introduce generic probe function for component based masters.

On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote: > On Mon, Oct 19, 2015 at 01:25:37PM +0100, Russell King - ARM Linux wrote: > > Please don't move this into here, it's completely inappropriate. Just > > because something makes use of this does not mean they only support > > 32-bit

[PATCH 2/2] drm/qxl: allocate objects in both video rams

If memory is not enough in the default BAR for a type try other BAR this allow better memory usage and avoid memory allocation failure if a BAR is quite small and other is quite unused. Signed-off-by: Frediano Ziglio --- drivers/gpu/drm/qxl/qxl_object.c | 11 +++ 1 file changed, 7

[PATCH 1/2] drm/qxl: change the way slot is detected

Instead of relaying on surface type use the actual placement. This allow to have different placement for a single type of surface. Signed-off-by: Frediano Ziglio --- drivers/gpu/drm/qxl/qxl_cmd.c | 2 +- drivers/gpu/drm/qxl/qxl_drv.h | 9 - 2 files changed, 9 insertions(+), 2

[PATCH 0/2] Smartly allocate memory on the two BARs

Currently a single type of surface is allocated in a specific BAR. This also changes from userspace driver to the kernel one. This way it could happen that allocation are failing even if there are plenty of space in the other BAR. For instance this can happen trying to change resolution as the old

[PATCH] drm/imx: hdmi: fix HDMI setup to allow modes larger than FullHD

Dave, could you please pick this patch up as a fix for 4.3? It fixes a regression introduced in this cycle by the stricter parameter validation in the DW HDMI driver. Philipp is on holiday this week, so I guess he won't be able to pick it up. Thanks, Lucas Am Donnerstag, den 15.10.2015, 15:42

[RFC PATCH v2 1/4] drm: Introduce generic probe function for component based masters.

On Mon, Oct 19, 2015 at 01:25:37PM +0100, Russell King - ARM Linux wrote: > On Mon, Oct 19, 2015 at 01:21:50PM +0100, Liviu Dudau wrote: > > A lot of component based DRM drivers use a variant of the same code > > as the probe function. They bind the crtc ports in the first iteration > > and then

[GIT PULL] On-demand device probing

able URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/98eff440/attachment-0001.bin>

[Bug 92524] system hang on "radeon_hwmon_get_pwm1_enable"

via the kernel command line. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/75eb6ada/attachment-0001.html>

[RFC PATCH v2 1/4] drm: Introduce generic probe function for component based masters.

On Mon, Oct 19, 2015 at 01:21:50PM +0100, Liviu Dudau wrote: > A lot of component based DRM drivers use a variant of the same code > as the probe function. They bind the crtc ports in the first iteration > and then scan through the child nodes and bind the encoders attached > to the remote

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Mon, Oct 19, 2015 at 12:05:29PM +0100, Chris Wilson wrote: > In order to add the clobbers, I had to adjust the macro slightly: > > +#define alternative_output(oldinstr, newinstr, feature, output)\ > + asm volatile (ALTERNATIVE(oldinstr, newinstr, feature) \ > +

[RFC PATCH v2 4/4] drm/armada: Convert the probe function to the generic drm_of_component_probe()

The armada DRM driver keeps some old platform data compatibility in the probe function that makes moving to the generic drm_of_component_probe() a bit more complicated that it should. Refactor the probe function to do the platform_data processing after the generic probe (and only if that fails).

[RFC PATCH v2 3/4] drm/rockchip: Convert the probe function to the generic drm_of_component_probe()

Use the generic drm_of_component_probe() function to probe for components. Signed-off-by: Liviu Dudau --- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 86 ++--- 1 file changed, 6 insertions(+), 80 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c

[RFC PATCH v2 2/4] drm/imx: Convert the probe function to the generic drm_of_component_probe()

The generic function is functionally equivalent to the driver's imx_drm_platform_probe(). Use the generic function and reduce the overall code size. Signed-off-by: Liviu Dudau --- drivers/gpu/drm/imx/imx-drm-core.c | 54 +- 1 file changed, 1 insertion(+), 53

[RFC PATCH v2 1/4] drm: Introduce generic probe function for component based masters.

A lot of component based DRM drivers use a variant of the same code as the probe function. They bind the crtc ports in the first iteration and then scan through the child nodes and bind the encoders attached to the remote endpoints. Factor the common code into a separate function called

[RFC PATCH v2 0/4] drm: Cleanup probe function for component based masters.

Changelog: v2: Rebased the patchset on top of drm-next rather than Linus' latest -rc A few drivers in drivers/gpu/drm are component-enabled and use quite similar code sequences to probe for their encoder slaves at the remote end of the ports. Move the code into a "generic" function and remove it

[PATCH v6 0/17] Add Analogix Core Display Port Driver

Hello Yakir, On 10/10/2015 05:35 PM, Yakir Yang wrote: > > Hi all, > >The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller > share the same IP, so a lot of parts can be re-used. I split the common > code into bridge directory, then rk3288 and exynos only need to keep > some

[PATCH] drm/virtio: use %llu format string form atomic64_t

On Mon, Oct 19, 2015 at 12:11 PM, Arnd Bergmann wrote: > On Monday 19 October 2015 09:34:15 Geert Uytterhoeven wrote: >> On Wed, Oct 7, 2015 at 1:23 PM, Arnd Bergmann wrote: >> > static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u) >> > >> > which truncates the result to 32

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Mon, Oct 19, 2015 at 10:58:55AM +0100, Chris Wilson wrote: > During testing we observed that the last cacheline was not being flushed > from a > > mb() > for (addr = addr & -clflush_size; addr < end; addr += clflush_size) > clflushopt(); > mb() > > loop (where

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Mon, Oct 19, 2015 at 10:58:55AM +0100, Chris Wilson wrote: > During testing we observed that the last cacheline was not being flushed > from a > > mb() > for (addr = addr & -clflush_size; addr < end; addr += clflush_size) > clflushopt(); > mb() > > loop (where

[PATCH] drm/virtio: use %llu format string form atomic64_t

On Monday 19 October 2015 09:34:15 Geert Uytterhoeven wrote: > On Wed, Oct 7, 2015 at 1:23 PM, Arnd Bergmann wrote: > > static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u) > > > > which truncates the result to 32 bit. > > Woops. > > See also my unanswered question in

[PATCH] drm/virtio: use %llu format string form atomic64_t

On Monday 19 October 2015 11:37:00 Ralf Baechle wrote: > On Wed, Oct 07, 2015 at 01:23:07PM +0200, Arnd Bergmann wrote: > > > > I haven't checked all architectures, but I assume what happens is that > > > 64-bit ones just #define atomic64_t atomic_long_t, so they don't have > > > to provide three

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Mon, Oct 19, 2015 at 12:16:12PM +0200, Borislav Petkov wrote: > On Mon, Oct 19, 2015 at 10:58:55AM +0100, Chris Wilson wrote: > > Adding a barrier() into clflushopt() is enough for GCC to dtrt, but > > solving why GCC is not seeing the constraints from the alternative_io() > > would be

[GIT PULL] On-demand device probing

: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/f1d7d9d1/attachment-0001.sig>

[PATCH 1/9] drm: fix trivial typos

On Sun, Oct 18, 2015 at 11:29 AM, Geliang Tang wrote: > s/regsiter/register/ > > Signed-off-by: Geliang Tang Applied. thanks! Alex > --- > drivers/gpu/drm/amd/include/atombios.h | 2 +- > drivers/gpu/drm/radeon/cayman_blit_shaders.c| 2 +- >

[PATCH] drm/virtio: use %llu format string form atomic64_t

On Wed, Oct 07, 2015 at 01:23:07PM +0200, Arnd Bergmann wrote: > > I haven't checked all architectures, but I assume what happens is that > > 64-bit ones just #define atomic64_t atomic_long_t, so they don't have > > to provide three sets of functions. > > scratch that, I just looked at all the

[Bug 91620] Tonga warnings after mem sleep with drm-next-4.3-wip

because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/be0f5fa9/attachment-0001.html>

[Bug 91620] Tonga warnings after mem sleep with drm-next-4.3-wip

ves/dri-devel/attachments/20151019/1ce4062c/attachment.html>

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

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

[PATCH] drm: fix mutex leak in drm_dp_get_mst_branch_device

On Fri, 16 Oct 2015, Daniel Vetter wrote: > On Fri, Oct 16, 2015 at 03:33:02AM -0700, Adam Richter wrote: >> In Linux 4.3-rc5, there is an error case in drm_dp_get_branch_device >> that returns without releasing mgr->lock, resulting a spew of kernel >> messages about a kernel work function

[PATCH 0/8] Add ASoC support for AMD APUs [v4]

On Thu, Oct 8, 2015 at 12:12 PM, Alex Deucher wrote: > This patch set implements support for i2s audio and new AMD GPUs. > The i2s codec is fed by a DMA engine on the GPU. To handle this > we create mfd cells which we hang the i2s codec and DMA engine on. > Because of this, this patch set covers

[PATCH] x86: Add an explicit barrier() to clflushopt()

During testing we observed that the last cacheline was not being flushed from a mb() for (addr = addr & -clflush_size; addr < end; addr += clflush_size) clflushopt(); mb() loop (where the initial addr and end were not cacheline aligned). Changing the loop

[GIT PULL] On-demand device probing

On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse wrote: > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote: >> > But the point I'm making is that we are working towards *fixing* that, >> > and *not* using DT-specific code in places where we should be using the >> > generic APIs. >> >> What

[RFC v4 02/11] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.

On Fri, Oct 16, 2015 at 10:12:04PM +0200, Philipp Zabel wrote: > From: CK Hu > > This patch adds an initial DRM driver for the Mediatek MT8173 DISP > subsystem. It currently supports two fixed output streams from the > OVL0/OVL1 sources to the DSI0/DPI0 sinks, respectively. > > Signed-off-by:

  1   2   >