* Re: [RFC PATCH] video: Use fb_sys_write rather than open-coding in drivers
From: Ryan Mallon @ 2014-02-12 5:02 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jean-Christophe PLAGNIOL-VILLARD, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <52FB1AB0.6090601@ti.com>
On 12/02/14 19:54, Tomi Valkeinen wrote:
> On 11/02/14 21:07, Ryan Mallon wrote:
>> On 12/02/14 03:06, Tomi Valkeinen wrote:
>>
>>> On 20/09/13 10:06, Ryan Mallon wrote:
>>>> Several video drivers open code the fb_write write function with code
>>>> which is very similar to fb_sys_write. Replace the open code versions
>>>> with calls to fb_sys_write. An fb_sync callback is added to each of
>>>> the drivers.
>>>>
>>>> Signed-off-by: Ryan Mallon <rmallon@gmail.com>
>>>> ---
>>>
>>> Doesn't this change the behavior so that fb_write does no longer update
>>> the display, but fb_sync does? I don't think fb_sync is even meant to
>>> update the display, it's meant to wait for an update to finish. Then
>>> again, I'm not sure about that, all I see in fb.h is "wait for blit
>>> idle, optional"
>>
>>
>> fb_write() in fbmem.c calls ->fb_sync() after ->fb_write(), and I've set
>> the fb_sync() for each of the drivers, so the behaviour should be
>> unchanged for writes.
>>
>> The fb_sync() function is also called by fb_read() and
>> fb_get_buffer_offset() (if FB_PIXMAP_SYNC flag is set). I don't know if
>> that will adversely affect behaviour.
>
> Well, by just looking at the function names the drivers' fb_syncs call,
> it sounds to me that with your patch fb_sync will update the LCD, i.e.
> send data to it. Doing that in fb_read sounds totally wrong.
Well, the alternative is to supply an fb_write() implementation for each
driver that calls fb_sys_write(), and then updates the display. The
fb_sync() additions can be removed. That would cut down the boiler-plate
code, and should keep the behaviour the same.
If you don't think it is worth the effort, then the patch can just be
dropped.
~Ryan
^ permalink raw reply
* Re: [PATCH 01/28] Remove CPU_MMP3
From: Paul Bolle @ 2014-02-11 22:01 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Richard Weinberger, Felipe Balbi,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
open list:USB PHY LAYER, open list, open list:FRAMEBUFFER LAYER
In-Reply-To: <20140211213054.GA2555@kroah.com>
On Tue, 2014-02-11 at 13:30 -0800, Greg Kroah-Hartman wrote:
> On Sun, Feb 09, 2014 at 07:47:39PM +0100, Richard Weinberger wrote:
> > The symbol is an orphan, get rid of it.
> >
> > Signed-off-by: Richard Weinberger <richard@nod.at>
> > Acked-by: Paul Bolle <pebolle@tiscali.nl>
> >
> > ---
> > drivers/usb/phy/Kconfig | 1 -
> > drivers/video/mmp/Kconfig | 2 +-
> > drivers/video/mmp/hw/Kconfig | 2 +-
> > 3 files changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> > index 7d1451d..b9b1c52 100644
> > --- a/drivers/usb/phy/Kconfig
> > +++ b/drivers/usb/phy/Kconfig
> > @@ -61,7 +61,6 @@ config KEYSTONE_USB_PHY
> >
> > config MV_U3D_PHY
> > bool "Marvell USB 3.0 PHY controller Driver"
> > - depends on CPU_MMP3
> > select USB_PHY
> > help
> > Enable this to support Marvell USB 3.0 phy controller for Marvell
>
> Do this and the driver breaks the build so it needs to depend on
> something:
>
> drivers/usb/phy/phy-mv-u3d-usb.c: In function ‘mv_u3d_phy_read’:
> drivers/usb/phy/phy-mv-u3d-usb.c:42:2: error: implicit declaration of function ‘writel_relaxed’ [-Werror=implicit-function-declaration]
This sort of proves that a driver that depends on an unknown Kconfig
symbol gets no build coverage (and will bit rot).
> Sorry, I can't take this as-is.
My mistake, I should have spotted this when looking a Richard's patch.
Some background (which I quickly dug up): config MV_U3D_PHY got added in
v3.7 through commit a67e76ac904c ("usb: phy: mv_u3d: Add usb phy driver
for mv_u3d"). It then depended on USB_MV_U3D. And that symbol depended
on CPU_MMP3 at that time. Ie, MV_U3D_PHY was unbuildable when it was
added.
In commit 60630c2eabd4 ("usb: gadget: mv_u3d: drop ARCH dependency")
MV_U3D_PHY was made depended directly on CPU_MMP3. That kept it
unbuildable, of course.
Richard, assuming you agree with the above short history of MV_U3D_PHY,
would you mind sending a v2 that removes this unbuildable driver?
Paul Bolle
^ permalink raw reply
* Re: [PATCH 01/28] Remove CPU_MMP3
From: Greg Kroah-Hartman @ 2014-02-11 21:30 UTC (permalink / raw)
To: Richard Weinberger
Cc: Felipe Balbi, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
open list:USB PHY LAYER, open list, open list:FRAMEBUFFER LAYER
In-Reply-To: <1391971686-9517-2-git-send-email-richard@nod.at>
On Sun, Feb 09, 2014 at 07:47:39PM +0100, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
>
> Signed-off-by: Richard Weinberger <richard@nod.at>
> Acked-by: Paul Bolle <pebolle@tiscali.nl>
>
> ---
> drivers/usb/phy/Kconfig | 1 -
> drivers/video/mmp/Kconfig | 2 +-
> drivers/video/mmp/hw/Kconfig | 2 +-
> 3 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> index 7d1451d..b9b1c52 100644
> --- a/drivers/usb/phy/Kconfig
> +++ b/drivers/usb/phy/Kconfig
> @@ -61,7 +61,6 @@ config KEYSTONE_USB_PHY
>
> config MV_U3D_PHY
> bool "Marvell USB 3.0 PHY controller Driver"
> - depends on CPU_MMP3
> select USB_PHY
> help
> Enable this to support Marvell USB 3.0 phy controller for Marvell
Do this and the driver breaks the build so it needs to depend on
something:
drivers/usb/phy/phy-mv-u3d-usb.c: In function ‘mv_u3d_phy_read’:
drivers/usb/phy/phy-mv-u3d-usb.c:42:2: error: implicit declaration of function ‘writel_relaxed’ [-Werror=implicit-function-declaration]
Sorry, I can't take this as-is.
greg k-h
^ permalink raw reply
* Re: [RFC PATCH] video: Use fb_sys_write rather than open-coding in drivers
From: Ryan Mallon @ 2014-02-11 19:07 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jean-Christophe PLAGNIOL-VILLARD, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <52FA2E57.3010300@ti.com>
On 12/02/14 03:06, Tomi Valkeinen wrote:
> On 20/09/13 10:06, Ryan Mallon wrote:
>> Several video drivers open code the fb_write write function with code
>> which is very similar to fb_sys_write. Replace the open code versions
>> with calls to fb_sys_write. An fb_sync callback is added to each of
>> the drivers.
>>
>> Signed-off-by: Ryan Mallon <rmallon@gmail.com>
>> ---
>
> Doesn't this change the behavior so that fb_write does no longer update
> the display, but fb_sync does? I don't think fb_sync is even meant to
> update the display, it's meant to wait for an update to finish. Then
> again, I'm not sure about that, all I see in fb.h is "wait for blit
> idle, optional"
fb_write() in fbmem.c calls ->fb_sync() after ->fb_write(), and I've set
the fb_sync() for each of the drivers, so the behaviour should be
unchanged for writes.
The fb_sync() function is also called by fb_read() and
fb_get_buffer_offset() (if FB_PIXMAP_SYNC flag is set). I don't know if
that will adversely affect behaviour.
Note that I haven't actually tested this code since I don't have any of
the hardware. It was just something I noticed while digging through
framebuffer driver code.
~Ryan
^ permalink raw reply
* Re: [PATCH] video: imxfb: Use regulator API w =?UTF-8?B?aXRoIExDRCBjbGFzc
From: Alexander Shiyan @ 2014-02-11 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FA2170.3040900@ti.com>
0JLRgtC+0YDQvdC40LosIDExINGE0LXQstGA0LDQu9GPIDIwMTQsIDE1OjExICswMjowMCDQvtGC
IFRvbWkgVmFsa2VpbmVuIDx0b21pLnZhbGtlaW5lbkB0aS5jb20+Ogo+IE9uIDExLzAyLzE0IDA0
OjQzLCBTaGF3biBHdW8gd3JvdGU6Cj4gPiBBY2tlZC1ieTogU2hhd24gR3VvIDxzaGF3bi5ndW9A
bGluYXJvLm9yZz4KPiAKPiBUaGFua3MuIFF1ZXVlZCBmb3IgMy4xNS4KClRoYW5rcy4KVG9taSwg
Y2FuIHlvdSBhZGRpdGlvbmFsbHkgYXBwbHkgcGF0Y2ggZnJvbSBEZW5pcyBDYXJpa2xpIHRvIGFs
bG93CmhhdmUgRFQtb25seSBrZXJuZWxzIHdpdGggaS5NWCBGQiBkcml2ZXI/Cmh0dHA6Ly93d3cu
c3Bpbmljcy5uZXQvbGlzdHMvYXJtLWtlcm5lbC9tc2czMDI0OTkuaHRtbAoKLS0tCg=
^ permalink raw reply
* Re: [PATCH 1/2] video: exynos: Remove OF dependency for Exynos DP
From: Tomi Valkeinen @ 2014-02-11 14:27 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1389933172-22991-1-git-send-email-sachin.kamat@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]
On 11/02/14 14:01, Sachin Kamat wrote:
> On 10 February 2014 17:48, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 17/01/14 06:32, Sachin Kamat wrote:
>>> Exynos is now a DT only platform. Hence there is no need
>>> for an explicit OF dependency. Remove it.
>>
>> But the driver still depends on OF, doesn't it? I don't think it's very
>> good for the driver Kconfig to make presumptions about what ARCH_*
>> depend on.
>
> Depending upon nested dependencies is redundant IMHO.
Well, a driver should be independent of the underlying arch. In
practice, we have ARCH dependencies, as many of the devices only exist
on that arch. But I think the drivers should still be designed to be
arch-independent, as far as possible (omapdss compiles fine on x86).
If the driver depends on OF, it should depend on OF in the Kconfig, no
matter if the arch also depends on OF.
I don't really care if the EXYNOS_LCD_S6E8AX0 has OF dependency or not,
but to me this just looks unneeded cleanup, cluttering git logs, and in
my opinion it's even going to the wrong direction.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] video: Use fb_sys_write rather than open-coding in drivers
From: Tomi Valkeinen @ 2014-02-11 14:06 UTC (permalink / raw)
To: Ryan Mallon
Cc: Jean-Christophe PLAGNIOL-VILLARD, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <523BF40B.1090002@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 652 bytes --]
On 20/09/13 10:06, Ryan Mallon wrote:
> Several video drivers open code the fb_write write function with code
> which is very similar to fb_sys_write. Replace the open code versions
> with calls to fb_sys_write. An fb_sync callback is added to each of
> the drivers.
>
> Signed-off-by: Ryan Mallon <rmallon@gmail.com>
> ---
Doesn't this change the behavior so that fb_write does no longer update
the display, but fb_sync does? I don't think fb_sync is even meant to
update the display, it's meant to wait for an update to finish. Then
again, I'm not sure about that, all I see in fb.h is "wait for blit
idle, optional"
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video: xilinxfb: Move xilinxfb_platform_data directly to the driver
From: Tomi Valkeinen @ 2014-02-11 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <af8de8bd8803b319c0f6a02ca5109768e5ef8457.1392101292.git.michal.simek@xilinx.com>
[-- Attachment #1: Type: text/plain, Size: 701 bytes --]
On 11/02/14 08:48, Michal Simek wrote:
> No reason to have separate file in header in include/linux folder
> if this is purely driver specific structure.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
>
> I have this patch in my devel tree for a while and would like
> to hear your opinion. I can't see any reason to have
> xilinxfb_platform_data in header if this is purely OF driver
> used on OF archs.
> ---
> drivers/video/xilinxfb.c | 15 ++++++++++++++-
> include/linux/xilinxfb.h | 30 ------------------------------
> 2 files changed, 14 insertions(+), 31 deletions(-)
> delete mode 100644 include/linux/xilinxfb.h
Thanks. Queued for 3.15.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video: imxfb: Use regulator API with LCD class for powering
From: Tomi Valkeinen @ 2014-02-11 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140211024318.GA31484@S2101-09.ap.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 124 bytes --]
On 11/02/14 04:43, Shawn Guo wrote:
> Acked-by: Shawn Guo <shawn.guo@linaro.org>
Thanks. Queued for 3.15.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 0/10] framebuffer patches
From: Tomi Valkeinen @ 2014-02-11 13:00 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <alpine.LRH.2.02.1401231436400.7971@file01.intranet.prod.int.rdu2.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 476 bytes --]
On 11/02/14 14:58, Tomi Valkeinen wrote:
> On 23/01/14 21:37, Mikulas Patocka wrote:
>> Hi
>>
>> Here I'm sending some framebuffer patches for matrox, mach64, tga and a
>> fix for copying on vesafb.
>>
>> Mikulas
>>
>
> Looks fine to me. Queuing for 3.15.
Oh, I did some conflict resolution on "tgafb: fix mode setting with
fbset". It was trivial, so I think I got it right. But please check
anyway in a few days when these get into linux-next.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 0/10] framebuffer patches
From: Tomi Valkeinen @ 2014-02-11 12:58 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <alpine.LRH.2.02.1401231436400.7971@file01.intranet.prod.int.rdu2.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 230 bytes --]
On 23/01/14 21:37, Mikulas Patocka wrote:
> Hi
>
> Here I'm sending some framebuffer patches for matrox, mach64, tga and a
> fix for copying on vesafb.
>
> Mikulas
>
Looks fine to me. Queuing for 3.15.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] fbcon: Clean up fbcon data in fb_info on FB_EVENT_FB_UNBIND with 0 fbs
From: Tomi Valkeinen @ 2014-02-11 12:18 UTC (permalink / raw)
To: Keith Packard; +Cc: linux-kernel, Jean-Christophe Plagniol-Villard, linux-fbdev
In-Reply-To: <1390253470-23594-1-git-send-email-keithp@keithp.com>
[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]
Hi,
On 20/01/14 23:31, Keith Packard wrote:
> When FB_EVENT_FB_UNBIND is sent, fbcon has two paths, one path taken
> when there is another frame buffer to switch any affected vcs to and
> another path when there isn't.
>
> In the case where there is another frame buffer to use,
> fbcon_fb_unbind calls set_con2fb_map to remap all of the affected vcs
> to the replacement frame buffer. set_con2fb_map will eventually call
> con2fb_release_oldinfo when the last vcs gets unmapped from the old
> frame buffer.
>
> con2fb_release_oldinfo frees the fbcon data that is hooked off of the
> fb_info structure, including the cursor timer.
>
> In the case where there isn't another frame buffer to use,
> fbcon_fb_unbind simply calls fbcon_unbind, which doesn't clear the
> con2fb_map or free the fbcon data hooked from the fb_info
> structure. In particular, it doesn't stop the cursor blink timer. When
> the fb_info structure is then freed, we end up with a timer queue
> pointing into freed memory and "bad things" start happening.
>
> This patch first changes con2fb_release_oldinfo so that it can take a
> NULL pointer for the new frame buffer, but still does all of the
> deallocation and cursor timer cleanup.
>
> Finally, the patch tries to replicate some of what set_con2fb_map does
> by clearing the con2fb_map for the affected vcs and calling the
> modified con2fb_release_info function to clean up the fb_info structure.
>
> Signed-off-by: Keith Packard <keithp@keithp.com>
> ---
> drivers/video/console/fbcon.c | 27 +++++++++++++++++++++++++--
> 1 file changed, 25 insertions(+), 2 deletions(-)
Thanks, queued for 3.15.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] video: exynos: Remove OF dependency for Exynos DP
From: Sachin Kamat @ 2014-02-11 12:13 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1389933172-22991-1-git-send-email-sachin.kamat@linaro.org>
On 10 February 2014 17:48, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 17/01/14 06:32, Sachin Kamat wrote:
>> Exynos is now a DT only platform. Hence there is no need
>> for an explicit OF dependency. Remove it.
>
> But the driver still depends on OF, doesn't it? I don't think it's very
> good for the driver Kconfig to make presumptions about what ARCH_*
> depend on.
Depending upon nested dependencies is redundant IMHO.
--
With warm regards,
Sachin
^ permalink raw reply
* [PATCH] video: xilinxfb: Move xilinxfb_platform_data directly to the driver
From: Michal Simek @ 2014-02-11 6:48 UTC (permalink / raw)
To: linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 2777 bytes --]
No reason to have separate file in header in include/linux folder
if this is purely driver specific structure.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
I have this patch in my devel tree for a while and would like
to hear your opinion. I can't see any reason to have
xilinxfb_platform_data in header if this is purely OF driver
used on OF archs.
---
drivers/video/xilinxfb.c | 15 ++++++++++++++-
include/linux/xilinxfb.h | 30 ------------------------------
2 files changed, 14 insertions(+), 31 deletions(-)
delete mode 100644 include/linux/xilinxfb.h
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 6ff1a91..553cff2 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -33,7 +33,6 @@
#include <linux/of_platform.h>
#include <linux/of_address.h>
#include <linux/io.h>
-#include <linux/xilinxfb.h>
#include <linux/slab.h>
#ifdef CONFIG_PPC_DCR
@@ -84,6 +83,20 @@
#define PALETTE_ENTRIES_NO 16 /* passed to fb_alloc_cmap() */
+/* ML300/403 reference design framebuffer driver platform data struct */
+struct xilinxfb_platform_data {
+ u32 rotate_screen; /* Flag to rotate display 180 degrees */
+ u32 screen_height_mm; /* Physical dimensions of screen in mm */
+ u32 screen_width_mm;
+ u32 xres, yres; /* resolution of screen in pixels */
+ u32 xvirt, yvirt; /* resolution of memory buffer */
+
+ /* Physical address of framebuffer memory; If non-zero, driver
+ * will use provided memory address instead of allocating one from
+ * the consistent pool. */
+ u32 fb_phys;
+};
+
/*
* Default xilinxfb configuration
*/
diff --git a/include/linux/xilinxfb.h b/include/linux/xilinxfb.h
deleted file mode 100644
index 5a155a9..0000000
--- a/include/linux/xilinxfb.h
+++ /dev/null
@@ -1,30 +0,0 @@
-/*
- * Platform device data for Xilinx Framebuffer device
- *
- * Copyright 2007 Secret Lab Technologies Ltd.
- *
- * This file is licensed under the terms of the GNU General Public License
- * version 2. This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
- */
-
-#ifndef __XILINXFB_H__
-#define __XILINXFB_H__
-
-#include <linux/types.h>
-
-/* ML300/403 reference design framebuffer driver platform data struct */
-struct xilinxfb_platform_data {
- u32 rotate_screen; /* Flag to rotate display 180 degrees */
- u32 screen_height_mm; /* Physical dimensions of screen in mm */
- u32 screen_width_mm;
- u32 xres, yres; /* resolution of screen in pixels */
- u32 xvirt, yvirt; /* resolution of memory buffer */
-
- /* Physical address of framebuffer memory; If non-zero, driver
- * will use provided memory address instead of allocating one from
- * the consistent pool. */
- u32 fb_phys;
-};
-
-#endif /* __XILINXFB_H__ */
--
1.8.2.3
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: [PATCH v2 4/4] video: mmp: add device tree support
From: Zhou Zhu @ 2014-02-11 3:27 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jean-Christophe Plagniol-Villard, Haojian Zhuang, Sascha Hauer,
Jingoo Han, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Chao Xie, Guoqing Li
In-Reply-To: <52F8C96F.7050107-l0cyMroinI0@public.gmane.org>
On 02/10/2014 08:43 PM, Tomi Valkeinen wrote:
> On 14/01/14 13:16, Zhou Zhu wrote:
>> add device tree support for mmp fb/controller
>> the description of DT config is at
>> Documentation/devicetree/bindings/fb/mmp-disp.txt
>>
>> Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
>> ---
>> Documentation/devicetree/bindings/fb/mmp-disp.txt | 60 ++++++++
>> drivers/video/mmp/fb/mmpfb.c | 73 ++++++----
>> drivers/video/mmp/hw/mmp_ctrl.c | 160 ++++++++++++++++-----
>> 3 files changed, 235 insertions(+), 58 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/fb/mmp-disp.txt
>>
>> diff --git a/Documentation/devicetree/bindings/fb/mmp-disp.txt b/Documentation/devicetree/bindings/fb/mmp-disp.txt
>> new file mode 100644
>> index 0000000..80702f5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/fb/mmp-disp.txt
>> @@ -0,0 +1,60 @@
>> +* Marvell MMP Display (MMP_DISP)
>> +
>> +To config mmp display, 3 parts are required to be set in dts:
>> +1. mmp fb
>> +Required properties:
>> +- compatible: Should be "marvell,<soc>-fb".
>> +- marvell,path: Should be the path this fb connecting to.
>> +- marvell,overlay-id: Should be the id of overlay this fb is on.
>> +- marvell,dmafetch-id: Should be the dma fetch id this fb using.
>> +- marvell,default-pixfmt: Should be the default pixel format when this fb is
>> +turned on.
>> +
>> +2. mmp controller
>> +Required properties:
>> +- compatible: Should be "marvell,<soc>-disp".
>> +- reg: Should be address and length of the register set for this controller.
>> +- interrupts: Should be interrupt of this controller.
>> +
>> +Required sub-node:
>> +- path:
>> +Required properties in this sub-node:
>> +-- marvell,overlay_num: Should be number of overlay this path has.
>
> If that one tells how many overlays there are, maybe "num_overlays"
> would be better.
I will update it in next version.
>
>> +-- marvell,output-type: Should be output-type settings
>> +-- marvell,path-config: Should be path-config settings
>> +-- marvell,link-config: Should be link-config settings
>> +-- marvell,rbswap: Should be rbswap settings
>
> If these terms (output-type, path-config, ...) are straight from the HW
> manual, then fine. But if they are not clear, or are driver specific,
> the values these can have should be documented here.
Yes, it's straight from HW manual.
>
>> +
>> +3. panel
>> +Required properties:
>> +- marvell,path: Should be path that this panel connected to.
>> +- other properties each panel has.
>> +
>> +Examples:
>> +
>> +fb: mmp-fb {
>> + compatible = "marvell,pxa988-fb";
>> + marvell,path = <&path1>;
>> + marvell,overlay-id = <0>;
>> + marvell,dmafetch-id = <1>;
>> + marvell,default-pixfmt = <0x108>;
>> +};
>> +
>> +disp: mmp-disp@d420b000 {
>> + compatible = "marvell,pxa988-disp";
>> + reg = <0xd420b000 0x1fc>;
>> + interrupts = <0 41 0x4>;
>> + path1: mmp-pnpath {
>> + marvell,overlay-num = <2>;
>> + marvell,output-type = <0>;
>> + marvell,path-config = <0x20000000>;
>> + marvell,link-config = <0x60000001>;
>> + marvell,rbswap = <0>;
>> + };
>> +};
>> +
>> +panel: <panel-name> {
>
> How is the panel linked to all this? The nodes above do not refer to the
> panel.
We are making panel refer to path, so when panel dev probe, it could
register to related path.
The reason we not link from path to panel is our customer sometimes
asked us to use same image pack (include dts) for different panel types
in product. We could only add all these panels in dts and detect panel
dynamically when boot. So moving panel out and making path not link to
panel but panel link to path would be more straight forward.
>
>> + ...
>> + marvell,path = <&path1>;
>> + ...
>> +};
>
> It's a bit difficult to say much about this, as I have no knowledge
> about mmp.
>
> But I don't quite understand what the pxa988-fb is. Is that some kind of
> virtual device, only used to set up fbdev side? And pxa988-disp is the
> actual hardware device?
>
> If so, I don't really think pxa988-fb should exist in the DT data at
> all, as it's not a hardware device.
Yes, fb is a virtual device for fbdev side.
In our platforms we may use more than one fb for different paths/output
panel or multi overlays on same path for composition. So we need to
configure fb settings like which path/overlay/dmafetch it connected to
for one or more fbdev.
Besides, some more configures like yres_virtual size or fixed fb mem
reserved rather than allocated which depends on platforms are also
needed although these features are not upstreamed yet.
So we put fb as a dt node here for these configures.
>
> Why isn't there just one node for pxa988-disp, which would contain all
> the above information?
We have moved out fb/panel from path due to several reasons:
1. To simplify the node. If moved these nodes in, it might be:
disp {
...
path1 {
...
panel-xxx {
}
panel-yyy {
}
...
fb0 {
}
fb1 {
}
}
path2 {
...
panel-zzz {
}
fb3 {
}
}
}
Also due to child node type might be different, we could even not
directly check child of node. The code would be complex.
2. the path of node would be too long and not so common.
e.g. the panel node in dts would be /soc/axi/disp/path1/panel-xxx, and
in sysfs, node would be /sys/devices/platform/soc/axi/path1/panel-xxx.
It would be complex and not compatible for platforms when our
bootloader/user app doing some operations to these nodes.
If we moved them out, we could move fb/panel out of soc directory so the
node would be /panel-xxx or /fb1 and simpler and compatible.
>
> Tomi
>
>
--
Thanks, -Zhou
^ permalink raw reply
* Re: [PATCH] video: imxfb: Use regulator API with LCD class for powering
From: Shawn Guo @ 2014-02-11 2:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F8C449.2080502@ti.com>
On Mon, Feb 10, 2014 at 02:21:29PM +0200, Tomi Valkeinen wrote:
> The drivers/video side looks fine. I can either merge this via fbdev
> tree if I get an ack from arch/arm/mach-imx/mach-mx27ads.c's maintainer,
Acked-by: Shawn Guo <shawn.guo@linaro.org>
^ permalink raw reply
* Re: [PATCH v2 3/4] video: mmp: add devm_mmp_get_path_by_phandle for DT
From: Zhou Zhu @ 2014-02-11 1:03 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jean-Christophe Plagniol-Villard, Haojian Zhuang, Sascha Hauer,
Jingoo Han, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Chao Xie, Guoqing Li
In-Reply-To: <52F8C6F6.5000200-l0cyMroinI0@public.gmane.org>
On 02/10/2014 08:32 PM, Tomi Valkeinen wrote:
> On 14/01/14 13:16, Zhou Zhu wrote:
>> add devm_mmp_get_path_by_phandle to replace mmp_get_path
>> for DT usage
>>
>> Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
>> ---
>> drivers/video/mmp/core.c | 35 +++++++++++++++++++++++++++++++++++
>> include/video/mmp_disp.h | 2 ++
>> 2 files changed, 37 insertions(+)
>>
>> diff --git a/drivers/video/mmp/core.c b/drivers/video/mmp/core.c
>> index b563b92..0538458 100644
>> --- a/drivers/video/mmp/core.c
>> +++ b/drivers/video/mmp/core.c
>> @@ -23,6 +23,7 @@
>> #include <linux/slab.h>
>> #include <linux/dma-mapping.h>
>> #include <linux/export.h>
>> +#include <linux/of.h>
>> #include <video/mmp_disp.h>
>>
>> static struct mmp_overlay *path_get_overlay(struct mmp_path *path,
>> @@ -156,6 +157,40 @@ struct mmp_path *mmp_get_path(const char *name)
>> EXPORT_SYMBOL_GPL(mmp_get_path);
>>
>> /*
>> + * devm_mmp_get_path_by_phandle - get path by phandle
>> + * @dev: device that want to get path
>> + * @phandle: name of phandle in device node that want to get path
>> + *
>> + * this function gets path according to node pointed by phandle
>> + * return NULL if no matching path
>> + */
>> +struct mmp_path *devm_mmp_get_path_by_phandle(struct device *dev,
>> + const char *phandle)
>> +{
>> + struct mmp_path *path;
>> + struct device_node *node;
>> +
>> + if (!dev->of_node) {
>> + dev_err(dev, "device does not have a device node entry\n");
>> + return NULL;
>> + }
>> +
>> + node = of_parse_phandle(dev->of_node, phandle, 0);
>> + if (!node) {
>> + dev_err(dev, "failed to get %s phandle in %s node\n", phandle,
>> + dev->of_node->name);
>> + return NULL;
>> + }
>> +
>> + path = mmp_get_path(node->name);
>> +
>> + of_node_put(node);
>> +
>> + return path;
>> +}
>> +EXPORT_SYMBOL_GPL(devm_mmp_get_path_by_phandle);
>
> Why is this function "devm_"? devm_ functions are supposed to
> automatically free resources when the device is removed, I don't see
> anything like that here.
Thank you for your review, I will remove "devm_" in next version.
>
> Tomi
>
>
--
Thanks, -Zhou
^ permalink raw reply
* RE: [PATCH] hyperv_fb: Add screen refresh after pause/resume operation
From: Haiyang Zhang @ 2014-02-10 20:23 UTC (permalink / raw)
To: Haiyang Zhang, FlorianSchandinat@gmx.de,
akpm@linux-foundation.org, linux-fbdev@vger.kernel.org
Cc: driverdev-devel@linuxdriverproject.org, olaf@aepfle.de,
jasowang@redhat.com, linux-kernel@vger.kernel.org
In-Reply-To: <1389658838-15765-1-git-send-email-haiyangz@microsoft.com>
> -----Original Message-----
> From: Haiyang Zhang [mailto:haiyangz@microsoft.com]
> Sent: Monday, January 13, 2014 7:21 PM
> To: FlorianSchandinat@gmx.de; akpm@linux-foundation.org; linux-
> fbdev@vger.kernel.org
> Cc: Haiyang Zhang; KY Srinivasan; olaf@aepfle.de; jasowang@redhat.com;
> linux-kernel@vger.kernel.org; driverdev-devel@linuxdriverproject.org
> Subject: [PATCH] hyperv_fb: Add screen refresh after pause/resume operation
>
> This is necessary because after VM is pause/resumed, some portion of the
> screen may need refresh.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
> ---
This was submitted before the tree re-opened. Is it still being considered?
Thanks,
- Haiyang
^ permalink raw reply
* Re: [PATCH] backlight: replace kfree with put_device
From: Lee Jones @ 2014-02-10 17:47 UTC (permalink / raw)
To: Bryan Wu
Cc: Jingoo Han, Andrew Morton, Levente Kurusa, LKML,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, FBDEV list
In-Reply-To: <CAK5ve-L54nmDX_HLPpfWQrTe=n11RFr5hyUFFcc-1otWPQde7Q@mail.gmail.com>
> >> > As per the comments on device_register, we shouldn't call kfree()
> >> > right after a device_register() failure. Instead call put_device(),
> >> > which in turn will call bl_device_release resulting in a kfree to the
> >> > full structure.
> >> >
> >> > Signed-off-by: Levente Kurusa <levex@linux.com>
> >>
> >> (+cc Bryan Wu, Lee Jones)
> >>
> >> Acked-by: Jingoo Han <jg1.han@samsung.com>
> >
> > Applied to temporary Backlight repo [1], thanks.
> >
> > [1] git://git.linaro.org/people/lee.jones/backlight.git
> >
>
> Great, I think we can put the Git URL into the MAINTAINS file for
> Backlight subsystem after your finalize the git repo.
Right, I plan do to this for MFD too. Before doing so I need to load
my GPG Key with lots of signatures, at Linus' request. I'm aiming for
the end of the month(ish).
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH] backlight: replace kfree with put_device
From: Bryan Wu @ 2014-02-10 17:37 UTC (permalink / raw)
To: Lee Jones
Cc: Jingoo Han, Andrew Morton, Levente Kurusa, LKML,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, FBDEV list
In-Reply-To: <20140210111349.GA21522@lee--X1>
On Mon, Feb 10, 2014 at 3:13 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> > As per the comments on device_register, we shouldn't call kfree()
>> > right after a device_register() failure. Instead call put_device(),
>> > which in turn will call bl_device_release resulting in a kfree to the
>> > full structure.
>> >
>> > Signed-off-by: Levente Kurusa <levex@linux.com>
>>
>> (+cc Bryan Wu, Lee Jones)
>>
>> Acked-by: Jingoo Han <jg1.han@samsung.com>
>
> Applied to temporary Backlight repo [1], thanks.
>
> [1] git://git.linaro.org/people/lee.jones/backlight.git
>
Great, I think we can put the Git URL into the MAINTAINS file for
Backlight subsystem after your finalize the git repo.
Thanks,
-Bryan
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v2 4/4] video: mmp: add device tree support
From: Tomi Valkeinen @ 2014-02-10 12:43 UTC (permalink / raw)
To: Zhou Zhu, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
Jean-Christophe Plagniol-Villard, Haojian Zhuang, Sascha Hauer,
Jingoo Han, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Chao Xie, Guoqing Li
In-Reply-To: <1389698184-28761-5-git-send-email-zzhu3-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3629 bytes --]
On 14/01/14 13:16, Zhou Zhu wrote:
> add device tree support for mmp fb/controller
> the description of DT config is at
> Documentation/devicetree/bindings/fb/mmp-disp.txt
>
> Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
> ---
> Documentation/devicetree/bindings/fb/mmp-disp.txt | 60 ++++++++
> drivers/video/mmp/fb/mmpfb.c | 73 ++++++----
> drivers/video/mmp/hw/mmp_ctrl.c | 160 ++++++++++++++++-----
> 3 files changed, 235 insertions(+), 58 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/fb/mmp-disp.txt
>
> diff --git a/Documentation/devicetree/bindings/fb/mmp-disp.txt b/Documentation/devicetree/bindings/fb/mmp-disp.txt
> new file mode 100644
> index 0000000..80702f5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fb/mmp-disp.txt
> @@ -0,0 +1,60 @@
> +* Marvell MMP Display (MMP_DISP)
> +
> +To config mmp display, 3 parts are required to be set in dts:
> +1. mmp fb
> +Required properties:
> +- compatible: Should be "marvell,<soc>-fb".
> +- marvell,path: Should be the path this fb connecting to.
> +- marvell,overlay-id: Should be the id of overlay this fb is on.
> +- marvell,dmafetch-id: Should be the dma fetch id this fb using.
> +- marvell,default-pixfmt: Should be the default pixel format when this fb is
> +turned on.
> +
> +2. mmp controller
> +Required properties:
> +- compatible: Should be "marvell,<soc>-disp".
> +- reg: Should be address and length of the register set for this controller.
> +- interrupts: Should be interrupt of this controller.
> +
> +Required sub-node:
> +- path:
> +Required properties in this sub-node:
> +-- marvell,overlay_num: Should be number of overlay this path has.
If that one tells how many overlays there are, maybe "num_overlays"
would be better.
> +-- marvell,output-type: Should be output-type settings
> +-- marvell,path-config: Should be path-config settings
> +-- marvell,link-config: Should be link-config settings
> +-- marvell,rbswap: Should be rbswap settings
If these terms (output-type, path-config, ...) are straight from the HW
manual, then fine. But if they are not clear, or are driver specific,
the values these can have should be documented here.
> +
> +3. panel
> +Required properties:
> +- marvell,path: Should be path that this panel connected to.
> +- other properties each panel has.
> +
> +Examples:
> +
> +fb: mmp-fb {
> + compatible = "marvell,pxa988-fb";
> + marvell,path = <&path1>;
> + marvell,overlay-id = <0>;
> + marvell,dmafetch-id = <1>;
> + marvell,default-pixfmt = <0x108>;
> +};
> +
> +disp: mmp-disp@d420b000 {
> + compatible = "marvell,pxa988-disp";
> + reg = <0xd420b000 0x1fc>;
> + interrupts = <0 41 0x4>;
> + path1: mmp-pnpath {
> + marvell,overlay-num = <2>;
> + marvell,output-type = <0>;
> + marvell,path-config = <0x20000000>;
> + marvell,link-config = <0x60000001>;
> + marvell,rbswap = <0>;
> + };
> +};
> +
> +panel: <panel-name> {
How is the panel linked to all this? The nodes above do not refer to the
panel.
> + ...
> + marvell,path = <&path1>;
> + ...
> +};
It's a bit difficult to say much about this, as I have no knowledge
about mmp.
But I don't quite understand what the pxa988-fb is. Is that some kind of
virtual device, only used to set up fbdev side? And pxa988-disp is the
actual hardware device?
If so, I don't really think pxa988-fb should exist in the DT data at
all, as it's not a hardware device.
Why isn't there just one node for pxa988-disp, which would contain all
the above information?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/4] video: mmp: add devm_mmp_get_path_by_phandle for DT
From: Tomi Valkeinen @ 2014-02-10 12:32 UTC (permalink / raw)
To: Zhou Zhu, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
Jean-Christophe Plagniol-Villard, Haojian Zhuang, Sascha Hauer,
Jingoo Han, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Chao Xie, Guoqing Li
In-Reply-To: <1389698184-28761-4-git-send-email-zzhu3-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1967 bytes --]
On 14/01/14 13:16, Zhou Zhu wrote:
> add devm_mmp_get_path_by_phandle to replace mmp_get_path
> for DT usage
>
> Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
> ---
> drivers/video/mmp/core.c | 35 +++++++++++++++++++++++++++++++++++
> include/video/mmp_disp.h | 2 ++
> 2 files changed, 37 insertions(+)
>
> diff --git a/drivers/video/mmp/core.c b/drivers/video/mmp/core.c
> index b563b92..0538458 100644
> --- a/drivers/video/mmp/core.c
> +++ b/drivers/video/mmp/core.c
> @@ -23,6 +23,7 @@
> #include <linux/slab.h>
> #include <linux/dma-mapping.h>
> #include <linux/export.h>
> +#include <linux/of.h>
> #include <video/mmp_disp.h>
>
> static struct mmp_overlay *path_get_overlay(struct mmp_path *path,
> @@ -156,6 +157,40 @@ struct mmp_path *mmp_get_path(const char *name)
> EXPORT_SYMBOL_GPL(mmp_get_path);
>
> /*
> + * devm_mmp_get_path_by_phandle - get path by phandle
> + * @dev: device that want to get path
> + * @phandle: name of phandle in device node that want to get path
> + *
> + * this function gets path according to node pointed by phandle
> + * return NULL if no matching path
> + */
> +struct mmp_path *devm_mmp_get_path_by_phandle(struct device *dev,
> + const char *phandle)
> +{
> + struct mmp_path *path;
> + struct device_node *node;
> +
> + if (!dev->of_node) {
> + dev_err(dev, "device does not have a device node entry\n");
> + return NULL;
> + }
> +
> + node = of_parse_phandle(dev->of_node, phandle, 0);
> + if (!node) {
> + dev_err(dev, "failed to get %s phandle in %s node\n", phandle,
> + dev->of_node->name);
> + return NULL;
> + }
> +
> + path = mmp_get_path(node->name);
> +
> + of_node_put(node);
> +
> + return path;
> +}
> +EXPORT_SYMBOL_GPL(devm_mmp_get_path_by_phandle);
Why is this function "devm_"? devm_ functions are supposed to
automatically free resources when the device is removed, I don't see
anything like that here.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video: imxfb: Use regulator API with LCD class for powering
From: Tomi Valkeinen @ 2014-02-10 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392034587.333931582@f419.i.mail.ru>
[-- Attachment #1: Type: text/plain, Size: 2500 bytes --]
On 10/02/14 14:16, Alexander Shiyan wrote:
> Понедельник, 10 февраля 2014, 14:05 +02:00 от Tomi Valkeinen <tomi.valkeinen@ti.com>:
>> On 21/12/13 13:08, Alexander Shiyan wrote:
>>> This patch replaces custom lcd_power() callback with
>>> regulator API over LCD class.
>>>
>>> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
>>> ---
>>> .../devicetree/bindings/video/fsl,imx-fb.txt | 1 +
>>> arch/arm/mach-imx/mach-mx27ads.c | 55 +++++++++++++++--
>>> drivers/video/imxfb.c | 71
>> +++++++++++++++++++---
>>> include/linux/platform_data/video-imxfb.h | 1 -
>>> 4 files changed, 114 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
>> b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
>>> index 46da08d..e6b1ee9 100644
>>> --- a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
>>> +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
>>> @@ -15,6 +15,7 @@ Required nodes:
>>> - fsl,pcr: LCDC PCR value
>>>
>>> Optional properties:
>>> +- lcd-supply: Regulator for LCD supply voltage.
>>> - fsl,dmacr: DMA Control Register value. This is optional. By default, the
>>> register is not modified as recommended by the datasheet.
>>> - fsl,lscr1: LCDC Sharp Configuration Register value.
>>> diff --git a/arch/arm/mach-imx/mach-mx27ads.c
> ...
>>> +static void __init mx27ads_regulator_init(void)
>>> +{
>>> + struct gpio_chip *vchip;
>>> +
>>> + vchip = kzalloc(sizeof(*vchip), GFP_KERNEL);
>>> + vchip->owner = THIS_MODULE;
>>> + vchip->label = "LCD";
>>> + vchip->base = MX27ADS_LCD_GPIO;
>>> + vchip->ngpio = 1;
>>> + vchip->direction_output = vgpio_dir_out;
>>> + vchip->set = vgpio_set;
>>> + gpiochip_add(vchip);
>>> +
>>> + platform_device_register_data(&platform_bus, "reg-fixed-voltage",
>>> + PLATFORM_DEVID_AUTO,
>>> + &mx27ads_lcd_regulator_pdata,
>>> + sizeof(mx27ads_lcd_regulator_pdata));
>>> +}
>>> +
>>
>> Hmm, isn't all this something that should be in the board's .dts?
>
> There are no DT support for this board yet.
Oh, ok. You added 'lcd-supply' to devtree binding documentation, so I
presumed DT is being used.
The drivers/video side looks fine. I can either merge this via fbdev
tree if I get an ack from arch/arm/mach-imx/mach-mx27ads.c's maintainer,
or this can go via imx tree with my ack.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] video: exynos: Remove OF dependency for Exynos DP
From: Tomi Valkeinen @ 2014-02-10 12:18 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1389933172-22991-1-git-send-email-sachin.kamat@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 313 bytes --]
On 17/01/14 06:32, Sachin Kamat wrote:
> Exynos is now a DT only platform. Hence there is no need
> for an explicit OF dependency. Remove it.
But the driver still depends on OF, doesn't it? I don't think it's very
good for the driver Kconfig to make presumptions about what ARCH_*
depend on.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video: imxfb: Use regulator API w =?UTF-8?B?aXRoIExDRCBjbGFzc
From: Alexander Shiyan @ 2014-02-10 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F8C091.50704@ti.com>
0J/QvtC90LXQtNC10LvRjNC90LjQuiwgMTAg0YTQtdCy0YDQsNC70Y8gMjAxNCwgMTQ6MDUgKzAy
OjAwINC+0YIgVG9taSBWYWxrZWluZW4gPHRvbWkudmFsa2VpbmVuQHRpLmNvbT46Cj4gT24gMjEv
MTIvMTMgMTM6MDgsIEFsZXhhbmRlciBTaGl5YW4gd3JvdGU6Cj4gPiBUaGlzIHBhdGNoIHJlcGxh
Y2VzIGN1c3RvbSBsY2RfcG93ZXIoKSBjYWxsYmFjayB3aXRoCj4gPiByZWd1bGF0b3IgQVBJIG92
ZXIgTENEIGNsYXNzLgo+ID4gCj4gPiBTaWduZWQtb2ZmLWJ5OiBBbGV4YW5kZXIgU2hpeWFuIDxz
aGNfd29ya0BtYWlsLnJ1Pgo+ID4gLS0tCj4gPiAgLi4uL2RldmljZXRyZWUvYmluZGluZ3Mvdmlk
ZW8vZnNsLGlteC1mYi50eHQgICAgICAgfCAgMSArCj4gPiAgYXJjaC9hcm0vbWFjaC1pbXgvbWFj
aC1teDI3YWRzLmMgICAgICAgICAgICAgICAgICAgfCA1NSArKysrKysrKysrKysrKystLQo+ID4g
IGRyaXZlcnMvdmlkZW8vaW14ZmIuYyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgNzEK
PiArKysrKysrKysrKysrKysrKysrLS0tCj4gPiAgaW5jbHVkZS9saW51eC9wbGF0Zm9ybV9kYXRh
L3ZpZGVvLWlteGZiLmggICAgICAgICAgfCAgMSAtCj4gPiAgNCBmaWxlcyBjaGFuZ2VkLCAxMTQg
aW5zZXJ0aW9ucygrKSwgMTQgZGVsZXRpb25zKC0pCj4gPiAKPiA+IGRpZmYgLS1naXQgYS9Eb2N1
bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvdmlkZW8vZnNsLGlteC1mYi50eHQKPiBiL0Rv
Y3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy92aWRlby9mc2wsaW14LWZiLnR4dAo+ID4g
aW5kZXggNDZkYTA4ZC4uZTZiMWVlOSAxMDA2NDQKPiA+IC0tLSBhL0RvY3VtZW50YXRpb24vZGV2
aWNldHJlZS9iaW5kaW5ncy92aWRlby9mc2wsaW14LWZiLnR4dAo+ID4gKysrIGIvRG9jdW1lbnRh
dGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3ZpZGVvL2ZzbCxpbXgtZmIudHh0Cj4gPiBAQCAtMTUs
NiArMTUsNyBAQCBSZXF1aXJlZCBub2RlczoKPiA+ICAJLSBmc2wscGNyOiBMQ0RDIFBDUiB2YWx1
ZQo+ID4gIAo+ID4gIE9wdGlvbmFsIHByb3BlcnRpZXM6Cj4gPiArLSBsY2Qtc3VwcGx5OiBSZWd1
bGF0b3IgZm9yIExDRCBzdXBwbHkgdm9sdGFnZS4KPiA+ICAtIGZzbCxkbWFjcjogRE1BIENvbnRy
b2wgUmVnaXN0ZXIgdmFsdWUuIFRoaXMgaXMgb3B0aW9uYWwuIEJ5IGRlZmF1bHQsIHRoZQo+ID4g
IAlyZWdpc3RlciBpcyBub3QgbW9kaWZpZWQgYXMgcmVjb21tZW5kZWQgYnkgdGhlIGRhdGFzaGVl
dC4KPiA+ICAtIGZzbCxsc2NyMTogTENEQyBTaGFycCBDb25maWd1cmF0aW9uIFJlZ2lzdGVyIHZh
bHVlLgo+ID4gZGlmZiAtLWdpdCBhL2FyY2gvYXJtL21hY2gtaW14L21hY2gtbXgyN2Fkcy5jCi4u
Lgo+ID4gK3N0YXRpYyB2b2lkIF9faW5pdCBteDI3YWRzX3JlZ3VsYXRvcl9pbml0KHZvaWQpCj4g
PiArewo+ID4gKwlzdHJ1Y3QgZ3Bpb19jaGlwICp2Y2hpcDsKPiA+ICsKPiA+ICsJdmNoaXAgPSBr
emFsbG9jKHNpemVvZigqdmNoaXApLCBHRlBfS0VSTkVMKTsKPiA+ICsJdmNoaXAtPm93bmVyCQk9
IFRISVNfTU9EVUxFOwo+ID4gKwl2Y2hpcC0+bGFiZWwJCT0gIkxDRCI7Cj4gPiArCXZjaGlwLT5i
YXNlCQk9IE1YMjdBRFNfTENEX0dQSU87Cj4gPiArCXZjaGlwLT5uZ3BpbwkJPSAxOwo+ID4gKwl2
Y2hpcC0+ZGlyZWN0aW9uX291dHB1dAk9IHZncGlvX2Rpcl9vdXQ7Cj4gPiArCXZjaGlwLT5zZXQJ
CT0gdmdwaW9fc2V0Owo+ID4gKwlncGlvY2hpcF9hZGQodmNoaXApOwo+ID4gKwo+ID4gKwlwbGF0
Zm9ybV9kZXZpY2VfcmVnaXN0ZXJfZGF0YSgmcGxhdGZvcm1fYnVzLCAicmVnLWZpeGVkLXZvbHRh
Z2UiLAo+ID4gKwkJCQkgICAgICBQTEFURk9STV9ERVZJRF9BVVRPLAo+ID4gKwkJCQkgICAgICAm
bXgyN2Fkc19sY2RfcmVndWxhdG9yX3BkYXRhLAo+ID4gKwkJCQkgICAgICBzaXplb2YobXgyN2Fk
c19sY2RfcmVndWxhdG9yX3BkYXRhKSk7Cj4gPiArfQo+ID4gKwo+IAo+IEhtbSwgaXNuJ3QgYWxs
IHRoaXMgc29tZXRoaW5nIHRoYXQgc2hvdWxkIGJlIGluIHRoZSBib2FyZCdzIC5kdHM/CgpUaGVy
ZSBhcmUgbm8gRFQgc3VwcG9ydCBmb3IgdGhpcyBib2FyZCB5ZXQuCgotLS0K
^ permalink raw reply
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