* [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
@ 2014-09-09 14:38 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 14:38 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Tony Lindgren, Russell King, Vinod Koul,
Arnd Bergmann, Peter Griffin, Balaji T K, Nishanth Menon,
linux-next, linux-kernel, Stephen Rothwell
We want to be able to COMPILE_TEST the omap1_camera driver.
It compiles fine, but it fails linkediting:
ERROR: "omap_stop_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_start_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_dma_link_lch" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_set_dma_dest_burst_mode" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_set_dma_src_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_request_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_set_dma_transfer_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_set_dma_dest_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_free_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
So, add some stub functions to avoid it.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 6f06f8bc612c..7c8bfdd90a33 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -294,43 +294,24 @@ struct omap_system_dma_plat_info {
extern struct omap_system_dma_plat_info *omap_get_plat_info(void);
extern void omap_set_dma_priority(int lch, int dst_port, int priority);
-extern int omap_request_dma(int dev_id, const char *dev_name,
- void (*callback)(int lch, u16 ch_status, void *data),
- void *data, int *dma_ch);
extern void omap_enable_dma_irq(int ch, u16 irq_bits);
extern void omap_disable_dma_irq(int ch, u16 irq_bits);
-extern void omap_free_dma(int ch);
-extern void omap_start_dma(int lch);
-extern void omap_stop_dma(int lch);
-extern void omap_set_dma_transfer_params(int lch, int data_type,
- int elem_count, int frame_count,
- int sync_mode,
- int dma_trigger, int src_or_dst_synch);
extern void omap_set_dma_color_mode(int lch, enum omap_dma_color_mode mode,
u32 color);
extern void omap_set_dma_write_mode(int lch, enum omap_dma_write_mode mode);
extern void omap_set_dma_channel_mode(int lch, enum omap_dma_channel_mode mode);
-extern void omap_set_dma_src_params(int lch, int src_port, int src_amode,
- unsigned long src_start,
- int src_ei, int src_fi);
extern void omap_set_dma_src_index(int lch, int eidx, int fidx);
extern void omap_set_dma_src_data_pack(int lch, int enable);
extern void omap_set_dma_src_burst_mode(int lch,
enum omap_dma_burst_mode burst_mode);
-extern void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
- unsigned long dest_start,
- int dst_ei, int dst_fi);
extern void omap_set_dma_dest_index(int lch, int eidx, int fidx);
extern void omap_set_dma_dest_data_pack(int lch, int enable);
-extern void omap_set_dma_dest_burst_mode(int lch,
- enum omap_dma_burst_mode burst_mode);
extern void omap_set_dma_params(int lch,
struct omap_dma_channel_params *params);
-extern void omap_dma_link_lch(int lch_head, int lch_queue);
extern void omap_dma_unlink_lch(int lch_head, int lch_queue);
extern int omap_set_dma_callback(int lch,
@@ -356,18 +337,9 @@ extern void omap_dma_disable_irq(int lch);
/* Chaining APIs */
#ifndef CONFIG_ARCH_OMAP1
-extern int omap_request_dma_chain(int dev_id, const char *dev_name,
- void (*callback) (int lch, u16 ch_status,
- void *data),
- int *chain_id, int no_of_chans,
- int chain_mode,
- struct omap_dma_channel_params params);
-extern int omap_free_dma_chain(int chain_id);
extern int omap_dma_chain_a_transfer(int chain_id, int src_start,
int dest_start, int elem_count,
int frame_count, void *callbk_data);
-extern int omap_start_dma_chain_transfers(int chain_id);
-extern int omap_stop_dma_chain_transfers(int chain_id);
extern int omap_get_dma_chain_index(int chain_id, int *ei, int *fi);
extern int omap_get_dma_chain_dst_pos(int chain_id);
extern int omap_get_dma_chain_src_pos(int chain_id);
@@ -377,6 +349,87 @@ extern int omap_modify_dma_chain_params(int chain_id,
extern int omap_dma_chain_status(int chain_id);
#endif
+#ifndef CONFIG_COMPILE_TEST
+extern int omap_request_dma(int dev_id, const char *dev_name,
+ void (*callback)(int lch, u16 ch_status, void *data),
+ void *data, int *dma_ch);
+extern void omap_free_dma(int ch);
+extern void omap_start_dma(int lch);
+extern void omap_stop_dma(int lch);
+extern void omap_set_dma_transfer_params(int lch, int data_type,
+ int elem_count, int frame_count,
+ int sync_mode,
+ int dma_trigger, int src_or_dst_synch);
+extern void omap_set_dma_src_params(int lch, int src_port, int src_amode,
+ unsigned long src_start,
+ int src_ei, int src_fi);
+extern void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
+ unsigned long dest_start,
+ int dst_ei, int dst_fi);
+extern void omap_set_dma_dest_burst_mode(int lch,
+ enum omap_dma_burst_mode burst_mode);
+extern void omap_dma_link_lch(int lch_head, int lch_queue);
+
+#ifndef CONFIG_ARCH_OMAP1
+extern int omap_request_dma_chain(int dev_id, const char *dev_name,
+ void (*callback) (int lch, u16 ch_status,
+ void *data),
+ int *chain_id, int no_of_chans,
+ int chain_mode,
+ struct omap_dma_channel_params params);
+extern int omap_free_dma_chain(int chain_id);
+extern int omap_start_dma_chain_transfers(int chain_id);
+extern int omap_stop_dma_chain_transfers(int chain_id);
+#endif /* CONFIG_ARCH_OMAP1 */
+#else
+ /* Stubs for compile testing some drivers on other archs */
+
+static inline
+int omap_request_dma(int dev_id, const char *dev_name,
+ void (*callback)(int lch, u16 ch_status, void *data),
+ void *data, int *dma_ch) { return 0; }
+
+static inline void omap_free_dma(int ch) {}
+static inline void omap_start_dma(int lch) {}
+static inline void omap_stop_dma(int lch) {}
+
+static inline
+void omap_set_dma_transfer_params(int lch, int data_type,
+ int elem_count, int frame_count,
+ int sync_mode,
+ int dma_trigger, int src_or_dst_synch) {}
+
+static inline
+void omap_set_dma_src_params(int lch, int src_port, int src_amode,
+ unsigned long src_start,
+ int src_ei, int src_fi) {}
+
+static inline
+void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
+ unsigned long dest_start,
+ int dst_ei, int dst_fi) {}
+
+static inline
+void omap_set_dma_dest_burst_mode(int lch,
+ enum omap_dma_burst_mode burst_mode) {}
+
+static inline
+void omap_dma_link_lch(int lch_head, int lch_queue) {}
+
+static inline
+int omap_request_dma_chain(int dev_id, const char *dev_name,
+ void (*callback) (int lch, u16 ch_status,
+ void *data),
+ int *chain_id, int no_of_chans,
+ int chain_mode,
+ struct omap_dma_channel_params params) { return 0; }
+
+static inline int omap_free_dma_chain(int chain_id) { return 0; }
+static inline int omap_start_dma_chain_transfers(int chain_id) { return 0; }
+static inline int omap_stop_dma_chain_transfers(int chain_id) { return 0; }
+
+#endif /* CONFIG_COMPILE_TEST */
+
#if defined(CONFIG_ARCH_OMAP1) && IS_ENABLED(CONFIG_FB_OMAP)
#include <mach/lcd_dma.h>
#else
--
1.9.3
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
@ 2014-09-09 14:38 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 14:38 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Tony Lindgren, Russell King, Vinod Koul,
Arnd Bergmann, Peter Griffin, Balaji T K, Nishanth Menon,
linux-next, linux-kernel, Stephen Rothwell
We want to be able to COMPILE_TEST the omap1_camera driver.
It compiles fine, but it fails linkediting:
ERROR: "omap_stop_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_start_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_dma_link_lch" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_set_dma_dest_burst_mode" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_set_dma_src_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_request_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_set_dma_transfer_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_set_dma_dest_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_free_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
So, add some stub functions to avoid it.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 6f06f8bc612c..7c8bfdd90a33 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -294,43 +294,24 @@ struct omap_system_dma_plat_info {
extern struct omap_system_dma_plat_info *omap_get_plat_info(void);
extern void omap_set_dma_priority(int lch, int dst_port, int priority);
-extern int omap_request_dma(int dev_id, const char *dev_name,
- void (*callback)(int lch, u16 ch_status, void *data),
- void *data, int *dma_ch);
extern void omap_enable_dma_irq(int ch, u16 irq_bits);
extern void omap_disable_dma_irq(int ch, u16 irq_bits);
-extern void omap_free_dma(int ch);
-extern void omap_start_dma(int lch);
-extern void omap_stop_dma(int lch);
-extern void omap_set_dma_transfer_params(int lch, int data_type,
- int elem_count, int frame_count,
- int sync_mode,
- int dma_trigger, int src_or_dst_synch);
extern void omap_set_dma_color_mode(int lch, enum omap_dma_color_mode mode,
u32 color);
extern void omap_set_dma_write_mode(int lch, enum omap_dma_write_mode mode);
extern void omap_set_dma_channel_mode(int lch, enum omap_dma_channel_mode mode);
-extern void omap_set_dma_src_params(int lch, int src_port, int src_amode,
- unsigned long src_start,
- int src_ei, int src_fi);
extern void omap_set_dma_src_index(int lch, int eidx, int fidx);
extern void omap_set_dma_src_data_pack(int lch, int enable);
extern void omap_set_dma_src_burst_mode(int lch,
enum omap_dma_burst_mode burst_mode);
-extern void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
- unsigned long dest_start,
- int dst_ei, int dst_fi);
extern void omap_set_dma_dest_index(int lch, int eidx, int fidx);
extern void omap_set_dma_dest_data_pack(int lch, int enable);
-extern void omap_set_dma_dest_burst_mode(int lch,
- enum omap_dma_burst_mode burst_mode);
extern void omap_set_dma_params(int lch,
struct omap_dma_channel_params *params);
-extern void omap_dma_link_lch(int lch_head, int lch_queue);
extern void omap_dma_unlink_lch(int lch_head, int lch_queue);
extern int omap_set_dma_callback(int lch,
@@ -356,18 +337,9 @@ extern void omap_dma_disable_irq(int lch);
/* Chaining APIs */
#ifndef CONFIG_ARCH_OMAP1
-extern int omap_request_dma_chain(int dev_id, const char *dev_name,
- void (*callback) (int lch, u16 ch_status,
- void *data),
- int *chain_id, int no_of_chans,
- int chain_mode,
- struct omap_dma_channel_params params);
-extern int omap_free_dma_chain(int chain_id);
extern int omap_dma_chain_a_transfer(int chain_id, int src_start,
int dest_start, int elem_count,
int frame_count, void *callbk_data);
-extern int omap_start_dma_chain_transfers(int chain_id);
-extern int omap_stop_dma_chain_transfers(int chain_id);
extern int omap_get_dma_chain_index(int chain_id, int *ei, int *fi);
extern int omap_get_dma_chain_dst_pos(int chain_id);
extern int omap_get_dma_chain_src_pos(int chain_id);
@@ -377,6 +349,87 @@ extern int omap_modify_dma_chain_params(int chain_id,
extern int omap_dma_chain_status(int chain_id);
#endif
+#ifndef CONFIG_COMPILE_TEST
+extern int omap_request_dma(int dev_id, const char *dev_name,
+ void (*callback)(int lch, u16 ch_status, void *data),
+ void *data, int *dma_ch);
+extern void omap_free_dma(int ch);
+extern void omap_start_dma(int lch);
+extern void omap_stop_dma(int lch);
+extern void omap_set_dma_transfer_params(int lch, int data_type,
+ int elem_count, int frame_count,
+ int sync_mode,
+ int dma_trigger, int src_or_dst_synch);
+extern void omap_set_dma_src_params(int lch, int src_port, int src_amode,
+ unsigned long src_start,
+ int src_ei, int src_fi);
+extern void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
+ unsigned long dest_start,
+ int dst_ei, int dst_fi);
+extern void omap_set_dma_dest_burst_mode(int lch,
+ enum omap_dma_burst_mode burst_mode);
+extern void omap_dma_link_lch(int lch_head, int lch_queue);
+
+#ifndef CONFIG_ARCH_OMAP1
+extern int omap_request_dma_chain(int dev_id, const char *dev_name,
+ void (*callback) (int lch, u16 ch_status,
+ void *data),
+ int *chain_id, int no_of_chans,
+ int chain_mode,
+ struct omap_dma_channel_params params);
+extern int omap_free_dma_chain(int chain_id);
+extern int omap_start_dma_chain_transfers(int chain_id);
+extern int omap_stop_dma_chain_transfers(int chain_id);
+#endif /* CONFIG_ARCH_OMAP1 */
+#else
+ /* Stubs for compile testing some drivers on other archs */
+
+static inline
+int omap_request_dma(int dev_id, const char *dev_name,
+ void (*callback)(int lch, u16 ch_status, void *data),
+ void *data, int *dma_ch) { return 0; }
+
+static inline void omap_free_dma(int ch) {}
+static inline void omap_start_dma(int lch) {}
+static inline void omap_stop_dma(int lch) {}
+
+static inline
+void omap_set_dma_transfer_params(int lch, int data_type,
+ int elem_count, int frame_count,
+ int sync_mode,
+ int dma_trigger, int src_or_dst_synch) {}
+
+static inline
+void omap_set_dma_src_params(int lch, int src_port, int src_amode,
+ unsigned long src_start,
+ int src_ei, int src_fi) {}
+
+static inline
+void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
+ unsigned long dest_start,
+ int dst_ei, int dst_fi) {}
+
+static inline
+void omap_set_dma_dest_burst_mode(int lch,
+ enum omap_dma_burst_mode burst_mode) {}
+
+static inline
+void omap_dma_link_lch(int lch_head, int lch_queue) {}
+
+static inline
+int omap_request_dma_chain(int dev_id, const char *dev_name,
+ void (*callback) (int lch, u16 ch_status,
+ void *data),
+ int *chain_id, int no_of_chans,
+ int chain_mode,
+ struct omap_dma_channel_params params) { return 0; }
+
+static inline int omap_free_dma_chain(int chain_id) { return 0; }
+static inline int omap_start_dma_chain_transfers(int chain_id) { return 0; }
+static inline int omap_stop_dma_chain_transfers(int chain_id) { return 0; }
+
+#endif /* CONFIG_COMPILE_TEST */
+
#if defined(CONFIG_ARCH_OMAP1) && IS_ENABLED(CONFIG_FB_OMAP)
#include <mach/lcd_dma.h>
#else
--
1.9.3
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
2014-09-09 14:38 ` Mauro Carvalho Chehab
(?)
(?)
@ 2014-09-09 14:38 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 14:38 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Kukjin Kim, Jacek Anaszewski,
Kamil Debski, Kyungmin Park, Sylwester Nawrocki,
linux-arm-kernel, linux-samsung-soc, linux-next, linux-kernel,
Stephen Rothwell
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 <sfr@canb.auug.org.au>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@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(100000);
+#endif
writel(reg | EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG);
}
--
1.9.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
@ 2014-09-09 14:38 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 14:38 UTC (permalink / raw)
To: linux-arm-kernel
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 <sfr@canb.auug.org.au>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@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(100000);
+#endif
writel(reg | EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG);
}
--
1.9.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
@ 2014-09-09 14:38 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 14:38 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Kukjin Kim, Jacek Anaszewski,
Kamil Debski, Kyungmin Park, Sylwester Nawrocki,
linux-arm-kernel, linux-samsung-soc, linux-next, linux-kernel,
Stephen Rothwell
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 <sfr@canb.auug.org.au>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@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(100000);
+#endif
writel(reg | EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG);
}
--
1.9.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
@ 2014-09-09 14:38 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 14:38 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Kukjin Kim, Jacek Anaszewski,
Kamil Debski, Kyungmin Park, Sylwester Nawrocki,
linux-arm-kernel, linux-samsung-soc, linux-next, linux-kernel,
Stephen Rothwell
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 <sfr@canb.auug.org.au>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@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(100000);
+#endif
writel(reg | EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG);
}
--
1.9.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* Re: [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
2014-09-09 14:38 ` Mauro Carvalho Chehab
@ 2014-09-09 14:58 ` Sylwester Nawrocki
-1 siblings, 0 replies; 54+ messages in thread
From: Sylwester Nawrocki @ 2014-09-09 14:58 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, Kukjin Kim,
Jacek Anaszewski, Kamil Debski, Kyungmin Park, linux-arm-kernel,
linux-samsung-soc, linux-next, linux-kernel, Stephen Rothwell
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 <sfr@canb.auug.org.au>
> Signed-off-by: Mauro Carvalho Chehab <m.chehab@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(100000);
> +#endif
Wouldn't be a better fix to replace ndelay(100000); 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
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
@ 2014-09-09 14:58 ` Sylwester Nawrocki
0 siblings, 0 replies; 54+ messages in thread
From: Sylwester Nawrocki @ 2014-09-09 14:58 UTC (permalink / raw)
To: linux-arm-kernel
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 <sfr@canb.auug.org.au>
> Signed-off-by: Mauro Carvalho Chehab <m.chehab@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(100000);
> +#endif
Wouldn't be a better fix to replace ndelay(100000); 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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
2014-09-09 14:58 ` Sylwester Nawrocki
@ 2014-09-09 15:09 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 15:09 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, Kukjin Kim,
Jacek Anaszewski, Kamil Debski, Kyungmin Park, linux-arm-kernel,
linux-samsung-soc, linux-next, linux-kernel, Stephen Rothwell
Em Tue, 09 Sep 2014 16:58:58 +0200
Sylwester Nawrocki <s.nawrocki@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 <sfr@canb.auug.org.au>
> > Signed-off-by: Mauro Carvalho Chehab <m.chehab@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(100000);
> > +#endif
>
> Wouldn't be a better fix to replace ndelay(100000); 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
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
@ 2014-09-09 15:09 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 15:09 UTC (permalink / raw)
To: linux-arm-kernel
Em Tue, 09 Sep 2014 16:58:58 +0200
Sylwester Nawrocki <s.nawrocki@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 <sfr@canb.auug.org.au>
> > Signed-off-by: Mauro Carvalho Chehab <m.chehab@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(100000);
> > +#endif
>
> Wouldn't be a better fix to replace ndelay(100000); 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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
2014-09-09 15:09 ` Mauro Carvalho Chehab
@ 2014-09-09 15:30 ` Jacek Anaszewski
-1 siblings, 0 replies; 54+ messages in thread
From: Jacek Anaszewski @ 2014-09-09 15:30 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Sylwester Nawrocki, Linux Media Mailing List,
Mauro Carvalho Chehab, Kukjin Kim, Kamil Debski, Kyungmin Park,
linux-arm-kernel, linux-samsung-soc, linux-next, linux-kernel,
Stephen Rothwell
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.nawrocki@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 <sfr@canb.auug.org.au>
>>> Signed-off-by: Mauro Carvalho Chehab <m.chehab@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(100000);
>>> +#endif
>>
>> Wouldn't be a better fix to replace ndelay(100000); 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
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
@ 2014-09-09 15:30 ` Jacek Anaszewski
0 siblings, 0 replies; 54+ messages in thread
From: Jacek Anaszewski @ 2014-09-09 15:30 UTC (permalink / raw)
To: linux-arm-kernel
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.nawrocki@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 <sfr@canb.auug.org.au>
>>> Signed-off-by: Mauro Carvalho Chehab <m.chehab@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(100000);
>>> +#endif
>>
>> Wouldn't be a better fix to replace ndelay(100000); 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
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCHv2 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
2014-09-09 15:30 ` Jacek Anaszewski
@ 2014-09-09 16:10 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 16:10 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: Jacek Anaszewski, Linux Media Mailing List,
Mauro Carvalho Chehab, Kukjin Kim, Kamil Debski, Kyungmin Park,
linux-arm-kernel, linux-samsung-soc, linux-next, linux-kernel,
Stephen Rothwell
ERROR: "__bad_ndelay" [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined!
That happens because asm-generic doesn't like any ndelay time
bigger than 20us.
Currently, usleep_range() couldn't simply be used, since
exynos4_jpeg_sw_reset() is called with a spinlock held.
So, let's use ndelay() instead.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@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..ab6d6f43c96f 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
@@ -23,7 +23,7 @@ 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);
- ndelay(100000);
+ udelay(100);
writel(reg | EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG);
}
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCHv2 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
@ 2014-09-09 16:10 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 16:10 UTC (permalink / raw)
To: linux-arm-kernel
ERROR: "__bad_ndelay" [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined!
That happens because asm-generic doesn't like any ndelay time
bigger than 20us.
Currently, usleep_range() couldn't simply be used, since
exynos4_jpeg_sw_reset() is called with a spinlock held.
So, let's use ndelay() instead.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@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..ab6d6f43c96f 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
@@ -23,7 +23,7 @@ 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);
- ndelay(100000);
+ udelay(100);
writel(reg | EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG);
}
^ permalink raw reply related [flat|nested] 54+ messages in thread
* Re: [PATCHv2 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
2014-09-09 16:10 ` Mauro Carvalho Chehab
@ 2014-09-09 17:10 ` Sylwester Nawrocki
-1 siblings, 0 replies; 54+ messages in thread
From: Sylwester Nawrocki @ 2014-09-09 17:10 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Jacek Anaszewski, Linux Media Mailing List,
Mauro Carvalho Chehab, Kukjin Kim, Kamil Debski, Kyungmin Park,
linux-arm-kernel, linux-samsung-soc, linux-next, linux-kernel,
Stephen Rothwell
On 09/09/14 18:10, Mauro Carvalho Chehab wrote:
> ERROR: "__bad_ndelay" [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined!
>
> That happens because asm-generic doesn't like any ndelay time
> bigger than 20us.
>
> Currently, usleep_range() couldn't simply be used, since
> exynos4_jpeg_sw_reset() is called with a spinlock held.
>
> So, let's use ndelay() instead.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
--
Thanks,
Sylwester
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCHv2 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
@ 2014-09-09 17:10 ` Sylwester Nawrocki
0 siblings, 0 replies; 54+ messages in thread
From: Sylwester Nawrocki @ 2014-09-09 17:10 UTC (permalink / raw)
To: linux-arm-kernel
On 09/09/14 18:10, Mauro Carvalho Chehab wrote:
> ERROR: "__bad_ndelay" [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined!
>
> That happens because asm-generic doesn't like any ndelay time
> bigger than 20us.
>
> Currently, usleep_range() couldn't simply be used, since
> exynos4_jpeg_sw_reset() is called with a spinlock held.
>
> So, let's use ndelay() instead.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
--
Thanks,
Sylwester
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCHv2 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
2014-09-09 16:10 ` Mauro Carvalho Chehab
(?)
@ 2014-09-09 17:19 ` Fabio Estevam
-1 siblings, 0 replies; 54+ messages in thread
From: Fabio Estevam @ 2014-09-09 17:19 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Sylwester Nawrocki, Jacek Anaszewski, Linux Media Mailing List,
Mauro Carvalho Chehab, Kukjin Kim, Kamil Debski, Kyungmin Park,
linux-arm-kernel, linux-samsung-soc, linux-next, linux-kernel,
Stephen Rothwell
On Tue, Sep 9, 2014 at 1:10 PM, Mauro Carvalho Chehab
<m.chehab@samsung.com> wrote:
> ERROR: "__bad_ndelay" [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined!
>
> That happens because asm-generic doesn't like any ndelay time
> bigger than 20us.
>
> Currently, usleep_range() couldn't simply be used, since
> exynos4_jpeg_sw_reset() is called with a spinlock held.
>
> So, let's use ndelay() instead.
You meant 'udelay() instead'.
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCHv2 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
@ 2014-09-09 17:19 ` Fabio Estevam
0 siblings, 0 replies; 54+ messages in thread
From: Fabio Estevam @ 2014-09-09 17:19 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 9, 2014 at 1:10 PM, Mauro Carvalho Chehab
<m.chehab@samsung.com> wrote:
> ERROR: "__bad_ndelay" [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined!
>
> That happens because asm-generic doesn't like any ndelay time
> bigger than 20us.
>
> Currently, usleep_range() couldn't simply be used, since
> exynos4_jpeg_sw_reset() is called with a spinlock held.
>
> So, let's use ndelay() instead.
You meant 'udelay() instead'.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCHv2 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
@ 2014-09-09 17:19 ` Fabio Estevam
0 siblings, 0 replies; 54+ messages in thread
From: Fabio Estevam @ 2014-09-09 17:19 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Sylwester Nawrocki, Jacek Anaszewski, Linux Media Mailing List,
Mauro Carvalho Chehab, Kukjin Kim, Kamil Debski, Kyungmin Park,
linux-arm-kernel, linux-samsung-soc, linux-next, linux-kernel,
Stephen Rothwell
On Tue, Sep 9, 2014 at 1:10 PM, Mauro Carvalho Chehab
<m.chehab@samsung.com> wrote:
> ERROR: "__bad_ndelay" [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined!
>
> That happens because asm-generic doesn't like any ndelay time
> bigger than 20us.
>
> Currently, usleep_range() couldn't simply be used, since
> exynos4_jpeg_sw_reset() is called with a spinlock held.
>
> So, let's use ndelay() instead.
You meant 'udelay() instead'.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
2014-09-09 15:09 ` Mauro Carvalho Chehab
(?)
@ 2014-09-09 17:54 ` Arnd Bergmann
-1 siblings, 0 replies; 54+ messages in thread
From: Arnd Bergmann @ 2014-09-09 17:54 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mauro Carvalho Chehab, Sylwester Nawrocki, Stephen Rothwell,
Kamil Debski, Kukjin Kim, linux-kernel, Mauro Carvalho Chehab,
Kyungmin Park, linux-samsung-soc, linux-next, Jacek Anaszewski,
Linux Media Mailing List
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(100000);
> > > +#endif
> >
> > Wouldn't be a better fix to replace ndelay(100000); 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
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
@ 2014-09-09 17:54 ` Arnd Bergmann
0 siblings, 0 replies; 54+ messages in thread
From: Arnd Bergmann @ 2014-09-09 17:54 UTC (permalink / raw)
To: linux-arm-kernel
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(100000);
> > > +#endif
> >
> > Wouldn't be a better fix to replace ndelay(100000); 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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
@ 2014-09-09 17:54 ` Arnd Bergmann
0 siblings, 0 replies; 54+ messages in thread
From: Arnd Bergmann @ 2014-09-09 17:54 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Stephen Rothwell, Kamil Debski, Kukjin Kim, linux-kernel,
Mauro Carvalho Chehab, Kyungmin Park, linux-samsung-soc,
linux-next, Sylwester Nawrocki, Linux Media Mailing List,
Jacek Anaszewski, Mauro Carvalho Chehab
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(100000);
> > > +#endif
> >
> > Wouldn't be a better fix to replace ndelay(100000); 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
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
2014-09-09 17:54 ` Arnd Bergmann
@ 2014-09-09 18:40 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 18:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Sylwester Nawrocki, Stephen Rothwell,
Kamil Debski, Kukjin Kim, linux-kernel, Mauro Carvalho Chehab,
Kyungmin Park, linux-samsung-soc, linux-next, Jacek Anaszewski,
Linux Media Mailing List
Em Tue, 09 Sep 2014 19:54:19 +0200
Arnd Bergmann <arnd@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(100000);
> > > > +#endif
> > >
> > > Wouldn't be a better fix to replace ndelay(100000); 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 20000). See
include/asm-generic/delay.h.
Btw, I suspect that the only reason why ndelay(100000) causes a
compilation breakage is to avoid a big number, as the maximum limit
check ndelay() code (20000) 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
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCH 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
@ 2014-09-09 18:40 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 18:40 UTC (permalink / raw)
To: linux-arm-kernel
Em Tue, 09 Sep 2014 19:54:19 +0200
Arnd Bergmann <arnd@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(100000);
> > > > +#endif
> > >
> > > Wouldn't be a better fix to replace ndelay(100000); 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 20000). See
include/asm-generic/delay.h.
Btw, I suspect that the only reason why ndelay(100000) causes a
compilation breakage is to avoid a big number, as the maximum limit
check ndelay() code (20000) 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
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCH 3/3] [media] vpif: Fix compilation with allmodconfig
2014-09-09 14:38 ` Mauro Carvalho Chehab
(?)
@ 2014-09-09 14:38 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 14:38 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Lad, Prabhakar, davinci-linux-open-source,
linux-next, linux-kernel, Stephen Rothwell
When vpif is compiled as module, those errors happen:
ERROR: "vpif_lock" [drivers/media/platform/davinci/vpif_display.ko] undefined!
ERROR: "vpif_lock" [drivers/media/platform/davinci/vpif_capture.ko] undefined!
That's because vpif_lock symbol is not exported.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c
index cd08e5248387..3dad5bd7fe0a 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -38,6 +38,7 @@ MODULE_LICENSE("GPL");
#define VPIF_CH3_MAX_MODES 2
spinlock_t vpif_lock;
+EXPORT_SYMBOL_GPL(vpif_lock);
void __iomem *vpif_base;
EXPORT_SYMBOL_GPL(vpif_base);
--
1.9.3
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 3/3] [media] vpif: Fix compilation with allmodconfig
@ 2014-09-09 14:38 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 14:38 UTC (permalink / raw)
Cc: Stephen Rothwell,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mauro Carvalho Chehab,
linux-next-u79uwXL29TY76Z2rM5mHXA, Mauro Carvalho Chehab,
Linux Media Mailing List
When vpif is compiled as module, those errors happen:
ERROR: "vpif_lock" [drivers/media/platform/davinci/vpif_display.ko] undefined!
ERROR: "vpif_lock" [drivers/media/platform/davinci/vpif_capture.ko] undefined!
That's because vpif_lock symbol is not exported.
Reported-by: Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
Signed-off-by: Mauro Carvalho Chehab <m.chehab-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c
index cd08e5248387..3dad5bd7fe0a 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -38,6 +38,7 @@ MODULE_LICENSE("GPL");
#define VPIF_CH3_MAX_MODES 2
spinlock_t vpif_lock;
+EXPORT_SYMBOL_GPL(vpif_lock);
void __iomem *vpif_base;
EXPORT_SYMBOL_GPL(vpif_base);
--
1.9.3
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH 3/3] [media] vpif: Fix compilation with allmodconfig
@ 2014-09-09 14:38 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 14:38 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Lad, Prabhakar, davinci-linux-open-source,
linux-next, linux-kernel, Stephen Rothwell
When vpif is compiled as module, those errors happen:
ERROR: "vpif_lock" [drivers/media/platform/davinci/vpif_display.ko] undefined!
ERROR: "vpif_lock" [drivers/media/platform/davinci/vpif_capture.ko] undefined!
That's because vpif_lock symbol is not exported.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c
index cd08e5248387..3dad5bd7fe0a 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -38,6 +38,7 @@ MODULE_LICENSE("GPL");
#define VPIF_CH3_MAX_MODES 2
spinlock_t vpif_lock;
+EXPORT_SYMBOL_GPL(vpif_lock);
void __iomem *vpif_base;
EXPORT_SYMBOL_GPL(vpif_base);
--
1.9.3
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [PATCH 3/3] [media] vpif: Fix compilation with allmodconfig
2014-09-09 14:38 ` Mauro Carvalho Chehab
(?)
(?)
@ 2014-09-09 18:30 ` Prabhakar Lad
-1 siblings, 0 replies; 54+ messages in thread
From: Prabhakar Lad @ 2014-09-09 18:30 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, dlos,
linux-next, LKML, Stephen Rothwell
On Tue, Sep 9, 2014 at 3:38 PM, Mauro Carvalho Chehab
<m.chehab@samsung.com> wrote:
> When vpif is compiled as module, those errors happen:
>
> ERROR: "vpif_lock" [drivers/media/platform/davinci/vpif_display.ko] undefined!
> ERROR: "vpif_lock" [drivers/media/platform/davinci/vpif_capture.ko] undefined!
>
> That's because vpif_lock symbol is not exported.
>
Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Regards,
--Prabhakar Lad
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
>
> diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c
> index cd08e5248387..3dad5bd7fe0a 100644
> --- a/drivers/media/platform/davinci/vpif.c
> +++ b/drivers/media/platform/davinci/vpif.c
> @@ -38,6 +38,7 @@ MODULE_LICENSE("GPL");
> #define VPIF_CH3_MAX_MODES 2
>
> spinlock_t vpif_lock;
> +EXPORT_SYMBOL_GPL(vpif_lock);
>
> void __iomem *vpif_base;
> EXPORT_SYMBOL_GPL(vpif_base);
> --
> 1.9.3
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
2014-09-09 14:38 ` Mauro Carvalho Chehab
@ 2014-09-09 14:40 ` Nishanth Menon
-1 siblings, 0 replies; 54+ messages in thread
From: Nishanth Menon @ 2014-09-09 14:40 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, Tony Lindgren,
Russell King, Vinod Koul, Arnd Bergmann, Peter Griffin,
linux-next, linux-kernel, Stephen Rothwell, linux-omap, tony
+linux-omap, tony
-Balaji
On 09/09/2014 09:38 AM, Mauro Carvalho Chehab wrote:
> We want to be able to COMPILE_TEST the omap1_camera driver.
> It compiles fine, but it fails linkediting:
>
> ERROR: "omap_stop_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_start_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_dma_link_lch" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_set_dma_dest_burst_mode" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_set_dma_src_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_request_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_set_dma_transfer_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_set_dma_dest_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_free_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
>
> So, add some stub functions to avoid it.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
>
> diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
> index 6f06f8bc612c..7c8bfdd90a33 100644
> --- a/include/linux/omap-dma.h
> +++ b/include/linux/omap-dma.h
> @@ -294,43 +294,24 @@ struct omap_system_dma_plat_info {
> extern struct omap_system_dma_plat_info *omap_get_plat_info(void);
>
> extern void omap_set_dma_priority(int lch, int dst_port, int priority);
> -extern int omap_request_dma(int dev_id, const char *dev_name,
> - void (*callback)(int lch, u16 ch_status, void *data),
> - void *data, int *dma_ch);
> extern void omap_enable_dma_irq(int ch, u16 irq_bits);
> extern void omap_disable_dma_irq(int ch, u16 irq_bits);
> -extern void omap_free_dma(int ch);
> -extern void omap_start_dma(int lch);
> -extern void omap_stop_dma(int lch);
> -extern void omap_set_dma_transfer_params(int lch, int data_type,
> - int elem_count, int frame_count,
> - int sync_mode,
> - int dma_trigger, int src_or_dst_synch);
> extern void omap_set_dma_color_mode(int lch, enum omap_dma_color_mode mode,
> u32 color);
> extern void omap_set_dma_write_mode(int lch, enum omap_dma_write_mode mode);
> extern void omap_set_dma_channel_mode(int lch, enum omap_dma_channel_mode mode);
>
> -extern void omap_set_dma_src_params(int lch, int src_port, int src_amode,
> - unsigned long src_start,
> - int src_ei, int src_fi);
> extern void omap_set_dma_src_index(int lch, int eidx, int fidx);
> extern void omap_set_dma_src_data_pack(int lch, int enable);
> extern void omap_set_dma_src_burst_mode(int lch,
> enum omap_dma_burst_mode burst_mode);
>
> -extern void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
> - unsigned long dest_start,
> - int dst_ei, int dst_fi);
> extern void omap_set_dma_dest_index(int lch, int eidx, int fidx);
> extern void omap_set_dma_dest_data_pack(int lch, int enable);
> -extern void omap_set_dma_dest_burst_mode(int lch,
> - enum omap_dma_burst_mode burst_mode);
>
> extern void omap_set_dma_params(int lch,
> struct omap_dma_channel_params *params);
>
> -extern void omap_dma_link_lch(int lch_head, int lch_queue);
> extern void omap_dma_unlink_lch(int lch_head, int lch_queue);
>
> extern int omap_set_dma_callback(int lch,
> @@ -356,18 +337,9 @@ extern void omap_dma_disable_irq(int lch);
>
> /* Chaining APIs */
> #ifndef CONFIG_ARCH_OMAP1
> -extern int omap_request_dma_chain(int dev_id, const char *dev_name,
> - void (*callback) (int lch, u16 ch_status,
> - void *data),
> - int *chain_id, int no_of_chans,
> - int chain_mode,
> - struct omap_dma_channel_params params);
> -extern int omap_free_dma_chain(int chain_id);
> extern int omap_dma_chain_a_transfer(int chain_id, int src_start,
> int dest_start, int elem_count,
> int frame_count, void *callbk_data);
> -extern int omap_start_dma_chain_transfers(int chain_id);
> -extern int omap_stop_dma_chain_transfers(int chain_id);
> extern int omap_get_dma_chain_index(int chain_id, int *ei, int *fi);
> extern int omap_get_dma_chain_dst_pos(int chain_id);
> extern int omap_get_dma_chain_src_pos(int chain_id);
> @@ -377,6 +349,87 @@ extern int omap_modify_dma_chain_params(int chain_id,
> extern int omap_dma_chain_status(int chain_id);
> #endif
>
> +#ifndef CONFIG_COMPILE_TEST
> +extern int omap_request_dma(int dev_id, const char *dev_name,
> + void (*callback)(int lch, u16 ch_status, void *data),
> + void *data, int *dma_ch);
> +extern void omap_free_dma(int ch);
> +extern void omap_start_dma(int lch);
> +extern void omap_stop_dma(int lch);
> +extern void omap_set_dma_transfer_params(int lch, int data_type,
> + int elem_count, int frame_count,
> + int sync_mode,
> + int dma_trigger, int src_or_dst_synch);
> +extern void omap_set_dma_src_params(int lch, int src_port, int src_amode,
> + unsigned long src_start,
> + int src_ei, int src_fi);
> +extern void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
> + unsigned long dest_start,
> + int dst_ei, int dst_fi);
> +extern void omap_set_dma_dest_burst_mode(int lch,
> + enum omap_dma_burst_mode burst_mode);
> +extern void omap_dma_link_lch(int lch_head, int lch_queue);
> +
> +#ifndef CONFIG_ARCH_OMAP1
> +extern int omap_request_dma_chain(int dev_id, const char *dev_name,
> + void (*callback) (int lch, u16 ch_status,
> + void *data),
> + int *chain_id, int no_of_chans,
> + int chain_mode,
> + struct omap_dma_channel_params params);
> +extern int omap_free_dma_chain(int chain_id);
> +extern int omap_start_dma_chain_transfers(int chain_id);
> +extern int omap_stop_dma_chain_transfers(int chain_id);
> +#endif /* CONFIG_ARCH_OMAP1 */
> +#else
> + /* Stubs for compile testing some drivers on other archs */
> +
> +static inline
> +int omap_request_dma(int dev_id, const char *dev_name,
> + void (*callback)(int lch, u16 ch_status, void *data),
> + void *data, int *dma_ch) { return 0; }
> +
> +static inline void omap_free_dma(int ch) {}
> +static inline void omap_start_dma(int lch) {}
> +static inline void omap_stop_dma(int lch) {}
> +
> +static inline
> +void omap_set_dma_transfer_params(int lch, int data_type,
> + int elem_count, int frame_count,
> + int sync_mode,
> + int dma_trigger, int src_or_dst_synch) {}
> +
> +static inline
> +void omap_set_dma_src_params(int lch, int src_port, int src_amode,
> + unsigned long src_start,
> + int src_ei, int src_fi) {}
> +
> +static inline
> +void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
> + unsigned long dest_start,
> + int dst_ei, int dst_fi) {}
> +
> +static inline
> +void omap_set_dma_dest_burst_mode(int lch,
> + enum omap_dma_burst_mode burst_mode) {}
> +
> +static inline
> +void omap_dma_link_lch(int lch_head, int lch_queue) {}
> +
> +static inline
> +int omap_request_dma_chain(int dev_id, const char *dev_name,
> + void (*callback) (int lch, u16 ch_status,
> + void *data),
> + int *chain_id, int no_of_chans,
> + int chain_mode,
> + struct omap_dma_channel_params params) { return 0; }
> +
> +static inline int omap_free_dma_chain(int chain_id) { return 0; }
> +static inline int omap_start_dma_chain_transfers(int chain_id) { return 0; }
> +static inline int omap_stop_dma_chain_transfers(int chain_id) { return 0; }
> +
> +#endif /* CONFIG_COMPILE_TEST */
> +
> #if defined(CONFIG_ARCH_OMAP1) && IS_ENABLED(CONFIG_FB_OMAP)
> #include <mach/lcd_dma.h>
> #else
>
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
@ 2014-09-09 14:40 ` Nishanth Menon
0 siblings, 0 replies; 54+ messages in thread
From: Nishanth Menon @ 2014-09-09 14:40 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, Tony Lindgren,
Russell King, Vinod Koul, Arnd Bergmann, Peter Griffin,
linux-next, linux-kernel, Stephen Rothwell, linux-omap
+linux-omap, tony
-Balaji
On 09/09/2014 09:38 AM, Mauro Carvalho Chehab wrote:
> We want to be able to COMPILE_TEST the omap1_camera driver.
> It compiles fine, but it fails linkediting:
>
> ERROR: "omap_stop_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_start_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_dma_link_lch" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_set_dma_dest_burst_mode" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_set_dma_src_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_request_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_set_dma_transfer_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_set_dma_dest_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_free_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
>
> So, add some stub functions to avoid it.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
>
> diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
> index 6f06f8bc612c..7c8bfdd90a33 100644
> --- a/include/linux/omap-dma.h
> +++ b/include/linux/omap-dma.h
> @@ -294,43 +294,24 @@ struct omap_system_dma_plat_info {
> extern struct omap_system_dma_plat_info *omap_get_plat_info(void);
>
> extern void omap_set_dma_priority(int lch, int dst_port, int priority);
> -extern int omap_request_dma(int dev_id, const char *dev_name,
> - void (*callback)(int lch, u16 ch_status, void *data),
> - void *data, int *dma_ch);
> extern void omap_enable_dma_irq(int ch, u16 irq_bits);
> extern void omap_disable_dma_irq(int ch, u16 irq_bits);
> -extern void omap_free_dma(int ch);
> -extern void omap_start_dma(int lch);
> -extern void omap_stop_dma(int lch);
> -extern void omap_set_dma_transfer_params(int lch, int data_type,
> - int elem_count, int frame_count,
> - int sync_mode,
> - int dma_trigger, int src_or_dst_synch);
> extern void omap_set_dma_color_mode(int lch, enum omap_dma_color_mode mode,
> u32 color);
> extern void omap_set_dma_write_mode(int lch, enum omap_dma_write_mode mode);
> extern void omap_set_dma_channel_mode(int lch, enum omap_dma_channel_mode mode);
>
> -extern void omap_set_dma_src_params(int lch, int src_port, int src_amode,
> - unsigned long src_start,
> - int src_ei, int src_fi);
> extern void omap_set_dma_src_index(int lch, int eidx, int fidx);
> extern void omap_set_dma_src_data_pack(int lch, int enable);
> extern void omap_set_dma_src_burst_mode(int lch,
> enum omap_dma_burst_mode burst_mode);
>
> -extern void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
> - unsigned long dest_start,
> - int dst_ei, int dst_fi);
> extern void omap_set_dma_dest_index(int lch, int eidx, int fidx);
> extern void omap_set_dma_dest_data_pack(int lch, int enable);
> -extern void omap_set_dma_dest_burst_mode(int lch,
> - enum omap_dma_burst_mode burst_mode);
>
> extern void omap_set_dma_params(int lch,
> struct omap_dma_channel_params *params);
>
> -extern void omap_dma_link_lch(int lch_head, int lch_queue);
> extern void omap_dma_unlink_lch(int lch_head, int lch_queue);
>
> extern int omap_set_dma_callback(int lch,
> @@ -356,18 +337,9 @@ extern void omap_dma_disable_irq(int lch);
>
> /* Chaining APIs */
> #ifndef CONFIG_ARCH_OMAP1
> -extern int omap_request_dma_chain(int dev_id, const char *dev_name,
> - void (*callback) (int lch, u16 ch_status,
> - void *data),
> - int *chain_id, int no_of_chans,
> - int chain_mode,
> - struct omap_dma_channel_params params);
> -extern int omap_free_dma_chain(int chain_id);
> extern int omap_dma_chain_a_transfer(int chain_id, int src_start,
> int dest_start, int elem_count,
> int frame_count, void *callbk_data);
> -extern int omap_start_dma_chain_transfers(int chain_id);
> -extern int omap_stop_dma_chain_transfers(int chain_id);
> extern int omap_get_dma_chain_index(int chain_id, int *ei, int *fi);
> extern int omap_get_dma_chain_dst_pos(int chain_id);
> extern int omap_get_dma_chain_src_pos(int chain_id);
> @@ -377,6 +349,87 @@ extern int omap_modify_dma_chain_params(int chain_id,
> extern int omap_dma_chain_status(int chain_id);
> #endif
>
> +#ifndef CONFIG_COMPILE_TEST
> +extern int omap_request_dma(int dev_id, const char *dev_name,
> + void (*callback)(int lch, u16 ch_status, void *data),
> + void *data, int *dma_ch);
> +extern void omap_free_dma(int ch);
> +extern void omap_start_dma(int lch);
> +extern void omap_stop_dma(int lch);
> +extern void omap_set_dma_transfer_params(int lch, int data_type,
> + int elem_count, int frame_count,
> + int sync_mode,
> + int dma_trigger, int src_or_dst_synch);
> +extern void omap_set_dma_src_params(int lch, int src_port, int src_amode,
> + unsigned long src_start,
> + int src_ei, int src_fi);
> +extern void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
> + unsigned long dest_start,
> + int dst_ei, int dst_fi);
> +extern void omap_set_dma_dest_burst_mode(int lch,
> + enum omap_dma_burst_mode burst_mode);
> +extern void omap_dma_link_lch(int lch_head, int lch_queue);
> +
> +#ifndef CONFIG_ARCH_OMAP1
> +extern int omap_request_dma_chain(int dev_id, const char *dev_name,
> + void (*callback) (int lch, u16 ch_status,
> + void *data),
> + int *chain_id, int no_of_chans,
> + int chain_mode,
> + struct omap_dma_channel_params params);
> +extern int omap_free_dma_chain(int chain_id);
> +extern int omap_start_dma_chain_transfers(int chain_id);
> +extern int omap_stop_dma_chain_transfers(int chain_id);
> +#endif /* CONFIG_ARCH_OMAP1 */
> +#else
> + /* Stubs for compile testing some drivers on other archs */
> +
> +static inline
> +int omap_request_dma(int dev_id, const char *dev_name,
> + void (*callback)(int lch, u16 ch_status, void *data),
> + void *data, int *dma_ch) { return 0; }
> +
> +static inline void omap_free_dma(int ch) {}
> +static inline void omap_start_dma(int lch) {}
> +static inline void omap_stop_dma(int lch) {}
> +
> +static inline
> +void omap_set_dma_transfer_params(int lch, int data_type,
> + int elem_count, int frame_count,
> + int sync_mode,
> + int dma_trigger, int src_or_dst_synch) {}
> +
> +static inline
> +void omap_set_dma_src_params(int lch, int src_port, int src_amode,
> + unsigned long src_start,
> + int src_ei, int src_fi) {}
> +
> +static inline
> +void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
> + unsigned long dest_start,
> + int dst_ei, int dst_fi) {}
> +
> +static inline
> +void omap_set_dma_dest_burst_mode(int lch,
> + enum omap_dma_burst_mode burst_mode) {}
> +
> +static inline
> +void omap_dma_link_lch(int lch_head, int lch_queue) {}
> +
> +static inline
> +int omap_request_dma_chain(int dev_id, const char *dev_name,
> + void (*callback) (int lch, u16 ch_status,
> + void *data),
> + int *chain_id, int no_of_chans,
> + int chain_mode,
> + struct omap_dma_channel_params params) { return 0; }
> +
> +static inline int omap_free_dma_chain(int chain_id) { return 0; }
> +static inline int omap_start_dma_chain_transfers(int chain_id) { return 0; }
> +static inline int omap_stop_dma_chain_transfers(int chain_id) { return 0; }
> +
> +#endif /* CONFIG_COMPILE_TEST */
> +
> #if defined(CONFIG_ARCH_OMAP1) && IS_ENABLED(CONFIG_FB_OMAP)
> #include <mach/lcd_dma.h>
> #else
>
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
2014-09-09 14:40 ` Nishanth Menon
(?)
@ 2014-09-09 14:58 ` Tony Lindgren
-1 siblings, 0 replies; 54+ messages in thread
From: Tony Lindgren @ 2014-09-09 14:58 UTC (permalink / raw)
To: Nishanth Menon
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Russell King, Vinod Koul, Arnd Bergmann,
Peter Griffin, linux-next, linux-kernel, Stephen Rothwell,
linux-omap
* Nishanth Menon <nm@ti.com> [140909 07:40]:
> +linux-omap, tony
> -Balaji
>
> On 09/09/2014 09:38 AM, Mauro Carvalho Chehab wrote:
> > We want to be able to COMPILE_TEST the omap1_camera driver.
> > It compiles fine, but it fails linkediting:
> >
> > ERROR: "omap_stop_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_start_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_dma_link_lch" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_set_dma_dest_burst_mode" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_set_dma_src_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_request_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_set_dma_transfer_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_set_dma_dest_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_free_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> >
> > So, add some stub functions to avoid it.
How about just remove that old driver? I doubt it works, and I'm
almost certain nobody has actually tried to use it for many
years. At least I'm not aware of any hardware supported in the
mainline kernel with it. And we're moving things to dma engine
API anyways.
Regards,
Tony
> > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
> >
> > diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
> > index 6f06f8bc612c..7c8bfdd90a33 100644
> > --- a/include/linux/omap-dma.h
> > +++ b/include/linux/omap-dma.h
> > @@ -294,43 +294,24 @@ struct omap_system_dma_plat_info {
> > extern struct omap_system_dma_plat_info *omap_get_plat_info(void);
> >
> > extern void omap_set_dma_priority(int lch, int dst_port, int priority);
> > -extern int omap_request_dma(int dev_id, const char *dev_name,
> > - void (*callback)(int lch, u16 ch_status, void *data),
> > - void *data, int *dma_ch);
> > extern void omap_enable_dma_irq(int ch, u16 irq_bits);
> > extern void omap_disable_dma_irq(int ch, u16 irq_bits);
> > -extern void omap_free_dma(int ch);
> > -extern void omap_start_dma(int lch);
> > -extern void omap_stop_dma(int lch);
> > -extern void omap_set_dma_transfer_params(int lch, int data_type,
> > - int elem_count, int frame_count,
> > - int sync_mode,
> > - int dma_trigger, int src_or_dst_synch);
> > extern void omap_set_dma_color_mode(int lch, enum omap_dma_color_mode mode,
> > u32 color);
> > extern void omap_set_dma_write_mode(int lch, enum omap_dma_write_mode mode);
> > extern void omap_set_dma_channel_mode(int lch, enum omap_dma_channel_mode mode);
> >
> > -extern void omap_set_dma_src_params(int lch, int src_port, int src_amode,
> > - unsigned long src_start,
> > - int src_ei, int src_fi);
> > extern void omap_set_dma_src_index(int lch, int eidx, int fidx);
> > extern void omap_set_dma_src_data_pack(int lch, int enable);
> > extern void omap_set_dma_src_burst_mode(int lch,
> > enum omap_dma_burst_mode burst_mode);
> >
> > -extern void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
> > - unsigned long dest_start,
> > - int dst_ei, int dst_fi);
> > extern void omap_set_dma_dest_index(int lch, int eidx, int fidx);
> > extern void omap_set_dma_dest_data_pack(int lch, int enable);
> > -extern void omap_set_dma_dest_burst_mode(int lch,
> > - enum omap_dma_burst_mode burst_mode);
> >
> > extern void omap_set_dma_params(int lch,
> > struct omap_dma_channel_params *params);
> >
> > -extern void omap_dma_link_lch(int lch_head, int lch_queue);
> > extern void omap_dma_unlink_lch(int lch_head, int lch_queue);
> >
> > extern int omap_set_dma_callback(int lch,
> > @@ -356,18 +337,9 @@ extern void omap_dma_disable_irq(int lch);
> >
> > /* Chaining APIs */
> > #ifndef CONFIG_ARCH_OMAP1
> > -extern int omap_request_dma_chain(int dev_id, const char *dev_name,
> > - void (*callback) (int lch, u16 ch_status,
> > - void *data),
> > - int *chain_id, int no_of_chans,
> > - int chain_mode,
> > - struct omap_dma_channel_params params);
> > -extern int omap_free_dma_chain(int chain_id);
> > extern int omap_dma_chain_a_transfer(int chain_id, int src_start,
> > int dest_start, int elem_count,
> > int frame_count, void *callbk_data);
> > -extern int omap_start_dma_chain_transfers(int chain_id);
> > -extern int omap_stop_dma_chain_transfers(int chain_id);
> > extern int omap_get_dma_chain_index(int chain_id, int *ei, int *fi);
> > extern int omap_get_dma_chain_dst_pos(int chain_id);
> > extern int omap_get_dma_chain_src_pos(int chain_id);
> > @@ -377,6 +349,87 @@ extern int omap_modify_dma_chain_params(int chain_id,
> > extern int omap_dma_chain_status(int chain_id);
> > #endif
> >
> > +#ifndef CONFIG_COMPILE_TEST
> > +extern int omap_request_dma(int dev_id, const char *dev_name,
> > + void (*callback)(int lch, u16 ch_status, void *data),
> > + void *data, int *dma_ch);
> > +extern void omap_free_dma(int ch);
> > +extern void omap_start_dma(int lch);
> > +extern void omap_stop_dma(int lch);
> > +extern void omap_set_dma_transfer_params(int lch, int data_type,
> > + int elem_count, int frame_count,
> > + int sync_mode,
> > + int dma_trigger, int src_or_dst_synch);
> > +extern void omap_set_dma_src_params(int lch, int src_port, int src_amode,
> > + unsigned long src_start,
> > + int src_ei, int src_fi);
> > +extern void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
> > + unsigned long dest_start,
> > + int dst_ei, int dst_fi);
> > +extern void omap_set_dma_dest_burst_mode(int lch,
> > + enum omap_dma_burst_mode burst_mode);
> > +extern void omap_dma_link_lch(int lch_head, int lch_queue);
> > +
> > +#ifndef CONFIG_ARCH_OMAP1
> > +extern int omap_request_dma_chain(int dev_id, const char *dev_name,
> > + void (*callback) (int lch, u16 ch_status,
> > + void *data),
> > + int *chain_id, int no_of_chans,
> > + int chain_mode,
> > + struct omap_dma_channel_params params);
> > +extern int omap_free_dma_chain(int chain_id);
> > +extern int omap_start_dma_chain_transfers(int chain_id);
> > +extern int omap_stop_dma_chain_transfers(int chain_id);
> > +#endif /* CONFIG_ARCH_OMAP1 */
> > +#else
> > + /* Stubs for compile testing some drivers on other archs */
> > +
> > +static inline
> > +int omap_request_dma(int dev_id, const char *dev_name,
> > + void (*callback)(int lch, u16 ch_status, void *data),
> > + void *data, int *dma_ch) { return 0; }
> > +
> > +static inline void omap_free_dma(int ch) {}
> > +static inline void omap_start_dma(int lch) {}
> > +static inline void omap_stop_dma(int lch) {}
> > +
> > +static inline
> > +void omap_set_dma_transfer_params(int lch, int data_type,
> > + int elem_count, int frame_count,
> > + int sync_mode,
> > + int dma_trigger, int src_or_dst_synch) {}
> > +
> > +static inline
> > +void omap_set_dma_src_params(int lch, int src_port, int src_amode,
> > + unsigned long src_start,
> > + int src_ei, int src_fi) {}
> > +
> > +static inline
> > +void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode,
> > + unsigned long dest_start,
> > + int dst_ei, int dst_fi) {}
> > +
> > +static inline
> > +void omap_set_dma_dest_burst_mode(int lch,
> > + enum omap_dma_burst_mode burst_mode) {}
> > +
> > +static inline
> > +void omap_dma_link_lch(int lch_head, int lch_queue) {}
> > +
> > +static inline
> > +int omap_request_dma_chain(int dev_id, const char *dev_name,
> > + void (*callback) (int lch, u16 ch_status,
> > + void *data),
> > + int *chain_id, int no_of_chans,
> > + int chain_mode,
> > + struct omap_dma_channel_params params) { return 0; }
> > +
> > +static inline int omap_free_dma_chain(int chain_id) { return 0; }
> > +static inline int omap_start_dma_chain_transfers(int chain_id) { return 0; }
> > +static inline int omap_stop_dma_chain_transfers(int chain_id) { return 0; }
> > +
> > +#endif /* CONFIG_COMPILE_TEST */
> > +
> > #if defined(CONFIG_ARCH_OMAP1) && IS_ENABLED(CONFIG_FB_OMAP)
> > #include <mach/lcd_dma.h>
> > #else
> >
>
>
> --
> Regards,
> Nishanth Menon
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
2014-09-09 14:38 ` Mauro Carvalho Chehab
` (4 preceding siblings ...)
(?)
@ 2014-09-09 14:41 ` Russell King - ARM Linux
2014-09-09 15:36 ` Mauro Carvalho Chehab
-1 siblings, 1 reply; 54+ messages in thread
From: Russell King - ARM Linux @ 2014-09-09 14:41 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, Tony Lindgren,
Vinod Koul, Arnd Bergmann, Peter Griffin, Balaji T K,
Nishanth Menon, linux-next, linux-kernel, Stephen Rothwell
On Tue, Sep 09, 2014 at 11:38:17AM -0300, Mauro Carvalho Chehab wrote:
> We want to be able to COMPILE_TEST the omap1_camera driver.
> It compiles fine, but it fails linkediting:
>
> ERROR: "omap_stop_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_start_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_dma_link_lch" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_set_dma_dest_burst_mode" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_set_dma_src_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_request_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_set_dma_transfer_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_set_dma_dest_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_free_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
>
> So, add some stub functions to avoid it.
The real answer to this is to find someone who still uses it, and convert
it to the DMA engine API. If there's no users, the driver might as well
be killed off.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
2014-09-09 14:41 ` Russell King - ARM Linux
@ 2014-09-09 15:36 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 15:36 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, Tony Lindgren,
Vinod Koul, Arnd Bergmann, Peter Griffin, Balaji T K,
Nishanth Menon, linux-next, linux-kernel, Stephen Rothwell,
Janusz Krzysztofik, Tony Lindgren, linux-omap
Em Tue, 9 Sep 2014 15:41:58 +0100
Russell King - ARM Linux <linux@arm.linux.org.uk> escreveu:
> On Tue, Sep 09, 2014 at 11:38:17AM -0300, Mauro Carvalho Chehab wrote:
> > We want to be able to COMPILE_TEST the omap1_camera driver.
> > It compiles fine, but it fails linkediting:
> >
> > ERROR: "omap_stop_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_start_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_dma_link_lch" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_set_dma_dest_burst_mode" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_set_dma_src_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_request_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_set_dma_transfer_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_set_dma_dest_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_free_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> >
> > So, add some stub functions to avoid it.
>
> The real answer to this is to find someone who still uses it, and convert
> it to the DMA engine API. If there's no users, the driver might as well
> be killed off.
Hmm... it seems that there are still several drivers still relying on
the functions declared at: omap-dma.h:
$ grep extern include/linux/omap-dma.h |perl -ne 'print "$1\n" if (m/extern\s\S+\s(.*)\(/)' >funcs && git grep -f funcs -l
arch/arm/mach-omap1/pm.c
arch/arm/mach-omap2/pm24xx.c
arch/arm/plat-omap/dma.c
drivers/dma/omap-dma.c
drivers/media/platform/omap/omap_vout_vrfb.c
drivers/media/platform/omap3isp/isphist.c
drivers/media/platform/soc_camera/omap1_camera.c
drivers/mtd/onenand/omap2.c
drivers/usb/gadget/udc/omap_udc.c
drivers/usb/musb/tusb6010_omap.c
drivers/video/fbdev/omap/omapfb_main.c
include/linux/omap-dma.h
Perhaps we can remove the header and mark all the above as BROKEN.
If nobody fixes, we can strip all of them from the Kernel.
Regards,
Mauro
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
@ 2014-09-09 15:36 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 15:36 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, Tony Lindgren,
Vinod Koul, Arnd Bergmann, Peter Griffin, Balaji T K,
Nishanth Menon, linux-next, linux-kernel, Stephen Rothwell,
Janusz Krzysztofik
Em Tue, 9 Sep 2014 15:41:58 +0100
Russell King - ARM Linux <linux@arm.linux.org.uk> escreveu:
> On Tue, Sep 09, 2014 at 11:38:17AM -0300, Mauro Carvalho Chehab wrote:
> > We want to be able to COMPILE_TEST the omap1_camera driver.
> > It compiles fine, but it fails linkediting:
> >
> > ERROR: "omap_stop_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_start_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_dma_link_lch" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_set_dma_dest_burst_mode" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_set_dma_src_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_request_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_set_dma_transfer_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_set_dma_dest_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > ERROR: "omap_free_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> >
> > So, add some stub functions to avoid it.
>
> The real answer to this is to find someone who still uses it, and convert
> it to the DMA engine API. If there's no users, the driver might as well
> be killed off.
Hmm... it seems that there are still several drivers still relying on
the functions declared at: omap-dma.h:
$ grep extern include/linux/omap-dma.h |perl -ne 'print "$1\n" if (m/extern\s\S+\s(.*)\(/)' >funcs && git grep -f funcs -l
arch/arm/mach-omap1/pm.c
arch/arm/mach-omap2/pm24xx.c
arch/arm/plat-omap/dma.c
drivers/dma/omap-dma.c
drivers/media/platform/omap/omap_vout_vrfb.c
drivers/media/platform/omap3isp/isphist.c
drivers/media/platform/soc_camera/omap1_camera.c
drivers/mtd/onenand/omap2.c
drivers/usb/gadget/udc/omap_udc.c
drivers/usb/musb/tusb6010_omap.c
drivers/video/fbdev/omap/omapfb_main.c
include/linux/omap-dma.h
Perhaps we can remove the header and mark all the above as BROKEN.
If nobody fixes, we can strip all of them from the Kernel.
Regards,
Mauro
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
2014-09-09 15:36 ` Mauro Carvalho Chehab
(?)
@ 2014-09-09 17:52 ` Mauro Carvalho Chehab
2014-09-10 16:25 ` Tony Lindgren
-1 siblings, 1 reply; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 17:52 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Linux Media Mailing List, Tony Lindgren, Vinod Koul,
Arnd Bergmann, Peter Griffin, Balaji T K, Nishanth Menon,
linux-next, linux-kernel, Stephen Rothwell, Janusz Krzysztofik,
linux-omap
Em Tue, 09 Sep 2014 12:36:54 -0300
Mauro Carvalho Chehab <m.chehab@samsung.com> escreveu:
> Em Tue, 9 Sep 2014 15:41:58 +0100
> Russell King - ARM Linux <linux@arm.linux.org.uk> escreveu:
>
> > On Tue, Sep 09, 2014 at 11:38:17AM -0300, Mauro Carvalho Chehab wrote:
> > > We want to be able to COMPILE_TEST the omap1_camera driver.
> > > It compiles fine, but it fails linkediting:
> > >
> > > ERROR: "omap_stop_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > > ERROR: "omap_start_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > > ERROR: "omap_dma_link_lch" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > > ERROR: "omap_set_dma_dest_burst_mode" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > > ERROR: "omap_set_dma_src_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > > ERROR: "omap_request_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > > ERROR: "omap_set_dma_transfer_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > > ERROR: "omap_set_dma_dest_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > > ERROR: "omap_free_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > >
> > > So, add some stub functions to avoid it.
> >
> > The real answer to this is to find someone who still uses it, and convert
> > it to the DMA engine API. If there's no users, the driver might as well
> > be killed off.
>
> Hmm... it seems that there are still several drivers still relying on
> the functions declared at: omap-dma.h:
>
> $ grep extern include/linux/omap-dma.h |perl -ne 'print "$1\n" if (m/extern\s\S+\s(.*)\(/)' >funcs && git grep -f funcs -l
> arch/arm/mach-omap1/pm.c
> arch/arm/mach-omap2/pm24xx.c
> arch/arm/plat-omap/dma.c
> drivers/dma/omap-dma.c
> drivers/media/platform/omap/omap_vout_vrfb.c
> drivers/media/platform/omap3isp/isphist.c
> drivers/media/platform/soc_camera/omap1_camera.c
> drivers/mtd/onenand/omap2.c
> drivers/usb/gadget/udc/omap_udc.c
> drivers/usb/musb/tusb6010_omap.c
> drivers/video/fbdev/omap/omapfb_main.c
> include/linux/omap-dma.h
>
> Perhaps we can remove the header and mark all the above as BROKEN.
>
> If nobody fixes, we can strip all of them from the Kernel.
Are all the functions declared at omap-dma.h part of the
old DMA API that should be deprecated?
If so, it seems that the OMAP2 and OMAP3 also depends on this
thing, as all the PM code for OMAP depends on the functions
declared inside omap-dma.h, and marking them as BROKEN
causes compilation to failure:
arch/arm/mach-omap2/built-in.o: In function `omap3_save_scratchpad_contents':
:(.text+0x798): undefined reference to `omap3_restore_3630'
:(.text+0x7a8): undefined reference to `omap3_restore'
:(.text+0x7ac): undefined reference to `omap3_restore_es3'
arch/arm/mach-omap2/built-in.o: In function `omap3_sram_restore_context':
:(.text+0x925c): undefined reference to `omap_push_sram_idle'
arch/arm/mach-omap2/built-in.o: In function `option_set':
:(.text+0xc15c): undefined reference to `omap3_pm_off_mode_enable'
arch/arm/mach-omap2/built-in.o: In function `pwrdm_suspend_set':
:(.text+0xc1a0): undefined reference to `omap3_pm_set_suspend_state'
arch/arm/mach-omap2/built-in.o: In function `pwrdm_suspend_get':
:(.text+0xc1e4): undefined reference to `omap3_pm_get_suspend_state'
arch/arm/mach-omap2/built-in.o: In function `omap3_enter_idle_bm':
:(.text+0xc7ec): undefined reference to `omap_sram_idle'
:(.text+0xc848): undefined reference to `pm34xx_errata'
arch/arm/mach-omap2/built-in.o: In function `omap2420_init_late':
:(.init.text+0xf64): undefined reference to `omap2_pm_init'
arch/arm/mach-omap2/built-in.o: In function `omap2430_init_late':
:(.init.text+0x1024): undefined reference to `omap2_pm_init'
arch/arm/mach-omap2/built-in.o: In function `omap3_init_late':
:(.init.text+0x1248): undefined reference to `omap3_pm_init'
arch/arm/mach-omap2/built-in.o: In function `omap3430_init_late':
:(.init.text+0x1264): undefined reference to `omap3_pm_init'
arch/arm/mach-omap2/built-in.o: In function `omap35xx_init_late':
:(.init.text+0x1280): undefined reference to `omap3_pm_init'
arch/arm/mach-omap2/built-in.o: In function `omap3630_init_late':
:(.init.text+0x129c): undefined reference to `omap3_pm_init'
arch/arm/mach-omap2/built-in.o: In function `am35xx_init_late':
:(.init.text+0x12b8): undefined reference to `omap3_pm_init'
arch/arm/mach-omap2/built-in.o::(.init.text+0x12d4): more undefined references to `omap3_pm_init' follow
This was compiled with allmodconfig on arm, with COMPILE_TEST
disabled (a few sub-archs disabled too), to avoid spurious
unrelated compilation issues).
Am I missing something?
BTW, CONFIG_PM is auto-selected by ARCH_OMAP3.
And those are the functions that the OMAP3 code uses from omap-dma.h:
arch/arm/mach-omap2/pm34xx.c:92:2: error: implicit declaration of function ‘omap_dma_global_context_save’ [-Werror=implicit-function-declaration]
arch/arm/mach-omap2/pm34xx.c:103:2: error: implicit declaration of function ‘omap_dma_global_context_restore’ [-Werror=implicit-function-declaration]
arch/arm/mach-omap2/pm24xx.c:170:2: error: implicit declaration of function ‘omap_dma_running’ [-Werror=implicit-function-declaration]
Just enabling this won't work, as the code at arch/arm/plat-omap/dma.c
depends on several other functions inside omap-dma.h.
Regards,
Mauro
-
From: Mauro Carvalho Chehab <m.chehab@samsung.com>
Subject: [PATCH] omap-dma: remove deprecated omap-dma.h API
We want to be able to COMPILE_TEST the omap1_camera driver.
It compiles fine, but it fails linkediting:
ERROR: "omap_stop_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_start_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_dma_link_lch" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_set_dma_dest_burst_mode" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_set_dma_src_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_request_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_set_dma_transfer_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_set_dma_dest_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
ERROR: "omap_free_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
That's because OMAP1 is using a legacy deprecated API.
Instead of fixing it, the right thing to do is to convert the
remaining OMAP drivers that use the legacy API to the standard
DMA API.
While this doesn't happen, let's mark the broken stuff with
BROKEN.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 6f06f8bc612c..2f19292d1e78 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -291,6 +291,12 @@ struct omap_system_dma_plat_info {
#define dma_omap15xx() __dma_omap15xx(d)
#define dma_omap16xx() __dma_omap16xx(d)
+#ifdef CONFIG_BROKEN
+
+/*
+ * Deprecated non-standard DMA API.
+ */
+
extern struct omap_system_dma_plat_info *omap_get_plat_info(void);
extern void omap_set_dma_priority(int lch, int dst_port, int priority);
@@ -377,6 +383,8 @@ extern int omap_modify_dma_chain_params(int chain_id,
extern int omap_dma_chain_status(int chain_id);
#endif
+#endif /* CONFIG_BROKEN */
+
#if defined(CONFIG_ARCH_OMAP1) && IS_ENABLED(CONFIG_FB_OMAP)
#include <mach/lcd_dma.h>
#else
diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index cdd05f2e67ee..c5dbcebd8fdc 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -34,6 +34,11 @@ config ARCH_OMAP16XX
comment "OMAP Board Type"
depends on ARCH_OMAP1
+config OMAP1_PM
+ tristate
+ depends on PM
+ depends on BROKEN
+
config MACH_OMAP_INNOVATOR
bool "TI Innovator"
depends on ARCH_OMAP1 && (ARCH_OMAP15XX || ARCH_OMAP16XX)
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 3889b6cd211e..4a80fcd9528e 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -17,7 +17,7 @@ obj-$(CONFIG_OMAP_32K_TIMER) += timer32k.o
obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
# Power Management
-obj-$(CONFIG_PM) += pm.o sleep.o
+obj-$(CONFIG_OMAP1_PM) += pm.o sleep.o
i2c-omap-$(CONFIG_I2C_OMAP) := i2c.o
obj-y += $(i2c-omap-m) $(i2c-omap-y)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index e7189dcc9309..8a670f374638 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -11,6 +11,16 @@ config ARCH_OMAP2
select CPU_V6
select SOC_HAS_OMAP2_SDRC
+config OMAP2_PM24XX
+ bool
+ depends on ARCH_OMAP2
+ depends on BROKEN
+
+config OMAP2_PM34XX
+ bool
+ depends on ARCH_OMAP3
+ depends on BROKEN
+
config ARCH_OMAP3
bool "TI OMAP3"
depends on ARCH_MULTI_V7
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 69bbcba8842f..9b88e8083b22 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -84,9 +84,9 @@ endif
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
ifeq ($(CONFIG_PM),y)
-obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
-obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
-obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
+obj-$(CONFIG_OMAP2_PM24XX) += pm24xx.o
+obj-$(CONFIG_OMAP2_PM24XX) += sleep24xx.o
+obj-$(CONFIG_OMAP3_PM34XX) += pm34xx.o sleep34xx.o
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o
obj-$(CONFIG_SOC_OMAP5) += omap-mpuss-lowpower.o
obj-$(CONFIG_SOC_DRA7XX) += omap-mpuss-lowpower.o
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 0b01b68fd033..07c45d60a026 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -5,7 +5,8 @@
ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/arch/arm/plat-omap/include
# Common support
-obj-y := sram.o dma.o counter_32k.o
+obj-y := sram.o counter_32k.o
+obj-$(CONFIG_BROKEN) := dma.o
obj-m :=
obj-n :=
obj- :=
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 9b1ea0ef59af..8f297523ba0f 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -321,6 +321,7 @@ config MMP_TDMA
config DMA_OMAP
tristate "OMAP DMA support"
depends on ARCH_OMAP
+ depends on BROKEN
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index bee9074ebc13..63a87448ac83 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -97,6 +97,7 @@ config VIDEO_OMAP3
tristate "OMAP 3 Camera support"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
depends on HAS_DMA
+ depends on BROKEN
select ARM_DMA_USE_IOMMU
select OMAP_IOMMU
select VIDEOBUF2_DMA_CONTIG
diff --git a/drivers/media/platform/omap/Kconfig b/drivers/media/platform/omap/Kconfig
index 05de442d24e4..d4a3c6170907 100644
--- a/drivers/media/platform/omap/Kconfig
+++ b/drivers/media/platform/omap/Kconfig
@@ -4,6 +4,7 @@ config VIDEO_OMAP2_VOUT_VRFB
config VIDEO_OMAP2_VOUT
tristate "OMAP2/OMAP3 V4L2-Display driver"
depends on ARCH_OMAP2 || ARCH_OMAP3 || (COMPILE_TEST && HAS_MMU)
+ depends on BROKEN
select VIDEOBUF_GEN
select VIDEOBUF_DMA_CONTIG
select OMAP2_DSS if HAS_IOMEM && ARCH_OMAP2PLUS
diff --git a/drivers/media/platform/soc_camera/Kconfig b/drivers/media/platform/soc_camera/Kconfig
index 6af6c6dccda8..52afbdd2b915 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -65,6 +65,7 @@ config VIDEO_OMAP1
depends on VIDEO_DEV && SOC_CAMERA
depends on ARCH_OMAP1 || COMPILE_TEST
depends on HAS_DMA
+ depends on BROKEN
select VIDEOBUF_DMA_CONTIG
select VIDEOBUF_DMA_SG
---help---
diff --git a/drivers/mtd/onenand/Kconfig b/drivers/mtd/onenand/Kconfig
index dcae2f6a2b11..2155c081e7ea 100644
--- a/drivers/mtd/onenand/Kconfig
+++ b/drivers/mtd/onenand/Kconfig
@@ -26,6 +26,7 @@ config MTD_ONENAND_GENERIC
config MTD_ONENAND_OMAP2
tristate "OneNAND on OMAP2/OMAP3 support"
depends on ARCH_OMAP2 || ARCH_OMAP3
+ depends on BROKEN
help
Support for a OneNAND flash device connected to an OMAP2/OMAP3 CPU
via the GPMC memory controller.
diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 5151f947a4f5..66216d1e3c22 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -29,6 +29,11 @@ menu "USB Peripheral Controller"
# Integrated controllers
#
+config UDC_OMAP
+ tristate
+ depends on USB_OMAP
+ depends on BROKEN
+
config USB_AT91
tristate "Atmel AT91 USB Device Port"
depends on ARCH_AT91
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index 4096122bb283..9b14964adccd 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_USB_AMD5536UDC) += amd5536udc.o
obj-$(CONFIG_USB_PXA25X) += pxa25x_udc.o
obj-$(CONFIG_USB_PXA27X) += pxa27x_udc.o
obj-$(CONFIG_USB_GOKU) += goku_udc.o
-obj-$(CONFIG_USB_OMAP) += omap_udc.o
+obj-$(CONFIG_UDC_OMAP) += omap_udc.o
obj-$(CONFIG_USB_S3C2410) += s3c2410_udc.o
obj-$(CONFIG_USB_AT91) += at91_udc.o
obj-$(CONFIG_USB_ATMEL_USBA) += atmel_usba_udc.o
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 06cc5d6ea681..13c3e3767938 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -147,6 +147,7 @@ config USB_TUSB_OMAP_DMA
bool 'TUSB 6010'
depends on USB_MUSB_TUSB6010 = USB_MUSB_HDRC # both built-in or both modules
depends on ARCH_OMAP
+ depends on BROKEN
help
Enable DMA transfers on TUSB 6010 when OMAP DMA is available.
diff --git a/drivers/video/fbdev/omap/Kconfig b/drivers/video/fbdev/omap/Kconfig
index 18c4cb0d5690..c0a6d208c6e3 100644
--- a/drivers/video/fbdev/omap/Kconfig
+++ b/drivers/video/fbdev/omap/Kconfig
@@ -2,6 +2,7 @@ config FB_OMAP
tristate "OMAP frame buffer support"
depends on FB
depends on ARCH_OMAP1
+ depends on BROKEN
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
2014-09-09 17:52 ` Mauro Carvalho Chehab
@ 2014-09-10 16:25 ` Tony Lindgren
0 siblings, 0 replies; 54+ messages in thread
From: Tony Lindgren @ 2014-09-10 16:25 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Russell King - ARM Linux, Linux Media Mailing List, Vinod Koul,
Arnd Bergmann, Peter Griffin, Balaji T K, Nishanth Menon,
linux-next, linux-kernel, Stephen Rothwell, Janusz Krzysztofik,
linux-omap
* Mauro Carvalho Chehab <mchehab@infradead.org> [140909 17:52]:
> Em Tue, 09 Sep 2014 12:36:54 -0300
> Mauro Carvalho Chehab <m.chehab@samsung.com> escreveu:
>
> > Em Tue, 9 Sep 2014 15:41:58 +0100
> > Russell King - ARM Linux <linux@arm.linux.org.uk> escreveu:
> >
> > > On Tue, Sep 09, 2014 at 11:38:17AM -0300, Mauro Carvalho Chehab wrote:
> > > > We want to be able to COMPILE_TEST the omap1_camera driver.
> > > > It compiles fine, but it fails linkediting:
> > > >
> > > > ERROR: "omap_stop_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > > > ERROR: "omap_start_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > > > ERROR: "omap_dma_link_lch" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > > > ERROR: "omap_set_dma_dest_burst_mode" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > > > ERROR: "omap_set_dma_src_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > > > ERROR: "omap_request_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > > > ERROR: "omap_set_dma_transfer_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > > > ERROR: "omap_set_dma_dest_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > > > ERROR: "omap_free_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> > > >
> > > > So, add some stub functions to avoid it.
> > >
> > > The real answer to this is to find someone who still uses it, and convert
> > > it to the DMA engine API. If there's no users, the driver might as well
> > > be killed off.
> >
> > Hmm... it seems that there are still several drivers still relying on
> > the functions declared at: omap-dma.h:
> >
> > $ grep extern include/linux/omap-dma.h |perl -ne 'print "$1\n" if (m/extern\s\S+\s(.*)\(/)' >funcs && git grep -f funcs -l
> > arch/arm/mach-omap1/pm.c
> > arch/arm/mach-omap2/pm24xx.c
> > arch/arm/plat-omap/dma.c
> > drivers/dma/omap-dma.c
> > drivers/media/platform/omap/omap_vout_vrfb.c
> > drivers/media/platform/omap3isp/isphist.c
> > drivers/media/platform/soc_camera/omap1_camera.c
> > drivers/mtd/onenand/omap2.c
> > drivers/usb/gadget/udc/omap_udc.c
> > drivers/usb/musb/tusb6010_omap.c
> > drivers/video/fbdev/omap/omapfb_main.c
> > include/linux/omap-dma.h
> >
> > Perhaps we can remove the header and mark all the above as BROKEN.
No, not quite yet. That would currently cause major issues for omap2
and omap3.
> > If nobody fixes, we can strip all of them from the Kernel.
>
> Are all the functions declared at omap-dma.h part of the
> old DMA API that should be deprecated?
For the drivers yes. For the platform code, there are few functions
needed, that's at least omap_dma_global_context_save()
and omap_dma_global_context_restore(). But those can be in a local
header file in arch/arm/plat-omap/include/plat.
> If so, it seems that the OMAP2 and OMAP3 also depends on this
> thing, as all the PM code for OMAP depends on the functions
> declared inside omap-dma.h, and marking them as BROKEN
> causes compilation to failure:
>
> arch/arm/mach-omap2/built-in.o: In function `omap3_save_scratchpad_contents':
> :(.text+0x798): undefined reference to `omap3_restore_3630'
> :(.text+0x7a8): undefined reference to `omap3_restore'
> :(.text+0x7ac): undefined reference to `omap3_restore_es3'
> arch/arm/mach-omap2/built-in.o: In function `omap3_sram_restore_context':
> :(.text+0x925c): undefined reference to `omap_push_sram_idle'
> arch/arm/mach-omap2/built-in.o: In function `option_set':
> :(.text+0xc15c): undefined reference to `omap3_pm_off_mode_enable'
> arch/arm/mach-omap2/built-in.o: In function `pwrdm_suspend_set':
> :(.text+0xc1a0): undefined reference to `omap3_pm_set_suspend_state'
> arch/arm/mach-omap2/built-in.o: In function `pwrdm_suspend_get':
> :(.text+0xc1e4): undefined reference to `omap3_pm_get_suspend_state'
> arch/arm/mach-omap2/built-in.o: In function `omap3_enter_idle_bm':
> :(.text+0xc7ec): undefined reference to `omap_sram_idle'
> :(.text+0xc848): undefined reference to `pm34xx_errata'
> arch/arm/mach-omap2/built-in.o: In function `omap2420_init_late':
> :(.init.text+0xf64): undefined reference to `omap2_pm_init'
> arch/arm/mach-omap2/built-in.o: In function `omap2430_init_late':
> :(.init.text+0x1024): undefined reference to `omap2_pm_init'
> arch/arm/mach-omap2/built-in.o: In function `omap3_init_late':
> :(.init.text+0x1248): undefined reference to `omap3_pm_init'
> arch/arm/mach-omap2/built-in.o: In function `omap3430_init_late':
> :(.init.text+0x1264): undefined reference to `omap3_pm_init'
> arch/arm/mach-omap2/built-in.o: In function `omap35xx_init_late':
> :(.init.text+0x1280): undefined reference to `omap3_pm_init'
> arch/arm/mach-omap2/built-in.o: In function `omap3630_init_late':
> :(.init.text+0x129c): undefined reference to `omap3_pm_init'
> arch/arm/mach-omap2/built-in.o: In function `am35xx_init_late':
> :(.init.text+0x12b8): undefined reference to `omap3_pm_init'
> arch/arm/mach-omap2/built-in.o::(.init.text+0x12d4): more undefined references to `omap3_pm_init' follow
>
> This was compiled with allmodconfig on arm, with COMPILE_TEST
> disabled (a few sub-archs disabled too), to avoid spurious
> unrelated compilation issues).
OK thanks for pointing that out. I'll take a look at dealing with the
with omap_dma_global_context_save() and omap_dma_global_context_restore()
to fix the above.
> Am I missing something?
>
> BTW, CONFIG_PM is auto-selected by ARCH_OMAP3.
>
> And those are the functions that the OMAP3 code uses from omap-dma.h:
>
> arch/arm/mach-omap2/pm34xx.c:92:2: error: implicit declaration of function ‘omap_dma_global_context_save’ [-Werror=implicit-function-declaration]
> arch/arm/mach-omap2/pm34xx.c:103:2: error: implicit declaration of function ‘omap_dma_global_context_restore’ [-Werror=implicit-function-declaration]
> arch/arm/mach-omap2/pm24xx.c:170:2: error: implicit declaration of function ‘omap_dma_running’ [-Werror=implicit-function-declaration]
>
> Just enabling this won't work, as the code at arch/arm/plat-omap/dma.c
> depends on several other functions inside omap-dma.h.
OK so looks like omap_dma_running() is needed by the platform code too,
it's the same story.
> From: Mauro Carvalho Chehab <m.chehab@samsung.com>
> Subject: [PATCH] omap-dma: remove deprecated omap-dma.h API
>
> We want to be able to COMPILE_TEST the omap1_camera driver.
> It compiles fine, but it fails linkediting:
>
> ERROR: "omap_stop_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_start_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_dma_link_lch" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_set_dma_dest_burst_mode" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_set_dma_src_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_request_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_set_dma_transfer_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_set_dma_dest_params" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
> ERROR: "omap_free_dma" [drivers/media/platform/soc_camera/omap1_camera.ko] undefined!
>
> That's because OMAP1 is using a legacy deprecated API.
> Instead of fixing it, the right thing to do is to convert the
> remaining OMAP drivers that use the legacy API to the standard
> DMA API.
>
> While this doesn't happen, let's mark the broken stuff with
> BROKEN.
As pointed out, the proper fix for the above is to remove the broken
driver that nobody is using. Or update it to use dmaengine API if
somebody is still using it.
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -11,6 +11,16 @@ config ARCH_OMAP2
> select CPU_V6
> select SOC_HAS_OMAP2_SDRC
>
> +config OMAP2_PM24XX
> + bool
> + depends on ARCH_OMAP2
> + depends on BROKEN
> +
> +config OMAP2_PM34XX
> + bool
> + depends on ARCH_OMAP3
> + depends on BROKEN
> +
And all this should not be needed, I'll move those to a local platform
specific header file.
Regards,
Tony
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH 1/3] omap-dma: Allow compile-testing omap1_camera driver
2014-09-09 15:36 ` Mauro Carvalho Chehab
(?)
(?)
@ 2014-09-11 10:45 ` Russell King - ARM Linux
-1 siblings, 0 replies; 54+ messages in thread
From: Russell King - ARM Linux @ 2014-09-11 10:45 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, Tony Lindgren,
Vinod Koul, Arnd Bergmann, Peter Griffin, Balaji T K,
Nishanth Menon, linux-next, linux-kernel, Stephen Rothwell,
Janusz Krzysztofik, linux-omap
On Tue, Sep 09, 2014 at 12:36:54PM -0300, Mauro Carvalho Chehab wrote:
> Hmm... it seems that there are still several drivers still relying on
> the functions declared at: omap-dma.h:
>
> $ grep extern include/linux/omap-dma.h |perl -ne 'print "$1\n" if (m/extern\s\S+\s(.*)\(/)' >funcs && git grep -f funcs -l
> arch/arm/mach-omap1/pm.c
> arch/arm/mach-omap2/pm24xx.c
> arch/arm/plat-omap/dma.c
> drivers/dma/omap-dma.c
> drivers/media/platform/omap/omap_vout_vrfb.c
> drivers/media/platform/omap3isp/isphist.c
> drivers/media/platform/soc_camera/omap1_camera.c
> drivers/mtd/onenand/omap2.c
> drivers/usb/gadget/udc/omap_udc.c
> drivers/usb/musb/tusb6010_omap.c
> drivers/video/fbdev/omap/omapfb_main.c
> include/linux/omap-dma.h
>
> Perhaps we can remove the header and mark all the above as BROKEN.
Not quite. You'll notice that drivers/dma/omap-dma.c appears in that
list. That is because right now, the new code has to co-operate with
the old legacy code to ensure that both do not try and operate on the
same hardware channel simultaneously.
Right now, when anyone tries to use any of the drivers using the legacy
APIs, they will get a warning printed in their kernel message log. This
is part of my attempt to try and find out:
(a) whether anyone is using these drivers
(b) whether we can delete these drivers
That warning has not been in the kernel long enough to be certain of
anything - it was merged during the last merge window (despite me
having it ready to go since the previous merge window, it would not
have been correct to introduce a new warning during the -rc period.)
What I recommend is that you just don't mark the OMAP drivers for
compile testing right now, especially as their future is rather
uncertain.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCHv3 1/3] [media] disable OMAP1 COMPILE_TEST
2014-09-09 14:38 ` Mauro Carvalho Chehab
(?)
@ 2014-09-09 18:54 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 18:54 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Guennadi Liakhovetski, linux-next,
linux-kernel, Stephen Rothwell
This driver depends on a legacy OMAP DMA API. So, it won't
compile-test on other archs.
While we might add stubs to the functions, this is not a
good idea, as the hole API should be replaced.
So, for now, let's just remove COMPILE_TEST and wait for
some time for people to fix. If not fixed, then we'll end
by removing this driver as a hole.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
diff --git a/drivers/media/platform/soc_camera/Kconfig b/drivers/media/platform/soc_camera/Kconfig
index 6af6c6dccda8..f2776cd415ca 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -63,7 +63,7 @@ config VIDEO_SH_MOBILE_CEU
config VIDEO_OMAP1
tristate "OMAP1 Camera Interface driver"
depends on VIDEO_DEV && SOC_CAMERA
- depends on ARCH_OMAP1 || COMPILE_TEST
+ depends on ARCH_OMAP1
depends on HAS_DMA
select VIDEOBUF_DMA_CONTIG
select VIDEOBUF_DMA_SG
--
1.9.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCHv3 1/3] [media] disable OMAP1 COMPILE_TEST
@ 2014-09-09 18:54 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 18:54 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Guennadi Liakhovetski, linux-next,
linux-kernel, Stephen Rothwell
This driver depends on a legacy OMAP DMA API. So, it won't
compile-test on other archs.
While we might add stubs to the functions, this is not a
good idea, as the hole API should be replaced.
So, for now, let's just remove COMPILE_TEST and wait for
some time for people to fix. If not fixed, then we'll end
by removing this driver as a hole.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
diff --git a/drivers/media/platform/soc_camera/Kconfig b/drivers/media/platform/soc_camera/Kconfig
index 6af6c6dccda8..f2776cd415ca 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -63,7 +63,7 @@ config VIDEO_SH_MOBILE_CEU
config VIDEO_OMAP1
tristate "OMAP1 Camera Interface driver"
depends on VIDEO_DEV && SOC_CAMERA
- depends on ARCH_OMAP1 || COMPILE_TEST
+ depends on ARCH_OMAP1
depends on HAS_DMA
select VIDEOBUF_DMA_CONTIG
select VIDEOBUF_DMA_SG
--
1.9.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCHv3 1/3] [media] disable OMAP1 COMPILE_TEST
@ 2014-09-09 18:54 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 18:54 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Guennadi Liakhovetski, linux-next,
linux-kernel, Stephen Rothwell
This driver depends on a legacy OMAP DMA API. So, it won't
compile-test on other archs.
While we might add stubs to the functions, this is not a
good idea, as the hole API should be replaced.
So, for now, let's just remove COMPILE_TEST and wait for
some time for people to fix. If not fixed, then we'll end
by removing this driver as a hole.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
diff --git a/drivers/media/platform/soc_camera/Kconfig b/drivers/media/platform/soc_camera/Kconfig
index 6af6c6dccda8..f2776cd415ca 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -63,7 +63,7 @@ config VIDEO_SH_MOBILE_CEU
config VIDEO_OMAP1
tristate "OMAP1 Camera Interface driver"
depends on VIDEO_DEV && SOC_CAMERA
- depends on ARCH_OMAP1 || COMPILE_TEST
+ depends on ARCH_OMAP1
depends on HAS_DMA
select VIDEOBUF_DMA_CONTIG
select VIDEOBUF_DMA_SG
--
1.9.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCHv3 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
2014-09-09 18:54 ` Mauro Carvalho Chehab
(?)
(?)
@ 2014-09-09 18:54 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 18:54 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Kukjin Kim, Jacek Anaszewski,
Kamil Debski, Sylwester Nawrocki, Kyungmin Park,
linux-arm-kernel, linux-samsung-soc, linux-next, linux-kernel,
Stephen Rothwell
ERROR: "__bad_ndelay" [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined!
That happens because asm-generic doesn't like any ndelay time
bigger than 20us.
Currently, usleep_range() couldn't simply be used, since
exynos4_jpeg_sw_reset() is called with a spinlock held.
So, let's use udelay() instead.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@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..ab6d6f43c96f 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
@@ -23,7 +23,7 @@ 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);
- ndelay(100000);
+ udelay(100);
writel(reg | EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG);
}
--
1.9.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCHv3 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
@ 2014-09-09 18:54 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 18:54 UTC (permalink / raw)
To: linux-arm-kernel
ERROR: "__bad_ndelay" [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined!
That happens because asm-generic doesn't like any ndelay time
bigger than 20us.
Currently, usleep_range() couldn't simply be used, since
exynos4_jpeg_sw_reset() is called with a spinlock held.
So, let's use udelay() instead.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@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..ab6d6f43c96f 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
@@ -23,7 +23,7 @@ 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);
- ndelay(100000);
+ udelay(100);
writel(reg | EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG);
}
--
1.9.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCHv3 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
@ 2014-09-09 18:54 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 18:54 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Kukjin Kim, Jacek Anaszewski,
Kamil Debski, Sylwester Nawrocki, Kyungmin Park,
linux-arm-kernel, linux-samsung-soc, linux-next, linux-kernel,
Stephen Rothwell
ERROR: "__bad_ndelay" [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined!
That happens because asm-generic doesn't like any ndelay time
bigger than 20us.
Currently, usleep_range() couldn't simply be used, since
exynos4_jpeg_sw_reset() is called with a spinlock held.
So, let's use udelay() instead.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@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..ab6d6f43c96f 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
@@ -23,7 +23,7 @@ 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);
- ndelay(100000);
+ udelay(100);
writel(reg | EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG);
}
--
1.9.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCHv3 2/3] [media] s5p-jpeg: Fix compilation with COMPILE_TEST
@ 2014-09-09 18:54 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 18:54 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Kukjin Kim, Jacek Anaszewski,
Kamil Debski, Sylwester Nawrocki, Kyungmin Park,
linux-arm-kernel, linux-samsung-soc, linux-next, linux-kernel,
Stephen Rothwell
ERROR: "__bad_ndelay" [drivers/media/platform/s5p-jpeg/s5p-jpeg.ko] undefined!
That happens because asm-generic doesn't like any ndelay time
bigger than 20us.
Currently, usleep_range() couldn't simply be used, since
exynos4_jpeg_sw_reset() is called with a spinlock held.
So, let's use udelay() instead.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@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..ab6d6f43c96f 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
@@ -23,7 +23,7 @@ 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);
- ndelay(100000);
+ udelay(100);
writel(reg | EXYNOS4_SOFT_RESET_HI, base + EXYNOS4_JPEG_CNTL_REG);
}
--
1.9.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCHv3 3/3] [media] vpif: Fix compilation with allmodconfig
2014-09-09 18:54 ` Mauro Carvalho Chehab
(?)
@ 2014-09-09 18:54 ` Mauro Carvalho Chehab
-1 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 18:54 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Lad, Prabhakar, davinci-linux-open-source,
linux-next, linux-kernel, Stephen Rothwell
When vpif is compiled as module, those errors happen:
ERROR: "vpif_lock" [drivers/media/platform/davinci/vpif_display.ko] undefined!
ERROR: "vpif_lock" [drivers/media/platform/davinci/vpif_capture.ko] undefined!
That's because vpif_lock symbol is not exported.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c
index cd08e5248387..3dad5bd7fe0a 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -38,6 +38,7 @@ MODULE_LICENSE("GPL");
#define VPIF_CH3_MAX_MODES 2
spinlock_t vpif_lock;
+EXPORT_SYMBOL_GPL(vpif_lock);
void __iomem *vpif_base;
EXPORT_SYMBOL_GPL(vpif_base);
--
1.9.3
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCHv3 3/3] [media] vpif: Fix compilation with allmodconfig
@ 2014-09-09 18:54 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 18:54 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Lad, Prabhakar, davinci-linux-open-source,
linux-next, linux-kernel, Stephen Rothwell
When vpif is compiled as module, those errors happen:
ERROR: "vpif_lock" [drivers/media/platform/davinci/vpif_display.ko] undefined!
ERROR: "vpif_lock" [drivers/media/platform/davinci/vpif_capture.ko] undefined!
That's because vpif_lock symbol is not exported.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c
index cd08e5248387..3dad5bd7fe0a 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -38,6 +38,7 @@ MODULE_LICENSE("GPL");
#define VPIF_CH3_MAX_MODES 2
spinlock_t vpif_lock;
+EXPORT_SYMBOL_GPL(vpif_lock);
void __iomem *vpif_base;
EXPORT_SYMBOL_GPL(vpif_base);
--
1.9.3
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCHv3 3/3] [media] vpif: Fix compilation with allmodconfig
@ 2014-09-09 18:54 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 54+ messages in thread
From: Mauro Carvalho Chehab @ 2014-09-09 18:54 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, Linux Media Mailing List,
Mauro Carvalho Chehab, Lad, Prabhakar, davinci-linux-open-source,
linux-next, linux-kernel, Stephen Rothwell
When vpif is compiled as module, those errors happen:
ERROR: "vpif_lock" [drivers/media/platform/davinci/vpif_display.ko] undefined!
ERROR: "vpif_lock" [drivers/media/platform/davinci/vpif_capture.ko] undefined!
That's because vpif_lock symbol is not exported.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c
index cd08e5248387..3dad5bd7fe0a 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -38,6 +38,7 @@ MODULE_LICENSE("GPL");
#define VPIF_CH3_MAX_MODES 2
spinlock_t vpif_lock;
+EXPORT_SYMBOL_GPL(vpif_lock);
void __iomem *vpif_base;
EXPORT_SYMBOL_GPL(vpif_base);
--
1.9.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* Re: [PATCHv3 1/3] [media] disable OMAP1 COMPILE_TEST
2014-09-09 18:54 ` Mauro Carvalho Chehab
` (3 preceding siblings ...)
(?)
@ 2014-09-09 20:36 ` Guennadi Liakhovetski
-1 siblings, 0 replies; 54+ messages in thread
From: Guennadi Liakhovetski @ 2014-09-09 20:36 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Media Mailing List, Mauro Carvalho Chehab, linux-next,
linux-kernel, Stephen Rothwell
Thanks, Mauro,
On Tue, 9 Sep 2014, Mauro Carvalho Chehab wrote:
> This driver depends on a legacy OMAP DMA API. So, it won't
> compile-test on other archs.
>
> While we might add stubs to the functions, this is not a
> good idea, as the hole API should be replaced.
>
> So, for now, let's just remove COMPILE_TEST and wait for
> some time for people to fix. If not fixed, then we'll end
> by removing this driver as a hole.
>
> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Regards
Guennadi
>
> diff --git a/drivers/media/platform/soc_camera/Kconfig b/drivers/media/platform/soc_camera/Kconfig
> index 6af6c6dccda8..f2776cd415ca 100644
> --- a/drivers/media/platform/soc_camera/Kconfig
> +++ b/drivers/media/platform/soc_camera/Kconfig
> @@ -63,7 +63,7 @@ config VIDEO_SH_MOBILE_CEU
> config VIDEO_OMAP1
> tristate "OMAP1 Camera Interface driver"
> depends on VIDEO_DEV && SOC_CAMERA
> - depends on ARCH_OMAP1 || COMPILE_TEST
> + depends on ARCH_OMAP1
> depends on HAS_DMA
> select VIDEOBUF_DMA_CONTIG
> select VIDEOBUF_DMA_SG
> --
> 1.9.3
>
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCHv3 1/3] [media] disable OMAP1 COMPILE_TEST
2014-09-09 18:54 ` Mauro Carvalho Chehab
` (4 preceding siblings ...)
(?)
@ 2014-09-10 8:04 ` Bartlomiej Zolnierkiewicz
2014-09-10 8:19 ` Bartlomiej Zolnierkiewicz
-1 siblings, 1 reply; 54+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2014-09-10 8:04 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Media Mailing List, Mauro Carvalho Chehab,
Guennadi Liakhovetski, linux-next, linux-kernel,
Stephen Rothwell
Hi,
On Tuesday, September 09, 2014 03:54:04 PM Mauro Carvalho Chehab wrote:
> This driver depends on a legacy OMAP DMA API. So, it won't
> compile-test on other archs.
>
> While we might add stubs to the functions, this is not a
> good idea, as the hole API should be replaced.
This is also not a good idea becaouse it would break the driver
for OMAP1 once somebody enables COMPILE_TEST option while also
having ARCH_OMAP1 enabled (which is perfectly fine and shouldn't
cause the driver breakage). In general COMPILE_TEST option is
completely independent from the arch specific ones and it should
not change behaviour of the existing code.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> So, for now, let's just remove COMPILE_TEST and wait for
> some time for people to fix. If not fixed, then we'll end
> by removing this driver as a hole.
>
> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
>
> diff --git a/drivers/media/platform/soc_camera/Kconfig b/drivers/media/platform/soc_camera/Kconfig
> index 6af6c6dccda8..f2776cd415ca 100644
> --- a/drivers/media/platform/soc_camera/Kconfig
> +++ b/drivers/media/platform/soc_camera/Kconfig
> @@ -63,7 +63,7 @@ config VIDEO_SH_MOBILE_CEU
> config VIDEO_OMAP1
> tristate "OMAP1 Camera Interface driver"
> depends on VIDEO_DEV && SOC_CAMERA
> - depends on ARCH_OMAP1 || COMPILE_TEST
> + depends on ARCH_OMAP1
> depends on HAS_DMA
> select VIDEOBUF_DMA_CONTIG
> select VIDEOBUF_DMA_SG
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCHv3 1/3] [media] disable OMAP1 COMPILE_TEST
2014-09-10 8:04 ` Bartlomiej Zolnierkiewicz
@ 2014-09-10 8:19 ` Bartlomiej Zolnierkiewicz
0 siblings, 0 replies; 54+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2014-09-10 8:19 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Media Mailing List, Mauro Carvalho Chehab,
Guennadi Liakhovetski, linux-next, linux-kernel,
Stephen Rothwell
On Wednesday, September 10, 2014 10:04:12 AM Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Tuesday, September 09, 2014 03:54:04 PM Mauro Carvalho Chehab wrote:
> > This driver depends on a legacy OMAP DMA API. So, it won't
> > compile-test on other archs.
> >
> > While we might add stubs to the functions, this is not a
> > good idea, as the hole API should be replaced.
>
> This is also not a good idea becaouse it would break the driver
> for OMAP1 once somebody enables COMPILE_TEST option while also
> having ARCH_OMAP1 enabled (which is perfectly fine and shouldn't
> cause the driver breakage). In general COMPILE_TEST option is
> completely independent from the arch specific ones and it should
> not change behaviour of the existing code.
Small clarification:
I was of course referring to the original patch for the issue:
https://lkml.org/lkml/2014/9/9/498
stubs can be added properly with using
#if defined(CONFIG_COMPILE_TEST) && !defined(CONFIG_ARCH_OMAP1)
similarly like it is handled for ARCH_QCOM in
drivers/gpu/drm/msm/msm_drv.h
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply [flat|nested] 54+ messages in thread