From: Sascha Hauer <s.hauer@pengutronix.de>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: video4linux-list@redhat.com
Subject: Re: PATCH: soc-camera: use flag for colour / bw camera instead of module parameter
Date: Wed, 16 Jul 2008 07:49:22 +0200 [thread overview]
Message-ID: <20080716054922.GI6739@pengutronix.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0807152224040.6361@axis700.grange>
On Tue, Jul 15, 2008 at 10:43:53PM +0200, Guennadi Liakhovetski wrote:
> On Tue, 15 Jul 2008, Sascha Hauer wrote:
>
> > Use a flag in struct soc_camera_link for differentiation between
> > a black/white and a colour camera rather than a module parameter.
> > This allows for having colour and black/white cameras in the same
> > system.
> > Note that this one breaks the phytec pcm027 pxa board as it makes it
> > impossible to switch between cameras on the command line. I will send
> > an updated version of this patch once I know this patch is acceptable
> > this way.
>
> Yes, we did discuss this on IRC and I did agree to use a platform-provided
> parameter to specify camera properties like colour / monochrome, but now
> as I see it, I think, it might not be a very good idea. Having it as a
> parameter you can just reload the driver with a different parameter to
> test your colour camera in b/w mode. With this change you would need a new
> kernel.
I think it's a more common case to specify the correct camera on a
per-board basis than to test a colour camera in b/w mode. Only
developers want to do this and they know how to start a new kernel,
right? ;)
Another thing that came to my mind is that this particular camera has an
internal PLL for pixel clock generation. It can use the pxa pixel clock
directly or the one from the PLL. At the moment there is no way to
specify which clock to use, so we might even want to add a pointer to a
camera specific struct to soc_camera_link. This would be the right place
to put colour/bw flags aswell.
> What about an array of module parameters? Specifying flags on the
> command line is too weird, so, maybe colo(u)r=0,2 where numbers are
> camera-IDs? Or even 0:0 with bus-IDs. Yes, you would have to add optional
> camera-ID to the link struct.
I don't like module parameters for specifying my hardware. It
reminds me of the ISA days where you had to specify iobase/irq this way.
Sascha
--
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
next prev parent reply other threads:[~2008-07-16 5:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-15 13:56 PATCH: soc-camera: use flag for colour / bw camera instead of module parameter Sascha Hauer
2008-07-15 14:01 ` Sascha Hauer
2008-07-15 14:24 ` Paulius Zaleckas
2008-07-15 20:43 ` Guennadi Liakhovetski
2008-07-16 5:49 ` Sascha Hauer [this message]
2008-07-16 6:43 ` Sascha Hauer
2008-07-16 7:19 ` Guennadi Liakhovetski
2008-07-16 7:32 ` Robert Schwebel
2008-07-16 9:12 ` Sascha Hauer
[not found] ` <Pine.LNX.4.64.0807161117120.12100@axis700.grange>
[not found] ` <20080716104506.GO6739@pengutronix.de>
2008-07-16 11:16 ` Guennadi Liakhovetski
2008-07-16 12:32 ` Sascha Hauer
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=20080716054922.GI6739@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=g.liakhovetski@gmx.de \
--cc=video4linux-list@redhat.com \
/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