linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: grinberg@compulab.co.il (Igor Grinberg)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3] arm: omap3evm: Add support for an MT9M032 based camera board.
Date: Thu, 15 Dec 2011 12:18:07 +0200	[thread overview]
Message-ID: <4EE9C95F.2090308@compulab.co.il> (raw)
In-Reply-To: <1323886442.815408.21905@localhost>

On 12/14/11 20:14, martin at neutronstar.dyndns.org wrote:
> On Wed, Dec 14, 2011 at 11:31:35AM +0200, Igor Grinberg wrote:
>> Hi Martin,
>>
>> On 12/14/11 03:25, Martin Hostettler wrote:
>>> Adds board support for an MT9M032 based camera to omap3evm.
>>>
>>> Signed-off-by: Martin Hostettler <martin@neutronstar.dyndns.org>
>>> ---
>>>  arch/arm/mach-omap2/Makefile                |    3 +-
>>>  arch/arm/mach-omap2/board-omap3evm-camera.c |  155 +++++++++++++++++++++++++++
>>>  arch/arm/mach-omap2/board-omap3evm.c        |    4 +
>>>  3 files changed, 161 insertions(+), 1 deletions(-)
>>>  create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
>>>
>>> Changes in V3
>>>  * Added missing copyright and attribution.
>>>  * switched to gpio_request_array for gpio init.
>>>  * removed device_initcall and added call to omap3_evm_camera_init into omap3_evm_init
>>>
>>> Changes in V2:
>>>  * ported to current mainline
>>>  * Style fixes
>>>  * Fix error handling
>>>

[...]

>>> +/**
>>> + * omap3evm_set_mux - Sets mux to enable signal routing to
>>> + *                           different peripherals present on new EVM board
>>> + * @mux_id: enum, mux id to enable
>>> + *
>>> + * Returns 0 for success or a negative error code
>>> + */
>>> +static int omap3evm_set_mux(enum omap3evmdc_mux mux_id)
>>> +{
>>> +	/* Set GPIO6 = 1 */
>>> +	gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 6, 1);
>>> +	gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
>>> +
>>> +	switch (mux_id) {
>>> +	case MUX_TVP5146:
>>> +		gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
>>> +		gpio_set_value(nCAM_VD_SEL, 1);
>>> +		break;
>>> +
>>> +	case MUX_CAMERA_SENSOR:
>>> +		gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
>>> +		gpio_set_value(nCAM_VD_SEL, 0);
>>> +		break;
>>> +
>>> +	case MUX_EXP_CAMERA_SENSOR:
>>> +		gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 1);
>>> +		break;
>>> +
>>> +	default:
>>> +		pr_err("omap3evm-camera: Invalid mux id #%d\n", mux_id);
>>> +		return -EINVAL;
>>> +	}
>>> +
>>> +	return 0;
>>> +}
>>
>> I don't really care about that, but I don't see any mux
>> being set in the above function so the name and comments
>> are misleading.
> 
> There's are video muxes on this board that's controlled by various
> gpios. It's not a mux in the omap chip if you've expected to see that.
> 
> As this is an evaluation board it has a bunch of video connectors that 
> the user can choose from for different input devices.

I see... Probably a comment explaining that would not hurt here.

[...]

>>> +
>>> +	omap_mux_init_gpio(nCAM_VD_SEL, OMAP_PIN_OUTPUT);
>>> +	ret = gpio_request_array(setup_gpios, ARRAY_SIZE(setup_gpios));
>>> +	if (ret < 0) {
>>> +		pr_err("omap3evm-camera: Failed to setup camera signal routing.\n");
>>> +		return ret;
>>> +	}
>>
>> It looks like both above calls (gpio_request and mux_init)
>> can be moved to omap3evm_set_mux() function (or a renamed version of it),
>> so all the GPIO stuff will be close to each other instead of requesting
>> in one place and playing with values in another...
> 
> I'd like to keep the one time setup and the theoretically run time switchable
> parts seperate. It doesn't complicate the code and if a brave soul wants to
> connect different camera modules and switch between them it's a more reviewable
> patch from here.

Ok

> 
>>
>>> +	omap3evm_set_mux(MUX_CAMERA_SENSOR);
>>
>> So the plan is to add support for the 3 types,
>> but hard code to only one?
>> Can't this be runtime detected somehow?
> 
> The mux code came from out of tree drivers. I did want to keep enough
> information so someone extending this board code for other setups doesn't have a
> hard time. I can't think of an reliable way to runtime detect what video source
> a specific use case would want. Ideally someone who needs one of the other
> video sources should add a more generic solution here. 

I'm Ok with it, but usually, stuff that is never used stays out...
I think the way it should be is to have a platform driver that uses
a callback to switch between the "muxes" on the extension.

[...]

-- 
Regards,
Igor.

      reply	other threads:[~2011-12-15 10:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-14  1:25 [PATCH v3] arm: omap3evm: Add support for an MT9M032 based camera board Martin Hostettler
2011-12-14  9:31 ` Igor Grinberg
2011-12-14 13:15   ` Laurent Pinchart
2011-12-14 18:22     ` martin at neutronstar.dyndns.org
2011-12-15 12:02       ` Laurent Pinchart
2011-12-14 18:14   ` martin at neutronstar.dyndns.org
2011-12-15 10:18     ` Igor Grinberg [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EE9C95F.2090308@compulab.co.il \
    --to=grinberg@compulab.co.il \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).