.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/afc697bb/attachment.html>
On Tue, Feb 3, 2015 at 10:42 PM, Arnd Bergmann wrote:
>> Again assuming I'm not confused can't we just solve this by pushing the
>> dma api abstraction down one layer for just the gpu, and let it use its
>> private iommmu directly? Steps for binding a buffer would be:
>> 1. dma_map_sg
>> 2. Noodle
On Tuesday 03 February 2015 12:35:34 Rob Clark wrote:
>
> I can't think of cases outside of GPU's.. if it were more common I'd
> be in favor of teaching dma api about multiple contexts, but right now
> I think that would just amount to forcing a lot of churn on everyone
> else for the benefit of
On Tuesday 03 February 2015 21:04:35 Daniel Vetter wrote:
> - On many soc people love to reuse iommus with the same or similar
> interface all over the place. The solution thus far adopted on arm
> platforms is to write an iommu driver for those and then implement the
> dma-api on top of thi
freedesktop.org/archives/dri-devel/attachments/20150203/1f9623ce/attachment.html>
Hi,
tested next-20150202. System boots, but graphic output is broken (empty black
screen).
Booted five times the same kernel, always got the same result. The system works
with 3.19-rc7.
This is the first warning in the log:
WARNING: CPU: 0 PID: 855 at drivers/gpu/drm/i915/intel_uncore.c:169
On 02/02/2015 08:09 AM, Russell King - ARM Linux wrote:
> On Mon, Feb 02, 2015 at 07:32:05AM -0500, Yang Kuankuan wrote:
>> On 02/02/2015 06:53 AM, Russell King - ARM Linux wrote:
>>> On Mon, Feb 02, 2015 at 12:02:50PM +0800, Daniel Kurtz wrote:
Hi ykk,
On Sat, Jan 31, 2015 at 10:34
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/7ba076b8/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/19f48195/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/455de842/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/56f1de82/attachment.html>
ttachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/8545bc40/attachment-0001.html>
On Tue, Feb 03, 2015 at 12:35:34PM -0500, Rob Clark wrote:
> On Tue, Feb 3, 2015 at 11:58 AM, Russell King - ARM Linux
> wrote:
> >
> > Okay, but switching contexts is not something which the DMA API has
> > any knowledge of (so it can't know which context to associate with
> > which mapping.) Wh
https://bugzilla.kernel.org/show_bug.cgi?id=89731
--- Comment #3 from Alex Deucher ---
see also:
https://bugs.freedesktop.org/show_bug.cgi?id=88927
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Tue, Feb 03, 2015 at 05:36:59PM +0100, Arnd Bergmann wrote:
> On Tuesday 03 February 2015 11:22:01 Rob Clark wrote:
> > On Tue, Feb 3, 2015 at 11:12 AM, Arnd Bergmann wrote:
> > > I agree for the case you are describing here. From what I understood
> > > from Rob was that he is looking at somet
--
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/20150203/98cb50dd/attachment.html>
On Tue, Feb 03, 2015 at 10:15:47PM +0300, Andrey Skvortsov wrote:
> Hi,
>
> tested next-20150202. System boots, but graphic output is broken (empty black
> screen).
> Booted five times the same kernel, always got the same result. The system
> works with 3.19-rc7.
Those two warnings are more or
On 02/03/2015 06:45 PM, Laurent Pinchart wrote:
> Hi Chen,
>
> Thank you for the patch.
>
> On Sunday 01 February 2015 22:08:33 Chen Gang S wrote:
>> DRM_GEM_CMA_HELPER is depend on HAVE_DMA_ATTRS, or it will break the
>> building. The related error (with allmodconfig under xtensa):
>>
>> CC
This patch makes the fsl,data-width and fsl,data-mapping device tree
properties optional if a panel is connected to the ldb output port
via the of_graph bindings. The data mapping is determined from the
display_info.bus_format field provided by the panel.
Signed-off-by: Philipp Zabel
---
drivers
The LDB driver changes the attached display interface's input clock mux
to the LDB_DI clock reference. Change it back again when disabling the
LVDS display. Changing back to the PLL5 for example allows to configure
the same DI for HDMI output later.
Signed-off-by: Philipp Zabel
---
drivers/gpu/d
This patch allows to optionally attach the lvds-channel to a panel
supported by a drm_panel driver using of-graph bindings, instead of
supplying the modes via display-timings in the device tree.
This depends on of_graph_get_port_by_id and uses the OF graph to
link the optional DRM panel to the LDB
This patch consolidates the different interface_pix_fmt, pixel_fmt, pix_fmt,
and pixfmt variables to a common name "bus_format" wherever they describe the
pixel format on the bus between display controller and encoder hardware.
At the same time, it renames imx_drm_panel_format to imx_drm_set_bus_fo
imx-drm internally misused the V4L2_PIX_FMT constants, which are supposed to
describe the pixel format of frame buffers in memory, to describe the pixel
format on the bus between the display controller and the encoder hardware
instead. Now that MEDIA_BUS_FMT constants are available to drm drivers,
Commit 9e74d2926a28 ("staging: imx-drm: add LVDS666 support for parallel
display") describes a 24-bit bus format where three 6-bit components each
take the lower part of 8 bits with the two high bits zero padded. Add a
component-wise padded media bus format RGB666_1X24_CPADHI to support this
connec
This patch adds the media bus format for a 24-bit bus format with three
8-bit YUV components.
Signed-off-by: Philipp Zabel
Acked-by: Laurent Pinchart
---
Documentation/DocBook/media/v4l/subdev-formats.xml | 37 ++
include/uapi/linux/media-bus-format.h | 3 +-
2
This patch adds two more 24-bit RGB formats. BGR888 is more or less common,
GBR888 is used on the internal connection between the IPU display interface
and the TVE (VGA DAC) on i.MX53 SoCs.
Signed-off-by: Philipp Zabel
Acked-by: Laurent Pinchart
---
Documentation/DocBook/media/v4l/subdev-format
This patch adds three new RGB media bus formats that describe
18-bit or 24-bit samples transferred over an LVDS bus with three
or four differential data pairs, serialized into 7 time slots,
using standard SPWG/PSWG/VESA or JEIDA data ordering.
Signed-off-by: Philipp Zabel
Acked-by: Sakari Ailus
From: Boris Brezillion
Add RGB444_1X12 and RGB565_1X16 format definitions and update the
documentation.
Signed-off-by: Boris Brezillon
Acked-by: Mauro Carvalho Chehab
Acked-by: Sakari Ailus
Acked-by: Laurent Pinchart
Signed-off-by: Philipp Zabel
---
Changes since v1:
- Fixed constant value
Sorry about the noise, this time sent to the correct list:
Currently the imx-drm driver misuses the V4L2_PIX_FMT constants to describe the
pixel format on the parallel bus between display controllers and encoders. Now
that MEDIA_BUS_FMT is available, use that instead.
I'd like to get the V4L2 mai
Hi Thierry,
Am Dienstag, den 03.02.2015, 14:30 +0100 schrieb Thierry Reding:
> On Thu, Dec 11, 2014 at 06:32:44PM +0100, Philipp Zabel wrote:
> > Many panel data sheets additionally to typical values list allowed ranges
> > for
> > timings such as hsync/vsync lengths, porches, and the pixel clock
The commit [8975626ea35a: drm/cirrus: allow 32bpp framebuffers for
cirrus drm] broke X modesetting driver because cirrus driver still
provides the full list of modes up to 1280x1024 while the 32bpp can
support only up to 800x600.
We might be able to filter out the invalid modes in mode_valid
callb
On Tuesday 03 February 2015 11:22:01 Rob Clark wrote:
> On Tue, Feb 3, 2015 at 11:12 AM, Arnd Bergmann wrote:
> > I agree for the case you are describing here. From what I understood
> > from Rob was that he is looking at something more like:
> >
> > Fig 3
> > CPU--L1cache--L2cache--Memory--IOMMU-
From: Gustavo Padovan
exynos_disable_plane() is used only once now thus remove it and call
exynos_plane_dpms() directly.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exyn
From: Gustavo Padovan
Use the pipe var received instead of using always -1 as pipe value.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/
From: Gustavo Padovan
It is not used outside of the plane scope anymore.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 11 ++-
drivers/gpu/drm/exynos/exynos_drm_plane.h | 5 -
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/
From: Gustavo Padovan
Use drm_atomic_set_fb_for_plane() in the legacy page_flip path to keep
track of the framebuffer pointer and reference.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/exynos
From: Gustavo Padovan
Set CRTC, planes and connectors to use the default implementations from
the atomic helper library. The helpers will work to keep track of state
for each DRM object.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/bridge/ptn3460.c | 4
drivers/gpu/drm/
From: Gustavo Padovan
The new atomic infrastructure needs the .mode_set_nofb() callback to
update CRTC timings before setting any plane.
Signed-off-by: Gustavo Padovan
Conflicts:
drivers/gpu/drm/exynos/exynos_drm_crtc.c
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 55 +++
From: Gustavo Padovan
Add CRTC callbacks .atomic_begin() .atomic_flush(). On exynos they
unprotect the windows before the commit and protects it after based on
a plane mask tha store which plane will be updated.
For that we create two new exynos_crtc callbacks: .win_protect() and
.win_unprotect(
From: Gustavo Padovan
The atomic helper to disable planes also uses the optional
.atomic_disable() helper. The unique operation it does is calling
.win_disable()
exynos_drm_fb_get_buf_cnt() needs a fb check too to avoid a null pointer.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos
From: Gustavo Padovan
Rip out the check from exynos_update_plane() and create
exynos_check_plane() for the check phase enabling use to use
the atomic helpers to call our check and update phases when updating
planes.
Update all users of exynos_update_plane() accordingly to call
exynos_check_plane
From: Daniel Kurtz
The 'mode' is the modeline information which specifies the ideal mode
requested by the mode set initiator (usually userspace).
The 'adjusted_mode' is the actual hardware mode after all the crtcs
and encoders have had a chance to "fix it up".
The adjusted_mode starts as a dupli
From: Gustavo Padovan
struct {fimd,mixer,vidi}_win_data was just keeping the same data
as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
directly.
It changes how planes are created and remove .win_mode_set() callback
that was only filling all *_win_data structs.
Signed-off
From: Gustavo Padovan
These functions were already removed by previous cleanup work, but these
ones were left behind.
Signed-off-by: Gustavo Padovan
Acked-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/e
From: Gustavo Padovan
exynos_plane_dpms(DRM_MODE_DPMS_ON) calls the win_enable()'s callback
from the underlying layer. However neither one of these layers implement
win_enable() - FIMD, Mixer and VIDI. Thus the call to exynos_plane_dpms()
is pointless.
Signed-off-by: Gustavo Padovan
---
driver
From: Mandeep Singh Baines
The goal of the change is to make sure we send the vblank event on the
current vblank. My hope is to fix any races that might be causing flicker.
After this change I only see a flicker in the transition plymouth and
X11.
Simplified the code by tracking vblank events on
From: Gustavo Padovan
Hi,
This series clean ups a few more paths from exynos-drm with the most important
being the removal of the global page flip queue and the removal in driver
internal data (struct *_win_data) that was replicating plane data.
Following these patches comes the first step torw
On Tuesday 03 February 2015 15:54:04 Russell King - ARM Linux wrote:
> On Tue, Feb 03, 2015 at 04:31:13PM +0100, Arnd Bergmann wrote:
> > The dma_map_* interfaces assign the virtual addresses internally,
> > using typically either a global address space for all devices, or one
> > address space per
usty/+bug/1355562
--
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/20150203/f77155e2/attachment.html>
On Tue, Feb 03, 2015 at 11:22:01AM -0500, Rob Clark wrote:
> On Tue, Feb 3, 2015 at 11:12 AM, Arnd Bergmann wrote:
> > I agree for the case you are describing here. From what I understood
> > from Rob was that he is looking at something more like:
> >
> > Fig 3
> > CPU--L1cache--L2cache--Memory--I
On Tue, Feb 03, 2015 at 05:12:40PM +0100, Arnd Bergmann wrote:
> On Tuesday 03 February 2015 15:54:04 Russell King - ARM Linux wrote:
> > On Tue, Feb 03, 2015 at 04:31:13PM +0100, Arnd Bergmann wrote:
> > > The dma_map_* interfaces assign the virtual addresses internally,
> > > using typically eith
So this has been merged originally in
commit 83052d4d5cd518332440bb4ee63d68bb5f744e0f
Author: Seung-Woo Kim
Date: Thu Dec 15 15:40:55 2011 +0900
drm: Add multi buffer plane pixel formats
which hasn't seen a lot of review really. The problem is that it's not
a real pixel format, but just a
This commits breaks a working configuration here - reverting it let both
version 3.18.4 and 3.18.5 working fine again at a hardened Gentoo Linux
commit ddf6f9a4c9fb1c72ea2e8d196c9a580a8e914dbd
Author: Dave Airlie
Date: Mon Dec 8 13:23:37 2014 +1000
drm/i915: resume MST after reading back
ed
> + * below. The lower 56 bits are assigned as vendor sees fit.
> + */
> +
> +/* Vendor Ids: */
> +#define DRM_FORMAT_MOD_NONE 0
> +#define DRM_FORMAT_MOD_VENDOR_INTEL 0x01
> +#define DRM_FORMAT_MOD_VENDOR_AMD 0x02
> +#define DRM_FORMAT_MOD_VENDOR_NV 0x03
On Tuesday 03 February 2015 15:22:05 Russell King - ARM Linux wrote:
> On Tue, Feb 03, 2015 at 03:52:48PM +0100, Arnd Bergmann wrote:
> > On Tuesday 03 February 2015 14:41:09 Russell King - ARM Linux wrote:
> > > I'd go as far as saying that the "DMA API on top of IOMMU" is more
> > > intended to b
dri-devel/attachments/20150203/ae3a0df0/attachment.html>
olved.
--
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/20150203/79effc58/attachment.html>
On Tue, Feb 03, 2015 at 04:31:13PM +0100, Arnd Bergmann wrote:
> On Tuesday 03 February 2015 15:22:05 Russell King - ARM Linux wrote:
> > Don't we already have those in the DMA API? dma_sync_*() ?
> >
> > dma_map_sg() - sets up the system MMU and deals with initial cache
> > coherency handling. D
On Thu, 29 Jan 2015 15:40:33 -0800
Linus Torvalds wrote:
> On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie wrote:
> >
> > Linus, this came up a while back I finally got some confirmation
> > that it fixes those servers.
>
> I'm certainly ok with this. which way should it go in? The users are:
>
>
On Tuesday 03 February 2015 14:41:09 Russell King - ARM Linux wrote:
> On Tue, Feb 03, 2015 at 03:17:27PM +0100, Arnd Bergmann wrote:
> > On Tuesday 03 February 2015 09:04:03 Rob Clark wrote:
> > > Since I'm stuck w/ an iommu, instead of built in mmu, my plan was to
> > > drop use of dma-mapping en
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/cbbe19b7/attachment.html>
On Tue, Feb 03, 2015 at 03:52:48PM +0100, Arnd Bergmann wrote:
> On Tuesday 03 February 2015 14:41:09 Russell King - ARM Linux wrote:
> > I'd go as far as saying that the "DMA API on top of IOMMU" is more
> > intended to be for a system IOMMU for the bus in question, rather
> > than a device-level
On Tuesday 03 February 2015 09:04:03 Rob Clark wrote:
> On Tue, Feb 3, 2015 at 2:48 AM, Daniel Vetter wrote:
> > On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
> >> On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter wrote:
> >> >> My initial thought is for dma-buf to not try to prevent so
l driver
that I reviewed earlier.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/d0edcc9d/attachment-0001.sig>
On Tue, Feb 03, 2015 at 09:44:57AM -0500, Rob Clark wrote:
> On Tue, Feb 3, 2015 at 9:37 AM, Russell King - ARM Linux
> wrote:
> > On Tue, Feb 03, 2015 at 09:04:03AM -0500, Rob Clark wrote:
> >> Since I'm stuck w/ an iommu, instead of built in mmu, my plan was to
> >> drop use of dma-mapping entir
This sets up the blending equation in the following way:
out = src * src_alpha + dst * (1 - src_alpha)
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 4
exynos/exynos_fimg2d.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
in
Register defines all use uppercase hex codes.
Signed-off-by: Tobias Jakobi
---
exynos/fimg2d_reg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/exynos/fimg2d_reg.h b/exynos/fimg2d_reg.h
index 5782488..07dd634 100644
--- a/exynos/fimg2d_reg.h
+++ b/exynos/fimg2d_reg.h
@@ -1
The coefficient mode enables use of global color, not alpha.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/exynos/exynos_fimg2d.h b/exynos/exynos_fimg2d.h
index bd116cf..78cff47 100644
--- a/exynos/exynos_fimg2d.h
+++
The reason for this change is to let userspace use the header.
Currently 'make install' does not install it.
Signed-off-by: Tobias Jakobi
---
exynos/Makefile.am | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/exynos/Makefile.am b/exynos/Makefile.am
index 1715a85..35bc71f 10
Signed-off-by: Tobias Jakobi
---
exynos/Makefile.am| 2 +-
exynos/exynos_fimg2d.c| 2 +-
exynos/exynos_fimg2d.h| 328 ++
exynos/fimg2d.h | 328 --
tests/exynos/exy
Check for a useable connector and also if the resolution is sane
(width and height are both non-zero).
Signed-off-by: Tobias Jakobi
---
tests/exynos/exynos_fimg2d_test.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/tests/exynos/exynos_fimg2d_test.c
b/tests/
Keeps the code cleaner, since the structs have to be initialized
once anyway.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c| 4 +---
tests/exynos/exynos_fimg2d_test.c | 15 ---
2 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/exynos/exynos_fimg2d
In almost all functions the base address register is written, so it
makes sense to have a helper function for this.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 87 +++---
1 file changed, 33 insertions(+), 54 deletions(-)
diff --git a/exy
This is useful when the default repeat mode, which is 'repeat'
produces artifacts at the borders of the copied image.
Choose the 'pad' mode to make use of the color of the destination
image.
In my usage case the destination is the framebuffer, which is
solid filled with a background color. Scaling
Currently getchar() is used to pause execution after each test.
The user isn't informed if one is supposed to do anything for
the tests to continue, so print a simple message to make this
more clear.
Signed-off-by: Tobias Jakobi
---
tests/exynos/exynos_fimg2d_test.c | 20
1
This is a combination of g2d_copy_with_scale and g2d_scale.
It is a pretty common operation to scale one buffer and then
blend it on top of another, so provide a direct way to that
operation.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 129 ++
The blend test uses the userptr functionality of exynos-drm, which
is currently not safe to use. If the kernel hasn't been build with
exynos-iommu support, then the blend test is going to produce (kernel)
memory corruption, eventually leading to a system crash.
Disable the test for now, until the
No functional changes.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c| 8
tests/exynos/exynos_fimg2d_test.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index d22c893..e7b00b1 100644
--- a/e
This also avoids the floating point conversion steps and just
uses pure integer arithmetic.
Since the G2D hardware scaling approach is a bit unintuitive,
document it in the function as well.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 19 ++-
exynos/fimg2d.h
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
---
tests/exynos/exynos_fimg2d_test.c | 117 +++
Hello,
here are some miscellaneous improvements (small features, bugfixes, spelling
fixes, etc.) for the exynos component of libdrm. The general idea is to let
userspace use the G2D engine functionality more
efficiently.
If someone is interested in an application that actually makes use of thi
On Tue, Feb 03, 2015 at 03:17:27PM +0100, Arnd Bergmann wrote:
> On Tuesday 03 February 2015 09:04:03 Rob Clark wrote:
> > Since I'm stuck w/ an iommu, instead of built in mmu, my plan was to
> > drop use of dma-mapping entirely (incl the current call to dma_map_sg,
> > which I just need until we c
On 1 February 2015 at 01:03, CodeSwim OS Development
wrote:
> I'm trying to build libdrm and have an issue when I gmake after
> configuring. Steps to reproduce:
>
> # uname -a
> SunOS omnios 5.11 omnios-10b9c79 i86pc i386 i86pc
>
Where can one get a copy of OmniOS ? Free of charge of course :-P
B
On Tue, Feb 03, 2015 at 09:04:03AM -0500, Rob Clark wrote:
> Since I'm stuck w/ an iommu, instead of built in mmu, my plan was to
> drop use of dma-mapping entirely (incl the current call to dma_map_sg,
> which I just need until we can use drm_cflush on arm), and
> attach/detach iommu domains direc
On Tue, Feb 03, 2015 at 02:28:26PM +0100, Christian Gmeiner wrote:
> 2015-02-03 13:28 GMT+01:00 Russell King - ARM Linux arm.linux.org.uk>:
> > What I've found with *my* etnaviv drm implementation (not Christian's - I
> > found it impossible to work with Christian, especially with the endless
> >
nt was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/23f05c0b/attachment.sig>
Hi,
On 02/02/2015 11:26 PM, Gustavo Padovan wrote:
> From: Prathyush K
>
> When VPLL clock of less than 140 MHz was used and all the three clocks -
> hdmiphy, hdmi, sclk_hdmi are disabled, the system hangs during S2R when
> HDMI is connected. Since we want to use a vpll clock of 70.5 MHz, we
> c
2015-02-03 13:28 GMT+01:00 Russell King - ARM Linux :
> On Tue, Feb 03, 2015 at 08:48:56AM +0100, Daniel Vetter wrote:
>> On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
>> > On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter wrote:
>> > >> My initial thought is for dma-buf to not try to pr
2015-02-03 Daniel Vetter :
> So this has been merged originally in
>
> commit 83052d4d5cd518332440bb4ee63d68bb5f744e0f
> Author: Seung-Woo Kim
> Date: Thu Dec 15 15:40:55 2011 +0900
>
> drm: Add multi buffer plane pixel formats
>
> which hasn't seen a lot of review really. The problem is
move = crystalcove_panel_remove,
> + .driver = {
> + .name = "crystal_cove_panel",
> + },
> +};
> +
> +module_platform_driver(crystalcove_panel_driver);
What's also weird here is that you claim this to be a DSI panel, yet you
use a platform driver. The right thing to do would be to instantiate the
device as mipi_dsi_device, with the DSI controller being the parent.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/b3b71794/attachment.sig>
d...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/ae9ddb19/attachment-0001.sig>
a static one.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/91aced16/attachment.sig>
On Tue, Feb 03, 2015 at 12:28:14PM +, Russell King - ARM Linux wrote:
> On Tue, Feb 03, 2015 at 08:48:56AM +0100, Daniel Vetter wrote:
> > On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
> > > On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter wrote:
> > > >> My initial thought is for d
're
supposed to wait for the display driver to tell you to turn it on via
->prepare() and ->enable().
> +
> + drm_panel_init(&ctx->panel);
> + ctx->panel.dev = dev;
> + ctx->panel.funcs = &s6e3ha2_drm_funcs;
I don't see a use for the _drm in here.
> +static struct of_device_id s6e3ha2_of_match[] = {
static const, please.
> + { .compatible = "samsung,s6e3ha2" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, s6e3ha2_of_match);
> +
> +static struct mipi_dsi_driver s6e3ha2_driver = {
> + .probe = s6e3ha2_probe,
> + .remove = s6e3ha2_remove,
> + .driver = {
> + .name = "panel_s6e3ha2",
Please use a - instead of an _ here, for consistency with other drivers.
> + .owner = THIS_MODULE,
No need for this anymore.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/e5c8aa2f/attachment.sig>
Hi Dave,
Two more fixes for 3.20 amdkfd code:
- Fixing accounting of active queues
- Preserving a register internal state
Thanks,
Oded
The following changes since commit e4bf44b3b558742fb7c58b4d34e206c8942f07e6:
drm/modes: Print the mode status in human readable form (2015-02-03 11:
Hi Daniel,
Thank you for the patch.
On Tuesday 03 February 2015 11:30:11 Daniel Vetter wrote:
> At driver load we need to tell the vblank code about the state of the
> pipes, so that the logic around reject vblank_get when the pipe is off
> works correctly.
>
> Thus far i915 used drm_vblank_off,
des them that needs to free them (in ->remove()).
It's not a completely perfect solution yet, but with the registry patch
that I proposed a while back all the remaining issues should go away.
Now if I could get anybody to look at that patch...
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/443d0324/attachment.sig>
Marek Szyprowski wrote:
>
> Hi all,
>
> This is yet another update on patchset, which enables HDMI support for
> Exynos based platforms.
>
> Beside DTS changes, this patchset adds parent domain support for Exynos
> PM domains and add support for 'hdmi' clock directly to Exynos DRM mixer
> driver
On Tue, Feb 03, 2015 at 01:31:34PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Tuesday 03 February 2015 11:30:11 Daniel Vetter wrote:
> > At driver load we need to tell the vblank code about the state of the
> > pipes, so that the logic around reject vblank_get
Hi Chen,
Thank you for the patch.
On Sunday 01 February 2015 22:08:33 Chen Gang S wrote:
> DRM_GEM_CMA_HELPER is depend on HAVE_DMA_ATTRS, or it will break the
> building. The related error (with allmodconfig under xtensa):
>
> CC [M] drivers/gpu/drm/drm_gem_cma_helper.o
> drivers/gpu/drm
1 - 100 of 152 matches
Mail list logo
