Re: [PATCH] [media] V4L: s5c73m3: Fix build after v4l2_of_get_next_endpoint rename
On Wed, 9 Apr 2014, Krzysztof Kozlowski wrote:
Fix build error after v4l2_of_get_next_endpoint rename (fd9fdb78a9bf:
[media] of: move graph helpers from drivers/media/v4l2-core...):
drivers/media/i2c/s5c73m3/s5c73m3-core.c: In function
‘s5c73m3_get_platform_data’:
drivers/media/i2c/s5c73m3/s5c73m3-core.c:1619:2: error: implicit declaration
of function ‘v4l2_of_get_next_endpoint’
[-Werror=implicit-function-declaration]
drivers/media/i2c/s5c73m3/s5c73m3-core.c:1619:10: warning: assignment makes
pointer from integer without a cast [enabled by default]
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
drivers/media/i2c/s5c73m3/s5c73m3-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
index a4459301b5f8..ee0f57e01b56 100644
--- a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
+++ b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
@@ -1616,7 +1616,7 @@ static int s5c73m3_get_platform_data(struct s5c73m3
*state)
if (ret 0)
return -EINVAL;
- node_ep = v4l2_of_get_next_endpoint(node, NULL);
+ node_ep = of_graph_get_next_endpoint(node, NULL);
if (!node_ep) {
dev_warn(dev, no endpoint defined for node: %s\n,
node-full_name);
Acked-by: David Rientjes rient...@google.com
The build error that this patch fixes is still present in Linus's tree,
and there's been no response to it in two weeks. Any chance of this
getting merged?
Re: linux-next: Tree for May 1 (media/usb/stk1160)
On Wed, 1 May 2013, Yann E. MORIN wrote: When CONFIG_SND=m and CONFIG_SND_AC97_CODEC=m and CONFIG_VIDEO_STK1160=y CONFIG_VIDEO_STK1160_AC97=y drivers/built-in.o: In function `stk1160_ac97_register': (.text+0x122706): undefined reference to `snd_card_create' drivers/built-in.o: In function `stk1160_ac97_register': (.text+0x1227b2): undefined reference to `snd_ac97_bus' drivers/built-in.o: In function `stk1160_ac97_register': (.text+0x1227cd): undefined reference to `snd_card_free' drivers/built-in.o: In function `stk1160_ac97_register': (.text+0x12281b): undefined reference to `snd_ac97_mixer' drivers/built-in.o: In function `stk1160_ac97_register': (.text+0x122832): undefined reference to `snd_card_register' drivers/built-in.o: In function `stk1160_ac97_unregister': (.text+0x12285e): undefined reference to `snd_card_free' This kconfig fragment: config VIDEO_STK1160_AC97 bool STK1160 AC97 codec support depends on VIDEO_STK1160 SND This doesn't depend on SND, it depends on SND=y. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for May 1 (media/usb/stk1160)
On Wed, 1 May 2013, Randy Dunlap wrote: When CONFIG_SND=m and CONFIG_SND_AC97_CODEC=m and CONFIG_VIDEO_STK1160=y CONFIG_VIDEO_STK1160_AC97=y drivers/built-in.o: In function `stk1160_ac97_register': (.text+0x122706): undefined reference to `snd_card_create' drivers/built-in.o: In function `stk1160_ac97_register': (.text+0x1227b2): undefined reference to `snd_ac97_bus' drivers/built-in.o: In function `stk1160_ac97_register': (.text+0x1227cd): undefined reference to `snd_card_free' drivers/built-in.o: In function `stk1160_ac97_register': (.text+0x12281b): undefined reference to `snd_ac97_mixer' drivers/built-in.o: In function `stk1160_ac97_register': (.text+0x122832): undefined reference to `snd_card_register' drivers/built-in.o: In function `stk1160_ac97_unregister': (.text+0x12285e): undefined reference to `snd_card_free' This kconfig fragment: config VIDEO_STK1160_AC97 bool STK1160 AC97 codec support depends on VIDEO_STK1160 SND This doesn't depend on SND, it depends on SND=y. -- Maybe this option *should* depend on SND=y, but that's not what the kconfig syntax says. The kconfig language does not care if the variable is a bool or a tristate when evaluating a depends expression AFAICT (but I am only reading Documentation/kbuild/kconfig-language.txt, not the source code). Doing depends on SND=y will only allow an option to be enabled if SND is builtin so the snd_card_* functions above will be defined (with your config we have a builtin function calling a module which may or may not be loaded). I think you've already addressed the snd_ac97_* functions, so the fix here should be relatively simple. Yann? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -next] media:
On Tue, 9 Apr 2013, Antti Palosaari wrote: On 04/08/2013 08:47 PM, Randy Dunlap wrote: From: Randy Dunlap rdun...@infradead.org Fix randconfig error when USB is not enabled: ERROR: usb_control_msg [drivers/media/common/cypress_firmware.ko] undefined! Signed-off-by: Randy Dunlap rdun...@infradead.org Cc: Antti Palosaari cr...@iki.fi Reviewed-by: Antti Palosaari cr...@iki.fi --- drivers/media/common/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-next-20130408.orig/drivers/media/common/Kconfig +++ linux-next-20130408/drivers/media/common/Kconfig @@ -18,6 +18,7 @@ config VIDEO_TVEEPROM config CYPRESS_FIRMWARE tristate Cypress firmware helper routines + depends on USB source drivers/media/common/b2c2/Kconfig source drivers/media/common/saa7146/Kconfig Mauro, this problem persists in linux-next seven days later, any chance we can get this fix from Randy merged? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for 3.6-rc1] media updates part 2
On Thu, 9 Aug 2012, Mauro Carvalho Chehab wrote: Yeah, that would work as well, although the code would look uglier. IMHO, using select/depend is better. Agreed, I think it should be depends on LEDS_CLASS rather than select it if there is a hard dependency that cannot be fixed with extracting the led support in the driver to #ifdef CONFIG_LEDS_CLASS code. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for 3.6-rc1] media updates part 2
On Tue, 31 Jul 2012, Mauro Carvalho Chehab wrote: [media] radio-shark: New driver for the Griffin radioSHARK USB radio receiver This one gives me a build warning if CONFIG_LEDS_CLASS is disabled: ERROR: led_classdev_register [drivers/media/radio/shark2.ko] undefined! ERROR: led_classdev_unregister [drivers/media/radio/shark2.ko] undefined! -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel OOPS when releasing usb webcam (random)
On Tue, 18 Oct 2011, David Rientjes wrote: Guennadi or Mauro, how is this going to Linus? It sounds like 3.1 material since we've received at least a couple of reports of this in the past week. This fix is now in Linus' tree at e58fced201ad ([media] videodev: fix a NULL pointer dereference in v4l2_device_release()) for 3.1. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] videodev: fix a NULL pointer dereference in v4l2_device_release()
On Tue, 18 Oct 2011, Antonio Ospite wrote: can anyone reproduce this? Ping. David, does the change below fix it for you, I sent the patch last week. I never had the problem. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel OOPS when releasing usb webcam (random)
On Tue, 18 Oct 2011, Antonio Ospite wrote: im getting the following null pointer dereference from time to time when releasing a usb camera. maybe this trace is of assistance...please reply to my mail since im not subscribed. I suspect this is happening in v4l2_device_unregister_subdev(). Adding Guennadi, Mauro, and linux-media. BUG: unable to handle kernel NULL pointer dereference at 006c IP: [f90be6c2] v4l2_device_release+0xa2/0xf0 [videodev] Hi, I sent a fix for a similar trace last week: http://patchwork.linuxtv.org/patch/8124/ Tomas, can you test it fixes the problem for you too? Tomas reported that the same change from Frederik Deweerdt fixed the issue, so you can add his tested-by from https://lkml.org/lkml/2011/10/18/298. Guennadi or Mauro, how is this going to Linus? It sounds like 3.1 material since we've received at least a couple of reports of this in the past week. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel OOPS when releasing usb webcam (random)
On Mon, 17 Oct 2011, Tomas M. wrote: im getting the following null pointer dereference from time to time when releasing a usb camera. maybe this trace is of assistance...please reply to my mail since im not subscribed. I suspect this is happening in v4l2_device_unregister_subdev(). Adding Guennadi, Mauro, and linux-media. BUG: unable to handle kernel NULL pointer dereference at 006c IP: [f90be6c2] v4l2_device_release+0xa2/0xf0 [videodev] *pde = Oops: [#1] PREEMPT SMP Modules linked in: fuse arc4 rt73usb rt2x00usb rt2x00lib mac80211 cfg80211 rfkill gspca_zc3xx gspca_main videodev joydev snd_hda_codec_si3054 sg 8139too snd_hda_codec_realtek firewire_ohci firewire_core mmc_core snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore mii crc_itu_t snd_page_alloc iTCO_wdt iTCO_vendor_support i2c_i801 evdev psmouse thermal battery serio_raw ac cpufreq_ondemand acpi_cpufreq freq_table processor mperf usbhid hid ext3 jbd mbcache sd_mod sr_mod cdrom pata_acpi uhci_hcd ata_piix ehci_hcd libata scsi_mod usbcore [last unloaded: sdhci] Pid: 171, comm: khubd Not tainted 3.1.0-rc9 #66 Everex Systems, Inc. Everex StepNote Series/Everex StepNote Series EIP: 0060:[f90be6c2] EFLAGS: 00010292 CPU: 0 EIP is at v4l2_device_release+0xa2/0xf0 [videodev] EAX: EBX: f5636004 ECX: EDX: ESI: f5636000 EDI: EBP: f563600c ESP: f5627e38 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process khubd (pid: 171, ti=f5626000 task=f554dc00 task.ti=f5626000) Stack: ef000480 c1433780 f5474b00 c12343f8 f54e7e1c c114737a f563600c f5636028 c114605d f5636028 c1146020 f91512d4 c114737a f54e7e1c f54e7e00 f81623f4 f56d4000 f54e7e1c f91512d4 f56d4064 0001 c12373b7 Call Trace: [c12343f8] ? device_release+0x18/0x80 [c114737a] ? kref_put+0x2a/0x60 [c114605d] ? kobject_release+0x3d/0xa0 [c1146020] ? kobject_del+0x30/0x30 [c114737a] ? kref_put+0x2a/0x60 [f81623f4] ? usb_unbind_interface+0x34/0x130 [usbcore] [c12373b7] ? __device_release_driver+0x57/0xb0 [c123742d] ? device_release_driver+0x1d/0x30 [c1236fc2] ? bus_remove_device+0x72/0x90 [c12350bf] ? device_del+0xdf/0x150 [f8160591] ? usb_disable_device+0x81/0x180 [usbcore] [f8159b3b] ? usb_disconnect+0x8b/0x110 [usbcore] [f815b76c] ? hub_thread+0x97c/0x1180 [usbcore] [c102d80b] ? pick_next_task_fair+0x8b/0xe0 [c1052600] ? abort_exclusive_wait+0x90/0x90 [f815adf0] ? usb_remote_wakeup+0x40/0x40 [usbcore] [c1052029] ? kthread+0x69/0x70 [c1051fc0] ? kthread_worker_fn+0x150/0x150 [c130d8be] ? kernel_thread_helper+0x6/0xd Code: 83 94 01 00 00 c7 83 60 01 00 00 00 00 00 00 0f b7 93 9c 01 00 00 c1 e0 05 f0 0f b3 90 c0 e7 0c f9 b8 20 e1 0c f9 e8 4e cf 24 c8 8b 57 6c 89 f0 85 d2 74 25 ff 93 c8 01 00 00 85 ff 74 21 89 f8 EIP: [f90be6c2] v4l2_device_release+0xa2/0xf0 [videodev] SS:ESP 0068:f5627e38 CR2: 006c ---[ end trace 39522f0f1757c8f8 ]--- -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL for v3.0] OMAP_VOUT bug fixes and code cleanup
On Thu, 7 Jul 2011, JAIN, AMBER wrote: I think what David wants to say is that if we do not have DMA restrictions on OMAP we should have not used GFP_DMA flag for page allocation at first place. Is my understanding correct David? Right, and that's what the patch is doing. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL for v3.0] OMAP_VOUT bug fixes and code cleanup
On Tue, 5 Jul 2011, JAIN, AMBER wrote:
diff --git a/drivers/media/video/omap24xxcam.c
b/drivers/media/video/omap24xxcam.c
index f6626e8..d92d4c6 100644
--- a/drivers/media/video/omap24xxcam.c
+++ b/drivers/media/video/omap24xxcam.c
@@ -309,11 +309,11 @@ static int
omap24xxcam_vbq_alloc_mmap_buffer(struct videobuf_buffer *vb)
order--;
/* try to allocate as many contiguous pages as possible */
- page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
+ page = alloc_pages(GFP_KERNEL, order);
/* if allocation fails, try to allocate smaller amount */
while (page == NULL) {
order--;
- page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
+ page = alloc_pages(GFP_KERNEL, order);
if (page == NULL !order) {
err = -ENOMEM;
goto out;
Hmm... the proper fix wouldn't be to define ZONE_DMA at OMAP?
I don't think so, my understanding for ZOME_DMA is that it is defined
for architectures that have restrictions on memory addresses that can be
used for DMA. OMAP doesn't have any such restriction and hence we should
not define ZONE_DMA.
s/should not define/do not need to define/
Right, if omap does not have DMA restrictions then the GFP_DMA usage that
is removed with this patch was incorrect.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
