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 it
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 better,
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
> ---
>
> v2: fixed subject line
> v3: fixed patch description as recommended by Dan Carpenter
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
>>> ---
>>>
>>> v2: fixed subject line
>>>
Hi,
On 25/01/15 16:47, Nicholas Mc Guire wrote:
> Signed-off-by: Nicholas Mc Guire
> ---
>
> 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 x86_64_defconfig +
register a handler on panic_notifier_list: the handler can 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
>
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
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
> CONFIG_PREEMPT_VOL
On 28/02/14 12:19, Gerd Hoffmann wrote:
> On Fr, 2014-02-28 at 11:01 +0200, Tomi Valkeinen wrote:
>> 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 dri
On 24/02/14 15:17, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
> ---
> 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
> +++ b/drivers/hv/vmbu
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 sho
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
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 th
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 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:
>
> htt
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 propertie
On 02/10/13 14:55, Gerd Hoffmann wrote:
> This patch adds a pci stub driver to hyper-fb. The hyperv framebuffer
> driver will bind to the pci device then, so linux kernel and userspace
> know there is a proper kernel driver for the device active. lspci shows
> this for example:
>
> [root@dhcp231
18 matches
Mail list logo
