All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jimmy RUBIN <jimmy.rubin@stericsson.com>
To: Joe Perches <joe@perches.com>
Cc: "linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-media@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: Mon, 15 Nov 2010 10:52:55 +0100	[thread overview]
Message-ID: <F45880696056844FA6A73F415B568C6953604E7105@EXDCVYMBSTM006.EQ1STM.local> (raw)
In-Reply-To: <1289409276.15905.65.camel@Joe-Laptop>

Hi Joe,

Thanks for your input.
See comments below.
 
> Just trivia:
> 
> > diff --git a/drivers/video/mcde/mcde_hw.c
> b/drivers/video/mcde/mcde_hw.c
> 
> []
> 
> > +#define dsi_rfld(__i, __reg, __fld) \
> > +	((dsi_rreg(__i, __reg) & __reg##_##__fld##_MASK) >> \
> > +		__reg##_##__fld##_SHIFT)
> > +#define dsi_wfld(__i, __reg, __fld, __val) \
> > +	dsi_wreg(__i, __reg, (dsi_rreg(__i, __reg) & \
> > +	~__reg##_##__fld##_MASK) | (((__val) <<
> __reg##_##__fld##_SHIFT) & \
> > +		 __reg##_##__fld##_MASK))
> 
> These macros are not particularly readable.
> Perhaps use statement expression macros like:
> 
> #define dsi_rfld(__i, __reg, __fld)
> 		\
> ({
> 			\
> 	const u32 mask = __reg##_#__fld##_MASK;
> 		\
> 	const u32 shift = __reg##_##__fld##_SHIFT;
> 	\
> 	((dsi_rreg(__i, __reg) & mask) >> shift;
> 	\
> })
> 
> #define dsi_wfld(__i, __reg, __fld, __val)
> 	\
> ({
> 			\
> 	const u32 mask = __reg##_#__fld##_MASK;
> 		\
> 	const u32 shift = __reg##_##__fld##_SHIFT;
> 	\
> 	dsi_wreg(__i, __reg,
> 		\
> 		 (dsi_rreg(__i, __reg) & ~mask) | (((__val) <<
> shift) & mask));\
> })

I agree, more readable.
> 
> > +static struct mcde_chnl_state channels[] = {
> 
> Should more static structs be static const?

I think so, we got some strange behavior when we changed the structs to static const. But we will investigate it.

> 
> []
> 
> > +	dev_vdbg(&mcde_dev->dev, "%s\n", __func__);
> 
> If your dev_<level> logging messages use "%s", __func__
> I suggest you use a set of local macros to preface this.
> 
> I don't generally find the function name useful.
> 
> Maybe only use the %s __func__ pair when you are also
> setting verbose debugging.
Alright, will add some local macros for this.

> 
> #ifdef VERBOSE_DEBUG
> #define mcde_printk(level, dev, fmt, args) \
> 	dev_printk(level, dev, "%s: " fmt, __func__, ##args)
> #else
> #define mcde_printk(level, dev, fmt, args) \
> 	dev_printk(level, dev, fmt, args)
> #endif
> 
> #ifdef VERBOSE_DEBUG
> #define mcde_vdbg(dev, fmt, args) \
> 	mcde_printk(KERN_DEBUG, dev, fmt, ##args)
> #else
> #define mcde_vdbg(dev, fmt, args) \
> 	do { if (0) mcde_printk(KERN_DEBUG, dev, fmt, ##args); }
> while (0)
> #endif
> 
> #ifdef DEBUG
> #define mcde_dbg(dev, fmt, args) \
> 	mcde_printk(KERN_DEBUG, dev, fmt, ##args)
> #else
> #define mcde_dbg(dev, fmt, args) \
> 	do { if (0) mcde_printk(KERN_DEBUG, dev, fmt, ##args); }
> while (0)
> #endif
> 
> #define mcde_ERR(dev, fmt, args) \
> 	mcde_printk(KERN_ERR, dev, fmt, ##args)
> #define mcde_warn(dev, fmt, args) \
> 	mcde_printk(KERN_WARNING, dev, fmt, ##args)
> #define mcde_info(dev, fmt, args) \
> 	mcde_printk(KERN_INFO, dev, fmt, ##args)
> 
> > +static void disable_channel(struct mcde_chnl_state *chnl)
> > +{
> > +	int i;
> > +	const struct mcde_port *port = &chnl->port;
> > +
> > +	dev_vdbg(&mcde_dev->dev, "%s\n", __func__);
> > +
> > +	if (hardware_version == MCDE_CHIP_VERSION_3_0_8 &&
> > +				!is_channel_enabled(chnl))
> {
> > +		chnl->continous_running = false;
> 
> It'd be nice to change to continuous_running

Continous_running is normally set to true when a chnl_update is performed.
In disable channel continous_running must be set to false in order to get the hw registers updated in the next chnl_update.

> 
> > +int mcde_dsi_dcs_write(struct mcde_chnl_state *chnl, u8 cmd, u8*
> data, int len)
> > +{
> > +	int i;
> > +	u32 wrdat[4] = { 0, 0, 0, 0 };
> > +	u32 settings;
> > +	u8 link = chnl->port.link;
> > +	u8 virt_id = chnl->port.phy.dsi.virt_id;
> > +
> > +	/* REVIEW: One command at a time */
> > +	/* REVIEW: Allow read/write on unreserved ports */
> > +	if (len > MCDE_MAX_DCS_WRITE || chnl->port.type !=
> MCDE_PORTTYPE_DSI)
> > +		return -EINVAL;
> > +
> > +	wrdat[0] = cmd;
> > +	for (i = 1; i <= len; i++)
> > +		wrdat[i>>2] |= ((u32)data[i-1] << ((i & 3) * 8));
> 
> Ever overrun wrdat?
> Maybe WARN_ON(len > 16, "oops?")
> 
MCDE_MAX_DCS_WRITE is 15 so it will be an early return in that case.

/Jimmy

WARNING: multiple messages have this Message-ID (diff)
From: Jimmy RUBIN <jimmy.rubin@stericsson.com>
To: linux-arm-kernel@lists.infradead.org
Subject: RE: [PATCH 01/10] MCDE: Add hardware abstraction layer
Date: Mon, 15 Nov 2010 09:52:55 +0000	[thread overview]
Message-ID: <F45880696056844FA6A73F415B568C6953604E7105@EXDCVYMBSTM006.EQ1STM.local> (raw)
In-Reply-To: <1289409276.15905.65.camel@Joe-Laptop>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 4067 bytes --]

Hi Joe,

Thanks for your input.
See comments below.
 
> Just trivia:
> 
> > diff --git a/drivers/video/mcde/mcde_hw.c
> b/drivers/video/mcde/mcde_hw.c
> 
> []
> 
> > +#define dsi_rfld(__i, __reg, __fld) \
> > +	((dsi_rreg(__i, __reg) & __reg##_##__fld##_MASK) >> \
> > +		__reg##_##__fld##_SHIFT)
> > +#define dsi_wfld(__i, __reg, __fld, __val) \
> > +	dsi_wreg(__i, __reg, (dsi_rreg(__i, __reg) & \
> > +	~__reg##_##__fld##_MASK) | (((__val) <<
> __reg##_##__fld##_SHIFT) & \
> > +		 __reg##_##__fld##_MASK))
> 
> These macros are not particularly readable.
> Perhaps use statement expression macros like:
> 
> #define dsi_rfld(__i, __reg, __fld)
> 		\
> ({
> 			\
> 	const u32 mask = __reg##_#__fld##_MASK;
> 		\
> 	const u32 shift = __reg##_##__fld##_SHIFT;
> 	\
> 	((dsi_rreg(__i, __reg) & mask) >> shift;
> 	\
> })
> 
> #define dsi_wfld(__i, __reg, __fld, __val)
> 	\
> ({
> 			\
> 	const u32 mask = __reg##_#__fld##_MASK;
> 		\
> 	const u32 shift = __reg##_##__fld##_SHIFT;
> 	\
> 	dsi_wreg(__i, __reg,
> 		\
> 		 (dsi_rreg(__i, __reg) & ~mask) | (((__val) <<
> shift) & mask));\
> })

I agree, more readable.
> 
> > +static struct mcde_chnl_state channels[] = {
> 
> Should more static structs be static const?

I think so, we got some strange behavior when we changed the structs to static const. But we will investigate it.

> 
> []
> 
> > +	dev_vdbg(&mcde_dev->dev, "%s\n", __func__);
> 
> If your dev_<level> logging messages use "%s", __func__
> I suggest you use a set of local macros to preface this.
> 
> I don't generally find the function name useful.
> 
> Maybe only use the %s __func__ pair when you are also
> setting verbose debugging.
Alright, will add some local macros for this.

> 
> #ifdef VERBOSE_DEBUG
> #define mcde_printk(level, dev, fmt, args) \
> 	dev_printk(level, dev, "%s: " fmt, __func__, ##args)
> #else
> #define mcde_printk(level, dev, fmt, args) \
> 	dev_printk(level, dev, fmt, args)
> #endif
> 
> #ifdef VERBOSE_DEBUG
> #define mcde_vdbg(dev, fmt, args) \
> 	mcde_printk(KERN_DEBUG, dev, fmt, ##args)
> #else
> #define mcde_vdbg(dev, fmt, args) \
> 	do { if (0) mcde_printk(KERN_DEBUG, dev, fmt, ##args); }
> while (0)
> #endif
> 
> #ifdef DEBUG
> #define mcde_dbg(dev, fmt, args) \
> 	mcde_printk(KERN_DEBUG, dev, fmt, ##args)
> #else
> #define mcde_dbg(dev, fmt, args) \
> 	do { if (0) mcde_printk(KERN_DEBUG, dev, fmt, ##args); }
> while (0)
> #endif
> 
> #define mcde_ERR(dev, fmt, args) \
> 	mcde_printk(KERN_ERR, dev, fmt, ##args)
> #define mcde_warn(dev, fmt, args) \
> 	mcde_printk(KERN_WARNING, dev, fmt, ##args)
> #define mcde_info(dev, fmt, args) \
> 	mcde_printk(KERN_INFO, dev, fmt, ##args)
> 
> > +static void disable_channel(struct mcde_chnl_state *chnl)
> > +{
> > +	int i;
> > +	const struct mcde_port *port = &chnl->port;
> > +
> > +	dev_vdbg(&mcde_dev->dev, "%s\n", __func__);
> > +
> > +	if (hardware_version = MCDE_CHIP_VERSION_3_0_8 &&
> > +				!is_channel_enabled(chnl))
> {
> > +		chnl->continous_running = false;
> 
> It'd be nice to change to continuous_running

Continous_running is normally set to true when a chnl_update is performed.
In disable channel continous_running must be set to false in order to get the hw registers updated in the next chnl_update.

> 
> > +int mcde_dsi_dcs_write(struct mcde_chnl_state *chnl, u8 cmd, u8*
> data, int len)
> > +{
> > +	int i;
> > +	u32 wrdat[4] = { 0, 0, 0, 0 };
> > +	u32 settings;
> > +	u8 link = chnl->port.link;
> > +	u8 virt_id = chnl->port.phy.dsi.virt_id;
> > +
> > +	/* REVIEW: One command at a time */
> > +	/* REVIEW: Allow read/write on unreserved ports */
> > +	if (len > MCDE_MAX_DCS_WRITE || chnl->port.type !> MCDE_PORTTYPE_DSI)
> > +		return -EINVAL;
> > +
> > +	wrdat[0] = cmd;
> > +	for (i = 1; i <= len; i++)
> > +		wrdat[i>>2] |= ((u32)data[i-1] << ((i & 3) * 8));
> 
> Ever overrun wrdat?
> Maybe WARN_ON(len > 16, "oops?")
> 
MCDE_MAX_DCS_WRITE is 15 so it will be an early return in that case.

/Jimmy
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ýöÝzÿâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm

WARNING: multiple messages have this Message-ID (diff)
From: jimmy.rubin@stericsson.com (Jimmy RUBIN)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 01/10] MCDE: Add hardware abstraction layer
Date: Mon, 15 Nov 2010 10:52:55 +0100	[thread overview]
Message-ID: <F45880696056844FA6A73F415B568C6953604E7105@EXDCVYMBSTM006.EQ1STM.local> (raw)
In-Reply-To: <1289409276.15905.65.camel@Joe-Laptop>

Hi Joe,

Thanks for your input.
See comments below.
 
> Just trivia:
> 
> > diff --git a/drivers/video/mcde/mcde_hw.c
> b/drivers/video/mcde/mcde_hw.c
> 
> []
> 
> > +#define dsi_rfld(__i, __reg, __fld) \
> > +	((dsi_rreg(__i, __reg) & __reg##_##__fld##_MASK) >> \
> > +		__reg##_##__fld##_SHIFT)
> > +#define dsi_wfld(__i, __reg, __fld, __val) \
> > +	dsi_wreg(__i, __reg, (dsi_rreg(__i, __reg) & \
> > +	~__reg##_##__fld##_MASK) | (((__val) <<
> __reg##_##__fld##_SHIFT) & \
> > +		 __reg##_##__fld##_MASK))
> 
> These macros are not particularly readable.
> Perhaps use statement expression macros like:
> 
> #define dsi_rfld(__i, __reg, __fld)
> 		\
> ({
> 			\
> 	const u32 mask = __reg##_#__fld##_MASK;
> 		\
> 	const u32 shift = __reg##_##__fld##_SHIFT;
> 	\
> 	((dsi_rreg(__i, __reg) & mask) >> shift;
> 	\
> })
> 
> #define dsi_wfld(__i, __reg, __fld, __val)
> 	\
> ({
> 			\
> 	const u32 mask = __reg##_#__fld##_MASK;
> 		\
> 	const u32 shift = __reg##_##__fld##_SHIFT;
> 	\
> 	dsi_wreg(__i, __reg,
> 		\
> 		 (dsi_rreg(__i, __reg) & ~mask) | (((__val) <<
> shift) & mask));\
> })

I agree, more readable.
> 
> > +static struct mcde_chnl_state channels[] = {
> 
> Should more static structs be static const?

I think so, we got some strange behavior when we changed the structs to static const. But we will investigate it.

> 
> []
> 
> > +	dev_vdbg(&mcde_dev->dev, "%s\n", __func__);
> 
> If your dev_<level> logging messages use "%s", __func__
> I suggest you use a set of local macros to preface this.
> 
> I don't generally find the function name useful.
> 
> Maybe only use the %s __func__ pair when you are also
> setting verbose debugging.
Alright, will add some local macros for this.

> 
> #ifdef VERBOSE_DEBUG
> #define mcde_printk(level, dev, fmt, args) \
> 	dev_printk(level, dev, "%s: " fmt, __func__, ##args)
> #else
> #define mcde_printk(level, dev, fmt, args) \
> 	dev_printk(level, dev, fmt, args)
> #endif
> 
> #ifdef VERBOSE_DEBUG
> #define mcde_vdbg(dev, fmt, args) \
> 	mcde_printk(KERN_DEBUG, dev, fmt, ##args)
> #else
> #define mcde_vdbg(dev, fmt, args) \
> 	do { if (0) mcde_printk(KERN_DEBUG, dev, fmt, ##args); }
> while (0)
> #endif
> 
> #ifdef DEBUG
> #define mcde_dbg(dev, fmt, args) \
> 	mcde_printk(KERN_DEBUG, dev, fmt, ##args)
> #else
> #define mcde_dbg(dev, fmt, args) \
> 	do { if (0) mcde_printk(KERN_DEBUG, dev, fmt, ##args); }
> while (0)
> #endif
> 
> #define mcde_ERR(dev, fmt, args) \
> 	mcde_printk(KERN_ERR, dev, fmt, ##args)
> #define mcde_warn(dev, fmt, args) \
> 	mcde_printk(KERN_WARNING, dev, fmt, ##args)
> #define mcde_info(dev, fmt, args) \
> 	mcde_printk(KERN_INFO, dev, fmt, ##args)
> 
> > +static void disable_channel(struct mcde_chnl_state *chnl)
> > +{
> > +	int i;
> > +	const struct mcde_port *port = &chnl->port;
> > +
> > +	dev_vdbg(&mcde_dev->dev, "%s\n", __func__);
> > +
> > +	if (hardware_version == MCDE_CHIP_VERSION_3_0_8 &&
> > +				!is_channel_enabled(chnl))
> {
> > +		chnl->continous_running = false;
> 
> It'd be nice to change to continuous_running

Continous_running is normally set to true when a chnl_update is performed.
In disable channel continous_running must be set to false in order to get the hw registers updated in the next chnl_update.

> 
> > +int mcde_dsi_dcs_write(struct mcde_chnl_state *chnl, u8 cmd, u8*
> data, int len)
> > +{
> > +	int i;
> > +	u32 wrdat[4] = { 0, 0, 0, 0 };
> > +	u32 settings;
> > +	u8 link = chnl->port.link;
> > +	u8 virt_id = chnl->port.phy.dsi.virt_id;
> > +
> > +	/* REVIEW: One command at a time */
> > +	/* REVIEW: Allow read/write on unreserved ports */
> > +	if (len > MCDE_MAX_DCS_WRITE || chnl->port.type !=
> MCDE_PORTTYPE_DSI)
> > +		return -EINVAL;
> > +
> > +	wrdat[0] = cmd;
> > +	for (i = 1; i <= len; i++)
> > +		wrdat[i>>2] |= ((u32)data[i-1] << ((i & 3) * 8));
> 
> Ever overrun wrdat?
> Maybe WARN_ON(len > 16, "oops?")
> 
MCDE_MAX_DCS_WRITE is 15 so it will be an early return in that case.

/Jimmy

  reply	other threads:[~2010-11-15  9:53 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 [this message]
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
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=F45880696056844FA6A73F415B568C6953604E7105@EXDCVYMBSTM006.EQ1STM.local \
    --to=jimmy.rubin@stericsson.com \
    --cc=dan.johansson@stericsson.com \
    --cc=joe@perches.com \
    --cc=linus.walleij@stericsson.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-media@vger.kernel.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.