On 8 December 2015 at 22:12, Nicolas Iooss
wrote:
> drm_dev_set_unique() uses a format string to define the unique name of a
> device. This feature is not used as currently all the calls to this
> function either use "%s" as a format string or directly use
> dev_name().
>
> Even though this seco
The following code pattern exists in some DRM drivers:
ddev = drm_dev_alloc(&driver, parent_dev);
drm_dev_set_unique(ddev, dev_name(parent_dev));
(Sometimes dev_name(ddev->dev) is used, which is the same.)
As suggested in
http://lists.freedesktop.org/archives/dri-devel/2015-December/0964
drm_dev_set_unique() uses a format string to define the unique name of a
device. This feature is not used as currently all the calls to this
function either use "%s" as a format string or directly use
dev_name().
Even though this second kind of call does not introduce security
problems, because t
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151208/31e149ca/attachment.html>
On Wed, Dec 09, 2015 at 10:10:39AM +0800, Yakir Yang wrote:
> Some edp screen do not have hpd signal, so we can't just return
> failed when hpd plug in detect failed.
>
> This is an hardware property, so we need add a devicetree property
> "analogix,need-force-hpd" to indicate this sutiation.
>
>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151208/a7e49590/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151208/de66a6b9/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151208/103923e7/attachment.html>
ng 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/20151208/30a39b32/attachment.html>
description||.run008.check_vm-dump
--
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/20151208/6422a
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151208/5112d445/attachment.html>
runs, so it's cleaner to reproduce
using a trace.
--
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/20151208/55a7322c/attachment.html>
The intel_dvo_dev_ops structures are never modified, so declare them as
const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/i915/dvo.h| 12 ++--
drivers/gpu/drm/i915/dvo_ch7017.c |2 +-
drivers/gpu/drm/i915/dvo_ch7xxx.c |2 +-
driv
On Tue, Dec 08, 2015 at 02:49:05PM +0100, Andrzej Hajda wrote:
> SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0. It is controlled
> via I2C bus.
>
> Signed-off-by: Andrzej Hajda
> ---
> .../bindings/video/bridge/sil-sii8620.txt | 34
> ++
> 1 file changed
Any more feedback on this?
Thanks,
Alex
On Thu, 26 Nov 2015, Alex Goins wrote:
> Hello all,
>
> For a while now, I've been working to fix tearing with PRIME. This is the
> same as the eighth version of the DRM component for PRIME synchronization,
>
> In this version, use_mmio_flip() tests agai
From: Ville Syrjälä
To get a better idea where exactly some error occurred during modeset,
put in some debug prints to tell us when the variuous encoder hooks are
getting called.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 58 +---
From: Ville Syrjälä
Rather than let the core generate usless encoder names, let's pass in
something that actually identifies the piece of hardware we're dealing
with.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_crt.c| 2 +-
drivers/gpu/drm/i915/intel_ddi.c| 2 +-
From: Ville Syrjälä
Let's name our planes in a way that makes sense wrt. the spec:
- skl+ -> "plane 1A", "plane 2A", "plane 1C", "cursor A" etc.
- g4x+ -> "primary A", "primary B", "sprite A", "cursor C" etc.
- pre-g4x -> "plane A", "cursor B" etc.
v2: Rebase on top of the fixed/cleaned error
From: Ville Syrjälä
Call intel_plane_destroy() instead of drm_plane_cleanup() so that we
also free the plane struct itself when bailing out of the crtc init.
And make intel_plane_destroy() NULL tolerant to avoid having to check
for it in the caller.
Signed-off-by: Ville Syrjälä
---
driver
From: Ville Syrjälä
Deal with errors from drm_universal_plane_init() in primary and cursor
plane init paths (sprites were already covered). Also make the code
neater by using goto for error handling.
v2: Rebased due to drm_universal_plane_init() 'name' parameter
v3: Another rebase due to s/""/
From: Ville Syrjälä
v2: Fix intel_crtc leak on failure to allocate the name
Use a local 'name' variable to make things easier
v3: Pass the name as a function arguemnt to drm_crtc_init_with_planes() (Jani)
v4: Pass the printf style format string to drm_crtc_init_with_planes()
Signed-off-by:
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 38 +---
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 39ee629cb40
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 55
drivers/gpu/drm/i915/intel_fbdev.c | 5 ++--
2 files changed, 33 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drive
From: Ville Syrjälä
Show a sensible name for the plane in debug mesages. The driver
may supply its own name, otherwise the core genrates the name
("plane-0", "plane-1" etc.).
v2: kstrdup() the name passed by the caller (Jani)
v3: Generate a default name if the driver doesn't supply one
Signed
From: Ville Syrjälä
Show a sensible name for the crtc in debug mesages. The driver may
supply its own name, otherwise the core genrates the name
("crtc-0", "crtc-1" etc.).
v2: kstrdup() the name passed by the caller (Jani)
v3: Generate a default name if the driver doesn't supply one
Signed-of
From: Ville Syrjälä
Use the encoder name passed by the driver if non-NULL, otherwise fall
back to the old style name.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b
From: Ville Syrjälä
Done with coccinelle for the most part. However, it thinks '...' is
part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder
in its place and got rid of it with sed afterwards.
@@
identifier dev, encoder, funcs;
@@
int drm_encoder_init(struct drm_device *dev,
From: Ville Syrjälä
Done with coccinelle for the most part. It choked on
msm/mdp/mdp5/mdp5_plane.c like so:
"BAD:! enum drm_plane_type type;"
No idea how to deal with that, so I just fixed that up
by hand.
Also it thinks '...' is part of the semantic patch, so I put an
'int DOTDOTDOT' pla
From: Ville Syrjälä
Done with coccinelle for the most part. However, it thinks '...' is
part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder
in its place and got rid of it with sed afterwards.
I didn't convert drm_crtc_init() since passing the varargs through
would mean either c
From: Ville Syrjälä
I've done some more modeset log staring recently and again got
fed up with the noise. So here's another attempt at making the
logs make some sense.
This time I pass a printf style format string to the init functions, so
that callers don't have to worry about any snprintf bu
On 08/12/15 13:59, David Herrmann wrote:
> Hi
>
> On Fri, Dec 4, 2015 at 9:07 AM, Daniel Vetter wrote:
>> On Thu, Dec 03, 2015 at 07:26:31PM +0200, Martin Peres wrote:
>>> You are right Ilia, this is indeed what Jaakko and I had in mind, but they
>>> did not re-use the fuse/cuse framework to do th
omap_fbdev always creates a framebuffer with ARGB pixel format. On
OMAP3 we have VIDEO1 overlay that does not support ARGB, and on
OMAP2 none of the overlays support ARGB888.
This patch changes the omap_fbdev's fb to XRGB, which is supported
by all platforms.
Signed-off-by: Tomi Valke
Hi
On Tue, Dec 8, 2015 at 5:39 PM, Martin Peres wrote:
> On 08/12/15 13:59, David Herrmann wrote:
>> I looked into all this when working on WFD, but I cannot recommend
>> going down that road. First of all, you still need heavy modifications
>> for gnome-shell, kwin, and friends, as neither of th
On 07.12.2015 17:41, Michel Dänzer wrote:
> On 05.12.2015 19:12, Daniel Vetter wrote:
>> On Fri, Dec 04, 2015 at 05:43:33PM -0500, Ilia Mirkin wrote:
>>> On Fri, Dec 4, 2015 at 5:05 PM, Russell King - ARM Linux
>>> wrote:
On Fri, Dec 04, 2015 at 03:42:47PM -0500, Ilia Mirkin wrote:
> On
On Mon, Dec 07, 2015 at 08:12:00PM +, Mark Brown wrote:
> On Tue, Dec 08, 2015 at 02:47:58AM +0530, Subhransu S. Prusty wrote:
> > This patch series adds DP audio and hotplug notification support.
>
> Not related to the code but there seems to be something wrong with the
> time configuration o
On Tue, Dec 08, 2015 at 04:25:27PM +, Robin Murphy wrote:
> Hi Liviu,
>
> On 07/12/15 12:11, Liviu Dudau wrote:
> >The HDLCD controller is a display controller that supports resolutions
> >up to 4096x4096 pixels. It is present on various development boards
> >produced by ARM Ltd and emulated b
The STi drm driver correctly warns about invalid format strings
when built with 64-bit dma_addr_t:
sti_hqvdp.c: In function 'sti_hqvdp_vtg_cb':
sti_hqvdp.c:605:119: warning: format '%x' expects argument of type 'unsigned
int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}'
[-W
Hi Yakir,
Am Montag, 7. Dezember 2015, 14:37:19 schrieb Yakir Yang:
>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 plat
Hi Liviu,
On 07/12/15 12:11, Liviu Dudau wrote:
> The HDLCD controller is a display controller that supports resolutions
> up to 4096x4096 pixels. It is present on various development boards
> produced by ARM Ltd and emulated by the latest Fast Models from the
> company.
>
> Cc: David Airlie
>
On Mon, 07 Dec 2015, "Subhransu S. Prusty"
wrote:
> To fill the audio infoframe it is required to identify the
> connection type as DP or HDMI. This patch adds an API which
> parses ELD and returns the display type of connected.
>
> Signed-off-by: Subhransu S. Prusty
> Signed-off-by: Vinod Koul
Hello,
On Tuesday 08 December 2015 10:59:05 Pierre Moreau wrote:
> On 09:49 AM - Dec 08 2015, Daniel Vetter wrote:
> > Every time I type or review docs this seems a bit different. Try to
> > document the common style so we can try to unify at least new docs.
> >
> > Signed-off-by: Daniel Vetter
On 08.12.2015 15:04, Ilia Mirkin wrote:
> On Tue, Dec 8, 2015 at 8:43 AM, Ernst Sjöstrand wrote:
>> Hello list!
>>
>> I lurk here and try to follow Mesa/DRI and most specifically Radeon
>> driver development, report bugs, test new stuff and help get the bugs
>> closed and so on...
>>
>> However I
On 8 December 2015 at 14:22, Christian König
wrote:
> On 08.12.2015 15:04, Ilia Mirkin wrote:
>>
>> On Tue, Dec 8, 2015 at 8:43 AM, Ernst Sjöstrand wrote:
>>>
>>> Hello list!
>>>
>>> I lurk here and try to follow Mesa/DRI and most specifically Radeon
>>> driver development, report bugs, test n
Dave,
A couple of fixes for vmwgfx. A WARN() fix by Dan Carpenter,
a TTM read/write lock imbalance causing occasional hangs with Wayland and
an implementation of cursor_set2 to fix incorrectly offset Wayland cursors.
The following changes since commit 2f1371614a5d49428846b90673a89036518dffad:
M
Hi Ernst,
On 8 December 2015 at 13:43, Ernst Sjöstrand wrote:
> Hello list!
>
> I lurk here and try to follow Mesa/DRI and most specifically Radeon
> driver development, report bugs, test new stuff and help get the bugs
> closed and so on...
>
> However I see that the commit messages for AMD/Rad
SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
It is controlled via I2C bus. Its interaction with other
devices in video pipeline is performed mainly on HW level.
The only interaction it does on device driver level is
filtering-out unsupported video modes, it exposes drm_bridge
interfac
SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0. It is controlled
via I2C bus.
Signed-off-by: Andrzej Hajda
---
.../bindings/video/bridge/sil-sii8620.txt | 34 ++
1 file changed, 34 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/
This header adds definitions specific to MHL protocol.
Signed-off-by: Andrzej Hajda
---
include/linux/mhl.h | 292
1 file changed, 292 insertions(+)
create mode 100644 include/linux/mhl.h
diff --git a/include/linux/mhl.h b/include/linux/mhl.
Hi,
This patchset adds MHL bridge driver for Silicon Image SiI8620 chip.
The chip is quite powerful, supports MHL versions up to 3.0. It is present
in multiple mobile devices.
I have put common MHL definitions into include/linux/mhl.h header file,
similarily to include/linux/hdmi.h.
The patchset
Hello list!
I lurk here and try to follow Mesa/DRI and most specifically Radeon
driver development, report bugs, test new stuff and help get the bugs
closed and so on...
However I see that the commit messages for AMD/Radeon are often very
unhelpful. They don't state the motivation behind the comm
Hi
On Fri, Dec 4, 2015 at 9:07 AM, Daniel Vetter wrote:
> On Thu, Dec 03, 2015 at 07:26:31PM +0200, Martin Peres wrote:
>> You are right Ilia, this is indeed what Jaakko and I had in mind, but they
>> did not re-use the fuse/cuse framework to do the serialization of the
>> ioctls.
>>
>> Not sure
Reviewed-by: Thomas Hellstrom
On 12/04/2015 09:45 AM, Daniel Vetter wrote:
> These hooks will be gone soon.
>
> Cc: Thomas Hellstrom
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 16
> drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4
> drivers/gp
On Tue, 08 Dec 2015, Daniel Vetter wrote:
> On Tue, Dec 08, 2015 at 09:53:05AM +, Tvrtko Ursulin wrote:
>>
>> Hi,
>>
>> On 07/12/15 19:25, Andy Lutomirski wrote:
>> >[53834.386369] traps: gnome-session-b[2308] general protection
>> >ip:7f10efc1fc2b sp:7ffdfde31880 error:0 in
>> >libc-2.22.so
Hi,
On 8 December 2015 at 08:49, Daniel Vetter wrote:
> We want this for consistency with existing page_flip semantics.
>
> Since this spurred quite a discussion on IRC also document why we
> reject even generation when the pipe is off: It's not that it's hard
> to implement, but userspace has a
On 08.12.2015 02:49, Oded Gabbay wrote:
> On Mon, Dec 7, 2015 at 9:51 AM, Michel Dänzer wrote:
>> On 05.12.2015 06:09, Oded Gabbay wrote:
>>>
>>> @@ -765,7 +765,7 @@ int radeon_vce_ring_test(struct radeon_device *rdev,
>>> struct radeon_ring *ring)
>>> ring->idx, r);
>>>
On 08.12.2015 10:16, Eric Anholt wrote:
> Emil Velikov writes:
>
>> Hi Eric,
>>
>> A couple of suggestions/requests on the UAPI header side
>>
>> On 1 December 2015 at 20:35, Eric Anholt wrote:
>>
>>> --- /dev/null
>>> +++ b/include/uapi/drm/vc4_drm.h
>>
>>> +#include
>>> +
>> Can we make this
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/i2c/tda998x_drv.c:1354:2: error: unknown field 'save' specified
in initializer
.save = tda998x_encoder_save,
^
drivers/gpu/drm/i2c/tda998x_drv.c:1354:10: warning: initial
On Tue, Dec 08, 2015 at 10:59:05AM +0100, Pierre Moreau wrote:
> On 09:49 AM - Dec 08 2015, Daniel Vetter wrote:
> > +
> > + Functions which have a non-void return value should
> > have a
> > + section called "Returns" explaining the expected return values in
> > + different cas
2015ë
12ì 08ì¼ 10:47ì Krzysztof Kozlowski ì´(ê°) ì´ ê¸:
> On 08.12.2015 10:33, Javier Martinez Canillas wrote:
>> Hello Krzysztof,
>>
>> On 12/07/2015 09:45 PM, Krzysztof Kozlowski wrote:
>>> On 07.12.2015 21:52, Inki Dae wrote:
From: Javier Martinez Canillas
The DT bin
On Tue, Dec 08, 2015 at 09:30:48AM +, Emil Velikov wrote:
> On 8 December 2015 at 08:49, Daniel Vetter wrote:
> > In my quest to remove all the drm_encoder_helper_funcs->save/restore
> > hooks I somehow missed that this driver has a dummy set too - I
> > thought all the i2c drivers only set up
On Mon, Dec 07, 2015 at 10:35:06AM -0800, Rodrigo Vivi wrote:
> save/restore have been removed from drm_encoder_helper_funcs by
> 'commit 79f13ad5d8e0 ("drm: Move encoder->save/restore into nouveau")'
>
> But this module was still defining it with empty content causing
> compilation fails:
>
> dr
2015ë
12ì 08ì¼ 09:48ì Krzysztof Kozlowski ì´(ê°) ì´ ê¸:
> On 08.12.2015 00:36, Inki Dae wrote:
>> Hi Javier,
>>
>> 2015-12-07 22:41 GMT+09:00 Javier Martinez Canillas > osg.samsung.com>:
>>> Hello Inki,
>>>
>>> On 12/07/2015 09:52 AM, Inki Dae wrote:
From: Javier Martinez Canillas
On Tue, Dec 08, 2015 at 09:53:05AM +, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 07/12/15 19:25, Andy Lutomirski wrote:
> >[53834.386369] traps: gnome-session-b[2308] general protection
> >ip:7f10efc1fc2b sp:7ffdfde31880 error:0 in
> >libc-2.22.so[7f10efba1000+1b7000]
> >[53834.687584]
Hello Daniel,
Just some typo comments below.
On 09:49 AM - Dec 08 2015, Daniel Vetter wrote:
> Every time I type or review docs this seems a bit different. Try to
> document the common style so we can try to unify at least new docs.
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/DocBoo
On 08.12.2015 10:33, Javier Martinez Canillas wrote:
> Hello Krzysztof,
>
> On 12/07/2015 09:45 PM, Krzysztof Kozlowski wrote:
>> On 07.12.2015 21:52, Inki Dae wrote:
>>> From: Javier Martinez Canillas
>>>
>>> The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent
>>> since i
This can be parsed with vc4-gpu-tools tools for trying to figure out
what was going on.
Signed-off-by: Eric Anholt
---
v2: Use __u32-style types.
drivers/gpu/drm/vc4/vc4_drv.c | 2 +
drivers/gpu/drm/vc4/vc4_drv.h | 4 +
drivers/gpu/drm/vc4/vc4_gem.c | 185 ++
An async pageflip stores the modeset to be done and executes it once
the BOs are ready to be displayed. This gets us about 3x performance
in full screen rendering with pageflipping.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_crtc.c | 99 +-
drivers/gpu/drm/
The user submission is basically a pointer to a command list and a
pointer to uniforms. We copy those in to the kernel, validate and
relocate them, and store the result in a GPU BO which we queue for
execution.
Signed-off-by: Eric Anholt
---
v2: Drop support for NV shader recs (not necessary fo
This is the component of the GPU that does 3D rendering.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/Makefile | 1 +
drivers/gpu/drm/vc4/vc4_debugfs.c | 2 +
drivers/gpu/drm/vc4/vc4_drv.c | 1 +
drivers/gpu/drm/vc4/vc4_drv.h | 13 +++
drivers/gpu/drm/vc4/vc4_v3d.c
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_regs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
index 9e4e904..4e52a0a 100644
--- a/drivers/gpu/drm/vc4/vc4_regs.h
+++ b/drivers/gpu/drm/vc4/vc4_regs.h
Since we have no MMU, the kernel needs to validate that the submitted
shader code won't make any accesses to memory that the user doesn't
control, which involves banning some operations (general purpose DMA
writes), and tracking where we need to write out pointers for other
operations (texture samp
While there exist dumb APIs for creating and mapping BOs, one of the
rules is that drivers doing 3D acceleration have to provide their own
APIs for buffer allocation (besides, the pitch/height parameters of
the dumb alloc don't really make sense for a lot of 3D allocations).
Signed-off-by: Eric An
We need to allocate new BOs in the kernel as part of each frame, but
the CMA allocator is way too slow for that. As an optimization, keep
track of recently-freed BOs and reuse them, with a 1 second timeout to
fully free them back to the system.
This improves 3D performance by about 15%.
Signed-o
The CMA helpers had no way for a driver to extend the struct with its
own fields. Since the CMA helpers are mostly "Allocate a
drm_gem_cma_object, then fill in a few fields", it's hard to write as
pure helpers without passing in a driver callback for the allocate
step.
Signed-off-by: Eric Anholt
Updated version of the patch series for Emil's comments about
vc4_drm.h. I also pulled in some improvements to the validation code
which I'd written in Mesa and failed to propagate to this branch.
The series can be found at:
https://github.com/anholt/linux/tree/vc4-kms-v3d-squash-2
and a versio
more manageable since I added lockdep annotations to
> console_lock.
I don't know... I just have a vague recollection that I was having
trouble with the lock with... crashes during blanking, perhaps. I really
can't remember, so possibly things are better now, or I just remember wrong.
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/20151208/a1acfb5b/attachment.sig>
On Tue, Dec 08, 2015 at 11:11:01AM +0100, Daniel Vetter wrote:
> On Tue, Dec 08, 2015 at 09:30:48AM +, Emil Velikov wrote:
> > On 8 December 2015 at 08:49, Daniel Vetter
> > wrote:
> > > In my quest to remove all the drm_encoder_helper_funcs->save/restore
> > > hooks I somehow missed that thi
Hi,
On 07/12/15 19:25, Andy Lutomirski wrote:
> [53834.386369] traps: gnome-session-b[2308] general protection
> ip:7f10efc1fc2b sp:7ffdfde31880 error:0 in
> libc-2.22.so[7f10efba1000+1b7000]
> [53834.687584] [ cut here ]
> [53834.687607] WARNING: CPU: 0 PID: 23730 at
> dr
In my quest to remove all the drm_encoder_helper_funcs->save/restore
hooks I somehow missed that this driver has a dummy set too - I
thought all the i2c drivers only set up the slave_encoder save/restore
hooks, which I've left. Remove them.
Reported-by: Stephen Rothwell
Cc: Stephen Rothwell
Cc:
We want this for consistency with existing page_flip semantics.
Since this spurred quite a discussion on IRC also document why we
reject even generation when the pipe is off: It's not that it's hard
to implement, but userspace has a track recording proofing that it's
way too easy to accidentally a
I missed a few paragraphs in the docbook that need to be pulled into
the fbdev vfunc docs.
Cc: Thierry Reding
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/gpu.tmpl | 72 +-
include/drm/drm_crtc.h | 18 ++-
2 files changed, 18 ins
Just a remnant from an old iteration of this patch that I've forgotten
to remove: We only need the encoder to figure out whether it has been
reassigned in this update already or not to figure out whether there's
a conflict or not.
Reported-by: Thierry Reding
Cc: Thierry Reding
Signed-off-by: Dan
Every time I type or review docs this seems a bit different. Try to
document the common style so we can try to unify at least new docs.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/gpu.tmpl | 37 +
1 file changed, 37 insertions(+)
diff --git a/Docum
On 08.12.2015 00:36, Inki Dae wrote:
> Hi Javier,
>
> 2015-12-07 22:41 GMT+09:00 Javier Martinez Canillas osg.samsung.com>:
>> Hello Inki,
>>
>> On 12/07/2015 09:52 AM, Inki Dae wrote:
>>> From: Javier Martinez Canillas
>>>
>>
>> Thanks a lot for posting this patch.
>>
>>> The DT binding for the
On 07.12.2015 21:52, Inki Dae wrote:
> From: Javier Martinez Canillas
>
> The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent
> since it uses a phandle to describe the connection between the DP port and
> the display panel but uses the OF graph ports and endpoints to descr
Op 07-12-15 om 11:34 schreef Thierry Reding:
> On Tue, Nov 24, 2015 at 10:34:35AM +0100, Maarten Lankhorst wrote:
> [...]
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index cee31d43cd1c..fb79c54b2aed 100644
>> --- a/drivers/gpu/drm/drm_atomic_help
On 8 December 2015 at 08:49, Daniel Vetter wrote:
> In my quest to remove all the drm_encoder_helper_funcs->save/restore
> hooks I somehow missed that this driver has a dummy set too - I
> thought all the i2c drivers only set up the slave_encoder save/restore
> hooks, which I've left. Remove them.
On Mon, Dec 07, 2015 at 09:52:37PM +0900, Inki Dae wrote:
> This patch updates a ports node binding for panel.
>
> With this, dp node can have a ports node which describes
> a remote endpoint node that can be connected to panel or bridge
> node.
>
> Changelog v2:
> - remove unnecessary properties
On Mon, Dec 07, 2015 at 03:33:00PM +, Daniel Stone wrote:
> Hi,
>
> On 4 December 2015 at 08:46, Daniel Vetter wrote:
> > + /*
> > +* Reject event generation for when a CRTC is off and stays off. It
> > +* wouldn't be hard to implement this, but userspace has a track
>
On Mon, Dec 07, 2015 at 04:28:45PM -0200, Gustavo Padovan wrote:
> Hi,
>
> any comments/update on this? Thanks
My ack from the previous version still stands.
-Daniel
>
> Gustavo
>
> 2015-11-26 Gustavo Padovan :
>
> > From: Gustavo Padovan
> >
> > - remove CONFIG_SW_SYNC_USER, it is u
On Mon, Dec 07, 2015 at 07:32:42PM +0200, Tomi Valkeinen wrote:
>
> On 25/08/15 16:45, Daniel Vetter wrote:
> > When the usual fbcon legacy options are enabled we have
> > ->register_framebuffer
> > ->fb notifier chain calls into fbcon
> > ->fbcon sets up console on new fbi
> > ->fbi->
Op 07-12-15 om 11:02 schreef Thierry Reding:
> On Tue, Nov 24, 2015 at 02:35:34PM +0100, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/tegra/dsi.c | 9 +++--
>> 1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tegra/ds
On Mon, Dec 07, 2015 at 02:40:42PM +0800, Yakir Yang wrote:
> Some edp screen do not have hpd signal, so we can't just return
> failed when hpd plug in detect failed.
>
> This is an hardware property, so we need add a devicetree property
> "analogix,need-force-hpd" to indicate this sutiation.
I c
On Mon, Dec 07, 2015 at 02:39:50PM +0800, Yakir Yang wrote:
> Add dt binding documentation for rockchip display port PHY.
>
> Signed-off-by: Yakir Yang
> Reviewed-by: Heiko Stuebner
One possible typo below, otherwise:
Acked-by: Rob Herring
> ---
> Changes in v10: None
> Changes in v9: None
>
On Tue, Dec 8, 2015 at 8:43 AM, Ernst Sjöstrand wrote:
> Hello list!
>
> I lurk here and try to follow Mesa/DRI and most specifically Radeon
> driver development, report bugs, test new stuff and help get the bugs
> closed and so on...
>
> However I see that the commit messages for AMD/Radeon are
On Mon, Dec 07, 2015 at 02:39:34PM +0800, Yakir Yang wrote:
> Rockchip DP driver is a helper driver of analogix_dp coder driver,
> so most of the DT property should be descriped in analogix_dp document.
>
> Signed-off-by: Yakir Yang
> Reviewed-by: Heiko Stuebner
I already acked the previous v10
like this.
IIRC there is also a rather big warning in the fancontrol manual about this.
--
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/a
On Mon, Dec 07, 2015 at 02:39:07PM +0800, Yakir Yang wrote:
> Analogix dp driver is split from exynos dp driver, so we just
> make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
>
> Beside update some exynos dtsi file with the latest change
> according to the devicetree binding document
On Tue, Dec 8, 2015 at 3:49 AM, Daniel Vetter wrote:
> We want this for consistency with existing page_flip semantics.
>
> Since this spurred quite a discussion on IRC also document why we
> reject even generation when the pipe is off: It's not that it's hard
event generation?
> to implement, bu
;http://lists.freedesktop.org/archives/dri-devel/attachments/20151208/5da402ce/attachment.html>
1 - 100 of 115 matches
Mail list logo
