On Fri, Nov 18, 2016 at 09:52:36PM +0200, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Second installment of my effort to remove the duplicated
> depth/bpp/pixel_format from drm_framebuffer and just use
> struct drm_format_info instead.
>
> I tried to address all of the r
We're going to use R8A7791 VSPDs to control DU, so set the corresponding
flag.
Signed-off-by: Sergei Shtylyov
---
The patch is against David Airlie's 'linux.git' repo's 'drm-next' branch.
drivers/gpu/drm/rcar-du/rcar_du_drv.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: l
Hi Sebastian,
(CC'ing Peter Ujfalusi)
On Wednesday 14 Dec 2016 15:03:08 Sebastian Reichel wrote:
> On Wed, Dec 14, 2016 at 11:14:32AM +0200, Tomi Valkeinen wrote:
> > On 14/12/16 11:10, Laurent Pinchart wrote:
> >> On Wednesday 14 Dec 2016 10:43:18 Tomi Valkeinen wrote:
> >>> On 13/12/16 19:35, L
Hi Peter,
On Thursday 01 Sep 2016 14:22:54 Peter Ujfalusi wrote:
> Hi,
>
> The following series will convert the omapdrm stack to use the generic
> videmode instead of the private omap_video_timings struct for the panel
> information.
>
> Since we have several panels under omapdrm/displays/ wher
From: Ville Syrjälä
Replace uses of fb->pixel_format with fb->format->format.
Less duplicated information is a good thing.
Note that coccinelle failed to eliminate the
"/* fourcc format */" comment from drm_framebuffer.h, so I had
to do that part manually.
@@
struct drm_framebuffer *FB;
expre
From: Ville Syrjälä
Replace uses of fb->bits_per_pixel with fb->format->cpp[0]*8.
Less duplicated information is a good thing.
Note that I didn't put parens around the cpp*8 in the below cocci script,
on account of not wanting spurious parens all over the place. Instead I
did the unsafe way, a
From: Ville Syrjälä
Replace uses of fb->depth with fb->format->depth. Less duplicate
information is a good thing.
@@
struct drm_framebuffer *fb;
expression E;
@@
drm_helper_mode_fill_fb_struct(...) {
...
- fb->depth = E;
...
}
@@
struct nouveau_framebuffer *fb;
@@
- fb
From: Ville Syrjälä
Replace drm_format_plane_cpp(fb->pixel_format) with just
fb->format->cpp[]. Avoids the expensive format info lookup.
@@
struct drm_framebuffer *a;
struct drm_framebuffer b;
expression E;
@@
(
- drm_format_plane_cpp(a->pixel_format, E)
+ a->format->cpp[E]
|
- drm_format_plan
From: Ville Syrjälä
Replace drm_format_num_planes(fb->pixel_format) with just
fb->format->num_planes. Avoids the expensive format info lookup.
@@
struct drm_framebuffer *a;
struct drm_framebuffer b;
@@
(
- drm_format_num_planes(a->pixel_format)
+ a->format->num_planes
|
- drm_format_num_planes
Forgot to add the most relevant list for this issue (linux-next).
Stephen, maybe you will want to temporarily revert this patch until this
is cleared? This probably affects other users than DRM.
On 12/13/2016 04:14 PM, Alexandre Courbot wrote:
> Hi Matthew,
>
> Trying the latest -next on the Jet
Hi Sergei,
Thank you for the patch.
On Wednesday 14 Dec 2016 23:37:08 Sergei Shtylyov wrote:
> We're going to use R8A7791 VSPDs to control DU, so set the corresponding
> flag.
>
> Signed-off-by: Sergei Shtylyov
For the same reason I nacked the corresponding patch to the VSP1 driver, I
have to
From: Ville Syrjälä
Pass the drm_device to drm_helper_mode_fill_fb_struct() so that we can
populate fb->dev early. Will make it easier to use the fb before we
register it.
@@
identifier fb, mode_cmd;
@@
void drm_helper_mode_fill_fb_struct(
+struct drm_devic
On 12/14/2016 09:51 PM, Stefan Agner wrote:
> On 2016-12-13 23:52, Marek Vasut wrote:
>> On 12/14/2016 02:02 AM, Stefan Agner wrote:
>>> The LCD bus width does not need to align with the pixel format. The
>>> LCDIF controller automatically converts between pixel formats and
>>> bus width by padding
On 12/14/2016 09:48 PM, Stefan Agner wrote:
> The DRM subsystem specifies the pixel clock polarity from a
> controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means
> the controller drives the data on pixel clocks falling edge.
> That is the controllers DOTCLK_POL=0 (Default is data launched
> a
On 12/14/2016 09:29 PM, Stefan Agner wrote:
> On 2016-12-14 00:04, Marek Vasut wrote:
>> On 12/14/2016 01:01 AM, Stefan Agner wrote:
>>> On 2016-12-08 15:38, Marek Vasut wrote:
On 12/08/2016 09:46 PM, Stefan Agner wrote:
> On 2016-12-07 18:37, Marek Vasut wrote:
>> On 12/08/2016 02:26
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/338f14f2/attachment.html>
On 12 December 2016 at 18:51, wrote:
> From: Arindam Nath
>
> User might want to query the maximum number of UVD
> instances supported by firmware. In addition to that,
> if there are multiple applications using UVD handles
> at the same time, he might also want to query the
> currently used num
Hi,
Comments below:
> On Dec 14, 2016, at 6:48 AM, Daniel Vetter wrote:
>
> On Wed, Dec 14, 2016 at 3:11 PM, Daniel Vetter wrote:
>> On Wed, Dec 14, 2016 at 03:32:16PM +0200, Mikko Perttunen wrote:
>>> On 14.12.2016 15:05, Daniel Vetter wrote:
On Wed, Dec 14, 2016 at 02:41:28PM +0200, Mik
On 14 December 2016 at 12:30, Daniel Vetter wrote:
> On Wed, Dec 14, 2016 at 01:16:10PM +0200, Mikko Perttunen wrote:
>> This series adds IOMMU support to Host1x and TegraDRM
>> and adds support for the VIC (Video Image Compositor)
>> host1x client. The series is available as a git repository at
>
The audio setting implementation was limited to a few specific pixel
clocks. This prevented HDMI audio from working on several test devices
as they need a pixel clock that is not supported by this implementation.
Fix this by implementing the algorithm provided in the TRM using fixed
point arithmet
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161214/03d508cc/attachment.html>
Thanks Alex my reply was a little off topic :)
-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
Sent: Wednesday, December 14, 2016 1:02 PM
To: Cheng, Tony
Cc: Jani Nikula ; Lukas Wunner ; Bridgman, John ; Deucher, Alexander
; Grodzovsky, Andrey ; amd-gfx mailing list
e: radeon
Kernel modules: radeon
--
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/20161214/6a797aa4/attachment-0001.html>
efore it won't be removed from the queue.
Interestingly the kerneldoc for drm_read() says that the maximum event
space is currently 4 KiB, so I guess libdrm could use an update to use
that maximum. However, upon further inspection I don't see any code in
the kernel that enforces this limit...
Let me see if I can untangle that with some patches...
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/ea6682db/attachment.sig>
The LCD bus width does not need to align with the pixel format. The
LCDIF controller automatically converts between pixel formats and
bus width by padding or dropping LSBs.
The DRM subsystem has the notion of bus_format which allows to
determine what bus_formats are supported by the display. Choos
This patch fixes memory leak in error path of exynos_bo_create().
Signed-off-by: Seung-Woo Kim
---
libkms/exynos.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/libkms/exynos.c b/libkms/exynos.c
index 5de2e5a..0e97fb5 100644
--- a/libkms/exynos.c
+++ b/libkms/exynos.
On 14 December 2016 at 13:12, Eric Engestrom
wrote:
> On Wednesday, 2016-12-14 12:21:55 +, Emil Velikov wrote:
>> On 14 December 2016 at 12:07, Eric Engestrom
>> wrote:
>> > On Wednesday, 2016-12-14 17:16:30 +0900, Seung-Woo Kim wrote:
>> >> This patch fixes memory leak in error path of exy
On 14 December 2016 at 07:04, Michel Dänzer wrote:
> On 13/12/16 10:09 PM, Emil Velikov wrote:
>> Just set the rules automatically rather than asking each contributor to
>> update thing locally.
>>
>> Signed-off-by: Emil Velikov
>> ---
>> autogen.sh | 6 ++
>> 1 file changed, 6 insertions(+
)?
--
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/20161214/615e21e2/attachment.html>
On Wed, 14 Dec 2016, Daniel Vetter wrote:
> On Wed, Dec 14, 2016 at 01:22:15PM +0200, Jani Nikula wrote:
>> On Wed, 14 Dec 2016, Daniel Vetter wrote:
>> > +/**
>> > + * drm_for_each_connector_iter - connector_list iterator macro
>> > + * @connector: struct &drm_connector pointer used as cursor
>>
On 14 December 2016 at 13:34, Tomeu Vizoso
wrote:
> There's no reason any more for callers of this function to take the lock
> themselves, so just move the lock to the function to avoid confusion and
> bugs when more callers are contributed.
>
> Signed-off-by: Tomeu Vizoso
Reviewed-by: Emil Veli
y: Tomi Valkeinen
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/584be2ab/attachment-0001.sig>
On Wed, 14 Dec 2016, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 20bc04d5e617..7e25a7fffb1c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -481,6 +481,9 @@ struct i915_hotplug {
>
On 14.12.2016 16:11, Daniel Vetter wrote:
> On Wed, Dec 14, 2016 at 03:32:16PM +0200, Mikko Perttunen wrote:
>> On 14.12.2016 15:05, Daniel Vetter wrote:
>>> On Wed, Dec 14, 2016 at 02:41:28PM +0200, Mikko Perttunen wrote:
On 14.12.2016 14:30, Daniel Vetter wrote:
> On Wed, Dec 14, 2016
; the code.
Hi,
I have reverted this commit on a 4.8.14 and the flickering stopped.
C.
--
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/20161214/03d72de1/attachment.html>
On 12/14/2016 12:23 PM, Emil Velikov wrote:
> Did you see this causing issues in practise ?
>
> We use a combination of strstr to strip any unwanted starting data,
> and sscanf which [should] trim any trailing garbage.
> That aside, your patch provides an extra bit of robustness which is
> always n
Add user interface to provide channel mapping.
In a first step this control is read only.
As TLV type, the control provides all configuration available for
HDMI sink(ELD), and provides current channel mapping selected by codec
based on ELD and number of channels specified by user on open.
When con
During probe, DAIs can need to perform some actions that requests
the knowledge of the pcm runtime handle.
The callback is called during DAIs linking, after PCM device creation.
For instance this can be used to add relation ship between a DAI pcm
control and the pcm device.
Signed-off-by: Arnaud P
For HDMI, channel mapping can be retrieved from ELD. In this case mapping
can change during runtime (plug/unplug).
This patch suppresses the 'const' property of the struct chmap.
Signed-off-by: Arnaud Pouliquen
---
include/sound/pcm.h | 4 ++--
sound/core/pcm_lib.c | 6 +++---
2 files changed,
Add helper to allow users to retrieve the speaker allocations without
knowledge of the ELD structure.
Signed-off-by: Arnaud Pouliquen
---
include/drm/drm_edid.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 919933d..0706c
Aim of this patch is to add 'Playback Channel Map' control to export
audio capabilities in term of HDMI sink speakers allocation.
V2:
In this version I use chmap helper functions from pcm_lib.c.
It is quite tricky to use it from ASoC due to the relation chip of the controls
with the pcm runtime
Technically, calling dma_buf_map_attachment should return a buffer
properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
ensure this happens. As a side effect, this lets Ion buffers take
advantage of the dma_buf sync ioctls.
Not-signed-off-by: Laura Abbott
---
drivers/staging/andr
Unclear if this is wanted or needed?
Not-signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 74 ---
1 file changed, 74 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 76b874a0..86dba07 1
Ion currently returns a single sg_table on each dma_map call. This is
incorrect for later usage.
Not-signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion
- dmap_cnt isn't used. Remove it.
- Ion has been using dma apis incorrectly to sync the caches.
Remove bad usage in preparation for something better.
- The alignment field doesn't actually change the alignment of an
allocation, it only serves as an error check. This is basically
pointless. R
Hi,
I've been (once again) looking at alternate caching models for Ion. Part of
this work is also to make Ion fit better in to the dma_buf model.
Ion is a bit unusual for dma_buf. Most drivers that support dma_buf have two
parts: exporting buffers that a driver allocates and importing buffers
al
On 13/12/16 10:09 PM, Emil Velikov wrote:
> Just set the rules automatically rather than asking each contributor to
> update thing locally.
>
> Signed-off-by: Emil Velikov
> ---
> autogen.sh | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/autogen.sh b/autogen.sh
> index c896097..
On 12 December 2016 at 18:49, wrote:
> From: Arindam Nath
>
> Change History
> --
>
> v3: changes suggested by Christian
> - Add a check for UVD IP block using AMDGPU_HW_IP_UVD
> query type.
> - Add a check for asic_type to be less than
> CHIP_POLARIS10 since starting Polaris, we
On Wed, Dec 14, 2016 at 3:44 PM, Jani Nikula
wrote:
> On Wed, 14 Dec 2016, Daniel Vetter wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 20bc04d5e617..7e25a7fffb1c 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i
On Wed, Dec 14, 2016 at 3:11 PM, Daniel Vetter wrote:
> On Wed, Dec 14, 2016 at 03:32:16PM +0200, Mikko Perttunen wrote:
>> On 14.12.2016 15:05, Daniel Vetter wrote:
>> > On Wed, Dec 14, 2016 at 02:41:28PM +0200, Mikko Perttunen wrote:
>> > > On 14.12.2016 14:30, Daniel Vetter wrote:
>> > > > On W
On 12 December 2016 at 23:28, Grazvydas Ignotas wrote:
> On Mon, Dec 12, 2016 at 3:59 PM, Emil Velikov
> wrote:
>> On 11 December 2016 at 18:03, Grazvydas Ignotas wrote:
>>> Just tell the compiler that drm_event will alias the char buffer,
>>> so that it has no excuse to warn or generate bad co
or split up the
helpers a little differently to avoid creating GEM objects from the
firmware buffers. We wouldn't want userspace to start mmap()'ing those.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/872e65bc/attachment.sig>
On 14.12.2016 15:05, Daniel Vetter wrote:
> On Wed, Dec 14, 2016 at 02:41:28PM +0200, Mikko Perttunen wrote:
>> On 14.12.2016 14:30, Daniel Vetter wrote:
>>> On Wed, Dec 14, 2016 at 01:16:10PM +0200, Mikko Perttunen wrote:
This series adds IOMMU support to Host1x and TegraDRM
and adds sup
rry these patches out of tree and use them
for testing until we've got a complete userspace ready. It's just
something that I had hoped I could avoid.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/0474a959/attachment.sig>
On 14.12.2016 14:56, Lucas Stach wrote:
> Am Mittwoch, den 14.12.2016, 14:36 +0200 schrieb Mikko Perttunen:
>> On 14.12.2016 13:35, Lucas Stach wrote:
>>> Am Mittwoch, den 14.12.2016, 13:16 +0200 schrieb Mikko Perttunen:
Add a new IO virtual memory allocation API to allow clients to
alloc
On 14.12.2016 07:04, Hoegeun Kwon wrote:
> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
> driver. This panel has 1440x2560 resolution in 5.7-inch physical
> panel in the TM2 device.
>
> Signed-off-by: Donghwa Lee
> Signed-off-by: Hyungwon Hwang
> Signed-off-by: Hoegeun Kwon
Hi
s not perfect either, and in the worst case could mean still
doing the spinlock at every irq... But, if I'm not mistaken, the current
HW versions do not have overlapping irq bits.
> Given that we already take the same lock in the IRQ handler to call the wait
> handlers, do you think this is really an issue ?
I don't think it's really an issue. But it's nice to optimize irq
handlers, especially as this is a hard-irq.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/6dab0fac/attachment.sig>
On Wed, Dec 14, 2016 at 03:32:16PM +0200, Mikko Perttunen wrote:
> On 14.12.2016 15:05, Daniel Vetter wrote:
> > On Wed, Dec 14, 2016 at 02:41:28PM +0200, Mikko Perttunen wrote:
> > > On 14.12.2016 14:30, Daniel Vetter wrote:
> > > > On Wed, Dec 14, 2016 at 01:16:10PM +0200, Mikko Perttunen wrote:
--- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/6a5092b5/attachment.html>
From: Hyungwon Hwang
This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.
Signed-off-by: Hyungwon Hwang
Signed-off-by: Andrzej Hajda
Signed-off-by: Chanwoo Choi
Signed-off-by: Hoegeun Kwon
---
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 33 +++
This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
---
.../bindings/display/panel/samsung,s6e3ha2.txt |
Purpose of this patch is add support for S6E3HA2 AMOLED panel on
the TM2 board. The first patch adds support for S6E3HA2 panel
device tree document and driver, the second patch add support for
S6E3HA2 panel device tree.
Hoegeun Kwon (1):
drm/panel: Add support for S6E3HA2 panel driver on TM2 boa
a huge change.
I guess a first step is Peter Ujfalusi's series:
https://lkml.org/lkml/2016/9/1/267
-- Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/df0fdfa4/attachment-0001.sig>
Am Mittwoch, den 14.12.2016, 14:48 +0100 schrieb Thierry Reding:
> On Wed, Dec 14, 2016 at 12:35:31PM +0100, Lucas Stach wrote:
> > Am Mittwoch, den 14.12.2016, 13:16 +0200 schrieb Mikko Perttunen:
> > > Add a new IO virtual memory allocation API to allow clients to
> > > allocate non-GEM memory in
ment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/6dd7af93/attachment.sig>
On 14.12.2016 14:30, Daniel Vetter wrote:
> On Wed, Dec 14, 2016 at 01:16:10PM +0200, Mikko Perttunen wrote:
>> This series adds IOMMU support to Host1x and TegraDRM
>> and adds support for the VIC (Video Image Compositor)
>> host1x client. The series is available as a git repository at
>> git://gi
On 14.12.2016 13:35, Lucas Stach wrote:
> Am Mittwoch, den 14.12.2016, 13:16 +0200 schrieb Mikko Perttunen:
>> Add a new IO virtual memory allocation API to allow clients to
>> allocate non-GEM memory in the Tegra DRM IOMMU domain. This is
>> required e.g. for loading client firmware when clients a
Use drm_accurate_vblank_count so we have the full 32 bit to represent
the frame counter and userspace has a simpler way of knowing when the
counter wraps around.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/i915/i915_irq.c | 6 +++---
1 file changed, 3 insertions(+
The core provides now an ABI to userspace for generation of frame CRCs,
so implement the ->set_crc_source() callback and reuse as much code as
possible with the previous ABI implementation.
When handling the pageflip interrupt, we skip 1 or 2 frames depending on
the HW because they contain wrong v
There's no reason any more for callers of this function to take the lock
themselves, so just move the lock to the function to avoid confusion and
bugs when more callers are contributed.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_debugfs_crc.c | 9 +++--
1 file changed, 7 insertions
Hi,
here are the patches that remain to be merged in this series.
I have only rebased them since last time.
Thanks,
Tomeu
Tomeu Vizoso (3):
drm: Move locking into drm_debugfs_crtc_crc_add
drm/i915: Use new CRC debugfs API
drm/i915: Put "cooked" vlank counters in frame CRC lines
driver
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Exercise drm_mm_insert_node(), check that we can't overfill a range and
> that the lists are correct after reserving/removing.
>
> Signed-off-by: Chris Wilson
> +static int __igt_insert(int count, u64 size)
> +{
> + for (n = 0; n <
On Mon, 2016-12-12 at 07:33 -0800, Alex Deucher wrote:
> On Mon, Dec 12, 2016 at 1:14 AM, sourab gupta
> wrote:
> > On Mon, 2016-12-05 at 03:06 -0800, Dhingra, Swati wrote:
> >> From: Swati Dhingra
> >>
> >> Currently, we don't have a stable ABI which can be used for the purpose of
> >> providin
On Wed, Nov 16, 2016 at 02:58:04PM +0100, Maarten Lankhorst wrote:
> Second approach. Instead of trying to convert all drivers straight away,
> implement all macros that are required to get state working.
>
> Current situation:
> Use obj->state, which can refer to old or new state.
> Use drm_atomi
On Thu, Nov 17, 2016 at 02:20:10PM +0100, Maarten Lankhorst wrote:
> With checks! This will allow safe access to the current state,
> while ensuring that the correct locks are held.
>
> Changes since v1:
> - Constify returned states.
> - Require plane lock to return plane state, don't allow crtc_l
ment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/d1b0183e/attachment.html>
On Wed, Dec 14, 2016 at 02:41:28PM +0200, Mikko Perttunen wrote:
> On 14.12.2016 14:30, Daniel Vetter wrote:
> > On Wed, Dec 14, 2016 at 01:16:10PM +0200, Mikko Perttunen wrote:
> > > This series adds IOMMU support to Host1x and TegraDRM
> > > and adds support for the VIC (Video Image Compositor)
>
On ke, 2016-12-14 at 11:39 +, Chris Wilson wrote:
> On Tue, Dec 13, 2016 at 11:35:42AM +0200, Joonas Lahtinen wrote:
> >
> > On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> > >
> > > +#define __drm_mm_nodes(mm) (&(mm)->head_node.node_list)
> >
> > Not static inline for type checking?
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Reuse drm_mm_insert_node() with a temporary node to exercise
> drm_mm_replace_node(). We use the previous test in order to exercise the
> various lists following replacement.
>
> Signed-off-by: Chris Wilson
> +static int __igt_insert(int
By using the HDMI notifier framework there is no longer any reason
to manually set the physical address. This was the one blocking
issue that prevented this driver from going out of staging, so do
this move as well.
Update the bindings documenting the new hdmi phandle and
update stih410.dtsi and s
Implement the HDMI notifier support to allow CEC drivers to
be informed when there is a new EDID and when a connect or
disconnect happens.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/Kconfig| 1 +
drivers/gpu/drm/sti/sti_hdmi.c | 15 +++
drivers/gpu/drm/sti/sti_hdmi
Following (copying !) what Hans have done in this serie of patches
http://www.spinics.net/lists/linux-media/msg109141.html
I have implemented hdmi notifier in hdmi controled and stih-cec drivers.
Those patches should be applied on top of Hans patches for exynos.
I have tested hdmi notifier by plu
Am Mittwoch, den 14.12.2016, 14:36 +0200 schrieb Mikko Perttunen:
> On 14.12.2016 13:35, Lucas Stach wrote:
> > Am Mittwoch, den 14.12.2016, 13:16 +0200 schrieb Mikko Perttunen:
> >> Add a new IO virtual memory allocation API to allow clients to
> >> allocate non-GEM memory in the Tegra DRM IOMMU d
Hi Tomi,
On Wednesday 14 Dec 2016 10:20:39 Tomi Valkeinen wrote:
> On 14/12/16 01:38, Laurent Pinchart wrote:
> > The omapdrm platform device is a virtual device created for the sole
> > purpose of handling the omapdss/omapdrm driver split. It should
> > eventually be removed. As a first step to e
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Check that if we request top-down allocation with a particular alignment
> from drm_mm_insert_node() that the start of the node matches our
> request.
>
> Signed-off-by: Chris Wilson
Assuming magic numbers be gone in next iteration.
> +sta
Hi Tomi,
On Wednesday 14 Dec 2016 10:48:06 Tomi Valkeinen wrote:
> On 14/12/16 02:27, Laurent Pinchart wrote:
> > Hello,
> >
> > Here's the fourth version of my current stack of pending patches for the
> > omapdrm driver.
> >
> > All comments received for v3 have been considered and patches upda
Hi Tomi,
On Wednesday 14 Dec 2016 12:22:29 Tomi Valkeinen wrote:
> On 14/12/16 02:27, Laurent Pinchart wrote:
> > As the FIFO underflow IRQ handler just prints an error message to the
> > kernel log, simplify the code by not registering one IRQ handler per
> > plane but print the messages directly
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Check that if we request top-down allocation from drm_mm_insert_node()
> we receive the next available hole from the top.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technol
On Wed, Dec 14, 2016 at 01:16:10PM +0200, Mikko Perttunen wrote:
> This series adds IOMMU support to Host1x and TegraDRM
> and adds support for the VIC (Video Image Compositor)
> host1x client. The series is available as a git repository at
> git://github.com/cyndis/linux.git; branch vic-2.
>
> A
Hi Tomi,
On Wednesday 14 Dec 2016 12:43:54 Tomi Valkeinen wrote:
> On 14/12/16 02:27, Laurent Pinchart wrote:
> > The DRM core supports skipping plane update for inactive CRTCs for
> > hardware that don't need it or can't cope with it. That's our case, and
> > the driver already skips flushing pla
On Wed, Dec 14, 2016 at 01:22:15PM +0200, Jani Nikula wrote:
> On Wed, 14 Dec 2016, Daniel Vetter wrote:
> > +/**
> > + * drm_for_each_connector_iter - connector_list iterator macro
> > + * @connector: struct &drm_connector pointer used as cursor
> > + * @iter: struct &drm_connector_list_iter
> >
On Wed, 14 Dec 2016, Daniel Vetter wrote:
> The requirements for connector_list locking are a bit tricky:
> - We need to be able to jump over zombie conectors (i.e. with refcount
> == 0, but not yet removed from the list). If instead we require that
> there's no zombies on the list then the fi
signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/88d603a4/attachment.sig>
The Host1x driver now supports operation behind an IOMMU,
so add its IOMMU domain to the device tree.
Signed-off-by: Mikko Perttunen
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/dts/
Enable the VIC (Video Image Compositor) host1x
unit on Tegra210 systems.
Signed-off-by: Mikko Perttunen
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/d
The VIC (Video Image Compositor) is a Host1x client unit
that can do various 2D composition and transform operations.
Signed-off-by: Mikko Perttunen
---
.../bindings/display/tegra/nvidia,tegra20-host1x.txt| 13 +
1 file changed, 13 insertions(+)
diff --git
a/Documentation/d
Add support for the Host1x unit to be located behind
an IOMMU. This is required when gather buffers may be
allocated non-contiguously in physical memory, as can
be the case when TegraDRM is also using the IOMMU.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/cdma.c | 74
From: Arto Merilainen
This patch adds support for Video Image Compositor engine which
can be used for 2d operations.
Signed-off-by: Andrew Chew
Signed-off-by: Arto Merilainen
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/Makefile | 3 +-
drivers/gpu/drm/tegra/drm.c| 3 +
d
From: Arto Merilainen
Add a set of falcon helper routines for use by the tegradrm client drivers
of the various falcon-based engines.
The falcon is a microcontroller that acts as a frontend for the rest of a
particular Tegra engine. In order to properly utilize these engines, the
frontend must
Add a new IO virtual memory allocation API to allow clients to
allocate non-GEM memory in the Tegra DRM IOMMU domain. This is
required e.g. for loading client firmware when clients are attached
to the IOMMU domain.
The allocator allocates contiguous physical pages that are then
mapped contiguously
1 - 100 of 237 matches
Mail list logo
