On Mon, Nov 16, 2015 at 09:17:35PM +, Liviu Dudau wrote:
> On Mon, Nov 16, 2015 at 05:22:48PM +, Russell King - ARM Linux wrote:
> > Put those two sentences together and please think about it. If the
> > pointer type is unknown to component_match_add(), how could it ever
> > use of_node_ge
This patch adds runtime pm interfaces to dsi driver.
Each sub driver should control not only its own clocks and
regulator but also its power domain.
For this, it removes existing exynos_dsi_poweron/poweroff interfaces
and uses runtime pm interfaces instead.
Signed-off-by: Inki Dae
---
drivers/
On Mon, Nov 16, 2015 at 05:22:48PM +, Russell King - ARM Linux wrote:
> Please sensibly wrap your messages. Your lines are longer than 80 characters
> which makes it exceedingly difficult for some people to reply to your very
> very very very very very very very very very very very very very
From: Ville Syrjälä
Rather than using drm_match_cea_mode() to see if the EDID detailed
timings are supposed to represent one of the CEA/HDMI modes, add a
special version of that function that takes in an explicit clock
tolerance value (in kHz). When looking at the detailed timings specify
the t
lists.freedesktop.o
||rg
--
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/20151116/0480b
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151116/d5ffcf34/attachment.html>
alctl after a lock occuring when
reactivating a session
--
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/20151116/34179274/attachment.html>
All of that sounds easily done by changing
reservation_object_wait_timeout_rcu() args wait_all to FALSE, intr to TRUE, and
timeout to MAX_SCHEDULE_TIMEOUT.
Thanks,
Alex
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, Novemb
From: Thierry Reding
An encoder is associated with a connector by the DRM core as a result of
setting up a configuration. Drivers using the atomic or legacy helpers
should never set up this link, even if it is a static one.
While at it, try to catch this kind of error in the future by adding a
W
Am Montag, 16. November 2015, 16:52:06 schrieb Liviu Dudau:
> On Mon, Nov 16, 2015 at 04:30:16PM +, Russell King - ARM Linux wrote:
> > I've tweaked your patch to make the above (buggy) change a little clearer.
> >
> > On Mon, Nov 16, 2015 at 02:44:53PM +, Liviu Dudau wrote:
> > > - for (i
On Mon, Nov 16, 2015 at 05:48:32PM +, Daniel Stone wrote:
> On 16 November 2015 at 17:43, Russell King - ARM Linux
> wrote:
> > On Mon, Nov 16, 2015 at 05:32:05PM +, Daniel Stone wrote:
> >> On 16 November 2015 at 17:22, Russell King - ARM Linux
> >> wrote:
> >> > Please sensibly wrap you
On 16 November 2015 at 17:43, Russell King - ARM Linux
wrote:
> On Mon, Nov 16, 2015 at 05:32:05PM +, Daniel Stone wrote:
>> On 16 November 2015 at 17:22, Russell King - ARM Linux
>> wrote:
>> > Please sensibly wrap your messages. Your lines are longer than 80
>> > characters which makes it
On Mon, Nov 16, 2015 at 06:19:53PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> An encoder is associated with a connector by the DRM core as a result of
> setting up a configuration. Drivers using the atomic or legacy helpers
> should never set up this link, even if it is a static one.
On Mon, Nov 16, 2015 at 05:32:05PM +, Daniel Stone wrote:
> On 16 November 2015 at 17:22, Russell King - ARM Linux
> wrote:
> > Please sensibly wrap your messages. Your lines are longer than 80
> > characters which makes it exceedingly difficult for some people to reply
> > to your very very
On 16 November 2015 at 17:22, Russell King - ARM Linux
wrote:
> Please sensibly wrap your messages. Your lines are longer than 80
> characters which makes it exceedingly difficult for some people to reply
> to your very very very very very very very very very very very very
> very very very very
On Thu, Nov 12, 2015 at 05:28:01PM +0100, Thierry Reding wrote:
> On Thu, Nov 12, 2015 at 01:57:11PM +, Liviu Dudau wrote:
> > On Thu, Nov 12, 2015 at 01:16:55PM +0100, Thierry Reding wrote:
> > > On Wed, Nov 11, 2015 at 04:09:42PM +, Liviu Dudau wrote:
> > > > On Tue, Nov 10, 2015 at 05:56
Hello Thierry,
Many thanks for your comments.
2015-11-16 12:50 GMT+01:00 Thierry Reding :
> On Sat, Nov 14, 2015 at 07:38:19PM +0100, Enric Balletbo i Serra wrote:
>> The MPEG Source (MS) InfoFrame is in EIA/CEA-861B. It describes aspects of
>> the compressed video stream that were used to produc
On Tue, Nov 10, 2015 at 05:11:57PM +0800, Mark Yao wrote:
> We want to display a buffer allocated by other driver, need import
> the buffer to gem.
Does this work with some open-source driver/userspace or is this for the
proprietary stack only? A bit a grey area I guess, but if it's only for
the p
On Mon, Nov 16, 2015 at 05:22:42PM +0100, Daniel Vetter wrote:
> On Tue, Jul 28, 2015 at 05:53:23PM +0900, Joonyoung Shim wrote:
> > Don't create a fake mmap offset in exynos_drm_gem_dumb_map_offset. If
> > not, it will call drm_gem_create_mmap_offset whenever user requests
> > DRM_IOCTL_MODE_MAP_D
Please sensibly wrap your messages. Your lines are longer than 80 characters
which makes it exceedingly difficult for some people to reply to your very very
very very very very very very very very very very very very very very very very
very very very very very very very very very very very ver
On Tue, Jul 28, 2015 at 05:53:23PM +0900, Joonyoung Shim wrote:
> Don't create a fake mmap offset in exynos_drm_gem_dumb_map_offset. If
> not, it will call drm_gem_create_mmap_offset whenever user requests
> DRM_IOCTL_MODE_MAP_DUMB ioctl.
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm
On Tue, Nov 10, 2015 at 02:17:43PM +0800, Mark yao wrote:
> Hi Heiko
> I don't think this patch is needed for rockchip drm, since rockchip drm
> only use kms.
> I saw the discussion about ("drm/exynos: create a fake mmap offset with gem
> creation"),
> Inki said that: "This patch makes drm_gem
On Thu, Nov 05, 2015 at 10:33:54AM +0100, LABBE Corentin wrote:
> The simple_strtoul function is marked as obsolete.
> This patch replace it by kstrtouint.
>
> Signed-off-by: LABBE Corentin
Applied to drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/drm_modes.c | 16 +++-
> 1 file
On Mon, Nov 02, 2015 at 05:18:36PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 02, 2015 at 04:14:08PM +0100, Robert Fekete wrote:
> > Adds clarification of the rotation property bits. I.e. rotation is
> > counter clockwise and that reflects are applied before any rotation.
> >
> > v2:
Hi Liviu,
Am Montag, 16. November 2015, 14:44:51 schrieb Liviu Dudau:
> When I have introduced the drm_of_component_probe() function I have managed
> to break rockchip's DRM driver as the compare_of() function had to match
> both local crtc ports and remote encoder ones. As suggested by Russell
>
On Thu, Nov 05, 2015 at 05:03:09PM +0200, Jyri Sarha wrote:
> Disable planes if they are on to be blanked CRTC and enable them when
> the CRTC is turned back on by DMPS.
>
> This is desirable on HW that loses its context on blanking. When
> planes are enabled and disabled with the associated CRTCs
From: Ville Syrjälä
To aid in debugging failures, print the src,dst,clip rectangles
when drm_plane_helper_check_update() fails.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_plane_helper.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/
From: Ville Syrjälä
Allow the caller to specify a "prefix" string to drm_rect_debug_print()
to make it easier to see which drm_rect is being printed.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_rect.c | 7 ---
drivers/gpu/drm/i915/intel_sprite.c | 8
include/
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 7857163..d5693b7 100644
--- a/drivers/
From: Ville Syrjälä
Properly double the hdisplay/vdisplay timings that we use as the primary
plane size with stereo doubled modes. Otherwise the modeset gets
rejected on machines where the primary plane must be fullscreen, and on
the rest only the first eye would get a visible plane.
Cc: Danie
On Wed, Nov 04, 2015 at 06:15:58PM +0800, Liu Ying wrote:
> Since we are using ipu_plane_init() to add one primary plane for each
> IPU CRTC, it's unnecessary to create the safe one by using the helper
> create_primary_plane().
>
> Furthermore, the safe one is attached to crtc->primary, which actu
On Mon, Nov 16, 2015 at 04:30:16PM +, Russell King - ARM Linux wrote:
> I've tweaked your patch to make the above (buggy) change a little clearer.
>
> On Mon, Nov 16, 2015 at 02:44:53PM +, Liviu Dudau wrote:
> > - for (i = 0;; i++) {
> > - port = of_parse_phandle(np, "ports", i
On Mon, Nov 16, 2015 at 05:07:17PM +0100, Heiko Stübner wrote:
> Hi Liviu,
>
> Am Montag, 16. November 2015, 14:44:51 schrieb Liviu Dudau:
> > When I have introduced the drm_of_component_probe() function I have managed
> > to break rockchip's DRM driver as the compare_of() function had to match
>
On Mon, Nov 16, 2015 at 04:22:41PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 16, 2015 at 02:44:52PM +, Liviu Dudau wrote:
> > Rockchip DRM driver cannot use the same compare_of() function to match
> > ports and remote ports (aka encoders) as their OF sub-trees look different.
> > Add
I've tweaked your patch to make the above (buggy) change a little clearer.
On Mon, Nov 16, 2015 at 02:44:53PM +, Liviu Dudau wrote:
> - for (i = 0;; i++) {
> - port = of_parse_phandle(np, "ports", i);
> - if (!port)
> - break;
> -
> -
On Mon, Nov 16, 2015 at 02:44:52PM +, Liviu Dudau wrote:
> Rockchip DRM driver cannot use the same compare_of() function to match
> ports and remote ports (aka encoders) as their OF sub-trees look different.
> Add a second compare function to be used when encoders are added to the
> component f
On Sun, Nov 01, 2015 at 02:22:00PM +0100, Lukas Wunner wrote:
> I noticed that intel_fbdev->our_mode is unused. Introduced by
> 79e539453b34 ("DRM: i915: add mode setting support").
>
> Then I noticed that intel_fbdev->fbdev_list is unused as well.
> Introduced by 386516744ba4 ("drm/fb: fix fbdev
On Mon, Nov 09, 2015 at 09:42:05PM +, Alexander Goins wrote:
> >> + /* For framebuffer backed by dmabuf, wait for fence */
> >> + mutex_lock(&dev->object_name_lock);
>
> >The lock here is unfortunate. I thought once a dmabuf as attached to an
> >object, it persists until the object is destr
kchip/rockchip_drm_vop.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151116/7ba6d0d0/attachment.sig>
On Mon, Nov 02, 2015 at 04:45:00PM +0900, Michel Dänzer wrote:
> On 31.10.2015 06:55, Daniel Vetter wrote:
> > Apparently pre-nv50 pageflip events happen before the actual vblank
> > period. Therefore that functionality got semi-disabled in
> >
> > commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28
On Wed, Nov 11, 2015 at 02:14:12PM -0800, Maxime Ripard wrote:
> Hi Daniel,
>
> Thanks for your review!
Back from vacation, sorry for the delay.
>
> On Fri, Oct 30, 2015 at 03:44:09PM +0100, Daniel Vetter wrote:
> > > +static void sun4i_crtc_disable(struct drm_crtc *crtc)
> > > +{
> > > + struc
From: Markus Elfring
Date: Mon, 16 Nov 2015 15:40:58 +0100
The ttm_tt_destroy() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
dr
Am Montag, 16. November 2015, 12:50:22 schrieb Daniel Stone:
> Rockchip previously treated a pageflip to the same framebuffer as a
> no-op, discarding the event if one was requested. This breaks Weston,
> which, when idle, sends a no-op vblank event to discover vblank
> timings if the vblank query
Am Montag, 16. November 2015, 12:50:21 schrieb Daniel Stone:
> Passing -1 as the pipe for vblank events now triggers a WARN_ON, but had
> previously made multi-screen unusable anyway. Pass the correct pipe to
> the event-send function, and use the new API to make this a bit easier
> for us.
>
> Fi
On Mon, Nov 16, 2015 at 12:55:37PM +, Chris Wilson wrote:
> On Mon, Nov 16, 2015 at 12:08:08PM +, Tvrtko Ursulin wrote:
> >
> > On 16/11/15 11:12, Chris Wilson wrote:
> > >On Mon, Nov 16, 2015 at 10:24:45AM +, Tvrtko Ursulin wrote:
> > >>On 15/11/15 13:32, Chris Wilson wrote:
> > >>>+s
Hi,
On 11/11/15 17:11, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> Drivers shouldn't clobber the passed in addfb ioctl parameters.
> i915 was doing just that. To prevent it from happening again,
> pass the struct around as const, starting all the way from
> internal_frame
On Fri, Nov 06, 2015 at 12:13:02PM +0100, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 6 Nov 2015 12:03:46 +0100
>
> The drm_property_unreference_blob() function tests whether its argument
> is NULL and then returns immediately.
> Thus the tests around the calls are not needed.
>
Take two: Initial attempt to convert rockchip to drm_of_component_probe()
missed the difference between ports and encoders when using the
compare_of() function. Now that drm_of_component_probe() has been enhanced,
let's try again the conversion.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/roc
Rockchip DRM driver cannot use the same compare_of() function to match
ports and remote ports (aka encoders) as their OF sub-trees look different.
Add a second compare function to be used when encoders are added to the
component framework and patch the existing users of the function
accordingly.
S
Hello,
When I have introduced the drm_of_component_probe() function I have managed to
break rockchip's DRM driver as the compare_of() function had to match both local
crtc ports and remote encoder ones. As suggested by Russell King, I have now
enhanced the drm_of_component_probe() function to take
Hi,
This avoids a NULL pointer dereference when no crtc is available (e.g.
the fsl,panel not assigned).
Any chance to get this into 4.4?
Tested-by: Stefan Agner
--
Stefan
On 2015-08-30 20:39, Jianwei Wang wrote:
> For state->fb may be NULL in fsl_dcu_drm_plane_atomic_check function,
> if so,
On Mon, 2015-11-16 at 12:50 +, Daniel Stone wrote:
> Rockchip previously treated a pageflip to the same framebuffer as a
> no-op, discarding the event if one was requested. This breaks Weston,
> which, when idle, sends a no-op vblank event to discover vblank
> timings if the vblank query interf
On Mon, 2015-11-16 at 12:50 +, Daniel Stone wrote:
> Passing -1 as the pipe for vblank events now triggers a WARN_ON, but
> had
> previously made multi-screen unusable anyway. Pass the correct pipe
> to
> the event-send function, and use the new API to make this a bit
> easier
> for us.
Tested
Hi Jonathan,
On 29 August 2015 at 08:32, Jonathan Gray wrote:
> The libdrm autoconf test for atomics uses __sync_val_compare_and_swap with
> the address of a function argument which triggers a gcc ICE on sparc64
> with the OpenBSD system compiler.
>
> Mark Kettenis pointed out that while other ar
On 16/11/15 12:55, Chris Wilson wrote:
> On Mon, Nov 16, 2015 at 12:08:08PM +, Tvrtko Ursulin wrote:
>>
>> On 16/11/15 11:12, Chris Wilson wrote:
>>> On Mon, Nov 16, 2015 at 10:24:45AM +, Tvrtko Ursulin wrote:
On 15/11/15 13:32, Chris Wilson wrote:
> +static u64 local_clock_us(uns
On Mon, Nov 16, 2015 at 12:08:08PM +, Tvrtko Ursulin wrote:
>
> On 16/11/15 11:12, Chris Wilson wrote:
> >On Mon, Nov 16, 2015 at 10:24:45AM +, Tvrtko Ursulin wrote:
> >>On 15/11/15 13:32, Chris Wilson wrote:
> >>>+static u64 local_clock_us(unsigned *cpu)
> >>>+{
> >>>+ u64 t;
> >>>+
> >>
frame
> * @vendor: union of all vendor infoframes
> * @audio: audio infoframe
> + * @mpeg: mpeg infoframe
s/mpeg/MPEG/
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151116/3e20ac28/attachment.sig>
Rockchip previously treated a pageflip to the same framebuffer as a
no-op, discarding the event if one was requested. This breaks Weston,
which, when idle, sends a no-op vblank event to discover vblank
timings if the vblank query interface is not usable.
Silently dropping events is also quite a ho
Passing -1 as the pipe for vblank events now triggers a WARN_ON, but had
previously made multi-screen unusable anyway. Pass the correct pipe to
the event-send function, and use the new API to make this a bit easier
for us.
Fixes WARN present since cc1ef118fc for every pageflip event sent:
[ 209.5
Hello,
On 2015-11-12 15:46, Daniel Stone wrote:
> On 12 November 2015 at 12:44, Tobias Jakobi
> wrote:
>> Daniel Stone wrote:
>>> On 10 November 2015 at 13:23, Marek Szyprowski >> samsung.com> wrote:
This patch series introduces a new life into Exynos IPP (Image Post
Processing) subsyst
On 16/11/15 11:12, Chris Wilson wrote:
> On Mon, Nov 16, 2015 at 10:24:45AM +, Tvrtko Ursulin wrote:
>>
>> Hi,
>>
>> On 15/11/15 13:32, Chris Wilson wrote:
>>> When waiting for high frequency requests, the finite amount of time
>>> required to set up the irq and wait upon it limits the respons
Hi Marek,
On 16 November 2015 at 11:35, Marek Szyprowski
wrote:
> On 2015-11-12 15:46, Daniel Stone wrote:
>> On 12 November 2015 at 12:44, Tobias Jakobi
>> wrote:
>>> I wonder how this interacts with page flipping. If I queue a pageflip
>>> event with a buffer that needs to go through the IPP
On 16/11/15 11:22, Chris Wilson wrote:
> On Mon, Nov 16, 2015 at 09:54:10AM +, Tvrtko Ursulin wrote:
>>
>> Hi,
>>
>> On 15/11/15 13:32, Chris Wilson wrote:
>>> The busywait in __i915_spin_request() does not respect pending signals
>>> and so may consume the entire timeslice for the task instea
On Mon, Nov 16, 2015 at 09:54:10AM +, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 15/11/15 13:32, Chris Wilson wrote:
> >The busywait in __i915_spin_request() does not respect pending signals
> >and so may consume the entire timeslice for the task instead of
> >returning to userspace to handle the s
Hi Lukas,
Please send the patch to the list and maintainers reported by
get_maintainer.pl (specifically the platform-driver-x86 list and my
infradead ID) so we can have the review on list.
Thanks,
On 11/9/15 11:28 AM, Lukas Wunner wrote:
> Hi Darren,
>
> the following patch is a useful fix for
On Mon, Nov 16, 2015 at 10:24:45AM +, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 15/11/15 13:32, Chris Wilson wrote:
> >When waiting for high frequency requests, the finite amount of time
> >required to set up the irq and wait upon it limits the response rate. By
> >busywaiting on the request compl
On Mon, Nov 16, 2015 at 10:02 AM, wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper
Hi,
On 15/11/15 13:32, Chris Wilson wrote:
> When waiting for high frequency requests, the finite amount of time
> required to set up the irq and wait upon it limits the response rate. By
> busywaiting on the request completion for a short while we can service
> the high frequency waits as quick
Hi,
On 15/11/15 13:32, Chris Wilson wrote:
> The busywait in __i915_spin_request() does not respect pending signals
> and so may consume the entire timeslice for the task instead of
> returning to userspace to handle the signal.
Obviously correct to break the spin, but if spending a jiffie to re
On 11/15/2015 06:32 AM, Chris Wilson wrote:
> When waiting for high frequency requests, the finite amount of time
> required to set up the irq and wait upon it limits the response rate. By
> busywaiting on the request completion for a short while we can service
> the high frequency waits as quick a
uctureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 21738 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151116/4e299a9d/attachment-0001.obj>
71 matches
Mail list logo
