public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Robert Jarzmik <robert.jarzmik@free.fr>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: video4linux-list@redhat.com
Subject: Re: [PATCH 5/5] pxa-camera: framework to handle camera-native and synthesized formats
Date: Tue, 11 Nov 2008 13:02:12 +0100	[thread overview]
Message-ID: <87y6zqpj23.fsf@free.fr> (raw)
In-Reply-To: <Pine.LNX.4.64.0811111220130.4565@axis700.grange> (Guennadi Liakhovetski's message of "Tue\, 11 Nov 2008 12\:31\:46 +0100 \(CET\)")

Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:

> Don't you think we can have a default case? If the format requested by the 
> user is provided by the camera and we "can trandfer it 1-to-1" (bus-width 
> == depth or some such) then just switch on the pass-through mode?
Yes, we should, you're perfectly right.
>
> Wow, I'm scared...:-) Ok, let's try it your way, I don't want to play the 
> "maintainer" card, and you seem to be strongly in favour of a central 
> solution, whereas I just slightly incline towards local... So, either give 
> me a few days, or feel free to code off - whichever you prefer.

Well, since I bring the burden, I'll bring in the solution too, that's fair.

What I can do is make the translation in pxa_camera, but generic enough so that
it's transplantation to soc_camera is only a matter of copy/paste (with a bit of
renaming).
That way, we'll have :
 - the local model holding : no centralization in soc_camera
 - if you see a wave of incoming host cameras copy pasting that bit of code,
 transplant that to soc_camera.
 - tradeoff between your model and my model.

Do you like that approach ? If you prefer the soc_camera one (translation code
in soc_camera), I'll put it in there, just tell me.

> If you do this, I think, best do something like
>
> int soc_camera_host_register(struct soc_camera_host *ici)
> {
> ...
> 	if (!ici->ops->enum_fmt)
> 		ici->ops->enum_fmt = soc_camera_enum_fmt;
> ...
>
> etc. for any other methods you want to provide defaults for. Instead of 
> exporting more functions and letting hosts do
>
> int x_do_something(...)
> {
> 	return soc_camera_do_something(...);
> }
Yep. Sounds less poluting to kernel namespace.

OK, now I'm on the coding path, let's see what futur brings :)

Cheers.

--
Robert

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

  reply	other threads:[~2008-11-11 12:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-10 12:36 [PATCH 0/5] pixel format handling in camera host drivers - part 2 Guennadi Liakhovetski
2008-11-10 12:36 ` [PATCH 1/5] soc-camera: simplify naming Guennadi Liakhovetski
2008-11-10 12:36 ` [PATCH 2/5] soc-camera: move pixel format handling to host drivers (part 2) Guennadi Liakhovetski
2008-11-10 12:36 ` [PATCH 4/5] soc-camera: initialise fields on device-registration, more formatting cleanup Guennadi Liakhovetski
2008-11-10 12:37 ` [PATCH 5/5] pxa-camera: framework to handle camera-native and synthesized formats Guennadi Liakhovetski
2008-11-10 18:09   ` David Ellingsworth
2008-11-10 18:43     ` Guennadi Liakhovetski
2008-11-10 19:15       ` Robert Jarzmik
2008-11-10 20:22         ` Guennadi Liakhovetski
2008-11-10 23:11   ` Robert Jarzmik
2008-11-11  8:18     ` Guennadi Liakhovetski
2008-11-11 11:04       ` Robert Jarzmik
2008-11-11 11:31         ` Guennadi Liakhovetski
2008-11-11 12:02           ` Robert Jarzmik [this message]
2008-11-11 12:14             ` Guennadi Liakhovetski
2008-11-10 19:39 ` [PATCH 0/5] pixel format handling in camera host drivers - part 2 Robert Jarzmik
2008-11-10 20:33   ` Guennadi Liakhovetski
     [not found] ` <Pine.LNX.4.64.0811101333030.4248@axis700.grange>
2008-11-11 22:36   ` Moderators: please act (was Re: [PATCH 3/5] soc-camera: add a per-camera...) Guennadi Liakhovetski

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=87y6zqpj23.fsf@free.fr \
    --to=robert.jarzmik@free.fr \
    --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