Re: [PATCH] add raw video support for Samsung SUR40 touchscreen
Hi Florian, On 02/03/2015 09:45 PM, Florian Echtler wrote: Sorry to bring this up again, but would it be acceptable to simply use dma-contig after all? Since the GFP_DMA flag is gone, this shouldn't be too big of an issue IMHO, and I was kind of hoping the patch could still be part of 3.20. The window for 3.20 is closed, I'm afraid. I remain very skeptical about the use of dma-contig (or dma-sg for that matter). Have you tried using vmalloc and check if the USB core isn't automatically using DMA transfers for that? Basically I would like to see proof that vmalloc is not an option before allowing dma-contig (or dma-sg if you can figure out why that isn't working). You can also make a version with vmalloc and I'll merge that, and then you can look more into the DMA issues. That way the driver is merged, even if it is perhaps not yet optimal, and you can address that part later. Regards, Hans Best, Florian On 29.01.2015 22:35, Florian Echtler wrote: I'm still having a couple of issues sorting out the correct way to provide DMA access for my driver. I've integrated most of your suggestions, but I still can't switch from dma-contig to dma-sg. As far as I understood it, there is no further initialization required besides using vb2_dma_sg_memops, vb2_dma_sg_init_ctx and vb2_dma_sg_cleanup_ctx instead of the respective -contig- calls, correct? However, as soon as I swap the relevant function calls, the video image stays black and in dmesg, I get the following warning: Call Trace: [817c4584] dump_stack+0x45/0x57 [81076df7] warn_slowpath_common+0x97/0xe0 [81076ef6] warn_slowpath_fmt+0x46/0x50 [815aff0b] usb_hcd_map_urb_for_dma+0x4eb/0x500 [817d03b4] ? schedule_timeout+0x124/0x210 [815b0bd5] usb_hcd_submit_urb+0x135/0x1c0 [815b20a6] usb_submit_urb.part.8+0x1f6/0x580 [811bb542] ? vmap_pud_range+0x122/0x1c0 [815b2465] usb_submit_urb+0x35/0x80 [815b339a] usb_start_wait_urb+0x6a/0x170 [815b1cce] ? usb_alloc_urb+0x1e/0x50 [815b1cce] ? usb_alloc_urb+0x1e/0x50 [815b3570] usb_bulk_msg+0xd0/0x1a0 [c059a841] sur40_poll+0x561/0x5e0 [sur40] Moreover, I'm getting the following test failure from v4l2-compliance: Streaming ioctls: test read/write: OK test MMAP: OK fail: v4l2-test-buffers.cpp(951): buf.qbuf(node) fail: v4l2-test-buffers.cpp(994): setupUserPtr(node, q) test USERPTR: FAIL test DMABUF: Cannot test, specify --expbuf-device Total: 45, Succeeded: 44, Failed: 1, Warnings: 0 -- 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] add raw video support for Samsung SUR40 touchscreen
On 04.02.2015 11:22, Hans Verkuil wrote: On 02/04/15 11:08, Florian Echtler wrote: On 04.02.2015 09:08, Hans Verkuil wrote: You can also make a version with vmalloc and I'll merge that, and then you can look more into the DMA issues. That way the driver is merged, even if it is perhaps not yet optimal, and you can address that part later. OK, that sounds sensible, I will try that route. When using videobuf2-vmalloc, what do I pass back for alloc_ctxs in queue_setup? vmalloc doesn't need those, so you can just drop any alloc_ctx related code. That's what I assumed, however, I'm running into the same problem as with dma-sg when I switch to vmalloc...? I've sent a proper patch submission again, which has all the other issues from the previous submission fixed. I'm hoping you can maybe have a closer look and see if I'm doing anything subtly wrong which causes both vmalloc and dma-sg to fail while dma-contig works. Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH] add raw video support for Samsung SUR40 touchscreen
Hi Florian, On Wednesday 04 February 2015 11:56:58 Florian Echtler wrote: On 04.02.2015 11:22, Hans Verkuil wrote: On 02/04/15 11:08, Florian Echtler wrote: On 04.02.2015 09:08, Hans Verkuil wrote: You can also make a version with vmalloc and I'll merge that, and then you can look more into the DMA issues. That way the driver is merged, even if it is perhaps not yet optimal, and you can address that part later. OK, that sounds sensible, I will try that route. When using videobuf2-vmalloc, what do I pass back for alloc_ctxs in queue_setup? vmalloc doesn't need those, so you can just drop any alloc_ctx related code. That's what I assumed, however, I'm running into the same problem as with dma-sg when I switch to vmalloc...? I don't expect vmalloc to work, as you can't DMA to vmalloc memory directly without any IOMMU in the general case (the allocated memory being physically fragmented). dma-sg should work though, but you won't be able to use usb_bulk_msg(). You need to create the URBs manually, set their sg and num_sgs fields and submit them. I've sent a proper patch submission again, which has all the other issues from the previous submission fixed. I'm hoping you can maybe have a closer look and see if I'm doing anything subtly wrong which causes both vmalloc and dma-sg to fail while dma-contig works. -- Regards, Laurent Pinchart -- 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] add raw video support for Samsung SUR40 touchscreen
Hello everyone, On 04.02.2015 12:39, Hans Verkuil wrote: On 02/04/15 12:34, Laurent Pinchart wrote: On Wednesday 04 February 2015 11:56:58 Florian Echtler wrote: That's what I assumed, however, I'm running into the same problem as with dma-sg when I switch to vmalloc...? I don't expect vmalloc to work, as you can't DMA to vmalloc memory directly without any IOMMU in the general case (the allocated memory being physically fragmented). dma-sg should work though, but you won't be able to use usb_bulk_msg(). You need to create the URBs manually, set their sg and num_sgs fields and submit them. Can I also use usb_sg_init/_wait for this? I can't find any other driver which uses USB in conjunction with dma-sg, can you suggest one I could use as an example? Anyway Florian, based on Laurent's explanation I think trying to make dma-sg work seems to be the best solution. And I've learned something new :-) Thanks for the clarification, please ignore the v2 patch submission for now :-) Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH] add raw video support for Samsung SUR40 touchscreen
Hi Hans, On Wednesday 04 February 2015 12:39:30 Hans Verkuil wrote: On 02/04/15 12:34, Laurent Pinchart wrote: On Wednesday 04 February 2015 11:56:58 Florian Echtler wrote: On 04.02.2015 11:22, Hans Verkuil wrote: On 02/04/15 11:08, Florian Echtler wrote: On 04.02.2015 09:08, Hans Verkuil wrote: You can also make a version with vmalloc and I'll merge that, and then you can look more into the DMA issues. That way the driver is merged, even if it is perhaps not yet optimal, and you can address that part later. OK, that sounds sensible, I will try that route. When using videobuf2-vmalloc, what do I pass back for alloc_ctxs in queue_setup? vmalloc doesn't need those, so you can just drop any alloc_ctx related code. That's what I assumed, however, I'm running into the same problem as with dma-sg when I switch to vmalloc...? I don't expect vmalloc to work, as you can't DMA to vmalloc memory directly without any IOMMU in the general case (the allocated memory being physically fragmented). dma-sg should work though, but you won't be able to use usb_bulk_msg(). You need to create the URBs manually, set their sg and num_sgs fields and submit them. So it works for other usb media drivers because they allocate memory using kmalloc (and presumably the usb core can DMA to that), and then memcpy it to the vmalloc-ed buffers? Correct. In the uvcvideo case that's unavoidable as headers need to be removed from the packets. Anyway Florian, based on Laurent's explanation I think trying to make dma-sg work seems to be the best solution. And I've learned something new :-) -- Regards, Laurent Pinchart -- 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] add raw video support for Samsung SUR40 touchscreen
Hi Florian, On Wednesday 04 February 2015 14:21:47 Florian Echtler wrote: On 04.02.2015 12:39, Hans Verkuil wrote: On 02/04/15 12:34, Laurent Pinchart wrote: On Wednesday 04 February 2015 11:56:58 Florian Echtler wrote: That's what I assumed, however, I'm running into the same problem as with dma-sg when I switch to vmalloc...? I don't expect vmalloc to work, as you can't DMA to vmalloc memory directly without any IOMMU in the general case (the allocated memory being physically fragmented). dma-sg should work though, but you won't be able to use usb_bulk_msg(). You need to create the URBs manually, set their sg and num_sgs fields and submit them. Can I also use usb_sg_init/_wait for this? I can't find any other driver which uses USB in conjunction with dma-sg, can you suggest one I could use as an example? usb_sg_init() is an interesting abstraction that transparently splits SG lists into several URBs if the USB host controller can't support SG lists directly. Unfortunately the API is blocking. It shouldn't be too difficult to add an asynchronous option with a complete callback. Anyway Florian, based on Laurent's explanation I think trying to make dma-sg work seems to be the best solution. And I've learned something new :-) Thanks for the clarification, please ignore the v2 patch submission for now :-) -- Regards, Laurent Pinchart -- 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] add raw video support for Samsung SUR40 touchscreen
On 02/04/15 12:34, Laurent Pinchart wrote: Hi Florian, On Wednesday 04 February 2015 11:56:58 Florian Echtler wrote: On 04.02.2015 11:22, Hans Verkuil wrote: On 02/04/15 11:08, Florian Echtler wrote: On 04.02.2015 09:08, Hans Verkuil wrote: You can also make a version with vmalloc and I'll merge that, and then you can look more into the DMA issues. That way the driver is merged, even if it is perhaps not yet optimal, and you can address that part later. OK, that sounds sensible, I will try that route. When using videobuf2-vmalloc, what do I pass back for alloc_ctxs in queue_setup? vmalloc doesn't need those, so you can just drop any alloc_ctx related code. That's what I assumed, however, I'm running into the same problem as with dma-sg when I switch to vmalloc...? I don't expect vmalloc to work, as you can't DMA to vmalloc memory directly without any IOMMU in the general case (the allocated memory being physically fragmented). dma-sg should work though, but you won't be able to use usb_bulk_msg(). You need to create the URBs manually, set their sg and num_sgs fields and submit them. So it works for other usb media drivers because they allocate memory using kmalloc (and presumably the usb core can DMA to that), and then memcpy it to the vmalloc-ed buffers? Anyway Florian, based on Laurent's explanation I think trying to make dma-sg work seems to be the best solution. And I've learned something new :-) Regards, Hans I've sent a proper patch submission again, which has all the other issues from the previous submission fixed. I'm hoping you can maybe have a closer look and see if I'm doing anything subtly wrong which causes both vmalloc and dma-sg to fail while dma-contig works. -- 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] add raw video support for Samsung SUR40 touchscreen
Hello Hans, On 04.02.2015 09:08, Hans Verkuil wrote: I remain very skeptical about the use of dma-contig (or dma-sg for that matter). Have you tried using vmalloc and check if the USB core isn't automatically using DMA transfers for that? Basically I would like to see proof that vmalloc is not an option before allowing dma-contig (or dma-sg if you can figure out why that isn't working). You can also make a version with vmalloc and I'll merge that, and then you can look more into the DMA issues. That way the driver is merged, even if it is perhaps not yet optimal, and you can address that part later. OK, that sounds sensible, I will try that route. When using videobuf2-vmalloc, what do I pass back for alloc_ctxs in queue_setup? Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH] add raw video support for Samsung SUR40 touchscreen
On 02/04/15 11:08, Florian Echtler wrote: Hello Hans, On 04.02.2015 09:08, Hans Verkuil wrote: I remain very skeptical about the use of dma-contig (or dma-sg for that matter). Have you tried using vmalloc and check if the USB core isn't automatically using DMA transfers for that? Basically I would like to see proof that vmalloc is not an option before allowing dma-contig (or dma-sg if you can figure out why that isn't working). You can also make a version with vmalloc and I'll merge that, and then you can look more into the DMA issues. That way the driver is merged, even if it is perhaps not yet optimal, and you can address that part later. OK, that sounds sensible, I will try that route. When using videobuf2-vmalloc, what do I pass back for alloc_ctxs in queue_setup? vmalloc doesn't need those, so you can just drop any alloc_ctx related code. Regards, Hans -- 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] add raw video support for Samsung SUR40 touchscreen
Sorry to bring this up again, but would it be acceptable to simply use dma-contig after all? Since the GFP_DMA flag is gone, this shouldn't be too big of an issue IMHO, and I was kind of hoping the patch could still be part of 3.20. Best, Florian On 29.01.2015 22:35, Florian Echtler wrote: I'm still having a couple of issues sorting out the correct way to provide DMA access for my driver. I've integrated most of your suggestions, but I still can't switch from dma-contig to dma-sg. As far as I understood it, there is no further initialization required besides using vb2_dma_sg_memops, vb2_dma_sg_init_ctx and vb2_dma_sg_cleanup_ctx instead of the respective -contig- calls, correct? However, as soon as I swap the relevant function calls, the video image stays black and in dmesg, I get the following warning: Call Trace: [817c4584] dump_stack+0x45/0x57 [81076df7] warn_slowpath_common+0x97/0xe0 [81076ef6] warn_slowpath_fmt+0x46/0x50 [815aff0b] usb_hcd_map_urb_for_dma+0x4eb/0x500 [817d03b4] ? schedule_timeout+0x124/0x210 [815b0bd5] usb_hcd_submit_urb+0x135/0x1c0 [815b20a6] usb_submit_urb.part.8+0x1f6/0x580 [811bb542] ? vmap_pud_range+0x122/0x1c0 [815b2465] usb_submit_urb+0x35/0x80 [815b339a] usb_start_wait_urb+0x6a/0x170 [815b1cce] ? usb_alloc_urb+0x1e/0x50 [815b1cce] ? usb_alloc_urb+0x1e/0x50 [815b3570] usb_bulk_msg+0xd0/0x1a0 [c059a841] sur40_poll+0x561/0x5e0 [sur40] Moreover, I'm getting the following test failure from v4l2-compliance: Streaming ioctls: test read/write: OK test MMAP: OK fail: v4l2-test-buffers.cpp(951): buf.qbuf(node) fail: v4l2-test-buffers.cpp(994): setupUserPtr(node, q) test USERPTR: FAIL test DMABUF: Cannot test, specify --expbuf-device Total: 45, Succeeded: 44, Failed: 1, Warnings: 0 -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH] add raw video support for Samsung SUR40 touchscreen
Hello again, On 21.01.2015 14:29, Hans Verkuil wrote: On 01/21/15 14:28, Florian Echtler wrote: On 20.01.2015 14:06, Laurent Pinchart wrote: That depends on the platform and whether it can DMA to vmalloc'ed memory :-) To be totally safe I think vb2-dma-sg would be better, but I'm not sure it's worth the trouble. uvcvideo uses vb2-vmalloc as it performs a memcpy anyway. The SUR40 sends raw video data without any headers over the bulk endpoint in blocks of 16k, so I'm assuming that in this specific case, vb2-dma-sg would be the most efficient choice? I'm still having a couple of issues sorting out the correct way to provide DMA access for my driver. I've integrated most of your suggestions, but I still can't switch from dma-contig to dma-sg. As far as I understood it, there is no further initialization required besides using vb2_dma_sg_memops, vb2_dma_sg_init_ctx and vb2_dma_sg_cleanup_ctx instead of the respective -contig- calls, correct? However, as soon as I swap the relevant function calls, the video image stays black and in dmesg, I get the following warning: [ cut here ] WARNING: CPU: 1 PID: 37 at /home/kernel/COD/linux/drivers/usb/core/hcd.c:1504 usb_hcd_map_urb_for_dma+0x4eb/0x500() transfer buffer not dma capable Modules linked in: sur40(OE) videobuf2_dma_contig videobuf2_dma_sg videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev media dm_crypt joydev input_polldev wl(POE) snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi cfg80211 kvm_amd snd_seq kvm edac_core serio_raw snd_seq_device btusb snd_timer edac_mce_amd snd ipmi_si ipmi_msghandler k10temp sp5100_tco i2c_piix4 soundcore bnep 8250_fintek shpchp tpm_infineon rfcomm bluetooth mac_hid parport_pc ppdev lp parport hid_apple usbhid hid pata_acpi uas usb_storage amdkfd amd_iommu_v2 radeon psmouse pata_atiixp i2c_algo_bit ttm drm_kms_helper drm ahci libahci r8169 mii [last unloaded: sur40] CPU: 1 PID: 37 Comm: kworker/1:1 Tainted: P OE 3.19.0-031900rc6-generic #201501261152 Hardware name: Samsung SUR40/SDNE-R78BA2-20, BIOS SDNE-R78BA2-2000 11/04/2011 Workqueue: events_freezable input_polled_device_work [input_polldev] 05e0 8801320c3aa8 817c4584 0007 8801320c3af8 8801320c3ae8 81076df7 8800a71fa6c0 88013243f800 0010 0002 Call Trace: [817c4584] dump_stack+0x45/0x57 [81076df7] warn_slowpath_common+0x97/0xe0 [81076ef6] warn_slowpath_fmt+0x46/0x50 [815aff0b] usb_hcd_map_urb_for_dma+0x4eb/0x500 [817d03b4] ? schedule_timeout+0x124/0x210 [815b0bd5] usb_hcd_submit_urb+0x135/0x1c0 [815b20a6] usb_submit_urb.part.8+0x1f6/0x580 [811bb542] ? vmap_pud_range+0x122/0x1c0 [815b2465] usb_submit_urb+0x35/0x80 [815b339a] usb_start_wait_urb+0x6a/0x170 [815b1cce] ? usb_alloc_urb+0x1e/0x50 [815b1cce] ? usb_alloc_urb+0x1e/0x50 [815b3570] usb_bulk_msg+0xd0/0x1a0 [c059a841] sur40_poll+0x561/0x5e0 [sur40] [c016134b] input_polled_device_work+0x1b/0x30 [input_polldev] [8108f6dd] process_one_work+0x14d/0x460 [810900bb] worker_thread+0x11b/0x3f0 [8108ffa0] ? create_worker+0x1e0/0x1e0 [81095cc9] kthread+0xc9/0xe0 [81095c00] ? flush_kthread_worker+0x90/0x90 [817d17fc] ret_from_fork+0x7c/0xb0 [81095c00] ? flush_kthread_worker+0x90/0x90 ---[ end trace 30eaf6524fd028d3 ]--- Moreover, I'm getting the following test failure from v4l2-compliance: Streaming ioctls: test read/write: OK test MMAP: OK fail: v4l2-test-buffers.cpp(951): buf.qbuf(node) fail: v4l2-test-buffers.cpp(994): setupUserPtr(node, q) test USERPTR: FAIL test DMABUF: Cannot test, specify --expbuf-device Total: 45, Succeeded: 44, Failed: 1, Warnings: 0 Any suggestions how to deal with this? Best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH] add raw video support for Samsung SUR40 touchscreen
Hello everyone,
On 20.01.2015 14:06, Laurent Pinchart wrote:
On Tuesday 20 January 2015 14:03:00 Hans Verkuil wrote:
On 01/20/15 13:59, Laurent Pinchart wrote:
On Tuesday 20 January 2015 10:30:07 Hans Verkuil wrote:
I've CC-ed Laurent, I think he knows a lot more about this than I do.
Laurent, when does the USB core use DMA? What do you need to do on the
driver side to have USB use DMA when doing bulk transfers?
How USB HCD drivers map buffers for DMA is HCD-specific, but all drivers
exepct ehci-tegra, max3421-hcd and musb use the default implementation
usb_hcd_map_urb_for_dma() (in drivers/usb/core/hcd.c).
Unless the buffer has already been mapped by the USB driver (in which case
the driver will have set the URB_NO_TRANSFER_DMA_MAP flag in
urb-transfer_flags and initialized the urb-transfer_dma field), the
function will use dma_map_sg(), dma_map_page() or dma_map_single()
depending on the buffer type (controlled through urb-sg and
urb-num_sgs). DMA will thus always be used *expect* if the platform uses
bounce buffers when the buffer can't be mapped directly for DMA.
So we can safely use videobuf2-vmalloc, right?
That depends on the platform and whether it can DMA to vmalloc'ed memory :-)
To be totally safe I think vb2-dma-sg would be better, but I'm not sure it's
worth the trouble. uvcvideo uses vb2-vmalloc as it performs a memcpy anyway.
The SUR40 sends raw video data without any headers over the bulk
endpoint in blocks of 16k, so I'm assuming that in this specific case,
vb2-dma-sg would be the most efficient choice?
On that note, I've seen that vb2_dma_sg_{init|cleanup}_ctx will appear
only in 3.19. If I want to maintain a backwards-compatible version for
older kernels, what do I use in that case?
Best, Florian
--
SENT FROM MY DEC VT50 TERMINAL
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] add raw video support for Samsung SUR40 touchscreen
On 01/21/15 14:28, Florian Echtler wrote:
Hello everyone,
On 20.01.2015 14:06, Laurent Pinchart wrote:
On Tuesday 20 January 2015 14:03:00 Hans Verkuil wrote:
On 01/20/15 13:59, Laurent Pinchart wrote:
On Tuesday 20 January 2015 10:30:07 Hans Verkuil wrote:
I've CC-ed Laurent, I think he knows a lot more about this than I do.
Laurent, when does the USB core use DMA? What do you need to do on the
driver side to have USB use DMA when doing bulk transfers?
How USB HCD drivers map buffers for DMA is HCD-specific, but all drivers
exepct ehci-tegra, max3421-hcd and musb use the default implementation
usb_hcd_map_urb_for_dma() (in drivers/usb/core/hcd.c).
Unless the buffer has already been mapped by the USB driver (in which case
the driver will have set the URB_NO_TRANSFER_DMA_MAP flag in
urb-transfer_flags and initialized the urb-transfer_dma field), the
function will use dma_map_sg(), dma_map_page() or dma_map_single()
depending on the buffer type (controlled through urb-sg and
urb-num_sgs). DMA will thus always be used *expect* if the platform uses
bounce buffers when the buffer can't be mapped directly for DMA.
So we can safely use videobuf2-vmalloc, right?
That depends on the platform and whether it can DMA to vmalloc'ed memory :-)
To be totally safe I think vb2-dma-sg would be better, but I'm not sure it's
worth the trouble. uvcvideo uses vb2-vmalloc as it performs a memcpy anyway.
The SUR40 sends raw video data without any headers over the bulk
endpoint in blocks of 16k, so I'm assuming that in this specific case,
vb2-dma-sg would be the most efficient choice?
On that note, I've seen that vb2_dma_sg_{init|cleanup}_ctx will appear
only in 3.19. If I want to maintain a backwards-compatible version for
older kernels, what do I use in that case?
Easiest would actually be to copy all the videobuf2 sources and headers
to that older kernel.
Obviously, for upstreaming you should always use the latest APIs and
never use backwards-compatible constructs.
Regards,
Hans
--
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] add raw video support for Samsung SUR40 touchscreen
Hello Hans, On 19.01.2015 11:38, Hans Verkuil wrote: Sorry for the delay. No problem, thanks for your feedback. Note: I'm intentionally using dma-contig instead of vmalloc, as the USB core apparently _will_ try to use DMA for larger bulk transfers. As far as I can tell from looking through the usb core code it supports scatter-gather DMA, so you should at least use dma-sg rather than dma-contig. Physically contiguous memory should always be avoided. OK, will this work transparently (i.e. just switch from *-contig-* to *-sg-*)? If not, can you suggest an example driver to use as template? I'm also missing a patch for the Kconfig that adds a dependency on MEDIA_USB_SUPPORT and that selects VIDEOBUF2_DMA_SG. Good point, will add that. +err_unreg_video: +video_unregister_device(sur40-vdev); +err_unreg_v4l2: +v4l2_device_unregister(sur40-v4l2); err_free_buffer: kfree(sur40-bulk_in_buffer); err_free_polldev: @@ -436,6 +604,10 @@ static void sur40_disconnect(struct usb_interface *interface) Is this a hardwired device or hotpluggable? If it is hardwired, then this code is OK, but if it is hotpluggable, then this isn't good enough. It's hardwired. Out of curiosity, what would I have to change for a hotpluggable one? +i-type = V4L2_INPUT_TYPE_CAMERA; +i-std = V4L2_STD_UNKNOWN; +strlcpy(i-name, In-Cell Sensor, sizeof(i-name)); Perhaps just say Sensor here? I'm not sure what In-Cell means. In-cell is referring to the concept of integrating sensor pixels directly with LCD pixels, I think it's what Samsung calls it. Thanks best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH] add raw video support for Samsung SUR40 touchscreen
On 01/20/15 10:24, Florian Echtler wrote: Hello Hans, On 19.01.2015 11:38, Hans Verkuil wrote: Sorry for the delay. No problem, thanks for your feedback. Note: I'm intentionally using dma-contig instead of vmalloc, as the USB core apparently _will_ try to use DMA for larger bulk transfers. As far as I can tell from looking through the usb core code it supports scatter-gather DMA, so you should at least use dma-sg rather than dma-contig. Physically contiguous memory should always be avoided. OK, will this work transparently (i.e. just switch from *-contig-* to *-sg-*)? If not, can you suggest an example driver to use as template? Yes, that should pretty much be seamless. BTW, the more I think about it, the more I am convinced that DMA will also be used by the USB core when you use videobuf2-vmalloc. I've CC-ed Laurent, I think he knows a lot more about this than I do. Laurent, when does the USB core use DMA? What do you need to do on the driver side to have USB use DMA when doing bulk transfers? I'm also missing a patch for the Kconfig that adds a dependency on MEDIA_USB_SUPPORT and that selects VIDEOBUF2_DMA_SG. Good point, will add that. +err_unreg_video: + video_unregister_device(sur40-vdev); +err_unreg_v4l2: + v4l2_device_unregister(sur40-v4l2); err_free_buffer: kfree(sur40-bulk_in_buffer); err_free_polldev: @@ -436,6 +604,10 @@ static void sur40_disconnect(struct usb_interface *interface) Is this a hardwired device or hotpluggable? If it is hardwired, then this code is OK, but if it is hotpluggable, then this isn't good enough. It's hardwired. Out of curiosity, what would I have to change for a hotpluggable one? In that case you can't clean everything up since some application might still have a filehandle open. You have to wait until the very last filehandle is closed. + i-type = V4L2_INPUT_TYPE_CAMERA; + i-std = V4L2_STD_UNKNOWN; + strlcpy(i-name, In-Cell Sensor, sizeof(i-name)); Perhaps just say Sensor here? I'm not sure what In-Cell means. In-cell is referring to the concept of integrating sensor pixels directly with LCD pixels, I think it's what Samsung calls it. Thanks best regards, Florian Regards, Hans -- 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] add raw video support for Samsung SUR40 touchscreen
Hello, On Tuesday 20 January 2015 10:30:07 Hans Verkuil wrote: On 01/20/15 10:24, Florian Echtler wrote: On 19.01.2015 11:38, Hans Verkuil wrote: Sorry for the delay. No problem, thanks for your feedback. Note: I'm intentionally using dma-contig instead of vmalloc, as the USB core apparently _will_ try to use DMA for larger bulk transfers. As far as I can tell from looking through the usb core code it supports scatter-gather DMA, so you should at least use dma-sg rather than dma-contig. Physically contiguous memory should always be avoided. OK, will this work transparently (i.e. just switch from *-contig-* to *-sg-*)? If not, can you suggest an example driver to use as template? Yes, that should pretty much be seamless. BTW, the more I think about it, the more I am convinced that DMA will also be used by the USB core when you use videobuf2-vmalloc. I've CC-ed Laurent, I think he knows a lot more about this than I do. Laurent, when does the USB core use DMA? What do you need to do on the driver side to have USB use DMA when doing bulk transfers? How USB HCD drivers map buffers for DMA is HCD-specific, but all drivers exepct ehci-tegra, max3421-hcd and musb use the default implementation usb_hcd_map_urb_for_dma() (in drivers/usb/core/hcd.c). Unless the buffer has already been mapped by the USB driver (in which case the driver will have set the URB_NO_TRANSFER_DMA_MAP flag in urb-transfer_flags and initialized the urb-transfer_dma field), the function will use dma_map_sg(), dma_map_page() or dma_map_single() depending on the buffer type (controlled through urb-sg and urb-num_sgs). DMA will thus always be used *expect* if the platform uses bounce buffers when the buffer can't be mapped directly for DMA. I'm also missing a patch for the Kconfig that adds a dependency on MEDIA_USB_SUPPORT and that selects VIDEOBUF2_DMA_SG. Good point, will add that. +err_unreg_video: + video_unregister_device(sur40-vdev); +err_unreg_v4l2: + v4l2_device_unregister(sur40-v4l2); err_free_buffer: kfree(sur40-bulk_in_buffer); err_free_polldev: @@ -436,6 +604,10 @@ static void sur40_disconnect(struct usb_interface *interface) Is this a hardwired device or hotpluggable? If it is hardwired, then this code is OK, but if it is hotpluggable, then this isn't good enough. It's hardwired. Out of curiosity, what would I have to change for a hotpluggable one? In that case you can't clean everything up since some application might still have a filehandle open. You have to wait until the very last filehandle is closed. + i-type = V4L2_INPUT_TYPE_CAMERA; + i-std = V4L2_STD_UNKNOWN; + strlcpy(i-name, In-Cell Sensor, sizeof(i-name)); Perhaps just say Sensor here? I'm not sure what In-Cell means. In-cell is referring to the concept of integrating sensor pixels directly with LCD pixels, I think it's what Samsung calls it. -- Regards, Laurent Pinchart -- 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] add raw video support for Samsung SUR40 touchscreen
On 01/20/15 13:59, Laurent Pinchart wrote: Hello, On Tuesday 20 January 2015 10:30:07 Hans Verkuil wrote: On 01/20/15 10:24, Florian Echtler wrote: On 19.01.2015 11:38, Hans Verkuil wrote: Sorry for the delay. No problem, thanks for your feedback. Note: I'm intentionally using dma-contig instead of vmalloc, as the USB core apparently _will_ try to use DMA for larger bulk transfers. As far as I can tell from looking through the usb core code it supports scatter-gather DMA, so you should at least use dma-sg rather than dma-contig. Physically contiguous memory should always be avoided. OK, will this work transparently (i.e. just switch from *-contig-* to *-sg-*)? If not, can you suggest an example driver to use as template? Yes, that should pretty much be seamless. BTW, the more I think about it, the more I am convinced that DMA will also be used by the USB core when you use videobuf2-vmalloc. I've CC-ed Laurent, I think he knows a lot more about this than I do. Laurent, when does the USB core use DMA? What do you need to do on the driver side to have USB use DMA when doing bulk transfers? How USB HCD drivers map buffers for DMA is HCD-specific, but all drivers exepct ehci-tegra, max3421-hcd and musb use the default implementation usb_hcd_map_urb_for_dma() (in drivers/usb/core/hcd.c). Unless the buffer has already been mapped by the USB driver (in which case the driver will have set the URB_NO_TRANSFER_DMA_MAP flag in urb-transfer_flags and initialized the urb-transfer_dma field), the function will use dma_map_sg(), dma_map_page() or dma_map_single() depending on the buffer type (controlled through urb-sg and urb-num_sgs). DMA will thus always be used *expect* if the platform uses bounce buffers when the buffer can't be mapped directly for DMA. So we can safely use videobuf2-vmalloc, right? Regards, Hans I'm also missing a patch for the Kconfig that adds a dependency on MEDIA_USB_SUPPORT and that selects VIDEOBUF2_DMA_SG. Good point, will add that. +err_unreg_video: + video_unregister_device(sur40-vdev); +err_unreg_v4l2: + v4l2_device_unregister(sur40-v4l2); err_free_buffer: kfree(sur40-bulk_in_buffer); err_free_polldev: @@ -436,6 +604,10 @@ static void sur40_disconnect(struct usb_interface *interface) Is this a hardwired device or hotpluggable? If it is hardwired, then this code is OK, but if it is hotpluggable, then this isn't good enough. It's hardwired. Out of curiosity, what would I have to change for a hotpluggable one? In that case you can't clean everything up since some application might still have a filehandle open. You have to wait until the very last filehandle is closed. + i-type = V4L2_INPUT_TYPE_CAMERA; + i-std = V4L2_STD_UNKNOWN; + strlcpy(i-name, In-Cell Sensor, sizeof(i-name)); Perhaps just say Sensor here? I'm not sure what In-Cell means. In-cell is referring to the concept of integrating sensor pixels directly with LCD pixels, I think it's what Samsung calls it. -- 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] add raw video support for Samsung SUR40 touchscreen
Hi Hans, On Tuesday 20 January 2015 14:03:00 Hans Verkuil wrote: On 01/20/15 13:59, Laurent Pinchart wrote: On Tuesday 20 January 2015 10:30:07 Hans Verkuil wrote: On 01/20/15 10:24, Florian Echtler wrote: On 19.01.2015 11:38, Hans Verkuil wrote: Sorry for the delay. No problem, thanks for your feedback. Note: I'm intentionally using dma-contig instead of vmalloc, as the USB core apparently _will_ try to use DMA for larger bulk transfers. As far as I can tell from looking through the usb core code it supports scatter-gather DMA, so you should at least use dma-sg rather than dma-contig. Physically contiguous memory should always be avoided. OK, will this work transparently (i.e. just switch from *-contig-* to *-sg-*)? If not, can you suggest an example driver to use as template? Yes, that should pretty much be seamless. BTW, the more I think about it, the more I am convinced that DMA will also be used by the USB core when you use videobuf2-vmalloc. I've CC-ed Laurent, I think he knows a lot more about this than I do. Laurent, when does the USB core use DMA? What do you need to do on the driver side to have USB use DMA when doing bulk transfers? How USB HCD drivers map buffers for DMA is HCD-specific, but all drivers exepct ehci-tegra, max3421-hcd and musb use the default implementation usb_hcd_map_urb_for_dma() (in drivers/usb/core/hcd.c). Unless the buffer has already been mapped by the USB driver (in which case the driver will have set the URB_NO_TRANSFER_DMA_MAP flag in urb-transfer_flags and initialized the urb-transfer_dma field), the function will use dma_map_sg(), dma_map_page() or dma_map_single() depending on the buffer type (controlled through urb-sg and urb-num_sgs). DMA will thus always be used *expect* if the platform uses bounce buffers when the buffer can't be mapped directly for DMA. So we can safely use videobuf2-vmalloc, right? That depends on the platform and whether it can DMA to vmalloc'ed memory :-) To be totally safe I think vb2-dma-sg would be better, but I'm not sure it's worth the trouble. uvcvideo uses vb2-vmalloc as it performs a memcpy anyway. I'm also missing a patch for the Kconfig that adds a dependency on MEDIA_USB_SUPPORT and that selects VIDEOBUF2_DMA_SG. Good point, will add that. +err_unreg_video: + video_unregister_device(sur40-vdev); +err_unreg_v4l2: + v4l2_device_unregister(sur40-v4l2); err_free_buffer: kfree(sur40-bulk_in_buffer); err_free_polldev: @@ -436,6 +604,10 @@ static void sur40_disconnect(struct usb_interface *interface) Is this a hardwired device or hotpluggable? If it is hardwired, then this code is OK, but if it is hotpluggable, then this isn't good enough. It's hardwired. Out of curiosity, what would I have to change for a hotpluggable one? In that case you can't clean everything up since some application might still have a filehandle open. You have to wait until the very last filehandle is closed. + i-type = V4L2_INPUT_TYPE_CAMERA; + i-std = V4L2_STD_UNKNOWN; + strlcpy(i-name, In-Cell Sensor, sizeof(i-name)); Perhaps just say Sensor here? I'm not sure what In-Cell means. In-cell is referring to the concept of integrating sensor pixels directly with LCD pixels, I think it's what Samsung calls it. -- Regards, Laurent Pinchart -- 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] add raw video support for Samsung SUR40 touchscreen
Hi Florian,
Sorry for the delay.
Several comments below...
On 01/07/2015 11:35 AM, Florian Echtler wrote:
This patch add support for the raw video stream from the Samsung SUR40
touchscreen device. Existing input device support is not affected by this
patch and can be used concurrently. videobuf2-dma-contig is used for buffer
management. All tests from current v4l2-compliance -s run pass (see
http://floe.butterbrot.org/external/results.txt for details).
Note: I'm intentionally using dma-contig instead of vmalloc, as the USB
core apparently _will_ try to use DMA for larger bulk transfers.
As far as I can tell from looking through the usb core code it supports
scatter-gather DMA, so you should at least use dma-sg rather than dma-contig.
Physically contiguous memory should always be avoided.
I'm also missing a patch for the Kconfig that adds a dependency on
MEDIA_USB_SUPPORT
and that selects VIDEOBUF2_DMA_SG.
Signed-off-by: Florian Echtler f...@butterbrot.org
---
drivers/input/touchscreen/sur40.c | 423
--
1 file changed, 411 insertions(+), 12 deletions(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index f1cb051..bcd9ee2 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -1,7 +1,7 @@
/*
* Surface2.0/SUR40/PixelSense input driver
*
- * Copyright (c) 2013 by Florian 'floe' Echtler f...@butterbrot.org
+ * Copyright (c) 2014 by Florian 'floe' Echtler f...@butterbrot.org
*
* Derived from the USB Skeleton driver 1.1,
* Copyright (c) 2003 Greg Kroah-Hartman (g...@kroah.com)
@@ -12,6 +12,9 @@
* and from the generic hid-multitouch driver,
* Copyright (c) 2010-2012 Stephane Chatty cha...@enac.fr
*
+ * and from the v4l2-pci-skeleton driver,
+ * Copyright (c) Copyright 2014 Cisco Systems, Inc.
+ *
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
@@ -31,6 +34,11 @@
#include linux/input-polldev.h
#include linux/input/mt.h
#include linux/usb/input.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-dev.h
+#include media/v4l2-ioctl.h
+#include media/videobuf2-dma-contig.h
/* read 512 bytes from endpoint 0x86 - get header + blobs */
struct sur40_header {
@@ -82,9 +90,19 @@ struct sur40_data {
struct sur40_blob blobs[];
} __packed;
+/* read 512 bytes from endpoint 0x82 - get header below
+ * continue reading 16k blocks until header.size bytes read */
+struct sur40_image_header {
+ __le32 magic; /* SUBF */
+ __le32 packet_id;
+ __le32 size; /* always 0x0007e900 = 960x540 */
+ __le32 timestamp; /* milliseconds (increases by 16 or 17 each frame) */
+ __le32 unknown; /* epoch? always 02/03 00 00 00 */
+} __packed;
/* version information */
#define DRIVER_SHORT sur40
+#define DRIVER_LONGSamsung SUR40
#define DRIVER_AUTHOR Florian 'floe' Echtler f...@butterbrot.org
#define DRIVER_DESCSurface2.0/SUR40/PixelSense input driver
@@ -99,6 +117,13 @@ struct sur40_data {
/* touch data endpoint */
#define TOUCH_ENDPOINT 0x86
+/* video data endpoint */
+#define VIDEO_ENDPOINT 0x82
+
+/* video header fields */
+#define VIDEO_HEADER_MAGIC 0x46425553
+#define VIDEO_PACKET_SIZE 16384
+
/* polling interval (ms) */
#define POLL_INTERVAL 10
@@ -113,21 +138,23 @@ struct sur40_data {
#define SUR40_GET_STATE 0xc5 /* 4 bytes state (?) */
#define SUR40_GET_SENSORS 0xb1 /* 8 bytes sensors */
-/*
- * Note: an earlier, non-public version of this driver used
USB_RECIP_ENDPOINT
- * here by mistake which is very likely to have corrupted the firmware EEPROM
- * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
- * Should you ever run into a similar problem, the background story to this
- * incident and instructions on how to fix the corrupted EEPROM are available
- * at https://floe.butterbrot.org/matrix/hacking/surface/brick.html
-*/
-
+/* master device state */
struct sur40_state {
struct usb_device *usbdev;
struct device *dev;
struct input_polled_dev *input;
+ struct v4l2_device v4l2;
+ struct video_device vdev;
+ struct mutex lock;
+
+ struct vb2_queue queue;
+ struct vb2_alloc_ctx *alloc_ctx;
+ struct list_head buf_list;
+ spinlock_t qlock;
+ int sequence;
+
struct sur40_data *bulk_in_buffer;
size_t bulk_in_size;
u8 bulk_in_epaddr;
@@ -135,6 +162,27 @@ struct sur40_state {
char phys[64];
};
+struct sur40_buffer {
+ struct vb2_buffer vb;
+ struct list_head list;
+};
+
+/* forward declarations */
+static struct video_device sur40_video_device;
+static struct v4l2_pix_format sur40_video_format;
+static struct
[PATCH] add raw video support for Samsung SUR40 touchscreen
This patch add support for the raw video stream from the Samsung SUR40
touchscreen device. Existing input device support is not affected by this
patch and can be used concurrently. videobuf2-dma-contig is used for buffer
management. All tests from current v4l2-compliance -s run pass (see
http://floe.butterbrot.org/external/results.txt for details).
Note: I'm intentionally using dma-contig instead of vmalloc, as the USB
core apparently _will_ try to use DMA for larger bulk transfers.
Signed-off-by: Florian Echtler f...@butterbrot.org
---
drivers/input/touchscreen/sur40.c | 423 --
1 file changed, 411 insertions(+), 12 deletions(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index f1cb051..bcd9ee2 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -1,7 +1,7 @@
/*
* Surface2.0/SUR40/PixelSense input driver
*
- * Copyright (c) 2013 by Florian 'floe' Echtler f...@butterbrot.org
+ * Copyright (c) 2014 by Florian 'floe' Echtler f...@butterbrot.org
*
* Derived from the USB Skeleton driver 1.1,
* Copyright (c) 2003 Greg Kroah-Hartman (g...@kroah.com)
@@ -12,6 +12,9 @@
* and from the generic hid-multitouch driver,
* Copyright (c) 2010-2012 Stephane Chatty cha...@enac.fr
*
+ * and from the v4l2-pci-skeleton driver,
+ * Copyright (c) Copyright 2014 Cisco Systems, Inc.
+ *
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
@@ -31,6 +34,11 @@
#include linux/input-polldev.h
#include linux/input/mt.h
#include linux/usb/input.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-dev.h
+#include media/v4l2-ioctl.h
+#include media/videobuf2-dma-contig.h
/* read 512 bytes from endpoint 0x86 - get header + blobs */
struct sur40_header {
@@ -82,9 +90,19 @@ struct sur40_data {
struct sur40_blob blobs[];
} __packed;
+/* read 512 bytes from endpoint 0x82 - get header below
+ * continue reading 16k blocks until header.size bytes read */
+struct sur40_image_header {
+ __le32 magic; /* SUBF */
+ __le32 packet_id;
+ __le32 size; /* always 0x0007e900 = 960x540 */
+ __le32 timestamp; /* milliseconds (increases by 16 or 17 each frame) */
+ __le32 unknown; /* epoch? always 02/03 00 00 00 */
+} __packed;
/* version information */
#define DRIVER_SHORT sur40
+#define DRIVER_LONGSamsung SUR40
#define DRIVER_AUTHOR Florian 'floe' Echtler f...@butterbrot.org
#define DRIVER_DESCSurface2.0/SUR40/PixelSense input driver
@@ -99,6 +117,13 @@ struct sur40_data {
/* touch data endpoint */
#define TOUCH_ENDPOINT 0x86
+/* video data endpoint */
+#define VIDEO_ENDPOINT 0x82
+
+/* video header fields */
+#define VIDEO_HEADER_MAGIC 0x46425553
+#define VIDEO_PACKET_SIZE 16384
+
/* polling interval (ms) */
#define POLL_INTERVAL 10
@@ -113,21 +138,23 @@ struct sur40_data {
#define SUR40_GET_STATE 0xc5 /* 4 bytes state (?) */
#define SUR40_GET_SENSORS 0xb1 /* 8 bytes sensors */
-/*
- * Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
- * here by mistake which is very likely to have corrupted the firmware EEPROM
- * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
- * Should you ever run into a similar problem, the background story to this
- * incident and instructions on how to fix the corrupted EEPROM are available
- * at https://floe.butterbrot.org/matrix/hacking/surface/brick.html
-*/
-
+/* master device state */
struct sur40_state {
struct usb_device *usbdev;
struct device *dev;
struct input_polled_dev *input;
+ struct v4l2_device v4l2;
+ struct video_device vdev;
+ struct mutex lock;
+
+ struct vb2_queue queue;
+ struct vb2_alloc_ctx *alloc_ctx;
+ struct list_head buf_list;
+ spinlock_t qlock;
+ int sequence;
+
struct sur40_data *bulk_in_buffer;
size_t bulk_in_size;
u8 bulk_in_epaddr;
@@ -135,6 +162,27 @@ struct sur40_state {
char phys[64];
};
+struct sur40_buffer {
+ struct vb2_buffer vb;
+ struct list_head list;
+};
+
+/* forward declarations */
+static struct video_device sur40_video_device;
+static struct v4l2_pix_format sur40_video_format;
+static struct vb2_queue sur40_queue;
+static void sur40_process_video(struct sur40_state *sur40);
+
+/*
+ * Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
+ * here by mistake which is very likely to have corrupted the firmware EEPROM
+ * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
+ * Should you ever run into a similar problem, the background story to this
+ * incident and instructions on how to fix the corrupted EEPROM are available
+ * at
