* Re: [Xen-devel] [PATCH v3 1/2] xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v3).
From: David Vrabel @ 2014-01-02 15:09 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Fabio Fantoni, axboe, leosilva, linux-fbdev, dmitry.torokhov,
ian.campbell, stefano.stabellini, linux-pci, netdev, ashley,
tpmdd, linux-kernel, mail, tpmdd-devel, tomi.valkeinen,
david.vrabel, linux-input, bhelgaas, xen-devel, boris.ostrovsky,
plagnioj, peterhuewe
In-Reply-To: <20131231143258.GA3018@phenom.dumpdata.com>
On 31/12/13 14:32, Konrad Rzeszutek Wilk wrote:
>> That is because 'disks' is incorrect. It should have been 'ide-disks'
>>
>> [ 0.000000] unrecognised option 'disks' in parameter 'xen_emul_unplug'
>>
>> With the 'ide-disks' it should work. I will update the description to
>> mention 'ide-disks' instead of 'disks'. Thank you for finding this!
>>
>
> I've v4 with said update and will push it to Linus shortly.
>
> Thanks!
>
> P.S.
> Here is v4:
>
>>From 275a81e7496d3532e5b4752703c50a7c8355a6c7 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Tue, 26 Nov 2013 15:05:40 -0500
> Subject: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v4).
>
> The user has the option of disabling the platform driver:
> 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
>
> which is used to unplug the emulated drivers (IDE, Realtek 8169, etc)
> and allow the PV drivers to take over. If the user wishes
> to disable that they can set:
>
> xen_platform_pci=0
> (in the guest config file)
>
> or
> xen_emul_unplug=never
> (on the Linux command line)
>
> except it does not work properly. The PV drivers still try to
> load and since the Xen platform driver is not run - and it
> has not initialized the grant tables, most of the PV drivers
> stumble upon:
>
> input: Xen Virtual Keyboard as /devices/virtual/input/input5
> input: Xen Virtual Pointer as /devices/virtual/input/input6M
> ------------[ cut here ]------------
> kernel BUG at /home/konrad/ssd/konrad/linux/drivers/xen/grant-table.c:1206!
> invalid opcode: 0000 [#1] SMP
> Modules linked in: xen_kbdfront(+) xenfs xen_privcmd
> CPU: 6 PID: 1389 Comm: modprobe Not tainted 3.13.0-rc1upstream-00021-ga6c892b-dirty #1
> Hardware name: Xen HVM domU, BIOS 4.4-unstable 11/26/2013
> RIP: 0010:[<ffffffff813ddc40>] [<ffffffff813ddc40>] get_free_entries+0x2e0/0x300
> Call Trace:
> [<ffffffff8150d9a3>] ? evdev_connect+0x1e3/0x240
> [<ffffffff813ddd0e>] gnttab_grant_foreign_access+0x2e/0x70
> [<ffffffffa0010081>] xenkbd_connect_backend+0x41/0x290 [xen_kbdfront]
> [<ffffffffa0010a12>] xenkbd_probe+0x2f2/0x324 [xen_kbdfront]
> [<ffffffff813e5757>] xenbus_dev_probe+0x77/0x130
> [<ffffffff813e7217>] xenbus_frontend_dev_probe+0x47/0x50
> [<ffffffff8145e9a9>] driver_probe_device+0x89/0x230
> [<ffffffff8145ebeb>] __driver_attach+0x9b/0xa0
> [<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
> [<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
> [<ffffffff8145cf1c>] bus_for_each_dev+0x8c/0xb0
> [<ffffffff8145e7d9>] driver_attach+0x19/0x20
> [<ffffffff8145e260>] bus_add_driver+0x1a0/0x220
> [<ffffffff8145f1ff>] driver_register+0x5f/0xf0
> [<ffffffff813e55c5>] xenbus_register_driver_common+0x15/0x20
> [<ffffffff813e76b3>] xenbus_register_frontend+0x23/0x40
> [<ffffffffa0015000>] ? 0xffffffffa0014fff
> [<ffffffffa001502b>] xenkbd_init+0x2b/0x1000 [xen_kbdfront]
> [<ffffffff81002049>] do_one_initcall+0x49/0x170
>
> .. snip..
>
> which is hardly nice. This patch fixes this by having each
> PV driver check for:
> - if running in PV, then it is fine to execute (as that is their
> native environment).
> - if running in HVM, check if user wanted 'xen_emul_unplug=never',
> in which case bail out and don't load any PV drivers.
> - if running in HVM, and if PCI device 5853:0001 (xen_platform_pci)
> does not exist, then bail out and not load PV drivers.
> - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=ide-disks',
> then bail out for all PV devices _except_ the block one.
> Ditto for the network one ('nics').
> - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=unnecessary'
> then load block PV driver, and also setup the legacy IDE paths.
> In (v3) make it actually load PV drivers.
[...]
> --- a/arch/x86/xen/platform-pci-unplug.c
> +++ b/arch/x86/xen/platform-pci-unplug.c
> @@ -69,6 +69,80 @@ static int check_platform_magic(void)
> return 0;
> }
>
> +bool xen_has_pv_devices()
> +{
> + if (!xen_domain())
> + return false;
> +
> + /* PV domains always have them. */
> + if (xen_pv_domain())
> + return true;
> +
> + /* And user has xen_platform_pci=0 set in guest config as
> + * driver did not modify the value. */
> + if (xen_platform_pci_unplug = 0)
> + return false;
> +
> + if (xen_platform_pci_unplug & XEN_UNPLUG_NEVER)
> + return false;
> +
> + if (xen_platform_pci_unplug & XEN_UNPLUG_ALL)
> + return true;
> +
> + /* This is an odd one - we are going to run legacy
> + * and PV drivers at the same time. */
> + if (xen_platform_pci_unplug & XEN_UNPLUG_UNNECESSARY)
> + return true;
> +
> + /* And the caller has to follow with xen_pv_{disk,nic}_devices
> + * to be certain which driver can load. */
> + return false;
This may result in:
xen_has_pv_devices() = false
xen_has_pv_disk_devices() = true
which looks odd to me. Surely xen_has_pv_*_devices() is a subset of
xen_has_pv_devices()?
David
^ permalink raw reply
* Re: [Xen-devel] [PATCH v3 1/2] xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v3).
From: Konrad Rzeszutek Wilk @ 2014-01-02 19:16 UTC (permalink / raw)
To: David Vrabel
Cc: Fabio Fantoni, axboe, leosilva, linux-fbdev, dmitry.torokhov,
ian.campbell, stefano.stabellini, linux-pci, netdev, ashley,
tpmdd, linux-kernel, mail, tpmdd-devel, tomi.valkeinen,
linux-input, bhelgaas, xen-devel, boris.ostrovsky, plagnioj,
peterhuewe
In-Reply-To: <52C58138.1030301@citrix.com>
On Thu, Jan 02, 2014 at 03:09:44PM +0000, David Vrabel wrote:
> On 31/12/13 14:32, Konrad Rzeszutek Wilk wrote:
> >> That is because 'disks' is incorrect. It should have been 'ide-disks'
> >>
> >> [ 0.000000] unrecognised option 'disks' in parameter 'xen_emul_unplug'
> >>
> >> With the 'ide-disks' it should work. I will update the description to
> >> mention 'ide-disks' instead of 'disks'. Thank you for finding this!
> >>
> >
> > I've v4 with said update and will push it to Linus shortly.
> >
> > Thanks!
> >
> > P.S.
> > Here is v4:
> >
> >>From 275a81e7496d3532e5b4752703c50a7c8355a6c7 Mon Sep 17 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date: Tue, 26 Nov 2013 15:05:40 -0500
> > Subject: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v4).
> >
> > The user has the option of disabling the platform driver:
> > 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> >
> > which is used to unplug the emulated drivers (IDE, Realtek 8169, etc)
> > and allow the PV drivers to take over. If the user wishes
> > to disable that they can set:
> >
> > xen_platform_pci=0
> > (in the guest config file)
> >
> > or
> > xen_emul_unplug=never
> > (on the Linux command line)
> >
> > except it does not work properly. The PV drivers still try to
> > load and since the Xen platform driver is not run - and it
> > has not initialized the grant tables, most of the PV drivers
> > stumble upon:
> >
> > input: Xen Virtual Keyboard as /devices/virtual/input/input5
> > input: Xen Virtual Pointer as /devices/virtual/input/input6M
> > ------------[ cut here ]------------
> > kernel BUG at /home/konrad/ssd/konrad/linux/drivers/xen/grant-table.c:1206!
> > invalid opcode: 0000 [#1] SMP
> > Modules linked in: xen_kbdfront(+) xenfs xen_privcmd
> > CPU: 6 PID: 1389 Comm: modprobe Not tainted 3.13.0-rc1upstream-00021-ga6c892b-dirty #1
> > Hardware name: Xen HVM domU, BIOS 4.4-unstable 11/26/2013
> > RIP: 0010:[<ffffffff813ddc40>] [<ffffffff813ddc40>] get_free_entries+0x2e0/0x300
> > Call Trace:
> > [<ffffffff8150d9a3>] ? evdev_connect+0x1e3/0x240
> > [<ffffffff813ddd0e>] gnttab_grant_foreign_access+0x2e/0x70
> > [<ffffffffa0010081>] xenkbd_connect_backend+0x41/0x290 [xen_kbdfront]
> > [<ffffffffa0010a12>] xenkbd_probe+0x2f2/0x324 [xen_kbdfront]
> > [<ffffffff813e5757>] xenbus_dev_probe+0x77/0x130
> > [<ffffffff813e7217>] xenbus_frontend_dev_probe+0x47/0x50
> > [<ffffffff8145e9a9>] driver_probe_device+0x89/0x230
> > [<ffffffff8145ebeb>] __driver_attach+0x9b/0xa0
> > [<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
> > [<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
> > [<ffffffff8145cf1c>] bus_for_each_dev+0x8c/0xb0
> > [<ffffffff8145e7d9>] driver_attach+0x19/0x20
> > [<ffffffff8145e260>] bus_add_driver+0x1a0/0x220
> > [<ffffffff8145f1ff>] driver_register+0x5f/0xf0
> > [<ffffffff813e55c5>] xenbus_register_driver_common+0x15/0x20
> > [<ffffffff813e76b3>] xenbus_register_frontend+0x23/0x40
> > [<ffffffffa0015000>] ? 0xffffffffa0014fff
> > [<ffffffffa001502b>] xenkbd_init+0x2b/0x1000 [xen_kbdfront]
> > [<ffffffff81002049>] do_one_initcall+0x49/0x170
> >
> > .. snip..
> >
> > which is hardly nice. This patch fixes this by having each
> > PV driver check for:
> > - if running in PV, then it is fine to execute (as that is their
> > native environment).
> > - if running in HVM, check if user wanted 'xen_emul_unplug=never',
> > in which case bail out and don't load any PV drivers.
> > - if running in HVM, and if PCI device 5853:0001 (xen_platform_pci)
> > does not exist, then bail out and not load PV drivers.
> > - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=ide-disks',
> > then bail out for all PV devices _except_ the block one.
> > Ditto for the network one ('nics').
> > - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=unnecessary'
> > then load block PV driver, and also setup the legacy IDE paths.
> > In (v3) make it actually load PV drivers.
> [...]
> > --- a/arch/x86/xen/platform-pci-unplug.c
> > +++ b/arch/x86/xen/platform-pci-unplug.c
> > @@ -69,6 +69,80 @@ static int check_platform_magic(void)
> > return 0;
> > }
> >
> > +bool xen_has_pv_devices()
> > +{
> > + if (!xen_domain())
> > + return false;
> > +
> > + /* PV domains always have them. */
> > + if (xen_pv_domain())
> > + return true;
> > +
> > + /* And user has xen_platform_pci=0 set in guest config as
> > + * driver did not modify the value. */
> > + if (xen_platform_pci_unplug = 0)
> > + return false;
> > +
> > + if (xen_platform_pci_unplug & XEN_UNPLUG_NEVER)
> > + return false;
> > +
> > + if (xen_platform_pci_unplug & XEN_UNPLUG_ALL)
> > + return true;
> > +
> > + /* This is an odd one - we are going to run legacy
> > + * and PV drivers at the same time. */
> > + if (xen_platform_pci_unplug & XEN_UNPLUG_UNNECESSARY)
> > + return true;
> > +
> > + /* And the caller has to follow with xen_pv_{disk,nic}_devices
> > + * to be certain which driver can load. */
> > + return false;
>
> This may result in:
>
> xen_has_pv_devices() = false
> xen_has_pv_disk_devices() = true
Yes.
>
> which looks odd to me. Surely xen_has_pv_*_devices() is a subset of
> xen_has_pv_devices()?
I wish, this thing drives me nuts and I couldn't come up with a sensible
way to make this work for those special ones that have their own
xen_emul_unplug parameter without special casing the
'xen_has_pv_devices'.
Perhaps it should be renamed to 'xen_has_pv_generic_devices' ?
>
> David
^ permalink raw reply
* [PATCH 6/7] Fix a warning pertaining to the aty128fb backlight variable
From: David Howells @ 2014-01-03 16:08 UTC (permalink / raw)
To: akpm; +Cc: dhowells, linux-fbdev, Paul Mackerras, linux-kernel
Fix the following warning in the aty128fb driver:
drivers/video/aty/aty128fb.c:363:12: warning: 'backlight' defined but not used [-Wunused-variable]
static int backlight = 0;
^
as the variable's value is only read if CONFIG_FB_ATY128_BACKLIGHT=y. The
variable is also set if MODULE is unset[*].
[*] I wonder if the conditional wrapper around aty128fb_setup() should be
using CONFIG_MODULE rather than MODULE.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Paul Mackerras <paulus@samba.org>
cc: linux-fbdev@vger.kernel.org
---
drivers/video/aty/aty128fb.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/video/aty/aty128fb.c b/drivers/video/aty/aty128fb.c
index 12ca031877d4..52108be69e77 100644
--- a/drivers/video/aty/aty128fb.c
+++ b/drivers/video/aty/aty128fb.c
@@ -357,11 +357,13 @@ static int default_lcd_on = 1;
static bool mtrr = true;
#endif
+#ifdef CONFIG_FB_ATY128_BACKLIGHT
#ifdef CONFIG_PMAC_BACKLIGHT
static int backlight = 1;
#else
static int backlight = 0;
#endif
+#endif
/* PLL constants */
struct aty128_constants {
@@ -1671,7 +1673,9 @@ static int aty128fb_setup(char *options)
default_crt_on = simple_strtoul(this_opt+4, NULL, 0);
continue;
} else if (!strncmp(this_opt, "backlight:", 10)) {
+#ifdef CONFIG_FB_ATY128_BACKLIGHT
backlight = simple_strtoul(this_opt+10, NULL, 0);
+#endif
continue;
}
#ifdef CONFIG_MTRR
^ permalink raw reply related
* Re: [RFC PATCH 0/5] Move IPUv3 core out of staging, add CSI support
From: Philipp Zabel @ 2014-01-03 16:59 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1387561966-31758-1-git-send-email-p.zabel@pengutronix.de>
Am Freitag, den 20.12.2013, 11:12 -0800 schrieb Greg Kroah-Hartman:
> On Fri, Dec 20, 2013 at 06:52:41PM +0100, Philipp Zabel wrote:
> > Hi,
> >
> > this is mostly about the first patch, which moves the IPUv3 core code
> > (drivers/staging/imx-drm/ipu-v3) to drivers/gpu. host1x, which
> > serves a similar purpose, already sits there.
> > The other four patches add the necessary code for CSI and SMFC handling,
> > which is used by the V4L2 CSI capture driver.
> >
> > Currently this is based on Russell's patch
> > [PATCH 62/64] imx-drm: pass an IPU ID to crtc and core
> >
> > I am aware that there are now quite a few other patches in the pipeline
> > that touch drivers/staging/imx-drm/ipu-v3/*, so I am happy to rebase this
> > (or them) as needed. I'd like to move the core code out of staging so that
> > we can start submitting V4L2 code for video capture and scaling / colorspace
> > conversion in parallel.
>
> I'd recommend doing the move (if the gpu/drm maintainer agrees) after
> 3.14-rc1 as then all of my pending patches would be applied and we would
> be synced up with everything.
Ok.
> Once this "core" is moved, what is keeping the rest in staging and why
> isn't it moving out as well?
Russell put a lot of work into fixing imx-drm issues, and I'd like to
make the change to a common device tree binding before this leaves
staging.
regards
Philipp
^ permalink raw reply
* [PATCH v2] allow xenfb initialization for hvm guests
From: Stefano Stabellini @ 2014-01-03 19:02 UTC (permalink / raw)
To: xen-devel
Cc: linux-kernel, konrad.wilk, stefano.stabellini, boris.ostrovsky,
plagnioj, tomi.valkeinen, linux-fbdev
There is no reasons why an HVM guest shouldn't be allowed to use xenfb.
As a matter of fact ARM guests, HVM from Linux POV, can use xenfb.
Given that no Xen toolstacks configure a xenfb backend for x86 HVM
guests, they are not affected.
Please note that at this time QEMU needs few outstanding fixes to
provide xenfb on ARM:
http://marc.info/?l=qemu-devel&m\x138739419700837&w=2
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: David Vrabel <david.vrabel@citrix.com>
CC: boris.ostrovsky@oracle.com
CC: plagnioj@jcrosoft.com
CC: tomi.valkeinen@ti.com
CC: linux-fbdev@vger.kernel.org
CC: konrad.wilk@oracle.com
---
drivers/video/xen-fbfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index cd005c2..02e1c01 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -692,7 +692,7 @@ static DEFINE_XENBUS_DRIVER(xenfb, ,
static int __init xenfb_init(void)
{
- if (!xen_pv_domain())
+ if (!xen_domain())
return -ENODEV;
/* Nothing to do if running in dom0. */
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v2] allow xenfb initialization for hvm guests
From: Konrad Rzeszutek Wilk @ 2014-01-03 20:34 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel, linux-kernel, boris.ostrovsky, plagnioj,
tomi.valkeinen, linux-fbdev
In-Reply-To: <1388775730-2984-1-git-send-email-stefano.stabellini@eu.citrix.com>
On Fri, Jan 03, 2014 at 07:02:09PM +0000, Stefano Stabellini wrote:
The title needs 'xen/fb' prefixed but that is easy enough.
> There is no reasons why an HVM guest shouldn't be allowed to use xenfb.
> As a matter of fact ARM guests, HVM from Linux POV, can use xenfb.
> Given that no Xen toolstacks configure a xenfb backend for x86 HVM
> guests, they are not affected.
>
> Please note that at this time QEMU needs few outstanding fixes to
> provide xenfb on ARM:
>
> http://marc.info/?l=qemu-devel&m\x138739419700837&w=2
Cool. Is the video maintainer OK with the Xen maintainers stashing it
in the Xen tree for Linus?
Thanks!
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: David Vrabel <david.vrabel@citrix.com>
> CC: boris.ostrovsky@oracle.com
> CC: plagnioj@jcrosoft.com
> CC: tomi.valkeinen@ti.com
> CC: linux-fbdev@vger.kernel.org
> CC: konrad.wilk@oracle.com
> ---
> drivers/video/xen-fbfront.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
> index cd005c2..02e1c01 100644
> --- a/drivers/video/xen-fbfront.c
> +++ b/drivers/video/xen-fbfront.c
> @@ -692,7 +692,7 @@ static DEFINE_XENBUS_DRIVER(xenfb, ,
>
> static int __init xenfb_init(void)
> {
> - if (!xen_pv_domain())
> + if (!xen_domain())
> return -ENODEV;
>
> /* Nothing to do if running in dom0. */
> --
> 1.7.10.4
>
^ permalink raw reply
* Re: [PATCH] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks
From: Pavel Machek @ 2014-01-04 12:51 UTC (permalink / raw)
To: Ivaylo Dimitrov
Cc: tomi.valkeinen, plagnioj, pali.rohar, linux-omap, linux-fbdev,
linux-kernel, Ivaylo Dimitrov
In-Reply-To: <1388420272-5132-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
On Mon 2013-12-30 18:17:52, Ivaylo Dimitrov wrote:
> From: Ivaylo Dimitrov <freemangordon@abv.bg>
>
> Commit c37dd677988ca50bc8bc60ab5ab053720583c168 fixes the unbalanced
> unlock in acx565akm_enable but introduces another problem - if
> acx565akm_panel_power_on exits early, the mutex is not unlocked. Fix
> that by unlocking the mutex on early return. Also add mutex protection in
> acx565akm_panel_power_off and remove an unused variable
>
> Signed-off-by: Ivaylo Dimitrov <freemangordon@abv.bg>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks
From: Ivaylo Dimitrov @ 2014-01-05 12:58 UTC (permalink / raw)
To: Pavel Machek, Ivaylo Dimitrov
Cc: tomi.valkeinen, plagnioj, pali.rohar, linux-omap, linux-fbdev,
linux-kernel, Ivaylo Dimitrov
In-Reply-To: <20140104125108.GA22339@amd.pavel.ucw.cz>
On 04.01.2014 14:51, Pavel Machek wrote:
> On Mon 2013-12-30 18:17:52, Ivaylo Dimitrov wrote:
>> From: Ivaylo Dimitrov <freemangordon@abv.bg>
>>
>> Commit c37dd677988ca50bc8bc60ab5ab053720583c168 fixes the unbalanced
>> unlock in acx565akm_enable but introduces another problem - if
>> acx565akm_panel_power_on exits early, the mutex is not unlocked. Fix
>> that by unlocking the mutex on early return. Also add mutex protection in
>> acx565akm_panel_power_off and remove an unused variable
>>
>> Signed-off-by: Ivaylo Dimitrov <freemangordon@abv.bg>
> Reviewed-by: Pavel Machek <pavel@ucw.cz>
Hmm, I introduced a bug with that patch (recursive lock), will send a
new version that fixes it
Regards,
Ivo
^ permalink raw reply
* [PATCH v2] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks
From: Ivaylo Dimitrov @ 2014-01-05 13:13 UTC (permalink / raw)
To: tomi.valkeinen
Cc: plagnioj, pali.rohar, pavel, linux-omap, linux-fbdev,
linux-kernel, Ivaylo Dimitrov
In-Reply-To: <52C956E9.2030008@gmail.com>
From: Ivaylo Dimitrov <freemangordon@abv.bg>
Commit c37dd677988ca50bc8bc60ab5ab053720583c168 fixes the unbalanced
unlock in acx565akm_enable but introduces another problem - if
acx565akm_panel_power_on exits early, the mutex is not unlocked. Fix
that by unlocking the mutex on early return. Also add mutex protection in
acx565akm_panel_power_off and remove an unused variable
Signed-off-by: Ivaylo Dimitrov <freemangordon@abv.bg>
---
.../omap2/displays-new/panel-sony-acx565akm.c | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
index d94f35d..9aef7fa 100644
--- a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
+++ b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
@@ -535,6 +535,7 @@ static int acx565akm_panel_power_on(struct omap_dss_device *dssdev)
r = in->ops.sdi->enable(in);
if (r) {
+ mutex_unlock(&ddata->mutex);
pr_err("%s sdi enable failed\n", __func__);
return r;
}
@@ -546,6 +547,7 @@ static int acx565akm_panel_power_on(struct omap_dss_device *dssdev)
gpio_set_value(ddata->reset_gpio, 1);
if (ddata->enabled) {
+ mutex_unlock(&ddata->mutex);
dev_dbg(&ddata->spi->dev, "panel already enabled\n");
return 0;
}
@@ -578,10 +580,14 @@ static void acx565akm_panel_power_off(struct omap_dss_device *dssdev)
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *in = ddata->in;
+ mutex_lock(&ddata->mutex);
+
dev_dbg(dssdev->dev, "%s\n", __func__);
- if (!ddata->enabled)
+ if (!ddata->enabled) {
+ mutex_unlock(&ddata->mutex);
return;
+ }
set_display_state(ddata, 0);
set_sleep_mode(ddata, 1);
@@ -601,11 +607,13 @@ static void acx565akm_panel_power_off(struct omap_dss_device *dssdev)
msleep(100);
in->ops.sdi->disable(in);
+
+ mutex_unlock(&ddata->mutex);
+
}
static int acx565akm_enable(struct omap_dss_device *dssdev)
{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
int r;
dev_dbg(dssdev->dev, "%s\n", __func__);
@@ -627,16 +635,12 @@ static int acx565akm_enable(struct omap_dss_device *dssdev)
static void acx565akm_disable(struct omap_dss_device *dssdev)
{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
-
dev_dbg(dssdev->dev, "%s\n", __func__);
if (!omapdss_device_is_enabled(dssdev))
return;
- mutex_lock(&ddata->mutex);
acx565akm_panel_power_off(dssdev);
- mutex_unlock(&ddata->mutex);
dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
}
--
1.5.6.1
^ permalink raw reply related
* Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
From: Ivaylo Dimitrov @ 2014-01-05 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1388409550-10720-2-git-send-email-tomi.valkeinen@ti.com>
On 30.12.2013 15:19, Tomi Valkeinen wrote:
> The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
> However, on some use cases, even when CMA is in use, it's quite probable
> that omapfb fails to allocate the fb, either due to not enough free dma
> memory, fragmented dma memory, or CMA failing to make enough contiguous
> space.
>
> This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
> used to give the size of a memory area reserved exclusively for omapfb,
> and optionally a physical address where the memory area is reserved.
>
> The memory area is reserved with memblock, and assigned to omapfb with
> dma_declare_coherent_memory. The dma_alloc function will first try to
> allocate the fb from the coherent memory area, and if that fails, it'll
> use the normal method of allocation.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Ivaylo Dimitrov <freemangordon@abv.bg>
> ---
> arch/arm/mach-omap2/common.c | 1 +
> arch/arm/mach-omap2/common.h | 2 ++
> arch/arm/mach-omap2/fb.c | 77 +++++++++++++++++++++++++++++++++++++++++++-
> 3 files changed, 79 insertions(+), 1 deletion(-)
>
Tested on Nokia N900 with Maemo5 and linux 3.13-rc6
^ permalink raw reply
* [PATCH 0/2] video: mxsfb: fix broken videomode selection
From: Lothar Waßmann @ 2014-01-06 13:17 UTC (permalink / raw)
To: linux-arm-kernel
The first patch in this set converts some messages that are printed
in case of errors to be error messages rather than debug messages.
The second patch fixes a bug in the video selection code that
incorrectly OR's together the 'pixelclk-active' and 'de-active'
flags from all possible video modes specified in DT into one flag.
The current code does not allow selecting one specific mode from a
list of video modes, but always uses the last one of the video modes
listed in the DT.
Since all current dts files only have one entry in their
'display-timings' node, this bug was not apparent and the fix does not
change the driver's behaviour for the current users.
b/drivers/video/mxsfb.c | 6 +--
drivers/video/mxsfb.c | 120 +++++++++++++++++++++++++++++-----------------------------------------
2 files changed, 53 insertions(+), 73 deletions(-)
^ permalink raw reply
* [PATCH 1/2] video: mxsfb: convert pr_debug()/dev_dbg() to pr_err()/dev_err() for error messages
From: Lothar Waßmann @ 2014-01-06 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389014278-4903-1-git-send-email-LW@KARO-electronics.de>
Make the messages that are printed in case of fatal errors actually
visible to the user without having to recompile the driver with
debugging enabled.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
---
drivers/video/mxsfb.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 27197a8..d11c35c 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -297,7 +297,7 @@ static int mxsfb_check_var(struct fb_var_screeninfo *var,
}
break;
default:
- pr_debug("Unsupported colour depth: %u\n", var->bits_per_pixel);
+ pr_err("Unsupported colour depth: %u\n", var->bits_per_pixel);
return -EINVAL;
}
@@ -426,7 +426,7 @@ static int mxsfb_set_par(struct fb_info *fb_info)
ctrl |= CTRL_SET_WORD_LENGTH(3);
switch (host->ld_intf_width) {
case STMLCDIF_8BIT:
- dev_dbg(&host->pdev->dev,
+ dev_err(&host->pdev->dev,
"Unsupported LCD bus width mapping\n");
return -EINVAL;
case STMLCDIF_16BIT:
@@ -439,7 +439,7 @@ static int mxsfb_set_par(struct fb_info *fb_info)
writel(CTRL1_SET_BYTE_PACKAGING(0x7), host->base + LCDC_CTRL1);
break;
default:
- dev_dbg(&host->pdev->dev, "Unhandled color depth of %u\n",
+ dev_err(&host->pdev->dev, "Unhandled color depth of %u\n",
fb_info->var.bits_per_pixel);
return -EINVAL;
}
--
1.7.2.5
^ permalink raw reply related
* [PATCH 2/2] video: mxsfb: fix broken videomode selection
From: Lothar Waßmann @ 2014-01-06 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389014278-4903-1-git-send-email-LW@KARO-electronics.de>
Currently the driver re-implements the code found in of_get_videomode()
except for the fact that the latter honors the 'native-mode' property
to select a spcific video timing from the list of possible timings.
The driver builds up a list of all video timings, but uses only the
last mode from the list anyway. While building the list it incorrectly
OR's the 'pixelclk-active' and 'de-active' flags of all modes into
single flags, possibly leading to a wrong pixelclock or data-enable
polarity setting.
Fix this by using the of_get_videomode() directly with the
OF_USE_NATIVE_MODE flag.
Since all current dts files only have one entry in their
display-timings node, this bug was not apparent and the fix does not
change the driver's behaviour for the current users.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
---
drivers/video/mxsfb.c | 120 ++++++++++++++++++++----------------------------
1 files changed, 50 insertions(+), 70 deletions(-)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index d11c35c..accf48a2 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -49,6 +49,7 @@
#include <linux/fb.h>
#include <linux/regulator/consumer.h>
#include <video/of_display_timing.h>
+#include <video/of_videomode.h>
#include <video/videomode.h>
#define REG_SET 4
@@ -589,7 +590,8 @@ static struct fb_ops mxsfb_ops = {
.fb_imageblit = cfb_imageblit,
};
-static int mxsfb_restore_mode(struct mxsfb_info *host)
+static int mxsfb_restore_mode(struct mxsfb_info *host,
+ struct fb_videomode *vmode)
{
struct fb_info *fb_info = &host->fb_info;
unsigned line_count;
@@ -597,7 +599,6 @@ static int mxsfb_restore_mode(struct mxsfb_info *host)
unsigned long pa, fbsize;
int bits_per_pixel, ofs;
u32 transfer_count, vdctrl0, vdctrl2, vdctrl3, vdctrl4, ctrl;
- struct fb_videomode vmode;
/* Only restore the mode when the controller is running */
ctrl = readl(host->base + LCDC_CTRL);
@@ -611,8 +612,8 @@ static int mxsfb_restore_mode(struct mxsfb_info *host)
transfer_count = readl(host->base + host->devdata->transfer_count);
- vmode.xres = TRANSFER_COUNT_GET_HCOUNT(transfer_count);
- vmode.yres = TRANSFER_COUNT_GET_VCOUNT(transfer_count);
+ vmode->xres = TRANSFER_COUNT_GET_HCOUNT(transfer_count);
+ vmode->yres = TRANSFER_COUNT_GET_VCOUNT(transfer_count);
switch (CTRL_GET_WORD_LENGTH(ctrl)) {
case 0:
@@ -628,40 +629,39 @@ static int mxsfb_restore_mode(struct mxsfb_info *host)
fb_info->var.bits_per_pixel = bits_per_pixel;
- vmode.pixclock = KHZ2PICOS(clk_get_rate(host->clk) / 1000U);
- vmode.hsync_len = get_hsync_pulse_width(host, vdctrl2);
- vmode.left_margin = GET_HOR_WAIT_CNT(vdctrl3) - vmode.hsync_len;
- vmode.right_margin = VDCTRL2_GET_HSYNC_PERIOD(vdctrl2) - vmode.hsync_len -
- vmode.left_margin - vmode.xres;
- vmode.vsync_len = VDCTRL0_GET_VSYNC_PULSE_WIDTH(vdctrl0);
+ vmode->pixclock = KHZ2PICOS(clk_get_rate(host->clk) / 1000U);
+ vmode->hsync_len = get_hsync_pulse_width(host, vdctrl2);
+ vmode->left_margin = GET_HOR_WAIT_CNT(vdctrl3) - vmode->hsync_len;
+ vmode->right_margin = VDCTRL2_GET_HSYNC_PERIOD(vdctrl2) -
+ vmode->hsync_len - vmode->left_margin - vmode->xres;
+ vmode->vsync_len = VDCTRL0_GET_VSYNC_PULSE_WIDTH(vdctrl0);
period = readl(host->base + LCDC_VDCTRL1);
- vmode.upper_margin = GET_VERT_WAIT_CNT(vdctrl3) - vmode.vsync_len;
- vmode.lower_margin = period - vmode.vsync_len - vmode.upper_margin - vmode.yres;
+ vmode->upper_margin = GET_VERT_WAIT_CNT(vdctrl3) - vmode->vsync_len;
+ vmode->lower_margin = period - vmode->vsync_len -
+ vmode->upper_margin - vmode->yres;
- vmode.vmode = FB_VMODE_NONINTERLACED;
+ vmode->vmode = FB_VMODE_NONINTERLACED;
- vmode.sync = 0;
+ vmode->sync = 0;
if (vdctrl0 & VDCTRL0_HSYNC_ACT_HIGH)
- vmode.sync |= FB_SYNC_HOR_HIGH_ACT;
+ vmode->sync |= FB_SYNC_HOR_HIGH_ACT;
if (vdctrl0 & VDCTRL0_VSYNC_ACT_HIGH)
- vmode.sync |= FB_SYNC_VERT_HIGH_ACT;
+ vmode->sync |= FB_SYNC_VERT_HIGH_ACT;
pr_debug("Reconstructed video mode:\n");
pr_debug("%dx%d, hsync: %u left: %u, right: %u, vsync: %u, upper: %u, lower: %u\n",
- vmode.xres, vmode.yres,
- vmode.hsync_len, vmode.left_margin, vmode.right_margin,
- vmode.vsync_len, vmode.upper_margin, vmode.lower_margin);
- pr_debug("pixclk: %ldkHz\n", PICOS2KHZ(vmode.pixclock));
-
- fb_add_videomode(&vmode, &fb_info->modelist);
+ vmode->xres, vmode->yres, vmode->hsync_len, vmode->left_margin,
+ vmode->right_margin, vmode->vsync_len, vmode->upper_margin,
+ vmode->lower_margin);
+ pr_debug("pixclk: %ldkHz\n", PICOS2KHZ(vmode->pixclock));
host->ld_intf_width = CTRL_GET_BUS_WIDTH(ctrl);
host->dotclk_delay = VDCTRL4_GET_DOTCLK_DLY(vdctrl4);
- fb_info->fix.line_length = vmode.xres * (bits_per_pixel >> 3);
+ fb_info->fix.line_length = vmode->xres * (bits_per_pixel >> 3);
pa = readl(host->base + host->devdata->cur_buf);
- fbsize = fb_info->fix.line_length * vmode.yres;
+ fbsize = fb_info->fix.line_length * vmode->yres;
if (pa < fb_info->fix.smem_start)
return -EINVAL;
if (pa + fbsize > fb_info->fix.smem_start + fb_info->fix.smem_len)
@@ -681,18 +681,17 @@ static int mxsfb_restore_mode(struct mxsfb_info *host)
return 0;
}
-static int mxsfb_init_fbinfo_dt(struct mxsfb_info *host)
+static int mxsfb_init_fbinfo_dt(struct mxsfb_info *host,
+ struct fb_videomode *vmode)
{
struct fb_info *fb_info = &host->fb_info;
struct fb_var_screeninfo *var = &fb_info->var;
struct device *dev = &host->pdev->dev;
struct device_node *np = host->pdev->dev.of_node;
struct device_node *display_np;
- struct device_node *timings_np;
- struct display_timings *timings;
+ struct videomode vm;
u32 width;
- int i;
- int ret = 0;
+ int ret;
display_np = of_parse_phandle(np, "display", 0);
if (!display_np) {
@@ -732,54 +731,35 @@ static int mxsfb_init_fbinfo_dt(struct mxsfb_info *host)
goto put_display_node;
}
- timings = of_get_display_timings(display_np);
- if (!timings) {
- dev_err(dev, "failed to get display timings\n");
- ret = -ENOENT;
+ ret = of_get_videomode(display_np, &vm, OF_USE_NATIVE_MODE);
+ if (ret) {
+ dev_err(dev, "failed to get videomode from DT\n");
goto put_display_node;
}
- timings_np = of_find_node_by_name(display_np,
- "display-timings");
- if (!timings_np) {
- dev_err(dev, "failed to find display-timings node\n");
- ret = -ENOENT;
+ ret = fb_videomode_from_videomode(&vm, vmode);
+ if (ret < 0)
goto put_display_node;
- }
- for (i = 0; i < of_get_child_count(timings_np); i++) {
- struct videomode vm;
- struct fb_videomode fb_vm;
-
- ret = videomode_from_timings(timings, &vm, i);
- if (ret < 0)
- goto put_timings_node;
- ret = fb_videomode_from_videomode(&vm, &fb_vm);
- if (ret < 0)
- goto put_timings_node;
-
- if (vm.flags & DISPLAY_FLAGS_DE_HIGH)
- host->sync |= MXSFB_SYNC_DATA_ENABLE_HIGH_ACT;
- if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
- host->sync |= MXSFB_SYNC_DOTCLK_FALLING_ACT;
- fb_add_videomode(&fb_vm, &fb_info->modelist);
- }
+ if (vm.flags & DISPLAY_FLAGS_DE_HIGH)
+ host->sync |= MXSFB_SYNC_DATA_ENABLE_HIGH_ACT;
+ if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+ host->sync |= MXSFB_SYNC_DOTCLK_FALLING_ACT;
-put_timings_node:
- of_node_put(timings_np);
put_display_node:
of_node_put(display_np);
return ret;
}
-static int mxsfb_init_fbinfo(struct mxsfb_info *host)
+static int mxsfb_init_fbinfo(struct mxsfb_info *host,
+ struct fb_videomode *vmode)
{
+ int ret;
struct fb_info *fb_info = &host->fb_info;
struct fb_var_screeninfo *var = &fb_info->var;
dma_addr_t fb_phys;
void *fb_virt;
unsigned fb_size;
- int ret;
fb_info->fbops = &mxsfb_ops;
fb_info->flags = FBINFO_FLAG_DEFAULT | FBINFO_READS_FAST;
@@ -789,7 +769,7 @@ static int mxsfb_init_fbinfo(struct mxsfb_info *host)
fb_info->fix.visual = FB_VISUAL_TRUECOLOR,
fb_info->fix.accel = FB_ACCEL_NONE;
- ret = mxsfb_init_fbinfo_dt(host);
+ ret = mxsfb_init_fbinfo_dt(host, vmode);
if (ret)
return ret;
@@ -810,7 +790,7 @@ static int mxsfb_init_fbinfo(struct mxsfb_info *host)
fb_info->screen_base = fb_virt;
fb_info->screen_size = fb_info->fix.smem_len = fb_size;
- if (mxsfb_restore_mode(host))
+ if (mxsfb_restore_mode(host, vmode))
memset(fb_virt, 0, fb_size);
return 0;
@@ -850,7 +830,7 @@ static int mxsfb_probe(struct platform_device *pdev)
struct resource *res;
struct mxsfb_info *host;
struct fb_info *fb_info;
- struct fb_modelist *modelist;
+ struct fb_videomode *mode;
int ret;
if (of_id)
@@ -862,6 +842,11 @@ static int mxsfb_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ mode = devm_kzalloc(&pdev->dev, sizeof(struct fb_videomode),
+ GFP_KERNEL);
+ if (mode = NULL)
+ return -ENOMEM;
+
host = to_imxfb_host(fb_info);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -893,15 +878,11 @@ static int mxsfb_probe(struct platform_device *pdev)
goto fb_release;
}
- INIT_LIST_HEAD(&fb_info->modelist);
-
- ret = mxsfb_init_fbinfo(host);
+ ret = mxsfb_init_fbinfo(host, mode);
if (ret != 0)
goto fb_release;
- modelist = list_first_entry(&fb_info->modelist,
- struct fb_modelist, list);
- fb_videomode_to_var(&fb_info->var, &modelist->mode);
+ fb_videomode_to_var(&fb_info->var, mode);
/* init the color fields */
mxsfb_check_var(&fb_info->var, fb_info);
@@ -927,7 +908,6 @@ static int mxsfb_probe(struct platform_device *pdev)
fb_destroy:
if (host->enabled)
clk_disable_unprepare(host->clk);
- fb_destroy_modelist(&fb_info->modelist);
fb_release:
framebuffer_release(fb_info);
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH 1/2] drm/panel: Add support for Samsung LTN101NT05 panel
From: Stephen Warren @ 2014-01-06 19:22 UTC (permalink / raw)
To: Thierry Reding; +Cc: linux-fbdev, dri-devel, Marc Dietrich
In-Reply-To: <f03a644deb858f10affb7b039f9982bac81b02c9.1387656959.git.marvin24@gmx.de>
On 12/21/2013 01:40 PM, Marc Dietrich wrote:
> The Samsung LNT101NT05 10.1" WXVGA panel can be supported by the simple panel
> driver.
Thierry, I assume you'll take patch 1/2 throught the appropriate DRM tree.
^ permalink raw reply
* FOSDEM14: Graphics DevRoom: Deadline approaching fast.
From: Luc Verhaegen @ 2014-01-07 1:22 UTC (permalink / raw)
To: mesa-dev, xorg-devel, dri-devel, xorg, wayland-devel,
xorg-announce, mir-devel, directfb-dev, linux-fbdev, linux-media
Hi,
There are still 5 slots open for the FOSDEM graphics DevRoom, and the
deadline is this friday, the 10th. Get a move on.
If you have requested an account reset with me before, but if you then
haven't bothered filing a talk, you do NOT have a slot. Please file a
talk ASAP to still secure a place.
For more information on how to file for a devroom, read the email sent
back in october:
http://lists.x.org/archives/xorg-devel/2013-October/038185.html
Luc Verhaegen.
^ permalink raw reply
* Re: [PATCH 3/4] backlight: lcd: call put_device if device_register fails
From: Jingoo Han @ 2014-01-07 1:42 UTC (permalink / raw)
To: 'Levente Kurusa'
Cc: 'LKML', 'Jean-Christophe Plagniol-Villard',
'Tomi Valkeinen', linux-fbdev, 'Jingoo Han',
'Andrew Morton'
In-Reply-To: <1386959996-7958-4-git-send-email-levex@linux.com>
On Saturday, December 14, 2013 3:40 AM, Levente Kurusa wrote:
>
> Currently we kfree the container of the device which failed to register.
> This is wrong as the last reference is not given up with a put_device
> call. Also, now that we have put_device() callen, we no longer need
> the kfree as the new_ld->dev.release function will take care of kfreeing
> the associated memory.
>
> Signed-off-by: Levente Kurusa <levex@linux.com>
> ---
> drivers/video/backlight/lcd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/lcd.c b/drivers/video/backlight/lcd.c
> index 93cf15e..7de847d 100644
> --- a/drivers/video/backlight/lcd.c
> +++ b/drivers/video/backlight/lcd.c
> @@ -228,7 +228,7 @@ struct lcd_device *lcd_device_register(const char *name, struct device *parent,
>
> rc = device_register(&new_ld->dev);
> if (rc) {
> - kfree(new_ld);
> + put_device(&new_ld->dev);
> return ERR_PTR(rc);
> }
(+cc Andrew Morton)
Hi Levente Kurusa,
Would you fix the same thing for 'backlight.c' file?
./drivers/video/backlight/backlight.c
struct backlight_device *backlight_device_register(const char *name,
.....
rc = device_register(&new_bd->dev);
if (rc) {
kfree(new_bd);
return ERR_PTR(rc);
}
Best regards,
Jingoo Han
^ permalink raw reply
* Re: [PATCH v2] allow xenfb initialization for hvm guests
From: Tomi Valkeinen @ 2014-01-07 12:49 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Stefano Stabellini
Cc: xen-devel, linux-kernel, boris.ostrovsky, plagnioj, linux-fbdev
In-Reply-To: <20140103203422.GA2668@phenom.dumpdata.com>
[-- Attachment #1: Type: text/plain, Size: 747 bytes --]
On 2014-01-03 22:34, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 03, 2014 at 07:02:09PM +0000, Stefano Stabellini wrote:
>
> The title needs 'xen/fb' prefixed but that is easy enough.
>
>> There is no reasons why an HVM guest shouldn't be allowed to use xenfb.
>> As a matter of fact ARM guests, HVM from Linux POV, can use xenfb.
>> Given that no Xen toolstacks configure a xenfb backend for x86 HVM
>> guests, they are not affected.
>>
>> Please note that at this time QEMU needs few outstanding fixes to
>> provide xenfb on ARM:
>>
>> http://marc.info/?l=qemu-devel&m=138739419700837&w=2
>
> Cool. Is the video maintainer OK with the Xen maintainers stashing it
> in the Xen tree for Linus?
Yep, fine for me.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* fbdev patches for 3.14
From: Tomi Valkeinen @ 2014-01-07 12:53 UTC (permalink / raw)
To: linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 486 bytes --]
Hi,
Jean-Christophe was supposed to be handling this merge window, but that
doesn't seem to happen. So I'll start collecting fbdev patches for 3.14.
We're obviously very late, so I'm trying to apply only relatively safe
patches, nothing controversial.
I'll start going through the patches, but if there's something urgent, I
don't mind if you re-post it already. Or, if it's not urgent, check
linux-next at the end of the week, and re-post if it's not there yet.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 13/15] fbdev: sh-mobile-lcdcfb: Enable driver compilation with COMPILE_TEST
From: Laurent Pinchart @ 2014-01-07 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1542726.dq1lpTml5f@avalon>
On Wednesday 11 December 2013 13:51:18 Laurent Pinchart wrote:
> Hi Jean-Christophe and Tomi,
>
> Could you please pick this patch up for v3.14 ?
Ping ?
> On Wednesday 27 November 2013 02:18:35 Laurent Pinchart wrote:
> > This helps increasing build testing coverage.
> >
> > Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Cc: linux-fbdev@vger.kernel.org
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
> > Acked-by: Simon Horman <horms@verge.net.au>
> > ---
> >
> > drivers/video/Kconfig | 8 +++++---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index 4f2e1b3..2aceb08 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -10,7 +10,8 @@ config HAVE_FB_ATMEL
> >
> > config SH_MIPI_DSI
> > tristate
> > - depends on (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
> > + depends on HAVE_CLK
> > + depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
> >
> > config SH_LCD_MIPI_DSI
> > bool
> > @@ -1997,7 +1998,8 @@ config FB_W100
> >
> > config FB_SH_MOBILE_LCDC
> > tristate "SuperH Mobile LCDC framebuffer support"
> > - depends on FB && (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
> > + depends on FB && HAVE_CLK
> > + depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
> > select FB_SYS_FILLRECT
> > select FB_SYS_COPYAREA
> > select FB_SYS_IMAGEBLIT
> > @@ -2484,7 +2486,7 @@ endif
> >
> > config FB_SH_MOBILE_MERAM
> > tristate "SuperH Mobile MERAM read ahead support"
> > - depends on (SUPERH || ARCH_SHMOBILE)
> > + depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
> > select GENERIC_ALLOCATOR
> > ---help---
> > Enable MERAM support for the SuperH controller.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] fbdev: sh_mobile_lcdcfb: Don't use plain 0 as NULL pointer
From: Laurent Pinchart @ 2014-01-07 15:17 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1385512723-11722-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Hi Jean-Christophe and Tomi,
Could you please pick this patch up for v3.14 ?
On Wednesday 27 November 2013 01:38:43 Laurent Pinchart wrote:
> This fixes a sparse warning.
>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> drivers/video/sh_mobile_lcdcfb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/sh_mobile_lcdcfb.c
> b/drivers/video/sh_mobile_lcdcfb.c index ab85ad6..2bcc84a 100644
> --- a/drivers/video/sh_mobile_lcdcfb.c
> +++ b/drivers/video/sh_mobile_lcdcfb.c
> @@ -1227,7 +1227,7 @@ static void sh_mobile_lcdc_stop(struct
> sh_mobile_lcdc_priv *priv) /* Free the MERAM cache. */
> if (ch->cache) {
> sh_mobile_meram_cache_free(priv->meram_dev, ch->cache);
> - ch->cache = 0;
> + ch->cache = NULL;
> }
>
> }
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 1/2] drm/panel: Add support for Samsung LTN101NT05 panel
From: Thierry Reding @ 2014-01-07 16:00 UTC (permalink / raw)
To: Stephen Warren; +Cc: linux-fbdev, Thierry Reding, dri-devel, Marc Dietrich
In-Reply-To: <52CB0281.7060203@wwwdotorg.org>
[-- Attachment #1: Type: text/plain, Size: 319 bytes --]
On Mon, Jan 06, 2014 at 12:22:41PM -0700, Stephen Warren wrote:
> On 12/21/2013 01:40 PM, Marc Dietrich wrote:
> > The Samsung LNT101NT05 10.1" WXVGA panel can be supported by the simple panel
> > driver.
>
> Thierry, I assume you'll take patch 1/2 throught the appropriate DRM tree.
Yes, will do.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
From: Tony Lindgren @ 2014-01-07 23:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1388409550-10720-2-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131230 05:21]:
> The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
> However, on some use cases, even when CMA is in use, it's quite probable
> that omapfb fails to allocate the fb, either due to not enough free dma
> memory, fragmented dma memory, or CMA failing to make enough contiguous
> space.
>
> This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
> used to give the size of a memory area reserved exclusively for omapfb,
> and optionally a physical address where the memory area is reserved.
>
> The memory area is reserved with memblock, and assigned to omapfb with
> dma_declare_coherent_memory. The dma_alloc function will first try to
> allocate the fb from the coherent memory area, and if that fails, it'll
> use the normal method of allocation.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Ivaylo Dimitrov <freemangordon@abv.bg>
Feel free to queue this along with the DSS patches:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH RESEND 1/4] video: asiliantfb: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2014-01-08 0:44 UTC (permalink / raw)
To: linux-fbdev
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/asiliantfb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/asiliantfb.c b/drivers/video/asiliantfb.c
index d611f1a..7e8ddf0 100644
--- a/drivers/video/asiliantfb.c
+++ b/drivers/video/asiliantfb.c
@@ -589,7 +589,6 @@ static void asiliantfb_remove(struct pci_dev *dp)
fb_dealloc_cmap(&p->cmap);
iounmap(p->screen_base);
release_mem_region(pci_resource_start(dp, 0), pci_resource_len(dp, 0));
- pci_set_drvdata(dp, NULL);
framebuffer_release(p);
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH RESEND 2/4] video: nvidiafb: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2014-01-08 0:45 UTC (permalink / raw)
To: linux-fbdev
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/nvidia/nvidia.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/nvidia/nvidia.c b/drivers/video/nvidia/nvidia.c
index ff22871..def0412 100644
--- a/drivers/video/nvidia/nvidia.c
+++ b/drivers/video/nvidia/nvidia.c
@@ -1461,7 +1461,6 @@ static void nvidiafb_remove(struct pci_dev *pd)
pci_release_regions(pd);
kfree(info->pixmap.addr);
framebuffer_release(info);
- pci_set_drvdata(pd, NULL);
NVTRACE_LEAVE();
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH RESEND 3/4] video: rivafb: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2014-01-08 0:45 UTC (permalink / raw)
To: linux-fbdev
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/riva/fbdev.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/riva/fbdev.c b/drivers/video/riva/fbdev.c
index a5514ac..8a8d7f0 100644
--- a/drivers/video/riva/fbdev.c
+++ b/drivers/video/riva/fbdev.c
@@ -2128,7 +2128,6 @@ static void rivafb_remove(struct pci_dev *pd)
pci_release_regions(pd);
kfree(info->pixmap.addr);
framebuffer_release(info);
- pci_set_drvdata(pd, NULL);
NVTRACE_LEAVE();
}
--
1.7.10.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox