its a pain
but at least it's working without crashes.
--
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/20140909/683046e9/attachment.html>
On 09/08/2014 11:37 PM, Keith Packard wrote:
> With atomic mode setting in the kernel, I think you're probably right in
> proposing to eliminate explicit CRTC allocation from that. I do think
> you'll want to indicate the number of available CRTCs in the display
> engine, and the number of CRTCs ea
On Mon, Sep 08, 2014 at 12:09:49PM -0700, Greg Kroah-Hartman wrote:
> On Mon, Sep 08, 2014 at 12:08:59PM -0700, Greg Kroah-Hartman wrote:
> > On Mon, Sep 01, 2014 at 06:07:12PM +0100, Russell King - ARM Linux wrote:
> > > Greg,
> > >
> > > Here's two oops fixes for imx-drm, which I've had queued u
l/attachments/20140909/a1403aa9/attachment.html>
./../../src/gallium/auxiliary/util/u_math.h:767:37: note: in definition of
macro 'MAX2'
#define MAX2( A, B ) ( (A)>(B) ? (A) : (B) )
--
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/20140909/80f24f76/attachment.html>
Hi!
There is a notebook eMashines e442 142G25Mikk Model PEW86 with a video
card Radeon HD 4250. Since a kernel 3.7.10 (tested until 3.16.1) it
have a problem: screen is a white (not black) when PC is idle. A
changes causing problem is:
--- linux-3.6.11/drivers/gpu/drm/radeon/radeon_encoders.c
2012
On Tue, Sep 09, 2014 at 11:43:21AM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Fold intel_pipe_set_base() in the update primary plane path merging
> pieces of code that are common to both paths.
>
> Basically the the pin/unpin procedures are the same for both paths
> and some check
https://bugzilla.kernel.org/show_bug.cgi?id=83221
Karol Herbst changed:
What|Removed |Added
Resolution|--- |OBSOLETE
Status|NEW
with v2. Can you try this patch?
--
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/20140909/646d2612/attachment.html>
On Tue, Sep 9, 2014 at 4:16 AM, Ville Syrj?l?
wrote:
> On Tue, Sep 09, 2014 at 10:43:35AM +1000, Dave Airlie wrote:
>> Hi,
>>
>> So I've been attempting to hide the 30" Dell MST monitors in the
>> kernel, and ran into a number of problems,
>> but the major one is how to steal a crtc and get away w
On Tue, Sep 09, 2014 at 11:43:19AM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> The !crtc->enabled case will now be handled by the !visible code,
> since the handling is basically the same.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/i915/intel_display.c | 26 --
On Tue, Sep 09, 2014 at 11:43:20AM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Factor out a piece of code from intel_pipe_set_base() that updates
> the pipe size and adjust fitter.
>
> This will help refactor the update primary plane path.
>
> Signed-off-by: Gustavo Padovan
> ---
On 9 September 2014 10:43, Dave Airlie wrote:
> Hi,
>
> So I've been attempting to hide the 30" Dell MST monitors in the
> kernel, and ran into a number of problems,
> but the major one is how to steal a crtc and get away with it.
>
> The standard scenario I have is
>
> CRTC 0: eDP monitor connect
From: Gustavo Padovan
Optimize code avoiding helding dev mutex if old fb and current fb
are the same.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_sprite.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_s
elsius hotter and that's just on idle.
--
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/20140909/6dd350c4/attachment-0001.html>
From: Gustavo Padovan
Fold intel_pipe_set_base() in the update primary plane path merging
pieces of code that are common to both paths.
Basically the the pin/unpin procedures are the same for both paths
and some checks can also be shared (some of the were moved to the
check() stage)
v2: take Vi
From: Gustavo Padovan
Factor out a piece of code from intel_pipe_set_base() that updates
the pipe size and adjust fitter.
This will help refactor the update primary plane path.
v2: use struct intel_crtc as argument to intel_update_pipe_size()
Signed-off-by: Gustavo Padovan
---
drivers/gpu/dr
From: Gustavo Padovan
The !crtc->enabled case will now be handled by the !visible code,
since the handling is basically the same.
Signed-off-by: Gustavo Padovan
Reviewed-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_display.c | 26 --
1 file changed, 26 deletions(-)
From: Dave Airlie
This is going to be a bit of a reference counting nightmare,
Since when we moved from one tile to the other, we need to
transfer the framebuffer over between them.
Also only universal is tackled here.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 33 ++
From: Dave Airlie
This is OMG bad, but in order to get semantics that don't defeat
userspace we have to wait for both flips to complete.
So rewrite the event handling code to make sure we wait for
all crtcs in the tile group to complete flipping.
The main problem otherwise is userspace does
ad
From: Dave Airlie
This is probably not the greatest idea in the world, but if userspace
does a modesetting sequences
initial state : crtc 0 -> eDP-1
modeset : crtc 1 -> DP-4 (dual crtc)
we have to steal crtc 2 for DP-3
modeset : crtc 2 -> eDP-1
we are kind off stuck, so when we see this, we bac
From: Dave Airlie
So when userspace asks us to set a mode on a tiled crtc,
split it up and find the actual modes and attempt to set them.
Also disable crtcs when no longer in tiled group.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c| 51 +++
From: Dave Airlie
This patches the EDID to add the special mode.
TODO make this more generic.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_mst_topology.c | 13 ++---
drivers/gpu/drm/drm_edid.c| 36 +++
include/drm/drm_edid.h
From: Dave Airlie
Using the tiling info attempt to set a mode across two crtcs
---
drivers/gpu/drm/drm_crtc.c| 100 +-
drivers/gpu/drm/drm_displayid.c | 13 -
drivers/gpu/drm/drm_dp_mst_topology.c | 18 +-
drivers/gpu/drm/drm_edid.c
From: Dave Airlie
This gives us a base identifier to group tiled outputs from.
However after reading about the Dell 5k monitor I expect this
is probably too little, and we need some sort of hash table
from the monitor EDID serial number.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_m
From: Dave Airlie
Just enough to get the tiling info from a Dell 4k monitor.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_displayid.c| 68 ++
drivers/gpu/drm/drm_edid.c | 29 ++--
driv
From: Dave Airlie
For the monitors with panels we only want EDID once,
and they show up on logical ports, which are always connected.
This is required as if we start hiding connector status
we won't be able to get the EDID normally later.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_
From: Dave Airlie
Since DP MST has new userspace requirements and any effort at trying
to shoehorn things into the something the current userspace can handle are
doomed, lets just put this behind a config option.
This also adds a command line arg to switch it on as well.
Distros should probably
From: Dave Airlie
The old code has problems with the Dell MST monitors due to some
assumptions I made that weren't true.
I initially thought the Virtual Channel Payload IDs had to be in
the DPCD table in ascending order, however it appears that assumption
is bogus.
The old code also assumed it
All these are on top of rc3 (also in my drm-mst-hide-monitor branch).
So after talking to Keith and Daniel in Chicago I decided to give
another go at hiding the horror that is 30" 4k dual-panel MST
monitors in the kernel.
Also this hw is not going away, if anything it seems to be getting
worse wi
During component removal driver should unregister connector.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 562966d..79
During component removal driver should unregister connector.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 4f
During component removal it should unregister connector
and optionally detach the panel.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
b/drivers/gpu/drm/ex
During component unbind connector should be unregistered.
Also DSI host should be unregistered after KMS cleanup.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dr
Adding reference to framebuffer should be accompanied with removing
reference to old framebuffer assigned to the plane.
This patch removes following warning:
[ 95.038017] WARNING: CPU: 1 PID: 3067 at drivers/gpu/drm/drm_crtc.c:5115
drm_mode_config_cleanup+0x258/0x268()
[ 95.048086] Modules li
In case drm_framebuffer_init fails exynos_fb should be freed
before returning an error.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
ind
exynos_gem_obj is used by exynos_drm_fbdev_destroy so it cannot be destroyed
before calling the latter. exynos_gem_obj will be destroyed anyway by
exynos_drm_fbdev_destroy->...->exynos_drm_fb_destroy.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 ---
1 file chan
Since components have their own cleanup routines calling
drm_mode_config_cleanup before component_unbind_all causes errors
due to double free of KMS objects. The patch fixes it by changing
de-initialization order. Now it is exactly opposite to init order.
Signed-off-by: Andrzej Hajda
---
drivers
On ipp subsystem removal list of ipp drivers is traversed
and their members are deleted. To do it properly safe version
of list_for_each* should be used.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
This set of patches contains fixes of initialization and deinitialization
code of exynos_drm core and components.
It is based on exynos-drm-next branch.
Patchset has been tested on trats and universal_c210 platforms.
Regards
Andrzej
Andrzej Hajda (9):
drm/exynos/ipp: traverse ipp drivers list
2014-09-09 Ville Syrj?l? :
> On Tue, Sep 09, 2014 at 11:43:20AM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Factor out a piece of code from intel_pipe_set_base() that updates
> > the pipe size and adjust fitter.
> >
> > This will help refactor the update primary plane path.
vel/attachments/20140909/5b7ff192/attachment.sig>
While the DMA channel is running, it is not allowed to change anything
but the inactive (double) buffer base address, so resizing a plane or
changing to a frame buffer with different pixel format is not possible.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipuv3-plane.c | 15 +++
This allows to update the buffer base address while the DMA
channel is running. It is needed to flip the frame buffer of
an active plane.
Signed-off-by: Philipp Zabel
---
Change since v1:
- Added missing ipu_idmac_select_buffer call to make the hardware
double buffering actually consider the
Setting the stride can only be done on inactive channels, while
the buffer base address can also be updated for running channels
using the hardware double buffering feature.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipuv3-plane.c | 3 +--
1 file changed, 1 insertion(+), 2 deletion
For the overlay plane scanning out a framebuffer with an alpha component,
enable the DP local alpha feature on the partial plane.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipuv3-plane.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/stagi
Am Montag, den 08.09.2014, 12:50 -0700 schrieb Greg Kroah-Hartman:
> On Tue, Jul 29, 2014 at 11:57:06AM +0200, Philipp Zabel wrote:
> > For the overlay plane scanning out a framebuffer with an alpha component,
> > enable the DP local alpha feature on the partial plane.
> >
> > Signed-off-by: Phili
> PAGE_SHIFT));
> + bo->placements[i].lpfn = max_offset >> PAGE_SHIFT;
>
> - bo->placements[i].lpfn = lpfn;
> bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
> }
>
> --
> 2.1.0
>
>
> --
> Earthling Michel D?nzer| http://www.amd.com
> Libre software enthusiast |Mesa and X developer
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-add-RADEON_GEM_NO_CPU_ACCESS-BO-creation-.patch
Type: text/x-diff
Size: 1804 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/073b383f/attachment.patch>
On systems with special thermal configurations make sure we make
note of the thermal setup. This is required for proper firmware
configuration on these systems.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_atombios.c | 26 +++---
From: Gustavo Padovan
Fold intel_pipe_set_base() in the update primary plane path merging
pieces of code that are common to both paths.
Basically the the pin/unpin procedures are the same for both paths
and some checks can also be shared (some of the were moved to the
check() stage)
Signed-off-
From: Gustavo Padovan
Factor out a piece of code from intel_pipe_set_base() that updates
the pipe size and adjust fitter.
This will help refactor the update primary plane path.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 71 +---
1
From: Gustavo Padovan
The !crtc->enabled case will now be handled by the !visible code,
since the handling is basically the same.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 26 --
1 file changed, 26 deletions(-)
diff --git a/drivers/gpu/d
On Tue, Sep 09, 2014 at 10:43:35AM +1000, Dave Airlie wrote:
> Hi,
>
> So I've been attempting to hide the 30" Dell MST monitors in the
> kernel, and ran into a number of problems,
> but the major one is how to steal a crtc and get away with it.
>
> The standard scenario I have is
>
> CRTC 0: eD
On Mon, 2014-09-08 at 18:28 -0400, Alex Deucher wrote:
> On Thu, Sep 4, 2014 at 8:44 AM, Andy Shevchenko
> wrote:
> > There is no need to use hex_dump_to_buffer() since we have a kernel helper
> > to
> > dump up to 64 bytes just via printk(). In our case the actual size is 15
> > bytes.
> >
> >
On 09/09/2014 02:30 AM, Tony Lindgren wrote:
> * Jyri Sarha [140818 14:49]:
>> Add external clock provider for am33xx devices.
>
> Please send all the .dts and defconfig changes separately
> so I can pick them up and we don't get pointless merge
> conflicts.
Moreover, this patch is obsolete now,
On Tue, Sep 9, 2014 at 4:14 AM, Andy Shevchenko
wrote:
> On Mon, 2014-09-08 at 18:28 -0400, Alex Deucher wrote:
>> On Thu, Sep 4, 2014 at 8:44 AM, Andy Shevchenko
>> wrote:
>> > There is no need to use hex_dump_to_buffer() since we have a kernel helper
>> > to
>> > dump up to 64 bytes just via p
On Tue, Sep 09, 2014 at 04:28:05PM +1000, Dave Airlie wrote:
> All these are on top of rc3 (also in my drm-mst-hide-monitor branch).
>
> So after talking to Keith and Daniel in Chicago I decided to give
> another go at hiding the horror that is 30" 4k dual-panel MST
> monitors in the kernel.
>
>
On Tue, 09 Sep 2014, Dave Airlie wrote:
> From: Dave Airlie
>
> Since DP MST has new userspace requirements and any effort at trying
> to shoehorn things into the something the current userspace can handle are
> doomed, lets just put this behind a config option.
>
> This also adds a command line
Hi,
So I've been attempting to hide the 30" Dell MST monitors in the
kernel, and ran into a number of problems,
but the major one is how to steal a crtc and get away with it.
The standard scenario I have is
CRTC 0: eDP monitor connected
hotplug 30" monitor, userspace decides to configure things
On 09.09.2014 09:47, Michel D?nzer wrote:
> On 09.09.2014 02:36, Alex Deucher wrote:
>>
>> Updated version with comments integrated.
>
> [...]
>
>> @@ -314,10 +314,12 @@ int radeon_bo_pin_restricted(struct radeon_bo
>> *bo, u32 domain, u64 max_offset,
>> unsigned lpfn = 0;
>>
>>
I used this patch to add LCD support on our SBC-SAMA5d36 with a mainline kernel
and it works properly. I used fb-test to test the framebuffer and I tested the
DRI device with modetest and I can set a mode and set planes.
Tested-by: Anthony Harivel
-Original Message-
From: Boris BREZIL
hat's why I have a loop there. So we flush, then check if there is
work for the irq. If yes, sleep a bit and go back to start. So if the
irq work created new work for the wq, we flush that. And if that work
created new work for the irq, we check that again. Etc.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/0ef9ea4d/attachment.sig>
On 09.09.2014 02:36, Alex Deucher wrote:
>
> Updated version with comments integrated.
[...]
> @@ -314,10 +314,12 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32
> domain, u64 max_offset,
> unsigned lpfn = 0;
>
> /* force to pin into visible video ram */
> -
On Tue, Sep 09, 2014 at 11:13:41PM +0800, Shawn Guo wrote:
> On Mon, Sep 08, 2014 at 12:09:49PM -0700, Greg Kroah-Hartman wrote:
> > On Mon, Sep 08, 2014 at 12:08:59PM -0700, Greg Kroah-Hartman wrote:
> > > On Mon, Sep 01, 2014 at 06:07:12PM +0100, Russell King - ARM Linux wrote:
> > > > Greg,
> >
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140909/949ad7c0/attachment.html>
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/d997f5e5/attachment.html>
On Tue, Sep 9, 2014 at 3:07 AM, Tomi Valkeinen wrote:
>
lockdep won't complain though since you essentially open-code a
workqueue_flush, and lockdep also doesn't complain about all possible
deadlocks (due to some design issues with lockdep).
>>>
>>> What do you mean "open-code a wor
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/c5ee7c86/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=78221
--- Comment #22 from t3st3r at mail.ru ---
Attempted to test on 3.17-rc4. Result: crashed in about 3 minutes of run (see
below).
Are some stability fixes missing 3.17-rc4 mainline? At first glance I do not
see radeon-related commits in drm-fixes w
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/e4334f92/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/c2db8b70/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/d133116c/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/36b11d2f/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/2d4a117f/attachment.html>
74 matches
Mail list logo
