On 02/09/15 15:48, Sudip Mukherjee wrote:
> Now I am getting confused. :(
> Since this has already been merged I guess we need to maintain it now.
Oh, ok. I thought it was still in staging. I haven't been able to follow
the list properly lately...
Well, in theory we could still revert it, as
On 01/09/15 16:55, Sudip Mukherjee wrote:
> On Tue, Sep 01, 2015 at 04:27:24PM +0300, Tomi Valkeinen wrote:
>>
>>
>> On 18/07/15 07:08, Sudip Mukherjee wrote:
>>> Now since all cleanups are done and the code is ready to be merged lets
>>> move it out of
On 18/07/15 07:08, Sudip Mukherjee wrote:
> Now since all cleanups are done and the code is ready to be merged lets
> move it out of staging into fbdev location.
Have you considered writing a DRM driver for this? I'm not happy at all
adding new fbdev drivers, as the DRM framework is much
On 29/01/15 12:24, Nicholas Mc Guire wrote:
The return type of wait_for_completion_timeout is unsigned long not
int. This patch fixes up the declarations only.
Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
---
v2: fixed subject line
v3: fixed patch description as recommended by Dan
On 29/01/15 11:38, Nicholas Mc Guire wrote:
On Mon, 26 Jan 2015, Tomi Valkeinen wrote:
Hi,
On 25/01/15 16:47, Nicholas Mc Guire wrote:
Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
---
v2: fixed subject line
The return type of wait_for_completion_timeout is unsigned long not
int
Hi,
On 25/01/15 16:47, Nicholas Mc Guire wrote:
Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
---
v2: fixed subject line
The return type of wait_for_completion_timeout is unsigned long not
int. This patch fixes up the declarations only.
Patch was compile tested only for
notify
the VSC and switch the framebuffer driver to a synchronous mode, meaning
the VSC flushes any future framebuffer change to the VSP immediately.
v2: removed the MS-TFS line in the commit message
v3: remove some 'unlikely' markings
v4: avoid global variables as Tomi Valkeinen suggested
On 31/07/14 13:11, Dexuan Cui wrote:
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@ti.com]
Sent: Wednesday, July 30, 2014 22:24 PM
+static struct fb_info *hvfb_info;
Static variables like these are usually a no-no. This prevents you from
having multiple device
On 09/07/14 06:04, Dexuan Cui wrote:
Currently the VSC has no chance to notify the VSP of the dirty rectangle on VM
panic because the notification work is done in a workqueue, and in panic() the
kernel typically ends up in an infinite loop, and a typical kernel config has
On 26/02/14 12:51, Gerd Hoffmann wrote:
Hi,
This patch series adds support for uefi-based gen2 virtual machines
to the hyperv-fb driver. It depends on a few vmbus changes which are
staged in Greg's char-misc tree (and linux-next).
Depends how? Patches that depend on other patches should
On 24/02/14 15:17, Gerd Hoffmann wrote:
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
drivers/hv/vmbus_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index b37c91b..2352ae48 100644
--- a/drivers/hv/vmbus_drv.c
+++
On 25/02/14 16:23, Philipp Zabel wrote:
+Freescale i.MX DRM master device
+
+
+The freescale i.MX DRM master device is a virtual device needed to list all
+IPU or other display interface nodes that comprise the graphics subsystem.
+
+Required properties:
+-
On 27/02/14 13:56, Russell King - ARM Linux wrote:
Is there even need for such a master device? You can find all the
connected display devices from any single display device, by just
following the endpoint links.
Please read up on what has been discussed over previous years:
On 27/02/14 15:00, Russell King - ARM Linux wrote:
On Thu, Feb 27, 2014 at 02:06:25PM +0100, Philipp Zabel wrote:
For the i.MX6 display subsystem there is no clear single master device,
and the physical configuration changes across the SoC family. The
i.MX6Q/i.MX6D SoCs have two separate
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 another way, it's forcing everyone to fix
the same problem in their
On 27/02/14 18:54, Philipp Zabel wrote:
- One IPU enabled, one disabled: nothing special here, just set the
other IPU to status=disabled in the DT data. The driver for the
enabled IPU would register the required DRM entities.
that should work. Let the enabled IPU create the imx-drm platform
16 matches
Mail list logo