diff for duplicates of <20101214084024.GS6017@pengutronix.de> diff --git a/a/1.txt b/N1/1.txt index 7353ac8..a3b71df 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -20,7 +20,7 @@ On Tue, Dec 14, 2010 at 12:05:07PM +0800, Liu Ying wrote: > >> > >> I have the following comments for the files editted respectively: > >> 1) ipu-common.c -> >> - ipu_idmac_get()/ipu_idmac_put() need a mechanism to protect IPU +> >> ? ? - ipu_idmac_get()/ipu_idmac_put() need a mechanism to protect IPU > >> IDMAC resources, namely, get rid of potential race condition issue. As > >> only framebuffer support is added in your patches, there should be no > >> race condition issue now. After IC channels are supported(maybe as DMA @@ -28,21 +28,21 @@ On Tue, Dec 14, 2010 at 12:05:07PM +0800, Liu Ying wrote: > > > > ok. > > -> >> - ipu_idmac_select_buffer() need to add spinlock to protect +> >> ? ? - ipu_idmac_select_buffer() need to add spinlock to protect > >> IPU_CHA_BUFx_RDY registers. > > > > ok. > > -> >> - It looks that ipu_uninit_channel() only clears +> >> ? ? - It looks that ipu_uninit_channel() only clears > >> IPU_CHA_DB_MODE_SEL register, so why not put it in > >> ipu_idmac_disable_channel()? > > > > ok. > > -> >> - It looks that ipu_add_client_devices() and your framebuffer +> >> ? ? - It looks that ipu_add_client_devices() and your framebuffer > >> patch assume /dev/fb0 uses DP_BG, /dev/fb1 uses DP_FG and /dev/fb2 > >> uses DC. -> >> But fb1_platform_data->ipu_channel_bg is +> >> ? ? ? But fb1_platform_data->ipu_channel_bg is > >> MX51_IPU_CHANNEL_MEM_DC_SYNC, this may make confusion for driver > >> readers and it is not easy for code maintenance. > > @@ -51,9 +51,9 @@ On Tue, Dec 14, 2010 at 12:05:07PM +0800, Liu Ying wrote: > [LY] How about assigning DP-BG to /dev/fb0, DC to /dev/fb1 and DP_FG > to /dev/fb2? > > -> >> - It also looks that ipu_add_client_devices() and your framebuffer +> >> ? ? - It also looks that ipu_add_client_devices() and your framebuffer > >> driver assume DP_BG/DP_FG are bound with DI0 and DC is bound with DI1. -> >> It is ok for babbage board to support this kind of +> >> ? ? ? It is ok for babbage board to support this kind of > >> configuration, but it may bring some limitation. For example, TVE(TV > >> encoder) module embedded in MX51 SoC can only connected with DI1 and > >> users may like to use TV as the primary device(support HW overlay), @@ -72,7 +72,7 @@ Ok, I'll find a solution for this. > > > >> > >> 2) ipu-cpmem.c -> >> - In order to improve performance, maybe writing +> >> ? ? - In order to improve performance, maybe writing > >> ipu_ch_param_addr(ch) directly will be fine, but not using memset() > >> and memcpy() in ipu_ch_param_init(). > > @@ -90,36 +90,36 @@ something memset. > > > >> > >> 3) ipu-dc.c -> >> - Looks '#include <asm/atomic.h>' and '#include +> >> ? ? - Looks '#include <asm/atomic.h>' and '#include > >> <linux/spinlock.h>' are unnecessary. -> >> - Need to call 'ipu_module_disable(IPU_CONF_DC_EN);' somewhere. +> >> ? ? - Need to call 'ipu_module_disable(IPU_CONF_DC_EN);' somewhere. > > > > ok. > > > >> > >> 4) ipu-di.c -> >> - Looks '#include <asm/atomic.h>' and '#include <linux/delay.h>' +> >> ? ? - Looks '#include <asm/atomic.h>' and '#include <linux/delay.h>' > >> are unnecessary. > > > > ok. > > > >> > >> 5) ipu-dmfc.c -> >> - Looks '#include <linux/delay.h>' are unnecessary. +> >> ? ? - Looks '#include <linux/delay.h>' are unnecessary. > > > > ok. > > > >> > >> 6) ipu-dp.c -> >> - Looks '#include <asm/atomic.h>' and '#include <linux/delay.h>' +> >> ? ? - Looks '#include <asm/atomic.h>' and '#include <linux/delay.h>' > >> are unnecessary. > > > > ok. > > > >> > >> 7) ipu-prv.h -> >> - Looks '#include <linux/interrupt.h>' is unnecessary. -> >> - Please rename 'MX51_IPU_CHANNEL_xxxx' to be 'IPU_CHANNEL_xxxx', +> >> ? ? - Looks '#include <linux/interrupt.h>' is unnecessary. +> >> ? ? - Please rename 'MX51_IPU_CHANNEL_xxxx' to be 'IPU_CHANNEL_xxxx', > >> IPUv3 channel names do not depend on SoC name. > > > > I was proven wrong each time I believed this. diff --git a/a/content_digest b/N1/content_digest index 5ec4388..7e2ac2c 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -3,9 +3,9 @@ "ref\0AANLkTine90yN=e-J_zr03GmGCXekEWTPKv0pB5-EhA1v@mail.gmail.com\0" "ref\020101213112345.GD6017@pengutronix.de\0" "ref\0AANLkTimuchaGAEuGX24GSnAu5-FVtG_kE_KDozGKo9e-@mail.gmail.com\0" - "From\0Sascha Hauer <s.hauer@pengutronix.de>\0" - "Subject\0Re: [PATCH 3/9] Add a mfd IPUv3 driver\0" - "Date\0Tue, 14 Dec 2010 08:40:24 +0000\0" + "From\0s.hauer@pengutronix.de (Sascha Hauer)\0" + "Subject\0[PATCH 3/9] Add a mfd IPUv3 driver\0" + "Date\0Tue, 14 Dec 2010 09:40:24 +0100\0" "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" @@ -31,7 +31,7 @@ "> >>\n" "> >> I have the following comments for the files editted respectively:\n" "> >> 1) ipu-common.c\n" - "> >> \302\240 \302\240 - ipu_idmac_get()/ipu_idmac_put() need a mechanism to protect IPU\n" + "> >> ? ? - ipu_idmac_get()/ipu_idmac_put() need a mechanism to protect IPU\n" "> >> IDMAC resources, namely, get rid of potential race condition issue. As\n" "> >> only framebuffer support is added in your patches, there should be no\n" "> >> race condition issue now. After IC channels are supported(maybe as DMA\n" @@ -39,21 +39,21 @@ "> >\n" "> > ok.\n" "> >\n" - "> >> \302\240 \302\240 - ipu_idmac_select_buffer() need to add spinlock to protect\n" + "> >> ? ? - ipu_idmac_select_buffer() need to add spinlock to protect\n" "> >> IPU_CHA_BUFx_RDY registers.\n" "> >\n" "> > ok.\n" "> >\n" - "> >> \302\240 \302\240 - It looks that ipu_uninit_channel() only clears\n" + "> >> ? ? - It looks that ipu_uninit_channel() only clears\n" "> >> IPU_CHA_DB_MODE_SEL register, so why not put it in\n" "> >> ipu_idmac_disable_channel()?\n" "> >\n" "> > ok.\n" "> >\n" - "> >> \302\240 \302\240 - It looks that ipu_add_client_devices() and your framebuffer\n" + "> >> ? ? - It looks that ipu_add_client_devices() and your framebuffer\n" "> >> patch assume /dev/fb0 uses DP_BG, /dev/fb1 uses DP_FG and /dev/fb2\n" "> >> uses DC.\n" - "> >> \302\240 \302\240 \302\240 But fb1_platform_data->ipu_channel_bg is\n" + "> >> ? ? ? But fb1_platform_data->ipu_channel_bg is\n" "> >> MX51_IPU_CHANNEL_MEM_DC_SYNC, this may make confusion for driver\n" "> >> readers and it is not easy for code maintenance.\n" "> >\n" @@ -62,9 +62,9 @@ "> [LY] How about assigning DP-BG to /dev/fb0, DC to /dev/fb1 and DP_FG\n" "> to /dev/fb2?\n" "> >\n" - "> >> \302\240 \302\240 - It also looks that ipu_add_client_devices() and your framebuffer\n" + "> >> ? ? - It also looks that ipu_add_client_devices() and your framebuffer\n" "> >> driver assume DP_BG/DP_FG are bound with DI0 and DC is bound with DI1.\n" - "> >> \302\240 \302\240 \302\240 It is ok for babbage board to support this kind of\n" + "> >> ? ? ? It is ok for babbage board to support this kind of\n" "> >> configuration, but it may bring some limitation. For example, TVE(TV\n" "> >> encoder) module embedded in MX51 SoC can only connected with DI1 and\n" "> >> users may like to use TV as the primary device(support HW overlay),\n" @@ -83,7 +83,7 @@ "> >\n" "> >>\n" "> >> 2) ipu-cpmem.c\n" - "> >> \302\240 \302\240 - In order to improve performance, maybe writing\n" + "> >> ? ? - In order to improve performance, maybe writing\n" "> >> ipu_ch_param_addr(ch) directly will be fine, but not using memset()\n" "> >> and memcpy() in ipu_ch_param_init().\n" "> >\n" @@ -101,36 +101,36 @@ "> >\n" "> >>\n" "> >> 3) ipu-dc.c\n" - "> >> \302\240 \302\240 - Looks '#include <asm/atomic.h>' and '#include\n" + "> >> ? ? - Looks '#include <asm/atomic.h>' and '#include\n" "> >> <linux/spinlock.h>' are unnecessary.\n" - "> >> \302\240 \302\240 - Need to call 'ipu_module_disable(IPU_CONF_DC_EN);' somewhere.\n" + "> >> ? ? - Need to call 'ipu_module_disable(IPU_CONF_DC_EN);' somewhere.\n" "> >\n" "> > ok.\n" "> >\n" "> >>\n" "> >> 4) ipu-di.c\n" - "> >> \302\240 \302\240 - Looks '#include <asm/atomic.h>' and '#include <linux/delay.h>'\n" + "> >> ? ? - Looks '#include <asm/atomic.h>' and '#include <linux/delay.h>'\n" "> >> are unnecessary.\n" "> >\n" "> > ok.\n" "> >\n" "> >>\n" "> >> 5) ipu-dmfc.c\n" - "> >> \302\240 \302\240 - Looks '#include <linux/delay.h>' are unnecessary.\n" + "> >> ? ? - Looks '#include <linux/delay.h>' are unnecessary.\n" "> >\n" "> > ok.\n" "> >\n" "> >>\n" "> >> 6) ipu-dp.c\n" - "> >> \302\240 \302\240 - Looks '#include <asm/atomic.h>' and '#include <linux/delay.h>'\n" + "> >> ? ? - Looks '#include <asm/atomic.h>' and '#include <linux/delay.h>'\n" "> >> are unnecessary.\n" "> >\n" "> > ok.\n" "> >\n" "> >>\n" "> >> 7) ipu-prv.h\n" - "> >> \302\240 \302\240 - Looks '#include <linux/interrupt.h>' is unnecessary.\n" - "> >> \302\240 \302\240 - Please rename 'MX51_IPU_CHANNEL_xxxx' to be 'IPU_CHANNEL_xxxx',\n" + "> >> ? ? - Looks '#include <linux/interrupt.h>' is unnecessary.\n" + "> >> ? ? - Please rename 'MX51_IPU_CHANNEL_xxxx' to be 'IPU_CHANNEL_xxxx',\n" "> >> IPUv3 channel names do not depend on SoC name.\n" "> >\n" "> > I was proven wrong each time I believed this.\n" @@ -148,4 +148,4 @@ "Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |\n" Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -b8c297f1c4ee702a0218883da6e625eb4a966dff34267dcaa3a9e001b53415a8 +bf1a5f7937c55fd790e1d40185a625ac1547722c335068e11751559b311e3bbe
diff --git a/a/content_digest b/N2/content_digest index 5ec4388..7724454 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -5,8 +5,13 @@ "ref\0AANLkTimuchaGAEuGX24GSnAu5-FVtG_kE_KDozGKo9e-@mail.gmail.com\0" "From\0Sascha Hauer <s.hauer@pengutronix.de>\0" "Subject\0Re: [PATCH 3/9] Add a mfd IPUv3 driver\0" - "Date\0Tue, 14 Dec 2010 08:40:24 +0000\0" - "To\0linux-arm-kernel@lists.infradead.org\0" + "Date\0Tue, 14 Dec 2010 09:40:24 +0100\0" + "To\0Liu Ying <liu.y.victor@gmail.com>\0" + "Cc\0linux-arm-kernel@lists.infradead.org" + linux-kernel@vger.kernel.org + linux-fbdev@vger.kernel.org + Zhang Lily-R58066 <r58066@freescale.com> + " Arnaud Patard <arnaud.patard@rtp-net.org>\0" "\00:1\0" "b\0" "On Tue, Dec 14, 2010 at 12:05:07PM +0800, Liu Ying wrote:\n" @@ -148,4 +153,4 @@ "Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |\n" Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -b8c297f1c4ee702a0218883da6e625eb4a966dff34267dcaa3a9e001b53415a8 +985c1aabf32e35a63978c91203eb58d0d316e58de57a16d122b1999513a68500
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.