[PATCH] ARM : i.MX27 : split code for allocation of ressources of camera and eMMA
gcembed at gmail.com
Wed Sep 5 05:35:42 EDT 2012
On 09/05/2012 11:11 AM, javier Martin wrote:
> On 5 September 2012 10:47, Gaëtan Carlier <gcembed at gmail.com> wrote:
>> On 09/05/2012 10:22 AM, javier Martin wrote:
>>> On 5 September 2012 09:37, Gaëtan Carlier <gcembed at gmail.com> wrote:
>>>> Hi Javier,
>>>> This is because I will send a patch to add support of eMMA-PP. eMMA-PrP
>>>> not only used for soc-camera. It can also be used as stand-alone driver
>>>> now to be able to use eMMA-PrP module, IMX_HAVE_PLATFORM_MX2_CAMERA must
>>> Do you mean the following stand-alone driver I submitted some time
>>> ago? Are you working on some improvements to it?
>>> 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:
>>>> And if I follow this logic, I have to put declaration of eMMA-PP with
>>>> 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
>>>> LCDC (imx-fb) but eMMA can be used to do HW accelarated colorspace
>>> 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
>>>> 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
>>>> 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
>>> 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
> 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
> 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:
>>> 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.
>>> 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.
More information about the linux-arm-kernel