On Thu, Sep 08, 2016 at 05:44:24PM +0300, Laurent Pinchart wrote:
> The driver needs the number of bytes per pixel, not the bpp and depth
> info meant for fbdev compatibility. Use the right API.
>
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v3:
>
> - Renamed bpp to cpp
> ---
> drive
On Sun, Sep 18, 2016 at 01:17:27PM +0300, Laurent Pinchart wrote:
> Various pieces of information about DRM formats (number of planes, color
> depth, chroma subsampling, ...) are scattered across different helper
> functions in the DRM core. Callers of those functions often need to
> access more th
On Thu, Sep 15, 2016 at 01:31:23AM +0300, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the review.
>
> On Wednesday 14 Sep 2016 16:23:09 Tomi Valkeinen wrote:
> > On 08/09/16 17:44, Laurent Pinchart wrote:
> > > Replace calls to the drm_format_*() helper functions with direct use of
> > >
tes of the trace should be the actual game.
Thanks for looking into it!
--
You are receiving this mail because:
You are on the CC list for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments
-devel/attachments/20160921/267ff79a/attachment-0001.html>
From: Markus Elfring
Date: Tue, 20 Sep 2016 22:22:14 +0200
* A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle s
Hi Rafael,
2016-09-14 Rafael Antognolli :
> Hi Chris and Gustavo,
>
> On Mon, Aug 29, 2016 at 07:16:13PM +0100, Chris Wilson wrote:
> > If we being polled with a timeout of zero, a nonblocking busy query,
> > we don't need to install any fence callbacks as we will not be waiting.
> > As we only
On 09/19/2016 06:43 PM, Daniel Vetter wrote:
> On Fri, Sep 02, 2016 at 03:00:38PM +0530, Archit Taneja wrote:
>>
>>
>> On 8/31/2016 9:39 PM, Daniel Vetter wrote:
>>> Big thing is untangling and carefully documenting the different uapi
>>> types of planes. I also sprinkled a few more cross referen
Hi
On Tue, Sep 20, 2016 at 11:25 AM, Alexander Potapenko
wrote:
> On Tue, Sep 20, 2016 at 11:21 AM, David Herrmann
> wrote:
>> Hi
>>
>> On Mon, Sep 5, 2016 at 10:30 AM, Dmitry Vyukov wrote:
>>> On Fri, Aug 19, 2016 at 7:10 PM, Alexander Potapenko
>>> wrote:
Hello,
the program
From: Markus Elfring
Date: Wed, 21 Sep 2016 08:44:38 +0200
The script "checkpatch.pl" can point out that assignments should usually
not be performed within condition checks.
Thus move the assignment for one local variable to a separate statement
in this function.
Signed-off-by: Markus Elfring
-
From: Markus Elfring
Date: Wed, 21 Sep 2016 08:28:08 +0200
Do not use curly brackets at four source code places
where a single statement should be sufficient.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c | 14 +-
1 file changed, 5 insertions(+
From: Markus Elfring
Date: Wed, 21 Sep 2016 08:58:41 +0200
Use another space character behind the keyword "if" according to
the Linux coding style convention.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
On Thu, Sep 08, 2016 at 05:44:25PM +0300, Laurent Pinchart wrote:
> The driver needs the number of bytes per pixel, not the bpp and depth
> info meant for fbdev compatibility. Use the right API.
>
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v3:
>
> - Renamed bpp to cpp
> ---
> drive
Hello,
I'm currently facing the following problem.
I want to use a devfreq device in one of the Exynos sub drivers, namely
the G2D sub driver. My current approach is to use
devfreq_get_devfreq_by_phandle() in g2d_probe(). But at the G2D probing
time the devfreq subsystem isn't initialized yet, an
Hi
On Wed, Sep 21, 2016 at 6:47 AM, poma wrote:
> Within X server, on top of DisplayLink GPU USB2.0 device,
> screen content is not refreshed i.e. updated.
>
> This fixes commit:
>
> - e375882406d0cc24030746638592004755ed4ae0
> "drm/udl: Use drm_fb_helper deferred_io support"
>
> Thanks Noralf
ly
more bugs to fix.
Still working on this.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160921/4b44937b/attachment-0001.html>
On Thu, Sep 08, 2016 at 05:44:16PM +0300, Laurent Pinchart wrote:
> Turn the drm_format_*() helpers into wrappers around the drm_format_info
> lookup function to centralize all format information in a single place.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_fourcc.c | 186
>
From: Gustavo Padovan
When merging sync_files there is a case when we can end up with only one
fence in the merged sync_file: when all fences belong to the same
timeline.
So for this case a fence_array is not created instead we just assigned the
fence to sync_file->fence. Then we do not use the
On Mon, Sep 19, 2016 at 7:14 AM, Daniel Kurtz wrote:
> Hi Sean,
>
> On Sat, Sep 17, 2016 at 2:22 AM, Sean Paul wrote:
>>
>> Instead of assigning device managed resources to local variables,
>> keep track of them in the vop struct.
>
> Why this patch?
> Is it fixing an issue?
> Or, is it preparing
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160921/c8bd252b/attachment-0001.html>
On Thu, Sep 08, 2016 at 05:44:26PM +0300, Laurent Pinchart wrote:
> The driver is the last users of the drm_fb_get_bpp_depth() function. It
> should ideally be converted to use struct drm_mode_fb_cmd2 instead of
> the legacy struct drm_mode_fb_cmd internally, but that will require
> broad changes a
From: Markus Elfring
Date: Wed, 21 Sep 2016 09:09:09 +0200
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (5):
Use kmalloc_array() in nvbios_iccsense_parse()
Use kmalloc_array() in gt215_link_train()
Delete unnecessary braces
Adjust a kz
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160921/2327ca3b/attachment-0001.html>
On Thu, Sep 08, 2016 at 05:44:27PM +0300, Laurent Pinchart wrote:
> The driver doesn't need the color depth, only the number of bits per
> pixel. Use the right API.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/arm/malidp_hw.c | 7 +--
> 1 file cha
bed...
Name: .config.gz
Type: application/gzip
Size: 28206 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160921/62d3c810/attachment-0001.gz>
Open 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/gzip
Size: 23322 bytes
Desc: not available
URL:
<https://lists.freed
from Michel Dänzer ---
Monk, any ideas? (See comment 6 and comment 9)
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160
et me know if you'd like me to raise a bug
> Please do so, it's nice to refer to when making a fix for it.
>
> Could you attach the contents of /sys/kernel/debug/dri/0/i915_ddb_info for
> working and not-working in it?
>
> ~Maarten
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160921/aa5647e9/attachment-0001.html>
Hey,
Op 20-09-16 om 20:45 schreef Mike Lothian:
> Hi
>
> I've bisected back to this commit in the drm-intel-nightly branch
>
> 05a76d3d6ad1ee9f9814f88949cc9305fc165460 is the first bad commit
> commit 05a76d3d6ad1ee9f9814f88949cc9305fc165460
> Author: Lyude
> Date: Wed Aug 17 15:55:57 2016 -040
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160921/8be5c86c/attachment-0001.html>
mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160921/114818ec/attachment-0001.html>
From: Markus Elfring
Date: Tue, 20 Sep 2016 22:32:14 +0200
* A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle s
On Thu, Sep 08, 2016 at 05:44:22PM +0300, Laurent Pinchart wrote:
> The driver doesn't need the color depth, only the number of bits per
> pixel. Use the right API.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/cirrus/cirrus_fbdev.c | 6 +++---
> drive
We get 4 warnings when building kernel with W=1:
drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:397:12: warning: no previous prototype
for 'tilcdc_tfp410_init' [-Wmissing-prototypes]
drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:402:13: warning: no previous prototype
for 'tilcdc_tfp410_fini' [-Wmissing-prototyp
On Thu, Sep 08, 2016 at 05:44:23PM +0300, Laurent Pinchart wrote:
> The driver uses drm_fb_get_bpp_depth() to check whether it can support
> the format requested by userspace when creating a framebuffer. This
> isn't the right API, as it doesn't differentiate between RGB formats
> other than on a d
Within X server, on top of DisplayLink GPU USB2.0 device,
screen content is not refreshed i.e. updated.
This fixes commit:
- e375882406d0cc24030746638592004755ed4ae0
"drm/udl: Use drm_fb_helper deferred_io support"
Thanks Noralf and Daniel for the comments.
Tested-by: poma
---
drivers/gpu/d
Dear All:
I am Ginny Chen from Mediatek company.I start to work with DRM for a
while and now I am evaluating our display architecture for our new SoC.
I would like to adopt DRM to develop our display driver.
However, in our new SoC, the input source of display engine could be
memory or direct-l
On Tue, Sep 20, 2016 at 11:29 AM, Chris Wilson
wrote:
> drm_atomic_state has a complicated single owner model that tracks the
> single reference from allocation through to destruction on another
> thread - or perhaps on a local error path. We can simplify this tracking
> by using reference counti
We get 1 warning when building kernel with W=1:
drivers/gpu/drm/tilcdc/tilcdc_drv.c:64:5: warning: no previous prototype for
'tilcdc_atomic_check' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
S
On Mon, Sep 19, 2016 at 4:11 PM, Daniel Vetter wrote:
> On Tue, Sep 06, 2016 at 12:59:31PM -0400, Sean Paul wrote:
>> On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter
>> wrote:
>> > Just pure code movement, cleanup and polish will happen in later
>> > patches.
>> >
>> > v2: Don't forget all the i
The original style was correct, the new style is wrong. Multi-line
indents get curly braces for readability.
regards,
dan carpenter
-
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160921/6116cfce/attachment.html>
On Wed, Sep 21, 2016 at 3:36 PM, Sean Paul wrote:
> On Mon, Sep 19, 2016 at 7:14 AM, Daniel Kurtz wrote:
>> Hi Sean,
>>
>> On Sat, Sep 17, 2016 at 2:22 AM, Sean Paul wrote:
>>>
>>> Instead of assigning device managed resources to local variables,
>>> keep track of them in the vop struct.
>>
>> W
Hi Russell,
Are you in a position to be able to test this now?
I believe it should work fine on anything since 4.8-rc1.
(specifically, either of commit e28cd4d0a223 or 79190ea2658a)
Thanks,
Brian
On Tue, Aug 09, 2016 at 11:48:12PM +0100, Russell King - ARM Linux
wrote:
>On Tue, Aug 09, 2016 at
Imo zpos, rotatation, blending eq (once we have it) and all that
should be in drm_blend.c, since those are all about how exactly the
pixels are rendered onto the CRTC's visible area. Also noticed that
one exported function accidentally ended up in drm_crtc_internal.h,
move it to the right place too
Try to spec a bit more precisely how they all fit together, now that
at least the code is for all the additional properties is in one
place.
Also remove the entries for the standardized properties from the
table, because that thing is supremely unmaintaineable.
v2: Fix typos Sean spotted.
Cc: Vi
For both the new degamm/lut/gamma atomic combo, and the old legacy
gamma tables.
Acked-by: Lionel Landwerlin
Cc: Lionel Landwerlin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_color_mgmt.c| 248
driv
Again move it from the unmaintainable csv into DOC free-form overview
sections.
v2: Types Lionel&Sean spotted.
Cc: Lionel Landwerlin
Reviewed-by: Sean Paul
Reviewed-by: Lionel Landwerlin
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst| 12 +
Documentation/gpu/k
Just pure code movement, cleanup and polish will happen in later
patches.
v2: Don't forget all the ioctl! To extract those cleanly I decided to
put check_src_coords into drm_framebuffer.c (and give it a
drm_framebuffer_ prefix), since that just checks framebuffer
constraints.
v3: rebase over PAGE
We removed it in
commit 6ab10b76ff6252bd9be0849c40f5865e39a29961
Author: Daniel Vetter
Date: Fri Aug 12 22:48:45 2016 +0200
drm/kms: Nuke dirty_info property
Reviewed-by: Sean Paul
Signed-off-by: Daniel Vetter
---
Documentation/gpu/kms-properties.csv | 1 -
1 file changed, 1 deletion(-
Big thing is untangling and carefully documenting the different uapi
types of planes. I also sprinkled a few more cross references around
to make this easier to discover.
As usual, remove the kerneldoc for internal functions which are not
exported. Aside: We should probably go OCD on all the ioctl
and feel free to Cc: me.
The following changes since commit
3be7988674ab33565700a37b210f502563d932e6:
Linux 4.8-rc7 (2016-09-18 17:27:41 -0700)
are available in the git repository at:
git://git.kraxel.org/linux tags/drm-qemu-20160921
for you to fetch changes up to
On 13/09/16 09:52 PM, Christian König wrote:
> Am 13.09.2016 um 11:39 schrieb Chris Wilson:
>> On Tue, Sep 13, 2016 at 10:44:11AM +0200, Christian König wrote:
>>> Am 09.09.2016 um 03:15 schrieb Michel Dänzer:
On 09/09/16 01:23 AM, Chris Wilson wrote:
> On Thu, Sep 08, 2016 at 05:21:42P
Am 21.09.2016 um 11:56 schrieb Michel Dänzer:
>
> Looks like there are different interpretations of the semantics of
> exclusive vs. shared fences. Where are these semantics documented?
Yeah, I think as well that this is the primary question here.
IIRC the fences were explicitly called exclusive
On Wed, Sep 21, 2016 at 12:30 PM, Christian König
wrote:
> Am 21.09.2016 um 11:56 schrieb Michel Dänzer:
>>
>>
>> Looks like there are different interpretations of the semantics of
>> exclusive vs. shared fences. Where are these semantics documented?
>
>
> Yeah, I think as well that this is the
On Wed, Sep 21, 2016 at 10:26:25AM +0300, Gustavo Padovan wrote:
> Hi Rafael,
>
> 2016-09-14 Rafael Antognolli :
>
> > Hi Chris and Gustavo,
> >
> > On Mon, Aug 29, 2016 at 07:16:13PM +0100, Chris Wilson wrote:
> > > If we being polled with a timeout of zero, a nonblocking busy query,
> > > we d
On Wed, Sep 21, 2016 at 10:20:19AM +0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> When merging sync_files there is a case when we can end up with only one
> fence in the merged sync_file: when all fences belong to the same
> timeline.
>
> So for this case a fence_array is not created
Am 21.09.2016 um 13:04 schrieb Daniel Vetter:
> On Wed, Sep 21, 2016 at 12:30 PM, Christian König
> wrote:
>> Am 21.09.2016 um 11:56 schrieb Michel Dänzer:
>>>
>>> Looks like there are different interpretations of the semantics of
>>> exclusive vs. shared fences. Where are these semantics docume
On 21.09.2016 09:34, David Herrmann wrote:
> Hi
>
> On Wed, Sep 21, 2016 at 6:47 AM, poma wrote:
>> Within X server, on top of DisplayLink GPU USB2.0 device,
>> screen content is not refreshed i.e. updated.
>>
>> This fixes commit:
>>
>> - e375882406d0cc24030746638592004755ed4ae0
>> "drm/udl: U
quot;.
Up to 4.5.0-1 everything was fine.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160921/ff2c0fcb/attachment.html>
Hi Daniel,
Thanks for the review.
On Wednesday 21 Sep 2016 09:23:14 Daniel Vetter wrote:
> On Sun, Sep 18, 2016 at 01:17:27PM +0300, Laurent Pinchart wrote:
> > Various pieces of information about DRM formats (number of planes, color
> > depth, chroma subsampling, ...) are scattered across differ
On Mon, Sep 19, 2016 at 05:56:49PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Mon, 19 Sep 2016 17:30:31 +0200
>
> The script "checkpatch.pl" can point information out like the following.
>
> WARNING: Prefer kcalloc over kzalloc with multiply
>
> Thus fix the affected source
e:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160921/7240cc8e/attachment.html>
Hi Daniel,
Thanks for the review.
On Wednesday 21 Sep 2016 09:34:13 Daniel Vetter wrote:
> On Thu, Sep 08, 2016 at 05:44:16PM +0300, Laurent Pinchart wrote:
> > Turn the drm_format_*() helpers into wrappers around the drm_format_info
> > lookup function to centralize all format information in a s
Hi
On Wed, Sep 21, 2016 at 1:19 PM, poma wrote:
> On 21.09.2016 09:34, David Herrmann wrote:
>> Hi
>>
>> On Wed, Sep 21, 2016 at 6:47 AM, poma wrote:
>>> Within X server, on top of DisplayLink GPU USB2.0 device,
>>> screen content is not refreshed i.e. updated.
>>>
>>> This fixes commit:
>>>
>>>
On Mon, Sep 19, 2016 at 03:40:48PM -0700, Dhinakaran Pandiyan wrote:
> Corrected typo in bridge and encoder comparison. Also, added a one-line
> encoder description from the previous documentation.
>
> Cc: Daniel Vetter
> Cc: Archit Taneja
>
> Signed-off-by: Dhinakaran Pandiyan
Thanks for spo
I've raised https://bugs.freedesktop.org/show_bug.cgi?id=97888 I'll
attach the info you requested once I get back to my machine
On 21 September 2016 at 07:56, Maarten Lankhorst
wrote:
> Hey,
>
> Op 20-09-16 om 20:45 schreef Mike Lothian:
>> Hi
>>
>> I've bisected back to this commit in the drm-in
On Wed, 21 Sep 2016, poma wrote:
> On 21.09.2016 09:34, David Herrmann wrote:
>> Hi
>>
>> On Wed, Sep 21, 2016 at 6:47 AM, poma wrote:
>>> Within X server, on top of DisplayLink GPU USB2.0 device,
>>> screen content is not refreshed i.e. updated.
>>>
>>> This fixes commit:
>>>
>>> - e375882406d0
From: Gustavo Padovan
If the fences in the fence_array signal on the fence_array does not have
signalling enabled num_pending will not be updated accordingly.
So when signaling is disabled check the signal of every fence with
fence_is_signaled() and then compare with num_pending to learn if the
On 20 September 2016 at 09:32, Peter Griffin
wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin
>> wrote:
>> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> > recursive dependency.
>
>
>> >
>> From a humble
Hi Daniel,
Thank you for the review.
On Wednesday 21 Sep 2016 09:51:44 Daniel Vetter wrote:
> On Thu, Sep 08, 2016 at 05:44:24PM +0300, Laurent Pinchart wrote:
> > The driver needs the number of bytes per pixel, not the bpp and depth
> > info meant for fbdev compatibility. Use the right API.
> >
On Wed, Sep 21, 2016 at 1:21 PM, Laurent Pinchart
wrote:
>> > +/**
>> > + * struct drm_format_info - information about a DRM format
>> > + * @format: 4CC format identifier (DRM_FORMAT_*)
>> > + * @depth: Color depth (number of bits per pixel excluding padding bits),
>> > + * valid for a subset of
On Wed, Sep 21, 2016 at 2:39 PM, Laurent Pinchart
wrote:
>> > @@ -82,7 +82,7 @@ int amdgpu_align_pitch(struct amdgpu_device *adev, int
>> > width, int bpp, bool tile
>> > aligned += pitch_mask;
>> > aligned &= ~pitch_mask;
>> >
>> > - return aligned;
>> > + return aligned * cpp;
>>
>>
On Wed, Sep 21, 2016 at 1:19 PM, Christian König
wrote:
> Am 21.09.2016 um 13:04 schrieb Daniel Vetter:
>>
>> On Wed, Sep 21, 2016 at 12:30 PM, Christian König
>> wrote:
>>>
>>> Am 21.09.2016 um 11:56 schrieb Michel Dänzer:
Looks like there are different interpretations of the s
https://bugzilla.kernel.org/show_bug.cgi?id=141741
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #15
> The original style was correct, the new style is wrong.
I find your feedback interesting for further clarifications.
> Multi-line indents get curly braces for readability.
How do you think about to transform such an information
into an official specification for the the document "CodingStyle"
On Wed, Sep 21, 2016 at 10:59:24AM +0200, Daniel Vetter wrote:
> Just pure code movement, cleanup and polish will happen in later
> patches.
>
> v2: Don't forget all the ioctl! To extract those cleanly I decided to
> put check_src_coords into drm_framebuffer.c (and give it a
> drm_framebuffer_ pre
Also reorder alphabetically and fix up drm_flip_work header.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 2087689..cb9
On Wed, Sep 21, 2016 at 6:28 AM, Sean Paul wrote:
> On Wed, Sep 21, 2016 at 10:59:24AM +0200, Daniel Vetter wrote:
>> Just pure code movement, cleanup and polish will happen in later
>> patches.
>>
>> v2: Don't forget all the ioctl! To extract those cleanly I decided to
>> put check_src_coords int
On Sun, Sep 18, 2016 at 01:17:27PM +0300, Laurent Pinchart wrote:
> Various pieces of information about DRM formats (number of planes, color
> depth, chroma subsampling, ...) are scattered across different helper
> functions in the DRM core. Callers of those functions often need to
> access more th
Hi Daniel,
On Wednesday 21 Sep 2016 14:46:07 Daniel Vetter wrote:
> On Wed, Sep 21, 2016 at 2:39 PM, Laurent Pinchart wrote:
> >> > @@ -82,7 +82,7 @@ int amdgpu_align_pitch(struct amdgpu_device *adev,
> >> > int width, int bpp, bool tile
> >> >
> >> > aligned += pitch_mask;
> >> > aligned
Hi Dave,
Here's an updated rockchip pull for -next
I've included some improvements to PSR from myself, as well as a great
series from Tomasz to clean up and tighten up vblank/flip handling.
The last patch is one from Tomeu that has been floating around for a
while, and since rockchip is one of t
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160921/a55a25fd/attachment.html>
On Fri, Aug 12, 2016 at 10:48:50PM +0200, Daniel Vetter wrote:
> Pulls in quite a lot of connector related structures (cmdline mode,
> force/status enums, display info), but I think that all makes perfect
> sense.
>
> Also had to move a few more core kms object stuff into drm_modeset.h.
>
> And a
On 21.09.2016 13:33, David Herrmann wrote:
> Hi
>
> On Wed, Sep 21, 2016 at 1:19 PM, poma wrote:
>> On 21.09.2016 09:34, David Herrmann wrote:
>>> Hi
>>>
>>> On Wed, Sep 21, 2016 at 6:47 AM, poma wrote:
Within X server, on top of DisplayLink GPU USB2.0 device,
screen content is not ref
ls are due to shader
compilation as well.
--
You are receiving this mail because:
You are on the CC list for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160921/5dd75905/attachment-0001.html>
There are many reasons other than ENOMEM that drm_dev_init() can
fail. Return ERR_PTR rather than NULL to be able to distinguish
these in the caller.
Signed-off-by: Tom Gundersen
---
drivers/gpu/drm/arc/arcpgu_drv.c| 4 ++--
drivers/gpu/drm/arm/hdlcd_drv.c | 4 ++-
If passing name == NULL to drm_drv_set_unique() we now get -ENOMEM
as kstrdup() returns NULL. Instead check for this explicitly and
return -EINVAL if no name is provided.
Signed-off-by: Tom Gundersen
---
drivers/gpu/drm/drm_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu
Am 21.09.2016 um 17:07 schrieb Michel Dänzer:
> On 21/09/16 09:56 PM, Daniel Vetter wrote:
>> On Wed, Sep 21, 2016 at 1:19 PM, Christian König
>> wrote:
>>> Am 21.09.2016 um 13:04 schrieb Daniel Vetter:
On Wed, Sep 21, 2016 at 12:30 PM, Christian König
wrote:
> Am 21.09.2016 um 1
Am 21.09.2016 um 17:13 schrieb Michel Dänzer:
> On 21/09/16 07:30 PM, Christian König wrote:
>> Am 21.09.2016 um 11:56 schrieb Michel Dänzer:
>>> FWIW, we seem to have the same issue with radeon vs. amdgpu: radeon only
>>> seems to wait for exclusive fences, so e.g. running Xorg on amdgpu and
>>
contains(B);}) &&
"Loop block has no in-loop successors!"' failed.
backtrace full attached
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/ar
Am 21.09.2016 um 17:29 schrieb Michel Dänzer:
> On 22/09/16 12:15 AM, Christian König wrote:
>> Am 21.09.2016 um 17:07 schrieb Michel Dänzer:
>>> On 21/09/16 09:56 PM, Daniel Vetter wrote:
On Wed, Sep 21, 2016 at 1:19 PM, Christian König
wrote:
> We use multiple writers without i
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160921/3440560a/attachment-0001.html>
From: Markus Elfring
Date: Wed, 21 Sep 2016 18:28:38 +0200
Several update suggestions were taken into account
from static source code analysis.
Markus Elfring (14):
Use kmalloc_array() in tiler_map_show()
Replace another kmalloc() call by kmalloc_array() in tiler_map_show()
Less function c
From: Markus Elfring
Date: Wed, 21 Sep 2016 12:23:46 +0200
A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle software.
From: Markus Elfring
Date: Wed, 21 Sep 2016 12:54:07 +0200
A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array" at another place.
Signed-off-by: Markus Elfring
---
driv
From: Markus Elfring
Date: Wed, 21 Sep 2016 13:16:20 +0200
The kfree() function was called in up to two cases
by the tiler_map_show() function during error handling even if
the passed variable contained a null pointer.
* Adjust jump targets according to the Linux coding style convention.
* Spli
From: Markus Elfring
Date: Wed, 21 Sep 2016 13:53:11 +0200
Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
Signed-off-by: Mar
From: Markus Elfring
Date: Wed, 21 Sep 2016 17:21:57 +0200
Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
Signed-off-by: Mar
From: Markus Elfring
Date: Wed, 21 Sep 2016 17:30:25 +0200
Adjust jump labels according to the current Linux coding style convention.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
di
1 - 100 of 144 matches
Mail list logo
