| Message ID | CACKLOr0=TccMNoQV-LfkeBrCN5=0E8eqTEaT7PRk-KAv_mQ5RQ@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 09/05/2012 11:11 AM, javier Martin wrote: > On 5 September 2012 10:47, Gaëtan Carlier <gcembed@gmail.com> wrote: >> On 09/05/2012 10:22 AM, javier Martin wrote: >>> >>> On 5 September 2012 09:37, Gaëtan Carlier <gcembed@gmail.com> wrote: >>>> >>>> Hi Javier, >>>> This is because I will send a patch to add support of eMMA-PP. eMMA-PrP >>>> is >>>> not only used for soc-camera. It can also be used as stand-alone driver >>>> and >>>> now to be able to use eMMA-PrP module, IMX_HAVE_PLATFORM_MX2_CAMERA must >>>> be >>>> set. >>> >>> >>> Do you mean the following stand-alone driver I submitted some time >>> ago? Are you working on some improvements to it? >>> >>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/media/video/mx2_emmaprp.c;h=5f8a6f5b98f91c3af4e1bdbd06654e7b496d8d65;hb=HEAD >> >> yes >> >>> >>> This driver can be used without applying your patch. Please take a >>> look at the following patch which is pending to get merged in >>> linux-media tree: >>> https://patchwork.kernel.org/patch/1347921/ >>> >>> >>>> And if I follow this logic, I have to put declaration of eMMA-PP with >>>> imx-fb >>>> and eMMA-PP can only be enabled if IMX_HAVE_PLATFORM_IMX_FB. >>>> Of course, eMMA-PrP is almost always used with soc-camera and eMMA-PP >>>> with >>>> LCDC (imx-fb) but eMMA can be used to do HW accelarated colorspace >>>> conversion. >>> >>> >>> Agree, there is already one driver supporting this feature. >>> >>>> It is not a problem for me to keep eMMA-PrP and mx2-camera together. It >>>> was >>>> just to have a more independant eMMA driver. >>> >>> >>> I won't oppose to it, for me it is just aesthetic. However, you must >>> do it properly without breaking existing boards such as Visstrim_M10. >> >> Ok, I missed your patch in mailing-list and I work with linux-next >> (20120824) so I didn't know that my patch would break yours. Sorry. >> >>> >>>> For the Visstrim_M10 board, I don't think that it is needed to set >>>> IMX_HAVE_PLATFORM_MX2_EMMA because there is no reference to m2m-emmaprp >>>> and >>>> mx2-camera embeds handling of eMMA-PrP without using eMMA-PrP driver. >>> >>> >>> The following patch was sent to the list in Agust the 20th and will be >>> merged in the linux-media tree. This patch does reference m2m-emmaprp >>> in Visstrim_M10 >>> https://patchwork.kernel.org/patch/1347921/ >>> >>> So, please, since you have to fix the wrong chunk and have to send a >>> v2 anyways I strongly encourage you to add the flag >>> IMX_HAVE_PLATFORM_MX2_EMMA to Visstrim_M10. This way nothing will be >>> broken no matter your patch gets merged after or before mine. >> >> What do you mean by "wrong chunk" ? > > > Your patch does not apply cleanly to linux-next due to the following chunk: > > diff --git a/arch/arm/mach-imx/devices-imx27.h > b/arch/arm/mach-imx/devices-imx27.h > index 0482293..d8eb4a0 100644 > --- a/arch/arm/mach-imx/devices-imx27.h > +++ b/arch/arm/mach-imx/devices-imx27.h > @@ -54,8 +54,10 @@ extern const struct imx_imx_uart_1irq_data > imx27_imx_uart_data[]; > extern const struct imx_mx2_camera_data imx27_mx2_camera_data; > #define imx27_add_mx2_camera(pdata) \ > imx_add_mx2_camera(&imx27_mx2_camera_data, pdata) > + > +extern const struct imx_mx2_emma_data imx27_mx2_emmaprp_data; > #define imx27_add_mx2_emmaprp() \ > - imx_add_mx2_emmaprp(&imx27_mx2_camera_data) > + imx_add_mx2_emmaprp(&imx27_mx2_emmaprp_data) > > When I apply the patch (I save my mail and apply it), there is no conflict/reject. Tested on linux-next-20120824 and linux-next-20120905. >>> >>>> It seems that eMMA-PrP embeded in mx2camera handles more case than >>>> stand-alone eMMA-PrP driver. Maybe eMMA-PrP driver needs some review to >>>> handle all In/Out image formats ? >>> >>> >>> eMMa-PrP is currently used in two drivers: >>> >>> 1. >>> http://git.linuxtv.org/media_tree.git/blob/refs/heads/staging/for_v3.7:/drivers/media/platform/soc_camera/mx2_camera.c >>> Where it is used as a substitute to a DMA that moves data between the >>> CSI and RAM apart from providing more features like format conversion, >>> etc... This is a soc_camera video capture driver. >>> >>> 2. >>> http://git.linuxtv.org/media_tree.git/blob/refs/heads/staging/for_v3.7:/drivers/media/platform/mx2_emmaprp.c >>> This is a stand-alone mem2mem v4l2 driver that can get YUYV 422 in the >>> input and transform it to YUV 420. Of course, the driver can be >>> extended to support more kinds of conversions. >>> >>> Regards. >>> >> Regards, >> Gaëtan. > > >
On 5 September 2012 11:35, Gaëtan Carlier <gcembed@gmail.com> wrote: > On 09/05/2012 11:11 AM, javier Martin wrote: >> >> On 5 September 2012 10:47, Gaëtan Carlier <gcembed@gmail.com> wrote: >>> >>> On 09/05/2012 10:22 AM, javier Martin wrote: >>>> >>>> >>>> On 5 September 2012 09:37, Gaëtan Carlier <gcembed@gmail.com> wrote: >>>>> >>>>> >>>>> Hi Javier, >>>>> This is because I will send a patch to add support of eMMA-PP. eMMA-PrP >>>>> is >>>>> not only used for soc-camera. It can also be used as stand-alone driver >>>>> and >>>>> now to be able to use eMMA-PrP module, IMX_HAVE_PLATFORM_MX2_CAMERA >>>>> must >>>>> be >>>>> set. >>>> >>>> >>>> >>>> Do you mean the following stand-alone driver I submitted some time >>>> ago? Are you working on some improvements to it? >>>> >>>> >>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/media/video/mx2_emmaprp.c;h=5f8a6f5b98f91c3af4e1bdbd06654e7b496d8d65;hb=HEAD >>> >>> >>> yes >>> >>>> >>>> This driver can be used without applying your patch. Please take a >>>> look at the following patch which is pending to get merged in >>>> linux-media tree: >>>> https://patchwork.kernel.org/patch/1347921/ >>>> >>>> >>>>> And if I follow this logic, I have to put declaration of eMMA-PP with >>>>> imx-fb >>>>> and eMMA-PP can only be enabled if IMX_HAVE_PLATFORM_IMX_FB. >>>>> Of course, eMMA-PrP is almost always used with soc-camera and eMMA-PP >>>>> with >>>>> LCDC (imx-fb) but eMMA can be used to do HW accelarated colorspace >>>>> conversion. >>>> >>>> >>>> >>>> Agree, there is already one driver supporting this feature. >>>> >>>>> It is not a problem for me to keep eMMA-PrP and mx2-camera together. It >>>>> was >>>>> just to have a more independant eMMA driver. >>>> >>>> >>>> >>>> I won't oppose to it, for me it is just aesthetic. However, you must >>>> do it properly without breaking existing boards such as Visstrim_M10. >>> >>> >>> Ok, I missed your patch in mailing-list and I work with linux-next >>> (20120824) so I didn't know that my patch would break yours. Sorry. >>> >>>> >>>>> For the Visstrim_M10 board, I don't think that it is needed to set >>>>> IMX_HAVE_PLATFORM_MX2_EMMA because there is no reference to m2m-emmaprp >>>>> and >>>>> mx2-camera embeds handling of eMMA-PrP without using eMMA-PrP driver. >>>> >>>> >>>> >>>> The following patch was sent to the list in Agust the 20th and will be >>>> merged in the linux-media tree. This patch does reference m2m-emmaprp >>>> in Visstrim_M10 >>>> https://patchwork.kernel.org/patch/1347921/ >>>> >>>> So, please, since you have to fix the wrong chunk and have to send a >>>> v2 anyways I strongly encourage you to add the flag >>>> IMX_HAVE_PLATFORM_MX2_EMMA to Visstrim_M10. This way nothing will be >>>> broken no matter your patch gets merged after or before mine. >>> >>> >>> What do you mean by "wrong chunk" ? >> >> >> >> Your patch does not apply cleanly to linux-next due to the following >> chunk: >> >> diff --git a/arch/arm/mach-imx/devices-imx27.h >> b/arch/arm/mach-imx/devices-imx27.h >> index 0482293..d8eb4a0 100644 >> --- a/arch/arm/mach-imx/devices-imx27.h >> +++ b/arch/arm/mach-imx/devices-imx27.h >> @@ -54,8 +54,10 @@ extern const struct imx_imx_uart_1irq_data >> imx27_imx_uart_data[]; >> extern const struct imx_mx2_camera_data imx27_mx2_camera_data; >> #define imx27_add_mx2_camera(pdata) \ >> imx_add_mx2_camera(&imx27_mx2_camera_data, pdata) >> + >> +extern const struct imx_mx2_emma_data imx27_mx2_emmaprp_data; >> #define imx27_add_mx2_emmaprp() \ >> - imx_add_mx2_emmaprp(&imx27_mx2_camera_data) >> + imx_add_mx2_emmaprp(&imx27_mx2_emmaprp_data) >> >> > When I apply the patch (I save my mail and apply it), there is no > conflict/reject. Tested on linux-next-20120824 and linux-next-20120905. Ok, this is my fault then, sorry. If you resend the patch adding the new flag to Visstrim_SM10 it's fine with me. Regards.
Javier/Gaëtan, On Wed, Sep 5, 2012 at 6:35 AM, Gaëtan Carlier <gcembed@gmail.com> wrote: > When I apply the patch (I save my mail and apply it), there is no > conflict/reject. Tested on linux-next-20120824 and linux-next-20120905. Can you please confirm whether you are able to run mx2_camera on linux-next-20120905? Tried it on my mx27pdk (and mx31pdk also) and the ov2640 is not detected. Regards, Fabio Estevam
On 09/05/2012 03:47 PM, Fabio Estevam wrote: > Javier/Gaëtan, > > On Wed, Sep 5, 2012 at 6:35 AM, Gaëtan Carlier <gcembed@gmail.com> wrote: > >> When I apply the patch (I save my mail and apply it), there is no >> conflict/reject. Tested on linux-next-20120824 and linux-next-20120905. > > Can you please confirm whether you are able to run mx2_camera on > linux-next-20120905? With or without my patch ? I have burnt out my ov2640 while previous experimentation so it is hard for me to test that and I have to write driver for MT9V111 to be able to test soc-camera on Kernel 3.x. > > Tried it on my mx27pdk (and mx31pdk also) and the ov2640 is not detected. > > Regards, > > Fabio Estevam > Regards, Gaëtan Carlier
On Wed, Sep 5, 2012 at 12:03 PM, Gaëtan Carlier <gcembed@gmail.com> wrote: > With or without my patch ? I have burnt out my ov2640 while previous Without your patch. Just running a clean linux-next-20120905. > experimentation so it is hard for me to test that and I have to write driver > for MT9V111 to be able to test soc-camera on Kernel 3.x. Write a driver? There is already one: drivers/media/i2c/mt9v011.c Regards, Fabio Estevam
On 09/05/2012 05:29 PM, Fabio Estevam wrote: > On Wed, Sep 5, 2012 at 12:03 PM, Gaëtan Carlier <gcembed@gmail.com> wrote: > >> With or without my patch ? I have burnt out my ov2640 while previous > > Without your patch. Just running a clean linux-next-20120905. I also notice a difference between previous release. Before, if CMOS was not scanned on I2C, soc-camera failed to init. With this release, soc-camera driver loads and create dev node even when nothing is connected on I2C bus. > >> experimentation so it is hard for me to test that and I have to write driver >> for MT9V111 to be able to test soc-camera on Kernel 3.x. > > Write a driver? There is already one: drivers/media/i2c/mt9v011.c MT9V011 is not compatible with MT9V111. MT9V111 uses two address spaces for register : Sensor Core registers and IFP registers. Another MT9* driver works with two address spaces but this is for a HD sensor and the function of registers is different. > > Regards, > > Fabio Estevam > Regards, Gaëtan Carlier.
On Wed, Sep 5, 2012 at 12:50 PM, Gaëtan Carlier <gcembed@gmail.com> wrote: > I also notice a difference between previous release. Before, if CMOS was not > scanned on I2C, soc-camera failed to init. > With this release, soc-camera driver loads and create dev node even when > nothing is connected on I2C bus. Sylwester suggested me this patch and it fixed the issue: http://git.linuxtv.org/snawrocki/media.git/commitdiff/458b9b5ab8cb970887c9d1f1fddf88399b2d9ef2 Now ov2640 probes correctly on mx31pdk, but on mx27pdk I have: soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0 mx2-camera mx2-camera.0: Camera driver attached to camera 0 ov2640 0-0030: Product ID error fb:fb mx2-camera mx2-camera.0: Camera driver detached from camera 0 mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency: 66500000 This works fine in 3.4.10 and I suspect this problem is due to the imx clock conversion as the csi clock frequency looks incorrect. Javier, Can you get your camera working on visstrim board using linux-next or 3.6-rc4? Any patches I am missing? Regards, Fabio Estevam
Hi, On 09/05/2012 08:20 PM, Fabio Estevam wrote: > On Wed, Sep 5, 2012 at 12:50 PM, Gaëtan Carlier <gcembed@gmail.com> wrote: > >> I also notice a difference between previous release. Before, if CMOS was not >> scanned on I2C, soc-camera failed to init. >> With this release, soc-camera driver loads and create dev node even when >> nothing is connected on I2C bus. > > Sylwester suggested me this patch and it fixed the issue: > http://git.linuxtv.org/snawrocki/media.git/commitdiff/458b9b5ab8cb970887c9d1f1fddf88399b2d9ef2 > > Now ov2640 probes correctly on mx31pdk, but on mx27pdk I have: > > soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0 > mx2-camera mx2-camera.0: Camera driver attached to camera 0 > ov2640 0-0030: Product ID error fb:fb > mx2-camera mx2-camera.0: Camera driver detached from camera 0 > mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock > frequency: 66500000 > I notice that before I damaged my ov2640 camera. > This works fine in 3.4.10 and I suspect this problem is due to the imx > clock conversion as the csi clock frequency looks incorrect. This is maybe related to the problem that I have already noticed here : http://mailman.alsa-project.org/pipermail/alsa-devel/2012-August/054594.html If MMC is disabled, Sound and coda (not sure anymore, I will check it tomorrow) don't work correctly. > > Javier, > > Can you get your camera working on visstrim board using linux-next or > 3.6-rc4? Any patches I am missing? > > Regards, > > Fabio Estevam > Regards, Gaëtan Carlier.
On Wed, Sep 5, 2012 at 3:51 PM, Gaëtan Carlier <gcembed@gmail.com> wrote: > This is maybe related to the problem that I have already noticed here : > http://mailman.alsa-project.org/pipermail/alsa-devel/2012-August/054594.html > If MMC is disabled, Sound and coda (not sure anymore, I will check it > tomorrow) don't work correctly. Yes, just reproduced the same here: deselected mmc driver and now audio does not work. We need to review the mx27 clock tree. Regards, Fabio Estevam
Hi Javier, On Wed, Sep 5, 2012 at 3:20 PM, Fabio Estevam <festevam@gmail.com> wrote: > Sylwester suggested me this patch and it fixed the issue: > http://git.linuxtv.org/snawrocki/media.git/commitdiff/458b9b5ab8cb970887c9d1f1fddf88399b2d9ef2 > > Now ov2640 probes correctly on mx31pdk, but on mx27pdk I have: > > soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0 > mx2-camera mx2-camera.0: Camera driver attached to camera 0 > ov2640 0-0030: Product ID error fb:fb > mx2-camera mx2-camera.0: Camera driver detached from camera 0 > mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock > frequency: 66500000 > > This works fine in 3.4.10 and I suspect this problem is due to the imx > clock conversion as the csi clock frequency looks incorrect. > > Javier, > > Can you get your camera working on visstrim board using linux-next or > 3.6-rc4? Any patches I am missing? Could you please confirm if your camera works with the latest kernel? If so, could you please your log below? Not sure if the clock frequency below is correct. > soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0 > mx2-camera mx2-camera.0: Camera driver attached to camera 0 > ov2640 0-0030: Product ID error fb:fb > mx2-camera mx2-camera.0: Camera driver detached from camera 0 > mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock > frequency: 66500000 Thanks, Fabio Estevam
Hi Fabio, On 4 October 2012 16:07, Fabio Estevam <festevam@gmail.com> wrote: > Hi Javier, > > On Wed, Sep 5, 2012 at 3:20 PM, Fabio Estevam <festevam@gmail.com> wrote: > >> Sylwester suggested me this patch and it fixed the issue: >> http://git.linuxtv.org/snawrocki/media.git/commitdiff/458b9b5ab8cb970887c9d1f1fddf88399b2d9ef2 >> >> Now ov2640 probes correctly on mx31pdk, but on mx27pdk I have: >> >> soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0 >> mx2-camera mx2-camera.0: Camera driver attached to camera 0 >> ov2640 0-0030: Product ID error fb:fb >> mx2-camera mx2-camera.0: Camera driver detached from camera 0 >> mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock >> frequency: 66500000 >> >> This works fine in 3.4.10 and I suspect this problem is due to the imx >> clock conversion as the csi clock frequency looks incorrect. >> >> Javier, >> > Could you please confirm if your camera works with the latest kernel? > > If so, could you please your log below? > > Not sure if the clock frequency below is correct. > >> soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0 >> mx2-camera mx2-camera.0: Camera driver attached to camera 0 >> ov2640 0-0030: Product ID error fb:fb >> mx2-camera mx2-camera.0: Camera driver detached from camera 0 >> mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock >> frequency: 66500000 > No, it isn't. Kernel 3.6 works properly in our Visstrim M10 board and the CSI clock frequency is the same as yours: soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0 mx2-camera mx2-camera.0: Camera driver attached to camera 0 ov7670 0-0021: chip found @ 0x42 (imx-i2c) mx2-camera mx2-camera.0: Invalid format code #1: 4098 mx2-camera mx2-camera.0: Invalid format code #1: 4098 mx2-camera mx2-camera.0: Camera driver detached from camera 0 mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency: 66500000
Hi Javier, On Fri, Oct 5, 2012 at 3:51 AM, javier Martin <javier.martin@vista-silicon.com> wrote: > No, it isn't. Kernel 3.6 works properly in our Visstrim M10 board and > the CSI clock frequency is the same as yours: I managed to fix it. Now the CSI clock is the same as in 3.4 kernel and ov2640 probes successfully. Just submitted the patches. Regards, Fabio Estevam
--- a/arch/arm/mach-imx/devices-imx27.h +++ b/arch/arm/mach-imx/devices-imx27.h @@ -54,8 +54,10 @@ extern const struct imx_imx_uart_1irq_data imx27_imx_uart_data[]; extern const struct imx_mx2_camera_data imx27_mx2_camera_data; #define imx27_add_mx2_camera(pdata) \ imx_add_mx2_camera(&imx27_mx2_camera_data, pdata) + +extern const struct imx_mx2_emma_data imx27_mx2_emmaprp_data; #define imx27_add_mx2_emmaprp() \ - imx_add_mx2_emmaprp(&imx27_mx2_camera_data) + imx_add_mx2_emmaprp(&imx27_mx2_emmaprp_data)