Re: [PATCH v2 1/3] staging: sm7xxfb: move sm712fb out of staging

2015-09-24 Thread Tomi Valkeinen
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

Re: [PATCH v2 1/3] staging: sm7xxfb: move sm712fb out of staging

2015-09-02 Thread Tomi Valkeinen
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

Re: [PATCH v2 1/3] staging: sm7xxfb: move sm712fb out of staging

2015-09-01 Thread Tomi Valkeinen
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

Re: [PATCH 2/3 v3] hyperv: hyperv_fb.c: match wait_for_completion_timeout return type

2015-03-10 Thread Tomi Valkeinen
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

Re: [PATCH 2/3 v2] hyperv: hyperv_fb.c: match wait_for_completion_timeout return type

2015-01-29 Thread Tomi Valkeinen
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

Re: [PATCH 2/3 v2] hyperv: hyperv_fb.c: match wait_for_completion_timeout return type

2015-01-26 Thread Tomi Valkeinen
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

Re: [PATCH v4] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic

2014-08-04 Thread Tomi Valkeinen
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

Re: [PATCH v3] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic

2014-07-31 Thread Tomi Valkeinen
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

Re: [PATCH v3] video: hyperv: hyperv_fb: refresh the VM screen by force on VM panic

2014-07-30 Thread Tomi Valkeinen
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

Re: [PATCH v5 0/2] hyperv-fb: add support for generation 2 virtual machines

2014-02-28 Thread Tomi Valkeinen
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

Re: [PATCH v3 1/4] vmbus: add missing breaks

2014-02-28 Thread Tomi Valkeinen
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 +++

Re: [RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings

2014-02-27 Thread Tomi Valkeinen
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: +-

Re: [RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings

2014-02-27 Thread Tomi Valkeinen
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:

Re: [RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings

2014-02-27 Thread Tomi Valkeinen
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

Re: [RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings

2014-02-27 Thread Tomi Valkeinen
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

Re: [RFC PATCH v4 3/8] staging: imx-drm: Document updated imx-drm device tree bindings

2014-02-27 Thread Tomi Valkeinen
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