diff mbox

ARM : i.MX27 : split code for allocation of ressources of camera and eMMA

Message ID CACKLOr0=TccMNoQV-LfkeBrCN5=0E8eqTEaT7PRk-KAv_mQ5RQ@mail.gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Javier Martin Sept. 5, 2012, 9:11 a.m. UTC
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
>>
>>> 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.

Comments

gcembed Sept. 5, 2012, 9:35 a.m. UTC | #1
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.
>
>
>
Javier Martin Sept. 5, 2012, 9:51 a.m. UTC | #2
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.
Fabio Estevam Sept. 5, 2012, 1:47 p.m. UTC | #3
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
gcembed Sept. 5, 2012, 3:03 p.m. UTC | #4
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
Fabio Estevam Sept. 5, 2012, 3:29 p.m. UTC | #5
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
gcembed Sept. 5, 2012, 3:50 p.m. UTC | #6
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.
Fabio Estevam Sept. 5, 2012, 6:20 p.m. UTC | #7
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
gcembed Sept. 5, 2012, 6:51 p.m. UTC | #8
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.
Fabio Estevam Sept. 5, 2012, 7:07 p.m. UTC | #9
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
Fabio Estevam Oct. 4, 2012, 2:07 p.m. UTC | #10
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
Javier Martin Oct. 5, 2012, 6:51 a.m. UTC | #11
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
Fabio Estevam Oct. 5, 2012, 9:55 p.m. UTC | #12
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
diff mbox

Patch

--- 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)