* Re: [PATCH 0/9] System Framebuffer Bus (sysfb)
From: Dave Airlie @ 2013-02-17 23:47 UTC (permalink / raw)
To: David Herrmann
Cc: linux-kernel, Florian Tobias Schandinat, linux-fbdev,
David Airlie, dri-devel
In-Reply-To: <CANq1E4TTB-Lp+eVRPpzOMnS7XNbzHJRTicwCcwXw3AUs11XFMw@mail.gmail.com>
>> I'm unsure if I like this or not, and I don't see why its greatly more
>> useful than the interface we have now.
>
> This interface at least solves the problem with having vesafb,
> uvesafb, vgacon, vga16fb, efifb, dvbe, defi and all other similar
> drivers from accessing the system framebuffer simultaneously. And
> provides a sane way of registering devices and drivers for it.
But do we have the problem now? or is it more when we get dvbe/defi?
Also vgacon is kinda different since fbcon kicks it off, not a driver,
> It also provides a way for real drivers to unload these drivers
> (sysfb_claim()) instead of using remove_conflicting_framebuffers(),
> which is horribly broken and has lots of race-conditions. (I tried
> fixing the fbdev refcounting/locking, but every time I tried, some
> driver broke because they worked around the bug. And fixing all
> drivers is just a lot of work...).
> And remove_conflicting_framebuffers() also doesn't work with
> vgacon/etc. which do _not_ use fbdev.
but vgacon is always kicked off by fbcon, so I'm not sure what etc there
is apart from it. I'd like to make fbcon a bool as well, so we don't
have to deal with it appearing after the drivers.
> We could simplify this approach by removing the bus and just providing
> the platform-device for vbefb/etc. from the arch-code. But I thought
> the bus-infrastructure allows nice rebinding of drivers if we need it
> at almost no cost.
I suspect a platform device is the right answer, since vesafb is that,
I think we should resolve vesafb vs dvbe by just making them not
config compatible, and dvbe vs defi seems like the same solution
as vesafb vs efi.
I'm just trying to work out what exactly you are fixing here, the
problems we have now don't seem to be addressed by this, if
it addresses future problems then it needs to be more upfront.
>> It doesn't solve the main problem with the current interface, which is
>> that if somebody opens has vesafb /dev/fb0, mmaps it, and modprobes a
>> real driver, things will fail either miserably or crappy from a users
>> pov.
>>
>> The internal reference counts stop vesafb from unloading due to the
>> mmaps, then i915 loads anyways and one bashes the other, or we fix so
>> i915 doesn't load and the user gets fail.
>
> It's not the mmap that prevents vesafb from unloading, it's the
> open-file instead. If a user does open(), mmap(), close(), they can
> still access the mapped memory but vesafb might get unloaded (this is,
> in fact, used by several user-space apps). So it's not about whether
> vesafb is still loaded, but rather what to do about users which have
> vesafb mmaped but don't expect it to go away.
In theory we'd have to do like GEM/TTM, and unmap_mapping_range for
all the open fd's mmaps and just point them to map something useless
or even just return -EFAULT, because really userspace needs to be told
something :-)
> So what do you propose to detect this case? Keep track of every user
> who mmap's vesafb? How can we detect when they unmap the memory? I
> think the only way to detect this is to wait for the pages'
> "mmap-count" to drop to zero and then release the memory.
>
> So lets compare this to other subsystems. If you unlink a file that is
> still mmaped, I think the file isn't removed from memory until the
> last user unmaps it. However, the memory-mapping is 'dead' in that it
> doesn't have any effect on real files.
> So why not copy that behavior to framebuffers? When a real DRM driver
> is loaded, simply reserve the VBE framebuffer-memory in VMEM until the
> last user unmaps it. But mark it 'dead' so it doesn't really belong to
> a _real_ framebuffer.
> So any access to the mmap'ed framebuffers will be a no-op as it just
> modifies 'dead' framebuffers.
>
> Another idea is copying the VBE framebuffer into the DRM driver so all
> old memory-maps are still valid. However, this prevents us from doing
> any kind of mode-setting in the DRM driver until the last fbdev user
> is gone (because there is no way to notify fbdev users of
> mode-setting).
> So in this case we are also stuck in a situation where we need to wait
> for all users to unmap their framebuffers.
It all kinda sucks, from the problems we've had previously with things
like plymouth
racing, (which all this will make much worse if we have kms vbe devices) really
what we want the system to do is give the user the proper driver asap, stalling
waiting for endless other things to let go is just going to screw
users, so I think
we need to be as upfront and brutal in the userspace interface if people mmaping
vesafb or efifb or any generic interface then expect to load a real driver, then
their old apps get killed.
> Any comments? If you have a plan on how it is supposed to work (or
> what the user-space semantics should be), tell me and I will try to
> make it work.
> I still think a central system-framebuffer registry like sysfb-bus
> (which does _not_ explicitly depend on fbdev) is the way to go.
> Whether it's a bus or not is just a matter of taste. I am willing to
> rework this.
As I said maybe I'm concentrating on the problem you aren't trying to fix,
but then I'm not sure I've enough information on the problem you are
trying to fix,
remove_confilicting_framebuffers might be ugly but it does 90% of what we want,
I just want to understand why this will make it better,
Dave.
^ permalink raw reply
* [PATCH 1/5 RESEND] video: s3c-fb: use ARCH_ dependancy
From: Jingoo Han @ 2013-02-18 5:13 UTC (permalink / raw)
To: 'Andrew Morton'
Cc: linux-kernel, linux-fbdev, 'Florian Tobias Schandinat',
'Jingoo Han'
This patch uses ARCH_ dependancy when using s3c-fb.
S3C_DEV_FB, S5P_DEV_FIMD0 cannot be enabled on EXYNOS5.
So, ARCH_ should be used as dependancy for s3c-fb.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/Kconfig | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index e7068c5..049fff1 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2025,7 +2025,8 @@ config FB_TMIO_ACCELL
config FB_S3C
tristate "Samsung S3C framebuffer support"
- depends on FB && (S3C_DEV_FB || S5P_DEV_FIMD0)
+ depends on FB && (CPU_S3C2416 || ARCH_S3C64XX || ARCH_S5P64X0 || \
+ ARCH_S5PC100 || ARCH_S5PV210 || ARCH_EXYNOS)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
--
1.7.2.5
^ permalink raw reply related
* [PATCH 2/5 RESEND] video: s3c-fb: remove duplicated S3C_FB_MAX_WIN
From: Jingoo Han @ 2013-02-18 5:14 UTC (permalink / raw)
To: 'Andrew Morton'
Cc: linux-kernel, linux-fbdev, 'Florian Tobias Schandinat',
'Jingoo Han'
In-Reply-To: <000201ce0d96$9fa550b0$deeff210$%han@samsung.com>
S3C_FB_MAX_WIN is already defined in 'plat-samsung/include/plat/fb.h'.
So, this definition in 'include/video/samsung_fimd.h' should be
removed to avoid the duplication.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
include/video/samsung_fimd.h | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index e755448..0865256 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -438,8 +438,6 @@
#define BLENDCON_NEW_8BIT_ALPHA_VALUE (1 << 0)
#define BLENDCON_NEW_4BIT_ALPHA_VALUE (0 << 0)
-#define S3C_FB_MAX_WIN (5) /* number of hardware windows available. */
-
/* Notes on per-window bpp settings
*
* Value Win0 Win1 Win2 Win3 Win 4
--
1.7.2.5
^ permalink raw reply related
* [PATCH 3/5 RESEND] video: s3c-fb: remove unnecessary brackets
From: Jingoo Han @ 2013-02-18 5:15 UTC (permalink / raw)
To: 'Andrew Morton'
Cc: linux-kernel, linux-fbdev, 'Florian Tobias Schandinat',
'Jingoo Han'
In-Reply-To: <000201ce0d96$9fa550b0$deeff210$%han@samsung.com>
This patch removes unnecessary brackets and the duplicated
VIDTCON2 definition.
Also, header comment is modified, because EXYNOS series is
supported and <mach/regs-fb.h> is not available.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
include/video/samsung_fimd.h | 199 ++++++++++++++++++++---------------------
1 files changed, 97 insertions(+), 102 deletions(-)
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index 0865256..be7b853 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -8,12 +8,8 @@
* S3C Platform - new-style fimd and framebuffer register definitions
*
* This is the register set for the fimd and new style framebuffer interface
- * found from the S3C2443 onwards into the S3C2416, S3C2450 and the
- * S3C64XX series such as the S3C6400 and S3C6410.
- *
- * The file does not contain the cpu specific items which are based on
- * whichever architecture is selected, it only contains the core of the
- * register set. See <mach/regs-fb.h> to get the specifics.
+ * found from the S3C2443 onwards into the S3C2416, S3C2450, the
+ * S3C64XX series such as the S3C6400 and S3C6410, and EXYNOS series.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -22,10 +18,10 @@
/* VIDCON0 */
-#define VIDCON0 (0x00)
+#define VIDCON0 0x00
#define VIDCON0_INTERLACE (1 << 29)
#define VIDCON0_VIDOUT_MASK (0x7 << 26)
-#define VIDCON0_VIDOUT_SHIFT (26)
+#define VIDCON0_VIDOUT_SHIFT 26
#define VIDCON0_VIDOUT_RGB (0x0 << 26)
#define VIDCON0_VIDOUT_TV (0x1 << 26)
#define VIDCON0_VIDOUT_I80_LDI0 (0x2 << 26)
@@ -35,7 +31,7 @@
#define VIDCON0_VIDOUT_WB_I80_LDI1 (0x7 << 26)
#define VIDCON0_L1_DATA_MASK (0x7 << 23)
-#define VIDCON0_L1_DATA_SHIFT (23)
+#define VIDCON0_L1_DATA_SHIFT 23
#define VIDCON0_L1_DATA_16BPP (0x0 << 23)
#define VIDCON0_L1_DATA_18BPP16 (0x1 << 23)
#define VIDCON0_L1_DATA_18BPP9 (0x2 << 23)
@@ -44,7 +40,7 @@
#define VIDCON0_L1_DATA_16BPP8 (0x5 << 23)
#define VIDCON0_L0_DATA_MASK (0x7 << 20)
-#define VIDCON0_L0_DATA_SHIFT (20)
+#define VIDCON0_L0_DATA_SHIFT 20
#define VIDCON0_L0_DATA_16BPP (0x0 << 20)
#define VIDCON0_L0_DATA_18BPP16 (0x1 << 20)
#define VIDCON0_L0_DATA_18BPP9 (0x2 << 20)
@@ -53,7 +49,7 @@
#define VIDCON0_L0_DATA_16BPP8 (0x5 << 20)
#define VIDCON0_PNRMODE_MASK (0x3 << 17)
-#define VIDCON0_PNRMODE_SHIFT (17)
+#define VIDCON0_PNRMODE_SHIFT 17
#define VIDCON0_PNRMODE_RGB (0x0 << 17)
#define VIDCON0_PNRMODE_BGR (0x1 << 17)
#define VIDCON0_PNRMODE_SERIAL_RGB (0x2 << 17)
@@ -61,14 +57,14 @@
#define VIDCON0_CLKVALUP (1 << 16)
#define VIDCON0_CLKVAL_F_MASK (0xff << 6)
-#define VIDCON0_CLKVAL_F_SHIFT (6)
-#define VIDCON0_CLKVAL_F_LIMIT (0xff)
+#define VIDCON0_CLKVAL_F_SHIFT 6
+#define VIDCON0_CLKVAL_F_LIMIT 0xff
#define VIDCON0_CLKVAL_F(_x) ((_x) << 6)
#define VIDCON0_VLCKFREE (1 << 5)
#define VIDCON0_CLKDIR (1 << 4)
#define VIDCON0_CLKSEL_MASK (0x3 << 2)
-#define VIDCON0_CLKSEL_SHIFT (2)
+#define VIDCON0_CLKSEL_SHIFT 2
#define VIDCON0_CLKSEL_HCLK (0x0 << 2)
#define VIDCON0_CLKSEL_LCD (0x1 << 2)
#define VIDCON0_CLKSEL_27M (0x3 << 2)
@@ -76,13 +72,13 @@
#define VIDCON0_ENVID (1 << 1)
#define VIDCON0_ENVID_F (1 << 0)
-#define VIDCON1 (0x04)
+#define VIDCON1 0x04
#define VIDCON1_LINECNT_MASK (0x7ff << 16)
-#define VIDCON1_LINECNT_SHIFT (16)
+#define VIDCON1_LINECNT_SHIFT 16
#define VIDCON1_LINECNT_GET(_v) (((_v) >> 16) & 0x7ff)
#define VIDCON1_FSTATUS_EVEN (1 << 15)
#define VIDCON1_VSTATUS_MASK (0x3 << 13)
-#define VIDCON1_VSTATUS_SHIFT (13)
+#define VIDCON1_VSTATUS_SHIFT 13
#define VIDCON1_VSTATUS_VSYNC (0x0 << 13)
#define VIDCON1_VSTATUS_BACKPORCH (0x1 << 13)
#define VIDCON1_VSTATUS_ACTIVE (0x2 << 13)
@@ -98,12 +94,12 @@
/* VIDCON2 */
-#define VIDCON2 (0x08)
+#define VIDCON2 0x08
#define VIDCON2_EN601 (1 << 23)
#define VIDCON2_TVFMTSEL_SW (1 << 14)
#define VIDCON2_TVFMTSEL1_MASK (0x3 << 12)
-#define VIDCON2_TVFMTSEL1_SHIFT (12)
+#define VIDCON2_TVFMTSEL1_SHIFT 12
#define VIDCON2_TVFMTSEL1_RGB (0x0 << 12)
#define VIDCON2_TVFMTSEL1_YUV422 (0x1 << 12)
#define VIDCON2_TVFMTSEL1_YUV444 (0x2 << 12)
@@ -115,74 +111,73 @@
* Might not be present in the S3C6410 documentation,
* but tests prove it's there almost for sure; shouldn't hurt in any case.
*/
-#define PRTCON (0x0c)
+#define PRTCON 0x0c
#define PRTCON_PROTECT (1 << 11)
/* VIDTCON0 */
-#define VIDTCON0 (0x10)
+#define VIDTCON0 0x10
#define VIDTCON0_VBPDE_MASK (0xff << 24)
-#define VIDTCON0_VBPDE_SHIFT (24)
-#define VIDTCON0_VBPDE_LIMIT (0xff)
+#define VIDTCON0_VBPDE_SHIFT 24
+#define VIDTCON0_VBPDE_LIMIT 0xff
#define VIDTCON0_VBPDE(_x) ((_x) << 24)
#define VIDTCON0_VBPD_MASK (0xff << 16)
-#define VIDTCON0_VBPD_SHIFT (16)
-#define VIDTCON0_VBPD_LIMIT (0xff)
+#define VIDTCON0_VBPD_SHIFT 16
+#define VIDTCON0_VBPD_LIMIT 0xff
#define VIDTCON0_VBPD(_x) ((_x) << 16)
#define VIDTCON0_VFPD_MASK (0xff << 8)
-#define VIDTCON0_VFPD_SHIFT (8)
-#define VIDTCON0_VFPD_LIMIT (0xff)
+#define VIDTCON0_VFPD_SHIFT 8
+#define VIDTCON0_VFPD_LIMIT 0xff
#define VIDTCON0_VFPD(_x) ((_x) << 8)
#define VIDTCON0_VSPW_MASK (0xff << 0)
-#define VIDTCON0_VSPW_SHIFT (0)
-#define VIDTCON0_VSPW_LIMIT (0xff)
+#define VIDTCON0_VSPW_SHIFT 0
+#define VIDTCON0_VSPW_LIMIT 0xff
#define VIDTCON0_VSPW(_x) ((_x) << 0)
/* VIDTCON1 */
-#define VIDTCON1 (0x14)
+#define VIDTCON1 0x14
#define VIDTCON1_VFPDE_MASK (0xff << 24)
-#define VIDTCON1_VFPDE_SHIFT (24)
-#define VIDTCON1_VFPDE_LIMIT (0xff)
+#define VIDTCON1_VFPDE_SHIFT 24
+#define VIDTCON1_VFPDE_LIMIT 0xff
#define VIDTCON1_VFPDE(_x) ((_x) << 24)
#define VIDTCON1_HBPD_MASK (0xff << 16)
-#define VIDTCON1_HBPD_SHIFT (16)
-#define VIDTCON1_HBPD_LIMIT (0xff)
+#define VIDTCON1_HBPD_SHIFT 16
+#define VIDTCON1_HBPD_LIMIT 0xff
#define VIDTCON1_HBPD(_x) ((_x) << 16)
#define VIDTCON1_HFPD_MASK (0xff << 8)
-#define VIDTCON1_HFPD_SHIFT (8)
-#define VIDTCON1_HFPD_LIMIT (0xff)
+#define VIDTCON1_HFPD_SHIFT 8
+#define VIDTCON1_HFPD_LIMIT 0xff
#define VIDTCON1_HFPD(_x) ((_x) << 8)
#define VIDTCON1_HSPW_MASK (0xff << 0)
-#define VIDTCON1_HSPW_SHIFT (0)
-#define VIDTCON1_HSPW_LIMIT (0xff)
+#define VIDTCON1_HSPW_SHIFT 0
+#define VIDTCON1_HSPW_LIMIT 0xff
#define VIDTCON1_HSPW(_x) ((_x) << 0)
-#define VIDTCON2 (0x18)
-#define VIDTCON2 (0x18)
+#define VIDTCON2 0x18
#define VIDTCON2_LINEVAL_E(_x) ((((_x) & 0x800) >> 11) << 23)
#define VIDTCON2_LINEVAL_MASK (0x7ff << 11)
-#define VIDTCON2_LINEVAL_SHIFT (11)
-#define VIDTCON2_LINEVAL_LIMIT (0x7ff)
+#define VIDTCON2_LINEVAL_SHIFT 11
+#define VIDTCON2_LINEVAL_LIMIT 0x7ff
#define VIDTCON2_LINEVAL(_x) (((_x) & 0x7ff) << 11)
#define VIDTCON2_HOZVAL_E(_x) ((((_x) & 0x800) >> 11) << 22)
#define VIDTCON2_HOZVAL_MASK (0x7ff << 0)
-#define VIDTCON2_HOZVAL_SHIFT (0)
-#define VIDTCON2_HOZVAL_LIMIT (0x7ff)
+#define VIDTCON2_HOZVAL_SHIFT 0
+#define VIDTCON2_HOZVAL_LIMIT 0x7ff
#define VIDTCON2_HOZVAL(_x) (((_x) & 0x7ff) << 0)
/* WINCONx */
#define WINCON(_win) (0x20 + ((_win) * 4))
#define WINCONx_CSCWIDTH_MASK (0x3 << 26)
-#define WINCONx_CSCWIDTH_SHIFT (26)
+#define WINCONx_CSCWIDTH_SHIFT 26
#define WINCONx_CSCWIDTH_WIDE (0x0 << 26)
#define WINCONx_CSCWIDTH_NARROW (0x3 << 26)
#define WINCONx_ENLOCAL (1 << 22)
@@ -195,14 +190,14 @@
#define WINCONx_WSWP (1 << 15)
#define WINCONx_YCbCr (1 << 13)
#define WINCONx_BURSTLEN_MASK (0x3 << 9)
-#define WINCONx_BURSTLEN_SHIFT (9)
+#define WINCONx_BURSTLEN_SHIFT 9
#define WINCONx_BURSTLEN_16WORD (0x0 << 9)
#define WINCONx_BURSTLEN_8WORD (0x1 << 9)
#define WINCONx_BURSTLEN_4WORD (0x2 << 9)
#define WINCONx_ENWIN (1 << 0)
#define WINCON0_BPPMODE_MASK (0xf << 2)
-#define WINCON0_BPPMODE_SHIFT (2)
+#define WINCON0_BPPMODE_SHIFT 2
#define WINCON0_BPPMODE_1BPP (0x0 << 2)
#define WINCON0_BPPMODE_2BPP (0x1 << 2)
#define WINCON0_BPPMODE_4BPP (0x2 << 2)
@@ -215,7 +210,7 @@
#define WINCON1_LOCALSEL_CAMIF (1 << 23)
#define WINCON1_BLD_PIX (1 << 6)
#define WINCON1_BPPMODE_MASK (0xf << 2)
-#define WINCON1_BPPMODE_SHIFT (2)
+#define WINCON1_BPPMODE_SHIFT 2
#define WINCON1_BPPMODE_1BPP (0x0 << 2)
#define WINCON1_BPPMODE_2BPP (0x1 << 2)
#define WINCON1_BPPMODE_4BPP (0x2 << 2)
@@ -234,7 +229,7 @@
#define WINCON1_ALPHA_SEL (1 << 1)
/* S5PV210 */
-#define SHADOWCON (0x34)
+#define SHADOWCON 0x34
#define SHADOWCON_WINx_PROTECT(_win) (1 << (10 + (_win)))
/* DMA channels (all windows) */
#define SHADOWCON_CHx_ENABLE(_win) (1 << (_win))
@@ -243,52 +238,52 @@
/* VIDOSDx */
-#define VIDOSD_BASE (0x40)
+#define VIDOSD_BASE 0x40
#define VIDOSDxA_TOPLEFT_X_E(_x) ((((_x) & 0x800) >> 11) << 23)
#define VIDOSDxA_TOPLEFT_X_MASK (0x7ff << 11)
-#define VIDOSDxA_TOPLEFT_X_SHIFT (11)
-#define VIDOSDxA_TOPLEFT_X_LIMIT (0x7ff)
+#define VIDOSDxA_TOPLEFT_X_SHIFT 11
+#define VIDOSDxA_TOPLEFT_X_LIMIT 0x7ff
#define VIDOSDxA_TOPLEFT_X(_x) (((_x) & 0x7ff) << 11)
#define VIDOSDxA_TOPLEFT_Y_E(_x) ((((_x) & 0x800) >> 11) << 22)
#define VIDOSDxA_TOPLEFT_Y_MASK (0x7ff << 0)
-#define VIDOSDxA_TOPLEFT_Y_SHIFT (0)
-#define VIDOSDxA_TOPLEFT_Y_LIMIT (0x7ff)
+#define VIDOSDxA_TOPLEFT_Y_SHIFT 0
+#define VIDOSDxA_TOPLEFT_Y_LIMIT 0x7ff
#define VIDOSDxA_TOPLEFT_Y(_x) (((_x) & 0x7ff) << 0)
#define VIDOSDxB_BOTRIGHT_X_E(_x) ((((_x) & 0x800) >> 11) << 23)
#define VIDOSDxB_BOTRIGHT_X_MASK (0x7ff << 11)
-#define VIDOSDxB_BOTRIGHT_X_SHIFT (11)
-#define VIDOSDxB_BOTRIGHT_X_LIMIT (0x7ff)
+#define VIDOSDxB_BOTRIGHT_X_SHIFT 11
+#define VIDOSDxB_BOTRIGHT_X_LIMIT 0x7ff
#define VIDOSDxB_BOTRIGHT_X(_x) (((_x) & 0x7ff) << 11)
#define VIDOSDxB_BOTRIGHT_Y_E(_x) ((((_x) & 0x800) >> 11) << 22)
#define VIDOSDxB_BOTRIGHT_Y_MASK (0x7ff << 0)
-#define VIDOSDxB_BOTRIGHT_Y_SHIFT (0)
-#define VIDOSDxB_BOTRIGHT_Y_LIMIT (0x7ff)
+#define VIDOSDxB_BOTRIGHT_Y_SHIFT 0
+#define VIDOSDxB_BOTRIGHT_Y_LIMIT 0x7ff
#define VIDOSDxB_BOTRIGHT_Y(_x) (((_x) & 0x7ff) << 0)
/* For VIDOSD[1..4]C */
#define VIDISD14C_ALPHA0_R(_x) ((_x) << 20)
#define VIDISD14C_ALPHA0_G_MASK (0xf << 16)
-#define VIDISD14C_ALPHA0_G_SHIFT (16)
-#define VIDISD14C_ALPHA0_G_LIMIT (0xf)
+#define VIDISD14C_ALPHA0_G_SHIFT 16
+#define VIDISD14C_ALPHA0_G_LIMIT 0xf
#define VIDISD14C_ALPHA0_G(_x) ((_x) << 16)
#define VIDISD14C_ALPHA0_B_MASK (0xf << 12)
-#define VIDISD14C_ALPHA0_B_SHIFT (12)
-#define VIDISD14C_ALPHA0_B_LIMIT (0xf)
+#define VIDISD14C_ALPHA0_B_SHIFT 12
+#define VIDISD14C_ALPHA0_B_LIMIT 0xf
#define VIDISD14C_ALPHA0_B(_x) ((_x) << 12)
#define VIDISD14C_ALPHA1_R_MASK (0xf << 8)
-#define VIDISD14C_ALPHA1_R_SHIFT (8)
-#define VIDISD14C_ALPHA1_R_LIMIT (0xf)
+#define VIDISD14C_ALPHA1_R_SHIFT 8
+#define VIDISD14C_ALPHA1_R_LIMIT 0xf
#define VIDISD14C_ALPHA1_R(_x) ((_x) << 8)
#define VIDISD14C_ALPHA1_G_MASK (0xf << 4)
-#define VIDISD14C_ALPHA1_G_SHIFT (4)
-#define VIDISD14C_ALPHA1_G_LIMIT (0xf)
+#define VIDISD14C_ALPHA1_G_SHIFT 4
+#define VIDISD14C_ALPHA1_G_LIMIT 0xf
#define VIDISD14C_ALPHA1_G(_x) ((_x) << 4)
#define VIDISD14C_ALPHA1_B_MASK (0xf << 0)
-#define VIDISD14C_ALPHA1_B_SHIFT (0)
-#define VIDISD14C_ALPHA1_B_LIMIT (0xf)
+#define VIDISD14C_ALPHA1_B_SHIFT 0
+#define VIDISD14C_ALPHA1_B_LIMIT 0xf
#define VIDISD14C_ALPHA1_B(_x) ((_x) << 0)
/* Video buffer addresses */
@@ -300,22 +295,22 @@
#define VIDW_BUF_SIZE_OFFSET_E(_x) ((((_x) & 0x2000) >> 13) << 27)
#define VIDW_BUF_SIZE_OFFSET_MASK (0x1fff << 13)
-#define VIDW_BUF_SIZE_OFFSET_SHIFT (13)
-#define VIDW_BUF_SIZE_OFFSET_LIMIT (0x1fff)
+#define VIDW_BUF_SIZE_OFFSET_SHIFT 13
+#define VIDW_BUF_SIZE_OFFSET_LIMIT 0x1fff
#define VIDW_BUF_SIZE_OFFSET(_x) (((_x) & 0x1fff) << 13)
#define VIDW_BUF_SIZE_PAGEWIDTH_E(_x) ((((_x) & 0x2000) >> 13) << 26)
#define VIDW_BUF_SIZE_PAGEWIDTH_MASK (0x1fff << 0)
-#define VIDW_BUF_SIZE_PAGEWIDTH_SHIFT (0)
-#define VIDW_BUF_SIZE_PAGEWIDTH_LIMIT (0x1fff)
+#define VIDW_BUF_SIZE_PAGEWIDTH_SHIFT 0
+#define VIDW_BUF_SIZE_PAGEWIDTH_LIMIT 0x1fff
#define VIDW_BUF_SIZE_PAGEWIDTH(_x) (((_x) & 0x1fff) << 0)
/* Interrupt controls and status */
-#define VIDINTCON0 (0x130)
+#define VIDINTCON0 0x130
#define VIDINTCON0_FIFOINTERVAL_MASK (0x3f << 20)
-#define VIDINTCON0_FIFOINTERVAL_SHIFT (20)
-#define VIDINTCON0_FIFOINTERVAL_LIMIT (0x3f)
+#define VIDINTCON0_FIFOINTERVAL_SHIFT 20
+#define VIDINTCON0_FIFOINTERVAL_LIMIT 0x3f
#define VIDINTCON0_FIFOINTERVAL(_x) ((_x) << 20)
#define VIDINTCON0_INT_SYSMAINCON (1 << 19)
@@ -323,7 +318,7 @@
#define VIDINTCON0_INT_I80IFDONE (1 << 17)
#define VIDINTCON0_FRAMESEL0_MASK (0x3 << 15)
-#define VIDINTCON0_FRAMESEL0_SHIFT (15)
+#define VIDINTCON0_FRAMESEL0_SHIFT 15
#define VIDINTCON0_FRAMESEL0_BACKPORCH (0x0 << 15)
#define VIDINTCON0_FRAMESEL0_VSYNC (0x1 << 15)
#define VIDINTCON0_FRAMESEL0_ACTIVE (0x2 << 15)
@@ -338,7 +333,7 @@
#define VIDINTCON0_INT_FRAME (1 << 12)
#define VIDINTCON0_FIFIOSEL_MASK (0x7f << 5)
-#define VIDINTCON0_FIFIOSEL_SHIFT (5)
+#define VIDINTCON0_FIFIOSEL_SHIFT 5
#define VIDINTCON0_FIFIOSEL_WINDOW0 (0x1 << 5)
#define VIDINTCON0_FIFIOSEL_WINDOW1 (0x2 << 5)
#define VIDINTCON0_FIFIOSEL_WINDOW2 (0x10 << 5)
@@ -346,7 +341,7 @@
#define VIDINTCON0_FIFIOSEL_WINDOW4 (0x40 << 5)
#define VIDINTCON0_FIFOLEVEL_MASK (0x7 << 2)
-#define VIDINTCON0_FIFOLEVEL_SHIFT (2)
+#define VIDINTCON0_FIFOLEVEL_SHIFT 2
#define VIDINTCON0_FIFOLEVEL_TO25PC (0x0 << 2)
#define VIDINTCON0_FIFOLEVEL_TO50PC (0x1 << 2)
#define VIDINTCON0_FIFOLEVEL_TO75PC (0x2 << 2)
@@ -354,46 +349,46 @@
#define VIDINTCON0_FIFOLEVEL_FULL (0x4 << 2)
#define VIDINTCON0_INT_FIFO_MASK (0x3 << 0)
-#define VIDINTCON0_INT_FIFO_SHIFT (0)
+#define VIDINTCON0_INT_FIFO_SHIFT 0
#define VIDINTCON0_INT_ENABLE (1 << 0)
-#define VIDINTCON1 (0x134)
+#define VIDINTCON1 0x134
#define VIDINTCON1_INT_I180 (1 << 2)
#define VIDINTCON1_INT_FRAME (1 << 1)
#define VIDINTCON1_INT_FIFO (1 << 0)
/* Window colour-key control registers */
-#define WKEYCON (0x140) /* 6410,V210 */
+#define WKEYCON 0x140
-#define WKEYCON0 (0x00)
-#define WKEYCON1 (0x04)
+#define WKEYCON0 0x00
+#define WKEYCON1 0x04
#define WxKEYCON0_KEYBL_EN (1 << 26)
#define WxKEYCON0_KEYEN_F (1 << 25)
#define WxKEYCON0_DIRCON (1 << 24)
#define WxKEYCON0_COMPKEY_MASK (0xffffff << 0)
-#define WxKEYCON0_COMPKEY_SHIFT (0)
-#define WxKEYCON0_COMPKEY_LIMIT (0xffffff)
+#define WxKEYCON0_COMPKEY_SHIFT 0
+#define WxKEYCON0_COMPKEY_LIMIT 0xffffff
#define WxKEYCON0_COMPKEY(_x) ((_x) << 0)
#define WxKEYCON1_COLVAL_MASK (0xffffff << 0)
-#define WxKEYCON1_COLVAL_SHIFT (0)
-#define WxKEYCON1_COLVAL_LIMIT (0xffffff)
+#define WxKEYCON1_COLVAL_SHIFT 0
+#define WxKEYCON1_COLVAL_LIMIT 0xffffff
#define WxKEYCON1_COLVAL(_x) ((_x) << 0)
/* Dithering control */
-#define DITHMODE (0x170)
+#define DITHMODE 0x170
#define DITHMODE_R_POS_MASK (0x3 << 5)
-#define DITHMODE_R_POS_SHIFT (5)
+#define DITHMODE_R_POS_SHIFT 5
#define DITHMODE_R_POS_8BIT (0x0 << 5)
#define DITHMODE_R_POS_6BIT (0x1 << 5)
#define DITHMODE_R_POS_5BIT (0x2 << 5)
#define DITHMODE_G_POS_MASK (0x3 << 3)
-#define DITHMODE_G_POS_SHIFT (3)
+#define DITHMODE_G_POS_SHIFT 3
#define DITHMODE_G_POS_8BIT (0x0 << 3)
#define DITHMODE_G_POS_6BIT (0x1 << 3)
#define DITHMODE_G_POS_5BIT (0x2 << 3)
#define DITHMODE_B_POS_MASK (0x3 << 1)
-#define DITHMODE_B_POS_SHIFT (1)
+#define DITHMODE_B_POS_SHIFT 1
#define DITHMODE_B_POS_8BIT (0x0 << 1)
#define DITHMODE_B_POS_6BIT (0x1 << 1)
#define DITHMODE_B_POS_5BIT (0x2 << 1)
@@ -403,18 +398,18 @@
#define WINxMAP(_win) (0x180 + ((_win) * 4))
#define WINxMAP_MAP (1 << 24)
#define WINxMAP_MAP_COLOUR_MASK (0xffffff << 0)
-#define WINxMAP_MAP_COLOUR_SHIFT (0)
-#define WINxMAP_MAP_COLOUR_LIMIT (0xffffff)
+#define WINxMAP_MAP_COLOUR_SHIFT 0
+#define WINxMAP_MAP_COLOUR_LIMIT 0xffffff
#define WINxMAP_MAP_COLOUR(_x) ((_x) << 0)
/* Winodw palette control */
-#define WPALCON (0x1A0)
+#define WPALCON 0x1A0
#define WPALCON_PAL_UPDATE (1 << 9)
#define WPALCON_W4PAL_16BPP_A555 (1 << 8)
#define WPALCON_W3PAL_16BPP_A555 (1 << 7)
#define WPALCON_W2PAL_16BPP_A555 (1 << 6)
#define WPALCON_W1PAL_MASK (0x7 << 3)
-#define WPALCON_W1PAL_SHIFT (3)
+#define WPALCON_W1PAL_SHIFT 3
#define WPALCON_W1PAL_25BPP_A888 (0x0 << 3)
#define WPALCON_W1PAL_24BPP (0x1 << 3)
#define WPALCON_W1PAL_19BPP_A666 (0x2 << 3)
@@ -423,7 +418,7 @@
#define WPALCON_W1PAL_16BPP_A555 (0x5 << 3)
#define WPALCON_W1PAL_16BPP_565 (0x6 << 3)
#define WPALCON_W0PAL_MASK (0x7 << 0)
-#define WPALCON_W0PAL_SHIFT (0)
+#define WPALCON_W0PAL_SHIFT 0
#define WPALCON_W0PAL_25BPP_A888 (0x0 << 0)
#define WPALCON_W0PAL_24BPP (0x1 << 0)
#define WPALCON_W0PAL_19BPP_A666 (0x2 << 0)
@@ -433,7 +428,7 @@
#define WPALCON_W0PAL_16BPP_565 (0x6 << 0)
/* Blending equation control */
-#define BLENDCON (0x260)
+#define BLENDCON 0x260
#define BLENDCON_NEW_MASK (1 << 0)
#define BLENDCON_NEW_8BIT_ALPHA_VALUE (1 << 0)
#define BLENDCON_NEW_4BIT_ALPHA_VALUE (0 << 0)
@@ -460,8 +455,8 @@
*/
/* FIMD Version 8 register offset definitions */
-#define FIMD_V8_VIDTCON0 (0x20010)
-#define FIMD_V8_VIDTCON1 (0x20014)
-#define FIMD_V8_VIDTCON2 (0x20018)
-#define FIMD_V8_VIDTCON3 (0x2001C)
-#define FIMD_V8_VIDCON1 (0x20004)
+#define FIMD_V8_VIDTCON0 0x20010
+#define FIMD_V8_VIDTCON1 0x20014
+#define FIMD_V8_VIDTCON2 0x20018
+#define FIMD_V8_VIDTCON3 0x2001C
+#define FIMD_V8_VIDCON1 0x20004
--
1.7.2.5
^ permalink raw reply related
* [PATCH 4/5 RESEND] video: s3c-fb: add the bit definitions for CSC EQ709 and EQ601
From: Jingoo Han @ 2013-02-18 5:16 UTC (permalink / raw)
To: 'Andrew Morton'
Cc: linux-kernel, linux-fbdev, 'Florian Tobias Schandinat',
'Jingoo Han'
In-Reply-To: <000201ce0d96$9fa550b0$deeff210$%han@samsung.com>
This patch adds the bit definitions for CSC EQ709 and EQ601.
These definitons are used to control the CSC parameter such as
equation 709 and equation 601.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
include/video/samsung_fimd.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index be7b853..2f95d9a 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -176,6 +176,8 @@
/* WINCONx */
#define WINCON(_win) (0x20 + ((_win) * 4))
+#define WINCONx_CSCCON_EQ601 (0x0 << 28)
+#define WINCONx_CSCCON_EQ709 (0x1 << 28)
#define WINCONx_CSCWIDTH_MASK (0x3 << 26)
#define WINCONx_CSCWIDTH_SHIFT 26
#define WINCONx_CSCWIDTH_WIDE (0x0 << 26)
--
1.7.2.5
^ permalink raw reply related
* [PATCH 5/5 RESEND] video: s3c-fb: Fix typo in definition of VIDCON1_VSTATUS_FRONTPORCH value
From: Jingoo Han @ 2013-02-18 5:18 UTC (permalink / raw)
To: 'Andrew Morton'
Cc: linux-kernel, linux-fbdev, 'Florian Tobias Schandinat',
'Jingoo Han'
In-Reply-To: <000201ce0d96$9fa550b0$deeff210$%han@samsung.com>
From: Tomasz Figa <t.figa@samsung.com>
The correct value for VIDCON1_VSTATUS_FRONTPORCH is 3, not 0.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
include/video/samsung_fimd.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index 2f95d9a..b039320 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -82,7 +82,7 @@
#define VIDCON1_VSTATUS_VSYNC (0x0 << 13)
#define VIDCON1_VSTATUS_BACKPORCH (0x1 << 13)
#define VIDCON1_VSTATUS_ACTIVE (0x2 << 13)
-#define VIDCON1_VSTATUS_FRONTPORCH (0x0 << 13)
+#define VIDCON1_VSTATUS_FRONTPORCH (0x3 << 13)
#define VIDCON1_VCLK_MASK (0x3 << 9)
#define VIDCON1_VCLK_HOLD (0x0 << 9)
#define VIDCON1_VCLK_RUN (0x1 << 9)
--
1.7.2.5
^ permalink raw reply related
* [PATCH 1/2 RESEND] video: exynos_dp: add missing of_node_put()
From: Jingoo Han @ 2013-02-18 5:24 UTC (permalink / raw)
To: 'Andrew Morton'
Cc: linux-kernel, linux-fbdev, 'Florian Tobias Schandinat',
'Jingoo Han'
of_find_node_by_name() returns a node pointer with refcount
incremented, use of_node_put() on it when done.
of_find_node_by_name() will call of_node_put() against
the node pass to from parameter, thus we also need to call
of_node_get(from) before calling of_find_node_by_name().
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/exynos/exynos_dp_core.c | 19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index 2ed9776..c7374c0 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -965,10 +965,11 @@ static struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
{
- struct device_node *dp_phy_node;
+ struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
u32 phy_base;
+ int ret = 0;
- dp_phy_node = of_find_node_by_name(dp->dev->of_node, "dptx-phy");
+ dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
if (!dp_phy_node) {
dev_err(dp->dev, "could not find dptx-phy node\n");
return -ENODEV;
@@ -976,22 +977,28 @@ static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
dev_err(dp->dev, "faild to get reg for dptx-phy\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto err;
}
if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
&dp->enable_mask)) {
dev_err(dp->dev, "faild to get enable-mask for dptx-phy\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto err;
}
dp->phy_addr = ioremap(phy_base, SZ_4);
if (!dp->phy_addr) {
dev_err(dp->dev, "failed to ioremap dp-phy\n");
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err;
}
- return 0;
+err:
+ of_node_put(dp_phy_node);
+
+ return ret;
}
static void exynos_dp_phy_init(struct exynos_dp_device *dp)
--
1.7.2.5
^ permalink raw reply related
* [PATCH 2/2 RESEND] video: exynos_dp: move disable_irq() to exynos_dp_suspend()
From: Jingoo Han @ 2013-02-18 5:25 UTC (permalink / raw)
To: 'Andrew Morton'
Cc: linux-kernel, linux-fbdev, 'Florian Tobias Schandinat',
'Jingoo Han'
In-Reply-To: <000801ce0d98$2e103fd0$8a30bf70$%han@samsung.com>
From: Ajay Kumar <ajaykumar.rs@samsung.com>
disable_irq() should be moved to exynos_dp_suspend(), because
enable_irq() is called at exynos_dp_resume().
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/exynos/exynos_dp_core.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index c7374c0..de9d4da 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -1124,8 +1124,6 @@ static int exynos_dp_remove(struct platform_device *pdev)
struct exynos_dp_platdata *pdata = pdev->dev.platform_data;
struct exynos_dp_device *dp = platform_get_drvdata(pdev);
- disable_irq(dp->irq);
-
flush_work(&dp->hotplug_work);
if (pdev->dev.of_node) {
@@ -1148,6 +1146,8 @@ static int exynos_dp_suspend(struct device *dev)
struct exynos_dp_platdata *pdata = dev->platform_data;
struct exynos_dp_device *dp = dev_get_drvdata(dev);
+ disable_irq(dp->irq);
+
flush_work(&dp->hotplug_work);
if (dev->of_node) {
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
From: Archit Taneja @ 2013-02-18 7:45 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Aaro Koskinen, linux-omap, linux-fbdev
In-Reply-To: <511C8B16.5060605@ti.com>
On Thursday 14 February 2013 12:28 PM, Tomi Valkeinen wrote:
> On 2013-02-14 08:51, Archit Taneja wrote:
>> On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
>>> Hi,
>>>
>>> On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
>>>> +static struct panel_acx565akm_data *get_panel_data(struct
>>>> omap_dss_device *dssdev)
>>>> +{
>>>> + return (struct panel_acx565akm_data *) dssdev->data;
>>>> +}
>>>> +
>>>> static int acx_panel_probe(struct omap_dss_device *dssdev)
>>>> {
>>>> int r;
>>>> struct acx565akm_device *md = &acx_dev;
>>>> + struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
>>>
>>> Why the get_panel_data function is needed, isn't the cast unnecessary?
>>
>> the 'data' member of omap_dss_device has the type 'void *', we need to
>> cast it to access the panel_acx565akm_data struct pointer.
>
> You don't need an explicit cast to assign a void pointer to a pointer to
> something else (or vice versa, I think).
>
> I remember us having similar constructs in some other panel drivers
> also. I think they are unnecessary also.
I was considering keeping the get_panel_data() funcs in the panel
drivers though. This way, whenever the way of retrieving platform data
changes because of DT or CDF or something else, we would just need to
modify the get_panel_data func.
Archit
^ permalink raw reply
* Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
From: Tomi Valkeinen @ 2013-02-18 8:11 UTC (permalink / raw)
To: Archit Taneja; +Cc: Aaro Koskinen, linux-omap, linux-fbdev
In-Reply-To: <5121D941.3060609@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]
On 2013-02-18 09:33, Archit Taneja wrote:
> On Thursday 14 February 2013 12:28 PM, Tomi Valkeinen wrote:
>> On 2013-02-14 08:51, Archit Taneja wrote:
>>> On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
>>>> Hi,
>>>>
>>>> On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
>>>>> +static struct panel_acx565akm_data *get_panel_data(struct
>>>>> omap_dss_device *dssdev)
>>>>> +{
>>>>> + return (struct panel_acx565akm_data *) dssdev->data;
>>>>> +}
>>>>> +
>>>>> static int acx_panel_probe(struct omap_dss_device *dssdev)
>>>>> {
>>>>> int r;
>>>>> struct acx565akm_device *md = &acx_dev;
>>>>> + struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
>>>>
>>>> Why the get_panel_data function is needed, isn't the cast unnecessary?
>>>
>>> the 'data' member of omap_dss_device has the type 'void *', we need to
>>> cast it to access the panel_acx565akm_data struct pointer.
>>
>> You don't need an explicit cast to assign a void pointer to a pointer to
>> something else (or vice versa, I think).
>>
>> I remember us having similar constructs in some other panel drivers
>> also. I think they are unnecessary also.
>
> I was considering keeping the get_panel_data() funcs in the panel
> drivers though. This way, whenever the way of retrieving platform data
> changes because of DT or CDF or something else, we would just need to
> modify the get_panel_data func.
I think it's simpler if we manage the fetching of the platform data in
probe one, and just store a struct panel_acx565akm_data or such to the
panel driver's data.
For DT we don't have platform data, but we can create the same platform
data struct from the DT properties.
So the above would become something like:
struct acx565akm_device *md = &acx_dev;
struct panel_acx565akm_data *panel_data = md->pdata;
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH v2] fbdev: Add Renesas vdc4 framebuffer driver
From: phil.edworthy @ 2013-02-18 8:14 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1347267372-22949-1-git-send-email-phil.edworthy@renesas.com>
Hi Simon,
> On Fri, Oct 05, 2012 at 05:34:54PM +0100, phil.edworthy@renesas.com
wrote:
> > Hi,
> >
> > Any news on this patch?
>
> Phil, did this patch get merged in the end?
No, I sent a couple of emails to try to get some response but nothing. I
suspect that it was my fault in that I only realised somewhat later that I
wasn't signed up to the fbdev ml.
Phil
> > > From: Jingoo Han <jg1.han@samsung.com>
> > > To: "'Phil Edworthy'" <phil.edworthy@renesas.com>,
> > > Cc: "'Florian Tobias Schandinat'" <FlorianSchandinat@gmx.de>, linux-
> > > fbdev@vger.kernel.org, linux-sh@vger.kernel.org, "'Jingoo Han'"
> > > <jg1.han@samsung.com>
> > > Date: 11/09/2012 03:31
> > > Subject: Re: [PATCH v2] fbdev: Add Renesas vdc4 framebuffer driver
> > >
> > > On Monday, September 10, 2012 5:56 PM Phil Edworthy wrote
> > > >
> > > > The vdc4 display hardware is found on the sh7269 device.
> > > >
> > > > Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
> > >
> > >
> > > Reviewed-by: Jingoo Han <jg1.han@samsung.com>
> > >
> > > Best regards,
> > > Jingoo Han
> > >
> > >
> > > > ---
> > > > v2:
> > > > * Use devm_ variants of clk_get, ioremap_nocache, request_irq.
> > > > * Replace spaces with tabs.
> > > > * Check ren_vdc4_start return value.
> > > > * Fix headers used.
> > > >
> > > > drivers/video/Kconfig | 10 +
> > > > drivers/video/Makefile | 1 +
> > > > drivers/video/ren_vdc4fb.c | 641 +++++++++++++++++++++++++++++++
> > > +++++++++++++
> > > > include/video/ren_vdc4fb.h | 19 ++
> > > > 4 files changed, 671 insertions(+), 0 deletions(-)
> > > > create mode 100644 drivers/video/ren_vdc4fb.c
> > > > create mode 100644 include/video/ren_vdc4fb.h
> > >
> > >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply
* Re: [PATCH 16/33] OMAPDSS: acx565akm panel: handle gpios in panel driver
From: Archit Taneja @ 2013-02-18 8:35 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Aaro Koskinen, linux-omap, linux-fbdev
In-Reply-To: <5121E24A.6090502@ti.com>
On Monday 18 February 2013 01:41 PM, Tomi Valkeinen wrote:
> On 2013-02-18 09:33, Archit Taneja wrote:
>> On Thursday 14 February 2013 12:28 PM, Tomi Valkeinen wrote:
>>> On 2013-02-14 08:51, Archit Taneja wrote:
>>>> On Wednesday 13 February 2013 10:59 PM, Aaro Koskinen wrote:
>>>>> Hi,
>>>>>
>>>>> On Wed, Feb 13, 2013 at 07:52:08PM +0530, Archit Taneja wrote:
>>>>>> +static struct panel_acx565akm_data *get_panel_data(struct
>>>>>> omap_dss_device *dssdev)
>>>>>> +{
>>>>>> + return (struct panel_acx565akm_data *) dssdev->data;
>>>>>> +}
>>>>>> +
>>>>>> static int acx_panel_probe(struct omap_dss_device *dssdev)
>>>>>> {
>>>>>> int r;
>>>>>> struct acx565akm_device *md = &acx_dev;
>>>>>> + struct panel_acx565akm_data *panel_data = get_panel_data(dssdev);
>>>>>
>>>>> Why the get_panel_data function is needed, isn't the cast unnecessary?
>>>>
>>>> the 'data' member of omap_dss_device has the type 'void *', we need to
>>>> cast it to access the panel_acx565akm_data struct pointer.
>>>
>>> You don't need an explicit cast to assign a void pointer to a pointer to
>>> something else (or vice versa, I think).
>>>
>>> I remember us having similar constructs in some other panel drivers
>>> also. I think they are unnecessary also.
>>
>> I was considering keeping the get_panel_data() funcs in the panel
>> drivers though. This way, whenever the way of retrieving platform data
>> changes because of DT or CDF or something else, we would just need to
>> modify the get_panel_data func.
>
> I think it's simpler if we manage the fetching of the platform data in
> probe one, and just store a struct panel_acx565akm_data or such to the
> panel driver's data.
>
> For DT we don't have platform data, but we can create the same platform
> data struct from the DT properties.
>
> So the above would become something like:
>
> struct acx565akm_device *md = &acx_dev;
> struct panel_acx565akm_data *panel_data = md->pdata;
okay, that seems to be a better way.
Archit
^ permalink raw reply
* Re: [PATCH] OMAPDSS: tpo-td043 panel: fix data passing between SPI/DSS parts
From: Tomi Valkeinen @ 2013-02-18 8:40 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1361061792-2350-1-git-send-email-notasas@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 659 bytes --]
On 2013-02-17 02:43, Grazvydas Ignotas wrote:
> This driver uses omap_dss_device that it gets from a board file through
> SPI platfrom_data pointer to pass data from SPI to DSS portion of the
> driver by using dev_set_drvdata(). However this trick no longer works,
> as DSS core no longer uses omap_dss_device from a board file to create
> the real device, so use a global pointer to accomplish this instead,
> like other SPI panel drivers do.
Thanks, looks fine to me.
As a side note, I'm working on removing the omap_dss_device stuff, and
after that change this driver can be a plain SPI driver. That should
make things simpler.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* [PATCH v2] mfd: as3711: add OF support
From: Guennadi Liakhovetski @ 2013-02-18 9:57 UTC (permalink / raw)
To: linux-kernel
Cc: Magnus Damm, Simon Horman, devicetree-discuss, Samuel Ortiz,
Mark Brown, Liam Girdwood, Richard Purdie, Andrew Morton,
linux-fbdev
Add device-tree bindings to the AS3711 regulator and backlight drivers.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
v2:
1. remove of_device_is_available() - it breaks compilation with CONFIG_OF
disabled and is redundant anyway - I2C devices are only registered for
available devoces
2. add parenthesis to eliminate a compiler warning
Documentation/devicetree/bindings/mfd/as3711.txt | 73 +++++++++++++
drivers/mfd/as3711.c | 27 ++++-
drivers/regulator/as3711-regulator.c | 69 ++++++++++++-
drivers/video/backlight/as3711_bl.c | 118 +++++++++++++++++++++-
4 files changed, 279 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/as3711.txt
diff --git a/Documentation/devicetree/bindings/mfd/as3711.txt b/Documentation/devicetree/bindings/mfd/as3711.txt
new file mode 100644
index 0000000..d98cf18
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/as3711.txt
@@ -0,0 +1,73 @@
+AS3711 is an I2C PMIC from Austria MicroSystems with multiple DCDC and LDO power
+supplies, a battery charger and an RTC. So far only bindings for the two stepup
+DCDC converters are defined. Other DCDC and LDO supplies are configured, using
+standard regulator properties, they must belong to a sub-node, called
+"regulators" and be called "sd1" to "sd4" and "ldo1" to "ldo8." Stepup converter
+configuration should be placed in a subnode, called "backlight."
+
+Compulsory properties:
+- compatible : must be "ams,as3711"
+- reg : specifies the I2C address
+
+To use the SU1 converter as a backlight source the following two properties must
+be provided:
+- su1-dev : framebuffer phandle
+- su1-max-uA : maximum current
+
+To use the SU2 converter as a backlight source the following two properties must
+be provided:
+- su2-dev : framebuffer phandle
+- su1-max-uA : maximum current
+
+Additionally one of these properties must be provided to select the type of
+feedback used:
+- su2-feedback-voltage : voltage feedback is used
+- su2-feedback-curr1 : CURR1 input used for current feedback
+- su2-feedback-curr2 : CURR2 input used for current feedback
+- su2-feedback-curr3 : CURR3 input used for current feedback
+- su2-feedback-curr-auto: automatic current feedback selection
+
+and one of these to select the over-voltage protection pin
+- su2-fbprot-lx-sd4 : LX_SD4 is used for over-voltage protection
+- su2-fbprot-gpio2 : GPIO2 is used for over-voltage protection
+- su2-fbprot-gpio3 : GPIO3 is used for over-voltage protection
+- su2-fbprot-gpio4 : GPIO4 is used for over-voltage protection
+
+If "su2-feedback-curr-auto" is selected, one or more of the following properties
+have to be specified:
+- su2-auto-curr1 : use CURR1 input for current feedback
+- su2-auto-curr2 : use CURR2 input for current feedback
+- su2-auto-curr3 : use CURR3 input for current feedback
+
+Example:
+
+as3711@40 {
+ compatible = "ams,as3711";
+ reg = <0x40>;
+
+ regulators {
+ sd4 {
+ regulator-name = "1.215V";
+ regulator-min-microvolt = <1215000>;
+ regulator-max-microvolt = <1235000>;
+ };
+ ldo2 {
+ regulator-name = "2.8V CPU";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+
+ backlight {
+ compatible = "ams,as3711-bl";
+ su2-dev = <&lcdc>;
+ su2-max-uA = <36000>;
+ su2-feedback-curr-auto;
+ su2-fbprot-gpio4;
+ su2-auto-curr1;
+ su2-auto-curr2;
+ su2-auto-curr3;
+ };
+};
diff --git a/drivers/mfd/as3711.c b/drivers/mfd/as3711.c
index e994c96..01e4141 100644
--- a/drivers/mfd/as3711.c
+++ b/drivers/mfd/as3711.c
@@ -112,16 +112,34 @@ static const struct regmap_config as3711_regmap_config = {
.cache_type = REGCACHE_RBTREE,
};
+#ifdef CONFIG_OF
+static struct of_device_id as3711_of_match[] = {
+ {.compatible = "ams,as3711",},
+ {}
+};
+MODULE_DEVICE_TABLE(of, as3711_of_match);
+#endif
+
static int as3711_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct as3711 *as3711;
- struct as3711_platform_data *pdata = client->dev.platform_data;
+ struct as3711_platform_data *pdata;
unsigned int id1, id2;
int ret;
- if (!pdata)
- dev_dbg(&client->dev, "Platform data not found\n");
+ if (!client->dev.of_node) {
+ pdata = client->dev.platform_data;
+ if (!pdata)
+ dev_dbg(&client->dev, "Platform data not found\n");
+ } else {
+ pdata = devm_kzalloc(&client->dev,
+ sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(&client->dev, "Failed to allocate pdata\n");
+ return -ENOMEM;
+ }
+ }
as3711 = devm_kzalloc(&client->dev, sizeof(struct as3711), GFP_KERNEL);
if (!as3711) {
@@ -193,7 +211,8 @@ static struct i2c_driver as3711_i2c_driver = {
.driver = {
.name = "as3711",
.owner = THIS_MODULE,
- },
+ .of_match_table = of_match_ptr(as3711_of_match),
+ },
.probe = as3711_i2c_probe,
.remove = as3711_i2c_remove,
.id_table = as3711_i2c_id,
diff --git a/drivers/regulator/as3711-regulator.c b/drivers/regulator/as3711-regulator.c
index f0ba8c4..cf145fc 100644
--- a/drivers/regulator/as3711-regulator.c
+++ b/drivers/regulator/as3711-regulator.c
@@ -13,9 +13,11 @@
#include <linux/init.h>
#include <linux/mfd/as3711.h>
#include <linux/module.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/regulator/driver.h>
+#include <linux/regulator/of_regulator.h>
#include <linux/slab.h>
struct as3711_regulator_info {
@@ -276,6 +278,57 @@ static struct as3711_regulator_info as3711_reg_info[] = {
#define AS3711_REGULATOR_NUM ARRAY_SIZE(as3711_reg_info)
+static const char *as3711_regulator_of_names[AS3711_REGULATOR_NUM] = {
+ [AS3711_REGULATOR_SD_1] = "sd1",
+ [AS3711_REGULATOR_SD_2] = "sd2",
+ [AS3711_REGULATOR_SD_3] = "sd3",
+ [AS3711_REGULATOR_SD_4] = "sd4",
+ [AS3711_REGULATOR_LDO_1] = "ldo1",
+ [AS3711_REGULATOR_LDO_2] = "ldo2",
+ [AS3711_REGULATOR_LDO_3] = "ldo3",
+ [AS3711_REGULATOR_LDO_4] = "ldo4",
+ [AS3711_REGULATOR_LDO_5] = "ldo5",
+ [AS3711_REGULATOR_LDO_6] = "ldo6",
+ [AS3711_REGULATOR_LDO_7] = "ldo7",
+ [AS3711_REGULATOR_LDO_8] = "ldo8",
+};
+
+static int as3711_regulator_parse_dt(struct device *dev)
+{
+ struct as3711_regulator_pdata *pdata = dev_get_platdata(dev);
+ struct device_node *regulators + of_find_node_by_name(dev->parent->of_node, "regulators");
+ struct of_regulator_match *matches, *match;
+ const int count = AS3711_REGULATOR_NUM;
+ int ret, i;
+
+ if (!regulators) {
+ dev_err(dev, "regulator node not found\n");
+ return -ENODEV;
+ }
+
+ matches = devm_kzalloc(dev, sizeof(*matches) * count, GFP_KERNEL);
+ if (!matches)
+ return -ENOMEM;
+
+ for (i = 0, match = matches; i < count; i++, match++) {
+ match->name = as3711_regulator_of_names[i];
+ match->driver_data = as3711_reg_info + i;
+ }
+
+ ret = of_regulator_match(dev->parent, regulators, matches, count);
+ if (ret < 0) {
+ dev_err(dev, "Error parsing regulator init data: %d\n", ret);
+ return ret;
+ }
+
+ for (i = 0, match = matches; i < count; i++, match++)
+ if (match->of_node)
+ pdata->init_data[i] = match->init_data;
+
+ return 0;
+}
+
static int as3711_regulator_probe(struct platform_device *pdev)
{
struct as3711_regulator_pdata *pdata = dev_get_platdata(&pdev->dev);
@@ -289,8 +342,18 @@ static int as3711_regulator_probe(struct platform_device *pdev)
int ret;
int id;
- if (!pdata)
- dev_dbg(&pdev->dev, "No platform data...\n");
+ if (!pdata) {
+ dev_err(&pdev->dev, "No platform data...\n");
+ return -ENODEV;
+ }
+
+ if (pdev->dev.parent->of_node) {
+ ret = as3711_regulator_parse_dt(&pdev->dev);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "DT parsing failed: %d\n", ret);
+ return ret;
+ }
+ }
regs = devm_kzalloc(&pdev->dev, AS3711_REGULATOR_NUM *
sizeof(struct as3711_regulator), GFP_KERNEL);
@@ -300,7 +363,7 @@ static int as3711_regulator_probe(struct platform_device *pdev)
}
for (id = 0, ri = as3711_reg_info; id < AS3711_REGULATOR_NUM; ++id, ri++) {
- reg_data = pdata ? pdata->init_data[id] : NULL;
+ reg_data = pdata->init_data[id];
/* No need to register if there is no regulator data */
if (!reg_data)
diff --git a/drivers/video/backlight/as3711_bl.c b/drivers/video/backlight/as3711_bl.c
index c6bc65d..c78e4cb 100644
--- a/drivers/video/backlight/as3711_bl.c
+++ b/drivers/video/backlight/as3711_bl.c
@@ -257,6 +257,109 @@ static int as3711_bl_register(struct platform_device *pdev,
return 0;
}
+static int as3711_backlight_parse_dt(struct device *dev)
+{
+ struct as3711_bl_pdata *pdata = dev_get_platdata(dev);
+ struct device_node *bl + of_find_node_by_name(dev->parent->of_node, "backlight"), *fb;
+ int ret;
+
+ if (!bl) {
+ dev_dbg(dev, "backlight node not found\n");
+ return -ENODEV;
+ }
+
+ fb = of_parse_phandle(bl, "su1-dev", 0);
+ if (fb) {
+ pdata->su1_fb = fb->full_name;
+
+ ret = of_property_read_u32(bl, "su1-max-uA", &pdata->su1_max_uA);
+ if (pdata->su1_max_uA <= 0)
+ ret = -EINVAL;
+ if (ret < 0)
+ return ret;
+ }
+
+ fb = of_parse_phandle(bl, "su2-dev", 0);
+ if (fb) {
+ int count = 0;
+
+ pdata->su2_fb = fb->full_name;
+
+ ret = of_property_read_u32(bl, "su2-max-uA", &pdata->su2_max_uA);
+ if (pdata->su2_max_uA <= 0)
+ ret = -EINVAL;
+ if (ret < 0)
+ return ret;
+
+ if (of_find_property(bl, "su2-feedback-voltage", NULL)) {
+ pdata->su2_feedback = AS3711_SU2_VOLTAGE;
+ count++;
+ }
+ if (of_find_property(bl, "su2-feedback-curr1", NULL)) {
+ pdata->su2_feedback = AS3711_SU2_CURR1;
+ count++;
+ }
+ if (of_find_property(bl, "su2-feedback-curr2", NULL)) {
+ pdata->su2_feedback = AS3711_SU2_CURR2;
+ count++;
+ }
+ if (of_find_property(bl, "su2-feedback-curr3", NULL)) {
+ pdata->su2_feedback = AS3711_SU2_CURR3;
+ count++;
+ }
+ if (of_find_property(bl, "su2-feedback-curr-auto", NULL)) {
+ pdata->su2_feedback = AS3711_SU2_CURR_AUTO;
+ count++;
+ }
+ if (count != 1)
+ return -EINVAL;
+
+ count = 0;
+ if (of_find_property(bl, "su2-fbprot-lx-sd4", NULL)) {
+ pdata->su2_fbprot = AS3711_SU2_LX_SD4;
+ count++;
+ }
+ if (of_find_property(bl, "su2-fbprot-gpio2", NULL)) {
+ pdata->su2_fbprot = AS3711_SU2_GPIO2;
+ count++;
+ }
+ if (of_find_property(bl, "su2-fbprot-gpio3", NULL)) {
+ pdata->su2_fbprot = AS3711_SU2_GPIO3;
+ count++;
+ }
+ if (of_find_property(bl, "su2-fbprot-gpio4", NULL)) {
+ pdata->su2_fbprot = AS3711_SU2_GPIO4;
+ count++;
+ }
+ if (count != 1)
+ return -EINVAL;
+
+ count = 0;
+ if (of_find_property(bl, "su2-auto-curr1", NULL)) {
+ pdata->su2_auto_curr1 = true;
+ count++;
+ }
+ if (of_find_property(bl, "su2-auto-curr2", NULL)) {
+ pdata->su2_auto_curr2 = true;
+ count++;
+ }
+ if (of_find_property(bl, "su2-auto-curr3", NULL)) {
+ pdata->su2_auto_curr3 = true;
+ count++;
+ }
+
+ /*
+ * At least one su2-auto-curr* must be specified iff
+ * AS3711_SU2_CURR_AUTO is used
+ */
+ if (!count ^ (pdata->su2_feedback != AS3711_SU2_CURR_AUTO))
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int as3711_backlight_probe(struct platform_device *pdev)
{
struct as3711_bl_pdata *pdata = dev_get_platdata(&pdev->dev);
@@ -266,11 +369,24 @@ static int as3711_backlight_probe(struct platform_device *pdev)
unsigned int max_brightness;
int ret;
- if (!pdata || (!pdata->su1_fb && !pdata->su2_fb)) {
+ if (!pdata) {
dev_err(&pdev->dev, "No platform data, exiting...\n");
return -ENODEV;
}
+ if (pdev->dev.parent->of_node) {
+ ret = as3711_backlight_parse_dt(&pdev->dev);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "DT parsing failed: %d\n", ret);
+ return ret;
+ }
+ }
+
+ if (!pdata->su1_fb && !pdata->su2_fb) {
+ dev_err(&pdev->dev, "No framebuffer specified\n");
+ return -EINVAL;
+ }
+
/*
* Due to possible hardware damage I chose to block all modes,
* unsupported on my hardware. Anyone, wishing to use any of those modes
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH RFC] video: Add Hyper-V Synthetic Video Frame Buffer Driver
From: Geert Uytterhoeven @ 2013-02-18 10:29 UTC (permalink / raw)
To: Haiyang Zhang
Cc: FlorianSchandinat, linux-fbdev, kys, olaf, jasowang, linux-kernel,
devel
In-Reply-To: <1360955396-14183-1-git-send-email-haiyangz@microsoft.com>
On Fri, Feb 15, 2013 at 8:09 PM, Haiyang Zhang <haiyangz@microsoft.com> wrote:
> +/* Allocate framebuffer memory */
> +#define FOUR_MEGA (4*1024*1024)
> +#define NALLOC 10
> +static void *hvfb_getmem(void)
> +{
> + ulong *p;
> + int i, j;
> + ulong ret = 0;
> +
> + if (screen_fb_size = FOUR_MEGA) {
> + ret = __get_free_pages(GFP_KERNEL|__GFP_ZERO,
> + get_order(FOUR_MEGA));
> + goto out1;
> + }
> +
> + if (screen_fb_size != FOUR_MEGA * 2)
> + return NULL;
> +
> + /*
> + * Windows 2012 requires frame buffer size to be 8MB, which exceeds
> + * the limit of __get_free_pages(). So, we allocate multiple 4MB
> + * chunks, and find out two adjacent ones.
> + */
> + p = kmalloc(NALLOC * sizeof(ulong), GFP_KERNEL);
> + if (!p)
> + return NULL;
> +
> + for (i = 0; i < NALLOC; i++)
> + p[i] = __get_free_pages(GFP_KERNEL|__GFP_ZERO,
> + get_order(FOUR_MEGA));
> +
> + for (i = 0; i < NALLOC; i++)
> + for (j = 0; j < NALLOC; j++) {
> + if (p[j] && p[i] && virt_to_phys((void *)p[j]) -
> + virt_to_phys((void *)p[i]) = FOUR_MEGA &&
> + p[j] - p[i] = FOUR_MEGA) {
> + ret = p[i];
> + goto out;
> + }
> + }
> +
> +out:
> + for (i = 0; i < NALLOC; i++)
> + if (p[i] && !(ret && (p[i] = ret || p[i] = ret + FOUR_MEGA)))
> + free_pages(p[i], get_order(FOUR_MEGA));
> +
> + kfree(p);
> +
> +out1:
> + if (!ret)
> + return NULL;
> +
> + /* Get an extra ref-count to prevent page error when x-window exits */
> + for (i = 0; i < screen_fb_size; i += PAGE_SIZE)
> + atomic_inc(&virt_to_page((void *)ret + i)->_count);
> +
> + return (void *)ret;
> +}
Please instead reserve some memory at boot time, or allocate it very early
(cfr. ps3fb).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v17 2/7] video: add display_timing and videomode
From: Tomi Valkeinen @ 2013-02-18 14:09 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: devicetree-discuss, Dave Airlie, Rob Herring, linux-fbdev,
dri-devel, Laurent Pinchart, Thierry Reding,
Guennady Liakhovetski, linux-media, Tomi Valkeinen,
Stephen Warren, Florian Tobias Schandinat, Rob Clark,
Leela Krishna Amudala, Mohammed, Afzal, kernel
In-Reply-To: <1359104515-8907-3-git-send-email-s.trumtrar@pengutronix.de>
Hi Steffen,
On 2013-01-25 11:01, Steffen Trumtrar wrote:
> +/* VESA display monitor timing parameters */
> +#define VESA_DMT_HSYNC_LOW BIT(0)
> +#define VESA_DMT_HSYNC_HIGH BIT(1)
> +#define VESA_DMT_VSYNC_LOW BIT(2)
> +#define VESA_DMT_VSYNC_HIGH BIT(3)
> +
> +/* display specific flags */
> +#define DISPLAY_FLAGS_DE_LOW BIT(0) /* data enable flag */
> +#define DISPLAY_FLAGS_DE_HIGH BIT(1)
> +#define DISPLAY_FLAGS_PIXDATA_POSEDGE BIT(2) /* drive data on pos. edge */
> +#define DISPLAY_FLAGS_PIXDATA_NEGEDGE BIT(3) /* drive data on neg. edge */
> +#define DISPLAY_FLAGS_INTERLACED BIT(4)
> +#define DISPLAY_FLAGS_DOUBLESCAN BIT(5)
<snip>
> + unsigned int dmt_flags; /* VESA DMT flags */
> + unsigned int data_flags; /* video data flags */
Why did you go for this approach? To be able to represent
true/false/not-specified?
Would it be simpler to just have "flags" field? What does it give us to
have those two separately?
Should the above say raising edge/falling edge instead of positive
edge/negative edge?
Tomi
^ permalink raw reply
* Re: [PATCH v2 0/1] OMAP4: DSS: Add panel for Blaze Tablet boards
From: Ruslan Bilovol @ 2013-02-18 14:30 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: andi, FlorianSchandinat, linux-fbdev, linux-kernel, linux-omap
In-Reply-To: <511CAD5D.2050502@ti.com>
Hi Tomi,
On Thu, Feb 14, 2013 at 11:24 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2013-02-14 02:07, Ruslan Bilovol wrote:
>
>> This patch is exactly a part of mainlining of the BlazeTablet board support :)
>> The goal is to have as much as possible support of this board in the
>> 'vanilla' kernel.
>> The BlazeTablet mainlining is already ongoing (
>> https://patchwork.kernel.org/patch/2118281/ )
>> and I hope we will have some support of this board in near future.
>> The BlazeTablet's LCD panel support is very important thing for us to
>> have it in mainline because
>> without it the BlazeTablet becomes a 'black brick' and it is painful
>> for us to port this
>> driver against each new version of kernel.
>
> Ok, good to hear you're pushing it to mainline. However, you should
> mentally prepare for it being a black brick =(.
>
> Tony said he's not adding new board files, only DT from now on. The
> display subsystem driver and the panel drivers do not work with DT yet,
> and it will still take some time for that to realize.
>
> Thus adding this driver would help nothing, as it couldn't be used. And
> after the DSS and the panel drivers are made to work with DT (which is a
> big job, needing large rewrites of the drivers), there's a rework that
> has to be done with this driver to make it compatible with the new DSS
> model.
>
> So, I'm still inclined to say that we shouldn't merge this.
Thanks for explanation.
Do you have some plan when DSS will be ready to port this driver?
(3.10, 3.11 or later)?
Best regards,
Ruslan
>
> Tomi
>
>
^ permalink raw reply
* Re: [PATCH v2 1/1] OMAP4: DSS: Add panel for Blaze Tablet boards
From: Ruslan Bilovol @ 2013-02-18 14:33 UTC (permalink / raw)
To: Andi Shyti
Cc: Andi Shyti, tomi.valkeinen, FlorianSchandinat, linux-fbdev,
linux-kernel, linux-omap
In-Reply-To: <20130217141757.GA5228@jack.whiskey>
Hi Andy,
On Sun, Feb 17, 2013 at 4:17 PM, Andi Shyti <andi.shyti@gmail.com> wrote:
>> >> + char name[30];
>> >> + char buf[50];
>> >> +
>> >> + if (size >= sizeof(buf))
>> >> + size = sizeof(buf);
>> >
>> > what's the point of this?
>>
>> This is a way to limit copied from userspace data by available buffer size,
>> widely used in current kernel sources. Are you implying there is some
>> better (more graceful) way?
>
> No indeed :)
> There is no other way, sorry for polluting the review :)
>
>> >> + if ((pins[2] & 1) || (pins[3] & 1)) {
>> >> + lanes |= (1 << 1);
>> >> + ret |= tc358765_write_register(dssdev, PPI_D0S_CLRSIPOCOUNT,
>> >> + board_data->clrsipo);
>> >> + }
>> >> + if ((pins[4] & 1) || (pins[5] & 1)) {
>> >> + lanes |= (1 << 2);
>> >> + ret |= tc358765_write_register(dssdev, PPI_D1S_CLRSIPOCOUNT,
>> >> + board_data->clrsipo);
>> >> + }
>> >> + if ((pins[6] & 1) || (pins[7] & 1)) {
>> >> + lanes |= (1 << 3);
>> >> + ret |= tc358765_write_register(dssdev, PPI_D2S_CLRSIPOCOUNT,
>> >> + board_data->clrsipo);
>> >> + }
>> >> + if ((pins[8] & 1) || (pins[9] & 1)) {
>> >> + lanes |= (1 << 4);
>> >> + ret |= tc358765_write_register(dssdev, PPI_D3S_CLRSIPOCOUNT,
>> >> + board_data->clrsipo);
>> >> + }
>> >
>> > Can't this be done in one single multiwrighting command since
>> > this registers are consecutive?
>> >
>> > You build once the array to write and you send it at once.
>>
>> In this particular case I disagree. Yes, it will be a little bit
>> faster, however:
>> 1) we write this for panel initialization only (so no impact in other cases)
>> 2) multiwriting of array will make code reading more difficult
>>
>> So I would like to leave it as-is
>> Same is for next your similar comment.
>
> If the hw is providing us some ways for simplifying the code I
> would use it. In this case we are talking about the i2c feature
> of multiwriting and multireading.
>
> Let's assume that we want to write on 8 different consecutive
> registers. In my opinion this aproach is quite "heavy":
>
> uX register;
>
> register = value1;
> i2c_write(REG1, register);
>
> register = value2;
> i2c_write(REG2, register);
>
> ...
>
> Usually what I do is this:
>
> uX register[8];
>
> for (i = 0; i < 8; i++)
> register |= valuei << i; (or register[i] = valuei or whatever)
>
> i2c_multi_write(REG, register, 8);
>
> of course this is a simplified example in pseudocode. I think
> it's more readable and we are making a better use of the i2c
> protocol.
>
> In your case you have some if statement that are making the multi
> writing more difficult, but still is not impossible.
>
> At the end it's still a matter of taste, so that you are free to
> choose whatever you prefer :)
Thank you for reviewing this.
Unfortunately, this driver is not accepted due to future OMAP DSS rework.
I will take into account your comments when will reimplement it for new
DSS architecture.
Thanks and best regards,
Ruslan
>
> Andi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* RE: [PATCH RFC] video: Add Hyper-V Synthetic Video Frame Buffer Driver
From: Haiyang Zhang @ 2013-02-18 16:09 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: FlorianSchandinat@gmx.de, linux-fbdev@vger.kernel.org,
KY Srinivasan, olaf@aepfle.de, jasowang@redhat.com,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org
In-Reply-To: <CAMuHMdXJ+waZJ95bRLPYYsneXf98c=9d9n1jdkWMKhUpAAB_RA@mail.gmail.com>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBnZWVydC51eXR0ZXJob2V2ZW5A
Z21haWwuY29tDQo+IFttYWlsdG86Z2VlcnQudXl0dGVyaG9ldmVuQGdtYWlsLmNvbV0gT24gQmVo
YWxmIE9mIEdlZXJ0IFV5dHRlcmhvZXZlbg0KPiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDE4LCAy
MDEzIDU6MjkgQU0NCj4gVG86IEhhaXlhbmcgWmhhbmcNCj4gQ2M6IEZsb3JpYW5TY2hhbmRpbmF0
QGdteC5kZTsgbGludXgtZmJkZXZAdmdlci5rZXJuZWwub3JnOyBLWSBTcmluaXZhc2FuOw0KPiBv
bGFmQGFlcGZsZS5kZTsgamFzb3dhbmdAcmVkaGF0LmNvbTsgbGludXgta2VybmVsQHZnZXIua2Vy
bmVsLm9yZzsNCj4gZGV2ZWxAbGludXhkcml2ZXJwcm9qZWN0Lm9yZw0KPiBTdWJqZWN0OiBSZTog
W1BBVENIIFJGQ10gdmlkZW86IEFkZCBIeXBlci1WIFN5bnRoZXRpYyBWaWRlbyBGcmFtZSBCdWZm
ZXINCj4gRHJpdmVyDQo+IA0KPiBPbiBGcmksIEZlYiAxNSwgMjAxMyBhdCA4OjA5IFBNLCBIYWl5
YW5nIFpoYW5nIDxoYWl5YW5nekBtaWNyb3NvZnQuY29tPg0KPiB3cm90ZToNCj4gPiArLyogQWxs
b2NhdGUgZnJhbWVidWZmZXIgbWVtb3J5ICovDQo+DQo+IFBsZWFzZSBpbnN0ZWFkIHJlc2VydmUg
c29tZSBtZW1vcnkgYXQgYm9vdCB0aW1lLCBvciBhbGxvY2F0ZSBpdCB2ZXJ5IGVhcmx5DQo+IChj
ZnIuIHBzM2ZiKS4NCg0KSSB3aWxsIGxvb2sgaW50byB0aGlzLg0KDQpUaGFua3MsDQotIEhhaXlh
bmcNCg0K
^ permalink raw reply
* [GIT PULL] samsung-fb updates for v3.9
From: Jingoo Han @ 2013-02-19 2:51 UTC (permalink / raw)
To: 'Linus Torvalds'
Cc: 'linux-fbdev', 'linux-kernel',
'Florian Tobias Schandinat', 'Andrew Morton',
'Jingoo Han'
Hi Linus,
Florian, the fbdev maintainer, has been very busy lately, so I send the pull request
for samsung-fb for this merge window.
The following changes since commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200:
Linux 3.8 (Mon Feb 18 15:58:34 2013 -0800)
are available in the git repository at:
git://github.com/jingoo/linux.git samsung-fb-next
for you to fetch changes up to 5a415ae252d5922de9eadefabe8510115395fbc6:
video: s3c-fb: Fix typo in definition of VIDCON1_VSTATUS_FRONTPORCH value (Sat Nov 17 21:31:00 2012 +0000)
----------------------------------------------------------------
samsung-fb updates for the v3.9:
- The bit definitions of header file are updated.
- The dependancy is fixed.
----------------------------------------------------------------
Jingoo Han (4):
video: s3c-fb: use ARCH_ dependancy
video: s3c-fb: remove duplicated S3C_FB_MAX_WIN
video: s3c-fb: remove unnecessary brackets
video: s3c-fb: add the bit definitions for CSC EQ709 and EQ601
Tomasz Figa (1):
video: s3c-fb: Fix typo in definition of VIDCON1_VSTATUS_FRONTPORCH value
drivers/video/Kconfig | 3 +-
include/video/samsung_fimd.h | 205 ++++++++++++++++++++---------------------
2 files changed, 102 insertions(+), 106 deletions(-)
--
Best regards,
Jingoo Han
^ permalink raw reply
* [GIT PULL] exynos-dp updates for v3.9
From: Jingoo Han @ 2013-02-19 2:57 UTC (permalink / raw)
To: 'Linus Torvalds'
Cc: 'linux-fbdev', 'linux-kernel',
'Florian Tobias Schandinat', 'Andrew Morton',
'Jingoo Han'
Hi Linus,
Florian, the fbdev maintainer, has been very busy lately, so I send the pull request
for exynos-dp for this merge window.
The following changes since commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200:
Linux 3.8 (Mon Feb 18 15:58:34 2013 -0800)
are available in the git repository at:
git://github.com/jingoo/linux.git exynos-dp-next
for you to fetch changes up to bb80934325dab97b479815aed237ebec33ed1c57:
video: exynos_dp: move disable_irq() to exynos_dp_suspend() (Tue Jan 29 18:26:05 2013 +0900)
----------------------------------------------------------------
exynos-dp updates for the v3.9:
- The missing function calls are fixed.
----------------------------------------------------------------
Ajay Kumar (1):
video: exynos_dp: move disable_irq() to exynos_dp_suspend()
Jingoo Han (1):
video: exynos_dp: add missing of_node_put()
drivers/video/exynos/exynos_dp_core.c | 24 +++++++++++++++---------
1 files changed, 15 insertions(+), 9 deletions(-)
--
Best regards,
Jingoo Han
^ permalink raw reply
* Re: [PATCH v2 0/1] OMAP4: DSS: Add panel for Blaze Tablet boards
From: Tomi Valkeinen @ 2013-02-19 11:34 UTC (permalink / raw)
To: Ruslan Bilovol
Cc: andi, FlorianSchandinat, linux-fbdev, linux-kernel, linux-omap
In-Reply-To: <CAB=otbRAj41dFMe_i+LDGbi29kMV0C-tw-HXyz7iF4m4R+5R+Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 939 bytes --]
On 2013-02-18 16:30, Ruslan Bilovol wrote:
>> So, I'm still inclined to say that we shouldn't merge this.
>
> Thanks for explanation.
>
> Do you have some plan when DSS will be ready to port this driver?
> (3.10, 3.11 or later)?
When it's ready =). The work depends also on common display framework,
so it's not only up to me.
That said, I have a prototype branch, with my version of CDF, that
somewhat works for the couple of boards and panels that I have ported.
It doesn't have DT code there, though (DSS DT is in a separate branch
for now). If all goes extremely well, I could imagine 3.10 having the
support allowing to port this driver.
And if you're interested in some prototype code, kernel crashes, DSS
debugging, etc, I can point you to my branch and give you some notes, so
you could try porting this panel driver to (my version of) CDF. Give me
a private email if you want to try that.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH RFC] video: Add Hyper-V Synthetic Video Frame Buffer Driver
From: Olaf Hering @ 2013-02-19 16:51 UTC (permalink / raw)
To: Haiyang Zhang
Cc: FlorianSchandinat, linux-fbdev, kys, jasowang, linux-kernel,
devel
In-Reply-To: <1360955396-14183-1-git-send-email-haiyangz@microsoft.com>
On Fri, Feb 15, Haiyang Zhang wrote:
> @@ -508,6 +544,18 @@ static int __init vesafb_init(void)
> int ret;
> char *option = NULL;
>
> +#if IS_ENABLED(CONFIG_HYPERV_FB)
> + /*
> + * On Hyper-V both the emulated and synthetic video devices are
> + * available. To avoid conflicts, we disable vesafb for the emulated
> + * video if hyperv_fb is configured.
> + */
> + if (is_hyperv()) {
> + pr_info("Disabled vesafb on Hyper-V.\n");
> + return -ENODEV;
> + }
> +#endif
What is the reason for this hook? Is it not possible to claim the
display like its appearently done by other drivers (like radeonfb can
take over display from vesafb)?
Olaf
^ permalink raw reply
* BUG: unable to handle kernel paging request at ffffc90000669000, IP: [<ffffffff8139d84a>] bitfill_un
From: Tommi Rantala @ 2013-02-19 17:33 UTC (permalink / raw)
To: David Airlie, dri-devel, Florian Tobias Schandinat, linux-fbdev
Cc: Dave Jones, Sasha Levin, LKML
Hello,
Hit the following oops while fuzzing the kernel with Trinity in a qemu
virtual machine:
[ 2143.140647] BUG: unable to handle kernel paging request at ffffc90000669000
[ 2143.140652] IP: [<ffffffff8139d84a>] bitfill_unaligned+0x10a/0x1a0
[ 2143.140654] PGD 3e073067 PUD 3e074067 PMD 3ca84067 PTE 0
[ 2143.140656] Oops: 0002 [#1] SMP
[ 2143.140660] CPU 0
[ 2143.140660] Pid: 2894, comm: trinity-child0 Not tainted 3.8.0-rc7+
#86 Bochs Bochs
[ 2143.140662] RIP: 0010:[<ffffffff8139d84a>] [<ffffffff8139d84a>]
bitfill_unaligned+0x10a/0x1a0
[ 2143.140663] RSP: 0018:ffff88003a967888 EFLAGS: 00010246
[ 2143.140664] RAX: 0000000003fffe1f RBX: 0000000000000000 RCX: 0000000000000008
[ 2143.140664] RDX: 0000000003f87fff RSI: ffffc900002a9f08 RDI: 0000000000000000
[ 2143.140665] RBP: ffff88003a9678a8 R08: 0000000000000008 R09: 0000000000000010
[ 2143.140666] R10: ffffc90000668fe8 R11: 0000000000000000 R12: 00000000ffff8800
[ 2143.140666] R13: 00000000ffffffc0 R14: ffffffffffffffff R15: 0000000000000018
[ 2143.140668] FS: 00007f965fc5e700(0000) GS:ffff88003fc00000(0000)
knlGS:0000000000000000
[ 2143.140668] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2143.140669] CR2: ffffc90000669000 CR3: 0000000039c50000 CR4: 00000000000006f0
[ 2143.140675] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2143.140678] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 2143.140679] Process trinity-child0 (pid: 2894, threadinfo
ffff88003a966000, task ffff88003b0c0000)
[ 2143.140679] Stack:
[ 2143.140682] ffff88003ca8d800 0000000000000000 ffffc900002a9f00
0000000000000000
[ 2143.140683] ffff88003a967938 ffffffff8139debf ffffffffffff8800
ffff880000000040
[ 2143.140685] ffffffff8225f1a0 ffff000000000000 ffff88003a9678e8
ffffffff810f5aed
[ 2143.140685] Call Trace:
[ 2143.140688] [<ffffffff8139debf>] sys_fillrect+0x34f/0x370
[ 2143.140692] [<ffffffff810f5aed>] ? trace_hardirqs_on+0xd/0x10
[ 2143.140693] [<ffffffff8139d740>] ? bitfill_aligned+0x120/0x120
[ 2143.140696] [<ffffffff814bbcef>] cirrus_fillrect+0x1f/0x40
[ 2143.140697] [<ffffffff8139aaba>] bit_clear_margins+0x12a/0x170
[ 2143.140701] [<ffffffff81395641>] fbcon_clear_margins+0x71/0x80
[ 2143.140702] [<ffffffff813998a9>] fbcon_switch+0x479/0x540
[ 2143.140705] [<ffffffff814166c1>] redraw_screen+0x131/0x250
[ 2143.140707] [<ffffffff81396c1c>] fbcon_modechanged+0x18c/0x210
[ 2143.140709] [<ffffffff81397739>] fbcon_event_notify+0x1f9/0x850
[ 2143.140712] [<ffffffff810c671d>] notifier_call_chain+0xbd/0xf0
[ 2143.140714] [<ffffffff810c6c08>] __blocking_notifier_call_chain+0x98/0xc0
[ 2143.140716] [<ffffffff810c6c41>] blocking_notifier_call_chain+0x11/0x20
[ 2143.140718] [<ffffffff81389146>] fb_notifier_call_chain+0x16/0x20
[ 2143.140720] [<ffffffff8138ae19>] fb_set_var+0x439/0x480
[ 2143.140721] [<ffffffff8138b089>] do_fb_ioctl+0x189/0x5d0
[ 2143.140723] [<ffffffff810f5bcd>] ? trace_hardirqs_off+0xd/0x10
[ 2143.140724] [<ffffffff810d552a>] ? local_clock+0x4a/0x70
[ 2143.140726] [<ffffffff810f1e98>] ? lock_release_holdtime+0x28/0x170
[ 2143.140728] [<ffffffff8138b90a>] fb_ioctl+0x3a/0x40
[ 2143.140731] [<ffffffff811b5ff2>] do_vfs_ioctl+0x532/0x580
[ 2143.140735] [<ffffffff812fc7d3>] ? file_has_perm+0x83/0xa0
[ 2143.140737] [<ffffffff811b609d>] sys_ioctl+0x5d/0xa0
[ 2143.140739] [<ffffffff813571de>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 2143.140741] [<ffffffff81ca06e9>] system_call_fastpath+0x16/0x1b
[ 2143.140758] Code: 89 7a 08 48 d3 e3 44 89 c9 48 d3 ef 44 89 c1 48
09 df 48 89 fb 49 89 7a 10 48 d3 e3 44 89 c9 48 d3 ef 44 89 c1 48 09
df 48 89 fb <49> 89 7a 18 49 83 c2 20 48 d3 e3 44 89 c9 48 d3 ef 48 09
df 83
[ 2143.140760] RIP [<ffffffff8139d84a>] bitfill_unaligned+0x10a/0x1a0
[ 2143.140760] RSP <ffff88003a967888>
[ 2143.140761] CR2: ffffc90000669000
[ 2143.146366] BUG: unable to handle kernel paging request at ffffc90000669000
[ 2143.146369] IP: [<ffffffff8139d84a>] bitfill_unaligned+0x10a/0x1a0
[ 2143.146371] PGD 3e073067 PUD 3e074067 PMD 3ca84067 PTE 0
[ 2143.146372] Oops: 0002 [#2] SMP
[ 2143.146375] CPU 0
[ 2143.146375] Pid: 2894, comm: trinity-child0 Not tainted 3.8.0-rc7+
#86 Bochs Bochs
[ 2143.146377] RIP: 0010:[<ffffffff8139d84a>] [<ffffffff8139d84a>]
bitfill_unaligned+0x10a/0x1a0
[ 2143.146378] RSP: 0018:ffff88003a967218 EFLAGS: 00010246
[ 2143.146378] RAX: 0000000003fffe1f RBX: 0000000000000000 RCX: 0000000000000008
[ 2143.146379] RDX: 0000000003f87fff RSI: ffffc900002a9f08 RDI: 0000000000000000
[ 2143.146380] RBP: ffff88003a967238 R08: 0000000000000008 R09: 0000000000000010
[ 2143.146380] R10: ffffc90000668fe8 R11: 0000000000000000 R12: 00000000ffff8800
[ 2143.146381] R13: 00000000ffffffc0 R14: ffffffffffffffff R15: 0000000000000018
[ 2143.146382] FS: 00007f965fc5e700(0000) GS:ffff88003fc00000(0000)
knlGS:0000000000000000
[ 2143.146383] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2143.146383] CR2: ffffc90000669000 CR3: 0000000039c50000 CR4: 00000000000006f0
[ 2143.146388] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2143.146391] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 2143.146391] Process trinity-child0 (pid: 2894, threadinfo
ffff88003a966000, task ffff88003b0c0000)
[ 2143.146392] Stack:
[ 2143.146394] ffff88003ca8d800 0000000000000000 ffffc900002a9f00
0000000000000000
[ 2143.146395] ffff88003a9672c8 ffffffff8139debf ffffffffffff8800
ffff880000000040
[ 2143.146397] ffffffff8225f1a0 ffff000000000000 ffff88003a967278
ffffffff810f5aed
[ 2143.146397] Call Trace:
[ 2143.146399] [<ffffffff8139debf>] sys_fillrect+0x34f/0x370
[ 2143.146402] [<ffffffff810f5aed>] ? trace_hardirqs_on+0xd/0x10
[ 2143.146403] [<ffffffff8139d740>] ? bitfill_aligned+0x120/0x120
[ 2143.146405] [<ffffffff814bbcef>] cirrus_fillrect+0x1f/0x40
[ 2143.146406] [<ffffffff8139aaba>] bit_clear_margins+0x12a/0x170
[ 2143.146408] [<ffffffff81395641>] fbcon_clear_margins+0x71/0x80
[ 2143.146410] [<ffffffff813998a9>] fbcon_switch+0x479/0x540
[ 2143.146412] [<ffffffff814166c1>] redraw_screen+0x131/0x250
[ 2143.146414] [<ffffffff81397f9a>] fbcon_blank+0x20a/0x2d0
[ 2143.146417] [<ffffffff81c9effc>] ? _raw_spin_lock_irqsave+0x7c/0x90
[ 2143.146420] [<ffffffff810a8ee3>] ? lock_timer_base.isra.25+0x33/0x70
[ 2143.146422] [<ffffffff810f5b18>] ? trace_hardirqs_off_caller+0x28/0xd0
[ 2143.146423] [<ffffffff810f5bcd>] ? trace_hardirqs_off+0xd/0x10
[ 2143.146425] [<ffffffff81c9f174>] ? _raw_spin_unlock_irqrestore+0x44/0x70
[ 2143.146427] [<ffffffff810aa17b>] ? mod_timer+0x1ab/0x200
[ 2143.146429] [<ffffffff814180f8>] do_unblank_screen+0xf8/0x1d0
[ 2143.146430] [<ffffffff814181db>] unblank_screen+0xb/0x10
[ 2143.146432] [<ffffffff81358239>] bust_spinlocks+0x19/0x30
[ 2143.146435] [<ffffffff8105cde2>] oops_end+0x42/0xe0
[ 2143.146438] [<ffffffff81c89d82>] no_context+0x253/0x27e
[ 2143.146439] [<ffffffff81c89f73>] __bad_area_nosemaphore+0x1c6/0x1e5
[ 2143.146442] [<ffffffff81091681>] ? kmemcheck_pte_lookup+0x11/0x40
[ 2143.146444] [<ffffffff81c89fa0>] bad_area_nosemaphore+0xe/0x10
[ 2143.146445] [<ffffffff8108a35e>] __do_page_fault+0x43e/0x4d0
[ 2143.146447] [<ffffffff810f58d3>] ? mark_held_locks+0x123/0x140
[ 2143.146449] [<ffffffff81c9fdb3>] ? retint_restore_args+0x13/0x13
[ 2143.146451] [<ffffffff810f58d3>] ? mark_held_locks+0x123/0x140
[ 2143.146452] [<ffffffff8135721d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
[ 2143.146454] [<ffffffff8108a419>] do_page_fault+0x9/0x10
[ 2143.146456] [<ffffffff8108492c>] do_async_page_fault+0x4c/0xa0
[ 2143.146458] [<ffffffff81ca00b8>] async_page_fault+0x28/0x30
[ 2143.146459] [<ffffffff8139d84a>] ? bitfill_unaligned+0x10a/0x1a0
[ 2143.146460] [<ffffffff8139debf>] sys_fillrect+0x34f/0x370
[ 2143.146462] [<ffffffff810f5aed>] ? trace_hardirqs_on+0xd/0x10
[ 2143.146464] [<ffffffff8139d740>] ? bitfill_aligned+0x120/0x120
[ 2143.146465] [<ffffffff814bbcef>] cirrus_fillrect+0x1f/0x40
[ 2143.146466] [<ffffffff8139aaba>] bit_clear_margins+0x12a/0x170
[ 2143.146468] [<ffffffff81395641>] fbcon_clear_margins+0x71/0x80
[ 2143.146470] [<ffffffff813998a9>] fbcon_switch+0x479/0x540
[ 2143.146472] [<ffffffff814166c1>] redraw_screen+0x131/0x250
[ 2143.146473] [<ffffffff81396c1c>] fbcon_modechanged+0x18c/0x210
[ 2143.146475] [<ffffffff81397739>] fbcon_event_notify+0x1f9/0x850
[ 2143.146477] [<ffffffff810c671d>] notifier_call_chain+0xbd/0xf0
[ 2143.146479] [<ffffffff810c6c08>] __blocking_notifier_call_chain+0x98/0xc0
[ 2143.146481] [<ffffffff810c6c41>] blocking_notifier_call_chain+0x11/0x20
[ 2143.146483] [<ffffffff81389146>] fb_notifier_call_chain+0x16/0x20
[ 2143.146484] [<ffffffff8138ae19>] fb_set_var+0x439/0x480
[ 2143.146486] [<ffffffff8138b089>] do_fb_ioctl+0x189/0x5d0
[ 2143.146487] [<ffffffff810f5bcd>] ? trace_hardirqs_off+0xd/0x10
[ 2143.146488] [<ffffffff810d552a>] ? local_clock+0x4a/0x70
[ 2143.146490] [<ffffffff810f1e98>] ? lock_release_holdtime+0x28/0x170
[ 2143.146492] [<ffffffff8138b90a>] fb_ioctl+0x3a/0x40
[ 2143.146494] [<ffffffff811b5ff2>] do_vfs_ioctl+0x532/0x580
[ 2143.146496] [<ffffffff812fc7d3>] ? file_has_perm+0x83/0xa0
[ 2143.146498] [<ffffffff811b609d>] sys_ioctl+0x5d/0xa0
[ 2143.146499] [<ffffffff813571de>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 2143.146501] [<ffffffff81ca06e9>] system_call_fastpath+0x16/0x1b
[ 2143.146518] Code: 89 7a 08 48 d3 e3 44 89 c9 48 d3 ef 44 89 c1 48
09 df 48 89 fb 49 89 7a 10 48 d3 e3 44 89 c9 48 d3 ef 44 89 c1 48 09
df 48 89 fb <49> 89 7a 18 49 83 c2 20 48 d3 e3 44 89 c9 48 d3 ef 48 09
df 83
[ 2143.146519] RIP [<ffffffff8139d84a>] bitfill_unaligned+0x10a/0x1a0
[ 2143.146520] RSP <ffff88003a967218>
[ 2143.146520] CR2: ffffc90000669000
[ 2143.146522] ---[ end trace bc6146191d8a6170 ]---
Tommi
^ permalink raw reply
* RE: [PATCH RFC] video: Add Hyper-V Synthetic Video Frame Buffer Driver
From: Haiyang Zhang @ 2013-02-19 17:48 UTC (permalink / raw)
To: Olaf Hering
Cc: FlorianSchandinat@gmx.de, linux-fbdev@vger.kernel.org,
KY Srinivasan, jasowang@redhat.com, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org
In-Reply-To: <20130219165118.GA17715@aepfle.de>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBPbGFmIEhlcmluZyBbbWFpbHRv
Om9sYWZAYWVwZmxlLmRlXQ0KPiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxOSwgMjAxMyAxMTo1
MSBBTQ0KPiBUbzogSGFpeWFuZyBaaGFuZw0KPiBDYzogRmxvcmlhblNjaGFuZGluYXRAZ214LmRl
OyBsaW51eC1mYmRldkB2Z2VyLmtlcm5lbC5vcmc7IEtZIFNyaW5pdmFzYW47DQo+IGphc293YW5n
QHJlZGhhdC5jb207IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7DQo+IGRldmVsQGxpbnV4
ZHJpdmVycHJvamVjdC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCBSRkNdIHZpZGVvOiBBZGQg
SHlwZXItViBTeW50aGV0aWMgVmlkZW8gRnJhbWUgQnVmZmVyDQo+IERyaXZlcg0KPiANCj4gT24g
RnJpLCBGZWIgMTUsIEhhaXlhbmcgWmhhbmcgd3JvdGU6DQo+IA0KPiA+IEBAIC01MDgsNiArNTQ0
LDE4IEBAIHN0YXRpYyBpbnQgX19pbml0IHZlc2FmYl9pbml0KHZvaWQpDQo+ID4gIAlpbnQgcmV0
Ow0KPiA+ICAJY2hhciAqb3B0aW9uID0gTlVMTDsNCj4gPg0KPiA+ICsjaWYgSVNfRU5BQkxFRChD
T05GSUdfSFlQRVJWX0ZCKQ0KPiA+ICsJLyoNCj4gPiArCSAqIE9uIEh5cGVyLVYgYm90aCB0aGUg
ZW11bGF0ZWQgYW5kIHN5bnRoZXRpYyB2aWRlbyBkZXZpY2VzIGFyZQ0KPiA+ICsJICogYXZhaWxh
YmxlLiBUbyBhdm9pZCBjb25mbGljdHMsIHdlIGRpc2FibGUgdmVzYWZiIGZvciB0aGUNCj4gZW11
bGF0ZWQNCj4gPiArCSAqIHZpZGVvIGlmIGh5cGVydl9mYiBpcyBjb25maWd1cmVkLg0KPiA+ICsJ
ICovDQo+ID4gKwlpZiAoaXNfaHlwZXJ2KCkpIHsNCj4gPiArCQlwcl9pbmZvKCJEaXNhYmxlZCB2
ZXNhZmIgb24gSHlwZXItVi5cbiIpOw0KPiA+ICsJCXJldHVybiAtRU5PREVWOw0KPiA+ICsJfQ0K
PiA+ICsjZW5kaWYNCj4gDQo+IFdoYXQgaXMgdGhlIHJlYXNvbiBmb3IgdGhpcyBob29rPyBJcyBp
dCBub3QgcG9zc2libGUgdG8gY2xhaW0gdGhlDQo+IGRpc3BsYXkgbGlrZSBpdHMgYXBwZWFyZW50
bHkgZG9uZSBieSBvdGhlciBkcml2ZXJzIChsaWtlIHJhZGVvbmZiIGNhbg0KPiB0YWtlIG92ZXIg
ZGlzcGxheSBmcm9tIHZlc2FmYik/DQoNClRoZSBlbXVsYXRlZCB2aWRlbyBkZXZpY2UgaXMgYSBz
ZXBhcmF0ZSBkZXZpY2UgZnJvbSB0aGUgc3ludGhldGljIHZpZGVvLg0KVGhlIHN5bnRoZXRpYyBk
cml2ZXIgY2FuIG9ubHkgdGFrZSBjb250cm9sIG9mIHRoZSBzeW50aGV0aWMgdmlkZW8sIGJ1dCBu
b3QNCnRoZSBlbXVsYXRlZCB2aWRlby4NCg0KQWN0dWFsbHksIHdlIGFscmVhZHkgaGF2ZSBhIHNp
bWlsYXIgbWVjaGFuaXNtIGluIGF0YS9hdGFfcGlpeC5jIHRvIGRpc2FibGUNCmVtdWxhdGVkIElE
RSBkcml2ZSBvbiBIeXBlci1WLCBzbyBpdCB3b24ndCBjb25mbGljdCB3aXRoIHRoZSBzeW50aGV0
aWMgZHJpdmUuDQoNClRoYW5rcywNCi0gSGFpeWFuZw0KDQo
^ 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