The R-Car DU supports writing back the display unit output to memory.
Add support for that feature using a V4L2 device.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/Makefile| 3 +-
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 47 +-
drivers/gpu/drm/rcar-du/rcar_du_crtc.h
Hi Daniel,
On Monday 16 March 2015 09:35:22 Daniel Vetter wrote:
> On Sun, Mar 15, 2015 at 11:55:35PM +0200, Laurent Pinchart wrote:
> > Hello,
> >
> > I have a feeling that RFC/PATCH will work better than just RFC, so here's
> > a patch set that adds a new object named live source to DRM.
> >
>
Previous code was busted, as it wasn't checking directly for what it was
meant to, and at the end changing the user's selection if host_cpu
heuristics were involved.
Simplify things by adding a macro that does the long message printing
for us, and check for only what we need.
This fixes commit 36
The message "enabled on x86" was meant for the intel libdrm.
Take the opportunity to mention how libkms is autodetected.
Signed-off-by: Emil Velikov
---
configure.ac | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 3f567f3..fb5e6aa 100644
The former is a subset of the latter. Error out early so the user is
aware that they are doing something very wrong.
Cc: Rob Clark
Signed-off-by: Emil Velikov
---
configure.ac | 5 +
1 file changed, 5 insertions(+)
diff --git a/configure.ac b/configure.ac
index fb5e6aa..fcb21df 100644
---
https://bugzilla.kernel.org/show_bug.cgi?id=94961
Bug ID: 94961
Summary: BUG: unable to handle kernel NULL pointer dereference
Product: Drivers
Version: 2.5
Kernel Version: 3.19.1
Hardware: All
OS: Linux
Tree:
On 16.03.2015 23:52, Carsten Emde wrote:
> Hi Michel,
>
>>> [..]
>>> The most striking problem of kernel 3.18.9-rt4 affects all systems that
>>> are equipped with Radeon graphics (irrespective whether PCIe cards or
>>> APUs with on-chip graphics). They suffer from a hanging radeon driver.
>>> The
p.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science &Technology
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150317/e8ec903a/attachment.html>
On 17.03.2015 07:32, Alex Deucher wrote:
> On Thu, Mar 12, 2015 at 10:55 PM, Michel Dänzer
> wrote:
>> On 12.03.2015 22:09, Alex Deucher wrote:
>>> On Thu, Mar 12, 2015 at 5:23 AM, Christian König
>>> wrote:
On 12.03.2015 10:02, Michel Dänzer wrote:
>
> On 12.03.2015 06:14, Alex
https://bugzilla.kernel.org/show_bug.cgi?id=85421
--- Comment #31 from Hin-Tak Leung ---
Apparently according to the log, I had a GPU crash on 1st March on suspend,
which I did not notice.
With kernel 3.18.9-200.fc21.x86_64, besides GPU lock up, the kernel also
oops'ed. May it is a good thing? :
https://bugzilla.kernel.org/show_bug.cgi?id=85421
--- Comment #32 from Hin-Tak Leung ---
Created attachment 170901
--> https://bugzilla.kernel.org/attachment.cgi?id=170901&action=edit
the part of /var/log/messages about GPU lock up and oops in
3.18.9-200.fc21.x86_64
gz'ed.
--
You are receivi
This wasn't too harmful since we already look at connector,
which has the same effect as the loop for any non-cloned configs.
Only when we have a cloned configuration is it important to look
at other connectors. Furthermore existing userspace always changes
dpms on all of them anyway.
Signed-off-b
There are some mistakes that the function name in the annotaions
is not matching the real function name.
And some duplication word in annotations
Signed-off-by: John Hunter
---
drivers/gpu/drm/drm_atomic_helper.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/dr
use outdise defined variable can reduce the recaculate of the
count of planes, crtcs and connectors.
Signed-off-by: John Hunter
---
drivers/gpu/drm/drm_atomic_helper.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/
On Mon, Mar 16, 2015 at 01:21:58PM -0400, Steven Rostedt wrote:
> On Mon, 16 Mar 2015 17:43:33 +0100
> Daniel Vetter wrote:
>
>
> > Is linux-next also affected or is this just a case of i915 maintainers
> > having failed to push the right patch to -fixes?
>
> I just confirmed, linux-next boots
Zhao
Microprocessor Research and Develop Center
Department of Computer Science &Technology
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150317/1
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150317/62087546/attachment.html>
On Tue, Mar 17, 2015 at 03:30:28PM +0800, John Hunter wrote:
> This wasn't too harmful since we already look at connector,
> which has the same effect as the loop for any non-cloned configs.
> Only when we have a cloned configuration is it important to look
> at other connectors. Furthermore existi
On Tue, Mar 17, 2015 at 03:30:27PM +0800, John Hunter wrote:
> use outdise defined variable can reduce the recaculate of the
> count of planes, crtcs and connectors.
>
> Signed-off-by: John Hunter
Hm, what's the benefit you see for this change? The lines aren't too long
yet and we don't reuse th
Hi John
> I noticed that there is no geode subsystem in the drm directory.
> I have a system using the geode LX framebuffer and
> xserver-xorg-video-geode. I am wondering if we can add the drm
> part of geode lx to let it support the dri?
>
The geode thing is nearly EOL and is quite old to do som
ntel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science &Technology
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150317/a2578300/attachment.html>
oundcloud.com/christian-gmeiner
>
--
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science &Technology
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150317/2e0374b9/attachment-0001.html>
On Tue, Mar 17, 2015 at 04:48:23PM +0800, John Hunter wrote:
> Hi Daniel,
>
> On Tue, Mar 17, 2015 at 4:40 PM, Daniel Vetter wrote:
>
> > On Tue, Mar 17, 2015 at 03:30:27PM +0800, John Hunter wrote:
> > > use outdise defined variable can reduce the recaculate of the
> > > count of planes, crtcs
sts.freedesktop.org
> > > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> > > ___
> > > dri-devel mailing list
> > > dri-devel at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> >
> >
> >
> > --
> > Best regards
> > Junwang Zhao
> > Microprocessor Research and Develop Center
> > Department of Computer Science &Technology
> > Peking University
> > Beijing, 100871, PRC
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
--
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science &Technology
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150317/e7f14e31/attachment.html>
Hi Sébastien,
Am Montag, den 16.03.2015, 18:29 +0100 schrieb Sébastien Szymanski:
> From: Steve Longerbeam
>
> [Sébastien - rebase, update drm_display_mode_to_videomode function]
>
> Signed-off-by: Steve Longerbeam
> Signed-off-by: Sébastien Szymanski
Thanks for bringing this up again. T
Be warned if primary or cursor planes haven't the correct type
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/drm_crtc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5785336..111849c4 100644
--- a/drivers/gpu/drm/drm_c
On 11/03/15 19:38, Tobias Jakobi wrote:
> This makes it easier to spot memory corruptions which don't become
> visible when using a plain buffer filled with a solid color (so
> corruptions that are just a permutation of the bytes in the buffer).
>
> Signed-off-by: Tobias Jakobi
> Reviewed-by: Ink
On 16.03.2015 23:32, Alex Deucher wrote:
> On Thu, Mar 12, 2015 at 10:55 PM, Michel Dänzer
> wrote:
>> On 12.03.2015 22:09, Alex Deucher wrote:
>>> On Thu, Mar 12, 2015 at 5:23 AM, Christian König
>>> wrote:
On 12.03.2015 10:02, Michel Dänzer wrote:
> On 12.03.2015 06:14, Alex Deuche
Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns() instead of
hand made mapping of virtual address to physical address. Also the
function leaked page reference from get_user_pages() so fix that by
properly release the reference when omap_vout_buffer_release() is
called.
Signed-off-by: Ja
Provide new function get_vaddr_pfns(). This function maps virtual
addresses from given start and fills given array with page frame numbers of
the corresponding pages. If given start belongs to a normal vma, the function
grabs reference to each of the pages to pin them in memory. If start
belongs t
Provide simple helper functions to map virtual address range into an
array of pfns.
Signed-off-by: Jan Kara
---
drivers/media/v4l2-core/videobuf2-memops.c | 57 ++
include/media/videobuf2-memops.h | 4 +++
2 files changed, 61 insertions(+)
diff --git a/dri
Hello,
After a long pause I'm sending second version of my patch series to abstract
vma handling from the various media drivers. After this patch set drivers have
to know much less details about vmas, their types, and locking. My motivation
for the series is that I want to change get_user_page
Currently vb2 core acquires mmap_sem just around call to
__qbuf_userptr(). However since commit f035eb4e976ef5 (videobuf2: fix
lockdep warning) it isn't necessary to acquire it so early as we no
longer have to drop queue mutex before acquiring mmap_sem. So push
acquisition of mmap_sem down into .ge
Convert vb2_vmalloc_get_userptr() to use passed vector of pfns. When we
are doing that there's no need to allocate page array and some code can
be simplified.
Signed-off-by: Jan Kara
---
drivers/media/v4l2-core/videobuf2-vmalloc.c | 94 +++--
1 file changed, 36 insertions
Convert g2d_userptr_get_dma_addr() to pin pages using get_vaddr_pfn().
This removes the knowledge about vmas and mmap_sem locking from exynos
driver. Also it fixes a problem that the function has been mapping user
provided address without holding mmap_sem.
Signed-off-by: Jan Kara
---
drivers/gpu
Signed-off-by: Jan Kara
---
drivers/media/v4l2-core/videobuf2-dma-sg.c | 97 +-
1 file changed, 15 insertions(+), 82 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 71510e4f7d7c..cc82c30d02cf 100
Conversion to the use of pinned pfns made some functions unused. Remove
them. Also there's no need to lock mmap_sem in __buf_prepare() anymore.
Signed-off-by: Jan Kara
---
drivers/media/v4l2-core/videobuf2-memops.c | 114 -
include/media/videobuf2-memops.h |
Convert vb2_dc_get_userptr() to use passed vector of pfns. When we are
doing that there's no need to allocate page array and some code can be
simplified.
Signed-off-by: Jan Kara
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 213 -
1 file changed, 32 insertions(+),
as scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150317/51b1eb86/attachment.html>
On Tue, Mar 17, 2015 at 12:05:29PM +0100, Benjamin Gaignard wrote:
> Be warned if primary or cursor planes haven't the correct type
>
> Signed-off-by: Benjamin Gaignard
Yeah that's a useful self-check to make sure universal plane conversions
are done correctly. Merged to drm-misc, thanks.
-Danie
> Thank you Tobias.
> The series is in master now.
>
> -Emil
Thanks Emil!
Going to prepare the next series now.
With best wishes,
Tobias
When performing a modeset, use the framebuffer pitch value to set FIMD
IMG_SIZE and Mixer SPAN registers. These are both defined as pitch - the
distance between contiguous lines (bytes for FIMD, pixels for mixer).
Fixes display on Snow (1366x768).
Signed-off-by: Daniel Stone
Tested-by: Javier Ma
On Tue, Mar 17, 2015 at 7:40 AM, Christian König
wrote:
> On 16.03.2015 23:32, Alex Deucher wrote:
>>
>> On Thu, Mar 12, 2015 at 10:55 PM, Michel Dänzer
>> wrote:
>>>
>>> On 12.03.2015 22:09, Alex Deucher wrote:
On Thu, Mar 12, 2015 at 5:23 AM, Christian König
wrote:
>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150317/e9b73d06/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150317/e794f9cf/attachment.html>
o
>> *rbo, u32 domain)
>>*/
>> if ((rbo->flags & RADEON_GEM_NO_CPU_ACCESS) &&
>> rbo->rdev->mc.visible_vram_size <
>> rbo->rdev->mc.real_vram_size) {
>> - rbo->
On Fri, 13 Mar 2015, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> When an i2c WRITE gets an i2c defer or short i2c ack reply, we are
> supposed to switch the request from I2C_WRITE to I2C_WRITE_STATUS_UPDATE
> when we continue to poll for the completion of the request.
As I
gt;mc.visible_vram_size >>
>>> PAGE_SHIFT))
>>> + rbo->placements[c].fpfn = fpfn;
>>> + else
>>> + rbo->placements[c].fpfn =
>>> + rbo->rdev->mc.visible_vram_size >>
>>> PAGE_SHIFT;
>>>rbo->placements[c++].flags = TTM_PL_FLAG_WC |
>>> TTM_PL_FLAG_UNCACHED |
>>> TTM_PL_FLAG_VRAM;
>>>}
>> If (fpfn >= rbo->rdev->mc.visible_vram_size), this whole block can be
>> skipped, since the next placement will be identical.
>>
>> OTOH, fpfn is currently always 0 anyway, so maybe it's better not to add
>> that parameter in the first place.
>>
>>
>> Other than that, looks good to me.
> Broken out patches attached. Also available here:
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=topdown-fixes
Thinking more about it that approach is a NAK. For limiting a BO into
visible VRAM we want the limit it to only apply to the VRAM domain
entry, doing it this way it applies to GTT as well which is really bad
for handling page faults.
I would rather say let us completely nuke
radeon_ttm_placement_from_domain for internal allocations and give
radeon_bo_create a ttm_placement pointer to use.
Driver internal allocations would then have a couple of predefined
placements for their buffers. We might need to make a few ttm_placement
pointers const for this, but I think that this is the better approach.
Regards,
Christian.
>
> Alex
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150317/3eb9758a/attachment.html>
When userspace queries the current vblank for the CRTC, we can reply
with the cached value (using atomic reads to serialise with the vblank
interrupt as necessary) without having to touch registers. In the
instant disable case, this saves us from enabling/disabling the vblank
around every query, gr
This patch adds the remaining missing IDMAC channel names: all VDIC channels
for deinterlacing and combining, the separate alpha channels for the MEM->IC
and MEM->DC ASYNC channels, and the DC read / command / output mask channels.
Signed-off-by: Philipp Zabel
---
include/video/imx-ipu-v3.h | 15
Hi,
this series uses the IPU IC post-processing task, to implement
a mem2mem device for scaling and colorspace conversion.
regards
Philipp
Philipp Zabel (3):
gpu: ipu-v3: Add missing IDMAC channel names
gpu: ipu-v3: Add mem2mem image conversion support to IC
gpu: ipu-v3: Register scaler pl
From: Sascha Hauer
Add video4linux API routines common to drivers for units that
accept or provide video data via the i.MX IPU IDMAC channels,
such as scaler or deinterlacer drivers.
Signed-off-by: Sascha Hauer
Signed-off-by: Lucas Stach
Signed-off-by: Philipp Zabel
---
drivers/media/platfor
From: Sascha Hauer
This patch adds support for hardware accelerated scaling and color
space conversion between memory buffers using the IPUv3 IC.
Since the maximum output size of the IC unit is 1024x1024 pixels, multiple
IC tasks with overlapping tiles are used internally to scale and convert
lar
This patch registers the scaler device using the IC post-processing task,
to be handled by a mem2mem scaler driver.
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-comm
This patch adds support for mem2mem scaling and colorspace conversion
using the IC module's post-processing task.
Scaling images larger than 1024x1024 is supported by tiling over multiple
IC scaling runs. Since the IDMAC and IC units have interesting and different
alignment limitations for buffer
On Tue, Mar 17, 2015 at 11:43 AM, Christian König
wrote:
> On 17.03.2015 16:19, Alex Deucher wrote:
>
> On Mon, Mar 16, 2015 at 11:48 PM, Michel Dänzer
> wrote:
>
> On 17.03.2015 07:32, Alex Deucher wrote:
>
> On Thu, Mar 12, 2015 at 10:55 PM, Michel Dänzer
> wrote:
>
> On 12.03.2015 22:09,
radeon_bo_create() calls radeon_ttm_placement_from_domain()
before ttm_bo_init() is called. radeon_ttm_placement_from_domain()
uses the ttm bo size to determine when to select top down
allocation but since the ttm bo is not initialized yet the
check is always false. It only took affect when buffe
On 17.03.2015 16:59, Alex Deucher wrote:
> radeon_bo_create() calls radeon_ttm_placement_from_domain()
> before ttm_bo_init() is called. radeon_ttm_placement_from_domain()
> uses the ttm bo size to determine when to select top down
> allocation but since the ttm bo is not initialized yet the
> che
On 03/17/2015 04:59 PM, Alex Deucher wrote:
> radeon_bo_create() calls radeon_ttm_placement_from_domain()
> before ttm_bo_init() is called. radeon_ttm_placement_from_domain()
> uses the ttm bo size to determine when to select top down
> allocation but since the ttm bo is not initialized yet the
>
h_limit: 450
--
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/20150317/2a219917/attachment.html>
Already implicitly handled by the compiler.
Signed-off-by: Emil Velikov
---
Inspired while cleaning up the very same includes in the Android build.
-Emil
exynos/Makefile.am| 1 -
freedreno/Makefile.am | 1 -
intel/Makefile.am | 1 -
nouveau/Makefile.am | 1 -
omap/Makefile.am |
Hi all,
As pointed out by Chih-Wei, Android's LOCAL_COPY_HEADERS{,_TO} has been
depreciated for quite some time.
Although it was a convenient way of getting things done (no more
hard-coding the location of drm) it seems that there is another more
appropriate (and cleaner) solution. Namely:
Ann
- Don't add ${hw}/${hw}, but ${hw} to the includes path. The former
does not exist.
- Set the variable for libkms.
Inspired by the work of from Chih-Wei from the Android-x86 project.
Signed-off-by: Emil Velikov
---
Android.mk | 2 +-
freedreno/Android.mk | 3 +--
intel/Android.mk
Each of the libdrm_${hw} modules pull libdrm for linking as such:
libdrm's LOCAL_EXPORT_C_INCLUDE_DIRS are added to the includes list.
The former of which is already set to ${top} and ${top}/include/drm.
Signed-off-by: Emil Velikov
---
freedreno/Android.mk | 4 +---
intel/Android.mk | 2 --
With earlier changes we've implicitly add the relevant directories
to the includes list, via LOCAL_EXPORT_C_INCLUDES_DIRS.
Signed-off-by: Emil Velikov
---
freedreno/Android.mk | 3 ---
intel/Android.mk | 3 ---
libkms/Android.mk| 3 ---
nouveau/Android.mk | 3 ---
radeon/Android.mk
Already implicitly handled by the compiler.
Signed-off-by: Emil Velikov
---
freedreno/Android.mk | 3 ---
intel/Android.mk | 1 -
nouveau/Android.mk | 3 ---
radeon/Android.mk| 3 ---
4 files changed, 10 deletions(-)
diff --git a/freedreno/Android.mk b/freedreno/Android.mk
index d6c19
Signed-off-by: Emil Velikov
---
libkms/Android.mk | 1 +
1 file changed, 1 insertion(+)
diff --git a/libkms/Android.mk b/libkms/Android.mk
index 12cf844..4f5e3d2 100644
--- a/libkms/Android.mk
+++ b/libkms/Android.mk
@@ -43,6 +43,7 @@ LOCAL_SRC_FILES += $(LIBKMS_RADEON_FILES)
endif
LOCAL_MODU
In commit 6a4a47cfd181 ("drm/nva3/clk: Set PLL refclk") diff was changed from
int to u32 because of which a later branch which was testing if (diff < 0)
became always false. Fix this by using int type for diff.
Signed-off-by: Pranith Kumar
CC: stable at vger.kernel.org
CC: Roy Spliet
CC: Ben Ske
On Tue, 17 Mar 2015 08:53:21 +0100
Daniel Vetter wrote:
> Can you please cherry pick 42a7b088127f (\"drm/i915: Make sure the primary
> plane is enabled before reading out the fb state\") from -next to 4.0-rc
> to test whether this is indeed the difference in ducttape?
I cherry-picked that patch
69 matches
Mail list logo
