From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 01/10] MCDE: Add hardware abstraction layer
Date: Fri, 12 Nov 2010 15:43:52 +0000 [thread overview]
Message-ID: <201011121643.52923.arnd@arndb.de> (raw)
In-Reply-To: <1289390653-6111-2-git-send-email-jimmy.rubin@stericsson.com>
On Wednesday 10 November 2010, Jimmy Rubin wrote:
> This patch adds support for MCDE, Memory-to-display controller
> found in the ST-Ericsson ux500 products.
Hi Jimmy,
I haven't looked at what this device does, but I've tried to do
a review based on coding style and common practices. I hope this
is useful to you.
> This patch adds the hardware abstraction layer.
> All calls to the hardware is handled in mcde_hw.c
A "hardware abstraction layer" is generally considered a bad thing,
you're usually better off not advertising your code as being one.
As a rule, the device driver *is* the hardware abstraction, so you
should not add another one ;-)
> +static void disable_channel(struct mcde_chnl_state *chnl);
> +static void enable_channel(struct mcde_chnl_state *chnl);
> +static void watchdog_auto_sync_timer_function(unsigned long arg);
I generally recomment avoiding forward declarations of static functions.
Just reorder the code so you don't need them.
> +u8 *mcdeio;
> +u8 **dsiio;
> +DEFINE_SPINLOCK(mcde_lock); /* REVIEW: Remove or use */
> +struct platform_device *mcde_dev;
> +u8 num_dsilinks;
You should try hard to avoid global variables in a well-designed driver.
There are many ways around them, like accessor functions or splitting the
driver into files in a more logical way where each file only accesses
its own data. If you really cannot think of a way to avoid these,
put them in a proper name space in the way that you have done for the
global functions, by prefixing each identifier with "mcde_".
> +static u8 hardware_version;
> +
> +static struct regulator *regulator;
> +static struct clk *clock_dsi;
> +static struct clk *clock_mcde;
> +static struct clk *clock_dsi_lp;
> +static u8 mcde_is_enabled;
Even static variables like these can cause problems. Ideally all of these
are referenced through a driver private data structure that is passed around
with the device. This way you can trivially support multiple devices if
that ever becomes necessary.
> +static inline u32 dsi_rreg(int i, u32 reg)
> +{
> + return readl(dsiio[i] + reg);
> +}
> +static inline void dsi_wreg(int i, u32 reg, u32 val)
> +{
> + writel(val, dsiio[i] + reg);
> +}
dsiio is not marked __iomem, so there is something wrong here.
Moreover, why do you need two indexes? If you have multiple identical
"dsiio" structures, maybe each of them should just be a device by itself?
> +struct mcde_ovly_state {
> + bool inuse;
> + u8 idx; /* MCDE overlay index */
> + struct mcde_chnl_state *chnl; /* Owner channel */
> + u32 transactionid; /* Apply time stamp */
> + u32 transactionid_regs; /* Register update time stamp */
> + u32 transactionid_hw; /* HW completed time stamp */
> + wait_queue_head_t waitq_hw; /* Waitq for transactionid_hw */
> +
> + /* Staged settings */
> + u32 paddr;
> + u16 stride;
> + enum mcde_ovly_pix_fmt pix_fmt;
> +
> + u16 src_x;
> + u16 src_y;
> + u16 dst_x;
> + u16 dst_y;
> + u16 dst_z;
> + u16 w;
> + u16 h;
> +
> + /* Applied settings */
> + struct ovly_regs regs;
> +};
There should probably be a "struct device" pointer in this, so you can pass
it around as a real object.
> + /* Handle channel irqs */
> + irq_status = mcde_rreg(MCDE_RISPP);
> + if (irq_status & MCDE_RISPP_VCMPARIS_MASK) {
> + chnl = &channels[MCDE_CHNL_A];
> ...
> + }
> + if (irq_status & MCDE_RISPP_VCMPBRIS_MASK) {
> + chnl = &channels[MCDE_CHNL_B];
> ...
> + }
> + if (irq_status & MCDE_RISPP_VCMPC0RIS_MASK) {
> + chnl = &channels[MCDE_CHNL_C0];
> ...
> + }
This looks a bit like you actually have multiple interrupt lines multiplexed
through a private interrupt controller. Have you considered making this controller
a separate device to multiplex the interrupt numbers?
> +void wait_for_overlay(struct mcde_ovly_state *ovly)
Not an appropriate name for a global function. Either make this static or
call it mcde_wait_for_overlay. Same for some other functions.
> +#ifdef CONFIG_AV8100_SDTV
> + /* TODO: check if these watermark levels work for HDMI as well. */
> + pixelfetchwtrmrklevel = MCDE_PIXFETCH_SMALL_WTRMRKLVL;
> +#else
> + if ((fifo = MCDE_FIFO_A || fifo = MCDE_FIFO_B) &&
> + regs->ppl >= fifo_size * 2)
> + pixelfetchwtrmrklevel = MCDE_PIXFETCH_LARGE_WTRMRKLVL;
> + else
> + pixelfetchwtrmrklevel = MCDE_PIXFETCH_MEDIUM_WTRMRKLVL;
> +#endif /* CONFIG_AV8100_SDTV */
Be careful with config options like this. If you want to build a kernel
to run on all machines, the first part probably needs to check where it
is running and consider the other pixelfetchwtrmrklevel values as well.
> +/* Channel path */
> +#define MCDE_CHNLPATH(__chnl, __fifo, __type, __ifc, __link) \
> + (((__chnl) << 16) | ((__fifo) << 12) | \
> + ((__type) << 8) | ((__ifc) << 4) | ((__link) << 0))
> +enum mcde_chnl_path {
> + /* Channel A */
> + MCDE_CHNLPATH_CHNLA_FIFOA_DPI_0 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_A, MCDE_PORTTYPE_DPI, 0, 0),
> + MCDE_CHNLPATH_CHNLA_FIFOA_DSI_IFC0_0 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_A, MCDE_PORTTYPE_DSI, 0, 0),
> + MCDE_CHNLPATH_CHNLA_FIFOA_DSI_IFC0_1 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_A, MCDE_PORTTYPE_DSI, 0, 1),
> + MCDE_CHNLPATH_CHNLA_FIFOC0_DSI_IFC0_2 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_C0, MCDE_PORTTYPE_DSI, 0, 2),
> + MCDE_CHNLPATH_CHNLA_FIFOC0_DSI_IFC1_0 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_C0, MCDE_PORTTYPE_DSI, 1, 0),
> + MCDE_CHNLPATH_CHNLA_FIFOC0_DSI_IFC1_1 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_C0, MCDE_PORTTYPE_DSI, 1, 1),
> + MCDE_CHNLPATH_CHNLA_FIFOA_DSI_IFC1_2 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_A, MCDE_PORTTYPE_DSI, 1, 2),
A table like this would become more readable by making each entry a single line,
even if that goes beyond the 80-character limit.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 01/10] MCDE: Add hardware abstraction layer
Date: Fri, 12 Nov 2010 16:43:52 +0100 [thread overview]
Message-ID: <201011121643.52923.arnd@arndb.de> (raw)
In-Reply-To: <1289390653-6111-2-git-send-email-jimmy.rubin@stericsson.com>
On Wednesday 10 November 2010, Jimmy Rubin wrote:
> This patch adds support for MCDE, Memory-to-display controller
> found in the ST-Ericsson ux500 products.
Hi Jimmy,
I haven't looked at what this device does, but I've tried to do
a review based on coding style and common practices. I hope this
is useful to you.
> This patch adds the hardware abstraction layer.
> All calls to the hardware is handled in mcde_hw.c
A "hardware abstraction layer" is generally considered a bad thing,
you're usually better off not advertising your code as being one.
As a rule, the device driver *is* the hardware abstraction, so you
should not add another one ;-)
> +static void disable_channel(struct mcde_chnl_state *chnl);
> +static void enable_channel(struct mcde_chnl_state *chnl);
> +static void watchdog_auto_sync_timer_function(unsigned long arg);
I generally recomment avoiding forward declarations of static functions.
Just reorder the code so you don't need them.
> +u8 *mcdeio;
> +u8 **dsiio;
> +DEFINE_SPINLOCK(mcde_lock); /* REVIEW: Remove or use */
> +struct platform_device *mcde_dev;
> +u8 num_dsilinks;
You should try hard to avoid global variables in a well-designed driver.
There are many ways around them, like accessor functions or splitting the
driver into files in a more logical way where each file only accesses
its own data. If you really cannot think of a way to avoid these,
put them in a proper name space in the way that you have done for the
global functions, by prefixing each identifier with "mcde_".
> +static u8 hardware_version;
> +
> +static struct regulator *regulator;
> +static struct clk *clock_dsi;
> +static struct clk *clock_mcde;
> +static struct clk *clock_dsi_lp;
> +static u8 mcde_is_enabled;
Even static variables like these can cause problems. Ideally all of these
are referenced through a driver private data structure that is passed around
with the device. This way you can trivially support multiple devices if
that ever becomes necessary.
> +static inline u32 dsi_rreg(int i, u32 reg)
> +{
> + return readl(dsiio[i] + reg);
> +}
> +static inline void dsi_wreg(int i, u32 reg, u32 val)
> +{
> + writel(val, dsiio[i] + reg);
> +}
dsiio is not marked __iomem, so there is something wrong here.
Moreover, why do you need two indexes? If you have multiple identical
"dsiio" structures, maybe each of them should just be a device by itself?
> +struct mcde_ovly_state {
> + bool inuse;
> + u8 idx; /* MCDE overlay index */
> + struct mcde_chnl_state *chnl; /* Owner channel */
> + u32 transactionid; /* Apply time stamp */
> + u32 transactionid_regs; /* Register update time stamp */
> + u32 transactionid_hw; /* HW completed time stamp */
> + wait_queue_head_t waitq_hw; /* Waitq for transactionid_hw */
> +
> + /* Staged settings */
> + u32 paddr;
> + u16 stride;
> + enum mcde_ovly_pix_fmt pix_fmt;
> +
> + u16 src_x;
> + u16 src_y;
> + u16 dst_x;
> + u16 dst_y;
> + u16 dst_z;
> + u16 w;
> + u16 h;
> +
> + /* Applied settings */
> + struct ovly_regs regs;
> +};
There should probably be a "struct device" pointer in this, so you can pass
it around as a real object.
> + /* Handle channel irqs */
> + irq_status = mcde_rreg(MCDE_RISPP);
> + if (irq_status & MCDE_RISPP_VCMPARIS_MASK) {
> + chnl = &channels[MCDE_CHNL_A];
> ...
> + }
> + if (irq_status & MCDE_RISPP_VCMPBRIS_MASK) {
> + chnl = &channels[MCDE_CHNL_B];
> ...
> + }
> + if (irq_status & MCDE_RISPP_VCMPC0RIS_MASK) {
> + chnl = &channels[MCDE_CHNL_C0];
> ...
> + }
This looks a bit like you actually have multiple interrupt lines multiplexed
through a private interrupt controller. Have you considered making this controller
a separate device to multiplex the interrupt numbers?
> +void wait_for_overlay(struct mcde_ovly_state *ovly)
Not an appropriate name for a global function. Either make this static or
call it mcde_wait_for_overlay. Same for some other functions.
> +#ifdef CONFIG_AV8100_SDTV
> + /* TODO: check if these watermark levels work for HDMI as well. */
> + pixelfetchwtrmrklevel = MCDE_PIXFETCH_SMALL_WTRMRKLVL;
> +#else
> + if ((fifo == MCDE_FIFO_A || fifo == MCDE_FIFO_B) &&
> + regs->ppl >= fifo_size * 2)
> + pixelfetchwtrmrklevel = MCDE_PIXFETCH_LARGE_WTRMRKLVL;
> + else
> + pixelfetchwtrmrklevel = MCDE_PIXFETCH_MEDIUM_WTRMRKLVL;
> +#endif /* CONFIG_AV8100_SDTV */
Be careful with config options like this. If you want to build a kernel
to run on all machines, the first part probably needs to check where it
is running and consider the other pixelfetchwtrmrklevel values as well.
> +/* Channel path */
> +#define MCDE_CHNLPATH(__chnl, __fifo, __type, __ifc, __link) \
> + (((__chnl) << 16) | ((__fifo) << 12) | \
> + ((__type) << 8) | ((__ifc) << 4) | ((__link) << 0))
> +enum mcde_chnl_path {
> + /* Channel A */
> + MCDE_CHNLPATH_CHNLA_FIFOA_DPI_0 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_A, MCDE_PORTTYPE_DPI, 0, 0),
> + MCDE_CHNLPATH_CHNLA_FIFOA_DSI_IFC0_0 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_A, MCDE_PORTTYPE_DSI, 0, 0),
> + MCDE_CHNLPATH_CHNLA_FIFOA_DSI_IFC0_1 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_A, MCDE_PORTTYPE_DSI, 0, 1),
> + MCDE_CHNLPATH_CHNLA_FIFOC0_DSI_IFC0_2 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_C0, MCDE_PORTTYPE_DSI, 0, 2),
> + MCDE_CHNLPATH_CHNLA_FIFOC0_DSI_IFC1_0 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_C0, MCDE_PORTTYPE_DSI, 1, 0),
> + MCDE_CHNLPATH_CHNLA_FIFOC0_DSI_IFC1_1 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_C0, MCDE_PORTTYPE_DSI, 1, 1),
> + MCDE_CHNLPATH_CHNLA_FIFOA_DSI_IFC1_2 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_A, MCDE_PORTTYPE_DSI, 1, 2),
A table like this would become more readable by making each entry a single line,
even if that goes beyond the 80-character limit.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Jimmy Rubin <jimmy.rubin@stericsson.com>,
linux-fbdev@vger.kernel.org, linux-media@vger.kernel.org,
Dan Johansson <dan.johansson@stericsson.com>,
Linus Walleij <linus.walleij@stericsson.com>
Subject: Re: [PATCH 01/10] MCDE: Add hardware abstraction layer
Date: Fri, 12 Nov 2010 16:43:52 +0100 [thread overview]
Message-ID: <201011121643.52923.arnd@arndb.de> (raw)
In-Reply-To: <1289390653-6111-2-git-send-email-jimmy.rubin@stericsson.com>
On Wednesday 10 November 2010, Jimmy Rubin wrote:
> This patch adds support for MCDE, Memory-to-display controller
> found in the ST-Ericsson ux500 products.
Hi Jimmy,
I haven't looked at what this device does, but I've tried to do
a review based on coding style and common practices. I hope this
is useful to you.
> This patch adds the hardware abstraction layer.
> All calls to the hardware is handled in mcde_hw.c
A "hardware abstraction layer" is generally considered a bad thing,
you're usually better off not advertising your code as being one.
As a rule, the device driver *is* the hardware abstraction, so you
should not add another one ;-)
> +static void disable_channel(struct mcde_chnl_state *chnl);
> +static void enable_channel(struct mcde_chnl_state *chnl);
> +static void watchdog_auto_sync_timer_function(unsigned long arg);
I generally recomment avoiding forward declarations of static functions.
Just reorder the code so you don't need them.
> +u8 *mcdeio;
> +u8 **dsiio;
> +DEFINE_SPINLOCK(mcde_lock); /* REVIEW: Remove or use */
> +struct platform_device *mcde_dev;
> +u8 num_dsilinks;
You should try hard to avoid global variables in a well-designed driver.
There are many ways around them, like accessor functions or splitting the
driver into files in a more logical way where each file only accesses
its own data. If you really cannot think of a way to avoid these,
put them in a proper name space in the way that you have done for the
global functions, by prefixing each identifier with "mcde_".
> +static u8 hardware_version;
> +
> +static struct regulator *regulator;
> +static struct clk *clock_dsi;
> +static struct clk *clock_mcde;
> +static struct clk *clock_dsi_lp;
> +static u8 mcde_is_enabled;
Even static variables like these can cause problems. Ideally all of these
are referenced through a driver private data structure that is passed around
with the device. This way you can trivially support multiple devices if
that ever becomes necessary.
> +static inline u32 dsi_rreg(int i, u32 reg)
> +{
> + return readl(dsiio[i] + reg);
> +}
> +static inline void dsi_wreg(int i, u32 reg, u32 val)
> +{
> + writel(val, dsiio[i] + reg);
> +}
dsiio is not marked __iomem, so there is something wrong here.
Moreover, why do you need two indexes? If you have multiple identical
"dsiio" structures, maybe each of them should just be a device by itself?
> +struct mcde_ovly_state {
> + bool inuse;
> + u8 idx; /* MCDE overlay index */
> + struct mcde_chnl_state *chnl; /* Owner channel */
> + u32 transactionid; /* Apply time stamp */
> + u32 transactionid_regs; /* Register update time stamp */
> + u32 transactionid_hw; /* HW completed time stamp */
> + wait_queue_head_t waitq_hw; /* Waitq for transactionid_hw */
> +
> + /* Staged settings */
> + u32 paddr;
> + u16 stride;
> + enum mcde_ovly_pix_fmt pix_fmt;
> +
> + u16 src_x;
> + u16 src_y;
> + u16 dst_x;
> + u16 dst_y;
> + u16 dst_z;
> + u16 w;
> + u16 h;
> +
> + /* Applied settings */
> + struct ovly_regs regs;
> +};
There should probably be a "struct device" pointer in this, so you can pass
it around as a real object.
> + /* Handle channel irqs */
> + irq_status = mcde_rreg(MCDE_RISPP);
> + if (irq_status & MCDE_RISPP_VCMPARIS_MASK) {
> + chnl = &channels[MCDE_CHNL_A];
> ...
> + }
> + if (irq_status & MCDE_RISPP_VCMPBRIS_MASK) {
> + chnl = &channels[MCDE_CHNL_B];
> ...
> + }
> + if (irq_status & MCDE_RISPP_VCMPC0RIS_MASK) {
> + chnl = &channels[MCDE_CHNL_C0];
> ...
> + }
This looks a bit like you actually have multiple interrupt lines multiplexed
through a private interrupt controller. Have you considered making this controller
a separate device to multiplex the interrupt numbers?
> +void wait_for_overlay(struct mcde_ovly_state *ovly)
Not an appropriate name for a global function. Either make this static or
call it mcde_wait_for_overlay. Same for some other functions.
> +#ifdef CONFIG_AV8100_SDTV
> + /* TODO: check if these watermark levels work for HDMI as well. */
> + pixelfetchwtrmrklevel = MCDE_PIXFETCH_SMALL_WTRMRKLVL;
> +#else
> + if ((fifo == MCDE_FIFO_A || fifo == MCDE_FIFO_B) &&
> + regs->ppl >= fifo_size * 2)
> + pixelfetchwtrmrklevel = MCDE_PIXFETCH_LARGE_WTRMRKLVL;
> + else
> + pixelfetchwtrmrklevel = MCDE_PIXFETCH_MEDIUM_WTRMRKLVL;
> +#endif /* CONFIG_AV8100_SDTV */
Be careful with config options like this. If you want to build a kernel
to run on all machines, the first part probably needs to check where it
is running and consider the other pixelfetchwtrmrklevel values as well.
> +/* Channel path */
> +#define MCDE_CHNLPATH(__chnl, __fifo, __type, __ifc, __link) \
> + (((__chnl) << 16) | ((__fifo) << 12) | \
> + ((__type) << 8) | ((__ifc) << 4) | ((__link) << 0))
> +enum mcde_chnl_path {
> + /* Channel A */
> + MCDE_CHNLPATH_CHNLA_FIFOA_DPI_0 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_A, MCDE_PORTTYPE_DPI, 0, 0),
> + MCDE_CHNLPATH_CHNLA_FIFOA_DSI_IFC0_0 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_A, MCDE_PORTTYPE_DSI, 0, 0),
> + MCDE_CHNLPATH_CHNLA_FIFOA_DSI_IFC0_1 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_A, MCDE_PORTTYPE_DSI, 0, 1),
> + MCDE_CHNLPATH_CHNLA_FIFOC0_DSI_IFC0_2 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_C0, MCDE_PORTTYPE_DSI, 0, 2),
> + MCDE_CHNLPATH_CHNLA_FIFOC0_DSI_IFC1_0 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_C0, MCDE_PORTTYPE_DSI, 1, 0),
> + MCDE_CHNLPATH_CHNLA_FIFOC0_DSI_IFC1_1 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_C0, MCDE_PORTTYPE_DSI, 1, 1),
> + MCDE_CHNLPATH_CHNLA_FIFOA_DSI_IFC1_2 = MCDE_CHNLPATH(MCDE_CHNL_A,
> + MCDE_FIFO_A, MCDE_PORTTYPE_DSI, 1, 2),
A table like this would become more readable by making each entry a single line,
even if that goes beyond the 80-character limit.
Arnd
next prev parent reply other threads:[~2010-11-12 15:43 UTC|newest]
Thread overview: 130+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-10 12:04 [PATCH 00/10] MCDE: Add frame buffer device driver Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` [PATCH 01/10] MCDE: Add hardware abstraction layer Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` [PATCH 02/10] MCDE: Add configuration registers Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` [PATCH 03/10] MCDE: Add pixel processing registers Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` [PATCH 04/10] MCDE: Add formatter registers Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` [PATCH 05/10] MCDE: Add dsi link registers Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` [PATCH 06/10] MCDE: Add generic display Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` [PATCH 07/10] MCDE: Add display subsystem framework Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` [PATCH 08/10] MCDE: Add frame buffer device Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` [PATCH 09/10] MCDE: Add build files and bus Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` [PATCH 10/10] ux500: MCDE: Add platform specific data Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-12 16:03 ` Arnd Bergmann
2010-11-12 16:03 ` Arnd Bergmann
2010-11-12 16:03 ` Arnd Bergmann
2010-11-25 11:20 ` Jimmy RUBIN
2010-11-25 11:20 ` Jimmy RUBIN
2010-11-12 16:23 ` [PATCH 09/10] MCDE: Add build files and bus Arnd Bergmann
2010-11-12 16:23 ` Arnd Bergmann
2010-11-12 16:23 ` Arnd Bergmann
2010-11-12 16:29 ` [PATCH 08/10] MCDE: Add frame buffer device Arnd Bergmann
2010-11-12 16:29 ` Arnd Bergmann
2010-11-12 16:29 ` Arnd Bergmann
2010-11-25 11:52 ` Jimmy RUBIN
2010-11-25 11:52 ` Jimmy RUBIN
2010-11-12 16:38 ` [PATCH 07/10] MCDE: Add display subsystem framework Arnd Bergmann
2010-11-12 16:38 ` Arnd Bergmann
2010-11-12 16:38 ` Arnd Bergmann
2010-11-25 7:16 ` Jimmy RUBIN
2010-11-25 7:16 ` Jimmy RUBIN
2010-11-12 15:46 ` [PATCH 03/10] MCDE: Add pixel processing registers Arnd Bergmann
2010-11-12 15:46 ` Arnd Bergmann
2010-11-12 15:46 ` Arnd Bergmann
2010-11-12 15:14 ` [PATCH 02/10] MCDE: Add configuration registers Arnd Bergmann
2010-11-12 15:14 ` Arnd Bergmann
2010-11-12 15:14 ` Arnd Bergmann
2010-11-12 15:34 ` Russell King - ARM Linux
2010-11-12 15:34 ` Russell King - ARM Linux
2010-11-12 15:34 ` Russell King - ARM Linux
2010-11-15 14:25 ` Arnd Bergmann
2010-11-15 14:25 ` Arnd Bergmann
2010-11-15 14:25 ` Arnd Bergmann
2010-11-15 14:59 ` Russell King - ARM Linux
2010-11-15 14:59 ` Russell King - ARM Linux
2010-11-15 14:59 ` Russell King - ARM Linux
2010-11-15 18:24 ` Geert Uytterhoeven
2010-11-15 18:24 ` Geert Uytterhoeven
2010-11-15 18:24 ` Geert Uytterhoeven
2010-11-25 11:30 ` Jimmy RUBIN
2010-11-25 11:30 ` Jimmy RUBIN
2010-11-25 16:21 ` Arnd Bergmann
2010-11-25 16:21 ` Arnd Bergmann
2010-11-10 17:14 ` [PATCH 01/10] MCDE: Add hardware abstraction layer Joe Perches
2010-11-10 17:14 ` Joe Perches
2010-11-10 17:14 ` Joe Perches
2010-11-15 9:52 ` Jimmy RUBIN
2010-11-15 9:52 ` Jimmy RUBIN
2010-11-15 9:52 ` Jimmy RUBIN
2010-11-15 16:30 ` Joe Perches
2010-11-15 16:30 ` Joe Perches
2010-11-15 16:30 ` Joe Perches
2010-11-12 15:43 ` Arnd Bergmann [this message]
2010-11-12 15:43 ` Arnd Bergmann
2010-11-12 15:43 ` Arnd Bergmann
2010-11-16 15:29 ` Jimmy RUBIN
2010-11-16 15:29 ` Jimmy RUBIN
2010-11-16 15:29 ` Jimmy RUBIN
2010-11-16 16:12 ` Arnd Bergmann
2010-11-16 16:12 ` Arnd Bergmann
2010-11-16 16:12 ` Arnd Bergmann
2010-11-16 16:16 ` Arnd Bergmann
2010-11-16 16:16 ` Arnd Bergmann
2010-11-16 16:16 ` Arnd Bergmann
2010-11-16 19:46 ` Joe Perches
2010-11-16 19:46 ` Joe Perches
2010-11-16 19:46 ` Joe Perches
2010-11-17 9:55 ` Arnd Bergmann
2010-11-17 9:55 ` Arnd Bergmann
2010-11-17 9:55 ` Arnd Bergmann
2010-11-17 16:01 ` Joe Perches
2010-11-17 16:01 ` Joe Perches
2010-11-17 16:01 ` Joe Perches
2010-11-10 14:42 ` [PATCH 00/10] MCDE: Add frame buffer device driver Alex Deucher
2010-11-10 14:42 ` Alex Deucher
2010-11-10 14:42 ` Alex Deucher
2010-11-12 13:18 ` Jimmy RUBIN
2010-11-12 13:18 ` Jimmy RUBIN
2010-11-12 13:18 ` Jimmy RUBIN
2010-11-12 15:52 ` Alex Deucher
2010-11-12 15:52 ` Alex Deucher
2010-11-12 15:52 ` Alex Deucher
2010-11-12 16:46 ` Marcus LORENTZON
2010-11-12 16:46 ` Marcus LORENTZON
2010-11-12 16:46 ` Marcus LORENTZON
2010-11-12 17:22 ` Alex Deucher
2010-11-12 17:22 ` Alex Deucher
2010-11-12 17:22 ` Alex Deucher
2010-11-15 11:05 ` Michel Dänzer
2010-11-15 11:05 ` Michel Dänzer
2010-11-15 11:05 ` Michel Dänzer
2010-11-13 11:54 ` Hans Verkuil
2010-11-13 11:54 ` Hans Verkuil
2010-11-13 11:54 ` Hans Verkuil
2010-11-13 17:26 ` Marcus LORENTZON
2010-11-13 17:26 ` Marcus LORENTZON
2010-11-13 17:26 ` Marcus LORENTZON
2010-11-13 17:57 ` Hans Verkuil
2010-11-13 17:57 ` Hans Verkuil
2010-11-13 17:57 ` Hans Verkuil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201011121643.52923.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.