[PATCH 2/2] [media] uvcvideo: Kill video URBs on disconnect
When an in-use webcam is disconnected, I noticed the following messages: uvcvideo: Failed to resubmit video URB (-19). -19 is -ENODEV, which does make sense given that the device has disappeared. We could put a case for -ENODEV like we have with -ENOENT, -ECONNRESET and -ESHUTDOWN, but the usb_unlink_urb() API documentation says that 'The disconnect function should synchronize with a driver's I/O routines to insure that all URB-related activity has completed before it returns.' So we should make an effort to proactively kill URBs in the disconnect path instead. Call uvc_enable_video() (specifying 0 to disable) in the disconnect path, which kills and frees URBs. Cc: Laurent Pinchart Signed-off-by: Daniel Axtens --- Before this patch, yavta -c hangs when a camera is disconnected, but with this patch it exits immediately after the camera is disconnected. I'm not sure if this is acceptable - Laurent? --- drivers/media/usb/uvc/uvc_driver.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c index 2390592f78e0..647e3d8a1256 100644 --- a/drivers/media/usb/uvc/uvc_driver.c +++ b/drivers/media/usb/uvc/uvc_driver.c @@ -1877,6 +1877,8 @@ static void uvc_unregister_video(struct uvc_device *dev) if (!video_is_registered(&stream->vdev)) continue; + uvc_video_enable(stream, 0); + video_unregister_device(&stream->vdev); uvc_debugfs_cleanup_stream(stream); -- 2.9.3
[PATCH 1/2] [media] uvcvideo: Refactor teardown of uvc on USB disconnect
Currently, disconnecting a USB webcam while it is in use prints out a
number of warnings, such as:
WARNING: CPU: 2 PID: 3118 at
/build/linux-ezBi1T/linux-4.8.0/fs/sysfs/group.c:237
sysfs_remove_group+0x8b/0x90
sysfs group a7cd0780 not found for kobject 'event13'
This has been noticed before. [0]
This is because of the order in which things are torn down.
If there are no streams active during a USB disconnect:
- uvc_disconnect() is invoked via device_del() through the bus
notifier mechanism.
- this calls uvc_unregister_video().
- uvc_unregister_video() unregisters the video device for each
stream,
- because there are no streams open, it calls uvc_delete()
- uvc_delete() calls uvc_status_cleanup(), which cleans up the status
input device.
- uvc_delete() calls media_device_unregister(), which cleans up the
media device
- uvc_delete(), uvc_unregister_video() and uvc_disconnect() all
return, and we end up back in device_del().
- device_del() then cleans up the sysfs folder for the camera with
dpm_sysfs_remove(). Because uvc_status_cleanup() and
media_device_unregister() have already been called, this all works
nicely.
If, on the other hand, there *are* streams active during a USB disconnect:
- uvc_disconnect() is invoked
- this calls uvc_unregister_video()
- uvc_unregister_video() unregisters the video device for each
stream,
- uvc_unregister_video() and uvc_disconnect() return, and we end up
back in device_del().
- device_del() then cleans up the sysfs folder for the camera with
dpm_sysfs_remove(). Because the status input device and the media
device are children of the USB device, this also deletes their
sysfs folders.
- Sometime later, the final stream is closed, invoking uvc_release().
- uvc_release() calls uvc_delete()
- uvc_delete() calls uvc_status_cleanup(), which cleans up the status
input device. Because the sysfs directory has already been removed,
this causes a WARNing.
- uvc_delete() calls media_device_unregister(), which cleans up the
media device. Because the sysfs directory has already been removed,
this causes another WARNing.
To fix this, we need to make sure the devices are always unregistered
before the end of uvc_disconnect(). To this, move the unregistration
into the disconnect path:
- split uvc_status_cleanup() into two parts, one on disconnect that
unregisters and one on delete that frees.
- move media_device_unregister() into the disconnect path.
[0]: https://lkml.org/lkml/2016/12/8/657
Cc: Laurent Pinchart
Cc: Dave Stevenson
Cc: Greg KH
Signed-off-by: Daniel Axtens
---
Tested with cheese and yavta.
---
drivers/media/usb/uvc/uvc_driver.c | 8 ++--
drivers/media/usb/uvc/uvc_status.c | 8 ++--
drivers/media/usb/uvc/uvcvideo.h | 1 +
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 46d6be0bb316..2390592f78e0 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1815,8 +1815,6 @@ static void uvc_delete(struct uvc_device *dev)
if (dev->vdev.dev)
v4l2_device_unregister(&dev->vdev);
#ifdef CONFIG_MEDIA_CONTROLLER
- if (media_devnode_is_registered(dev->mdev.devnode))
- media_device_unregister(&dev->mdev);
media_device_cleanup(&dev->mdev);
#endif
@@ -1884,6 +1882,12 @@ static void uvc_unregister_video(struct uvc_device *dev)
uvc_debugfs_cleanup_stream(stream);
}
+ uvc_status_unregister(dev);
+#ifdef CONFIG_MEDIA_CONTROLLER
+ if (media_devnode_is_registered(dev->mdev.devnode))
+ media_device_unregister(&dev->mdev);
+#endif
+
/* Decrement the stream count and call uvc_delete explicitly if there
* are no stream left.
*/
diff --git a/drivers/media/usb/uvc/uvc_status.c
b/drivers/media/usb/uvc/uvc_status.c
index f552ab997956..95709b23d3b4 100644
--- a/drivers/media/usb/uvc/uvc_status.c
+++ b/drivers/media/usb/uvc/uvc_status.c
@@ -198,12 +198,16 @@ int uvc_status_init(struct uvc_device *dev)
return 0;
}
-void uvc_status_cleanup(struct uvc_device *dev)
+void uvc_status_unregister(struct uvc_device *dev)
{
usb_kill_urb(dev->int_urb);
+ uvc_input_cleanup(dev);
+}
+
+void uvc_status_cleanup(struct uvc_device *dev)
+{
usb_free_urb(dev->int_urb);
kfree(dev->status);
- uvc_input_cleanup(dev);
}
int uvc_status_start(struct uvc_device *dev, gfp_t flags)
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 15e415e32c7f..4b4814df35cd 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -712,6 +712,7 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
/* Status */
extern int uvc_status_init(struct uvc_device *dev);
+extern void uvc_status_unregister(struct uvc_device *dev);
extern void uvc_stat
Re: uvcvideo logging kernel warnings on device disconnect
Hi, >> > I hate to pester, but wondered if you had found anything obvious. >> > I really do appreciate you taking the time to look. >> >> Sorry, I haven't had the chance and now will not be able to until >> January > > Did you mean January 2017 or 2018 ? :-) I stumbled across this problem independently, and with the help of some of the info on this thread (especially yavta), I have what I think is a solution: https://patchwork.kernel.org/patch/9683663/ Regards, Daniel
[PATCH] [media] atmel-isc: Fix the static checker warning
Initialize the pointer 'fmt' before the start of
the loop.
Reported-by: Dan Carpenter
Signed-off-by: Songjun Wu
---
drivers/media/platform/atmel/atmel-isc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/atmel/atmel-isc.c
b/drivers/media/platform/atmel/atmel-isc.c
index 7dacf8c1354f..c4b2115559a5 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -1490,6 +1490,7 @@ static int isc_formats_init(struct isc_device *isc)
}
}
+ fmt = &isc_formats[0];
for (i = 0, num_fmts = 0; i < ARRAY_SIZE(isc_formats); i++) {
if (fmt->isc_support || fmt->sd_support)
num_fmts++;
--
2.11.0
[PATCH] Make DMABUF a menuconfig to ease disabling it all
No need to get into the submenu to disable all DMABUF-related config entries Make the selecters also select the new DMABUF menuconfig Signed-off-by: Vincent Legoll --- drivers/dma-buf/Kconfig | 7 --- drivers/gpu/drm/Kconfig | 1 + drivers/gpu/drm/msm/Kconfig | 1 + 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index ed3b785..ad5075f 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -1,8 +1,10 @@ -menu "DMABUF options" +menuconfig DMABUF + bool "DMABUF options" config SYNC_FILE bool "Explicit Synchronization Framework" default n + depends on DMABUF select ANON_INODES select DMA_SHARED_BUFFER ---help--- @@ -20,6 +22,7 @@ config SYNC_FILE config SW_SYNC bool "Sync File Validation Framework" default n + depends on DMABUF depends on SYNC_FILE depends on DEBUG_FS ---help--- @@ -29,5 +32,3 @@ config SW_SYNC WARNING: improper use of this can result in deadlocking kernel drivers from userspace. Intended for test and debug only. - -endmenu diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 88e01e08e..c9c21c8 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -12,6 +12,7 @@ menuconfig DRM select I2C select I2C_ALGOBIT select DMA_SHARED_BUFFER + select DMABUF select SYNC_FILE help Kernel-level support for the Direct Rendering Infrastructure (DRI) diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig index 5b8e23d..fdc621b 100644 --- a/drivers/gpu/drm/msm/Kconfig +++ b/drivers/gpu/drm/msm/Kconfig @@ -12,6 +12,7 @@ config DRM_MSM select TMPFS select QCOM_SCM select SND_SOC_HDMI_CODEC if SND_SOC + select DMABUF select SYNC_FILE default y help -- 2.9.3
Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page
On Sun, Apr 16, 2017 at 07:10:21PM -0600, Shuah Khan wrote: > On 04/14/2017 03:46 AM, Russell King - ARM Linux wrote: > > On Fri, Apr 14, 2017 at 09:56:07AM +0200, Marek Szyprowski wrote: > This would be however quite large task, especially taking into account > all current users of DMA-buf framework... > >>> Yeah it will be a large task. > >> > >> Maybe once scatterlist are switched to pfns, changing dmabuf internal > >> memory representation to pfn array might be much easier. > > > > Switching to a PFN array won't work either as we have no cross-arch > > way to translate PFNs to a DMA address and vice versa. Yes, we have > > them in ARM, but they are an _implementation detail_ of ARM's > > DMA API support, they are not for use by drivers. > > > > So, the very first problem that needs solving is this: > > > > How do we go from a coherent DMA allocation for device X to a set > > of DMA addresses for device Y. > > > > Essentially, we need a way of remapping the DMA buffer for use with > > another device, and returning a DMA address suitable for that device. > > This could well mean that we need to deal with setting up an IOMMU > > mapping. My guess is that this needs to happen at the DMA coherent > > API level - the DMA coherent API needs to be augmented with support > > for this. I'll call this "DMA coherent remap". > > > > We then need to think about how to pass this through the dma-buf API. > > dma_map_sg() is done by the exporter, who should know what kind of > > memory is being exported. The exporter can avoid calling dma_map_sg() > > if it knows in advance that it is exporting DMA coherent memory. > > Instead, the exporter can simply create a scatterlist with the DMA > > address and DMA length prepopulated with the results of the DMA > > coherent remap operation above. > > The only way to conclusively say that it is coming from coherent area > is at the time it is getting allocated in dma_alloc_from_coherent(). > Since dma_alloc_attrs() will go on to find memory from other areas if > dma_alloc_from_coherent() doesn't allocate memory. Sorry, I disagree. The only thing that matters is "did this memory come from dma_alloc_coherent()". It doesn't matter where dma_alloc_coherent() ultimately got the memory from, it's memory from the coherent allocator interface, and it should not be passed back into the streaming APIs. It is, after all, DMA _coherent_ memory, passing it into the streaming APIs which is for DMA _noncoherent_ memory is insane - the streaming APIs can bring extra expensive cache flushes, which are not required for DMA _coherent_ memory. The exporter should know where it got the memory from. It's really not sane for anyone except the _original_ allocator to be exporting memory through a DMA buffer - only the original allocator knows the properties of that memory, and how to map it, whether that be for DMA, kmap or mmap. If a dmabuf is imported into a driver and then re-exported, the original dmabuf should be what is re-exported, not some creation of the driver - the re-exporting driver can't know what the properties of the memory backing the dmabuf are, so anything else is just insane. > How about adding get_sgtable, map_sg, unmap_sg to dma_buf_ops. The right > ops need to be installed based on buffer type. As I mentioned before, we > don't know which memory we got until dma_alloc_from_coherent() finds > memory in dev->mem area. So how about using the dma_check_dev_coherent() > to determine which ops we need. These could be set based on buffer type. > vb2_dc_get_dmabuf() can do that. Given my statement above, I don't believe any of that is necessary. All memory allocated from dma_alloc_coherent() is DMA coherent. So, if memory was obtained from dma_alloc_coherent() or similar, then it must not be passed to the streaming DMA API. It doesn't matter where it ultimately came from. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Re: [PATCH 1/2] [media] uvcvideo: Refactor teardown of uvc on USB disconnect
Hi Daniel, Thank you for the patch (and the investigation). On Monday 17 Apr 2017 18:52:39 Daniel Axtens wrote: > Currently, disconnecting a USB webcam while it is in use prints out a > number of warnings, such as: > > WARNING: CPU: 2 PID: 3118 at > /build/linux-ezBi1T/linux-4.8.0/fs/sysfs/group.c:237 > sysfs_remove_group+0x8b/0x90 sysfs group a7cd0780 not found for > kobject 'event13' > > This has been noticed before. [0] > > This is because of the order in which things are torn down. > > If there are no streams active during a USB disconnect: > > - uvc_disconnect() is invoked via device_del() through the bus >notifier mechanism. > > - this calls uvc_unregister_video(). > > - uvc_unregister_video() unregisters the video device for each >stream, > > - because there are no streams open, it calls uvc_delete() > > - uvc_delete() calls uvc_status_cleanup(), which cleans up the status >input device. > > - uvc_delete() calls media_device_unregister(), which cleans up the >media device > > - uvc_delete(), uvc_unregister_video() and uvc_disconnect() all >return, and we end up back in device_del(). > > - device_del() then cleans up the sysfs folder for the camera with >dpm_sysfs_remove(). Because uvc_status_cleanup() and >media_device_unregister() have already been called, this all works >nicely. > > If, on the other hand, there *are* streams active during a USB disconnect: > > - uvc_disconnect() is invoked > > - this calls uvc_unregister_video() > > - uvc_unregister_video() unregisters the video device for each >stream, > > - uvc_unregister_video() and uvc_disconnect() return, and we end up >back in device_del(). > > - device_del() then cleans up the sysfs folder for the camera with >dpm_sysfs_remove(). Because the status input device and the media >device are children of the USB device, this also deletes their >sysfs folders. > > - Sometime later, the final stream is closed, invoking uvc_release(). > > - uvc_release() calls uvc_delete() > > - uvc_delete() calls uvc_status_cleanup(), which cleans up the status >input device. Because the sysfs directory has already been removed, >this causes a WARNing. > > - uvc_delete() calls media_device_unregister(), which cleans up the >media device. Because the sysfs directory has already been removed, >this causes another WARNing. > > To fix this, we need to make sure the devices are always unregistered > before the end of uvc_disconnect(). To this, move the unregistration > into the disconnect path: > > - split uvc_status_cleanup() into two parts, one on disconnect that >unregisters and one on delete that frees. > > - move media_device_unregister() into the disconnect path. While the patch looks reasonable to me (with one comment below though), isn't this an issue with the USB core, or possibly the device core ? It's a common practice to create device nodes as children of physical devices. Does the device core really require all device nodes to be unregistered synchronously with physical device hot-unplug ? If so, shouldn't it warn somehow when a device is deleted and still has children, instead of accepting that silently and later complaining due to sysfs issues ? > [0]: https://lkml.org/lkml/2016/12/8/657 > > Cc: Laurent Pinchart > Cc: Dave Stevenson > Cc: Greg KH > Signed-off-by: Daniel Axtens > > --- > > Tested with cheese and yavta. > --- > drivers/media/usb/uvc/uvc_driver.c | 8 ++-- > drivers/media/usb/uvc/uvc_status.c | 8 ++-- > drivers/media/usb/uvc/uvcvideo.h | 1 + > 3 files changed, 13 insertions(+), 4 deletions(-) > > diff --git a/drivers/media/usb/uvc/uvc_driver.c > b/drivers/media/usb/uvc/uvc_driver.c index 46d6be0bb316..2390592f78e0 > 100644 > --- a/drivers/media/usb/uvc/uvc_driver.c > +++ b/drivers/media/usb/uvc/uvc_driver.c > @@ -1815,8 +1815,6 @@ static void uvc_delete(struct uvc_device *dev) > if (dev->vdev.dev) > v4l2_device_unregister(&dev->vdev); > #ifdef CONFIG_MEDIA_CONTROLLER > - if (media_devnode_is_registered(dev->mdev.devnode)) > - media_device_unregister(&dev->mdev); media_device_unregister() will now be called before v4l2_device_unregister() which, unless I'm mistaken, will now result in media_device_unregister_entity() being called twice for every entity, the first time by media_device_unregister(), and the second time by v4l2_device_unregister_subdev() through v4l2_device_unregister(). Looking at media_device_unregister() I don't think that's safe. We could move to v4l2_device_unregister() call to uvc_unregister_video(), but that worries me (perhaps unnecessarily though) due to the race conditions it could introduce. Would you still be able to give it a try ? Note that your patch isn't really at fault here, the media controller and V4L2 core code have been broken for a long time when it comes to entity lifetime management. That might be fixed s
Re: [PATCH 2/2] [media] uvcvideo: Kill video URBs on disconnect
Hi Daniel, Thank you for the patch. On Monday 17 Apr 2017 18:52:40 Daniel Axtens wrote: > When an in-use webcam is disconnected, I noticed the following > messages: > > uvcvideo: Failed to resubmit video URB (-19). > > -19 is -ENODEV, which does make sense given that the device has > disappeared. > > We could put a case for -ENODEV like we have with -ENOENT, -ECONNRESET > and -ESHUTDOWN, but the usb_unlink_urb() API documentation says that > 'The disconnect function should synchronize with a driver's I/O > routines to insure that all URB-related activity has completed before > it returns.' So we should make an effort to proactively kill URBs in > the disconnect path instead. > > Call uvc_enable_video() (specifying 0 to disable) in the disconnect > path, which kills and frees URBs. > > Cc: Laurent Pinchart > Signed-off-by: Daniel Axtens > > --- > > Before this patch, yavta -c hangs when a camera is disconnected, but > with this patch it exits immediately after the camera is > disconnected. I'm not sure if this is acceptable - Laurent? I assume that the error message is caused by a race between disconnection and URB handling. When the device is disconnected I believe the USB core will cancel all in-progress URBs (I'm not very familiar with that part of the USB core anymore, so please don't consider this or any further related statement as true without double-checking), resulting in the URB completion handler being called with an error status. The completion handler should then avoid resubmitting the URB. However, if the completion handler is in progress when the device is disconnected, it won't notice that the device got disconnected, and will try to resubmit the URB. I'm not sure to see how this patch will fix the problem. If the URB completion handler is in progress when the device is being disconnected, won't it call usb_submit_urb() regardless of whether you call usb_kill_urb() in the disconnect handler, resulting in an error message being printed ? > --- > drivers/media/usb/uvc/uvc_driver.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/media/usb/uvc/uvc_driver.c > b/drivers/media/usb/uvc/uvc_driver.c index 2390592f78e0..647e3d8a1256 > 100644 > --- a/drivers/media/usb/uvc/uvc_driver.c > +++ b/drivers/media/usb/uvc/uvc_driver.c > @@ -1877,6 +1877,8 @@ static void uvc_unregister_video(struct uvc_device > *dev) if (!video_is_registered(&stream->vdev)) > continue; > > + uvc_video_enable(stream, 0); > + > video_unregister_device(&stream->vdev); > > uvc_debugfs_cleanup_stream(stream); -- Regards, Laurent Pinchart
Re: uvcvideo logging kernel warnings on device disconnect
Hi Daniel, On Monday 17 Apr 2017 18:57:57 Daniel Axtens wrote: > Hi, > > >> > I hate to pester, but wondered if you had found anything obvious. > >> > I really do appreciate you taking the time to look. > >> > >> Sorry, I haven't had the chance and now will not be able to until > >> January > > > > Did you mean January 2017 or 2018 ? :-) > > I stumbled across this problem independently, and with the help of some > of the info on this thread (especially yavta), I have what I think is a > solution: https://patchwork.kernel.org/patch/9683663/ Thank you for that ! I've reviewed your patch. Greg, there's a question for you in my reply, could you have a look when you'll have time ? -- Regards, Laurent Pinchart
Re: [PATCH 20/26] [media] em28xx: split up em28xx_dvb_init to reduce stack size
Em Thu, 2 Mar 2017 17:38:28 +0100
Arnd Bergmann escreveu:
> With CONFIG_KASAN, the init function uses a large amount of kernel stack:
>
> drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init':
> drivers/media/usb/em28xx/em28xx-dvb.c:2069:1: error: the frame size of 4280
> bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
>
> By splitting out each part of the switch/case statement that has its own local
> variables into a separate function, no single one of them uses more than 500
> bytes,
> and with a noinline_for_kasan annotation we can ensure that they are not
> merged
> back together.
Actually, the best here would be to have a generic function that
would be doing the I2C binding. The code used to be a way simpler
(and it is still is, for most devices), but, on newer devices,
instead of using dvb_attach() macro, it now requires a lot of
code to do the same thing.
E. g. instead of:
> + /* attach demod + tuner combo */
> + tda10071_pdata.clk = 40444000, /* 40.444 MHz */
> + tda10071_pdata.i2c_wr_max = 64,
> + tda10071_pdata.ts_mode = TDA10071_TS_SERIAL,
> + tda10071_pdata.pll_multiplier = 20,
> + tda10071_pdata.tuner_i2c_addr = 0x14,
> + memset(&board_info, 0, sizeof(board_info));
> + strlcpy(board_info.type, "tda10071_cx24118", I2C_NAME_SIZE);
> + board_info.addr = 0x55;
> + board_info.platform_data = &tda10071_pdata;
> + request_module("tda10071");
> + client = i2c_new_device(&dev->i2c_adap[dev->def_i2c_bus], &board_info);
> + if (client == NULL || client->dev.driver == NULL) {
> + result = -ENODEV;
> + goto out_free;
> + }
> + if (!try_module_get(client->dev.driver->owner)) {
> + i2c_unregister_device(client);
> + result = -ENODEV;
> + goto out_free;
> + }
> + dvb->fe[0] = tda10071_pdata.get_dvb_frontend(client);
> + dvb->i2c_client_demod = client;
the code would be doing something like:
static const tda10071_platform_data tda10071_pdata {
...
};
...
ret = dvb_demod_attach(dvb, "tda10071", 0x55, tda10071_pdata);
if (ret)
return ret;
Antti,
As we discussed it in the past, we should really have a helper
function that would be doing everything that it is needed to
attach a frontend with the new way, instead of adding lots of
code, with causes static analyzers to break, and make the DVB
init code really big.
Btw, it is not just KASAN that breaks with it. I'm carrying
myself a some patches on my smatch's git internal tree, as otherwise
it is unable to parse those big DVB init routines, as it consumes
a lot of memory to parse it.
Regards,
Mauro
PS.: Cleaned up the C/C. There's no need to copy it to the entire world :-)
>
> Signed-off-by: Arnd Bergmann
> ---
> drivers/media/usb/em28xx/em28xx-dvb.c | 947
> ++
> 1 file changed, 508 insertions(+), 439 deletions(-)
>
> diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
> b/drivers/media/usb/em28xx/em28xx-dvb.c
> index 82edd37f0d73..83125a05918a 100644
> --- a/drivers/media/usb/em28xx/em28xx-dvb.c
> +++ b/drivers/media/usb/em28xx/em28xx-dvb.c
> @@ -934,7 +934,7 @@ static struct lgdt3306a_config
> hauppauge_01595_lgdt3306a_config = {
>
> /* -- */
>
> -static int em28xx_attach_xc3028(u8 addr, struct em28xx *dev)
> +static noinline_for_kasan int em28xx_attach_xc3028(u8 addr, struct em28xx
> *dev)
> {
> struct dvb_frontend *fe;
> struct xc2028_config cfg;
> @@ -1126,6 +1126,492 @@ static void em28xx_unregister_dvb(struct em28xx_dvb
> *dvb)
> dvb_unregister_adapter(&dvb->adapter);
> }
>
> +static noinline_for_kasan int em28174_dvb_init_pctv_460e(struct em28xx *dev)
> +{
> + struct em28xx_dvb *dvb = dev->dvb;
> + struct i2c_client *client;
> + struct i2c_board_info board_info;
> + struct tda10071_platform_data tda10071_pdata = {};
> + struct a8293_platform_data a8293_pdata = {};
> + int result;
> +
> + /* attach demod + tuner combo */
> + tda10071_pdata.clk = 40444000, /* 40.444 MHz */
> + tda10071_pdata.i2c_wr_max = 64,
> + tda10071_pdata.ts_mode = TDA10071_TS_SERIAL,
> + tda10071_pdata.pll_multiplier = 20,
> + tda10071_pdata.tuner_i2c_addr = 0x14,
> + memset(&board_info, 0, sizeof(board_info));
> + strlcpy(board_info.type, "tda10071_cx24118", I2C_NAME_SIZE);
> + board_info.addr = 0x55;
> + board_info.platform_data = &tda10071_pdata;
> + request_module("tda10071");
> + client = i2c_new_device(&dev->i2c_adap[dev->def_i2c_bus], &board_info);
> + if (client == NULL || client->dev.driver == NULL) {
> + result = -ENODEV;
> + goto out_free;
> + }
> + if (!try_module_get(client->dev.driver->owner)) {
> + i2c_unregister_device(client);
> + result = -ENODEV;
> +
Re: em28xx i2c writing error
Hi Frank, On Sun, Apr 16, 2017 at 7:59 PM, Frank Schäfer wrote: > > Am 15.04.2017 um 20:28 schrieb Anders Eriksson: >> Hi Mauro, >> >> I've two devices using this driver, and whenever I have them both in >> use I eventually (between 10K and 100K secs uptime) i2c write errors >> such as in the log below. If only have one of the devices in use, the >> machine is stable. >> >> The machine never recovers from the error. >> >> All help apreciated. >> -Anders >> >> >> >> [ 45.616358] br0: port 6(vb-work) entered forwarding state >> [ 45.634769] br0: port 6(vb-work) entered forwarding state >> [ 54.045274] br0: port 5(vb-revproxy) entered forwarding state >> [ 60.645283] br0: port 6(vb-work) entered forwarding state > Did you skip any lines here ? Any usb related messages ? > Nope. It ran without any messages up to 93093 >> [93038.637557] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93038.737581] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) > -5 is -EIO, which means the errors occure at usb level (line 176 in > em28xx-core.c) > However, the actual error returned by usb_control_msg() might be > different, because it is passed through usb_translate_errors(). > > Hth, > Frank > I add linux-usb@ and see who might knwo something. Do you know whom I should contact wrt usb? Br, Anders >> [93038.746399] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93039.247560] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93039.447579] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93039.647559] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93039.847564] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93040.047567] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93040.157570] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93040.165915] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93041.047583] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93041.167571] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93041.175973] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93042.047587] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93042.177582] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93042.185886] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93043.047590] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93043.187592] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93043.195868] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93044.047593] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93044.197589] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93044.205925] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93045.047597] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93045.207593] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93045.215996] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93046.117605] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93046.217617] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93046.226038] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93047.127686] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93048.127607] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93049.127649] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93050.127623] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93051.127653] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93052.127661] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93053.127629] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93054.127676] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93055.127642] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93055.567657] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93055.627642] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93055.635697] i2c i2c-4: cxd2820r: i2c wr failed=-5 reg=85 len=1 >> [93055.737670] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93055.745838] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93055.767696] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93055.937644] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93055.945765] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93056.357654] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93056.365873] i2c i2c-4: cxd2820r: i2c wr failed=-5 reg=85 len=1 >> [93056.557660] em28174 #0: writing to i2c device at 0xd8 failed (error=-5) >> [93056.565881] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1 >> [93056.767668] em28178 #1: writing to i2c device at 0xc8 failed (error=-5) >> [93056.957643] em28174 #0:
Re: [PATCH v6 2/3] v4l: Add 10/16-bits per channel YUV pixel formats
Em Sun, 5 Mar 2017 18:00:32 +0800
Randy Li escreveu:
> The formats added by this patch are:
> V4L2_PIX_FMT_P010
> V4L2_PIX_FMT_P010M
> V4L2_PIX_FMT_P016
> V4L2_PIX_FMT_P016M
> Currently, none of driver uses those format.
>
> Also a variant of V4L2_PIX_FMT_P010M pixel format is added.
> The V4L2_PIX_FMT_P010CM is a compat variant of the V4L2_PIX_FMT_P010,
> which uses the unused 6 bits to store the next pixel. And with
> the alignment requirement of the hardware, it usually would be
> some extra space left at the end of a stride.
You should check your patches with checkpatch... I'm getting
this:
WARNING: 'simliar' may be misspelled - perhaps 'similar'?
#61: FILE: Documentation/media/uapi/v4l/pixfmt-p010.rst:13:
+chroma samples as simliar to ``V4L2_PIX_FMT_NV12``
WARNING: 'simliar' may be misspelled - perhaps 'similar'?
#334: FILE: Documentation/media/uapi/v4l/pixfmt-p016.rst:13:
+chroma samples as simliar to ``V4L2_PIX_FMT_NV12``
>
> Signed-off-by: Randy Li
> ---
> Documentation/media/uapi/v4l/pixfmt-p010.rst | 126
> Documentation/media/uapi/v4l/pixfmt-p010m.rst | 135
> ++
> Documentation/media/uapi/v4l/pixfmt-p016.rst | 125
> Documentation/media/uapi/v4l/pixfmt-p016m.rst | 134 +
> Documentation/media/uapi/v4l/yuv-formats.rst | 4 +
> include/uapi/linux/videodev2.h| 5 +
> 6 files changed, 529 insertions(+)
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010.rst
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-p010m.rst
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016.rst
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-p016m.rst
>
> diff --git a/Documentation/media/uapi/v4l/pixfmt-p010.rst
> b/Documentation/media/uapi/v4l/pixfmt-p010.rst
> new file mode 100644
> index 000..59ed118
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-p010.rst
> @@ -0,0 +1,126 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _V4L2-PIX-FMT-P010:
> +
> +**
> +V4L2_PIX_FMT_P010 ('P010')
> +**
> +
> +
> +V4L2_PIX_FMT_P010
> +Formats with ½ horizontal and vertical chroma resolution. One luminance and
> +one chrominance plane with alternating
> +chroma samples as simliar to ``V4L2_PIX_FMT_NV12``
It is probably ok to use the UTF symbol for 1/2, but you should check
if both PDF and HTML outputs will be ok.
> +
> +
> +Description
> +===
> +
> +It is a two-plane versions of the YUV 4:2:0 format. The three
> +components are separated into two sub-images or planes. The Y plane is
> +first. The Y plane has 16 bits per pixel, but only 10 bits are used with the
> +rest 6 bits set to zero. For ``V4L2_PIX_FMT_P010``, a combined CbCr plane
> +immediately follows the Y plane in memory. The CbCr
> +plane is the same width, in bytes, as the Y plane (and of the image),
> +but is half as tall in pixels. Each CbCr pair belongs to four pixels.
> +For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to Y'\ :sub:`00`,
> +Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`.
> +If the Y plane has pad bytes after each row, then the CbCr plane has as
> +many pad bytes after its rows.
> +
> +**Byte Order.**
> +Each cell is two bytes.
> +
> +
> +.. flat-table::
> +:header-rows: 0
> +:stub-columns: 0
> +
> +* - start + 0:
> + - Y'\ :sub:`00`
> + - Y'\ :sub:`01`
> + - Y'\ :sub:`02`
> + - Y'\ :sub:`03`
> +* - start + 4:
> + - Y'\ :sub:`10`
> + - Y'\ :sub:`11`
> + - Y'\ :sub:`12`
> + - Y'\ :sub:`13`
> +* - start + 8:
> + - Y'\ :sub:`20`
> + - Y'\ :sub:`21`
> + - Y'\ :sub:`22`
> + - Y'\ :sub:`23`
> +* - start + 12:
> + - Y'\ :sub:`30`
> + - Y'\ :sub:`31`
> + - Y'\ :sub:`32`
> + - Y'\ :sub:`33`
> +* - start + 16:
> + - Cb\ :sub:`00`
> + - Cr\ :sub:`00`
> + - Cb\ :sub:`01`
> + - Cr\ :sub:`01`
> +* - start + 20:
> + - Cb\ :sub:`10`
> + - Cr\ :sub:`10`
> + - Cb\ :sub:`11`
> + - Cr\ :sub:`11`
> +
> +
> +**Color Sample Location..**
> +
> +.. flat-table::
> +:header-rows: 0
> +:stub-columns: 0
> +
> +* -
> + - 0
> + -
> + - 1
> + - 2
> + -
> + - 3
> +* - 0
> + - Y
> + -
> + - Y
> + - Y
> + -
> + - Y
> +* -
> + -
> + - C
> + -
> + -
> + - C
> + -
> +* - 1
> + - Y
> + -
> + - Y
> + - Y
> + -
> + - Y
> +* -
> +* - 2
> + - Y
> + -
> + - Y
> + - Y
> + -
> + - Y
> +* -
> + -
> + - C
> + -
> + -
> + - C
> + -
> +* - 3
> + - Y
> + -
> + - Y
> + - Y
> + -
> + - Y
> diff --git a/Documentation/media/uapi/v4l/pixfmt-p010m.rst
> b/Documentation/media/uapi/v4l/pixfmt-p
Re: [PATCH 1/1] v4l: Document the practice of symmetrically calling s_power(dev, 0/1)
Em Thu, 9 Mar 2017 13:54:45 +0200
Sakari Ailus escreveu:
> The caller must always call the s_power() op symmetrically powering the
> device on and off. This is the practice albeit it was not documented. A
> lot of sub-device drivers rely on it, so document it accordingly.
Actually, there are several non-embedded drivers that don't call s_power()
symmetrically, as they use it just put a sub-device in standby mode.
I remember some widely used tuners that has this behavior. Such subdevs
automatically awaken when a command is issued to them (for example,
requesting the tuner to tune into a channel).
If you're willing to change the kABI, you need first to patch such
drivers.
Regards,
Mauro
>
> Signed-off-by: Sakari Ailus
> ---
> include/media/v4l2-subdev.h | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> index 0ab1c5d..b4e521d 100644
> --- a/include/media/v4l2-subdev.h
> +++ b/include/media/v4l2-subdev.h
> @@ -172,8 +172,10 @@ struct v4l2_subdev_io_pin_config {
> *
> * @s_register: callback for %VIDIOC_G_REGISTER ioctl handler code.
> *
> - * @s_power: puts subdevice in power saving mode (on == 0) or normal
> operation
> - * mode (on == 1).
> + * @s_power: Puts subdevice in power saving mode (on == 0) or normal
> operation
> + * mode (on == 1). The caller is responsible for calling the op
> + * symmetrically, i.e. calling s_power(dev, 1) once requires later calling
> + * s_power(dev, 0) once.
> *
> * @interrupt_service_routine: Called by the bridge chip's interrupt service
> * handler, when an interrupt status has be raised due to this subdev,
Thanks,
Mauro
Re: [PATCH] [media] uvcvideo: Add iFunction or iInterface to device names.
Hi Peter,
Thank you for the patch.
On Thursday 06 April 2017 13:58:25 Peter Boström wrote:
> Permits distinguishing between two /dev/videoX entries from the same
> physical UVC device (that naturally share the same iProduct name).
>
> This change matches current Windows behavior by prioritizing iFunction
> over iInterface, but unlike Windows it displays both iProduct and
> iFunction/iInterface strings when both are available.
>
> Signed-off-by: Peter Boström
> ---
> drivers/media/usb/uvc/uvc_driver.c | 43 ---
> drivers/media/usb/uvc/uvcvideo.h | 4 +++-
> 2 files changed, 39 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_driver.c
> b/drivers/media/usb/uvc/uvc_driver.c index 04bf35063c4c..66adf8a77e56
> 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -1998,6 +1998,8 @@ static int uvc_probe(struct usb_interface *intf,
> {
> struct usb_device *udev = interface_to_usbdev(intf);
> struct uvc_device *dev;
> + char additional_name_buf[UVC_DEVICE_NAME_SIZE];
> + const char *additional_name = NULL;
> int ret;
>
> if (id->idVendor && id->idProduct)
> @@ -2025,13 +2027,40 @@ static int uvc_probe(struct usb_interface *intf,
> dev->quirks = (uvc_quirks_param == -1)
> ? id->driver_info : uvc_quirks_param;
>
> - if (udev->product != NULL)
> - strlcpy(dev->name, udev->product, sizeof dev->name);
> - else
> - snprintf(dev->name, sizeof dev->name,
> - "UVC Camera (%04x:%04x)",
> - le16_to_cpu(udev->descriptor.idVendor),
> - le16_to_cpu(udev->descriptor.idProduct));
> + /*
> + * Add iFunction or iInterface to names when available as additional
> + * distinguishers between interfaces. iFunction is prioritized over
> + * iInterface which matches Windows behavior at the point of writing.
> + */
> + if (intf->intf_assoc && intf->intf_assoc->iFunction != 0) {
> + usb_string(udev, intf->intf_assoc->iFunction,
> +additional_name_buf, sizeof(additional_name_buf));
> + additional_name = additional_name_buf;
> + } else if (intf->cur_altsetting->desc.iInterface != 0) {
> + usb_string(udev, intf->cur_altsetting->desc.iInterface,
> +additional_name_buf, sizeof(additional_name_buf));
> + additional_name = additional_name_buf;
> + }
> +
> + if (additional_name) {
> + if (udev->product) {
> + snprintf(dev->name, sizeof(dev->name), "%s: %s",
> + udev->product, additional_name);
> + } else {
> + snprintf(dev->name, sizeof(dev->name),
> + "UVC Camera: %s (%04x:%04x)",
> + additional_name,
> + le16_to_cpu(udev->descriptor.idVendor),
> + le16_to_cpu(udev->descriptor.idProduct));
> + }
> + } else if (udev->product) {
> + strlcpy(dev->name, udev->product, sizeof(dev->name));
> + } else {
> + snprintf(dev->name, sizeof(dev->name),
> + "UVC Camera (%04x:%04x)",
> + le16_to_cpu(udev->descriptor.idVendor),
> + le16_to_cpu(udev->descriptor.idProduct));
> + }
This makes sense to me, but I think we could come up with a version of the
same code that wouldn't require the temporary 64 bytes buffer on the stack.
How about the following (untested) code ?
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 602256ffe14d..9b90a1ac5945 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -2013,6 +2013,7 @@ static int uvc_probe(struct usb_interface *intf,
{
struct usb_device *udev = interface_to_usbdev(intf);
struct uvc_device *dev;
+ int string;
int ret;
if (id->idVendor && id->idProduct)
@@ -2048,6 +2049,24 @@ static int uvc_probe(struct usb_interface *intf,
le16_to_cpu(udev->descriptor.idVendor),
le16_to_cpu(udev->descriptor.idProduct));
+ /*
+* Add iFunction or iInterface to names when available as additional
+* distinguishers between interfaces. iFunction is prioritized over
+* iInterface which matches Windows behavior at the point of writing.
+*/
+ string = intf->intf_assoc ? intf->intf_assoc->iFunction
+ : intf->cur_altsetting->desc.iInterface;
+ if (string != 0) {
+ size_t len;
+
+ strlcat(dev->name, ": ", sizeof(dev->name));
+ len = strlen(dev->name);
+
+ /* usb_string() accounts for the terminating NULL character. */
+ usb_string(udev, string,
[PATCH v2] [media] uvcvideo: Add iFunction or iInterface to device names.
Permits distinguishing between two /dev/videoX entries from the same
physical UVC device (that naturally share the same iProduct name).
This change matches current Windows behavior by prioritizing iFunction
over iInterface, but unlike Windows it displays both iProduct and
iFunction/iInterface strings when both are available.
Signed-off-by: Peter Boström
---
drivers/media/usb/uvc/uvc_driver.c | 37 ++---
drivers/media/usb/uvc/uvcvideo.h | 2 +-
2 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 04bf35063c4c..3a00313772a0 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1998,6 +1998,7 @@ static int uvc_probe(struct usb_interface *intf,
{
struct usb_device *udev = interface_to_usbdev(intf);
struct uvc_device *dev;
+ int additional_name;
int ret;
if (id->idVendor && id->idProduct)
@@ -2025,13 +2026,35 @@ static int uvc_probe(struct usb_interface *intf,
dev->quirks = (uvc_quirks_param == -1)
? id->driver_info : uvc_quirks_param;
- if (udev->product != NULL)
- strlcpy(dev->name, udev->product, sizeof dev->name);
- else
- snprintf(dev->name, sizeof dev->name,
- "UVC Camera (%04x:%04x)",
- le16_to_cpu(udev->descriptor.idVendor),
- le16_to_cpu(udev->descriptor.idProduct));
+ strlcpy(dev->name, udev->product ? udev->product : "UVC Camera",
+ sizeof(dev->name));
+
+ /*
+* Add iFunction or iInterface to names when available as additional
+* distinguishers between interfaces. iFunction is prioritized over
+* iInterface which matches Windows behavior at the point of writing.
+*/
+ additional_name = intf->cur_altsetting->desc.iInterface;
+ if (intf->intf_assoc && intf->intf_assoc->iFunction != 0)
+ additional_name = intf->intf_assoc->iFunction;
+ if (additional_name != 0) {
+ size_t len;
+
+ strlcat(dev->name, ": ", sizeof(dev->name));
+ len = strlen(dev->name);
+ usb_string(udev, additional_name, dev->name + len,
+ sizeof(dev->name) - len);
+ }
+
+ /* Append descriptors to unknown UVC products. */
+ if (!udev->product) {
+ size_t len = strlen(dev->name);
+
+ snprintf(dev->name + len, sizeof(dev->name) - len,
+" (%04x:%04x)",
+le16_to_cpu(udev->descriptor.idVendor),
+le16_to_cpu(udev->descriptor.idProduct));
+ }
/* Parse the Video Class control descriptor. */
if (uvc_parse_control(dev) < 0) {
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 4205e7a423f0..905e40a90fa2 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -547,7 +547,7 @@ struct uvc_device {
unsigned long warnings;
__u32 quirks;
int intfnum;
- char name[32];
+ char name[64];
struct mutex lock; /* Protects users */
unsigned int users;
--
2.12.2.762.g0e3151a226-goog
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Tue Apr 18 05:00:17 CEST 2017 media-tree git hash:495ab569d0845065016617edcf07a75db96c3ef0 media_build git hash: 1af19680bde3e227d64d99ff5fdc43eb343a3b28 v4l-utils git hash: ea40243e8a8d1b5bcd90da0cf8be8b8ebf8cf4b1 gcc version:i686-linux-gcc (GCC) 6.2.0 sparse version: v0.5.0-3553-g78b2ea6 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.9.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: ERRORS linux-3.12.67-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0.9-i686: WARNINGS linux-4.1.33-i686: WARNINGS linux-4.2.8-i686: WARNINGS linux-4.3.6-i686: WARNINGS linux-4.4.22-i686: WARNINGS linux-4.5.7-i686: WARNINGS linux-4.6.7-i686: WARNINGS linux-4.7.5-i686: WARNINGS linux-4.8-i686: OK linux-4.9-i686: OK linux-4.10.1-i686: OK linux-4.11-rc1-i686: OK linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: ERRORS linux-3.12.67-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: WARNINGS linux-3.18.7-x86_64: WARNINGS linux-3.19-x86_64: WARNINGS linux-4.0.9-x86_64: WARNINGS linux-4.1.33-x86_64: WARNINGS linux-4.2.8-x86_64: WARNINGS linux-4.3.6-x86_64: WARNINGS linux-4.4.22-x86_64: WARNINGS linux-4.5.7-x86_64: WARNINGS linux-4.6.7-x86_64: WARNINGS linux-4.7.5-x86_64: WARNINGS linux-4.8-x86_64: WARNINGS linux-4.9-x86_64: WARNINGS linux-4.10.1-x86_64: WARNINGS linux-4.11-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
КЛИЕНТСКИЕ БАЗЫ http://xurl.es/PR0DAWEZ УЗНАЙТЕ ПОДРОБНЕЕ!
Re: [PATCH 05/22] drm/i915: Make use of the new sg_map helper function
On Thu, Apr 13, 2017 at 04:05:18PM -0600, Logan Gunthorpe wrote:
> This is a single straightforward conversion from kmap to sg_map.
>
> Signed-off-by: Logan Gunthorpe
Acked-by: Daniel Vetter
Probably makes sense to merge through some other tree, but please be aware
of the considerable churn rate in i915 (i.e. make sure your tree is in
linux-next before you send a pull request for this). Plane B would be to
get the prep patch in first and then merge the i915 conversion one kernel
release later.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_gem.c | 27 ---
> 1 file changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 67b1fc5..1b1b91a 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2188,6 +2188,15 @@ static void __i915_gem_object_reset_page_iter(struct
> drm_i915_gem_object *obj)
> radix_tree_delete(&obj->mm.get_page.radix, iter.index);
> }
>
> +static void i915_gem_object_unmap(const struct drm_i915_gem_object *obj,
> + void *ptr)
> +{
> + if (is_vmalloc_addr(ptr))
> + vunmap(ptr);
> + else
> + sg_unmap(obj->mm.pages->sgl, ptr, SG_KMAP);
> +}
> +
> void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
>enum i915_mm_subclass subclass)
> {
> @@ -2215,10 +2224,7 @@ void __i915_gem_object_put_pages(struct
> drm_i915_gem_object *obj,
> void *ptr;
>
> ptr = ptr_mask_bits(obj->mm.mapping);
> - if (is_vmalloc_addr(ptr))
> - vunmap(ptr);
> - else
> - kunmap(kmap_to_page(ptr));
> + i915_gem_object_unmap(obj, ptr);
>
> obj->mm.mapping = NULL;
> }
> @@ -2475,8 +2481,11 @@ static void *i915_gem_object_map(const struct
> drm_i915_gem_object *obj,
> void *addr;
>
> /* A single page can always be kmapped */
> - if (n_pages == 1 && type == I915_MAP_WB)
> - return kmap(sg_page(sgt->sgl));
> + if (n_pages == 1 && type == I915_MAP_WB) {
> + addr = sg_map(sgt->sgl, SG_KMAP);
> + if (IS_ERR(addr))
> + return NULL;
> + }
>
> if (n_pages > ARRAY_SIZE(stack_pages)) {
> /* Too big for stack -- allocate temporary array instead */
> @@ -2543,11 +2552,7 @@ void *i915_gem_object_pin_map(struct
> drm_i915_gem_object *obj,
> goto err_unpin;
> }
>
> - if (is_vmalloc_addr(ptr))
> - vunmap(ptr);
> - else
> - kunmap(kmap_to_page(ptr));
> -
> + i915_gem_object_unmap(obj, ptr);
> ptr = obj->mm.mapping = NULL;
> }
>
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
