4200), r600 free driver, if that
somehow matters.
--
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/20150316/f6ddc
On 15/03/15 18:09, Jan Vesely wrote:
> v2: Don't bother marking dead functions static
> (handler, xf86VDrvMsgVerb, drmSetDebugMsgFunction)
>
> Signed-off-by: Jan Vesely
Reviewed-by: Emil Velikov
Thanks
Emil
On 03/16/2015 at 10:30 AM, Stephen Rothwell wrote:
> Hi Dave,
>
> Today's linux-next merge of the drm tree got a conflict in
> drivers/gpu/drm/i915/intel_display.c between commit 2dccc9898d45
> ("drm/i915: Ensure plane->state->fb stays in sync with plane->fb") from
> the drm-intel-fixes tree and c
On Mon, Mar 16, 2015 at 8:19 PM, Emil Velikov
wrote:
> The former is a subset of the latter. Error out early so the user is
> aware that they are doing something very wrong.
>
> Cc: Rob Clark
> Signed-off-by: Emil Velikov
Reviewed-by: Rob Clark
> ---
> configure.ac | 5 +
> 1 file chang
of_device_id is always used as const.
(See driver.of_match_table and open firmware functions)
Signed-off-by: Fabian Frederick
---
drivers/gpu/drm/armada/armada_crtc.c| 2 +-
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +-
drivers/gpu/drm/exynos/exynos_hdmi.c| 2 +-
drivers/gpu/drm/exynos
This small patchset adds const to of_device_id arrays in
drivers branch.
Fabian Frederick (35):
ata: constify of_device_id array
regulator: constify of_device_id array
thermal: constify of_device_id array
tty/hvc_opal: constify of_device_id array
tty: constify of_device_id array
power:
the restricted
>> region since the top down flag is set which would end up fragmenting
>> vram.
>
> If that's an issue (which outweighs the supposed benefit of
> TTM_PL_FLAG_TOPDOWN), then again the proper solution would be not to set
> TTM_PL_FLAG_TOPDOWN when rbo->placements[i].lpfn != 0 and smaller than
> the whole available region, instead of checking for VRAM and
> RADEON_GEM_CPU_ACCESS.
>
How about something like the attached patch? I'm not really sure
about the restrictions for the UVD and VCE fw and stack/heap buffers,
but this seems to work. It seems like the current UVD/VCE code works
by accident since the check for TOPDOWN fails.
Alex
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-handle-pfn-restrictions-and-TOPDOWN-in-ra.patch
Type: text/x-patch
Size: 26208 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150316/d4830112/attachment-0001.bin>
From: Steve Longerbeam
Previously, pixel clock polarity was hardcoded and wasn't configurable.
This patch adds support to configure the pixel clock polarity from the
DRM mode flags.
[Sébastien - rebase]
Signed-off-by: Mohsin Kazmi
Signed-off-by: Steve Longerbeam
Signed-off-by: Sébastien Szy
From: Steve Longerbeam
[Sébastien - rebase, update drm_display_mode_to_videomode function]
Signed-off-by: Steve Longerbeam
Signed-off-by: Sébastien Szymanski
---
drivers/gpu/drm/drm_modes.c | 8
include/uapi/drm/drm_mode.h | 4
2 files changed, 12 insertions(+)
diff --git a/d
On Mon, Mar 16, 2015 at 11:45:03AM -0400, Steven Rostedt wrote:
>
> Any movement on this? I still get this warning on 4.0-rc4.
Sorry for not looking into this, I've thought we've addressed this already
and the fix is simply still in-flight to 4.0-rc. Seems it's not :(
Is linux-next also affected
On Mon, 16 Mar 2015, Xi Ruoyao wrote:
> On 03/16/2015 at 10:30 AM, Stephen Rothwell wrote:
>> Hi Dave,
>>
>> Today's linux-next merge of the drm tree got a conflict in
>> drivers/gpu/drm/i915/intel_display.c between commit 2dccc9898d45
>> ("drm/i915: Ensure plane->state->fb stays in sync with plan
omic_get_crtc_state(state, crtc);
> > if (IS_ERR(crtc_state)) {
> > @@ -1935,6 +1958,7 @@ retry:
> >
> > /* Driver takes ownership of state on successful async commit. */
> > return 0;
> > +
> > fail:
> > if (ret == -EDEADLK)
> > goto backoff;
> > @@ -1942,6 +1966,7 @@ fail:
> > drm_atomic_state_free(state);
> >
> > return ret;
> > +
> > backoff:
> > drm_atomic_state_clear(state);
> > drm_atomic_legacy_backoff(state);
> > @@ -1993,6 +2018,7 @@ void drm_atomic_helper_connector_dpms(struct
> drm_connector *connector,
> > return;
> >
> > state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
> > +
> > retry:
> > crtc_state = drm_atomic_get_crtc_state(state, crtc);
> > if (IS_ERR(crtc_state))
> > @@ -2017,6 +2043,7 @@ retry:
> >
> > /* Driver takes ownership of state on successful async commit. */
> > return;
> > +
> > fail:
> > if (ret == -EDEADLK)
> > goto backoff;
> > @@ -2026,6 +2053,7 @@ fail:
> > WARN(1, "Driver bug: Changing ->active failed with ret=%i\n", ret);
> >
> > return;
> > +
> > backoff:
> > drm_atomic_state_clear(state);
> > drm_atomic_legacy_backoff(state);
> > --
> > 1.9.1
> >
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science &Technology
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150316/d25911e9/attachment-0001.html>
Hi Dave,
This pull request contains a fix for a bug introduced by PM support
addition (which was part of my PR for 4.1), and thus should be
applied on top of the material queued for 4.1.
Best Regards,
Boris
The following changes since commit 03be70050c85768e9ce7c0d0887110d1b629e127:
Merge ta
On Thu, 12 Mar 2015 19:47:19 +0100
Sylvain Rochet wrote:
> Unfortunately we used the enabled flag in struct drm_crtc instead of the
> enabled flag in struct atmel_hlcdc_crtc. This obviously leads to
> discrepancies on crtc enable state.
>
> This patch fixes the issue by using the struct atmel_hl
Hi Michel,
>> [..]
>> The most striking problem of kernel 3.18.9-rt4 affects all systems that
>> are equipped with Radeon graphics (irrespective whether PCIe cards or
>> APUs with on-chip graphics). They suffer from a hanging radeon driver.
>> The block occurs when accelerated graphics load is cre
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150316/2789d76d/attachment-0001.html>
es changed, 102 insertions(+), 38 deletions(-)
--
Mark
E-mail:mark.yao at rock-chips.com
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150316/b965cfdd/attachment.html>
nature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150316/0910cc71/attachment.sig>
On Mon, 16 Mar 2015 17:43:33 +0100
Daniel Vetter wrote:
> Is linux-next also affected or is this just a case of i915 maintainers
> having failed to push the right patch to -fixes?
I just confirmed, linux-next boots without the warning.
>
> I'll try to figure out what fell apart here meanwhile
On Mon 2015-03-16 09:12:54, Daniel Vetter wrote:
> On Sat, Mar 14, 2015 at 08:21:04AM +0100, Pavel Machek wrote:
> > On Thu 2015-03-12 15:23:20, Pavel Machek wrote:
> > > Hi!
> > >
> > > It happened twice so far: in one case gui locked up, but music
> > > continued playing, and I could still ssh i
¤lli ---
please attach a test case
--
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/20150316/8291d115/attachment-0001.html>
On Mon, 16 Mar 2015, Daniel Vetter wrote:
> On Sat, Mar 14, 2015 at 08:21:04AM +0100, Pavel Machek wrote:
>> On Thu 2015-03-12 15:23:20, Pavel Machek wrote:
>> > Hi!
>> >
>> > It happened twice so far: in one case gui locked up, but music
>> > continued playing, and I could still ssh in. (Nothing
Any movement on this? I still get this warning on 4.0-rc4.
-- Steve
On Thu, 5 Mar 2015 09:27:28 -0500
Steven Rostedt wrote:
> On Mon, Feb 23, 2015 at 11:12:39PM +0300, Andrey Skvortsov wrote:
> >
> > This warning is moved from linux-next to v4.0-rc1 now. After system boot is
> > just a blac
On Mon, 2015-03-16 at 10:51 +0100, Thierry Reding wrote:
> There should be a patch in v4.0-rc4 (046d669c62f3 "drm/mm: Fix support 4
> GiB and larger ranges") that presumably fixes this. Does it work for you
> as well?
I just sent a message that mentions that commit. It surely fixes this
bug. v4.0-
d...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150316/340b39c8/attachment.sig>
On Fri, 2015-03-13 at 12:36 +0100, Paul Bolle wrote:
> Dave Airlie schreef op vr 06-03-2015 om 21:52 [+]:
> > Thierry Reding (1):
> > drm/mm: Support 4 GiB and larger ranges
>
> Yesterday the screen on my (outdated) ThinkPad X41 went, well, black
> while it was busy compiling something u
On 03/14/2015 01:15 AM, "Stéphane Viau" wrote:
> Hi,
>
>> Hi,
>>
>> On 03/09/2015 06:41 PM, Stephane Viau wrote:
>>> This change adds the hw configuration for msm8x16 chipsets in
>>> mdp5_cfg module.
>>>
>>> Note that only one external display interface is present in this
>>> configuration (DSI)
nd hence avoid the need to switch to u64).
But since it's already landed in Linus' tree and this fix in v4.0-rc4 I
guess it'd be too much churn to back it out again.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type
On Fri, Mar 13, 2015 at 6:51 PM, Oded Gabbay wrote:
> This patch updates the Kaveri MEC firmware to #396 (from #391).
> The MEC firmware is mainly used for amdkfd - AMD's HSA Linux kernel driver.
>
> Signed-off-by: Oded Gabbay
Acked-by: Alex Deucher
> ---
> radeon/kaveri_mec.bin | Bin 17024
On Sun, Mar 15, 2015 at 11:55:35PM +0200, Laurent Pinchart wrote:
> Hello,
>
> I have a feeling that RFC/PATCH will work better than just RFC, so here's a
> patch set that adds a new object named live source to DRM.
>
> The need comes from the Renesas R-Car SoCs in which a video processing engine
On Sun, Mar 15, 2015 at 08:59:11PM +0800, John Hunter wrote:
> I'm not sure whether this is right, as far as I can see, for the
> macro 'list_for_each_entry', if not use the tmp_connector, it does
> make sense.
>
> Hope I am right with that.
Nice catch and looks correct. But please follow patch s
On Sun, Mar 15, 2015 at 08:59:10PM +0800, John Hunter wrote:
> there are some duplication in the annotations
> add some empty line to make it easier to read
sob line missing. Also please split this up into individual parts, since I
don't agree with the additional empty lines bikeshed. See
Document
On 16 March 2015 at 05:31, Chris Wilson wrote:
> On Sun, Mar 15, 2015 at 08:22:36PM +0100, Krzysztof Kolasa wrote:
>> Problem solved and tested:
>>
>> [PATCH] drm/mm: Fix support 4 GiB and larger ranges
>>
>> bad argument if(tmp)... in check_free_hole
>>
>> fix oops: kernel BUG at drivers/gpu/drm/
On Sat, Mar 14, 2015 at 08:21:04AM +0100, Pavel Machek wrote:
> On Thu 2015-03-12 15:23:20, Pavel Machek wrote:
> > Hi!
> >
> > It happened twice so far: in one case gui locked up, but music
> > continued playing, and I could still ssh in. (Nothing interesting in
> > the logs, if I can tell in all
On Fri, Mar 13, 2015 at 03:12:10PM -0400, Stephane Viau wrote:
> From: Beeresh Gopal
>
> Using fb modifier flag, support NV12MT format in MDP4.
>
> v2:
> - rework the modifier's description [Daniel Vetter's comment]
> - drop .set_mode_config() callback [Rob Clark's comment]
>
> Signed-off-by: B
tarting minute of the video if anyone was happy to look at it).
--
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/2015031
36 matches
Mail list logo
