[PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
ERROR: __bad_ndelay [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined! Yet, it sounds a bad idea to use ndelay to wait for 100 us for the device to reset. Reported-by: Stephen Rothwell s...@canb.auug.org.au Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c index e51c078360f5..01eeacf28843 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c @@ -23,7 +23,9 @@ void exynos4_jpeg_sw_reset(void __iomem *base) reg = readl(base + EXYNOS4_JPEG_CNTL_REG); writel(reg ~EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); +#ifndef CONFIG_COMPILE_TEST ndelay(10); +#endif writel(reg | EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); } -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
On 09/09/14 16:38, Mauro Carvalho Chehab wrote: ERROR: __bad_ndelay [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined! Yet, it sounds a bad idea to use ndelay to wait for 100 us for the device to reset. Reported-by: Stephen Rothwell s...@canb.auug.org.au Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c index e51c078360f5..01eeacf28843 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c @@ -23,7 +23,9 @@ void exynos4_jpeg_sw_reset(void __iomem *base) reg = readl(base + EXYNOS4_JPEG_CNTL_REG); writel(reg ~EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); +#ifndef CONFIG_COMPILE_TEST ndelay(10); +#endif Wouldn't be a better fix to replace ndelay(10); with udelay(100), rather than sticking in a not so pretty #ifndef ? I guess usleep_range() couldn't simply be used, since exynos4_jpeg_sw_reset() is called with a spinlock held. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
Em Tue, 09 Sep 2014 16:58:58 +0200 Sylwester Nawrocki s.nawro...@samsung.com escreveu: On 09/09/14 16:38, Mauro Carvalho Chehab wrote: ERROR: __bad_ndelay [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined! Yet, it sounds a bad idea to use ndelay to wait for 100 us for the device to reset. Reported-by: Stephen Rothwell s...@canb.auug.org.au Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c index e51c078360f5..01eeacf28843 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c @@ -23,7 +23,9 @@ void exynos4_jpeg_sw_reset(void __iomem *base) reg = readl(base + EXYNOS4_JPEG_CNTL_REG); writel(reg ~EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); +#ifndef CONFIG_COMPILE_TEST ndelay(10); +#endif Wouldn't be a better fix to replace ndelay(10); with udelay(100), rather than sticking in a not so pretty #ifndef ? Works for me. I'll submit a new version. I guess usleep_range() couldn't simply be used, since exynos4_jpeg_sw_reset() is called with a spinlock held. Ok. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
Hi Mauro, Sylwester, On 09/09/2014 05:09 PM, Mauro Carvalho Chehab wrote: Em Tue, 09 Sep 2014 16:58:58 +0200 Sylwester Nawrocki s.nawro...@samsung.com escreveu: On 09/09/14 16:38, Mauro Carvalho Chehab wrote: ERROR: __bad_ndelay [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined! Yet, it sounds a bad idea to use ndelay to wait for 100 us for the device to reset. Reported-by: Stephen Rothwell s...@canb.auug.org.au Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c index e51c078360f5..01eeacf28843 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c @@ -23,7 +23,9 @@ void exynos4_jpeg_sw_reset(void __iomem *base) reg = readl(base + EXYNOS4_JPEG_CNTL_REG); writel(reg ~EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); +#ifndef CONFIG_COMPILE_TEST ndelay(10); +#endif Wouldn't be a better fix to replace ndelay(10); with udelay(100), rather than sticking in a not so pretty #ifndef ? Works for me. I'll submit a new version. I guess usleep_range() couldn't simply be used, since exynos4_jpeg_sw_reset() is called with a spinlock held. Ok. Within few days I will perform some hardware tests, to verify if there is more room for improvement here. Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
On Tuesday 09 September 2014 12:09:36 Mauro Carvalho Chehab wrote: -exynos4.c index e51c078360f5..01eeacf28843 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c @@ -23,7 +23,9 @@ void exynos4_jpeg_sw_reset(void __iomem *base) reg = readl(base + EXYNOS4_JPEG_CNTL_REG); writel(reg ~EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); +#ifndef CONFIG_COMPILE_TEST ndelay(10); +#endif Wouldn't be a better fix to replace ndelay(10); with udelay(100), rather than sticking in a not so pretty #ifndef ? Works for me. I'll submit a new version. New version looks good to me. On a more general level, I would argue that we should not disable code based on COMPILE_TEST. The typical use of this symbol is to make it possible to compile more code, not to change the behavior of code on machines that were able to build it already. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
Em Tue, 09 Sep 2014 19:54:19 +0200 Arnd Bergmann a...@arndb.de escreveu: On Tuesday 09 September 2014 12:09:36 Mauro Carvalho Chehab wrote: -exynos4.c index e51c078360f5..01eeacf28843 100644 --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c @@ -23,7 +23,9 @@ void exynos4_jpeg_sw_reset(void __iomem *base) reg = readl(base + EXYNOS4_JPEG_CNTL_REG); writel(reg ~EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG); +#ifndef CONFIG_COMPILE_TEST ndelay(10); +#endif Wouldn't be a better fix to replace ndelay(10); with udelay(100), rather than sticking in a not so pretty #ifndef ? Works for me. I'll submit a new version. New version looks good to me. On a more general level, I would argue that we should not disable code based on COMPILE_TEST. The typical use of this symbol is to make it possible to compile more code, not to change the behavior of code on machines that were able to build it already. Yeah, agreed as a general concept. In this case, however, it were causing a compilation breakage on X86 (as it generates a non-existing _bad_ndelay() symbol, if the time is bigger than 2). See include/asm-generic/delay.h. Btw, I suspect that the only reason why ndelay(10) causes a compilation breakage is to avoid a big number, as the maximum limit check ndelay() code (2) at asm-generic is identical to the one for udelay(). So, for ndelay, it means 20us, while, for udelay, it means 20ms. Even so, both calls the very same implementation code. Perhaps we should fix it, for both to accept a maximum time of 20ms. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
