* [PATCH 1/9] ARM i.MX51: Add ipu clock support
2010-12-09 13:47 [PATCH RFC] i.MX51 Framebuffer support Sascha Hauer
@ 2010-12-09 13:47 ` Sascha Hauer
2010-12-15 15:40 ` Arnd Bergmann
2010-12-09 13:47 ` [PATCH 2/9] ARM i.MX51: rename IPU irqs Sascha Hauer
` (7 subsequent siblings)
8 siblings, 1 reply; 34+ messages in thread
From: Sascha Hauer @ 2010-12-09 13:47 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/mach-mx5/clock-mx51-mx53.c | 140 +++++++++++++++++++++++++++++++++++
1 files changed, 140 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx5/clock-mx51-mx53.c b/arch/arm/mach-mx5/clock-mx51-mx53.c
index 9fc65bb..f550d02 100644
--- a/arch/arm/mach-mx5/clock-mx51-mx53.c
+++ b/arch/arm/mach-mx5/clock-mx51-mx53.c
@@ -39,6 +39,9 @@ static struct clk periph_apm_clk;
static struct clk ahb_clk;
static struct clk ipg_clk;
static struct clk usboh3_clk;
+static struct clk emi_fast_clk;
+static struct clk ipu_clk;
+static struct clk mipi_hsc1_clk;
#define MAX_DPLL_WAIT_TRIES 1000 /* 1000 * udelay(1) = 1ms */
@@ -688,6 +691,19 @@ static unsigned long clk_emi_slow_get_rate(struct clk *clk)
return clk_get_rate(clk->parent) / div;
}
+static unsigned long _clk_ddr_hf_get_rate(struct clk *clk)
+{
+ unsigned long rate;
+ u32 reg, div;
+
+ reg = __raw_readl(MXC_CCM_CBCDR);
+ div = ((reg & MXC_CCM_CBCDR_DDR_PODF_MASK) >>
+ MXC_CCM_CBCDR_DDR_PODF_OFFSET) + 1;
+ rate = clk_get_rate(clk->parent) / div;
+
+ return rate;
+}
+
/* External high frequency clock */
static struct clk ckih_clk = {
.get_rate = get_high_reference_clock_rate,
@@ -846,6 +862,109 @@ static struct clk emi_slow_clk = {
.get_rate = clk_emi_slow_get_rate,
};
+static int clk_ipu_enable(struct clk *clk)
+{
+ u32 reg;
+
+ _clk_ccgr_enable(clk);
+
+ /* Enable handshake with IPU when certain clock rates are changed */
+ reg = __raw_readl(MXC_CCM_CCDR);
+ reg &= ~MXC_CCM_CCDR_IPU_HS_MASK;
+ __raw_writel(reg, MXC_CCM_CCDR);
+
+ /* Enable handshake with IPU when LPM is entered */
+ reg = __raw_readl(MXC_CCM_CLPCR);
+ reg &= ~MXC_CCM_CLPCR_BYPASS_IPU_LPM_HS;
+ __raw_writel(reg, MXC_CCM_CLPCR);
+
+ return 0;
+}
+
+static void clk_ipu_disable(struct clk *clk)
+{
+ u32 reg;
+
+ _clk_ccgr_disable(clk);
+
+ /* Disable handshake with IPU whe dividers are changed */
+ reg = __raw_readl(MXC_CCM_CCDR);
+ reg |= MXC_CCM_CCDR_IPU_HS_MASK;
+ __raw_writel(reg, MXC_CCM_CCDR);
+
+ /* Disable handshake with IPU when LPM is entered */
+ reg = __raw_readl(MXC_CCM_CLPCR);
+ reg |= MXC_CCM_CLPCR_BYPASS_IPU_LPM_HS;
+ __raw_writel(reg, MXC_CCM_CLPCR);
+}
+
+static struct clk ahbmux1_clk = {
+ .parent = &ahb_clk,
+ .secondary = &ahb_max_clk,
+ .enable_reg = MXC_CCM_CCGR0,
+ .enable_shift = MXC_CCM_CCGRx_CG8_OFFSET,
+ .enable = _clk_ccgr_enable,
+ .disable = _clk_ccgr_disable_inwait,
+};
+
+static struct clk ipu_sec_clk = {
+ .parent = &emi_fast_clk,
+ .secondary = &ahbmux1_clk,
+};
+
+static struct clk ddr_hf_clk = {
+ .parent = &pll1_sw_clk,
+ .get_rate = _clk_ddr_hf_get_rate,
+};
+
+static struct clk ddr_clk = {
+ .parent = &ddr_hf_clk,
+};
+
+/* clock definitions for MIPI HSC unit which has been removed
+ * from documentation, but not from hardware
+ */
+static int _clk_hsc_enable(struct clk *clk)
+{
+ u32 reg;
+
+ _clk_ccgr_enable(clk);
+ /* Handshake with IPU when certain clock rates are changed. */
+ reg = __raw_readl(MXC_CCM_CCDR);
+ reg &= ~MXC_CCM_CCDR_HSC_HS_MASK;
+ __raw_writel(reg, MXC_CCM_CCDR);
+
+ reg = __raw_readl(MXC_CCM_CLPCR);
+ reg &= ~MXC_CCM_CLPCR_BYPASS_HSC_LPM_HS;
+ __raw_writel(reg, MXC_CCM_CLPCR);
+
+ return 0;
+}
+
+static void _clk_hsc_disable(struct clk *clk)
+{
+ u32 reg;
+
+ _clk_ccgr_disable(clk);
+ /* No handshake with HSC as its not enabled. */
+ reg = __raw_readl(MXC_CCM_CCDR);
+ reg |= MXC_CCM_CCDR_HSC_HS_MASK;
+ __raw_writel(reg, MXC_CCM_CCDR);
+
+ reg = __raw_readl(MXC_CCM_CLPCR);
+ reg |= MXC_CCM_CLPCR_BYPASS_HSC_LPM_HS;
+ __raw_writel(reg, MXC_CCM_CLPCR);
+}
+
+static struct clk mipi_hsp_clk = {
+ .parent = &ipu_clk,
+ .enable_reg = MXC_CCM_CCGR4,
+ .enable_shift = MXC_CCM_CCGRx_CG6_OFFSET,
+ .enable = _clk_hsc_enable,
+ .disable = _clk_hsc_disable,
+ .secondary = &mipi_hsc1_clk,
+};
+
#define DEFINE_CLOCK_CCGR(name, i, er, es, pfx, p, s) \
static struct clk name = { \
.id = i, \
@@ -1077,6 +1196,23 @@ DEFINE_CLOCK_FULL(esdhc2_ipg_clk, 1, MXC_CCM_CCGR3, MXC_CCM_CCGRx_CG2_OFFSET,
DEFINE_CLOCK_MAX(esdhc2_clk, 1, MXC_CCM_CCGR3, MXC_CCM_CCGRx_CG3_OFFSET,
clk_esdhc2, &pll2_sw_clk, &esdhc2_ipg_clk);
+DEFINE_CLOCK(mipi_esc_clk, 0, MXC_CCM_CCGR4, MXC_CCM_CCGRx_CG5_OFFSET, NULL, NULL, NULL, &pll2_sw_clk);
+DEFINE_CLOCK(mipi_hsc2_clk, 0, MXC_CCM_CCGR4, MXC_CCM_CCGRx_CG4_OFFSET, NULL, NULL, &mipi_esc_clk, &pll2_sw_clk);
+DEFINE_CLOCK(mipi_hsc1_clk, 0, MXC_CCM_CCGR4, MXC_CCM_CCGRx_CG3_OFFSET, NULL, NULL, &mipi_hsc2_clk, &pll2_sw_clk);
+
+/* IPU */
+DEFINE_CLOCK_FULL(ipu_clk, 0, MXC_CCM_CCGR5, MXC_CCM_CCGRx_CG5_OFFSET,
+ NULL, NULL, clk_ipu_enable, clk_ipu_disable, &ahb_clk, &ipu_sec_clk);
+
+DEFINE_CLOCK_FULL(emi_fast_clk, 0, MXC_CCM_CCGR5, MXC_CCM_CCGRx_CG7_OFFSET,
+ NULL, NULL, _clk_ccgr_enable, _clk_ccgr_disable_inwait,
+ &ddr_clk, NULL);
+
+DEFINE_CLOCK(ipu_di0_clk, 0, MXC_CCM_CCGR6, MXC_CCM_CCGRx_CG5_OFFSET,
+ NULL, NULL, &pll3_sw_clk, NULL);
+DEFINE_CLOCK(ipu_di1_clk, 0, MXC_CCM_CCGR6, MXC_CCM_CCGRx_CG6_OFFSET,
+ NULL, NULL, &pll3_sw_clk, NULL);
+
#define _REGISTER_CLOCK(d, n, c) \
{ \
.dev_id = d, \
@@ -1117,6 +1253,10 @@ static struct clk_lookup mx51_lookups[] = {
_REGISTER_CLOCK(NULL, "iim_clk", iim_clk)
_REGISTER_CLOCK("imx2-wdt.0", NULL, dummy_clk)
_REGISTER_CLOCK("imx2-wdt.1", NULL, dummy_clk)
+ _REGISTER_CLOCK(NULL, "mipi_hsp", mipi_hsp_clk)
+ _REGISTER_CLOCK("imx-ipuv3", NULL, ipu_clk)
+ _REGISTER_CLOCK("imx-ipuv3", "di0", ipu_di0_clk)
+ _REGISTER_CLOCK("imx-ipuv3", "di1", ipu_di1_clk)
};
static struct clk_lookup mx53_lookups[] = {
--
1.7.2.3
^ permalink raw reply related [flat|nested] 34+ messages in thread* Re: [PATCH 1/9] ARM i.MX51: Add ipu clock support
2010-12-09 13:47 ` [PATCH 1/9] ARM i.MX51: Add ipu clock support Sascha Hauer
@ 2010-12-15 15:40 ` Arnd Bergmann
2010-12-15 16:34 ` Russell King - ARM Linux
0 siblings, 1 reply; 34+ messages in thread
From: Arnd Bergmann @ 2010-12-15 15:40 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 09 December 2010, Sascha Hauer wrote:
> +static int clk_ipu_enable(struct clk *clk)
> +{
> + u32 reg;
> +
> + _clk_ccgr_enable(clk);
> +
> + /* Enable handshake with IPU when certain clock rates are changed */
> + reg = __raw_readl(MXC_CCM_CCDR);
> + reg &= ~MXC_CCM_CCDR_IPU_HS_MASK;
> + __raw_writel(reg, MXC_CCM_CCDR);
> +
> + /* Enable handshake with IPU when LPM is entered */
> + reg = __raw_readl(MXC_CCM_CLPCR);
> + reg &= ~MXC_CCM_CLPCR_BYPASS_IPU_LPM_HS;
> + __raw_writel(reg, MXC_CCM_CLPCR);
> +
> + return 0;
> +}
Why __raw_readl?
The regular accessor function for I/O registers is readl, which handles
the access correctly with regard to atomicity, I/O ordering and byteorder.
Arnd
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH 1/9] ARM i.MX51: Add ipu clock support
2010-12-15 15:40 ` Arnd Bergmann
@ 2010-12-15 16:34 ` Russell King - ARM Linux
2010-12-15 16:49 ` Arnd Bergmann
0 siblings, 1 reply; 34+ messages in thread
From: Russell King - ARM Linux @ 2010-12-15 16:34 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Dec 15, 2010 at 04:40:03PM +0100, Arnd Bergmann wrote:
> On Thursday 09 December 2010, Sascha Hauer wrote:
> > +static int clk_ipu_enable(struct clk *clk)
> > +{
> > + u32 reg;
> > +
> > + _clk_ccgr_enable(clk);
> > +
> > + /* Enable handshake with IPU when certain clock rates are changed */
> > + reg = __raw_readl(MXC_CCM_CCDR);
> > + reg &= ~MXC_CCM_CCDR_IPU_HS_MASK;
> > + __raw_writel(reg, MXC_CCM_CCDR);
> > +
> > + /* Enable handshake with IPU when LPM is entered */
> > + reg = __raw_readl(MXC_CCM_CLPCR);
> > + reg &= ~MXC_CCM_CLPCR_BYPASS_IPU_LPM_HS;
> > + __raw_writel(reg, MXC_CCM_CLPCR);
> > +
> > + return 0;
> > +}
>
> Why __raw_readl?
>
> The regular accessor function for I/O registers is readl, which handles
> the access correctly with regard to atomicity, I/O ordering and byteorder.
There's no possibility of those two being mis-ordered - they will be in
program order whatever.
What isn't guaranteed is the ordering between I/O accesses (accesses to
device memory) and SDRAM accesses (normal memory) which can pass each other
without additional barriers. Memory accesses can pass I/O accesses.
So, (eg), if you're writing to a register which causes the hardware to
begin reading DMA descriptors from an area allocated from dma_alloc_coherent(),
you need a barrier to ensure that writes to the dma_alloc_coherent() are
visible to the hardware before you write the enable register.
If you don't need normal vs device access ordering, using readl_relaxed()/
writel_relaxed() is preferred, and avoids the (apparantly rather high)
performance overhead of having to issue barriers all the way down to the
L2 cache.
Lastly, I don't see where atomicity comes into it - __raw_writel vs writel
have the same atomicity. Both are single access atomic provided they're
naturally aligned. Misaligned device accesses are not predictable.
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH 1/9] ARM i.MX51: Add ipu clock support
2010-12-15 16:34 ` Russell King - ARM Linux
@ 2010-12-15 16:49 ` Arnd Bergmann
2010-12-15 17:12 ` Russell King - ARM Linux
0 siblings, 1 reply; 34+ messages in thread
From: Arnd Bergmann @ 2010-12-15 16:49 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 15 December 2010, Russell King - ARM Linux wrote:
> > The regular accessor function for I/O registers is readl, which handles
> > the access correctly with regard to atomicity, I/O ordering and byteorder.
>
> There's no possibility of those two being mis-ordered - they will be in
> program order whatever.
>
> What isn't guaranteed is the ordering between I/O accesses (accesses to
> device memory) and SDRAM accesses (normal memory) which can pass each other
> without additional barriers. Memory accesses can pass I/O accesses.
Yes, that's what I meant.
> If you don't need normal vs device access ordering, using readl_relaxed()/
> writel_relaxed() is preferred, and avoids the (apparantly rather high)
> performance overhead of having to issue barriers all the way down to the
> L2 cache.
Well, my point was that the authors should choose their I/O accessors
carefully. Using __raw_writel() without any explanations is a rather
bad default, it's not designed for that. Using writel() as a default
is usually a good choice, as we can assume it to do the right thing.
writel_relaxed() is also good where appropriate, because it tells
the reader that the driver author has thought about the I/O (vs. code)
ordering and concluded that it's safe to do.
> Lastly, I don't see where atomicity comes into it - __raw_writel vs writel
> have the same atomicity. Both are single access atomic provided they're
> naturally aligned. Misaligned device accesses are not predictable.
This is just what gcc turns it into today. In theory, a future gcc or
a future cpu might change that. If you mark a pointer as
'__attribute__((packed))', it probably already does, even for aligned
pointers, while it does not when using writel_{,relaxed}. The point is
that __raw_* means just that -- we don't give any guarantees on what
happens on the bus, so people should not use it.
Arnd
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH 1/9] ARM i.MX51: Add ipu clock support
2010-12-15 16:49 ` Arnd Bergmann
@ 2010-12-15 17:12 ` Russell King - ARM Linux
0 siblings, 0 replies; 34+ messages in thread
From: Russell King - ARM Linux @ 2010-12-15 17:12 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Dec 15, 2010 at 05:49:59PM +0100, Arnd Bergmann wrote:
> On Wednesday 15 December 2010, Russell King - ARM Linux wrote:
> > Lastly, I don't see where atomicity comes into it - __raw_writel vs writel
> > have the same atomicity. Both are single access atomic provided they're
> > naturally aligned. Misaligned device accesses are not predictable.
>
> This is just what gcc turns it into today. In theory, a future gcc or
> a future cpu might change that. If you mark a pointer as
> '__attribute__((packed))', it probably already does, even for aligned
> pointers, while it does not when using writel_{,relaxed}. The point is
> that __raw_* means just that -- we don't give any guarantees on what
> happens on the bus, so people should not use it.
No. It does give guarantees on what happens on the bus. The kind of
pointer you pass in has no bearing on what happens on the bus because it's
casted away immediately.
__raw_writel(v, ptr) doesn't just do *(ptr) = v - that doesn't work when
ptr is void. Instead, it has to do a cast to ensure that we have a valid
C dereference (void pointers are illegal to dereference):
#define __raw_writel(v,a) (__chk_io_ptr(a), \
*(volatile unsigned int __force *)(a) = (v))
Doesn't matter if 'a' was marked as packed or not - that's all casted away.
That's not something that should ever change - otherwise we'll all be
screwed as you could never cast away pointer attributes.
It _may_ possible that the compiler decides that accessing an 'unsigned int'
will not be done as a single word load, in which case we have exactly the
same problems with writel() too.
And in any case, if __raw_writel() was as you're suggesting, then it would
serve absolutely no purpose at all.
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 2/9] ARM i.MX51: rename IPU irqs
2010-12-09 13:47 [PATCH RFC] i.MX51 Framebuffer support Sascha Hauer
2010-12-09 13:47 ` [PATCH 1/9] ARM i.MX51: Add ipu clock support Sascha Hauer
@ 2010-12-09 13:47 ` Sascha Hauer
2010-12-09 14:34 `
2010-12-09 13:47 ` [PATCH 4/9] fb: export fb mode db table Sascha Hauer
` (6 subsequent siblings)
8 siblings, 1 reply; 34+ messages in thread
From: Sascha Hauer @ 2010-12-09 13:47 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/plat-mxc/include/mach/mx51.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-mxc/include/mach/mx51.h b/arch/arm/plat-mxc/include/mach/mx51.h
index fa3a2a5..873807f 100644
--- a/arch/arm/plat-mxc/include/mach/mx51.h
+++ b/arch/arm/plat-mxc/include/mach/mx51.h
@@ -251,8 +251,8 @@
#define MX51_MXC_INT_IOMUX 7
#define MX51_INT_NFC 8
#define MX51_MXC_INT_VPU 9
-#define MX51_MXC_INT_IPU_ERR 10
-#define MX51_MXC_INT_IPU_SYN 11
+#define MX51_INT_IPU_ERR 10
+#define MX51_INT_IPU_SYN 11
#define MX51_MXC_INT_GPU 12
#define MX51_MXC_INT_RESV13 13
#define MX51_MXC_INT_USB_H1 14
--
1.7.2.3
^ permalink raw reply related [flat|nested] 34+ messages in thread* [PATCH 4/9] fb: export fb mode db table
2010-12-09 13:47 [PATCH RFC] i.MX51 Framebuffer support Sascha Hauer
2010-12-09 13:47 ` [PATCH 1/9] ARM i.MX51: Add ipu clock support Sascha Hauer
2010-12-09 13:47 ` [PATCH 2/9] ARM i.MX51: rename IPU irqs Sascha Hauer
@ 2010-12-09 13:47 ` Sascha Hauer
2011-01-06 7:26 ` Paul Mundt
2010-12-09 13:47 ` [PATCH 5/9] Add i.MX5 framebuffer driver Sascha Hauer
` (5 subsequent siblings)
8 siblings, 1 reply; 34+ messages in thread
From: Sascha Hauer @ 2010-12-09 13:47 UTC (permalink / raw)
To: linux-arm-kernel
The different modes can be useful for drivers. Currently there is
no way to expose the modes to sysfs, so export them.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/video/modedb.c | 7 ++++++-
include/linux/fb.h | 3 +++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index 0a4dbdc..82122a9 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -36,7 +36,7 @@ EXPORT_SYMBOL_GPL(fb_mode_option);
* Standard video mode definitions (taken from XFree86)
*/
-static const struct fb_videomode modedb[] = {
+const struct fb_videomode modedb[] = {
{
/* 640x400 @ 70 Hz, 31.5 kHz hsync */
NULL, 70, 640, 400, 39721, 40, 24, 39, 9, 96, 2,
@@ -277,6 +277,11 @@ static const struct fb_videomode modedb[] = {
},
};
+const struct fb_videomode *fb_modes = modedb;
+EXPORT_SYMBOL(fb_modes);
+const int num_fb_modes = ARRAY_SIZE(modedb);
+EXPORT_SYMBOL(num_fb_modes);
+
#ifdef CONFIG_FB_MODE_HELPERS
const struct fb_videomode vesa_modes[] = {
/* 0 640x350-85 VESA */
diff --git a/include/linux/fb.h b/include/linux/fb.h
index d1631d3..e006172 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -1151,6 +1151,9 @@ struct fb_videomode {
extern const char *fb_mode_option;
extern const struct fb_videomode vesa_modes[];
+extern const struct fb_videomode *fb_modes;
+extern const int num_fb_modes;
+
struct fb_modelist {
struct list_head list;
struct fb_videomode mode;
--
1.7.2.3
^ permalink raw reply related [flat|nested] 34+ messages in thread* Re: [PATCH 4/9] fb: export fb mode db table
2010-12-09 13:47 ` [PATCH 4/9] fb: export fb mode db table Sascha Hauer
@ 2011-01-06 7:26 ` Paul Mundt
2011-01-06 10:04 ` Sascha Hauer
0 siblings, 1 reply; 34+ messages in thread
From: Paul Mundt @ 2011-01-06 7:26 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Dec 09, 2010 at 02:47:16PM +0100, Sascha Hauer wrote:
> The different modes can be useful for drivers. Currently there is
> no way to expose the modes to sysfs, so export them.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
I'll admit I don't really like the idea of exposing the modedb to drivers
in this way, but given that we're already doing it for the vesa and cea
modes, allowing drivers to copy ranges in to their modelist from the
standard db is probably something we can live with.
The mode list dumping is basically a blatant sysfs abuse already though,
and it would be much cleaner simply to back the mode store with an
fb_find/try_mode() pair that grovels all the right places in addition to
doing a pass over the fb_info's modelist.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 4/9] fb: export fb mode db table
2011-01-06 7:26 ` Paul Mundt
@ 2011-01-06 10:04 ` Sascha Hauer
0 siblings, 0 replies; 34+ messages in thread
From: Sascha Hauer @ 2011-01-06 10:04 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 06, 2011 at 04:26:58PM +0900, Paul Mundt wrote:
> On Thu, Dec 09, 2010 at 02:47:16PM +0100, Sascha Hauer wrote:
> > The different modes can be useful for drivers. Currently there is
> > no way to expose the modes to sysfs, so export them.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>
> I'll admit I don't really like the idea of exposing the modedb to drivers
> in this way, but given that we're already doing it for the vesa and cea
> modes, allowing drivers to copy ranges in to their modelist from the
> standard db is probably something we can live with.
>
> The mode list dumping is basically a blatant sysfs abuse already though,
You mean the available modes should not be exposed to sysfs? I found it
quite convenient to have during development. Exporting the modedb seemed
to be the only way to populate sysfs with a sane set of modes.
> and it would be much cleaner simply to back the mode store with an
> fb_find/try_mode() pair that grovels all the right places in addition to
> doing a pass over the fb_info's modelist.
The kernel provides no way to query the modelist other than sysfs. So
when the modelist dumping is a sysfs abuse, what purpose does the
modelist have anyway?
Right now the behaviour is quite strange. Each time a new (formerly
unknown) mode is selected the modelist magically gets a new entry. So
the kernel normally starts with an empty (or one entry from startup)
modelist and gets populated over time with the modes the user used.
I could understand when we say: "We do not keep the modelist in kernel,
do this in userspace". I could also understand when we say "we keep a
list of sane modes in the kernel, use fbset to switch to exotic modes".
ATM we do the worst of both: We keep a list but we do not populate it
with sane modes. Even worse, we use it to store the history of modes.
I know much of this comes from the fact that the fb subsystem does not
have a maintainer and nowadays the big desktop guys are not using the fb
subsystem at all, but it's really hard to find a way through and every
driver seems to have it's own idea of how things should work.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 5/9] Add i.MX5 framebuffer driver
2010-12-09 13:47 [PATCH RFC] i.MX51 Framebuffer support Sascha Hauer
` (2 preceding siblings ...)
2010-12-09 13:47 ` [PATCH 4/9] fb: export fb mode db table Sascha Hauer
@ 2010-12-09 13:47 ` Sascha Hauer
2010-12-12 6:13 ` Liu Ying
2010-12-09 13:47 ` [PATCH 6/9] ARM i.MX51: Add IPU device support Sascha Hauer
` (4 subsequent siblings)
8 siblings, 1 reply; 34+ messages in thread
From: Sascha Hauer @ 2010-12-09 13:47 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds framebuffer support to the Freescale i.MX SoCs
equipped with an IPU v3, so far these are the i.MX50/51/53.
This driver has been tested on the i.MX51 babbage board with
both DVI and analog VGA in different resolutions and color depths.
It has also been tested on a custom i.MX51 board using a fixed
resolution panel.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/video/Kconfig | 11 +
drivers/video/Makefile | 1 +
drivers/video/mx5fb.c | 846 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 858 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/mx5fb.c
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 27c1fb4..1901915 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2236,6 +2236,17 @@ config FB_MX3
far only synchronous displays are supported. If you plan to use
an LCD display with your i.MX31 system, say Y here.
+config FB_MX5
+ tristate "MX5 Framebuffer support"
+ depends on FB && MFD_IMX_IPU_V3
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ select FB_MODE_HELPERS
+ help
+ This is a framebuffer device for the i.MX51 LCD Controller. If you
+ plan to use an LCD display with your i.MX51 system, say Y here.
+
config FB_BROADSHEET
tristate "E-Ink Broadsheet/Epson S1D13521 controller support"
depends on FB
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 485e8ed..ad408d2 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -145,6 +145,7 @@ obj-$(CONFIG_FB_BF54X_LQ043) += bf54x-lq043fb.o
obj-$(CONFIG_FB_BFIN_LQ035Q1) += bfin-lq035q1-fb.o
obj-$(CONFIG_FB_BFIN_T350MCQB) += bfin-t350mcqb-fb.o
obj-$(CONFIG_FB_MX3) += mx3fb.o
+obj-$(CONFIG_FB_MX5) += mx5fb.o
obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o
# the test framebuffer is last
diff --git a/drivers/video/mx5fb.c b/drivers/video/mx5fb.c
new file mode 100644
index 0000000..fd9baf4
--- /dev/null
+++ b/drivers/video/mx5fb.c
@@ -0,0 +1,846 @@
+/*
+ * Copyright 2004-2009 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ *
+ * Framebuffer Framebuffer Driver for SDC and ADC.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/errno.h>
+#include <linux/string.h>
+#include <linux/interrupt.h>
+#include <linux/slab.h>
+#include <linux/fb.h>
+#include <linux/delay.h>
+#include <linux/init.h>
+#include <linux/dma-mapping.h>
+#include <linux/console.h>
+#include <linux/mfd/imx-ipu-v3.h>
+#include <asm/uaccess.h>
+#include <mach/ipu-v3.h>
+
+#define DRIVER_NAME "imx-ipuv3-fb"
+
+struct imx_ipu_fb_info {
+ int ipu_channel_num;
+ struct ipu_channel *ipu_ch;
+ int dc;
+ int ipu_di;
+ u32 ipu_di_pix_fmt;
+ u32 ipu_in_pix_fmt;
+
+ u32 pseudo_palette[16];
+
+ struct ipu_dp *dp;
+ struct dmfc_channel *dmfc;
+ struct fb_info *slave;
+ struct fb_info *master;
+ bool enabled;
+};
+
+static int imx_ipu_fb_set_fix(struct fb_info *info)
+{
+ struct fb_fix_screeninfo *fix = &info->fix;
+ struct fb_var_screeninfo *var = &info->var;
+
+ fix->line_length = var->xres_virtual * var->bits_per_pixel / 8;
+
+ fix->type = FB_TYPE_PACKED_PIXELS;
+ fix->accel = FB_ACCEL_NONE;
+ fix->visual = FB_VISUAL_TRUECOLOR;
+ fix->xpanstep = 1;
+ fix->ypanstep = 1;
+
+ return 0;
+}
+
+static int imx_ipu_fb_map_video_memory(struct fb_info *fbi)
+{
+ int size;
+
+ size = fbi->var.yres_virtual * fbi->fix.line_length;
+
+ if (fbi->screen_base) {
+ if (fbi->fix.smem_len >= size)
+ return 0;
+
+ dma_free_writecombine(fbi->device, fbi->fix.smem_len,
+ fbi->screen_base, fbi->fix.smem_start);
+ }
+
+ fbi->screen_base = dma_alloc_writecombine(fbi->device,
+ size,
+ (dma_addr_t *)&fbi->fix.smem_start,
+ GFP_DMA);
+ if (fbi->screen_base = 0) {
+ dev_err(fbi->device, "Unable to allocate framebuffer memory (%d)\n",
+ fbi->fix.smem_len);
+ fbi->fix.smem_len = 0;
+ fbi->fix.smem_start = 0;
+ return -ENOMEM;
+ }
+
+ fbi->fix.smem_len = size;
+ fbi->screen_size = fbi->fix.smem_len;
+
+ dev_dbg(fbi->device, "allocated fb @ paddr=0x%08lx, size=%d\n",
+ fbi->fix.smem_start, fbi->fix.smem_len);
+
+ /* Clear the screen */
+ memset((char *)fbi->screen_base, 0, fbi->fix.smem_len);
+
+ return 0;
+}
+
+static void imx_ipu_fb_enable(struct fb_info *fbi)
+{
+ struct imx_ipu_fb_info *mxc_fbi = fbi->par;
+
+ if (mxc_fbi->enabled)
+ return;
+
+ ipu_di_enable(mxc_fbi->ipu_di);
+ ipu_dmfc_enable_channel(mxc_fbi->dmfc);
+ ipu_idmac_enable_channel(mxc_fbi->ipu_ch);
+ ipu_dc_enable_channel(mxc_fbi->dc);
+ ipu_dp_enable_channel(mxc_fbi->dp);
+ mxc_fbi->enabled = 1;
+}
+
+static void imx_ipu_fb_disable(struct fb_info *fbi)
+{
+ struct imx_ipu_fb_info *mxc_fbi = fbi->par;
+
+ if (!mxc_fbi->enabled)
+ return;
+
+ ipu_dp_disable_channel(mxc_fbi->dp);
+ ipu_dc_disable_channel(mxc_fbi->dc);
+ ipu_idmac_disable_channel(mxc_fbi->ipu_ch);
+ ipu_dmfc_disable_channel(mxc_fbi->dmfc);
+ ipu_di_disable(mxc_fbi->ipu_di);
+
+ mxc_fbi->enabled = 0;
+}
+
+static int calc_vref(struct fb_var_screeninfo *var)
+{
+ unsigned long htotal, vtotal;
+
+ htotal = var->xres + var->right_margin + var->hsync_len + var->left_margin;
+ vtotal = var->yres + var->lower_margin + var->vsync_len + var->upper_margin;
+
+ if (!htotal || !vtotal)
+ return 60;
+
+ return PICOS2KHZ(var->pixclock) * 1000 / vtotal / htotal;
+}
+
+static int calc_bandwidth(struct fb_var_screeninfo *var, unsigned int vref)
+{
+ return var->xres * var->yres * vref;
+}
+
+static int imx_ipu_fb_set_par(struct fb_info *fbi)
+{
+ int ret;
+ struct ipu_di_signal_cfg sig_cfg;
+ struct imx_ipu_fb_info *mxc_fbi = fbi->par;
+ u32 out_pixel_fmt;
+ int interlaced = 0;
+ struct fb_var_screeninfo *var = &fbi->var;
+ int enabled = mxc_fbi->enabled;
+
+ dev_dbg(fbi->device, "Reconfiguring framebuffer %dx%d-%d\n",
+ fbi->var.xres, fbi->var.yres, fbi->var.bits_per_pixel);
+
+ if (enabled)
+ imx_ipu_fb_disable(fbi);
+
+ fbi->fix.line_length = var->xres_virtual * var->bits_per_pixel / 8;
+
+ var->yres_virtual = var->yres;
+
+ ret = imx_ipu_fb_map_video_memory(fbi);
+ if (ret)
+ return ret;
+
+ if (var->vmode & FB_VMODE_INTERLACED)
+ interlaced = 1;
+
+ memset(&sig_cfg, 0, sizeof(sig_cfg));
+ out_pixel_fmt = mxc_fbi->ipu_di_pix_fmt;
+
+ if (var->vmode & FB_VMODE_INTERLACED)
+ sig_cfg.interlaced = 1;
+ if (var->vmode & FB_VMODE_ODD_FLD_FIRST) /* PAL */
+ sig_cfg.odd_field_first = 1;
+ if (var->sync & FB_SYNC_EXT)
+ sig_cfg.ext_clk = 1;
+ if (var->sync & FB_SYNC_HOR_HIGH_ACT)
+ sig_cfg.Hsync_pol = 1;
+ if (var->sync & FB_SYNC_VERT_HIGH_ACT)
+ sig_cfg.Vsync_pol = 1;
+ if (!(var->sync & FB_SYNC_CLK_LAT_FALL))
+ sig_cfg.clk_pol = 1;
+ if (var->sync & FB_SYNC_DATA_INVERT)
+ sig_cfg.data_pol = 1;
+ if (!(var->sync & FB_SYNC_OE_LOW_ACT))
+ sig_cfg.enable_pol = 1;
+ if (var->sync & FB_SYNC_CLK_IDLE_EN)
+ sig_cfg.clkidle_en = 1;
+
+ dev_dbg(fbi->device, "pixclock = %lu.%03lu MHz\n",
+ PICOS2KHZ(var->pixclock) / 1000,
+ PICOS2KHZ(var->pixclock) % 1000);
+
+ sig_cfg.width = var->xres;
+ sig_cfg.height = var->yres;
+ sig_cfg.pixel_fmt = out_pixel_fmt;
+ sig_cfg.h_start_width = var->left_margin;
+ sig_cfg.h_sync_width = var->hsync_len;
+ sig_cfg.h_end_width = var->right_margin;
+ sig_cfg.v_start_width = var->upper_margin;
+ sig_cfg.v_sync_width = var->vsync_len;
+ sig_cfg.v_end_width = var->lower_margin;
+ sig_cfg.v_to_h_sync = 0;
+
+ if (mxc_fbi->dp) {
+ ret = ipu_dp_setup_channel(mxc_fbi->dp, mxc_fbi->ipu_in_pix_fmt,
+ out_pixel_fmt, 1);
+ if (ret) {
+ dev_dbg(fbi->device, "initializing display processor failed with %d\n",
+ ret);
+ return ret;
+ }
+ }
+
+ ret = ipu_dc_init_sync(mxc_fbi->dc, mxc_fbi->ipu_di, interlaced,
+ out_pixel_fmt, fbi->var.xres);
+ if (ret) {
+ dev_dbg(fbi->device, "initializing display controller failed with %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = ipu_di_init_sync_panel(mxc_fbi->ipu_di,
+ PICOS2KHZ(var->pixclock) * 1000UL,
+ &sig_cfg);
+ if (ret) {
+ dev_dbg(fbi->device, "initializing panel failed with %d\n",
+ ret);
+ return ret;
+ }
+
+ fbi->mode = (struct fb_videomode *)fb_match_mode(var, &fbi->modelist);
+ var->xoffset = var->yoffset = 0;
+
+ if (fbi->var.vmode & FB_VMODE_INTERLACED)
+ interlaced = 1;
+
+ ret = ipu_idmac_init_channel_buffer(mxc_fbi->ipu_ch,
+ mxc_fbi->ipu_in_pix_fmt,
+ var->xres, var->yres,
+ fbi->fix.line_length,
+ IPU_ROTATE_NONE,
+ fbi->fix.smem_start,
+ 0,
+ 0, 0, interlaced);
+ if (ret) {
+ dev_dbg(fbi->device, "init channel buffer failed with %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = ipu_dmfc_init_channel(mxc_fbi->dmfc, var->xres);
+ if (ret) {
+ dev_dbg(fbi->device, "initializing dmfc channel failed with %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = ipu_dmfc_alloc_bandwidth(mxc_fbi->dmfc, calc_bandwidth(var, calc_vref(var)));
+ if (ret) {
+ dev_dbg(fbi->device, "allocating dmfc bandwidth failed with %d\n",
+ ret);
+ return ret;
+ }
+
+ if (enabled)
+ imx_ipu_fb_enable(fbi);
+
+ return ret;
+}
+
+/*
+ * These are the bitfields for each
+ * display depth that we support.
+ */
+struct imxfb_rgb {
+ struct fb_bitfield red;
+ struct fb_bitfield green;
+ struct fb_bitfield blue;
+ struct fb_bitfield transp;
+};
+
+static struct imxfb_rgb def_rgb_8 = {
+ .red = { .offset = 5, .length = 3, },
+ .green = { .offset = 2, .length = 3, },
+ .blue = { .offset = 0, .length = 2, },
+ .transp = { .offset = 0, .length = 0, },
+};
+
+static struct imxfb_rgb def_rgb_16 = {
+ .red = { .offset = 11, .length = 5, },
+ .green = { .offset = 5, .length = 6, },
+ .blue = { .offset = 0, .length = 5, },
+ .transp = { .offset = 0, .length = 0, },
+};
+
+static struct imxfb_rgb def_rgb_24 = {
+ .red = { .offset = 16, .length = 8, },
+ .green = { .offset = 8, .length = 8, },
+ .blue = { .offset = 0, .length = 8, },
+ .transp = { .offset = 0, .length = 0, },
+};
+
+static struct imxfb_rgb def_rgb_32 = {
+ .red = { .offset = 16, .length = 8, },
+ .green = { .offset = 8, .length = 8, },
+ .blue = { .offset = 0, .length = 8, },
+ .transp = { .offset = 24, .length = 8, },
+};
+
+/*
+ * Check framebuffer variable parameters and adjust to valid values.
+ *
+ * @param var framebuffer variable parameters
+ *
+ * @param info framebuffer information pointer
+ */
+static int imx_ipu_fb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
+{
+ struct imx_ipu_fb_info *mxc_fbi = info->par;
+ struct imxfb_rgb *rgb;
+
+ /* we don't support xpan, force xres_virtual to be equal to xres */
+ var->xres_virtual = var->xres;
+
+ if (var->yres_virtual < var->yres)
+ var->yres_virtual = var->yres;
+
+ switch (var->bits_per_pixel) {
+ case 8:
+ rgb = &def_rgb_8;
+ break;
+ case 16:
+ rgb = &def_rgb_16;
+ mxc_fbi->ipu_in_pix_fmt = IPU_PIX_FMT_RGB565;
+ break;
+ case 24:
+ rgb = &def_rgb_24;
+ mxc_fbi->ipu_in_pix_fmt = IPU_PIX_FMT_BGR24;
+ break;
+ case 32:
+ rgb = &def_rgb_32;
+ mxc_fbi->ipu_in_pix_fmt = IPU_PIX_FMT_BGR32;
+ break;
+ default:
+ var->bits_per_pixel = 24;
+ rgb = &def_rgb_24;
+ mxc_fbi->ipu_in_pix_fmt = IPU_PIX_FMT_BGR24;
+ }
+
+ var->red = rgb->red;
+ var->green = rgb->green;
+ var->blue = rgb->blue;
+ var->transp = rgb->transp;
+
+ return 0;
+}
+
+static inline unsigned int chan_to_field(u_int chan, struct fb_bitfield *bf)
+{
+ chan &= 0xffff;
+ chan >>= 16 - bf->length;
+ return chan << bf->offset;
+}
+
+static int imx_ipu_fb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
+ u_int trans, struct fb_info *fbi)
+{
+ unsigned int val;
+ int ret = 1;
+
+ /*
+ * If greyscale is true, then we convert the RGB value
+ * to greyscale no matter what visual we are using.
+ */
+ if (fbi->var.grayscale)
+ red = green = blue = (19595 * red + 38470 * green +
+ 7471 * blue) >> 16;
+ switch (fbi->fix.visual) {
+ case FB_VISUAL_TRUECOLOR:
+ /*
+ * 16-bit True Colour. We encode the RGB value
+ * according to the RGB bitfield information.
+ */
+ if (regno < 16) {
+ u32 *pal = fbi->pseudo_palette;
+
+ val = chan_to_field(red, &fbi->var.red);
+ val |= chan_to_field(green, &fbi->var.green);
+ val |= chan_to_field(blue, &fbi->var.blue);
+
+ pal[regno] = val;
+ ret = 0;
+ }
+ break;
+
+ case FB_VISUAL_STATIC_PSEUDOCOLOR:
+ case FB_VISUAL_PSEUDOCOLOR:
+ break;
+ }
+
+ return ret;
+}
+
+static int imx_ipu_fb_blank(int blank, struct fb_info *info)
+{
+ dev_dbg(info->device, "blank = %d\n", blank);
+
+ switch (blank) {
+ case FB_BLANK_POWERDOWN:
+ case FB_BLANK_VSYNC_SUSPEND:
+ case FB_BLANK_HSYNC_SUSPEND:
+ case FB_BLANK_NORMAL:
+ imx_ipu_fb_disable(info);
+ break;
+ case FB_BLANK_UNBLANK:
+ imx_ipu_fb_enable(info);
+ break;
+ }
+
+ return 0;
+}
+
+static int imx_ipu_fb_pan_display(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ struct imx_ipu_fb_info *mxc_fbi = info->par;
+ unsigned long base;
+ int ret;
+
+ if (info->var.yoffset = var->yoffset)
+ return 0; /* No change, do nothing */
+
+ base = var->yoffset * var->xres_virtual * var->bits_per_pixel / 8;
+ base += info->fix.smem_start;
+
+ ret = ipu_wait_for_interrupt(IPU_IRQ_EOF(mxc_fbi->ipu_channel_num), 100);
+ if (ret)
+ return ret;
+
+ if (ipu_idmac_update_channel_buffer(mxc_fbi->ipu_ch, 0, base)) {
+ dev_err(info->device,
+ "Error updating SDC buf to address=0x%08lX\n", base);
+ }
+
+ info->var.yoffset = var->yoffset;
+
+ return 0;
+}
+
+static struct fb_ops imx_ipu_fb_ops = {
+ .owner = THIS_MODULE,
+ .fb_set_par = imx_ipu_fb_set_par,
+ .fb_check_var = imx_ipu_fb_check_var,
+ .fb_setcolreg = imx_ipu_fb_setcolreg,
+ .fb_pan_display = imx_ipu_fb_pan_display,
+ .fb_fillrect = cfb_fillrect,
+ .fb_copyarea = cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+ .fb_blank = imx_ipu_fb_blank,
+};
+
+/*
+ * Overlay functions
+ */
+static int imx_ipu_fb_enable_overlay(struct fb_info *fbi)
+{
+ struct imx_ipu_fb_info *mxc_fbi = fbi->par;
+
+ ipu_dmfc_enable_channel(mxc_fbi->dmfc);
+ ipu_idmac_enable_channel(mxc_fbi->ipu_ch);
+ ipu_dp_enable_fg(mxc_fbi->dp);
+
+ return 0;
+}
+
+static int imx_ipu_fb_disable_overlay(struct fb_info *fbi)
+{
+ struct imx_ipu_fb_info *mxc_fbi = fbi->par;
+
+ ipu_dp_disable_fg(mxc_fbi->dp);
+ ipu_idmac_disable_channel(mxc_fbi->ipu_ch);
+ ipu_dmfc_disable_channel(mxc_fbi->dmfc);
+
+ return 0;
+}
+
+static int imx_ipu_fb_set_par_overlay(struct fb_info *fbi)
+{
+ struct imx_ipu_fb_info *mxc_fbi = fbi->par;
+ struct fb_var_screeninfo *var = &fbi->var;
+ struct fb_info *fbi_master = mxc_fbi->master;
+ struct fb_var_screeninfo *var_master = &fbi_master->var;
+ int ret;
+ int interlaced = 0;
+ int enabled = mxc_fbi->enabled;
+
+ dev_dbg(fbi->device, "Reconfiguring framebuffer %dx%d-%d\n",
+ fbi->var.xres, fbi->var.yres, fbi->var.bits_per_pixel);
+
+ if (enabled)
+ imx_ipu_fb_disable_overlay(fbi);
+
+ fbi->fix.line_length = var->xres_virtual *
+ var->bits_per_pixel / 8;
+
+ ret = imx_ipu_fb_map_video_memory(fbi);
+ if (ret)
+ return ret;
+
+ ipu_dp_set_window_pos(mxc_fbi->dp, 64, 64);
+
+ var->xoffset = var->yoffset = 0;
+
+ if (var->vmode & FB_VMODE_INTERLACED)
+ interlaced = 1;
+
+ ret = ipu_idmac_init_channel_buffer(mxc_fbi->ipu_ch,
+ mxc_fbi->ipu_in_pix_fmt,
+ var->xres, var->yres,
+ fbi->fix.line_length,
+ IPU_ROTATE_NONE,
+ fbi->fix.smem_start,
+ 0,
+ 0, 0, interlaced);
+ if (ret) {
+ dev_dbg(fbi->device, "init channel buffer failed with %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = ipu_dmfc_init_channel(mxc_fbi->dmfc, var->xres);
+ if (ret) {
+ dev_dbg(fbi->device, "initializing dmfc channel failed with %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = ipu_dmfc_alloc_bandwidth(mxc_fbi->dmfc, calc_bandwidth(var, calc_vref(var_master)));
+ if (ret) {
+ dev_dbg(fbi->device, "allocating dmfc bandwidth failed with %d\n",
+ ret);
+ return ret;
+ }
+
+ if (enabled)
+ imx_ipu_fb_enable_overlay(fbi);
+
+ return ret;
+}
+
+static int imx_ipu_fb_blank_overlay(int blank, struct fb_info *fbi)
+{
+ dev_dbg(fbi->device, "blank = %d\n", blank);
+
+ switch (blank) {
+ case FB_BLANK_POWERDOWN:
+ case FB_BLANK_VSYNC_SUSPEND:
+ case FB_BLANK_HSYNC_SUSPEND:
+ case FB_BLANK_NORMAL:
+ imx_ipu_fb_disable_overlay(fbi);
+ break;
+ case FB_BLANK_UNBLANK:
+ imx_ipu_fb_enable_overlay(fbi);
+ break;
+ }
+
+ return 0;
+}
+
+static struct fb_ops imx_ipu_fb_overlay_ops = {
+ .owner = THIS_MODULE,
+ .fb_set_par = imx_ipu_fb_set_par_overlay,
+ .fb_check_var = imx_ipu_fb_check_var,
+ .fb_setcolreg = imx_ipu_fb_setcolreg,
+ .fb_pan_display = imx_ipu_fb_pan_display,
+ .fb_fillrect = cfb_fillrect,
+ .fb_copyarea = cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+ .fb_blank = imx_ipu_fb_blank_overlay,
+};
+
+static struct fb_info *imx_ipu_fb_init_fbinfo(struct device *dev, struct fb_ops *ops)
+{
+ struct fb_info *fbi;
+ struct imx_ipu_fb_info *mxc_fbi;
+
+ fbi = framebuffer_alloc(sizeof(struct imx_ipu_fb_info), dev);
+ if (!fbi)
+ return NULL;
+
+ BUG_ON(fbi->par = NULL);
+ mxc_fbi = fbi->par;
+
+ fbi->var.activate = FB_ACTIVATE_NOW;
+
+ fbi->fbops = ops;
+ fbi->flags = FBINFO_FLAG_DEFAULT;
+ fbi->pseudo_palette = mxc_fbi->pseudo_palette;
+
+ fb_alloc_cmap(&fbi->cmap, 16, 0);
+
+ return fbi;
+}
+
+static int imx_ipu_fb_init_overlay(struct platform_device *pdev,
+ struct fb_info *fbi_master, int ipu_channel)
+{
+ struct imx_ipu_fb_info *mxc_fbi_master = fbi_master->par;
+ struct fb_info *ovlfbi;
+ struct imx_ipu_fb_info *ovl_mxc_fbi;
+ int ret;
+
+ ovlfbi = imx_ipu_fb_init_fbinfo(&pdev->dev, &imx_ipu_fb_overlay_ops);
+ if (!ovlfbi)
+ return -ENOMEM;
+
+ ovl_mxc_fbi = ovlfbi->par;
+ ovl_mxc_fbi->ipu_ch = ipu_idmac_get(ipu_channel);
+ ovl_mxc_fbi->dmfc = ipu_dmfc_get(ipu_channel);
+ ovl_mxc_fbi->ipu_di = -1;
+ ovl_mxc_fbi->dp = mxc_fbi_master->dp;
+ ovl_mxc_fbi->master = fbi_master;
+ mxc_fbi_master->slave = ovlfbi;
+
+ ovlfbi->var.xres = 240;
+ ovlfbi->var.yres = 320;
+ ovlfbi->var.yres_virtual = ovlfbi->var.yres;
+ ovlfbi->var.xres_virtual = ovlfbi->var.xres;
+ imx_ipu_fb_check_var(&ovlfbi->var, ovlfbi);
+ imx_ipu_fb_set_fix(ovlfbi);
+
+ ret = register_framebuffer(ovlfbi);
+ if (ret) {
+ framebuffer_release(ovlfbi);
+ return ret;
+ }
+
+ ipu_dp_set_global_alpha(ovl_mxc_fbi->dp, 1, 0x80, 1);
+ ipu_dp_set_color_key(ovl_mxc_fbi->dp, 0, 0);
+
+ imx_ipu_fb_set_par_overlay(ovlfbi);
+
+ return 0;
+}
+
+static void imx_ipu_fb_exit_overlay(struct platform_device *pdev,
+ struct fb_info *fbi_master, int ipu_channel)
+{
+ struct imx_ipu_fb_info *mxc_fbi_master = fbi_master->par;
+ struct fb_info *ovlfbi = mxc_fbi_master->slave;
+ struct imx_ipu_fb_info *ovl_mxc_fbi = ovlfbi->par;
+
+ imx_ipu_fb_blank_overlay(FB_BLANK_POWERDOWN, ovlfbi);
+
+ unregister_framebuffer(ovlfbi);
+
+ ipu_idmac_put(ovl_mxc_fbi->ipu_ch);
+ ipu_dmfc_free_bandwidth(ovl_mxc_fbi->dmfc);
+ ipu_dmfc_put(ovl_mxc_fbi->dmfc);
+
+ framebuffer_release(ovlfbi);
+}
+
+static int imx_ipu_fb_find_mode(struct fb_info *fbi)
+{
+ int ret;
+ struct fb_videomode *mode_array;
+ struct fb_modelist *modelist;
+ struct fb_var_screeninfo *var = &fbi->var;
+ int i = 0;
+
+ list_for_each_entry(modelist, &fbi->modelist, list)
+ i++;
+
+ mode_array = kmalloc(sizeof (struct fb_modelist) * i, GFP_KERNEL);
+ if (!mode_array)
+ return -ENOMEM;
+
+ i = 0;
+ list_for_each_entry(modelist, &fbi->modelist, list)
+ mode_array[i++] = modelist->mode;
+
+ ret = fb_find_mode(&fbi->var, fbi, NULL, mode_array, i, NULL, 16);
+ if (ret = 0)
+ return -EINVAL;
+
+ dev_dbg(fbi->device, "found %dx%d-%d hs:%d:%d:%d vs:%d:%d:%d\n",
+ var->xres, var->yres, var->bits_per_pixel,
+ var->hsync_len, var->left_margin, var->right_margin,
+ var->vsync_len, var->upper_margin, var->lower_margin);
+
+ kfree(mode_array);
+
+ return 0;
+}
+
+static int __devinit imx_ipu_fb_probe(struct platform_device *pdev)
+{
+ struct fb_info *fbi;
+ struct imx_ipu_fb_info *mxc_fbi;
+ struct ipuv3_fb_platform_data *plat_data = pdev->dev.platform_data;
+ int ret = 0, i;
+
+ pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+
+ fbi = imx_ipu_fb_init_fbinfo(&pdev->dev, &imx_ipu_fb_ops);
+ if (!fbi)
+ return -ENOMEM;
+
+ mxc_fbi = fbi->par;
+
+ mxc_fbi->ipu_channel_num = plat_data->ipu_channel_bg;
+ mxc_fbi->dc = plat_data->dc_channel;
+ mxc_fbi->ipu_di_pix_fmt = plat_data->interface_pix_fmt;
+ mxc_fbi->ipu_di = pdev->id;
+
+ mxc_fbi->ipu_ch = ipu_idmac_get(plat_data->ipu_channel_bg);
+ if (IS_ERR(mxc_fbi->ipu_ch)) {
+ ret = PTR_ERR(mxc_fbi->ipu_ch);
+ goto failed_request_ipu;
+ }
+
+ mxc_fbi->dmfc = ipu_dmfc_get(plat_data->ipu_channel_bg);
+ if (IS_ERR(mxc_fbi->ipu_ch)) {
+ ret = PTR_ERR(mxc_fbi->ipu_ch);
+ goto failed_request_dmfc;
+ }
+
+ if (plat_data->dp_channel >= 0) {
+ mxc_fbi->dp = ipu_dp_get(plat_data->dp_channel);
+ if (IS_ERR(mxc_fbi->dp)) {
+ ret = PTR_ERR(mxc_fbi->ipu_ch);
+ goto failed_request_dp;
+ }
+ }
+
+ fbi->var.yres_virtual = fbi->var.yres;
+
+ INIT_LIST_HEAD(&fbi->modelist);
+ for (i = 0; i < plat_data->num_modes; i++)
+ fb_add_videomode(&plat_data->modes[i], &fbi->modelist);
+
+ if (plat_data->flags & IMX_IPU_FB_USE_MODEDB) {
+ for (i = 0; i < num_fb_modes; i++)
+ fb_add_videomode(&fb_modes[i], &fbi->modelist);
+ }
+
+ imx_ipu_fb_find_mode(fbi);
+
+ imx_ipu_fb_check_var(&fbi->var, fbi);
+ imx_ipu_fb_set_fix(fbi);
+ ret = register_framebuffer(fbi);
+ if (ret < 0)
+ goto failed_register;
+
+ imx_ipu_fb_set_par(fbi);
+ imx_ipu_fb_blank(FB_BLANK_UNBLANK, fbi);
+
+ if (plat_data->ipu_channel_fg >= 0 && plat_data->flags & IMX_IPU_FB_USE_OVERLAY)
+ imx_ipu_fb_init_overlay(pdev, fbi, plat_data->ipu_channel_fg);
+
+ platform_set_drvdata(pdev, fbi);
+
+ return 0;
+
+failed_register:
+ if (plat_data->dp_channel >= 0)
+ ipu_dp_put(mxc_fbi->dp);
+failed_request_dp:
+ ipu_dmfc_put(mxc_fbi->dmfc);
+failed_request_dmfc:
+ ipu_idmac_put(mxc_fbi->ipu_ch);
+failed_request_ipu:
+ fb_dealloc_cmap(&fbi->cmap);
+ framebuffer_release(fbi);
+
+ return ret;
+}
+
+static int __devexit imx_ipu_fb_remove(struct platform_device *pdev)
+{
+ struct fb_info *fbi = platform_get_drvdata(pdev);
+ struct imx_ipu_fb_info *mxc_fbi = fbi->par;
+ struct ipuv3_fb_platform_data *plat_data = pdev->dev.platform_data;
+
+ if (plat_data->ipu_channel_fg >= 0 && plat_data->flags & IMX_IPU_FB_USE_OVERLAY)
+ imx_ipu_fb_exit_overlay(pdev, fbi, plat_data->ipu_channel_fg);
+
+ imx_ipu_fb_blank(FB_BLANK_POWERDOWN, fbi);
+
+ dma_free_writecombine(fbi->device, fbi->fix.smem_len,
+ fbi->screen_base, fbi->fix.smem_start);
+
+ if (&fbi->cmap)
+ fb_dealloc_cmap(&fbi->cmap);
+
+ unregister_framebuffer(fbi);
+
+ if (plat_data->dp_channel >= 0)
+ ipu_dp_put(mxc_fbi->dp);
+ ipu_dmfc_free_bandwidth(mxc_fbi->dmfc);
+ ipu_dmfc_put(mxc_fbi->dmfc);
+ ipu_idmac_put(mxc_fbi->ipu_ch);
+
+ framebuffer_release(fbi);
+
+ return 0;
+}
+
+static struct platform_driver imx_ipu_fb_driver = {
+ .driver = {
+ .name = DRIVER_NAME,
+ },
+ .probe = imx_ipu_fb_probe,
+ .remove = __devexit_p(imx_ipu_fb_remove),
+};
+
+static int __init imx_ipu_fb_init(void)
+{
+ return platform_driver_register(&imx_ipu_fb_driver);
+}
+
+static void __exit imx_ipu_fb_exit(void)
+{
+ platform_driver_unregister(&imx_ipu_fb_driver);
+}
+
+module_init(imx_ipu_fb_init);
+module_exit(imx_ipu_fb_exit);
+
+MODULE_AUTHOR("Freescale Semiconductor, Inc.");
+MODULE_DESCRIPTION("i.MX framebuffer driver");
+MODULE_LICENSE("GPL");
+MODULE_SUPPORTED_DEVICE("fb");
--
1.7.2.3
^ permalink raw reply related [flat|nested] 34+ messages in thread* Re: [PATCH 5/9] Add i.MX5 framebuffer driver
2010-12-09 13:47 ` [PATCH 5/9] Add i.MX5 framebuffer driver Sascha Hauer
@ 2010-12-12 6:13 ` Liu Ying
2010-12-13 7:23 ` Lothar Waßmann
2010-12-13 11:38 ` Sascha Hauer
0 siblings, 2 replies; 34+ messages in thread
From: Liu Ying @ 2010-12-12 6:13 UTC (permalink / raw)
To: linux-arm-kernel
Hello, Sascha,
I have following comments to this patch:
1) Please modify the commit message, as IPUv3 is not embedded in i.MX50 SoC.
2) ADC is not supported yet in the framebuffer driver, so please
modify this comment:
> + * Framebuffer Framebuffer Driver for SDC and ADC.
3) 'ipu_dp_set_window_pos()' is called only once in
imx_ipu_fb_set_par_overlay(). So, the framebuffer driver doesn't
support to change the overlay framebuffer position. Need a
mechanism/interface for users to change the overlay framebuffer
position.
4) Need to make sure the framebuffer on DP-FG is blanked before the
framebuffer on DP-BG is blanked. Meanwhile, the framebuffer on DP-FG
should be unblanked after the framebuffer on DP-BG is unblanked
5) Need to check the framebuffer on DP-FG doesn't run out of the range
of the framebuffer on DP-BG.
6) I prefer to find the video mode in modedb first, and if we cannot
find the video mode in common video mode data base, we can find a
video mode in custom video mode data base which is defined in platform
data. In this way, we don't need to export common modefb.
Best Regards,
Liu Ying
2010/12/9 Sascha Hauer <s.hauer@pengutronix.de>:
> This patch adds framebuffer support to the Freescale i.MX SoCs
> equipped with an IPU v3, so far these are the i.MX50/51/53.
>
> This driver has been tested on the i.MX51 babbage board with
> both DVI and analog VGA in different resolutions and color depths.
> It has also been tested on a custom i.MX51 board using a fixed
> resolution panel.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> drivers/video/Kconfig | 11 +
> drivers/video/Makefile | 1 +
> drivers/video/mx5fb.c | 846 ++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 858 insertions(+), 0 deletions(-)
> create mode 100644 drivers/video/mx5fb.c
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 27c1fb4..1901915 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2236,6 +2236,17 @@ config FB_MX3
> far only synchronous displays are supported. If you plan to use
> an LCD display with your i.MX31 system, say Y here.
>
> +config FB_MX5
> + tristate "MX5 Framebuffer support"
> + depends on FB && MFD_IMX_IPU_V3
> + select FB_CFB_FILLRECT
> + select FB_CFB_COPYAREA
> + select FB_CFB_IMAGEBLIT
> + select FB_MODE_HELPERS
> + help
> + This is a framebuffer device for the i.MX51 LCD Controller. If you
> + plan to use an LCD display with your i.MX51 system, say Y here.
> +
> config FB_BROADSHEET
> tristate "E-Ink Broadsheet/Epson S1D13521 controller support"
> depends on FB
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index 485e8ed..ad408d2 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -145,6 +145,7 @@ obj-$(CONFIG_FB_BF54X_LQ043) += bf54x-lq043fb.o
> obj-$(CONFIG_FB_BFIN_LQ035Q1) += bfin-lq035q1-fb.o
> obj-$(CONFIG_FB_BFIN_T350MCQB) += bfin-t350mcqb-fb.o
> obj-$(CONFIG_FB_MX3) += mx3fb.o
> +obj-$(CONFIG_FB_MX5) += mx5fb.o
> obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o
>
> # the test framebuffer is last
> diff --git a/drivers/video/mx5fb.c b/drivers/video/mx5fb.c
> new file mode 100644
> index 0000000..fd9baf4
> --- /dev/null
> +++ b/drivers/video/mx5fb.c
> @@ -0,0 +1,846 @@
> +/*
> + * Copyright 2004-2009 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + *
> + * Framebuffer Framebuffer Driver for SDC and ADC.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/platform_device.h>
> +#include <linux/errno.h>
> +#include <linux/string.h>
> +#include <linux/interrupt.h>
> +#include <linux/slab.h>
> +#include <linux/fb.h>
> +#include <linux/delay.h>
> +#include <linux/init.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/console.h>
> +#include <linux/mfd/imx-ipu-v3.h>
> +#include <asm/uaccess.h>
> +#include <mach/ipu-v3.h>
> +
> +#define DRIVER_NAME "imx-ipuv3-fb"
> +
> +struct imx_ipu_fb_info {
> + int ipu_channel_num;
> + struct ipu_channel *ipu_ch;
> + int dc;
> + int ipu_di;
> + u32 ipu_di_pix_fmt;
> + u32 ipu_in_pix_fmt;
> +
> + u32 pseudo_palette[16];
> +
> + struct ipu_dp *dp;
> + struct dmfc_channel *dmfc;
> + struct fb_info *slave;
> + struct fb_info *master;
> + bool enabled;
> +};
> +
> +static int imx_ipu_fb_set_fix(struct fb_info *info)
> +{
> + struct fb_fix_screeninfo *fix = &info->fix;
> + struct fb_var_screeninfo *var = &info->var;
> +
> + fix->line_length = var->xres_virtual * var->bits_per_pixel / 8;
> +
> + fix->type = FB_TYPE_PACKED_PIXELS;
> + fix->accel = FB_ACCEL_NONE;
> + fix->visual = FB_VISUAL_TRUECOLOR;
> + fix->xpanstep = 1;
> + fix->ypanstep = 1;
> +
> + return 0;
> +}
> +
> +static int imx_ipu_fb_map_video_memory(struct fb_info *fbi)
> +{
> + int size;
> +
> + size = fbi->var.yres_virtual * fbi->fix.line_length;
> +
> + if (fbi->screen_base) {
> + if (fbi->fix.smem_len >= size)
> + return 0;
> +
> + dma_free_writecombine(fbi->device, fbi->fix.smem_len,
> + fbi->screen_base, fbi->fix.smem_start);
> + }
> +
> + fbi->screen_base = dma_alloc_writecombine(fbi->device,
> + size,
> + (dma_addr_t *)&fbi->fix.smem_start,
> + GFP_DMA);
> + if (fbi->screen_base = 0) {
> + dev_err(fbi->device, "Unable to allocate framebuffer memory (%d)\n",
> + fbi->fix.smem_len);
> + fbi->fix.smem_len = 0;
> + fbi->fix.smem_start = 0;
> + return -ENOMEM;
> + }
> +
> + fbi->fix.smem_len = size;
> + fbi->screen_size = fbi->fix.smem_len;
> +
> + dev_dbg(fbi->device, "allocated fb @ paddr=0x%08lx, size=%d\n",
> + fbi->fix.smem_start, fbi->fix.smem_len);
> +
> + /* Clear the screen */
> + memset((char *)fbi->screen_base, 0, fbi->fix.smem_len);
> +
> + return 0;
> +}
> +
> +static void imx_ipu_fb_enable(struct fb_info *fbi)
> +{
> + struct imx_ipu_fb_info *mxc_fbi = fbi->par;
> +
> + if (mxc_fbi->enabled)
> + return;
> +
> + ipu_di_enable(mxc_fbi->ipu_di);
> + ipu_dmfc_enable_channel(mxc_fbi->dmfc);
> + ipu_idmac_enable_channel(mxc_fbi->ipu_ch);
> + ipu_dc_enable_channel(mxc_fbi->dc);
> + ipu_dp_enable_channel(mxc_fbi->dp);
> + mxc_fbi->enabled = 1;
> +}
> +
> +static void imx_ipu_fb_disable(struct fb_info *fbi)
> +{
> + struct imx_ipu_fb_info *mxc_fbi = fbi->par;
> +
> + if (!mxc_fbi->enabled)
> + return;
> +
> + ipu_dp_disable_channel(mxc_fbi->dp);
> + ipu_dc_disable_channel(mxc_fbi->dc);
> + ipu_idmac_disable_channel(mxc_fbi->ipu_ch);
> + ipu_dmfc_disable_channel(mxc_fbi->dmfc);
> + ipu_di_disable(mxc_fbi->ipu_di);
> +
> + mxc_fbi->enabled = 0;
> +}
> +
> +static int calc_vref(struct fb_var_screeninfo *var)
> +{
> + unsigned long htotal, vtotal;
> +
> + htotal = var->xres + var->right_margin + var->hsync_len + var->left_margin;
> + vtotal = var->yres + var->lower_margin + var->vsync_len + var->upper_margin;
> +
> + if (!htotal || !vtotal)
> + return 60;
> +
> + return PICOS2KHZ(var->pixclock) * 1000 / vtotal / htotal;
> +}
> +
> +static int calc_bandwidth(struct fb_var_screeninfo *var, unsigned int vref)
> +{
> + return var->xres * var->yres * vref;
> +}
> +
> +static int imx_ipu_fb_set_par(struct fb_info *fbi)
> +{
> + int ret;
> + struct ipu_di_signal_cfg sig_cfg;
> + struct imx_ipu_fb_info *mxc_fbi = fbi->par;
> + u32 out_pixel_fmt;
> + int interlaced = 0;
> + struct fb_var_screeninfo *var = &fbi->var;
> + int enabled = mxc_fbi->enabled;
> +
> + dev_dbg(fbi->device, "Reconfiguring framebuffer %dx%d-%d\n",
> + fbi->var.xres, fbi->var.yres, fbi->var.bits_per_pixel);
> +
> + if (enabled)
> + imx_ipu_fb_disable(fbi);
> +
> + fbi->fix.line_length = var->xres_virtual * var->bits_per_pixel / 8;
> +
> + var->yres_virtual = var->yres;
> +
> + ret = imx_ipu_fb_map_video_memory(fbi);
> + if (ret)
> + return ret;
> +
> + if (var->vmode & FB_VMODE_INTERLACED)
> + interlaced = 1;
> +
> + memset(&sig_cfg, 0, sizeof(sig_cfg));
> + out_pixel_fmt = mxc_fbi->ipu_di_pix_fmt;
> +
> + if (var->vmode & FB_VMODE_INTERLACED)
> + sig_cfg.interlaced = 1;
> + if (var->vmode & FB_VMODE_ODD_FLD_FIRST) /* PAL */
> + sig_cfg.odd_field_first = 1;
> + if (var->sync & FB_SYNC_EXT)
> + sig_cfg.ext_clk = 1;
> + if (var->sync & FB_SYNC_HOR_HIGH_ACT)
> + sig_cfg.Hsync_pol = 1;
> + if (var->sync & FB_SYNC_VERT_HIGH_ACT)
> + sig_cfg.Vsync_pol = 1;
> + if (!(var->sync & FB_SYNC_CLK_LAT_FALL))
> + sig_cfg.clk_pol = 1;
> + if (var->sync & FB_SYNC_DATA_INVERT)
> + sig_cfg.data_pol = 1;
> + if (!(var->sync & FB_SYNC_OE_LOW_ACT))
> + sig_cfg.enable_pol = 1;
> + if (var->sync & FB_SYNC_CLK_IDLE_EN)
> + sig_cfg.clkidle_en = 1;
> +
> + dev_dbg(fbi->device, "pixclock = %lu.%03lu MHz\n",
> + PICOS2KHZ(var->pixclock) / 1000,
> + PICOS2KHZ(var->pixclock) % 1000);
> +
> + sig_cfg.width = var->xres;
> + sig_cfg.height = var->yres;
> + sig_cfg.pixel_fmt = out_pixel_fmt;
> + sig_cfg.h_start_width = var->left_margin;
> + sig_cfg.h_sync_width = var->hsync_len;
> + sig_cfg.h_end_width = var->right_margin;
> + sig_cfg.v_start_width = var->upper_margin;
> + sig_cfg.v_sync_width = var->vsync_len;
> + sig_cfg.v_end_width = var->lower_margin;
> + sig_cfg.v_to_h_sync = 0;
> +
> + if (mxc_fbi->dp) {
> + ret = ipu_dp_setup_channel(mxc_fbi->dp, mxc_fbi->ipu_in_pix_fmt,
> + out_pixel_fmt, 1);
> + if (ret) {
> + dev_dbg(fbi->device, "initializing display processor failed with %d\n",
> + ret);
> + return ret;
> + }
> + }
> +
> + ret = ipu_dc_init_sync(mxc_fbi->dc, mxc_fbi->ipu_di, interlaced,
> + out_pixel_fmt, fbi->var.xres);
> + if (ret) {
> + dev_dbg(fbi->device, "initializing display controller failed with %d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = ipu_di_init_sync_panel(mxc_fbi->ipu_di,
> + PICOS2KHZ(var->pixclock) * 1000UL,
> + &sig_cfg);
> + if (ret) {
> + dev_dbg(fbi->device, "initializing panel failed with %d\n",
> + ret);
> + return ret;
> + }
> +
> + fbi->mode = (struct fb_videomode *)fb_match_mode(var, &fbi->modelist);
> + var->xoffset = var->yoffset = 0;
> +
> + if (fbi->var.vmode & FB_VMODE_INTERLACED)
> + interlaced = 1;
> +
> + ret = ipu_idmac_init_channel_buffer(mxc_fbi->ipu_ch,
> + mxc_fbi->ipu_in_pix_fmt,
> + var->xres, var->yres,
> + fbi->fix.line_length,
> + IPU_ROTATE_NONE,
> + fbi->fix.smem_start,
> + 0,
> + 0, 0, interlaced);
> + if (ret) {
> + dev_dbg(fbi->device, "init channel buffer failed with %d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = ipu_dmfc_init_channel(mxc_fbi->dmfc, var->xres);
> + if (ret) {
> + dev_dbg(fbi->device, "initializing dmfc channel failed with %d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = ipu_dmfc_alloc_bandwidth(mxc_fbi->dmfc, calc_bandwidth(var, calc_vref(var)));
> + if (ret) {
> + dev_dbg(fbi->device, "allocating dmfc bandwidth failed with %d\n",
> + ret);
> + return ret;
> + }
> +
> + if (enabled)
> + imx_ipu_fb_enable(fbi);
> +
> + return ret;
> +}
> +
> +/*
> + * These are the bitfields for each
> + * display depth that we support.
> + */
> +struct imxfb_rgb {
> + struct fb_bitfield red;
> + struct fb_bitfield green;
> + struct fb_bitfield blue;
> + struct fb_bitfield transp;
> +};
> +
> +static struct imxfb_rgb def_rgb_8 = {
> + .red = { .offset = 5, .length = 3, },
> + .green = { .offset = 2, .length = 3, },
> + .blue = { .offset = 0, .length = 2, },
> + .transp = { .offset = 0, .length = 0, },
> +};
> +
> +static struct imxfb_rgb def_rgb_16 = {
> + .red = { .offset = 11, .length = 5, },
> + .green = { .offset = 5, .length = 6, },
> + .blue = { .offset = 0, .length = 5, },
> + .transp = { .offset = 0, .length = 0, },
> +};
> +
> +static struct imxfb_rgb def_rgb_24 = {
> + .red = { .offset = 16, .length = 8, },
> + .green = { .offset = 8, .length = 8, },
> + .blue = { .offset = 0, .length = 8, },
> + .transp = { .offset = 0, .length = 0, },
> +};
> +
> +static struct imxfb_rgb def_rgb_32 = {
> + .red = { .offset = 16, .length = 8, },
> + .green = { .offset = 8, .length = 8, },
> + .blue = { .offset = 0, .length = 8, },
> + .transp = { .offset = 24, .length = 8, },
> +};
> +
> +/*
> + * Check framebuffer variable parameters and adjust to valid values.
> + *
> + * @param var framebuffer variable parameters
> + *
> + * @param info framebuffer information pointer
> + */
> +static int imx_ipu_fb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
> +{
> + struct imx_ipu_fb_info *mxc_fbi = info->par;
> + struct imxfb_rgb *rgb;
> +
> + /* we don't support xpan, force xres_virtual to be equal to xres */
> + var->xres_virtual = var->xres;
> +
> + if (var->yres_virtual < var->yres)
> + var->yres_virtual = var->yres;
> +
> + switch (var->bits_per_pixel) {
> + case 8:
> + rgb = &def_rgb_8;
> + break;
> + case 16:
> + rgb = &def_rgb_16;
> + mxc_fbi->ipu_in_pix_fmt = IPU_PIX_FMT_RGB565;
> + break;
> + case 24:
> + rgb = &def_rgb_24;
> + mxc_fbi->ipu_in_pix_fmt = IPU_PIX_FMT_BGR24;
> + break;
> + case 32:
> + rgb = &def_rgb_32;
> + mxc_fbi->ipu_in_pix_fmt = IPU_PIX_FMT_BGR32;
> + break;
> + default:
> + var->bits_per_pixel = 24;
> + rgb = &def_rgb_24;
> + mxc_fbi->ipu_in_pix_fmt = IPU_PIX_FMT_BGR24;
> + }
> +
> + var->red = rgb->red;
> + var->green = rgb->green;
> + var->blue = rgb->blue;
> + var->transp = rgb->transp;
> +
> + return 0;
> +}
> +
> +static inline unsigned int chan_to_field(u_int chan, struct fb_bitfield *bf)
> +{
> + chan &= 0xffff;
> + chan >>= 16 - bf->length;
> + return chan << bf->offset;
> +}
> +
> +static int imx_ipu_fb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
> + u_int trans, struct fb_info *fbi)
> +{
> + unsigned int val;
> + int ret = 1;
> +
> + /*
> + * If greyscale is true, then we convert the RGB value
> + * to greyscale no matter what visual we are using.
> + */
> + if (fbi->var.grayscale)
> + red = green = blue = (19595 * red + 38470 * green +
> + 7471 * blue) >> 16;
> + switch (fbi->fix.visual) {
> + case FB_VISUAL_TRUECOLOR:
> + /*
> + * 16-bit True Colour. We encode the RGB value
> + * according to the RGB bitfield information.
> + */
> + if (regno < 16) {
> + u32 *pal = fbi->pseudo_palette;
> +
> + val = chan_to_field(red, &fbi->var.red);
> + val |= chan_to_field(green, &fbi->var.green);
> + val |= chan_to_field(blue, &fbi->var.blue);
> +
> + pal[regno] = val;
> + ret = 0;
> + }
> + break;
> +
> + case FB_VISUAL_STATIC_PSEUDOCOLOR:
> + case FB_VISUAL_PSEUDOCOLOR:
> + break;
> + }
> +
> + return ret;
> +}
> +
> +static int imx_ipu_fb_blank(int blank, struct fb_info *info)
> +{
> + dev_dbg(info->device, "blank = %d\n", blank);
> +
> + switch (blank) {
> + case FB_BLANK_POWERDOWN:
> + case FB_BLANK_VSYNC_SUSPEND:
> + case FB_BLANK_HSYNC_SUSPEND:
> + case FB_BLANK_NORMAL:
> + imx_ipu_fb_disable(info);
> + break;
> + case FB_BLANK_UNBLANK:
> + imx_ipu_fb_enable(info);
> + break;
> + }
> +
> + return 0;
> +}
> +
> +static int imx_ipu_fb_pan_display(struct fb_var_screeninfo *var,
> + struct fb_info *info)
> +{
> + struct imx_ipu_fb_info *mxc_fbi = info->par;
> + unsigned long base;
> + int ret;
> +
> + if (info->var.yoffset = var->yoffset)
> + return 0; /* No change, do nothing */
> +
> + base = var->yoffset * var->xres_virtual * var->bits_per_pixel / 8;
> + base += info->fix.smem_start;
> +
> + ret = ipu_wait_for_interrupt(IPU_IRQ_EOF(mxc_fbi->ipu_channel_num), 100);
> + if (ret)
> + return ret;
> +
> + if (ipu_idmac_update_channel_buffer(mxc_fbi->ipu_ch, 0, base)) {
> + dev_err(info->device,
> + "Error updating SDC buf to address=0x%08lX\n", base);
> + }
> +
> + info->var.yoffset = var->yoffset;
> +
> + return 0;
> +}
> +
> +static struct fb_ops imx_ipu_fb_ops = {
> + .owner = THIS_MODULE,
> + .fb_set_par = imx_ipu_fb_set_par,
> + .fb_check_var = imx_ipu_fb_check_var,
> + .fb_setcolreg = imx_ipu_fb_setcolreg,
> + .fb_pan_display = imx_ipu_fb_pan_display,
> + .fb_fillrect = cfb_fillrect,
> + .fb_copyarea = cfb_copyarea,
> + .fb_imageblit = cfb_imageblit,
> + .fb_blank = imx_ipu_fb_blank,
> +};
> +
> +/*
> + * Overlay functions
> + */
> +static int imx_ipu_fb_enable_overlay(struct fb_info *fbi)
> +{
> + struct imx_ipu_fb_info *mxc_fbi = fbi->par;
> +
> + ipu_dmfc_enable_channel(mxc_fbi->dmfc);
> + ipu_idmac_enable_channel(mxc_fbi->ipu_ch);
> + ipu_dp_enable_fg(mxc_fbi->dp);
> +
> + return 0;
> +}
> +
> +static int imx_ipu_fb_disable_overlay(struct fb_info *fbi)
> +{
> + struct imx_ipu_fb_info *mxc_fbi = fbi->par;
> +
> + ipu_dp_disable_fg(mxc_fbi->dp);
> + ipu_idmac_disable_channel(mxc_fbi->ipu_ch);
> + ipu_dmfc_disable_channel(mxc_fbi->dmfc);
> +
> + return 0;
> +}
> +
> +static int imx_ipu_fb_set_par_overlay(struct fb_info *fbi)
> +{
> + struct imx_ipu_fb_info *mxc_fbi = fbi->par;
> + struct fb_var_screeninfo *var = &fbi->var;
> + struct fb_info *fbi_master = mxc_fbi->master;
> + struct fb_var_screeninfo *var_master = &fbi_master->var;
> + int ret;
> + int interlaced = 0;
> + int enabled = mxc_fbi->enabled;
> +
> + dev_dbg(fbi->device, "Reconfiguring framebuffer %dx%d-%d\n",
> + fbi->var.xres, fbi->var.yres, fbi->var.bits_per_pixel);
> +
> + if (enabled)
> + imx_ipu_fb_disable_overlay(fbi);
> +
> + fbi->fix.line_length = var->xres_virtual *
> + var->bits_per_pixel / 8;
> +
> + ret = imx_ipu_fb_map_video_memory(fbi);
> + if (ret)
> + return ret;
> +
> + ipu_dp_set_window_pos(mxc_fbi->dp, 64, 64);
> +
> + var->xoffset = var->yoffset = 0;
> +
> + if (var->vmode & FB_VMODE_INTERLACED)
> + interlaced = 1;
> +
> + ret = ipu_idmac_init_channel_buffer(mxc_fbi->ipu_ch,
> + mxc_fbi->ipu_in_pix_fmt,
> + var->xres, var->yres,
> + fbi->fix.line_length,
> + IPU_ROTATE_NONE,
> + fbi->fix.smem_start,
> + 0,
> + 0, 0, interlaced);
> + if (ret) {
> + dev_dbg(fbi->device, "init channel buffer failed with %d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = ipu_dmfc_init_channel(mxc_fbi->dmfc, var->xres);
> + if (ret) {
> + dev_dbg(fbi->device, "initializing dmfc channel failed with %d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = ipu_dmfc_alloc_bandwidth(mxc_fbi->dmfc, calc_bandwidth(var, calc_vref(var_master)));
> + if (ret) {
> + dev_dbg(fbi->device, "allocating dmfc bandwidth failed with %d\n",
> + ret);
> + return ret;
> + }
> +
> + if (enabled)
> + imx_ipu_fb_enable_overlay(fbi);
> +
> + return ret;
> +}
> +
> +static int imx_ipu_fb_blank_overlay(int blank, struct fb_info *fbi)
> +{
> + dev_dbg(fbi->device, "blank = %d\n", blank);
> +
> + switch (blank) {
> + case FB_BLANK_POWERDOWN:
> + case FB_BLANK_VSYNC_SUSPEND:
> + case FB_BLANK_HSYNC_SUSPEND:
> + case FB_BLANK_NORMAL:
> + imx_ipu_fb_disable_overlay(fbi);
> + break;
> + case FB_BLANK_UNBLANK:
> + imx_ipu_fb_enable_overlay(fbi);
> + break;
> + }
> +
> + return 0;
> +}
> +
> +static struct fb_ops imx_ipu_fb_overlay_ops = {
> + .owner = THIS_MODULE,
> + .fb_set_par = imx_ipu_fb_set_par_overlay,
> + .fb_check_var = imx_ipu_fb_check_var,
> + .fb_setcolreg = imx_ipu_fb_setcolreg,
> + .fb_pan_display = imx_ipu_fb_pan_display,
> + .fb_fillrect = cfb_fillrect,
> + .fb_copyarea = cfb_copyarea,
> + .fb_imageblit = cfb_imageblit,
> + .fb_blank = imx_ipu_fb_blank_overlay,
> +};
> +
> +static struct fb_info *imx_ipu_fb_init_fbinfo(struct device *dev, struct fb_ops *ops)
> +{
> + struct fb_info *fbi;
> + struct imx_ipu_fb_info *mxc_fbi;
> +
> + fbi = framebuffer_alloc(sizeof(struct imx_ipu_fb_info), dev);
> + if (!fbi)
> + return NULL;
> +
> + BUG_ON(fbi->par = NULL);
> + mxc_fbi = fbi->par;
> +
> + fbi->var.activate = FB_ACTIVATE_NOW;
> +
> + fbi->fbops = ops;
> + fbi->flags = FBINFO_FLAG_DEFAULT;
> + fbi->pseudo_palette = mxc_fbi->pseudo_palette;
> +
> + fb_alloc_cmap(&fbi->cmap, 16, 0);
> +
> + return fbi;
> +}
> +
> +static int imx_ipu_fb_init_overlay(struct platform_device *pdev,
> + struct fb_info *fbi_master, int ipu_channel)
> +{
> + struct imx_ipu_fb_info *mxc_fbi_master = fbi_master->par;
> + struct fb_info *ovlfbi;
> + struct imx_ipu_fb_info *ovl_mxc_fbi;
> + int ret;
> +
> + ovlfbi = imx_ipu_fb_init_fbinfo(&pdev->dev, &imx_ipu_fb_overlay_ops);
> + if (!ovlfbi)
> + return -ENOMEM;
> +
> + ovl_mxc_fbi = ovlfbi->par;
> + ovl_mxc_fbi->ipu_ch = ipu_idmac_get(ipu_channel);
> + ovl_mxc_fbi->dmfc = ipu_dmfc_get(ipu_channel);
> + ovl_mxc_fbi->ipu_di = -1;
> + ovl_mxc_fbi->dp = mxc_fbi_master->dp;
> + ovl_mxc_fbi->master = fbi_master;
> + mxc_fbi_master->slave = ovlfbi;
> +
> + ovlfbi->var.xres = 240;
> + ovlfbi->var.yres = 320;
> + ovlfbi->var.yres_virtual = ovlfbi->var.yres;
> + ovlfbi->var.xres_virtual = ovlfbi->var.xres;
> + imx_ipu_fb_check_var(&ovlfbi->var, ovlfbi);
> + imx_ipu_fb_set_fix(ovlfbi);
> +
> + ret = register_framebuffer(ovlfbi);
> + if (ret) {
> + framebuffer_release(ovlfbi);
> + return ret;
> + }
> +
> + ipu_dp_set_global_alpha(ovl_mxc_fbi->dp, 1, 0x80, 1);
> + ipu_dp_set_color_key(ovl_mxc_fbi->dp, 0, 0);
> +
> + imx_ipu_fb_set_par_overlay(ovlfbi);
> +
> + return 0;
> +}
> +
> +static void imx_ipu_fb_exit_overlay(struct platform_device *pdev,
> + struct fb_info *fbi_master, int ipu_channel)
> +{
> + struct imx_ipu_fb_info *mxc_fbi_master = fbi_master->par;
> + struct fb_info *ovlfbi = mxc_fbi_master->slave;
> + struct imx_ipu_fb_info *ovl_mxc_fbi = ovlfbi->par;
> +
> + imx_ipu_fb_blank_overlay(FB_BLANK_POWERDOWN, ovlfbi);
> +
> + unregister_framebuffer(ovlfbi);
> +
> + ipu_idmac_put(ovl_mxc_fbi->ipu_ch);
> + ipu_dmfc_free_bandwidth(ovl_mxc_fbi->dmfc);
> + ipu_dmfc_put(ovl_mxc_fbi->dmfc);
> +
> + framebuffer_release(ovlfbi);
> +}
> +
> +static int imx_ipu_fb_find_mode(struct fb_info *fbi)
> +{
> + int ret;
> + struct fb_videomode *mode_array;
> + struct fb_modelist *modelist;
> + struct fb_var_screeninfo *var = &fbi->var;
> + int i = 0;
> +
> + list_for_each_entry(modelist, &fbi->modelist, list)
> + i++;
> +
> + mode_array = kmalloc(sizeof (struct fb_modelist) * i, GFP_KERNEL);
> + if (!mode_array)
> + return -ENOMEM;
> +
> + i = 0;
> + list_for_each_entry(modelist, &fbi->modelist, list)
> + mode_array[i++] = modelist->mode;
> +
> + ret = fb_find_mode(&fbi->var, fbi, NULL, mode_array, i, NULL, 16);
> + if (ret = 0)
> + return -EINVAL;
> +
> + dev_dbg(fbi->device, "found %dx%d-%d hs:%d:%d:%d vs:%d:%d:%d\n",
> + var->xres, var->yres, var->bits_per_pixel,
> + var->hsync_len, var->left_margin, var->right_margin,
> + var->vsync_len, var->upper_margin, var->lower_margin);
> +
> + kfree(mode_array);
> +
> + return 0;
> +}
> +
> +static int __devinit imx_ipu_fb_probe(struct platform_device *pdev)
> +{
> + struct fb_info *fbi;
> + struct imx_ipu_fb_info *mxc_fbi;
> + struct ipuv3_fb_platform_data *plat_data = pdev->dev.platform_data;
> + int ret = 0, i;
> +
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> +
> + fbi = imx_ipu_fb_init_fbinfo(&pdev->dev, &imx_ipu_fb_ops);
> + if (!fbi)
> + return -ENOMEM;
> +
> + mxc_fbi = fbi->par;
> +
> + mxc_fbi->ipu_channel_num = plat_data->ipu_channel_bg;
> + mxc_fbi->dc = plat_data->dc_channel;
> + mxc_fbi->ipu_di_pix_fmt = plat_data->interface_pix_fmt;
> + mxc_fbi->ipu_di = pdev->id;
> +
> + mxc_fbi->ipu_ch = ipu_idmac_get(plat_data->ipu_channel_bg);
> + if (IS_ERR(mxc_fbi->ipu_ch)) {
> + ret = PTR_ERR(mxc_fbi->ipu_ch);
> + goto failed_request_ipu;
> + }
> +
> + mxc_fbi->dmfc = ipu_dmfc_get(plat_data->ipu_channel_bg);
> + if (IS_ERR(mxc_fbi->ipu_ch)) {
> + ret = PTR_ERR(mxc_fbi->ipu_ch);
> + goto failed_request_dmfc;
> + }
> +
> + if (plat_data->dp_channel >= 0) {
> + mxc_fbi->dp = ipu_dp_get(plat_data->dp_channel);
> + if (IS_ERR(mxc_fbi->dp)) {
> + ret = PTR_ERR(mxc_fbi->ipu_ch);
> + goto failed_request_dp;
> + }
> + }
> +
> + fbi->var.yres_virtual = fbi->var.yres;
> +
> + INIT_LIST_HEAD(&fbi->modelist);
> + for (i = 0; i < plat_data->num_modes; i++)
> + fb_add_videomode(&plat_data->modes[i], &fbi->modelist);
> +
> + if (plat_data->flags & IMX_IPU_FB_USE_MODEDB) {
> + for (i = 0; i < num_fb_modes; i++)
> + fb_add_videomode(&fb_modes[i], &fbi->modelist);
> + }
> +
> + imx_ipu_fb_find_mode(fbi);
> +
> + imx_ipu_fb_check_var(&fbi->var, fbi);
> + imx_ipu_fb_set_fix(fbi);
> + ret = register_framebuffer(fbi);
> + if (ret < 0)
> + goto failed_register;
> +
> + imx_ipu_fb_set_par(fbi);
> + imx_ipu_fb_blank(FB_BLANK_UNBLANK, fbi);
> +
> + if (plat_data->ipu_channel_fg >= 0 && plat_data->flags & IMX_IPU_FB_USE_OVERLAY)
> + imx_ipu_fb_init_overlay(pdev, fbi, plat_data->ipu_channel_fg);
> +
> + platform_set_drvdata(pdev, fbi);
> +
> + return 0;
> +
> +failed_register:
> + if (plat_data->dp_channel >= 0)
> + ipu_dp_put(mxc_fbi->dp);
> +failed_request_dp:
> + ipu_dmfc_put(mxc_fbi->dmfc);
> +failed_request_dmfc:
> + ipu_idmac_put(mxc_fbi->ipu_ch);
> +failed_request_ipu:
> + fb_dealloc_cmap(&fbi->cmap);
> + framebuffer_release(fbi);
> +
> + return ret;
> +}
> +
> +static int __devexit imx_ipu_fb_remove(struct platform_device *pdev)
> +{
> + struct fb_info *fbi = platform_get_drvdata(pdev);
> + struct imx_ipu_fb_info *mxc_fbi = fbi->par;
> + struct ipuv3_fb_platform_data *plat_data = pdev->dev.platform_data;
> +
> + if (plat_data->ipu_channel_fg >= 0 && plat_data->flags & IMX_IPU_FB_USE_OVERLAY)
> + imx_ipu_fb_exit_overlay(pdev, fbi, plat_data->ipu_channel_fg);
> +
> + imx_ipu_fb_blank(FB_BLANK_POWERDOWN, fbi);
> +
> + dma_free_writecombine(fbi->device, fbi->fix.smem_len,
> + fbi->screen_base, fbi->fix.smem_start);
> +
> + if (&fbi->cmap)
> + fb_dealloc_cmap(&fbi->cmap);
> +
> + unregister_framebuffer(fbi);
> +
> + if (plat_data->dp_channel >= 0)
> + ipu_dp_put(mxc_fbi->dp);
> + ipu_dmfc_free_bandwidth(mxc_fbi->dmfc);
> + ipu_dmfc_put(mxc_fbi->dmfc);
> + ipu_idmac_put(mxc_fbi->ipu_ch);
> +
> + framebuffer_release(fbi);
> +
> + return 0;
> +}
> +
> +static struct platform_driver imx_ipu_fb_driver = {
> + .driver = {
> + .name = DRIVER_NAME,
> + },
> + .probe = imx_ipu_fb_probe,
> + .remove = __devexit_p(imx_ipu_fb_remove),
> +};
> +
> +static int __init imx_ipu_fb_init(void)
> +{
> + return platform_driver_register(&imx_ipu_fb_driver);
> +}
> +
> +static void __exit imx_ipu_fb_exit(void)
> +{
> + platform_driver_unregister(&imx_ipu_fb_driver);
> +}
> +
> +module_init(imx_ipu_fb_init);
> +module_exit(imx_ipu_fb_exit);
> +
> +MODULE_AUTHOR("Freescale Semiconductor, Inc.");
> +MODULE_DESCRIPTION("i.MX framebuffer driver");
> +MODULE_LICENSE("GPL");
> +MODULE_SUPPORTED_DEVICE("fb");
> --
> 1.7.2.3
>
> --
> 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 [flat|nested] 34+ messages in thread* Re: [PATCH 5/9] Add i.MX5 framebuffer driver
2010-12-12 6:13 ` Liu Ying
@ 2010-12-13 7:23 ` Lothar Waßmann
2010-12-13 11:35 ` Liu Ying
2010-12-13 11:38 ` Sascha Hauer
1 sibling, 1 reply; 34+ messages in thread
From: Lothar Waßmann @ 2010-12-13 7:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Liu Ying writes:
> 6) I prefer to find the video mode in modedb first, and if we cannot
> find the video mode in common video mode data base, we can find a
> video mode in custom video mode data base which is defined in platform
> data. In this way, we don't need to export common modefb.
>
IMO platform specific video modes should take precedence over generic
ones, so the platform data should be evaluated first.
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 5/9] Add i.MX5 framebuffer driver
2010-12-13 7:23 ` Lothar Waßmann
@ 2010-12-13 11:35 ` Liu Ying
0 siblings, 0 replies; 34+ messages in thread
From: Liu Ying @ 2010-12-13 11:35 UTC (permalink / raw)
To: linux-arm-kernel
Hello, Lothar Waßmann,
I think your opinion is reasonable and better.
So, first, we can find the video mode in the video mode data base
defined in platform data, and then, if this fails, we can find it in
common video mode data base.
Best Regards,
Liu Ying
2010/12/13 Lothar Waßmann <LW@karo-electronics.de>:
> Hi,
>
> Liu Ying writes:
>> 6) I prefer to find the video mode in modedb first, and if we cannot
>> find the video mode in common video mode data base, we can find a
>> video mode in custom video mode data base which is defined in platform
>> data. In this way, we don't need to export common modefb.
>>
> IMO platform specific video modes should take precedence over generic
> ones, so the platform data should be evaluated first.
>
>
> Lothar Waßmann
> --
> ___________________________________________________________
>
> Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
> Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
> Geschäftsführer: Matthias Kaussen
> Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
>
> www.karo-electronics.de | info@karo-electronics.de
> ___________________________________________________________
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 5/9] Add i.MX5 framebuffer driver
2010-12-12 6:13 ` Liu Ying
2010-12-13 7:23 ` Lothar Waßmann
@ 2010-12-13 11:38 ` Sascha Hauer
2010-12-14 6:40 ` Liu Ying
1 sibling, 1 reply; 34+ messages in thread
From: Sascha Hauer @ 2010-12-13 11:38 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, Dec 12, 2010 at 02:13:40PM +0800, Liu Ying wrote:
> Hello, Sascha,
>
> I have following comments to this patch:
> 1) Please modify the commit message, as IPUv3 is not embedded in i.MX50 SoC.
ok.
> 2) ADC is not supported yet in the framebuffer driver, so please
> modify this comment:
> > + * Framebuffer Framebuffer Driver for SDC and ADC.
ok.
> 3) 'ipu_dp_set_window_pos()' is called only once in
> imx_ipu_fb_set_par_overlay(). So, the framebuffer driver doesn't
> support to change the overlay framebuffer position. Need a
> mechanism/interface for users to change the overlay framebuffer
> position.
Yes. The overlay support is currently only present in the driver because
I didn't want to break it in general. There is no generic overlay API in
the kernel and I didn't want to invent the n+1 API. Currently the
possible use cases of the overlay support are not clear to me. Number
one use case would probably be to display video output, but the
corresponding driver would be a v4l2 driver, so in this case we would
only need an in-kernel API.
Anyway, I have not the resources to implement complete overlay support.
So either we keep it like it is and it more has an example character
or we remove it completely from the driver for now.
> 4) Need to make sure the framebuffer on DP-FG is blanked before the
> framebuffer on DP-BG is blanked. Meanwhile, the framebuffer on DP-FG
> should be unblanked after the framebuffer on DP-BG is unblanked
> 5) Need to check the framebuffer on DP-FG doesn't run out of the range
> of the framebuffer on DP-BG.
I tend to remove the overlay support.
> 6) I prefer to find the video mode in modedb first, and if we cannot
> find the video mode in common video mode data base, we can find a
> video mode in custom video mode data base which is defined in platform
> data. In this way, we don't need to export common modefb.
I exported the modedb to be able to show the different modes under
/sys/class/graphics/fb0/modes and to set it with
/sys/class/graphics/fb0/mode. If you want this there is no way around
exporting it. The ioctl interface for mode setting is independent of the
specific modes anyway.
BTW please make comments specific to specific code inline.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 5/9] Add i.MX5 framebuffer driver
2010-12-13 11:38 ` Sascha Hauer
@ 2010-12-14 6:40 ` Liu Ying
2010-12-14 8:45 ` Sascha Hauer
0 siblings, 1 reply; 34+ messages in thread
From: Liu Ying @ 2010-12-14 6:40 UTC (permalink / raw)
To: linux-arm-kernel
Hello, Sascha,
Please find my feedback with [LY] embedded.
And, a bug related with this patch:
1) Bootup the babbage board.
2) echo U:640x480p-60 > /sys/class/graphics/fb0/mode
3) cat /sys/class/graphics/fb0/virtual_size, it shows '640,480'.
4) echo 640,960 > /sys/class/graphics/fb0/virtual_size, change virtual
yres to be 960.
5) cat /sys/class/graphics/fb0/virtual_size, it still shows '640,480'.
I think this is caused by 'var->yres_virtual = var->yres;' in custom
fb_set_par() function(Sorry, I cannot make the comment inline this
time, as I don't find the original code within the mail I am
replying). This makes fb0 use only one block of memory whose size is
equal to screen size, so pan display can not really play her role and
screen tearing issue may happen.
Best Regards,
Liu Ying
2010/12/13 Sascha Hauer <s.hauer@pengutronix.de>:
> On Sun, Dec 12, 2010 at 02:13:40PM +0800, Liu Ying wrote:
>> Hello, Sascha,
>>
>> I have following comments to this patch:
>> 1) Please modify the commit message, as IPUv3 is not embedded in i.MX50 SoC.
>
> ok.
>
>> 2) ADC is not supported yet in the framebuffer driver, so please
>> modify this comment:
>> > + * Framebuffer Framebuffer Driver for SDC and ADC.
>
> ok.
>
>> 3) 'ipu_dp_set_window_pos()' is called only once in
>> imx_ipu_fb_set_par_overlay(). So, the framebuffer driver doesn't
>> support to change the overlay framebuffer position. Need a
>> mechanism/interface for users to change the overlay framebuffer
>> position.
>
> Yes. The overlay support is currently only present in the driver because
> I didn't want to break it in general. There is no generic overlay API in
> the kernel and I didn't want to invent the n+1 API. Currently the
> possible use cases of the overlay support are not clear to me. Number
> one use case would probably be to display video output, but the
> corresponding driver would be a v4l2 driver, so in this case we would
> only need an in-kernel API.
> Anyway, I have not the resources to implement complete overlay support.
> So either we keep it like it is and it more has an example character
> or we remove it completely from the driver for now.
>
>> 4) Need to make sure the framebuffer on DP-FG is blanked before the
>> framebuffer on DP-BG is blanked. Meanwhile, the framebuffer on DP-FG
>> should be unblanked after the framebuffer on DP-BG is unblanked
>> 5) Need to check the framebuffer on DP-FG doesn't run out of the range
>> of the framebuffer on DP-BG.
>
> I tend to remove the overlay support.
>
>> 6) I prefer to find the video mode in modedb first, and if we cannot
>> find the video mode in common video mode data base, we can find a
>> video mode in custom video mode data base which is defined in platform
>> data. In this way, we don't need to export common modefb.
>
> I exported the modedb to be able to show the different modes under
> /sys/class/graphics/fb0/modes and to set it with
> /sys/class/graphics/fb0/mode. If you want this there is no way around
> exporting it. The ioctl interface for mode setting is independent of the
> specific modes anyway.
[LY] Just a concern. If a platform choose to add the generic video
mode data base to IPUv3 framebuffer modelist, 'cat
/sys/class/graphics/fb0/modes' will show all the video modes in the
generic data base to users. I am not sure whether showing them to
users means the IPUv3 framebuffer driver acknowledges to support all
of them or not. I tried to do 'echo U:1800x1440p-70 >
/sys/class/graphics/fb0/mode' with the kernel on ipuv3 branch, there
will be a kernel dump(seems it can not allocate enough memory).
>
> BTW please make comments specific to specific code inline.
[LY] Ok.
>
> Sascha
>
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 5/9] Add i.MX5 framebuffer driver
2010-12-14 6:40 ` Liu Ying
@ 2010-12-14 8:45 ` Sascha Hauer
2010-12-14 13:23 ` Liu Ying
0 siblings, 1 reply; 34+ messages in thread
From: Sascha Hauer @ 2010-12-14 8:45 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Dec 14, 2010 at 02:40:09PM +0800, Liu Ying wrote:
> Hello, Sascha,
>
> Please find my feedback with [LY] embedded.
>
> And, a bug related with this patch:
> 1) Bootup the babbage board.
> 2) echo U:640x480p-60 > /sys/class/graphics/fb0/mode
> 3) cat /sys/class/graphics/fb0/virtual_size, it shows '640,480'.
> 4) echo 640,960 > /sys/class/graphics/fb0/virtual_size, change virtual
> yres to be 960.
> 5) cat /sys/class/graphics/fb0/virtual_size, it still shows '640,480'.
> I think this is caused by 'var->yres_virtual = var->yres;' in custom
> fb_set_par() function(Sorry, I cannot make the comment inline this
> time, as I don't find the original code within the mail I am
> replying). This makes fb0 use only one block of memory whose size is
> equal to screen size, so pan display can not really play her role and
> screen tearing issue may happen.
>
> Best Regards,
> Liu Ying
>
> 2010/12/13 Sascha Hauer <s.hauer@pengutronix.de>:
> > On Sun, Dec 12, 2010 at 02:13:40PM +0800, Liu Ying wrote:
> >> Hello, Sascha,
> >>
> >> I have following comments to this patch:
> >> 1) Please modify the commit message, as IPUv3 is not embedded in i.MX50 SoC.
> >
> > ok.
> >
> >> 2) ADC is not supported yet in the framebuffer driver, so please
> >> modify this comment:
> >> > + * Framebuffer Framebuffer Driver for SDC and ADC.
> >
> > ok.
> >
> >> 3) 'ipu_dp_set_window_pos()' is called only once in
> >> imx_ipu_fb_set_par_overlay(). So, the framebuffer driver doesn't
> >> support to change the overlay framebuffer position. Need a
> >> mechanism/interface for users to change the overlay framebuffer
> >> position.
> >
> > Yes. The overlay support is currently only present in the driver because
> > I didn't want to break it in general. There is no generic overlay API in
> > the kernel and I didn't want to invent the n+1 API. Currently the
> > possible use cases of the overlay support are not clear to me. Number
> > one use case would probably be to display video output, but the
> > corresponding driver would be a v4l2 driver, so in this case we would
> > only need an in-kernel API.
> > Anyway, I have not the resources to implement complete overlay support.
> > So either we keep it like it is and it more has an example character
> > or we remove it completely from the driver for now.
> >
> >> 4) Need to make sure the framebuffer on DP-FG is blanked before the
> >> framebuffer on DP-BG is blanked. Meanwhile, the framebuffer on DP-FG
> >> should be unblanked after the framebuffer on DP-BG is unblanked
> >> 5) Need to check the framebuffer on DP-FG doesn't run out of the range
> >> of the framebuffer on DP-BG.
> >
> > I tend to remove the overlay support.
> >
> >> 6) I prefer to find the video mode in modedb first, and if we cannot
> >> find the video mode in common video mode data base, we can find a
> >> video mode in custom video mode data base which is defined in platform
> >> data. In this way, we don't need to export common modefb.
> >
> > I exported the modedb to be able to show the different modes under
> > /sys/class/graphics/fb0/modes and to set it with
> > /sys/class/graphics/fb0/mode. If you want this there is no way around
> > exporting it. The ioctl interface for mode setting is independent of the
> > specific modes anyway.
> [LY] Just a concern. If a platform choose to add the generic video
> mode data base to IPUv3 framebuffer modelist, 'cat
> /sys/class/graphics/fb0/modes' will show all the video modes in the
> generic data base to users. I am not sure whether showing them to
> users means the IPUv3 framebuffer driver acknowledges to support all
> of them or not. I tried to do 'echo U:1800x1440p-70 >
> /sys/class/graphics/fb0/mode' with the kernel on ipuv3 branch, there
> will be a kernel dump(seems it can not allocate enough memory).
We'll have to increase the dma coherent size (and max zone order) for
these resolutions to work. I have patches for this in my local tree but
decided to wait until some contiguous memory allocator hits the tree.
Also, the fb driver should sanity check the generic modes before adding
them to the list. FOr example the IPU can't do 1920x1200@60. This code
is missing currently.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 5/9] Add i.MX5 framebuffer driver
2010-12-14 8:45 ` Sascha Hauer
@ 2010-12-14 13:23 ` Liu Ying
2010-12-15 11:17 ` Sascha Hauer
0 siblings, 1 reply; 34+ messages in thread
From: Liu Ying @ 2010-12-14 13:23 UTC (permalink / raw)
To: linux-arm-kernel
2010/12/14 Sascha Hauer <s.hauer@pengutronix.de>:
> On Tue, Dec 14, 2010 at 02:40:09PM +0800, Liu Ying wrote:
>> Hello, Sascha,
>>
>> Please find my feedback with [LY] embedded.
>>
>> And, a bug related with this patch:
>> 1) Bootup the babbage board.
>> 2) echo U:640x480p-60 > /sys/class/graphics/fb0/mode
>> 3) cat /sys/class/graphics/fb0/virtual_size, it shows '640,480'.
>> 4) echo 640,960 > /sys/class/graphics/fb0/virtual_size, change virtual
>> yres to be 960.
>> 5) cat /sys/class/graphics/fb0/virtual_size, it still shows '640,480'.
>> I think this is caused by 'var->yres_virtual = var->yres;' in custom
>> fb_set_par() function(Sorry, I cannot make the comment inline this
>> time, as I don't find the original code within the mail I am
>> replying). This makes fb0 use only one block of memory whose size is
>> equal to screen size, so pan display can not really play her role and
>> screen tearing issue may happen.
Sascha,
Just would like to know if you've caught this bug.
>>
>> Best Regards,
>> Liu Ying
>>
>> 2010/12/13 Sascha Hauer <s.hauer@pengutronix.de>:
>> > On Sun, Dec 12, 2010 at 02:13:40PM +0800, Liu Ying wrote:
>> >> Hello, Sascha,
>> >>
>> >> I have following comments to this patch:
>> >> 1) Please modify the commit message, as IPUv3 is not embedded in i.MX50 SoC.
>> >
>> > ok.
>> >
>> >> 2) ADC is not supported yet in the framebuffer driver, so please
>> >> modify this comment:
>> >> > + * Framebuffer Framebuffer Driver for SDC and ADC.
>> >
>> > ok.
>> >
>> >> 3) 'ipu_dp_set_window_pos()' is called only once in
>> >> imx_ipu_fb_set_par_overlay(). So, the framebuffer driver doesn't
>> >> support to change the overlay framebuffer position. Need a
>> >> mechanism/interface for users to change the overlay framebuffer
>> >> position.
>> >
>> > Yes. The overlay support is currently only present in the driver because
>> > I didn't want to break it in general. There is no generic overlay API in
>> > the kernel and I didn't want to invent the n+1 API. Currently the
>> > possible use cases of the overlay support are not clear to me. Number
>> > one use case would probably be to display video output, but the
>> > corresponding driver would be a v4l2 driver, so in this case we would
>> > only need an in-kernel API.
>> > Anyway, I have not the resources to implement complete overlay support.
>> > So either we keep it like it is and it more has an example character
>> > or we remove it completely from the driver for now.
>> >
>> >> 4) Need to make sure the framebuffer on DP-FG is blanked before the
>> >> framebuffer on DP-BG is blanked. Meanwhile, the framebuffer on DP-FG
>> >> should be unblanked after the framebuffer on DP-BG is unblanked
>> >> 5) Need to check the framebuffer on DP-FG doesn't run out of the range
>> >> of the framebuffer on DP-BG.
>> >
>> > I tend to remove the overlay support.
>> >
>> >> 6) I prefer to find the video mode in modedb first, and if we cannot
>> >> find the video mode in common video mode data base, we can find a
>> >> video mode in custom video mode data base which is defined in platform
>> >> data. In this way, we don't need to export common modefb.
>> >
>> > I exported the modedb to be able to show the different modes under
>> > /sys/class/graphics/fb0/modes and to set it with
>> > /sys/class/graphics/fb0/mode. If you want this there is no way around
>> > exporting it. The ioctl interface for mode setting is independent of the
>> > specific modes anyway.
>> [LY] Just a concern. If a platform choose to add the generic video
>> mode data base to IPUv3 framebuffer modelist, 'cat
>> /sys/class/graphics/fb0/modes' will show all the video modes in the
>> generic data base to users. I am not sure whether showing them to
>> users means the IPUv3 framebuffer driver acknowledges to support all
>> of them or not. I tried to do 'echo U:1800x1440p-70 >
>> /sys/class/graphics/fb0/mode' with the kernel on ipuv3 branch, there
>> will be a kernel dump(seems it can not allocate enough memory).
>
> We'll have to increase the dma coherent size (and max zone order) for
> these resolutions to work. I have patches for this in my local tree but
> decided to wait until some contiguous memory allocator hits the tree.
> Also, the fb driver should sanity check the generic modes before adding
> them to the list. FOr example the IPU can't do 1920x1200@60. This code
> is missing currently.
>
> Sascha
>
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
--
Best Regards,
Liu Ying
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 5/9] Add i.MX5 framebuffer driver
2010-12-14 13:23 ` Liu Ying
@ 2010-12-15 11:17 ` Sascha Hauer
0 siblings, 0 replies; 34+ messages in thread
From: Sascha Hauer @ 2010-12-15 11:17 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Dec 14, 2010 at 09:23:30PM +0800, Liu Ying wrote:
> 2010/12/14 Sascha Hauer <s.hauer@pengutronix.de>:
> > On Tue, Dec 14, 2010 at 02:40:09PM +0800, Liu Ying wrote:
> >> Hello, Sascha,
> >>
> >> Please find my feedback with [LY] embedded.
> >>
> >> And, a bug related with this patch:
> >> 1) Bootup the babbage board.
> >> 2) echo U:640x480p-60 > /sys/class/graphics/fb0/mode
> >> 3) cat /sys/class/graphics/fb0/virtual_size, it shows '640,480'.
> >> 4) echo 640,960 > /sys/class/graphics/fb0/virtual_size, change virtual
> >> yres to be 960.
> >> 5) cat /sys/class/graphics/fb0/virtual_size, it still shows '640,480'.
> >> I think this is caused by 'var->yres_virtual = var->yres;' in custom
> >> fb_set_par() function(Sorry, I cannot make the comment inline this
> >> time, as I don't find the original code within the mail I am
> >> replying). This makes fb0 use only one block of memory whose size is
> >> equal to screen size, so pan display can not really play her role and
> >> screen tearing issue may happen.
>
> Sascha,
>
> Just would like to know if you've caught this bug.
Yes, it will be fixed in the next series. It was the framebuffer driver
forcing yres_virtual to yres in set_par.
Sascha
>
> >>
> >> Best Regards,
> >> Liu Ying
> >>
> >> 2010/12/13 Sascha Hauer <s.hauer@pengutronix.de>:
> >> > On Sun, Dec 12, 2010 at 02:13:40PM +0800, Liu Ying wrote:
> >> >> Hello, Sascha,
> >> >>
> >> >> I have following comments to this patch:
> >> >> 1) Please modify the commit message, as IPUv3 is not embedded in i.MX50 SoC.
> >> >
> >> > ok.
> >> >
> >> >> 2) ADC is not supported yet in the framebuffer driver, so please
> >> >> modify this comment:
> >> >> > + * Framebuffer Framebuffer Driver for SDC and ADC.
> >> >
> >> > ok.
> >> >
> >> >> 3) 'ipu_dp_set_window_pos()' is called only once in
> >> >> imx_ipu_fb_set_par_overlay(). So, the framebuffer driver doesn't
> >> >> support to change the overlay framebuffer position. Need a
> >> >> mechanism/interface for users to change the overlay framebuffer
> >> >> position.
> >> >
> >> > Yes. The overlay support is currently only present in the driver because
> >> > I didn't want to break it in general. There is no generic overlay API in
> >> > the kernel and I didn't want to invent the n+1 API. Currently the
> >> > possible use cases of the overlay support are not clear to me. Number
> >> > one use case would probably be to display video output, but the
> >> > corresponding driver would be a v4l2 driver, so in this case we would
> >> > only need an in-kernel API.
> >> > Anyway, I have not the resources to implement complete overlay support.
> >> > So either we keep it like it is and it more has an example character
> >> > or we remove it completely from the driver for now.
> >> >
> >> >> 4) Need to make sure the framebuffer on DP-FG is blanked before the
> >> >> framebuffer on DP-BG is blanked. Meanwhile, the framebuffer on DP-FG
> >> >> should be unblanked after the framebuffer on DP-BG is unblanked
> >> >> 5) Need to check the framebuffer on DP-FG doesn't run out of the range
> >> >> of the framebuffer on DP-BG.
> >> >
> >> > I tend to remove the overlay support.
> >> >
> >> >> 6) I prefer to find the video mode in modedb first, and if we cannot
> >> >> find the video mode in common video mode data base, we can find a
> >> >> video mode in custom video mode data base which is defined in platform
> >> >> data. In this way, we don't need to export common modefb.
> >> >
> >> > I exported the modedb to be able to show the different modes under
> >> > /sys/class/graphics/fb0/modes and to set it with
> >> > /sys/class/graphics/fb0/mode. If you want this there is no way around
> >> > exporting it. The ioctl interface for mode setting is independent of the
> >> > specific modes anyway.
> >> [LY] Just a concern. If a platform choose to add the generic video
> >> mode data base to IPUv3 framebuffer modelist, 'cat
> >> /sys/class/graphics/fb0/modes' will show all the video modes in the
> >> generic data base to users. I am not sure whether showing them to
> >> users means the IPUv3 framebuffer driver acknowledges to support all
> >> of them or not. I tried to do 'echo U:1800x1440p-70 >
> >> /sys/class/graphics/fb0/mode' with the kernel on ipuv3 branch, there
> >> will be a kernel dump(seems it can not allocate enough memory).
> >
> > We'll have to increase the dma coherent size (and max zone order) for
> > these resolutions to work. I have patches for this in my local tree but
> > decided to wait until some contiguous memory allocator hits the tree.
> > Also, the fb driver should sanity check the generic modes before adding
> > them to the list. FOr example the IPU can't do 1920x1200@60. This code
> > is missing currently.
> >
> > Sascha
> >
> >
> > --
> > Pengutronix e.K. | |
> > Industrial Linux Solutions | http://www.pengutronix.de/ |
> > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> >
>
>
>
> --
> Best Regards,
> Liu Ying
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 6/9] ARM i.MX51: Add IPU device support
2010-12-09 13:47 [PATCH RFC] i.MX51 Framebuffer support Sascha Hauer
` (3 preceding siblings ...)
2010-12-09 13:47 ` [PATCH 5/9] Add i.MX5 framebuffer driver Sascha Hauer
@ 2010-12-09 13:47 ` Sascha Hauer
2010-12-15 15:49 ` Arnd Bergmann
2010-12-09 13:47 ` [PATCH 7/9] ARM i.MX5: Allow to increase max zone order Sascha Hauer
` (3 subsequent siblings)
8 siblings, 1 reply; 34+ messages in thread
From: Sascha Hauer @ 2010-12-09 13:47 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/mach-mx5/devices-imx51.h | 4 ++
arch/arm/plat-mxc/devices/Kconfig | 4 ++
arch/arm/plat-mxc/devices/Makefile | 1 +
arch/arm/plat-mxc/devices/platform-imx_ipuv3.c | 47 +++++++++++++++++++++++
arch/arm/plat-mxc/include/mach/devices-common.h | 10 +++++
5 files changed, 66 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-mxc/devices/platform-imx_ipuv3.c
diff --git a/arch/arm/mach-mx5/devices-imx51.h b/arch/arm/mach-mx5/devices-imx51.h
index 6302e46..851c114 100644
--- a/arch/arm/mach-mx5/devices-imx51.h
+++ b/arch/arm/mach-mx5/devices-imx51.h
@@ -47,3 +47,7 @@ extern const struct imx_spi_imx_data imx51_ecspi_data[] __initconst;
extern const struct imx_imx2_wdt_data imx51_imx2_wdt_data[] __initconst;
#define imx51_add_imx2_wdt(id, pdata) \
imx_add_imx2_wdt(&imx51_imx2_wdt_data[id])
+
+extern const struct imx_ipuv3_data imx51_ipuv3_data __initconst;
+#define imx51_add_ipuv3(pdata) \
+ imx_add_ipuv3(&imx51_ipuv3_data, pdata)
diff --git a/arch/arm/plat-mxc/devices/Kconfig b/arch/arm/plat-mxc/devices/Kconfig
index 2537166..262d9c5 100644
--- a/arch/arm/plat-mxc/devices/Kconfig
+++ b/arch/arm/plat-mxc/devices/Kconfig
@@ -71,3 +71,7 @@ config IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
config IMX_HAVE_PLATFORM_SPI_IMX
bool
+
+config IMX_HAVE_PLATFORM_IMX_IPUV3
+ bool
+
diff --git a/arch/arm/plat-mxc/devices/Makefile b/arch/arm/plat-mxc/devices/Makefile
index 75cd2ec..0a6be0a 100644
--- a/arch/arm/plat-mxc/devices/Makefile
+++ b/arch/arm/plat-mxc/devices/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_RNGA) += platform-mxc_rnga.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_W1) += platform-mxc_w1.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX) += platform-sdhci-esdhc-imx.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_SPI_IMX) += platform-spi_imx.o
+obj-$(CONFIG_IMX_HAVE_PLATFORM_IMX_IPUV3) += platform-imx_ipuv3.o
diff --git a/arch/arm/plat-mxc/devices/platform-imx_ipuv3.c b/arch/arm/plat-mxc/devices/platform-imx_ipuv3.c
new file mode 100644
index 0000000..a470edb
--- /dev/null
+++ b/arch/arm/plat-mxc/devices/platform-imx_ipuv3.c
@@ -0,0 +1,47 @@
+/*
+ * Copyright (C) 2010 Pengutronix
+ * Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>
+ *
+ * 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 published by the
+ * Free Software Foundation.
+ */
+#include <mach/hardware.h>
+#include <mach/devices-common.h>
+
+#define imx51_ipuv3_data_entry_single(soc) \
+ { \
+ .iobase = soc ## _IPU_CTRL_BASE_ADDR, \
+ .irq_err = soc ## _INT_IPU_ERR, \
+ .irq = soc ## _INT_IPU_SYN, \
+ }
+
+#ifdef CONFIG_SOC_IMX51
+const struct imx_ipuv3_data imx51_ipuv3_data __initconst + imx51_ipuv3_data_entry_single(MX51);
+#endif /* ifdef CONFIG_SOC_IMX35 */
+
+struct platform_device *__init imx_add_ipuv3(
+ const struct imx_ipuv3_data *data,
+ const struct imx_ipuv3_platform_data *pdata)
+{
+ struct resource res[] = {
+ {
+ .start = data->iobase,
+ .end = data->iobase + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ }, {
+ .start = data->irq_err,
+ .end = data->irq_err,
+ .flags = IORESOURCE_IRQ,
+ }, {
+ .start = data->irq,
+ .end = data->irq,
+ .flags = IORESOURCE_IRQ,
+ },
+ };
+
+ return imx_add_platform_device("imx-ipuv3", -1,
+ res, ARRAY_SIZE(res), pdata, sizeof(*pdata));
+}
+
diff --git a/arch/arm/plat-mxc/include/mach/devices-common.h b/arch/arm/plat-mxc/include/mach/devices-common.h
index 8658c9c..8f5197f 100644
--- a/arch/arm/plat-mxc/include/mach/devices-common.h
+++ b/arch/arm/plat-mxc/include/mach/devices-common.h
@@ -264,3 +264,13 @@ struct imx_spi_imx_data {
struct platform_device *__init imx_add_spi_imx(
const struct imx_spi_imx_data *data,
const struct spi_imx_master *pdata);
+
+#include <mach/ipu-v3.h>
+struct imx_ipuv3_data {
+ resource_size_t iobase;
+ resource_size_t irq_err;
+ resource_size_t irq;
+};
+struct platform_device *__init imx_add_ipuv3(
+ const struct imx_ipuv3_data *data,
+ const struct imx_ipuv3_platform_data *pdata);
--
1.7.2.3
^ permalink raw reply related [flat|nested] 34+ messages in thread* Re: [PATCH 6/9] ARM i.MX51: Add IPU device support
2010-12-09 13:47 ` [PATCH 6/9] ARM i.MX51: Add IPU device support Sascha Hauer
@ 2010-12-15 15:49 ` Arnd Bergmann
2010-12-15 16:26 ` Arnaud Patard
0 siblings, 1 reply; 34+ messages in thread
From: Arnd Bergmann @ 2010-12-15 15:49 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 09 December 2010, Sascha Hauer wrote:
> +#define imx51_add_ipuv3(pdata) \
> + imx_add_ipuv3(&imx51_ipuv3_data, pdata)
This looks like a pointless abstraction, it does not make
the code smaller or easier to read. I know it's sometimes
tempting to use macros, but in most cases, you should try
not to.
> +#define imx51_ipuv3_data_entry_single(soc) \
> + { \
> + .iobase = soc ## _IPU_CTRL_BASE_ADDR, \
> + .irq_err = soc ## _INT_IPU_ERR, \
> + .irq = soc ## _INT_IPU_SYN, \
> + }
> +
> +#ifdef CONFIG_SOC_IMX51
> +const struct imx_ipuv3_data imx51_ipuv3_data __initconst > + imx51_ipuv3_data_entry_single(MX51);
> +#endif /* ifdef CONFIG_SOC_IMX35 */
This looks really strange: You define a macro that is used
in only a single place, and the only user is a data structure
that references data from other files and is used elsewhere
as well.
Avoiding the macro would make it easier to grep for the use
of the identifiers.
If you put the data structure in the place where it is used,
you can avoid the #ifdef and make it static.
Also, the comment on the #endif does not match the #if.
Arnd
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: [PATCH 6/9] ARM i.MX51: Add IPU device support
2010-12-15 15:49 ` Arnd Bergmann
@ 2010-12-15 16:26 ` Arnaud Patard
2010-12-15 16:29 ` Arnd Bergmann
0 siblings, 1 reply; 34+ messages in thread
From: Arnaud Patard @ 2010-12-15 16:26 UTC (permalink / raw)
To: linux-arm-kernel
Arnd Bergmann <arnd@arndb.de> writes:
Hi,
> On Thursday 09 December 2010, Sascha Hauer wrote:
>> +#define imx51_add_ipuv3(pdata) \
>> + imx_add_ipuv3(&imx51_ipuv3_data, pdata)
>
> This looks like a pointless abstraction, it does not make
> the code smaller or easier to read. I know it's sometimes
> tempting to use macros, but in most cases, you should try
> not to.
>
it's how things have been handled atm in the imx code. I don't have
any preference on this at all but at least either we go on with it
or we get rid of all theses #defines. It's a matter of consistency.
The thing is that I would consider removing the imx*add* stuff to be
a cleanup and should be done in a different patch, not in a patchset
adding IPU support for imx51.
Anyway, let's wait for Sascha's point of view, he knows the imx stuff
far better than me.
Arnaud
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 7/9] ARM i.MX5: Allow to increase max zone order
2010-12-09 13:47 [PATCH RFC] i.MX51 Framebuffer support Sascha Hauer
` (4 preceding siblings ...)
2010-12-09 13:47 ` [PATCH 6/9] ARM i.MX51: Add IPU device support Sascha Hauer
@ 2010-12-09 13:47 ` Sascha Hauer
2010-12-09 13:47 ` [PATCH 8/9] ARM i.MX5: increase dma consistent size for IPU support Sascha Hauer
` (2 subsequent siblings)
8 siblings, 0 replies; 34+ messages in thread
From: Sascha Hauer @ 2010-12-09 13:47 UTC (permalink / raw)
To: linux-arm-kernel
default setting of 11 allows us to allocate at maximum
2MB chunks of contiguous memory. For resolutions up to
1920x1080 32bpp we need much more memory, so make zone
order configurable
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/Kconfig | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index db524e7..b3e070e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1410,8 +1410,8 @@ config SPARSE_IRQ
source "mm/Kconfig"
config FORCE_MAX_ZONEORDER
- int "Maximum zone order" if ARCH_SHMOBILE
- range 11 64 if ARCH_SHMOBILE
+ int "Maximum zone order" if ARCH_SHMOBILE || ARCH_MX5
+ range 11 64 if ARCH_SHMOBILE || ARCH_MX5
default "9" if SA1111
default "11"
help
--
1.7.2.3
^ permalink raw reply related [flat|nested] 34+ messages in thread* [PATCH 8/9] ARM i.MX5: increase dma consistent size for IPU support
2010-12-09 13:47 [PATCH RFC] i.MX51 Framebuffer support Sascha Hauer
` (5 preceding siblings ...)
2010-12-09 13:47 ` [PATCH 7/9] ARM i.MX5: Allow to increase max zone order Sascha Hauer
@ 2010-12-09 13:47 ` Sascha Hauer
2010-12-09 13:47 ` [PATCH 9/9] ARM i.MX51 babbage: Add framebuffer support Sascha Hauer
[not found] ` <1291902441-24712-4-git-send-email-s.hauer@pengutronix.de>
8 siblings, 0 replies; 34+ messages in thread
From: Sascha Hauer @ 2010-12-09 13:47 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/plat-mxc/include/mach/memory.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-mxc/include/mach/memory.h b/arch/arm/plat-mxc/include/mach/memory.h
index 9a9a000..a8152db 100644
--- a/arch/arm/plat-mxc/include/mach/memory.h
+++ b/arch/arm/plat-mxc/include/mach/memory.h
@@ -40,7 +40,7 @@
# endif
#endif
-#if defined(CONFIG_MX3_VIDEO)
+#if defined(CONFIG_MX3_VIDEO) || defined(CONFIG_MFD_IMX_IPU_V3)
/*
* Increase size of DMA-consistent memory region.
* This is required for mx3 camera driver to capture at least two QXGA frames.
--
1.7.2.3
^ permalink raw reply related [flat|nested] 34+ messages in thread* [PATCH 9/9] ARM i.MX51 babbage: Add framebuffer support
2010-12-09 13:47 [PATCH RFC] i.MX51 Framebuffer support Sascha Hauer
` (6 preceding siblings ...)
2010-12-09 13:47 ` [PATCH 8/9] ARM i.MX5: increase dma consistent size for IPU support Sascha Hauer
@ 2010-12-09 13:47 ` Sascha Hauer
2010-12-12 1:37 ` Liu Ying
[not found] ` <1291902441-24712-4-git-send-email-s.hauer@pengutronix.de>
8 siblings, 1 reply; 34+ messages in thread
From: Sascha Hauer @ 2010-12-09 13:47 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/mach-mx5/Kconfig | 1 +
arch/arm/mach-mx5/board-mx51_babbage.c | 74 ++++++++++++++++++++++++++++++++
2 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index 5011f42..2a936b7 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -22,6 +22,7 @@ config MACH_MX51_BABBAGE
select IMX_HAVE_PLATFORM_IMX_UART
select IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
select IMX_HAVE_PLATFORM_SPI_IMX
+ select IMX_HAVE_PLATFORM_IMX_IPUV3
help
Include support for MX51 Babbage platform, also known as MX51EVK in
u-boot. This includes specific configurations for the board and its
diff --git a/arch/arm/mach-mx5/board-mx51_babbage.c b/arch/arm/mach-mx5/board-mx51_babbage.c
index a896f84..169c48c 100644
--- a/arch/arm/mach-mx5/board-mx51_babbage.c
+++ b/arch/arm/mach-mx5/board-mx51_babbage.c
@@ -22,11 +22,13 @@
#include <linux/input.h>
#include <linux/spi/flash.h>
#include <linux/spi/spi.h>
+#include <linux/mfd/imx-ipu-v3.h>
#include <mach/common.h>
#include <mach/hardware.h>
#include <mach/iomux-mx51.h>
#include <mach/mxc_ehci.h>
+#include <mach/ipu-v3.h>
#include <asm/irq.h>
#include <asm/setup.h>
@@ -158,6 +160,41 @@ static iomux_v3_cfg_t mx51babbage_pads[] = {
MX51_PAD_CSPI1_SCLK__ECSPI1_SCLK,
MX51_PAD_CSPI1_SS0__GPIO_4_24,
MX51_PAD_CSPI1_SS1__GPIO_4_25,
+
+ /* Display */
+ MX51_PAD_DISPB2_SER_DIN__GPIO_3_5,
+ MX51_PAD_DISPB2_SER_DIO__GPIO_3_6,
+ MX51_PAD_NANDF_D12__GPIO_3_28,
+
+ MX51_PAD_DISP1_DAT0__DISP1_DAT0,
+ MX51_PAD_DISP1_DAT1__DISP1_DAT1,
+ MX51_PAD_DISP1_DAT2__DISP1_DAT2,
+ MX51_PAD_DISP1_DAT3__DISP1_DAT3,
+ MX51_PAD_DISP1_DAT4__DISP1_DAT4,
+ MX51_PAD_DISP1_DAT5__DISP1_DAT5,
+ MX51_PAD_DISP1_DAT6__DISP1_DAT6,
+ MX51_PAD_DISP1_DAT7__DISP1_DAT7,
+ MX51_PAD_DISP1_DAT8__DISP1_DAT8,
+ MX51_PAD_DISP1_DAT9__DISP1_DAT9,
+ MX51_PAD_DISP1_DAT10__DISP1_DAT10,
+ MX51_PAD_DISP1_DAT11__DISP1_DAT11,
+ MX51_PAD_DISP1_DAT12__DISP1_DAT12,
+ MX51_PAD_DISP1_DAT13__DISP1_DAT13,
+ MX51_PAD_DISP1_DAT14__DISP1_DAT14,
+ MX51_PAD_DISP1_DAT15__DISP1_DAT15,
+ MX51_PAD_DISP1_DAT16__DISP1_DAT16,
+ MX51_PAD_DISP1_DAT17__DISP1_DAT17,
+ MX51_PAD_DISP1_DAT18__DISP1_DAT18,
+ MX51_PAD_DISP1_DAT19__DISP1_DAT19,
+ MX51_PAD_DISP1_DAT20__DISP1_DAT20,
+ MX51_PAD_DISP1_DAT21__DISP1_DAT21,
+ MX51_PAD_DISP1_DAT22__DISP1_DAT22,
+ MX51_PAD_DISP1_DAT23__DISP1_DAT23,
+#define MX51_PAD_DI_GP4__IPU_DI2_PIN15 IOMUX_PAD(0x758, 0x350, 4, 0x0, 0, NO_PAD_CTRL)
+ MX51_PAD_DI_GP4__IPU_DI2_PIN15,
+
+ /* I2C DVI enable */
+ MX51_PAD_CSI2_HSYNC__GPIO_4_14,
};
/* Serial ports */
@@ -342,6 +379,21 @@ static const struct spi_imx_master mx51_babbage_spi_pdata __initconst = {
.num_chipselect = ARRAY_SIZE(mx51_babbage_spi_cs),
};
+static struct ipuv3_fb_platform_data babbage_fb0_data = {
+ .interface_pix_fmt = IPU_PIX_FMT_RGB24,
+ .flags = IMX_IPU_FB_USE_MODEDB | IMX_IPU_FB_USE_OVERLAY,
+};
+
+static struct ipuv3_fb_platform_data babbage_fb1_data = {
+ .interface_pix_fmt = IPU_PIX_FMT_RGB565,
+ .flags = IMX_IPU_FB_USE_MODEDB,
+};
+
+static struct imx_ipuv3_platform_data ipu_data = {
+ .fb0_platform_data = &babbage_fb0_data,
+ .fb1_platform_data = &babbage_fb1_data,
+};
+
/*
* Board specific initialization.
*/
@@ -388,6 +440,28 @@ static void __init mxc_board_init(void)
ARRAY_SIZE(mx51_babbage_spi_board_info));
imx51_add_ecspi(0, &mx51_babbage_spi_pdata);
imx51_add_imx2_wdt(0, NULL);
+
+#define GPIO_DVI_DETECT (2 * 32 + 28)
+#define GPIO_DVI_RESET (2 * 32 + 5)
+#define GPIO_DVI_PWRDN (2 * 32 + 6)
+#define GPIO_DVI_I2C (3 * 32 + 14)
+
+ /* DVI Detect */
+ gpio_request(GPIO_DVI_DETECT, "dvi detect");
+ gpio_direction_input(GPIO_DVI_DETECT);
+ /* DVI Reset - Assert for i2c disabled mode */
+ gpio_request(GPIO_DVI_RESET, "dvi reset");
+ gpio_set_value(GPIO_DVI_RESET, 0);
+ gpio_direction_output(GPIO_DVI_RESET, 0);
+ /* DVI Power-down */
+ gpio_request(GPIO_DVI_PWRDN, "dvi pwdn");
+ gpio_direction_output(GPIO_DVI_PWRDN, 0);
+ gpio_set_value(GPIO_DVI_PWRDN, 1);
+
+ gpio_request(GPIO_DVI_I2C, "dvi i2c");
+ gpio_direction_output(GPIO_DVI_I2C, 0);
+
+ imx51_add_ipuv3(&ipu_data);
}
static void __init mx51_babbage_timer_init(void)
--
1.7.2.3
^ permalink raw reply related [flat|nested] 34+ messages in thread* Re: [PATCH 9/9] ARM i.MX51 babbage: Add framebuffer support
2010-12-09 13:47 ` [PATCH 9/9] ARM i.MX51 babbage: Add framebuffer support Sascha Hauer
@ 2010-12-12 1:37 ` Liu Ying
2010-12-13 11:43 ` Sascha Hauer
0 siblings, 1 reply; 34+ messages in thread
From: Liu Ying @ 2010-12-12 1:37 UTC (permalink / raw)
To: linux-arm-kernel
Hello, Sascha,
I have following 3 comments to this patch:
1) I think DISP1_DATx pins need not be set specially, as they keep the
default register values.
2) Please define 'MX51_PAD_DI_GP4__IPU_DI2_PIN15' in
arch/arm/plat-mxc/include/mach/iomux-mx51.h, and rename the pin to be
'MX51_PAD_DI_GP4__DI2_PIN15', as we name it according to the MX51
iomux reference manual.
3) It is better to exchange the following two lines or just remove the
first line:
+ gpio_set_value(GPIO_DVI_RESET, 0);
+ gpio_direction_output(GPIO_DVI_RESET, 0);
Best Regards,
Liu Ying
2010/12/9 Sascha Hauer <s.hauer@pengutronix.de>:
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> arch/arm/mach-mx5/Kconfig | 1 +
> arch/arm/mach-mx5/board-mx51_babbage.c | 74 ++++++++++++++++++++++++++++++++
> 2 files changed, 75 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
> index 5011f42..2a936b7 100644
> --- a/arch/arm/mach-mx5/Kconfig
> +++ b/arch/arm/mach-mx5/Kconfig
> @@ -22,6 +22,7 @@ config MACH_MX51_BABBAGE
> select IMX_HAVE_PLATFORM_IMX_UART
> select IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
> select IMX_HAVE_PLATFORM_SPI_IMX
> + select IMX_HAVE_PLATFORM_IMX_IPUV3
> help
> Include support for MX51 Babbage platform, also known as MX51EVK in
> u-boot. This includes specific configurations for the board and its
> diff --git a/arch/arm/mach-mx5/board-mx51_babbage.c b/arch/arm/mach-mx5/board-mx51_babbage.c
> index a896f84..169c48c 100644
> --- a/arch/arm/mach-mx5/board-mx51_babbage.c
> +++ b/arch/arm/mach-mx5/board-mx51_babbage.c
> @@ -22,11 +22,13 @@
> #include <linux/input.h>
> #include <linux/spi/flash.h>
> #include <linux/spi/spi.h>
> +#include <linux/mfd/imx-ipu-v3.h>
>
> #include <mach/common.h>
> #include <mach/hardware.h>
> #include <mach/iomux-mx51.h>
> #include <mach/mxc_ehci.h>
> +#include <mach/ipu-v3.h>
>
> #include <asm/irq.h>
> #include <asm/setup.h>
> @@ -158,6 +160,41 @@ static iomux_v3_cfg_t mx51babbage_pads[] = {
> MX51_PAD_CSPI1_SCLK__ECSPI1_SCLK,
> MX51_PAD_CSPI1_SS0__GPIO_4_24,
> MX51_PAD_CSPI1_SS1__GPIO_4_25,
> +
> + /* Display */
> + MX51_PAD_DISPB2_SER_DIN__GPIO_3_5,
> + MX51_PAD_DISPB2_SER_DIO__GPIO_3_6,
> + MX51_PAD_NANDF_D12__GPIO_3_28,
> +
> + MX51_PAD_DISP1_DAT0__DISP1_DAT0,
> + MX51_PAD_DISP1_DAT1__DISP1_DAT1,
> + MX51_PAD_DISP1_DAT2__DISP1_DAT2,
> + MX51_PAD_DISP1_DAT3__DISP1_DAT3,
> + MX51_PAD_DISP1_DAT4__DISP1_DAT4,
> + MX51_PAD_DISP1_DAT5__DISP1_DAT5,
> + MX51_PAD_DISP1_DAT6__DISP1_DAT6,
> + MX51_PAD_DISP1_DAT7__DISP1_DAT7,
> + MX51_PAD_DISP1_DAT8__DISP1_DAT8,
> + MX51_PAD_DISP1_DAT9__DISP1_DAT9,
> + MX51_PAD_DISP1_DAT10__DISP1_DAT10,
> + MX51_PAD_DISP1_DAT11__DISP1_DAT11,
> + MX51_PAD_DISP1_DAT12__DISP1_DAT12,
> + MX51_PAD_DISP1_DAT13__DISP1_DAT13,
> + MX51_PAD_DISP1_DAT14__DISP1_DAT14,
> + MX51_PAD_DISP1_DAT15__DISP1_DAT15,
> + MX51_PAD_DISP1_DAT16__DISP1_DAT16,
> + MX51_PAD_DISP1_DAT17__DISP1_DAT17,
> + MX51_PAD_DISP1_DAT18__DISP1_DAT18,
> + MX51_PAD_DISP1_DAT19__DISP1_DAT19,
> + MX51_PAD_DISP1_DAT20__DISP1_DAT20,
> + MX51_PAD_DISP1_DAT21__DISP1_DAT21,
> + MX51_PAD_DISP1_DAT22__DISP1_DAT22,
> + MX51_PAD_DISP1_DAT23__DISP1_DAT23,
> +#define MX51_PAD_DI_GP4__IPU_DI2_PIN15 IOMUX_PAD(0x758, 0x350, 4, 0x0, 0, NO_PAD_CTRL)
> + MX51_PAD_DI_GP4__IPU_DI2_PIN15,
> +
> + /* I2C DVI enable */
> + MX51_PAD_CSI2_HSYNC__GPIO_4_14,
> };
>
> /* Serial ports */
> @@ -342,6 +379,21 @@ static const struct spi_imx_master mx51_babbage_spi_pdata __initconst = {
> .num_chipselect = ARRAY_SIZE(mx51_babbage_spi_cs),
> };
>
> +static struct ipuv3_fb_platform_data babbage_fb0_data = {
> + .interface_pix_fmt = IPU_PIX_FMT_RGB24,
> + .flags = IMX_IPU_FB_USE_MODEDB | IMX_IPU_FB_USE_OVERLAY,
> +};
> +
> +static struct ipuv3_fb_platform_data babbage_fb1_data = {
> + .interface_pix_fmt = IPU_PIX_FMT_RGB565,
> + .flags = IMX_IPU_FB_USE_MODEDB,
> +};
> +
> +static struct imx_ipuv3_platform_data ipu_data = {
> + .fb0_platform_data = &babbage_fb0_data,
> + .fb1_platform_data = &babbage_fb1_data,
> +};
> +
> /*
> * Board specific initialization.
> */
> @@ -388,6 +440,28 @@ static void __init mxc_board_init(void)
> ARRAY_SIZE(mx51_babbage_spi_board_info));
> imx51_add_ecspi(0, &mx51_babbage_spi_pdata);
> imx51_add_imx2_wdt(0, NULL);
> +
> +#define GPIO_DVI_DETECT (2 * 32 + 28)
> +#define GPIO_DVI_RESET (2 * 32 + 5)
> +#define GPIO_DVI_PWRDN (2 * 32 + 6)
> +#define GPIO_DVI_I2C (3 * 32 + 14)
> +
> + /* DVI Detect */
> + gpio_request(GPIO_DVI_DETECT, "dvi detect");
> + gpio_direction_input(GPIO_DVI_DETECT);
> + /* DVI Reset - Assert for i2c disabled mode */
> + gpio_request(GPIO_DVI_RESET, "dvi reset");
> + gpio_set_value(GPIO_DVI_RESET, 0);
> + gpio_direction_output(GPIO_DVI_RESET, 0);
> + /* DVI Power-down */
> + gpio_request(GPIO_DVI_PWRDN, "dvi pwdn");
> + gpio_direction_output(GPIO_DVI_PWRDN, 0);
> + gpio_set_value(GPIO_DVI_PWRDN, 1);
> +
> + gpio_request(GPIO_DVI_I2C, "dvi i2c");
> + gpio_direction_output(GPIO_DVI_I2C, 0);
> +
> + imx51_add_ipuv3(&ipu_data);
> }
>
> static void __init mx51_babbage_timer_init(void)
> --
> 1.7.2.3
>
> --
> 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 [flat|nested] 34+ messages in thread* Re: [PATCH 9/9] ARM i.MX51 babbage: Add framebuffer support
2010-12-12 1:37 ` Liu Ying
@ 2010-12-13 11:43 ` Sascha Hauer
2010-12-14 6:47 ` Liu Ying
0 siblings, 1 reply; 34+ messages in thread
From: Sascha Hauer @ 2010-12-13 11:43 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, Dec 12, 2010 at 09:37:38AM +0800, Liu Ying wrote:
> Hello, Sascha,
>
> I have following 3 comments to this patch:
> 1) I think DISP1_DATx pins need not be set specially, as they keep the
> default register values.
We do not want to depend on default register values in the Linux Kernel.
> 2) Please define 'MX51_PAD_DI_GP4__IPU_DI2_PIN15' in
> arch/arm/plat-mxc/include/mach/iomux-mx51.h, and rename the pin to be
> 'MX51_PAD_DI_GP4__DI2_PIN15', as we name it according to the MX51
> iomux reference manual.
I'm not sure. Normally it's good practice to code the unit into the
name. Otherwise we end up with names like MX51_PAD_xyz__TX which could
be the tx pin of just about any unit.
> 3) It is better to exchange the following two lines or just remove the
> first line:
> + gpio_set_value(GPIO_DVI_RESET, 0);
> + gpio_direction_output(GPIO_DVI_RESET, 0);
ok.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 9/9] ARM i.MX51 babbage: Add framebuffer support
2010-12-13 11:43 ` Sascha Hauer
@ 2010-12-14 6:47 ` Liu Ying
0 siblings, 0 replies; 34+ messages in thread
From: Liu Ying @ 2010-12-14 6:47 UTC (permalink / raw)
To: linux-arm-kernel
2010/12/13 Sascha Hauer <s.hauer@pengutronix.de>:
> On Sun, Dec 12, 2010 at 09:37:38AM +0800, Liu Ying wrote:
>> Hello, Sascha,
>>
>> I have following 3 comments to this patch:
>> 1) I think DISP1_DATx pins need not be set specially, as they keep the
>> default register values.
>
> We do not want to depend on default register values in the Linux Kernel.
[LY] Ok. Please add disp1 related pins configuration, including
DISP1_HSYNC, DISP1_VSYNC and DISP1_CLK.
It will be fine to add disp2 related pins configuration also.
>
>> 2) Please define 'MX51_PAD_DI_GP4__IPU_DI2_PIN15' in
>> arch/arm/plat-mxc/include/mach/iomux-mx51.h, and rename the pin to be
>> 'MX51_PAD_DI_GP4__DI2_PIN15', as we name it according to the MX51
>> iomux reference manual.
>
> I'm not sure. Normally it's good practice to code the unit into the
> name. Otherwise we end up with names like MX51_PAD_xyz__TX which could
> be the tx pin of just about any unit.
>
>
>> 3) It is better to exchange the following two lines or just remove the
>> first line:
>> + gpio_set_value(GPIO_DVI_RESET, 0);
>> + gpio_direction_output(GPIO_DVI_RESET, 0);
>
> ok.
>
> Sascha
>
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <1291902441-24712-4-git-send-email-s.hauer@pengutronix.de>]