Hi Russell,
Time for me to jump in. The more, the merrier I suppose.
On Wednesday 26 February 2014 22:19:39 Russell King - ARM Linux wrote:
> On Wed, Feb 26, 2014 at 10:00:25PM +0100, Guennadi Liakhovetski wrote:
> > Hi Russell
> >
> > (I suspect this my email will be rejected by ALKML too like
On Thursday 27 February 2014 16:10:41 Tomi Valkeinen wrote:
> On 27/02/14 15:43, Russell King - ARM Linux wrote:
> > That may be - but the problem with CDF solving this problem is that it's
> > wrong. It's fixing what is in actual fact a *generic* problem in a much
> > too specific way. To put it
Hi
On Thu, Mar 6, 2014 at 10:56 PM, Bruno Pr?mont
wrote:
> Hi David,
>
> On Thu, 06 March 2014 David Herrmann wrote:
>> On modern linux user-space, the VT subsystem is no longer needed for
>> system consoles. Although most DEs will fail if VTs are disabled, there
>> are several gfx-systems that
Hi Linus,
mostly intel and radeon fixes, one tda998x, one kconfig dep fix and two
more MAINTAINERS updates,
All pretty run of the mill for this stage,
Dave.
The following changes since commit 0414855fdc4a40da05221fc6062cccbc0c30f169:
Linux 3.14-rc5 (2014-03-02 18:56:16 -0800)
are availabl
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/7d25574c/attachment.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/4627bf6d/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/ab1fcd6a/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #50 from Tobias Droste ---
Unfortunately not here.
It's still:
# echo auto > power_dpm_force_performance_level
bash: echo: write error: Invalid argument
# echo low > power_dpm_force_performance_level
bash: echo: write error: Invalid a
Hi David,
On Fri, 7 Mar 2014 00:41:05 +0100 David Herrmann wrote:
> On Thu, Mar 6, 2014 at 10:56 PM, Bruno Pr?mont wrote:
> > On Thu, 06 March 2014 David Herrmann wrote:
> >> On modern linux user-space, the VT subsystem is no longer needed for
> >> system consoles. Although most DEs will fail if V
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #51 from Alex Belykh ---
And not here. Applying this patch on top of latest drm-next
(786a7828bc74b9b1466e83abb200b75f80f94121) resulted in the same kind of lockups
ending with reboot.
--
You are receiving this mail because:
You are
Hi
>> I don't think it makes sense to modify drm_log_ensure_size(). I mean,
>> the worst that can happen is that the *text*-backlog is twice as big
>> as required. But if you have a high-dpi display, you already require
>> like 10x as much space for each framebuffer than for the entire
>> log-buff
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/ff92771c/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/69271d0e/attachment.html>
On Thu, 06 Mar 2014, Xiubo Li wrote:
> Since we cannot make sure the 'max_conn_count' will always be none
> zero from the users, and then if max_conn_count equals to zero, the
> kcalloc() will return ZERO_SIZE_PTR, which equals to ((void *)16).
>
> So this patch fix this via doing the zero pionter
On Thu, Mar 06, 2014 at 11:42:13AM +0530, Rahul Sharma wrote:
> Add generic KMS blob properties to core drm framework. These
> are writable blob properties which can be used to set Image
> Enhancement parameters. The properties which are added here
> are meant for color reproduction, color saturati
On 03/05/2014 03:56 AM, Inki Dae wrote:
> Hi Andrzej,
>
> Thanks for your contributions.
>
> 2014-02-12 20:31 GMT+09:00 Andrzej Hajda :
>> Hi,
>>
>> This patchset adds drivers and bindings to the following devices:
>> - Exynos DSI master,
>> - S6E8AA0 DSI panel,
>> - TC358764 DSI/LVDS bridge,
>> -
Hi Daniel,
On 7 March 2014 14:06, Daniel Vetter wrote:
> On Thu, Mar 06, 2014 at 11:42:13AM +0530, Rahul Sharma wrote:
>> Add generic KMS blob properties to core drm framework. These
>> are writable blob properties which can be used to set Image
>> Enhancement parameters. The properties which are
Hi Inki,
Thanks for the review.
On 03/05/2014 07:46 AM, Inki Dae wrote:
> 2014-02-12 20:31 GMT+09:00 Andrzej Hajda :
>> The patch adds driver for Toshiba DSI/LVDS TC358764 bridge.
>> Driver registers itself as mipi_dsi_driver. It is exposed to the
>> system via drm_panel interface, it uses also d
On Sun, Mar 2, 2014 at 8:09 PM, Laurent Pinchart
wrote:
> The GEM CMA helpers uses a custom mmap implementation based on
> remap_pfn_range(). While this works when the buffer DMA and physical
> addresses are identical, it fails to take IOMMU into account and tries
> to mmap the buffer to userspace
On 03/05/2014 06:56 AM, Inki Dae wrote:
> 2014-02-12 20:31 GMT+09:00 Andrzej Hajda :
>> The patch adds DT bindings for Exynos DSI Master. DSIM follows rules
>> for DSI bus host bindings [1].
>> Properties describes its resources: memory, interrupt, clocks,
>> phy, regulators and frequencies of cloc
op 07-03-14 12:18, Sebastian Andrzej Siewior schreef:
> * Fernando Lopez-Lezcano | 2014-03-01 17:48:29 [-0800]:
>
>> On 02/23/2014 10:47 AM, Sebastian Andrzej Siewior wrote:
>>> Dear RT folks!
>>>
>>> I'm pleased to announce the v3.12.12-rt19 patch set.
>> Just hit this Oops in my desktop at home:
On 03/05/2014 01:06 PM, Inki Dae wrote:
> Sorry for interrupting,
>
>
> 2014-03-04 21:00 GMT+09:00 Andrzej Hajda :
>> On 02/28/2014 02:39 PM, Tomi Valkeinen wrote:
>>> On 28/02/14 15:31, Tomi Valkeinen wrote:
>>>
Compared to what I've done on OMAP, you don't seem to specify the video
inpu
Hi
On Fri, Mar 7, 2014 at 1:44 PM, Tomi Valkeinen wrote:
> On 06/03/14 14:16, David Herrmann wrote:
>> Hi Tomi
>>
>> On Mon, Mar 3, 2014 at 12:22 PM, Tomi Valkeinen
>> wrote:
>>> On 03/03/14 13:09, David Herrmann wrote:
>>>
> What do you think, would it be possible to keep the sysfb stuff i
On 03/07/2014 01:32 PM, Tomi Valkeinen wrote:
> On 07/03/14 14:22, Andrzej Hajda wrote:
>
>> I think we should even extend the bindings to fimd:
>> dsi {
>> port at 0 {
>> dsi_0: endpoint {
>> remote-endpoint=<&fimd_0>;
>> }
>> }
>> port at 1 {
>> dsi
Paul Bolle schreef op vr 10-01-2014 om 11:37 [+0100]:
> Building ramnve0.o triggers a GCC warning on 32 bits x86:
> drivers/gpu/drm/nouveau/core/subdev/fb/ramnve0.c: In function
> 'nve0_ram_ctor':
> drivers/gpu/drm/nouveau/core/subdev/fb/ramnve0.c:1253:1: warning: the
> frame size of 1496
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140307/b8397aee/attachment-0001.pgp>
On Fri, Mar 07, 2014 at 02:42:56PM +0100, Toralf F?rster wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> At a ThinkPad T420 with i915 and kernel 3.12.13 my watchdog scripts
> told me :
>
> Mar 6 18:45:02 n22 kernel: [drm] stuck on render ring
> Mar 6 18:45:02 n22 kernel: [drm]
On Fri, Mar 07, 2014 at 02:59:23PM +0100, Toralf F?rster wrote:
> ick, attached full compressed file
It's the infamous https://bugs.freedesktop.org/show_bug.cgi?id=54226
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Hi Tomi
On Fri, Mar 7, 2014 at 2:52 PM, Tomi Valkeinen wrote:
> On 07/03/14 15:05, David Herrmann wrote:
>
>> If you can take these two patches, that's fine. They're not strictly
>> needed by the series and I'd be happy to see them upstream. The other
>> sysfb patches should be merged together, s
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/3dcbcbee/attachment.html>
[ccing dri-devel so other people can see what we're cooking...]
On Fri, Mar 07, 2014 at 01:49:18PM +, Goel, Akash wrote:
> > In my ideal solution the panel fitter output will be hdisplay/vdisplay
> > +/- the border (depending on which way we define it), and the panel
> > +fitter
> > input si
--
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/20140307/ed7ec680/attachment.html>
Hi,
Am Donnerstag, den 06.03.2014, 10:52 +0200 schrieb Tomi Valkeinen:
> On 06/03/14 10:39, Geert Uytterhoeven wrote:
> > On Wed, Mar 5, 2014 at 9:41 AM, Tomi Valkeinen
> > wrote:
> >> On 28/02/14 18:23, Russell King - ARM Linux wrote:
> >>
> >>> That's rather a lot of compatible strings. Anoth
On 03/07/2014 02:28 PM, Tomi Valkeinen wrote:
(...)
> There are many possible connections from FIMD, some of them:
> FIMD ---> RGB panel, external
> FIMD ---> DSI, on SoC
> FIMD ---> eDP, on SoC
> FIMD ---> ImageEnhacer, on SoC
> This sounds similar to OMAP, at least roughly.
>
>> In the first case
On Thu, Mar 06, 2014 at 02:54:40PM +0100, Philipp Zabel wrote:
> @@ -566,9 +566,18 @@ static int imx_ldb_bind(struct device *dev, struct
> device *master, void *data)
> return -EINVAL;
> }
>
> - panel_node = of_parse_phandle(child, "fsl,panel", 0);
On Thu, Mar 06, 2014 at 02:54:39PM +0100, Philipp Zabel wrote:
> This patch allows to optionally attach the lvds-channel to a panel
> supported by a drm_panel driver instead of supplying the modes via
> device tree.
Hmm, I think something may be missing in this patch... you're introducing
calls in
Hi Russell,
Am Freitag, den 07.03.2014, 17:22 + schrieb Russell King - ARM
Linux:
> On Thu, Mar 06, 2014 at 02:54:39PM +0100, Philipp Zabel wrote:
> > This patch allows to optionally attach the lvds-channel to a panel
> > supported by a drm_panel driver instead of supplying the modes via
> > d
On Wed, Mar 05, 2014 at 10:20:51AM +0100, Philipp Zabel wrote:
> Hi,
>
> this latest version of the imx-drm DT binding patches applies
> on top of staging-next and also depends on the OF graph binding
> patchset that moves the v4l2_of helpers to drivers/of.
> Currently, the two patchsets are also
https://bugzilla.kernel.org/show_bug.cgi?id=68571
--- Comment #34 from Mihai Coman ---
Is there a compiled kernel available for ubuntu that includes this patch?
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Fri, Mar 07, 2014 at 05:56:12PM +, Russell King - ARM Linux wrote:
> On Wed, Mar 05, 2014 at 10:20:51AM +0100, Philipp Zabel wrote:
> > Hi,
> >
> > this latest version of the imx-drm DT binding patches applies
> > on top of staging-next and also depends on the OF graph binding
> > patchset
[Added Shawn to Cc:]
On Fri, Mar 7, 2014 at 7:28 PM, Greg Kroah-Hartman
wrote:
> On Fri, Mar 07, 2014 at 05:56:12PM +, Russell King - ARM Linux wrote:
>> On Wed, Mar 05, 2014 at 10:20:51AM +0100, Philipp Zabel wrote:
>> > Hi,
>> >
>> > this latest version of the imx-drm DT binding patches app
On Fri, Mar 07, 2014 at 07:57:51PM +0100, Philipp Zabel wrote:
> [Added Shawn to Cc:]
>
> On Fri, Mar 7, 2014 at 7:28 PM, Greg Kroah-Hartman
> wrote:
> > On Fri, Mar 07, 2014 at 05:56:12PM +, Russell King - ARM Linux wrote:
> >> On Wed, Mar 05, 2014 at 10:20:51AM +0100, Philipp Zabel wrote:
>
* Fernando Lopez-Lezcano | 2014-03-01 17:48:29 [-0800]:
>On 02/23/2014 10:47 AM, Sebastian Andrzej Siewior wrote:
>>Dear RT folks!
>>
>>I'm pleased to announce the v3.12.12-rt19 patch set.
>
>Just hit this Oops in my desktop at home:
>
>[22328.388996] BUG: unable to handle kernel NULL pointer dere
ponents were truly independent IPs on the SoC, then
using ports might make things easier.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/f540b7b8/attachment.pgp>
> - The renderer supports *any* RGB target, from 8bit to 32bit with
>big-endian and little-endian support. The related pixel-renderer will
>probably never win a beauty-contest, but it works.. Again, who cares
>for debug-log rendering speed?
Debug log writing performance is extremely i
* Maarten Lankhorst | 2014-03-07 12:36:13 [+0100]:
>>I can't find any kind of locking so my question is what ensures that chan is
>>not set to NULL between nouveau_fence_done() and
>>nouveau_fence_wait_uevent()? There are just a few opcodes in between but
>>nothing that pauses nouveau_fence_signal
then send the reorg series a bit later and
offer a conflict resolution that solves the conflicts for both series.
That way this series doesn't get delayed needlessly in the case that
Linus rejects the reorg series.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/cf6449eb/attachment-0001.pgp>
non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/490977c1/attachment.pgp>
river will reserve the DSI master for itself,
and the DSI master will reserve the FIMD for itself, presuming FIMD has
not already been reserved. When the DSI panel is disabled, FIMD is freed.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/2e4c70e6/attachment.pgp>
bdev in any way,
right? That makes me think drivers/video/.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/6207b43b/attachment.pgp>
some properties in the endpoint node.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140307/94af5287/attachment.pgp>
> I mean what's there in the mode structure. So if we define the border as
> something that reduces hactive/vactice, we'd program the pfit output size as
> hactive-left_border-right_border x vactive-top_border-bottom_border.
> We can't change the already existing structure, so if we want to upda
The DRM core currently only tracks "overlay"-style planes. Start
refactoring the plane handling to allow other plane types (primary and
cursor) to also be placed on the DRM plane list.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_crtc.c | 21 -
drivers/gpu/drm/drm_
Before we add additional types of planes to the DRM plane list, ensure
that existing loops over all planes continue to operate only on
"overlay" planes and ignore primary & cursor planes.
Cc: Intel Graphics Development
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 6 +
Add primary plane as a parameter to drm_crtc_init() and update all
existing DRM drivers to use a helper-provided primary plane.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/armada/armada_crtc.c | 4 +++-
drivers/gpu/drm/ast/ast_mode.c | 4 +++-
drivers/gpu/drm/bochs/bochs_kms.
Intel hardware allows the primary plane to be disabled independently of
the CRTC. Provide custom primary plane handling to allow this.
Cc: Intel Graphics Development
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 132 ++-
drivers/gpu/drm/i9
Userspace clients which wish to receive all DRM planes (primary and
cursor planes in addition to the traditional overlay planes) may set the
DRM_CLIENT_CAP_UNIVERSAL_PLANES capability.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_crtc.c | 20 +++-
drivers/gpu/drm/drm_ioctl.
Before we add additional types of planes to the DRM plane list, ensure
that existing loops over all planes continue to operate only on
"overlay" planes and ignore primary & cursor planes.
Cc: Inki Dae
Signed-off-by: Matt Roper
---
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 6 ++
1 file c
Add a plane type property to allow userspace to distinguish plane types.
The type of the plane will now be established at drm_plane_init() time
(replacing the 'priv' parameter previously used).
Signed-off-by: Matt Roper
---
drivers/gpu/drm/armada/armada_overlay.c| 3 +-
drivers/gpu/drm/drm_
The name 'update_plane' was used both for the primary plane functions in
intel_display.c and the sprite/overlay functions in intel_sprite.c.
Rename the primary plane functions to 'update_primary_plane' to avoid
confusion.
On a similar note, intel_display.c already had a function called
intel_disab
Now that CRTC's have a primary plane, there's no need to track the
framebuffer in the CRTC. Replace all references to the CRTC fb
with the primary plane's fb.
Also note that this simplifies framebuffer removal slightly; we no
longer need to scan all CRTC's and disable the ones that were using the
When we expose non-overlay planes to userspace, they will become
accessible via standard userspace plane API's. We should be able to
handle the standard plane operations against primary planes in a generic
way via the page flip handler and modeset handler.
Drivers that can program primary planes
One of the stepping stones on the way to atomic/nuclear operation is to expose
all types of hardware planes to userspace via a consistent interface. Until
now, the DRM plane interface has only operated on planes that drivers consider
"overlay" or "sprite" planes; primary planes were simply represe
On Fri, Mar 07, 2014 at 03:50:54PM +0530, Rahul Sharma wrote:
> Hi Daniel,
>
> On 7 March 2014 14:06, Daniel Vetter wrote:
> > On Thu, Mar 06, 2014 at 11:42:13AM +0530, Rahul Sharma wrote:
> >> Add generic KMS blob properties to core drm framework. These
> >> are writable blob properties which ca
64 matches
Mail list logo
