Hi Linus,
playing the race -rc1 game, nothing too urgent if this doesn't get in
though, Jani sent it after I started my weekend so I felt I should send
it on.
Just intel fixes 3 of them.
Dave.
The following changes since commit c8b3fd0ce313443731e8fd6d5a541085eb465f99:
Merge tag 'pm+acpi-
xf86drm.c:356:2: warning: comparison of unsigned expression >= 0 is always true
[-Wtype-limits]
group = (serv_group >= 0) ? serv_group : DRM_DEV_GID;
^
v2: do 'int' cast to fix the warning
Signed-off-by: Jammy Zhou
---
xf86drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
Thanks for sharing the background. For [0], you mentioned that get_perms may
return -1 in some cases for the group, can you help indicate which case it is?
Since the drmSetServerInfo is seldom used, maybe we can just do the 'int' cast
at this moment. I will send v2 for this.
Regards,
Jammy
---
Hi Tobias,
On 04/24/2015 05:10 PM, Tobias Jakobi wrote:
> On 2015-04-24 03:48, Joonyoung Shim wrote:
>> Hi Tobias,
>>
>> On 04/23/2015 09:12 PM, Tobias Jakobi wrote:
>>> Move the defines for the pixelformats that the mixer supports out
>>> of mixer_graph_buffer() to the top of the source.
>>> Then
Hi Gustavo,
On 04/25/2015 03:15 AM, Gustavo Padovan wrote:
> Hi Joonyoung,
>
> 2015-04-16 Joonyoung Shim :
>
>> The exynos_update_plane function needs 16.16 fixed point source data.
>>
>> Signed-off-by: Joonyoung Shim
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 7 ---
>> 1 file ch
Hi Tobias,
On 04/26/2015 03:06 AM, Tobias Jakobi wrote:
> Remove the unused fields of struct exynos_drm_plane.
>
> v2: Remove index_color as well, also unused (thanks Joonyoung).
>
> Reviewed-by: Gustavo Padovan
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.h |
2015-04-24 0:56 GMT+08:00 Emil Velikov :
> On 22/04/15 16:19, Greg Hackmann wrote:
>> On Tue, Apr 21, 2015 at 11:31 AM, Emil Velikov
>> wrote:
>>>
>>> I'm not sure why I haven't hit this while building with Android-x86's
>>> bionic, although it's the right thing to do.
>>
>> Maybe a difference in
Hi Tobias,
On 04/26/2015 05:31 AM, Tobias Jakobi wrote:
> The video processor (VP) supports four formats: NV12, NV21 and its
> tiled variants. All these formats are bi-planar, so the buffer
> count in vp_video_buffer() is always 2.
>
> While we're at it, also add support for NV21 and properly exi
Added the y2038 mailinglist since I would like to get their input for
this API.
Y2038 experts, can you take a look at my comments in the code below?
Thanks!
On 04/23/2015 03:03 PM, Kamil Debski wrote:
> From: Hans Verkuil
>
> The added HDMI CEC framework provides a generic kernel interface for
On Sat, 25 Apr 2015, Fabian Frederick wrote:
> Inspired by scripts/coccinelle/api/err_cast.cocci
>
> Signed-off-by: Fabian Frederick
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915
Hi Lars,
Thank you for your comments.
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
owner at vger.kernel.org] On Behalf Of Lars Op den Kamp
Sent: Friday, April 24, 2015 12:04 PM
> Hi Kamil, Hans,
>
> I'm the main developer of libCEC
> (https://github.com/Pulse-Eight/libcec). Sor
Hi Lars,
My thanks as well for your comments.
I'd like to add some background information as well as to why we move
the core CEC support into the kernel: the main reason for doing this
is to support the HEAC part of the CEC protocol. Specifically the ARC
support and handling the hotplug detect CE
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150427/9e86b937/attachment.html>
On Sun, 26 Apr 2015, green at linuxhacker.ru wrote:
> From: Oleg Drokin
>
> Need to free just allocated ctx allocation if we cannot
> get our config mutex.
>
> This one has been flagged by kbuild bot all the way back in August,
> but somehow nobody picked it up:
> https://lists.01.org/pipermail/kb
Hi Kamil,
I've added some missing HDMI 2.0 commands:
On 04/23/2015 03:03 PM, Kamil Debski wrote:
> From: Hans Verkuil
>
> The added HDMI CEC framework provides a generic kernel interface for
> HDMI CEC devices.
>
> Signed-off-by: Hans Verkuil
> [k.debski at samsung.com: Merged CEC Updates com
Hi Kamil,
Sorry for all the replies, but I'm writing the DocBook documentation, so
whenever I find something missing I'll just reply to this patch.
> +/* The CEC version */
Add support for version 1.3a here:
#define CEC_VERSION_1_3A4
> +#define CEC_VERSION_1_4B 5
> +
On 04/27/2015 11:22 AM, Hans Verkuil wrote:
> Hi Kamil,
>
> Sorry for all the replies, but I'm writing the DocBook documentation, so
> whenever I find something missing I'll just reply to this patch.
>> +/* The CEC version */
>
> Add support for version 1.3a here:
>
> #define CEC_VERSION_1_3A
Hello, Syrjälä,
For drmModeSetPlane API, regarding the ctrc width, height and src width and
heitht,
Do they must 16 byte aligned?
For example, for the size of 33x66, will these value be supported?
William
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
uot;/usr/lib/xorg/modules/dri/radeonsi_dri.so" is not a core dump: File format not
recognized
Any idea what I did wrong? (I'll attach the PKGBUILD and my makepkg.conf)
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150427/bb606d64/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150427/e6ac2526/attachment.html>
e you tried getting a
backtrace of the crash again?
--
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/20150427/776f4ff6/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150427/0f225526/attachment-0001.html>
||
--
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/20150427/d0167b6e/attachment.html>
On Mon, Apr 27, 2015 at 11:51 AM, Geert Uytterhoeven
wrote:
> Below is the list of build error/warning regressions/improvements in
> v4.1-rc1[1] compared to v4.0[2].
>
> Summarized:
> - build errors: +34/-11
> - build warnings: +135/-163
>
> As I haven't mastered kup yet, there's no verbose su
On 04/23/2015 03:03 PM, Kamil Debski wrote:
> From: Hans Verkuil
>
> The added HDMI CEC framework provides a generic kernel interface for
> HDMI CEC devices.
>
> Signed-off-by: Hans Verkuil
> [k.debski at samsung.com: Merged CEC Updates commit by Hans Verkuil]
> [k.debski at samsung.com: Merged
/archives/dri-devel/attachments/20150427/e32f1f41/attachment.html>
On 04/23/2015 03:03 PM, Kamil Debski wrote:
> From: Hans Verkuil
>
> The added HDMI CEC framework provides a generic kernel interface for
> HDMI CEC devices.
>
> Signed-off-by: Hans Verkuil
> [k.debski at samsung.com: Merged CEC Updates commit by Hans Verkuil]
> [k.debski at samsung.com: Merged
On 04/27/2015 12:25 PM, Hans Verkuil wrote:
> On 04/23/2015 03:03 PM, Kamil Debski wrote:
>> From: Hans Verkuil
>>
>> The added HDMI CEC framework provides a generic kernel interface for
>> HDMI CEC devices.
>>
>> Signed-off-by: Hans Verkuil
>> [k.debski at samsung.com: Merged CEC Updates commit
https://bugzilla.kernel.org/show_bug.cgi?id=95911
--- Comment #7 from gitne at excite.co.jp ---
(In reply to Michel Dänzer from comment #6)
> Is this a regression compared to older kernel versions? If yes, can you
> bisect or at least narrow down which kernel version is the last good / first
> ba
On 04/27/2015 11:22 AM, Hans Verkuil wrote:
> Hi Kamil,
>
> Sorry for all the replies, but I'm writing the DocBook documentation, so
> whenever I find something missing I'll just reply to this patch.
>> +/* The CEC version */
>
> Add support for version 1.3a here:
>
> #define CEC_VERSION_1_3A
On 2015-04-27 08:33, Joonyoung Shim wrote:
> Hi Tobias,
>
> On 04/24/2015 05:10 PM, Tobias Jakobi wrote:
>> On 2015-04-24 03:48, Joonyoung Shim wrote:
>>> Hi Tobias,
>>>
>>> On 04/23/2015 09:12 PM, Tobias Jakobi wrote:
Move the defines for the pixelformats that the mixer supports out
of
On 2015-04-27 09:24, Joonyoung Shim wrote:
> Hi Tobias,
>
> On 04/26/2015 05:31 AM, Tobias Jakobi wrote:
>> The video processor (VP) supports four formats: NV12, NV21 and its
>> tiled variants. All these formats are bi-planar, so the buffer
>> count in vp_video_buffer() is always 2.
>>
>> While w
Hi Hans,
Thank you so much for all today's comments. I will consider them when
preparing the next version.
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
owner at vger.kernel.org] On Behalf Of Hans Verkuil
Sent: Monday, April 27, 2015 1:27 PM
>
> On 04/27/2015 12:25 PM, Hans Verkui
(Kamil, here is the DocBook documentation for the CEC API. Please add this to
your
patch series when you post the next version of that.)
---
Add the documentation for the public CEC API.
Signed-off-by: Hans Verkuil
---
Documentation/DocBook/media/Makefile | 4 +-
Documentation/
On Sat, 18 Apr 2015, Marc Ludwig wrote:
> Hi, Folks!
>
> I'am looking for an opportunity to access the I2C-Interface which is attached
> to my displayport link.
> Can anyone give me a hint aubout an minimal working example for this?
>
> I tried to figure aut how this could be solved using the
On Mon, Apr 27, 2015 at 09:37:54AM +, Xie, William wrote:
> Hello, Syrjälä,
> For drmModeSetPlane API, regarding the ctrc width, height and src width and
> heitht,
> Do they must 16 byte aligned?
> For example, for the size of 33x66, will these value be supported?
Depends on the hardware/d
ed by drmPrimeHandleToFD (xf86drm.c:2695)
--
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/20150427/d1950dc7/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150427/6d449b94/attachment.html>
From: Christian König
Otherwise it is possible that we will have page table corruption
if we change a BOs address multiple times.
Signed-off-by: Christian König
CC: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_vm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/
From: Christian König
Otherwise we print false warning from time to time.
Signed-off-by: Christian König
Signed-off-by: Jack Xiao
CC: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_mn.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/d
From: Christian König
If we unmap BOs before releasing them them the intervall tree locks
up because we try to remove an entry not inside the tree.
Signed-off-by: Christian König
CC: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_vm.c | 3 ++-
1 file changed, 2 insertions(+), 1
From: Christian König
Otherwise the change isn't atomic.
Signed-off-by: Christian König
CC: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_vm.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_vm.
On 27.04.2015 17:04, Christian König wrote:
> From: Christian König
>
> If we unmap BOs before releasing them them the intervall tree locks
> up because we try to remove an entry not inside the tree.
>
> Signed-off-by: Christian König
> CC: stable at vger.kernel.org
Somehow forgot to mention
On 23 April 2015 at 15:07, Peter Antoine wrote:
> There are several issues with the hardware locks functions that stretch
> from kernel crashes to priority escalations. This new test will test the
> the fixes for these features.
>
> This test will cause a driver/kernel crash on un-patched kernels,
On Mon, Apr 27, 2015 at 04:24:37PM +0100, Thomas Wood wrote:
> On 23 April 2015 at 15:07, Peter Antoine wrote:
> > There are several issues with the hardware locks functions that stretch
> > from kernel crashes to priority escalations. This new test will test the
> > the fixes for these features.
On Mon, Apr 27, 2015 at 11:04 AM, Christian König
wrote:
> From: Christian König
>
> Otherwise we print false warning from time to time.
>
> Signed-off-by: Christian König
> Signed-off-by: Jack Xiao
> CC: stable at vger.kernel.org
Applied the series to my 4.1 fixes tree. I had to make mino
On Thu, Apr 23, 2015 at 03:07:56PM +0100, Peter Antoine wrote:
> If an application that has a driver lock created, wants the lock the
> kernel context, it is not allowed to. If the call to drm_lock has a
> context of 0, it is rejected. If you set the context to _DRM_LOCK_CONT
> then call drm lock,
On Thu, Apr 23, 2015 at 03:07:57PM +0100, Peter Antoine wrote:
> As these functions are only used by one driver and there are security holes
> in these functions. Make the functions optional.
>
> Issue: VIZ-5485
> Signed-off-by: Peter Antoine
> ---
> drivers/gpu/drm/drm_lock.c| 6 ++
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150427/55084749/attachment.html>
Hi Jammy, Frank
As far as I can see you're trying to get a different version of
drmGetBusid(). With the DRM_IOCTL_{G,S}ET_UNIQUE ioctl being lovely as
it is I do see your point, but I'm not sure that the current design will
be too useful.
Do we have any upcoming users for this new function, can y
On Mon, 27 Apr 2015 14:33:45 +0300
Jyri Sarha wrote:
> Have you done anything about the tda998x audio support lately?
>
> I was thinking of taking a shot at this now that I finally seem to have
> some time for it. However, if you are just about to send another series
> I'll wait for that first
.conf instead. Anyway I hope I got something useful with the
last 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/
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150427/35d55383/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150427/24215f08/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150427/744dada6/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150427/c9cd6d25/attachment-0001.html>
The previous code had some special case handling for the buffer
count in exynos_drm_format_num_buffers().
This code was incorrect though, since this special case doesn't
exist for DRM. It stemmed from the existence of the special NV12M
V4L2 format. NV12 is a bi-planar format (separate planes for l
Previously we were ignoring the buffer offsets that are
passed through the addfb2 ioctl. This didn't cause any
major issues, since for uni-planar formats (like XRGB)
userspace would most of the time just use offsets[0]=0.
However with NV12 offsets[1] is very likely non-zero.
So properly apply
The video processor (VP) supports four formats: NV12, NV21 and its
tiled variants. All these formats are bi-planar, so the buffer
count in vp_video_buffer() is always 2.
Also properly exit if we're called with an invalid (non-VP) pixelformat.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exy
All the necessary code is already there, just need to
handle the format in the switch statement.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mi
Move the defines for the pixelformats that the mixer supports out
of mixer_graph_buffer() to the top of the source.
Then select the mixer pixelformat (pf) in mixer_graph_buffer() based on
the plane's pf (and not bpp).
Also add handling of RGB565 and XRGB1555 to the switch statement and
exit early i
Hello there,
[linux-4.1-rc1/drivers/gpu/drm/msm/dsi/dsi_host.c:1799] ->
[linux-4.1-rc1/drivers/gpu/drm/msm/dsi/dsi_host.c:1802]: (warning) Variable
'ret' is reassigned a value before the old one has been used. 'break;' missing?
   switch (cmd) {
   case MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR
Hi,
Have you done anything about the tda998x audio support lately?
I was thinking of taking a shot at this now that I finally seem to have
some time for it. However, if you are just about to send another series
I'll wait for that first and see what makes the most sense after that.
My plan is to
Hello!
On Apr 27, 2015, at 4:56 AM, Jani Nikula wrote:
> On Sun, 26 Apr 2015, green at linuxhacker.ru wrote:
>> From: Oleg Drokin
>>
>> Need to free just allocated ctx allocation if we cannot
>> get our config mutex.
>>
>> This one has been flagged by kbuild bot all the way back in August,
>>
From: Oleg Drokin
Need to free just allocated ctx allocation if we cannot
get our config mutex.
This one has been flagged by kbuild bot all the way back in August,
but somehow nobody picked it up:
https://lists.01.org/pipermail/kbuild/2014-August/001691.html
In addition there is another failure
Hi,
On Mon, Apr 27, 2015 at 12:03:32PM +0200, Geert Uytterhoeven wrote:
> > *** ERRORS ***
> >
> > 34 regressions:
>
> The quiet days are over...
>
> > + /home/kisskb/slave/src/arch/mips/cavium-octeon/smp.c: error: passing
> > argument 2 of 'cpumask_clear_cpu' discards 'volatile' qualifier fr
67 matches
Mail list logo
