Re: [PATCH] dma: fix ipu_idmac.c to not discard the last queued buffer
--- On Sat, 16/5/09, Russell King wrote: On Sat, May 16, 2009 at 08:22:18PM +0200, Guennadi Liakhovetski wrote: Hopefully with real tags (iow, with email addresses) rather than what's shown above (which is unacceptable.) Sure, Dan has done it perfectly: http://git.kernel.org/?p=linux/kernel/git/djbw/async_tx.git;a=commitdiff;h=ad567ffb32f067b30606071eb568cf637fe42185 as it also was in the patch submission http://marc.info/?l=linux-arm-kernelm=124212146702853w=2 and _not_ as it was in the mail that you quote. Looks like Agustin's mail client is removing the ... parts from those tags - look at the next message in the thread. Indeed. It was the new flash-based memory-hogging client from Yahoo. Just switched to the old one, not so 'smart' but not very compliant either... I will have to look for a nicer option. --Agustín. -- 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] dma: fix ipu_idmac.c to not discard the last queued buffer
On Tue, 12 May 2009, Guennadi Liakhovetski wrote:
This also fixes the case of a single queued buffer, for example, when taking a
single frame snapshot with the mx3_camera driver.
Reported-by: Agustin
Signed-off-by: Guennadi Liakhovetski
Signed-off-by: Agustin Ferrin Pozuelo
---
Subject: Re: Grabbing single stills on MX31 - Re: Solved? - Re:
soc-camera: timing out during capture - Re: Testing latest mx3_camera.c
On Mon, 11 May 2009, Agustin wrote:
On Thu, 7 May 2009, Guennadi Liakhovetski wrote:
On Thu, 7 May 2009, Agustin Ferrin Pozuelo wrote:
...
I thought about the fact that I was only queuing one buffer, and that
this might be a corner case as sample code uses a lot of them. And that
in the older code that funny things could happen in the handler if we
ran out of buffers, though they didn't happen.
So I have queued an extra buffer and voila, got it working.
So thanks again!
However, this could be a bug in ipu_idmac (or some other point), as
using a single buffer is very plausible, specially when grabbing huge
stills.
Great, thanks for testing and debugging! Ok, so, I will have to test this
case some time...
Agustin, does this patch fix your problem? Dan, please, pull it as soon as
we get a tested-by from Agustin.
Yes it works. And it happens to save 33% of system CPU time in addition to
freeing a lot of memory bandwith. Timings after this fix:
Vblank / real/ user / sys time:
[any] / real 0.50s / user 0.00s / sys 0.22s
(Everything was for a 3888x1944x15bpp still)
This workaround (queuing 2 buffers when needing only one) is having the
side effect of greatly increasing the time taken.
I did several tests playing with camera vertical blanking and looking at
capture times:
Vblank / real / user / sys time:
0 / real0m 0.90s / user0m 0.00s / sys 0m 0.34s
1 frame / real0m 1.04s / user0m 0.00s / sys 0m 0.34s
2 frames / real0m 1.18s / user0m 0.00s / sys 0m 0.33s
2.5 (max)/ real0m 1.23s / user0m 0.00s / sys 0m 0.35s
I think the second frame is being captured altogether, and its dma
transfer is not allowing any other process to run meanwhile.
(VIDIOC_STREAMOFF is being called as soon as the first buffer is ready.)
I don't quite understand this. What exactly are you doing above? You
submit 2 buffers and change vertical blanking? Where do you change the
blanking - in the driver? How exactly?
Do you think it will be too hard to fix?
The blanking issue or the 1-buffer problem?
Eh-eh, it was the same!
Thanks a lot!
--Agustín.
Thanks
Guennadi
drivers/dma/ipu/ipu_idmac.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index 3a4deea..9a5bc1a 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -1272,7 +1272,8 @@ static irqreturn_t idmac_interrupt(int irq, void
*dev_id)
/* Other interrupts do not interfere with this channel */
spin_lock(ichan-lock);
if (unlikely(chan_id != IDMAC_SDC_0 chan_id != IDMAC_SDC_1
- ((curbuf chan_id) 1) == ichan-active_buffer)) {
+ ((curbuf chan_id) 1) == ichan-active_buffer
+ !list_is_last(ichan-queue.next, ichan-queue))) {
int i = 100;
/* This doesn't help. See comment in ipu_disable_channel() */
--
1.6.2.4
--
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
Grabbing single stills on MX31 - Re: Solved? - Re: soc-camera: timing out during capture - Re: Testing latest mx3_camera.c
On Thu, 7 May 2009, Guennadi Liakhovetski wrote: On Thu, 7 May 2009, Agustin Ferrin Pozuelo wrote: ... I thought about the fact that I was only queuing one buffer, and that this might be a corner case as sample code uses a lot of them. And that in the older code that funny things could happen in the handler if we ran out of buffers, though they didn't happen. So I have queued an extra buffer and voila, got it working. So thanks again! However, this could be a bug in ipu_idmac (or some other point), as using a single buffer is very plausible, specially when grabbing huge stills. Great, thanks for testing and debugging! Ok, so, I will have to test this case some time... Guennadi, This workaround (queuing 2 buffers when needing only one) is having the side effect of greatly increasing the time taken. I did several tests playing with camera vertical blanking and looking at capture times: Vblank / real / user / sys time: 0 / real0m 0.90s / user0m 0.00s / sys 0m 0.34s 1 frame / real0m 1.04s / user0m 0.00s / sys 0m 0.34s 2 frames / real0m 1.18s / user0m 0.00s / sys 0m 0.33s 2.5 (max)/ real0m 1.23s / user0m 0.00s / sys 0m 0.35s I think the second frame is being captured altogether, and its dma transfer is not allowing any other process to run meanwhile. (VIDIOC_STREAMOFF is being called as soon as the first buffer is ready.) Do you think it will be too hard to fix? Regards, --Agustín. -- 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: soc-camera: timing out during capture - Re: Testing latest mx3_camera.c
On Tue, 5 May 2009, Guennadi Liakhovetski wrote: On Tue, 5 May 2009, Agustin wrote: No, as there is no driver_match_device() in 2.6.29 nor in my patched version. How important is that? No, sorry, forget it, that's not your problem. Meanwhile I noticed that IRQ 176 is being triggered, then discarded as unhandled by ipu_idmac, who gives the message IRQ on active buffer on channel 7, active 0, ready 0, 0, current 0! below... Yes, and this is not good. If you look in drivers/dma/ipu/ipu_idmac.c idmac_interrupt() you'll see, that this message is printed when IDMAC produces an interrupt for a DMA buffer, but at the same time it says, that the buffer, that should have completed is still in use... I've seen a few of such inconsistencies, and up to now always managed to get rid of them in one or another way. But that should not be related to the conversion. Maybe your formats on the sensor and on the SoC do not match, verify that. Thanks for the tip but I am still out of luck. I enabled DEBUG in ipu_idmac.c just to see that frame start and end are happening more or less when they should: [...] camera 0-0: mx3_camera: Submitted cookie 2 DMA 0x8640 Got SOF IRQ 177 on Channel 7 Got EOF IRQ 178 on Channel 7 dma dma0chan7: ipu_idmac: IDMAC irq 176, buf 0 dma dma0chan7: ipu_idmac: IRQ on active buffer on channel 7, active 0, ready 0, 0, current 0! Select timeout. [...] I also configured everything to the simplest mode I can have: 8-bit bus, sample falling. So I am now looking at IDMAC, trying to guess what could be wrong, but I feel quite lost at the moment. I am starting to fear that I introduced some subtle bug while merging your stack into Sascha's... Where can I check mx3_camera.c, ipu_idmac.c, soc_camera.c prior to the subdev changes? I would like them to check that my edited patches lead to the same sources as the originals. Thanks regards, --Agustín. I am not sure where to look for the problem, so here is a debug dump in case you can point me in the right direction... r...@sixcam:~ insmod sixcam.ko sixcam_mod_init(): ok Sixcam TRIGGER on Sixcam board: ATA_CS0~MCU3_26 sixcam_i2c_probe(): ok camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897 sixcam_init(): initialized camera. camera 0-0: MX3 Camera driver attached to camera 0 sixcam_video_probe(): probed camera. mx3-camera mx3-camera.0: soc_camera: Allocated video_device c6080a00 sixcam_release(): ok camera 0-0: MX3 Camera driver detached from camera 0 r...@sixcam:~ capture --bpp 8 --size 1536x1024 mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: requested bus width 15 bit: 0 mx3-camera.0: mx3_camera: requested bus width 10 bit: 0 camera 0-0: soc_camera: Found 0 supported formats. mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: Providing format Monochrome 8 bit in pass-through mode mx3-camera.0: mx3_camera: requested bus width 15 bit: 0 mx3-camera.0: mx3_camera: Providing format Monochrome 16 bit in pass-through mode mx3-camera.0: mx3_camera: requested bus width 10 bit: 0 mx3-camera.0: mx3_camera: Providing format Sixcam 10-bit in pass-through mode camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897 sixcam_init(): initialized camera. camera 0-0: MX3 Camera driver attached to camera 0 camera 0-0: soc_camera: camera device open sixcam_set_fmt(): 640x480+0+0 sixcam_try_fmt(): icd-width=640 icd-height=480 fmt.pix.width=1536 fmt.pix.height=1024. -- fmt.pix.width=1536 fmt.pix.height=1024. ipu-core: ipu_idmac: timeout = 0 * 10ms ipu-core: ipu_idmac: init channel = 7 ipu-core: ipu_idmac: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x0, IDMAC_CHA_PRI 0x80, IDMAC_CHA_BUSY 0x0 ipu-core: ipu_idmac: BUF0_RDY 0x0, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 0x0, TASKS_STAT 0x3 dma dma0chan7: ipu_idmac: Found channel 0x7, irq 176 sixcam_set_fmt(): 1536x1024+0+0 camera 0-0: soc_camera: set width: 1536 height: 1024 mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: Flags cam: 0x2695 host: 0xf0fd common: 0x2095 sixcam_set_bus_param(): 0x2095 mx3-camera.0: mx3_camera: Set SENS_CONF to 708 VIDIOC_S_FMT: width 1536, heightcamera 0-0: soc_camera: soc_camera_reqbufs: 1 1024, pixelformat = 'GREY' mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_free camera 0-0: soc_camera: mmap called, vma=0xc4f886e0 mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_mapper mx3-camera.0: videobuf_dma_contig: dma_alloc_coherent data is at addr c900 (size 1572864) mx3-camera.0: videobuf_dma_contig: mmap c4fafec0: q=c8b63004 40147000-402c7000 (18) pgoff 00084000 buf 0 mx3-camera.0: videobuf_dma_contig: vm_open c4fafec0 [count=0,vma
Solved? - Re: soc-camera: timing out during capture - Re: Testing latest mx3_camera.c
Holy cow... On Tue, 5 May 2009, Agustin wrote: On Tue, 5 May 2009, Guennadi Liakhovetski wrote: On Tue, 5 May 2009, Agustin wrote: No, as there is no driver_match_device() in 2.6.29 nor in my patched version. How important is that? No, sorry, forget it, that's not your problem. Meanwhile I noticed that IRQ 176 is being triggered, then discarded as unhandled by ipu_idmac, who gives the message IRQ on active buffer on channel 7, active 0, ready 0, 0, current 0! below... Yes, and this is not good. If you look in drivers/dma/ipu/ipu_idmac.c idmac_interrupt() you'll see, that this message is printed when IDMAC produces an interrupt for a DMA buffer, but at the same time it says, that the buffer, that should have completed is still in use... I've seen a few of such inconsistencies, and up to now always managed to get rid of them in one or another way. But that should not be related to the conversion. Maybe your formats on the sensor and on the SoC do not match, verify that. Thanks for the tip but I am still out of luck. I enabled DEBUG in ipu_idmac.c just to see that frame start and end are happening more or less when they should: [...] camera 0-0: mx3_camera: Submitted cookie 2 DMA 0x8640 Got SOF IRQ 177 on Channel 7 Got EOF IRQ 178 on Channel 7 dma dma0chan7: ipu_idmac: IDMAC irq 176, buf 0 dma dma0chan7: ipu_idmac: IRQ on active buffer on channel 7, active 0, ready 0, 0, current 0! Select timeout. [...] I also configured everything to the simplest mode I can have: 8-bit bus, sample falling. So I am now looking at IDMAC, trying to guess what could be wrong... [snip] After checking out every single bit in CSI and IDMAC to be correct according to reference and the same I had in the previous/working version... I thought about the fact that I was only queuing one buffer, and that this might be a corner case as sample code uses a lot of them. And that in the older code that funny things could happen in the handler if we ran out of buffers, though they didn't happen. So I have queued an extra buffer and voila, got it working. So thanks again! However, this could be a bug in ipu_idmac (or some other point), as using a single buffer is very plausible, specially when grabbing huge stills. --Agustín. [snip!] -- 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
soc-camera: timing out during capture - Re: Testing latest mx3_camera.c
Hi Guennadi, --- Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Mon, 13 Apr 2009, Agustin wrote: Which patchset should one use today to have latest and most stable mx3_camera driver in 2.6.29? [snip] Please, use http://marc.info/?l=linux-arm-kernelm=123866462620240w=2 also notice, which patches it needs. As a basis you can take linux-next or a suitable branch from git://git.pengutronix.de/git/imx/linux-2.6.git I managed to merge your patch stack of 20090415 on top of Sascha's stack for 2.6.29. I think that is just before the v4l-subdev work. Then I adapted my code to work pretty much as your mt9p031 driver. Now I get a timeout when trying to capture a single image, with the same hardware configuration that is working fine with 2.6.28-next. I can see my Sixcam camera dumping a few frames before the timeout. I am not sure where to look for the problem, so here is a debug dump in case you can point me in the right direction... r...@sixcam:~ insmod sixcam.ko sixcam_mod_init(): ok Sixcam TRIGGER on Sixcam board: ATA_CS0~MCU3_26 sixcam_i2c_probe(): ok camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897 sixcam_init(): initialized camera. camera 0-0: MX3 Camera driver attached to camera 0 sixcam_video_probe(): probed camera. mx3-camera mx3-camera.0: soc_camera: Allocated video_device c6080a00 sixcam_release(): ok camera 0-0: MX3 Camera driver detached from camera 0 r...@sixcam:~ capture --bpp 8 --size 1536x1024 mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: requested bus width 15 bit: 0 mx3-camera.0: mx3_camera: requested bus width 10 bit: 0 camera 0-0: soc_camera: Found 0 supported formats. mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: Providing format Monochrome 8 bit in pass-through mode mx3-camera.0: mx3_camera: requested bus width 15 bit: 0 mx3-camera.0: mx3_camera: Providing format Monochrome 16 bit in pass-through mode mx3-camera.0: mx3_camera: requested bus width 10 bit: 0 mx3-camera.0: mx3_camera: Providing format Sixcam 10-bit in pass-through mode camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897 sixcam_init(): initialized camera. camera 0-0: MX3 Camera driver attached to camera 0 camera 0-0: soc_camera: camera device open sixcam_set_fmt(): 640x480+0+0 sixcam_try_fmt(): icd-width=640 icd-height=480 fmt.pix.width=1536 fmt.pix.height=1024. -- fmt.pix.width=1536 fmt.pix.height=1024. ipu-core: ipu_idmac: timeout = 0 * 10ms ipu-core: ipu_idmac: init channel = 7 ipu-core: ipu_idmac: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x0, IDMAC_CHA_PRI 0x80, IDMAC_CHA_BUSY 0x0 ipu-core: ipu_idmac: BUF0_RDY 0x0, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 0x0, TASKS_STAT 0x3 dma dma0chan7: ipu_idmac: Found channel 0x7, irq 176 sixcam_set_fmt(): 1536x1024+0+0 camera 0-0: soc_camera: set width: 1536 height: 1024 mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: Flags cam: 0x2695 host: 0xf0fd common: 0x2095 sixcam_set_bus_param(): 0x2095 mx3-camera.0: mx3_camera: Set SENS_CONF to 708 VIDIOC_S_FMT: width 1536, heightcamera 0-0: soc_camera: soc_camera_reqbufs: 1 1024, pixelformat = 'GREY' mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_free camera 0-0: soc_camera: mmap called, vma=0xc4f886e0 mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_mapper mx3-camera.0: videobuf_dma_contig: dma_alloc_coherent data is at addr c900 (size 1572864) mx3-camera.0: videobuf_dma_contig: mmap c4fafec0: q=c8b63004 40147000-402c7000 (18) pgoff 00084000 buf 0 mx3-camera.0: videobuf_dma_contig: vm_open c4fafec0 [count=0,vma=40147000-402c7000] camera 0-0: soc_camera: vma start=0x40147000, size=1572864, ret=0 mx3-camera.0: videobuf_dma_contig: __videobuf_iolock memory method MMAP camera 0-0: soc_camera: soc_camera_streamon sixcam_start_capture(): trigger on! ipu-core: ipu_idmac: write param mem - addr = 0x00010070, data = 0x ipu-core: ipu_idmac: write param mem - addr = 0x00010071, data = 0x4000 ipu-core: ipu_idmac: write param mem - addr = 0x00010072, data = 0x ipu-core: ipu_idmac: write param mem - addr = 0x00010073, data = 0xFF5FF000 ipu-core: ipu_idmac: write param mem - addr = 0x00010074, data = 0x0003 ipu-core: ipu_idmac: write param mem - addr = 0x00010078, data = 0x8400 ipu-core: ipu_idmac: write param mem - addr = 0x00010079, data = 0x ipu-core: ipu_idmac: write param mem - addr = 0x0001007A, data = 0x3E0E2FFB ipu-core: ipu_idmac: write param mem - addr = 0x0001007B, data = 0x0002 ipu-core: ipu_idmac: write param mem - addr = 0x0001007C, data = 0x dma dma0chan7: ipu_idmac: Submitting sg c4e0772c dma dma0chan7: ipu_idmac: Updated sg c4e0772c on channel 0x7 buffer 0 ipu-core: ipu_idmac: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x0, IDMAC_CHA_PRI 0x80, IDMAC_CHA_BUSY 0x0 ipu-core: ipu_idmac: BUF0_RDY 0x80, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 0x0, TASKS_STAT 0x3 ipu-core: ipu_idmac: IDMAC_CONF 0x70, IC_CONF 0x4001
Re: soc-camera: timing out during capture - Re: Testing latest mx3_camera.c
On Tue, 5 May 2009, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Tue, 5 May 2009, Agustin wrote: Hi Guennadi, --- Guennadi Liakhovetski wrote: On Mon, 13 Apr 2009, Agustin wrote: Which patchset should one use today to have latest and most stable mx3_camera driver in 2.6.29? [snip] Please, use http://marc.info/?l=linux-arm-kernelm=123866462620240w=2 also notice, which patches it needs. As a basis you can take linux-next or a suitable branch from git://git.pengutronix.de/git/imx/linux-2.6.git I managed to merge your patch stack of 20090415 on top of Sascha's stack for 2.6.29. I think that is just before the v4l-subdev work. Then I adapted my code to work pretty much as your mt9p031 driver. Now I get a timeout when trying to capture a single image, with the same hardware configuration that is working fine with 2.6.28-next. I can see my Sixcam camera dumping a few frames before the timeout. Have you applied this patch: Author: Ming Lei Date: Fri Mar 27 21:50:00 2009 +0800 driver core: fix driver_match_device This patch fixes a bug introduced in commit 49b420a13ff95b449947181190b08367348e3e1b. If a instance of bus_type doesn't have .match method, all .probe of drivers in the bus should be called, or else the .probe have not a chance to be called. Signed-off-by: Ming Lei Reported-by: Guennadi Liakhovetski Signed-off-by: Greg Kroah-Hartman ? No, as there is no driver_match_device() in 2.6.29 nor in my patched version. How important is that? Meanwhile I noticed that IRQ 176 is being triggered, then discarded as unhandled by ipu_idmac, who gives the message IRQ on active buffer on channel 7, active 0, ready 0, 0, current 0! below... I am not sure where to look for the problem, so here is a debug dump in case you can point me in the right direction... r...@sixcam:~ insmod sixcam.ko sixcam_mod_init(): ok Sixcam TRIGGER on Sixcam board: ATA_CS0~MCU3_26 sixcam_i2c_probe(): ok camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897 sixcam_init(): initialized camera. camera 0-0: MX3 Camera driver attached to camera 0 sixcam_video_probe(): probed camera. mx3-camera mx3-camera.0: soc_camera: Allocated video_device c6080a00 sixcam_release(): ok camera 0-0: MX3 Camera driver detached from camera 0 r...@sixcam:~ capture --bpp 8 --size 1536x1024 mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: requested bus width 15 bit: 0 mx3-camera.0: mx3_camera: requested bus width 10 bit: 0 camera 0-0: soc_camera: Found 0 supported formats. mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: Providing format Monochrome 8 bit in pass-through mode mx3-camera.0: mx3_camera: requested bus width 15 bit: 0 mx3-camera.0: mx3_camera: Providing format Monochrome 16 bit in pass-through mode mx3-camera.0: mx3_camera: requested bus width 10 bit: 0 mx3-camera.0: mx3_camera: Providing format Sixcam 10-bit in pass-through mode camera 0-0: mx3_camera: Set SENS_CONF to f00, rate 19523897 sixcam_init(): initialized camera. camera 0-0: MX3 Camera driver attached to camera 0 camera 0-0: soc_camera: camera device open sixcam_set_fmt(): 640x480+0+0 sixcam_try_fmt(): icd-width=640 icd-height=480 fmt.pix.width=1536 fmt.pix.height=1024. -- fmt.pix.width=1536 fmt.pix.height=1024. ipu-core: ipu_idmac: timeout = 0 * 10ms ipu-core: ipu_idmac: init channel = 7 ipu-core: ipu_idmac: IDMAC_CONF 0x70, IC_CONF 0x0, IDMAC_CHA_EN 0x0, IDMAC_CHA_PRI 0x80, IDMAC_CHA_BUSY 0x0 ipu-core: ipu_idmac: BUF0_RDY 0x0, BUF1_RDY 0x0, CUR_BUF 0x0, DB_MODE 0x0, TASKS_STAT 0x3 dma dma0chan7: ipu_idmac: Found channel 0x7, irq 176 sixcam_set_fmt(): 1536x1024+0+0 camera 0-0: soc_camera: set width: 1536 height: 1024 mx3-camera.0: mx3_camera: requested bus width 8 bit: 0 mx3-camera.0: mx3_camera: Flags cam: 0x2695 host: 0xf0fd common: 0x2095 sixcam_set_bus_param(): 0x2095 mx3-camera.0: mx3_camera: Set SENS_CONF to 708 VIDIOC_S_FMT: width 1536, heightcamera 0-0: soc_camera: soc_camera_reqbufs: 1 1024, pixelformat = 'GREY' mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_free camera 0-0: soc_camera: mmap called, vma=0xc4f886e0 mx3-camera.0: videobuf_dma_contig: __videobuf_mmap_mapper mx3-camera.0: videobuf_dma_contig: dma_alloc_coherent data is at addr c900 (size 1572864) mx3-camera.0: videobuf_dma_contig: mmap c4fafec0: q=c8b63004 40147000-402c7000 (18) pgoff 00084000 buf 0 mx3-camera.0: videobuf_dma_contig: vm_open c4fafec0 [count=0,vma=40147000-402c7000] camera 0-0: soc_camera: vma start=0x40147000, size=1572864, ret=0 mx3-camera.0: videobuf_dma_contig: __videobuf_iolock memory method MMAP camera 0-0: soc_camera: soc_camera_streamon sixcam_start_capture(): trigger on! ipu-core: ipu_idmac
Re: [PATCH] v4l2-subdev: add a v4l2_i2c_new_dev_subdev() function
On 21/4/09, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Tue, 21 Apr 2009, Agustin wrote: Hi, On 21/4/09, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Video (sub)devices, connecting to SoCs over generic i2c busses cannot provide a pointer to struct v4l2_device in i2c-adapter driver_data, and provide their own i2c_board_info data, including a platform_data field. Add a v4l2_i2c_new_dev_subdev() API function that does exactly the same as v4l2_i2c_new_subdev() but uses different parameters, and make v4l2_i2c_new_subdev() a wrapper around it. [snip] I am wondering about this ongoing effort and its pursued goal: is it to hierarchize the v4l architecture, adding new abstraction levels? If so, what for? Driver-reuse. soc-camera framework will be able to use all available and new v4l2-subdev drivers, and vice versa. Well, Driver reuse. sounds more as a mantra than a reason for me. Then I can't find any available v4l2-subdev driver in 2.6.29. I assume this subdev stuff plays a mayor role in current V4L2 architecture refactorization. Then we probably should take this opportunity to relieve V4L APIs from all its explicit I2C mangling, because... To me, as an eventual driver developer, this makes it harder to integrate my own drivers, as I use I2C and V4L in my system but I don't want them to be tightly coupled. This conversion shouldn't make the coupling any tighter. But still I think V4L system should not be aware of I2C at all. To me, V4L is a kernel subsystem in charge of moving multimedia data from/to userspace/hardware, and the APIs should reflect just that. If one V4L driver uses I2C for device control, what does V4L have to say about that, really? Or why V4L would never care about usb or SPI links? I2C and V4L should stay cleanly and clearly apart. Of course I can ignore this subdev stuff and just link against soc-camera which is what I need, and manage I2C without V4L knowing about it. Which is what I do. You won't be able to. The only link to woc-camera will be the v4l2-subdev link. Already now with this patch many essential soc-camera API operations are gone. I guess you mean that I will have to use v4l2-subdev interface to connect to soc-camera, and not to surrender my I2C management to an I2C-extraneous subsystem. Is that right? (Sorry for arriving this late to the discussion just to critizise your good efforts.) Regards, --Agustín. -- 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/RFC 1/4] ipu_idmac: code clean-up and robustness improvements
--- On 28/2/09, Guennadi Liakhovetski wrote: On Sat, 28 Feb 2009, Agustin wrote: Hi Guennadi, I am having trouble while probing ipu idmac: At boot: ipu-core: probe of ipu-core failed with error -22 Which is apparently happening at ipu_idmac:1706: 1695 static int __init ipu_probe(struct platform_device *pdev) ... 1703 mem_ipu = platform_get_resource(pdev, IORESOURCE_MEM, 0); 1704 mem_ic = platform_get_resource(pdev, IORESOURCE_MEM, 1); 1705 if (!pdata || !mem_ipu || !mem_ic) 1706 return -EINVAL; Later on, I get error 16, Device or resource busy on VIDIOC_S_FMT, apparently because mx3_camera can't get its dma channel. Any clue? Are you sure it is failing here, have you verified with a printk? If it is indeed this place, then you probably didn't register all required resources in your platfom code. Look at my platform-bindings patch. Thanks Guennadi Thanks, I was missing mx3_ipu_data struct at devices.c file. It happened because I had git-pulled Valentin's older patch from mxc-master which made your patch fail a few chunks, then the code was very similar when I checked it visually. Now let's see if I can get back on track with my new hardware design and take those pics... Regards, --Agustín. -- 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/RFC 1/4] ipu_idmac: code clean-up and robustness improvements
Hi Guennadi,
I am having trouble while probing ipu idmac:
At boot:
ipu-core: probe of ipu-core failed with error -22
Which is apparently happening at ipu_idmac:1706:
1695 static int __init ipu_probe(struct platform_device *pdev)
...
1703 mem_ipu = platform_get_resource(pdev, IORESOURCE_MEM, 0);
1704 mem_ic = platform_get_resource(pdev, IORESOURCE_MEM, 1);
1705 if (!pdata || !mem_ipu || !mem_ic)
1706 return -EINVAL;
Later on, I get error 16, Device or resource busy on VIDIOC_S_FMT, apparently
because mx3_camera can't get its dma channel.
Any clue?
--
Agustin Ferrin Pozuelo
Embedded Systems Consultant
http://embedded.ferrin.org/
--- On 18/2/09, Guennadi Liakhovetski wrote:
From: Guennadi Liakhovetski l...@denx.de
General code clean-up: remove superfluous semicolons, update comments.
Robustness improvements: add DMA error handling to the ISR, move common code
fragments to functions, fix scatter-gather element queuing in the ISR, survive
channel freeing and re-allocation in a quick succession.
Signed-off-by: Guennadi Liakhovetski l...@denx.de
---
As mentioned in PATCH 0/4 this one is only for completeness / testing
here, will be submitted separately to the dmaengine queue. Dan, would be
good if you could review it here to save time.
drivers/dma/ipu/ipu_idmac.c | 300 ---
1 files changed, 196 insertions(+), 104 deletions(-)
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index 1f154d0..91e6e4e 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -28,6 +28,9 @@
#define FS_VF_IN_VALID 0x0002
#define FS_ENC_IN_VALID0x0001
+static int ipu_disable_channel(struct idmac *idmac, struct idmac_channel
*ichan,
+ bool wait_for_stop);
+
/*
* There can be only one, we could allocate it dynamically, but then we'd
have
* to add an extra parameter to some functions, and use something as ugly as
@@ -107,7 +110,7 @@ static uint32_t bytes_per_pixel(enum pixel_fmt fmt)
}
}
-/* Enable / disable direct write to memory by the Camera Sensor Interface */
+/* Enable direct write to memory by the Camera Sensor Interface */
static void ipu_ic_enable_task(struct ipu *ipu, enum ipu_channel channel)
{
uint32_t ic_conf, mask;
@@ -126,6 +129,7 @@ static void ipu_ic_enable_task(struct ipu *ipu, enum
ipu_channel channel)
idmac_write_icreg(ipu, ic_conf, IC_CONF);
}
+/* Called under spin_lock_irqsave(ipu_data.lock) */
static void ipu_ic_disable_task(struct ipu *ipu, enum ipu_channel channel)
{
uint32_t ic_conf, mask;
@@ -422,7 +426,7 @@ static void ipu_ch_param_set_size(union chan_param_mem
*params,
break;
default:
dev_err(ipu_data.dev,
- mxc ipu: unimplemented pixel format %d\n, pixel_fmt);
+ mx3 ipu: unimplemented pixel format %d\n, pixel_fmt);
break;
}
@@ -433,20 +437,20 @@ static void ipu_ch_param_set_burst_size(union
chan_param_mem *params,
uint16_t burst_pixels)
{
params-pp.npb = burst_pixels - 1;
-};
+}
static void ipu_ch_param_set_buffer(union chan_param_mem *params,
dma_addr_t buf0, dma_addr_t buf1)
{
params-pp.eba0 = buf0;
params-pp.eba1 = buf1;
-};
+}
static void ipu_ch_param_set_rotation(union chan_param_mem *params,
enum ipu_rotate_mode rotate)
{
params-pp.bam = rotate;
-};
+}
static void ipu_write_param_mem(uint32_t addr, uint32_t *data,
uint32_t num_words)
@@ -571,7 +575,7 @@ static uint32_t dma_param_addr(uint32_t dma_ch)
{
/* Channel Parameter Memory */
return 0x1 | (dma_ch 4);
-};
+}
static void ipu_channel_set_priority(struct ipu *ipu, enum ipu_channel
channel,
bool prio)
@@ -611,7 +615,8 @@ static uint32_t ipu_channel_conf_mask(enum ipu_channel
channel)
/**
* ipu_enable_channel() - enable an IPU channel.
- * @channel: channel ID.
+ * @idmac: IPU DMAC context.
+ * @ichan: IDMAC channel.
* @return:0 on success or negative error code on failure.
*/
static int ipu_enable_channel(struct idmac *idmac, struct idmac_channel
*ichan)
@@ -649,7 +654,7 @@ static int ipu_enable_channel(struct idmac *idmac, struct
idmac_channel *ichan)
/**
* ipu_init_channel_buffer() - initialize a buffer for logical IPU channel.
- * @channel: channel ID.
+ * @ichan: IDMAC channel.
* @pixel_fmt: pixel format of buffer. Pixel format is a FOURCC ASCII code.
* @width: width of buffer in pixels.
* @height:height of buffer in pixels.
@@ -687,7 +692,7 @@ static int ipu_init_channel_buffer(struct idmac_channel
*ichan,
}
/* IC channel's stride must be a multiple of 8 pixels
Re: [PATCH/RFC 1/4] ipu_idmac: code clean-up and robustness improvements
Guennadi, Guennadi Liakhovetski wrote: From: Guennadi Liakhovetski General code clean-up: remove superfluous semicolons, update comments. Robustness improvements: add DMA error handling to the ISR, move common code fragments to functions, fix scatter-gather element queuing in the ISR, survive channel freeing and re-allocation in a quick succession. Signed-off-by: Guennadi Liakhovetski --- As mentioned in PATCH 0/4 this one is only for completeness / testing here, will be submitted separately to the dmaengine queue. Dan, would be good if you could review it here to save time. drivers/dma/ipu/ipu_idmac.c | 300 --- 1 files changed, 196 insertions(+), 104 deletions(-) diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c index 1f154d0..91e6e4e 100644 --- a/drivers/dma/ipu/ipu_idmac.c +++ b/drivers/dma/ipu/ipu_idmac.c @@ -28,6 +28,9 @@ #define FS_VF_IN_VALID0x0002 #define FS_ENC_IN_VALID0x0001 +static int ipu_disable_channel(struct idmac *idmac, struct idmac_channel *ichan, + bool wait_for_stop); + /* ... Thanks a lot for the patchset! I am having some stoopid trouble while trying to apply this patch to 'mxc-master': $ patch -p1 --dry-run p1 patching file drivers/dma/ipu/ipu_idmac.c patch: malformed patch at line 29: /* Looks like your patches lost their format while on their way, specially every single line with a starting space has had it removed. Or is it my e-mail reader? I am trying to fix it manually, no luck. -- 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/RFC 1/4] ipu_idmac: code clean-up and robustness improvements
--- On 18/2/09, Russell King -wrote: On Wed, Feb 18, 2009 at 07:09:55AM -0800, Agustin wrote: $ patch -p1 --dry-run p1 patching file drivers/dma/ipu/ipu_idmac.c patch: malformed patch at line 29: /* Looks like your patches lost their format while on their way, specially every single line with a starting space has had it removed. Or is it my e-mail reader? I am trying to fix it manually, no luck. I think it's your mail reader - the version I have here is fine. What you could do is look up the message in the mailing list archive on lists.arm.linux.org.uk, and use the '(text/plain)' link to download an unmangled copy of it. Thanks, that worked fine. -- 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
