tream instead of the fist
one?)...
--
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/20150423/998cd162/attachment.html>
vel/attachments/20150423/ee90b1a7/attachment.html>
Hello Emil,
On 2015-04-21 20:14, Emil Velikov wrote:
> Hi Tobias,
>
> On 30/03/15 13:04, Tobias Jakobi wrote:
>> Hello,
>>
>> On 2015-03-30 02:02, Rob Clark wrote:
>>> so, iirc, vmwgfx also has some custom events.. not really sure if
>>> they have their own hand-rolled drmHandleEvent() or if th
Hello,
I've modified the two patches in [1] so that they now apply to Inki's
exynos-drm-next branch. The pixelformat one was rewritten, so that it doesn't
rely on Gustavo's blending patch (which seems to need
more discussion). The field cleanup patch was extended as Joonyoung suggested.
Since
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
Remove the unused fields of struct exynos_drm_plane.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index e12ecb5..c80331b 1
On 21/04/15 16:41, Alex Deucher wrote:
> On Tue, Apr 21, 2015 at 11:56 AM, Emil Velikov
> wrote:
>> Hi Alex,
>>
>> On 20 April 2015 at 23:33, Alex Deucher wrote:
>>> I'm pleased to announce the initial release of the new amdgpu driver.
>>> This is a partial replacement for the radeon driver for
Hi,
This is the fourth version of the HDMI CEC framework. I would like to thank
for all the comments and suggestions to the previous versions of this patch.
I believe that the code has matured enough to be tagged as PATCH and not RFC
as in previous version.
This patchset is base on the linux-next
Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and
Exynos4x12 SoCs. These are required by the HDMI CEC device.
Signed-off-by: Kamil Debski
---
arch/arm/boot/dts/exynos4210-pinctrl.dtsi |7 +++
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |7 +++
2 files changed, 14 inse
This patch adds HDMI CEC node specific to the Exynos4210/4x12 SoC series.
Signed-off-by: Kamil Debski
---
arch/arm/boot/dts/exynos4.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e20cdc2..8776db9 1006
Add a dts node entry and enable the HDMI CEC device present in the Exynos4
family of SoCs.
Signed-off-by: Kamil Debski
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/d
Add handling of remote control events coming from the HDMI CEC bus.
This patch includes a new keymap that maps values found in the CEC
messages to the keys pressed and released. Also, a new protocol has
been added to the core.
Signed-off-by: Kamil Debski
---
drivers/media/rc/keymaps/Makefile |
Add HDMI CEC specific keycodes to the keycodes definition.
Signed-off-by: Kamil Debski
---
include/uapi/linux/input.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index 731417c..7430a3f 100644
--- a/include/uapi/linux
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 Update author commit by Hans Verkuil]
[k.debski at samsung.
From: Hans Verkuil
Add callbacks to the v4l2_subdev_video_ops.
Signed-off-by: Hans Verkuil
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans
Verkuil]
Signed-off-by: Kamil Debski
---
include/media/v4l2-subdev.h |8
1 file changed, 8 insertions(+)
diff --gi
From: Hans Verkuil
Add CEC support to the adv7604 driver.
Signed-off-by: Hans Verkuil
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans
Verkuil]
[k.debski at samsung.com: add missing methods cec/io_write_and_or]
[k.debski at samsung.com: change adv7604 to adv76xx in adde
From: Hans Verkuil
Add CEC support to the adv7511 driver.
Signed-off-by: Hans Verkuil
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans
Verkuil]
Signed-off-by: Kamil Debski
---
drivers/media/i2c/adv7511.c | 347 ++-
include/medi
Basically this is an extended version of drmHandleEvent().
drmHandleEvent() only handles core events (like e.g. page flips),
but since kernel DRM drivers might use vendor-specific events
to signal userspace the completion of pending jobs, etc., its
desirable to provide a way to handle these withou
Hello Ilia,
On 2015-04-21 21:15, Ilia Mirkin wrote:
> I know it was immensely useful to me when I was adding YUV plane
> support to nouveau. Seemed to work as advertised at the time (1.5y
> ago) for YUYV, UYVY, and NV12.
>
> -ilia
maybe you can help me with that question.
Let's consider a user
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150423/b958a4be/attachment.html>
/lists.freedesktop.org/archives/dri-devel/attachments/20150423/e3594312/attachment.html>
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150423/a201466c/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 Thu, Apr 23, 2015 at 03:07:54PM +0100, Peter Antoine wrote:
> This patch fixes a possible kernel crash when drm_unlock (DRM_IOCTL_UNLOCK)
> is called by a application that has not had a lock created by it. This
> crash can be caused by any application from all users.
Crashing the application is
On Thu, Apr 23, 2015 at 03:07:55PM +0100, Peter Antoine wrote:
> This patch fixes an unsafe deference in the DRM_IOCTL_NEW_CTX. If the
> ioctl is called before the lock is created or after it has been destroyed.
> The code will deference a NULL pointer. This ioctl is a root ioctl so
> exploitation
Hello,
this series exposes async execution of G2D command buffers to userspace. Also
includes is a small performance analysis test, which can also be used to stress
test the engine. The async operation is of
course also tested.
Please review and let me know what I can improve.
v3: Rewrote han
Used to handle kernel events specific to the Exynos platform.
Currently only G2D events are handled.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_drm.c | 28
exynos/exynos_drm.h | 12
exynos/exynos_drmif.h | 26 ++
3 files c
Currently only fast solid color clear performance is measured.
A large buffer is allocated and solid color clear operations
are executed on it with randomly chosen properties (position
and size of the region, clear color). Execution time is
measured and output together with the amount of pixels
pro
On Thu, Apr 23, 2015 at 9:39 AM, Tobias Jakobi
wrote:
> Hello Ilia,
>
> On 2015-04-21 21:15, Ilia Mirkin wrote:
>>
>> I know it was immensely useful to me when I was adding YUV plane
>> support to nouveau. Seemed to work as advertised at the time (1.5y
>> ago) for YUYV, UYVY, and NV12.
>>
>> -il
Hello,
since it might not be entirely clear how to use this, here's how the
Exynos libdrm would use it:
https://patchwork.kernel.org/patch/6263151/
With best wishes,
Tobias
On 2015-04-23 15:32, Tobias Jakobi wrote:
> Basically this is an extended version of drmHandleEvent().
>
> drmHandleEve
This enables us to pass command buffers to the kernel which
trigger an event on the DRM fd upon completion.
The final goal is to enable asynchronous operation of the
G2D engine, similar to async page flips.
Passing the event userdata pointer through the G2D context
was chosen to not change the cur
On Thu, Apr 23, 2015 at 02:34:24PM +, Antoine, Peter wrote:
> Before the patch the system required rebooting (driver crash and/or kernel
> panic).
> Now the application gets terminated.
It should have an GPF which should not have required a reboot, but
terminated the application. Unless you s
This is a more 'flexible' version of g2d_exec allowing to pass
some flags which modify the behaviour of g2d_exec. Currently
only the 'async' operation flag is supported.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 15 +--
exynos/exynos_fimg2d.h | 6 ++
2 files chan
This tests async processing of G2D jobs. A separate thread is spawned
to monitor the DRM fd for events and check whether a G2D job was
completed.
v2: Add GPLv2 header, argument handling and documentation.
Test is only installed when requested.
Signed-off-by: Tobias Jakobi
---
tests/exynos/M
Hello Ilia!
On 2015-04-23 16:32, Ilia Mirkin wrote:
> On Thu, Apr 23, 2015 at 9:39 AM, Tobias Jakobi
> wrote:
>> Hello Ilia,
>>
>> On 2015-04-21 21:15, Ilia Mirkin wrote:
>>>
>>> I know it was immensely useful to me when I was adding YUV plane
>>> support to nouveau. Seemed to work as advertis
Even if flushing the command buffer doesn't succeed, the
G2D calls would still return zero. Fix this by just passing
the flush return code.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/exynos/exy
The 'usage' function already does exit(0), so that this
'return -EINVAL' is never called. Just put a break there
to avoid confusion.
Signed-off-by: Tobias Jakobi
---
tests/exynos/exynos_fimg2d_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/exynos/exynos_fimg2d_t
Hi Alex,
On 21/04/15 16:39, Alex Deucher wrote:
> This is the new ioctl wrapper used by the new admgpu driver.
> It's primarily used by xf86-video-amdgpu and mesa.
>
Glad to see amdgpu finally out :-)
Can we annotate the private symbols with drm_private, in both
declaration and definition ? It wi
Hi Ilia,
On 21/04/15 19:15, Ilia Mirkin wrote:
> On Tue, Apr 21, 2015 at 4:10 PM, Emil Velikov
> wrote:
>> Hi Tobias,
>>
>> On 20/04/15 19:50, Tobias Jakobi wrote:
>>> Only the 'offsets' array was initialized to zero.
>>> Since bo_create only sets the handles which are
>>> necessary, were we pas
On 22/04/15 02:05, Joonyoung Shim wrote:
> Hi Emil,
>
> On 04/22/2015 05:16 AM, Emil Velikov wrote:
>> Hi Joonyoung,
>>
>> On 13/04/15 08:31, Joonyoung Shim wrote:
>>> Hi all,
>>>
>>> This patchset is to fix properly about buffer and framebuffer resources
>>> when terminates modetest of libdrm.
>>
From: Christian König
v2: cleanup comments and function parameter
Signed-off-by: Christian König
Reviewed-by: Jammy Zhou
Reviewed-by: Alex Deucher
---
amdgpu/amdgpu.h| 51 --
amdgpu/amdgpu_bo.c | 56 +
amdgpu/a
From: Christian König
Remove the mostly unused device parameter, for the few cases
where we really need it keep a copy in the context structure.
Signed-off-by: Christian König
Reviewed-by: Jammy Zhou
Reviewed-by: Alex Deucher
---
amdgpu/amdgpu.h| 24 +++---
amdgpu/amdgpu_c
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 bionic versions? I know the bionic team made
>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150423/229a9bab/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150423/7b6c8bbd/attachment.html>
On Wed, Apr 22, 2015 at 10:50:55AM +0800, John Hunter wrote:
> Sure, but I need Daniel to admit that, because maybe include the two header
> file make it easier to understand.
> And after checked other files in drm/i915, I found that a lot other file do
> the
> same thing(include both header file).
hment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150423/a2031ff1/attachment.html>
On Tue, Apr 21, 2015 at 10:12:19AM -0700, Linus Torvalds wrote:
> On Tue, Apr 21, 2015 at 9:49 AM, Dmitry Torokhov
> wrote:
> > The hardware, according to the specs, is limited to 256 byte transfers,
> > and current driver has no protections in case users attempt to do larger
> > transfers. The co
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150423/bb18d33b/attachment-0001.html>
hment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150423/4ac389af/attachment.html>
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/20150423/435e30bf/attachment.html>
drm_mode_connector_attach_encoder() function call is missing
during eDP and DSI connector initialization. As a result,
no encoder is returned by DRM_IOCTL_MODE_GETCONNECTOR system
call. This change is to fix this issue.
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/dsi/dsi.c | 10 +
On Thu, 23 Apr 2015, Daniel Vetter wrote:
> On Tue, Apr 21, 2015 at 10:12:19AM -0700, Linus Torvalds wrote:
>> On Tue, Apr 21, 2015 at 9:49 AM, Dmitry Torokhov
>> wrote:
>> > The hardware, according to the specs, is limited to 256 byte transfers,
>> > and current driver has no protections in case
[+cc Matthew]
On Tue, Apr 21, 2015 at 09:07:45AM -0700, Linus Torvalds wrote:
> Hmm. The odd Intel PCI resource mess is back.
>
> Or maybe it never went away.
>
> I get these when suspending. Things *work*, but it's really spamming
> my logs a fair bit:
>
> i915 :00:02.0: BAR 6: [??? 0x00
It is never called. BAPM on KV is only controlled
through the power profile.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/radeon/kv_dpm.c | 12
drivers/gpu/drm/radeon/radeon_asic.c | 1 -
drivers/gpu/drm/radeon/radeon_asic.h | 1 -
3 files changed, 14 deletions(-)
diff --g
Trying to disable BAPM on battery power does not fix the problematic
Trinity mobile parts. Fixing those probably need a more complex solution,
like doing a complete reinit of the DPM state. This will take more work
and most likely it will not be possible to map this to a single callback.
Even wors
> -Original Message-
> From: Lucas Stach [mailto:dev at lynxeye.de]
> Sent: Thursday, April 23, 2015 5:28 PM
> To: Deucher, Alexander; Koenig, Christian; David Airlie
> Cc: dri-devel at lists.freedesktop.org
> Subject: [PATCH 2/2] drm/radeon: remove bapm callbacks
>
> Trying to disable BAP
On Thu, Apr 23, 2015 at 2:56 PM, Matthew Garrett
wrote:
> On Thu, Apr 23, 2015 at 2:30 PM, Bjorn Helgaas wrote:
>>
>> int pcibios_add_device(struct pci_dev *dev)
>> {
>> if (dev-is-default-vga-device) {
>> dev->rom = 0xC;
>> dev->romlen = 0x2;
>> }
>
> I don't know
On Thu, Apr 23, 2015 at 5:30 PM, Bjorn Helgaas wrote:
> [+cc Matthew]
>
> On Tue, Apr 21, 2015 at 09:07:45AM -0700, Linus Torvalds wrote:
>> Hmm. The odd Intel PCI resource mess is back.
>>
>> Or maybe it never went away.
>>
>> I get these when suspending. Things *work*, but it's really spamming
>
This patch fixes an unsafe deference in the DRM_IOCTL_NEW_CTX. If the
ioctl is called before the lock is created or after it has been destroyed.
The code will deference a NULL pointer. This ioctl is a root ioctl so
exploitation is limited.
Issue: VIZ-5485
Signed-off-by: Peter Antoine
---
drivers
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, it will pass the context == DRM_KERNEL_CONTEXT checks.
But as the DRM_L
As these functions are only used by one driver and there are security holes
in these functions. Make the functions optional.
These changes are based on the two patches:
commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
Author: Dave Airlie
And the commit that the above patch reverts:
commit 7
On Thu, Apr 23, 2015 at 2:30 PM, Bjorn Helgaas wrote:
> Your i915 does not have a ROM BAR in hardware. If the default video
> device has no ROM BAR, pci_fixup_video() sets IORESOURCE_ROM_SHADOW
> even though the resource flags are zero because the BAR itself doesn't
> exist.
>
> If IORESOURCE_RO
On Thu, Apr 23, 2015 at 3:47 PM, Linus Torvalds
wrote:
> I'm not sure why we want that IORESOURCE_ROM_SHADOW thing at all, but
> yes, if what this is all about is the magic video ROM at 0xc, then
It's used in the PCI layer to say "Read from 0xc rather than the
ROM BAR" and then ends up a
kmalloc() returns a void pointer - no need to cast it in
drivers/gpu/drm/amd/amdkfd/kfd_process.c::kfd_process_destroy_delayed()
Signed-off-by: Firo Yang
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/
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, the
following patches should be applied to stop the crash
The following series of patches fix a number of security holes in the i915
driver (actually in drm but...). The first three patches remove the actual
security issues that have been found. The last two patches make the functions
optional for all drivers. The only driver that has this feature turned
This patch fixes a possible kernel crash when drm_unlock (DRM_IOCTL_UNLOCK)
is called by a application that has not had a lock created by it. This
crash can be caused by any application from all users.
Issue: VIZ-5485
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/drm_lock.c | 8
1 fi
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 ++
drivers/gpu/drm/i915/i915_dma.c | 3 +++
drivers/gpu/drm/nouveau
Before the patch the system required rebooting (driver crash and/or kernel
panic).
Now the application gets terminated.
This follows the pattern in the other parts of this code that checks that
pointer.
Peter.
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sen
70 matches
Mail list logo
