Re: [coda6] Error while decoding second h.264 chunk
Hi, Do you have time to take a look at this (with the PC values) ? On 09/30/2014 09:54 AM, Gaëtan Carlier wrote: Hi, The problem can also come from register address or bit offset because depending source used (GStreamer for 2.6.22 or new coda kernel driver 3.6 or datasheet), registers do not have same addresses or do not even exists ! On 09/30/2014 08:00 AM, Gaëtan Carlier wrote: Hi Philipp and Fabio, First of all, thanks a lot for your reply. On 09/29/2014 03:53 PM, Philipp Zabel wrote: Hi Gaëtan, Am Mittwoch, den 24.09.2014, 11:18 +0200 schrieb Gaëtan Carlier: Hello Dears, I am back with my Coda6 (i.MX27). I have ported decoding from libvpu code to kernel 3.6 but I have a little problem. DEC_SEQ_INIT runs fine, the internal RdPtr increases by 512 bytes but when I run the DEC_PIC_RUN (PRESCAN disabled), the RdPTr has increased to 1024 (0x400), but macroblock error are reported and next DEC_PIC_RUN does not increase anymore the internal RdPtr. If I enable PRESCAN, the first DEC_PIC_RUN does not event finish (timeout). where is the PC pointer at when it times out? Maybe do a complete register dump before DEC_PIC_RUN and after the timeout to see if something stands out. I will do that and post reply today (I really don't know what to do with Program Counter of the FW. I hope you do :)). Here is the dump reg when PRESCAN is enable (and leads to timeout): Chunk 0[6269] : key frame 67 (0001674218D4) Chunk 1[1154] : frame 41 (0001419AFFBF) Chunk 2[1293] : frame 41 (0001419A8110) Chunk 3[1256] : frame 41 (0001419A7590) Chunk 4[1887] : frame 41 (0001419A0989) Chunk 5[2609] : frame 41 (0001419A6E54) Chunk 6[2463] : frame 41 (0001419A0865) Chunk 7[2087] : frame 41 (0001419AB42D) Chunk 8[2394] : frame 41 (0001419AB52F) Chunk 9[2210] : frame 41 (0001419A2CC2) coda_fill_decoder_bitstreambuf - c8c7f000 - 6269 bytes added - 6269 bytes bufferd WrPtr @ a73c187d - RdPtr @ a73c 0001674218D4 coda coda-imx27.0: Int occurs : 0002 CODA_REG_DEC_FUNC_CTRL (0x0114): CODA_RET_DEC_SEQ_SRC_SIZE (0x01C4): 000A01E0 CODA_RET_DEC_SEQ_SRC_F_RATE (0x01C8): CODA_RET_DEC_SEQ_FRAME_NEED (0x01CC): 0003 CODA_RET_DEC_SEQ_FRAME_DELAY (0x01D0): CODA_RET_DEC_SEQ_INFO (0x01D4): CODA_RET_DEC_SEQ_CROP_LEFT_RIGHT (0x01D8): CODA_RET_DEC_SEQ_CROP_TOP_BOTTOM (0x01DC): CODA_RET_DEC_SEQ_NEXT_FRAME_NUM (0x01E0): 0001 CODA_REG_BIT_RUN_INDEX (0x0168): CODA_REG_BIT_RD_PTR0 (0x0120): A73C0200 CODA_REG_BIT_WR_PTR0 (0x0124): A73C187D Framebuffers allocated 10 coda coda-imx27.0: Int occurs : 0010 coda_device_run_decoder coda_fill_decoder_bitstreambuf - c8d8 - 1154 bytes added - 7423 bytes bufferd WrPtr @ a73c1cff - RdPtr @ a73c0200 0001419AFFBF CODA_REG_BIT_INT_STATUS (0x0010): CODA_REG_BIT_CUR_PC (0x0018): 0069 CODA_REG_BIT_CODE_BUF_ADDR (0x0100): A713 CODA_REG_BIT_WORK_BUF_ADDR (0x0104): A720 CODA_REG_BIT_PARA_BUF_ADDR (0x0108): A730 CODA_REG_BIT_STREAM_CTRL (0x010C): 0006 CODA_REG_BIT_FRAME_MEM_CTRL (0x0110): CODA_REG_DEC_FUNC_CTRL (0x0114): CODADX6_REG_BIT_SEARCH_RAM_BASE_ADDR (0x0140): 4C00 coda coda-imx27.0: CODA PIC_RUN timeout, stopping all streams CODA_RET_DEC_PIC_FRAME_NUM (0x01C0): 0001 size 460800 CODA_RET_DEC_PIC_IDX (0x01C4): 000A01E0 CODA_RET_DEC_PIC_ERR_MB_NUM (0x01C8): CODA_RET_DEC_PIC_TYPE (0x01CC): 0003 CODA_RET_DEC_PIC_SUCCESS (0x01D4): 0003 CODA_RET_DEC_PIC_OPTION (0x01D0): CODA_RET_DEC_PIC_CUR_IDX (0x01DC): CODA_RET_DEC_PIC_NEXT_IDX (0x01E0): 0001 CODA_REG_BIT_INT_STATUS (0x0010): CODA_REG_BIT_CUR_PC (0x0018): 0DC6 CODA_REG_BIT_CODE_BUF_ADDR (0x0100): A713 CODA_REG_BIT_WORK_BUF_ADDR (0x0104): A720 CODA_REG_BIT_PARA_BUF_ADDR (0x0108): A730 CODA_REG_BIT_STREAM_CTRL (0x010C): 0006 CODA_REG_BIT_FRAME_MEM_CTRL (0x0110): CODA_REG_DEC_FUNC_CTRL (0x0114): CODADX6_REG_BIT_SEARCH_RAM_BASE_ADDR (0x0140): 4C00 I attach the kernel driver (+fw), the h264 raw file (encoded using this coda6 driver and played without error using ffplay), the userspace test program and the log file. Can you give me some advise to know where to search. I have tried to reset WrPtr and RdPtr before first DEC_PIC_RUN and reload h264 raw file from the beginning, let RdPtr and WrPtr unchanged and h264 raw file from the beginning but this is even worst... I don't think you are supposed to write RdPtr. That is what I think too but I have tried many things before asking help :) It is under firmware control, at least between SEQ_INIT and SEQ_END. There is a DEC_BUF_FLUSH command, maybe that does what you need. I supposed that DEC_BUF_FLUSH command is needed after DEC_PIC_RUN command in case of last chunk or one frame decoding. As my problem occurs while this first DEC_PIC_RUN, I don't even try to implement
Re: [coda6] Error while decoding second h.264 chunk
Hi Philipp and Fabio, First of all, thanks a lot for your reply. On 09/29/2014 03:53 PM, Philipp Zabel wrote: Hi Gaëtan, Am Mittwoch, den 24.09.2014, 11:18 +0200 schrieb Gaëtan Carlier: Hello Dears, I am back with my Coda6 (i.MX27). I have ported decoding from libvpu code to kernel 3.6 but I have a little problem. DEC_SEQ_INIT runs fine, the internal RdPtr increases by 512 bytes but when I run the DEC_PIC_RUN (PRESCAN disabled), the RdPTr has increased to 1024 (0x400), but macroblock error are reported and next DEC_PIC_RUN does not increase anymore the internal RdPtr. If I enable PRESCAN, the first DEC_PIC_RUN does not event finish (timeout). where is the PC pointer at when it times out? Maybe do a complete register dump before DEC_PIC_RUN and after the timeout to see if something stands out. I will do that and post reply today (I really don't know what to do with Program Counter of the FW. I hope you do :)). I attach the kernel driver (+fw), the h264 raw file (encoded using this coda6 driver and played without error using ffplay), the userspace test program and the log file. Can you give me some advise to know where to search. I have tried to reset WrPtr and RdPtr before first DEC_PIC_RUN and reload h264 raw file from the beginning, let RdPtr and WrPtr unchanged and h264 raw file from the beginning but this is even worst... I don't think you are supposed to write RdPtr. That is what I think too but I have tried many things before asking help :) It is under firmware control, at least between SEQ_INIT and SEQ_END. There is a DEC_BUF_FLUSH command, maybe that does what you need. I supposed that DEC_BUF_FLUSH command is needed after DEC_PIC_RUN command in case of last chunk or one frame decoding. As my problem occurs while this first DEC_PIC_RUN, I don't even try to implement this command. What happens if you queue a third ~1200 byte frame before calling the first DEC_PIC_RUN? I already try to increase v4l2buffer from userspace and queue upto 10 h.264 chunk in bitstreambuffer but same behaviour. The firmware is version 2.2.5. Thanks a lot for your help. Best regards, Gaëtan Carlier. ps: I do not post this on mailing list due to attachments that may not work You could extract the relevant parts of the log. I send this reply on mailing list, as people will already see your advise and avoid duplication. Here is the log: ... coda coda-imx27.0: Initialized CodaDx6. coda coda-imx27.0: Firmware version: 2.2.5 coda coda-imx27.0: codec registered as /dev/video2 ... Chunk 0[6269] : key frame 67 (0001674218D4) Chunk 1[1154] : frame 41 (0001419AFFBF) Chunk 2[1293] : frame 41 (0001419A8110) Chunk 3[1256] : frame 41 (0001419A7590) Chunk 4[1887] : frame 41 (0001419A0989) Chunk 5[2609] : frame 41 (0001419A6E54) Chunk 6[2463] : frame 41 (0001419A0865) Chunk 7[2087] : frame 41 (0001419AB42D) Chunk 8[2394] : frame 41 (0001419AB52F) Chunk 9[2210] : frame 41 (0001419A2CC2) coda_fill_decoder_bitstreambuf - c8c7f000 - 6269 bytes added - 6269 bytes bufferd WrPtr @ a73c187d - RdPtr @ a73c 0001674218D4 coda coda-imx27.0: Int occurs : 0002 (SEQ_INIT) coda coda-imx27.0: CODA_REG_DEC_FUNC_CTRL : coda coda-imx27.0: CODA_RET_DEC_SEQ_SRC_SIZE : 000A01E0 coda coda-imx27.0: CODA_RET_DEC_SEQ_SRC_F_RATE : coda coda-imx27.0: CODA_RET_DEC_SEQ_FRAME_NEED : 0003 coda coda-imx27.0: CODA_RET_DEC_SEQ_FRAME_DELAY : coda coda-imx27.0: CODA_RET_DEC_SEQ_INFO : coda coda-imx27.0: CODA_RET_DEC_SEQ_CROP_LEFT_RIGHT : coda coda-imx27.0: CODA_RET_DEC_SEQ_CROP_TOP_BOTTOM : coda coda-imx27.0: CODA_RET_DEC_SEQ_NEXT_FRAME_NUM : 0001 coda coda-imx27.0: CODA_REG_BIT_RUN_INDEX : coda coda-imx27.0: CODA_REG_BIT_RD_PTR0 : A73C0200 coda coda-imx27.0: CODA_REG_BIT_WR_PTR0 : A73C187D Framebuffers allocated 10 coda coda-imx27.0: Int occurs : 0010 (SET_FRAME_BUF) coda_device_run_decoder coda_fill_decoder_bitstreambuf - c8d8 - 1154 bytes added - 7423 bytes bufferd WrPtr @ a73c1cff - RdPtr @ a73c0200 0001419AFFBF coda coda-imx27.0: Int occurs : 0008 (PIC_RUN) CODA_RET_DEC_PIC_FRAME_NUM : 0001 size 460800 CODA_RET_DEC_PIC_IDX : CODA_RET_DEC_PIC_ERR_MB_NUM : 0442 CODA_RET_DEC_PIC_TYPE : CODA_RET_DEC_PIC_SUCCESS : 0001 CODA_RET_DEC_PIC_OPTION : 0002 CODA_RET_DEC_PIC_CUR_IDX : 0001 CODA_RET_DEC_PIC_NEXT_IDX : 0001 coda_device_run_decoder coda_fill_decoder_bitstreambuf - c8e81000 - 1293 bytes added - 8716 bytes bufferd WrPtr @ a73c220c - RdPtr @ a73c0400 0001419A8110 Image 1 decoded : 0 Chunk 10[2841] : frame 41 (0001419A09A2) Chunk 11 loaded coda coda-imx27.0: Int occurs : 0008 CODA_RET_DEC_PIC_FRAME_NUM : 0002 size 460800 CODA_RET_DEC_PIC_IDX : 0001 CODA_RET_DEC_PIC_ERR_MB_NUM : 00EA CODA_RET_DEC_PIC_TYPE : 0001
Re: [coda6] Error while decoding second h.264 chunk
Hi, The problem can also come from register address or bit offset because depending source used (GStreamer for 2.6.22 or new coda kernel driver 3.6 or datasheet), registers do not have same addresses or do not even exists ! On 09/30/2014 08:00 AM, Gaëtan Carlier wrote: Hi Philipp and Fabio, First of all, thanks a lot for your reply. On 09/29/2014 03:53 PM, Philipp Zabel wrote: Hi Gaëtan, Am Mittwoch, den 24.09.2014, 11:18 +0200 schrieb Gaëtan Carlier: Hello Dears, I am back with my Coda6 (i.MX27). I have ported decoding from libvpu code to kernel 3.6 but I have a little problem. DEC_SEQ_INIT runs fine, the internal RdPtr increases by 512 bytes but when I run the DEC_PIC_RUN (PRESCAN disabled), the RdPTr has increased to 1024 (0x400), but macroblock error are reported and next DEC_PIC_RUN does not increase anymore the internal RdPtr. If I enable PRESCAN, the first DEC_PIC_RUN does not event finish (timeout). where is the PC pointer at when it times out? Maybe do a complete register dump before DEC_PIC_RUN and after the timeout to see if something stands out. I will do that and post reply today (I really don't know what to do with Program Counter of the FW. I hope you do :)). Here is the dump reg when PRESCAN is enable (and leads to timeout): Chunk 0[6269] : key frame 67 (0001674218D4) Chunk 1[1154] : frame 41 (0001419AFFBF) Chunk 2[1293] : frame 41 (0001419A8110) Chunk 3[1256] : frame 41 (0001419A7590) Chunk 4[1887] : frame 41 (0001419A0989) Chunk 5[2609] : frame 41 (0001419A6E54) Chunk 6[2463] : frame 41 (0001419A0865) Chunk 7[2087] : frame 41 (0001419AB42D) Chunk 8[2394] : frame 41 (0001419AB52F) Chunk 9[2210] : frame 41 (0001419A2CC2) coda_fill_decoder_bitstreambuf - c8c7f000 - 6269 bytes added - 6269 bytes bufferd WrPtr @ a73c187d - RdPtr @ a73c 0001674218D4 coda coda-imx27.0: Int occurs : 0002 CODA_REG_DEC_FUNC_CTRL (0x0114): CODA_RET_DEC_SEQ_SRC_SIZE (0x01C4): 000A01E0 CODA_RET_DEC_SEQ_SRC_F_RATE (0x01C8): CODA_RET_DEC_SEQ_FRAME_NEED (0x01CC): 0003 CODA_RET_DEC_SEQ_FRAME_DELAY (0x01D0): CODA_RET_DEC_SEQ_INFO (0x01D4): CODA_RET_DEC_SEQ_CROP_LEFT_RIGHT (0x01D8): CODA_RET_DEC_SEQ_CROP_TOP_BOTTOM (0x01DC): CODA_RET_DEC_SEQ_NEXT_FRAME_NUM (0x01E0): 0001 CODA_REG_BIT_RUN_INDEX (0x0168): CODA_REG_BIT_RD_PTR0 (0x0120): A73C0200 CODA_REG_BIT_WR_PTR0 (0x0124): A73C187D Framebuffers allocated 10 coda coda-imx27.0: Int occurs : 0010 coda_device_run_decoder coda_fill_decoder_bitstreambuf - c8d8 - 1154 bytes added - 7423 bytes bufferd WrPtr @ a73c1cff - RdPtr @ a73c0200 0001419AFFBF CODA_REG_BIT_INT_STATUS (0x0010): CODA_REG_BIT_CUR_PC (0x0018): 0069 CODA_REG_BIT_CODE_BUF_ADDR (0x0100): A713 CODA_REG_BIT_WORK_BUF_ADDR (0x0104): A720 CODA_REG_BIT_PARA_BUF_ADDR (0x0108): A730 CODA_REG_BIT_STREAM_CTRL (0x010C): 0006 CODA_REG_BIT_FRAME_MEM_CTRL (0x0110): CODA_REG_DEC_FUNC_CTRL (0x0114): CODADX6_REG_BIT_SEARCH_RAM_BASE_ADDR (0x0140): 4C00 coda coda-imx27.0: CODA PIC_RUN timeout, stopping all streams CODA_RET_DEC_PIC_FRAME_NUM (0x01C0): 0001 size 460800 CODA_RET_DEC_PIC_IDX (0x01C4): 000A01E0 CODA_RET_DEC_PIC_ERR_MB_NUM (0x01C8): CODA_RET_DEC_PIC_TYPE (0x01CC): 0003 CODA_RET_DEC_PIC_SUCCESS (0x01D4): 0003 CODA_RET_DEC_PIC_OPTION (0x01D0): CODA_RET_DEC_PIC_CUR_IDX (0x01DC): CODA_RET_DEC_PIC_NEXT_IDX (0x01E0): 0001 CODA_REG_BIT_INT_STATUS (0x0010): CODA_REG_BIT_CUR_PC (0x0018): 0DC6 CODA_REG_BIT_CODE_BUF_ADDR (0x0100): A713 CODA_REG_BIT_WORK_BUF_ADDR (0x0104): A720 CODA_REG_BIT_PARA_BUF_ADDR (0x0108): A730 CODA_REG_BIT_STREAM_CTRL (0x010C): 0006 CODA_REG_BIT_FRAME_MEM_CTRL (0x0110): CODA_REG_DEC_FUNC_CTRL (0x0114): CODADX6_REG_BIT_SEARCH_RAM_BASE_ADDR (0x0140): 4C00 I attach the kernel driver (+fw), the h264 raw file (encoded using this coda6 driver and played without error using ffplay), the userspace test program and the log file. Can you give me some advise to know where to search. I have tried to reset WrPtr and RdPtr before first DEC_PIC_RUN and reload h264 raw file from the beginning, let RdPtr and WrPtr unchanged and h264 raw file from the beginning but this is even worst... I don't think you are supposed to write RdPtr. That is what I think too but I have tried many things before asking help :) It is under firmware control, at least between SEQ_INIT and SEQ_END. There is a DEC_BUF_FLUSH command, maybe that does what you need. I supposed that DEC_BUF_FLUSH command is needed after DEC_PIC_RUN command in case of last chunk or one frame decoding. As my problem occurs while this first DEC_PIC_RUN, I don't even try to implement this command. What happens if you queue a third ~1200 byte frame before calling the first DEC_PIC_RUN
Re: [CODA] Info about internal buffers in CodaDX6
Hello, No one can give me more information about these registers ? Thank you. Bets regards, Gaëtan Carlier. On 06/03/2014 10:32 AM, Gaëtan Carlier wrote: Dear, I am back to add support of h.264 decoding using Coda DX6 on i.MX27 (after long months of inactivity). I base my work on driver from linux 2.6.22 (libvpu) and last coda.c from linux-next/master. When I send DEC_SEQ_INIT command, it fails but I don't know why. 1) Which internal buffers do Coda DX6 really have/used for decoding PARABUF, WORKBUF, PSBUF, ...) ? 2) What is their role ? 3) I see in some code that there is a command CODA_RET_DEC_SEQ_ERR_REASON (0x1E0), which has the same opcode has RET_DEC_SEQ_NEXT_FRAME_NUM, but when I run this command after DEC_SEQ_INIT, it returns 1 that does not seems to be correct error (regarding RetCode enum in vpu_lib.h in libvpu) Code is based on 3.6.0 kernel revision with some backport from more recent version of coda.c Thanks a lot for your help. Best regards, Gaëtan Carlier. -- 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: coda: support of decoding
Hi On 02/19/2013 07:47 PM, Robert Schwebel wrote: On Tue, Feb 19, 2013 at 02:47:05AM +0100, Gaëtan Carlier wrote: I see in code source of coda driver that decoding is not supported. ctx-inst_type = CODA_INST_DECODER; v4l2_err(v4l2_dev, decoding not supported.\n); return -EINVAL; Is there any technical reason or the code has not been written ? We have a lot of encoder + decoder patches for Coda in the queue, but unfortunately not all of that is ready-for-primetime yet. MX27. I have not yet tested if encoding is working or not. Where can I find this set of patches ? I will test it with pleasure. Which processor are you interested in? MX27 or MX5/MX6? rsc Thank you. Best regards, Gaëtan Carlier. -- 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: coda: support of decoding
On 02/19/2013 10:30 PM, Robert Schwebel wrote: On Tue, Feb 19, 2013 at 08:57:50PM +0100, Gaëtan Carlier wrote: We have a lot of encoder + decoder patches for Coda in the queue, but unfortunately not all of that is ready-for-primetime yet. MX27. I have not yet tested if encoding is working or not. Where can I find this set of patches? I will test it with pleasure. Most of the work is on MX53 and MX6 recently. We will post the patches here when something is ready. OK thanks a lot. rsc Gaëtan Carlier. -- 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 v2 2/2] [media]: mx2_camera: Fix regression caused by clock conversion
); + clk_disable_unprepare(pcdev-clk_csi_ahb); + dev_info(pdev-dev, MX2 Camera driver unloaded\n); return 0; I only test detection at kernel boot not streaming using Gstreamer due to lack of time. On imx27_3ds board with ov2640 sensor: ov2640 0-0030: ov2640 Product ID 26:42 Manufacturer ID 7f:a2 mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency: 4433 On clone imx27_3ds board with mt9v111 sensor (draft driver): mt9v111 0-0048: Detected a MT9V111 chip ID 823a mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency: 4433 Tested-by: Gaëtan Carlier gcem...@gmail.com -- 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 1/2] ARM: clk-imx27: Add missing clock for mx2-camera
Hi, On 10/05/2012 11:53 PM, Fabio Estevam wrote: During the clock conversion for mx27 the per4_gate clock was missed to get registered as a dependency of mx2-camera driver. In the old mx27 clock driver we used to have: DEFINE_CLOCK1(csi_clk, 0, NULL, 0, parent, csi_clk1, per4_clk); ,so does the same in the new clock driver. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- arch/arm/mach-imx/clk-imx27.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c index 3b6b640..5ef0f08 100644 --- a/arch/arm/mach-imx/clk-imx27.c +++ b/arch/arm/mach-imx/clk-imx27.c @@ -224,6 +224,7 @@ int __init mx27_clocks_init(unsigned long fref) clk_register_clkdev(clk[lcdc_ipg_gate], ipg, imx-fb.0); clk_register_clkdev(clk[lcdc_ahb_gate], ahb, imx-fb.0); clk_register_clkdev(clk[csi_ahb_gate], ahb, mx2-camera.0); + clk_register_clkdev(clk[per4_gate], per, mx2-camera.0); clk_register_clkdev(clk[usb_div], per, fsl-usb2-udc); clk_register_clkdev(clk[usb_ipg_gate], ipg, fsl-usb2-udc); clk_register_clkdev(clk[usb_ahb_gate], ahb, fsl-usb2-udc); I only test detection at kernel boot not streaming using Gstreamer due to lack of time. On imx27_3ds board with ov2640 sensor: ov2640 0-0030: ov2640 Product ID 26:42 Manufacturer ID 7f:a2 mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency: 4433 On clone imx27_3ds board with mt9v111 sensor (draft driver): mt9v111 0-0048: Detected a MT9V111 chip ID 823a mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency: 4433 Tested-by: Gaëtan Carlier gcem...@gmail.com -- 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 2/2] [media]: mx2_camera: Fix regression caused by clock conversion
()) This patch does not apply on linux-next-20121008. I suppose that linux-media development branch is needed. How can I put linux-media branch on top of linux-next using git ? Is the linux-media branch is always compatible with linux-next ? Thanks a lot, Gaëtan Carlier. -- 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
