All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Jarzmik <robert.jarzmik@free.fr>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Michael Grzeschik <m.grzeschik@pengutronix.de>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	p.wiesner@phytec.de
Subject: Re: [PATCH 02/20] mt9m111: init chip after read CHIP_VERSION
Date: Sat, 31 Jul 2010 22:36:52 +0200	[thread overview]
Message-ID: <874off1j8b.fsf@free.fr> (raw)
In-Reply-To: <Pine.LNX.4.64.1007312157200.16769@axis700.grange> (Guennadi Liakhovetski's message of "Sat\, 31 Jul 2010 22\:09\:48 +0200 \(CEST\)")

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

> On Fri, 30 Jul 2010, Michael Grzeschik wrote:
>
>> Moved mt9m111_init after the chip version detection passage: I
>> don't like the idea of writing on a device we haven't identified
>> yet.
>
> In principle it's correct, but what do you do, if a chip cannot be probed, 
> before it is initialised / enabled? Actually, this shouldn't be the case, 
> devices should be available for probing without any initialisation. So, we 
> have to ask the original author, whether this really was necessary, 
> Robert?

Michael is right I think.
According to the specification, even before the reset, the control registers can
be read, and they'll return their current values, which can be weird before
reset, excepting the CHIP_VERSION which is hard coded.

Therefore I think Michael is right by reading chip version before doing the
reset, and I ack this patch.

Cheers.

-- 
Robert

  reply	other threads:[~2010-07-31 20:37 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-30 14:53 [PATCH 00/20] MT9M111/MT9M131 Michael Grzeschik
2010-07-30 14:53 ` [PATCH 01/20] mt9m111: Added indication that MT9M131 is supported by this driver Michael Grzeschik
2010-07-31 19:49   ` Guennadi Liakhovetski
2010-07-31 20:10   ` Robert Jarzmik
2010-07-31 20:16     ` Guennadi Liakhovetski
2010-07-31 20:28       ` Robert Jarzmik
2010-07-30 14:53 ` [PATCH 02/20] mt9m111: init chip after read CHIP_VERSION Michael Grzeschik
2010-07-31 20:09   ` Guennadi Liakhovetski
2010-07-31 20:36     ` Robert Jarzmik [this message]
2010-07-30 14:53 ` [PATCH 03/20] mt9m111: register cleanup hex to dec bitoffset Michael Grzeschik
2010-07-31 20:40   ` Robert Jarzmik
2010-07-30 14:53 ` [PATCH 04/20] mt9m111: added new bit offset defines Michael Grzeschik
2010-07-31 20:44   ` Robert Jarzmik
2010-07-30 14:53 ` [PATCH 05/20] mt9m111: added default row/col/width/height values Michael Grzeschik
2010-07-31 20:25   ` Guennadi Liakhovetski
2010-07-30 14:53 ` [PATCH 06/20] mt9m111: changed MAX_{HEIGHT,WIDTH} values to silicon pixelcount Michael Grzeschik
2010-07-31 20:51   ` Robert Jarzmik
2010-07-30 14:53 ` [PATCH 07/20] mt9m111: changed MIN_DARK_COLS to MT9M131 spec count Michael Grzeschik
2010-07-30 14:53 ` [PATCH 08/20] mt9m111: cropcap use defined default rect properties in defrect Michael Grzeschik
2010-07-30 14:53 ` [PATCH 09/20] mt9m111: cropcap check if type is CAPTURE Michael Grzeschik
2010-07-30 14:53 ` [PATCH 10/20] mt9m111: rewrite make_rect for positioning in debug Michael Grzeschik
2010-08-01  9:33   ` Guennadi Liakhovetski
2010-07-30 14:53 ` [PATCH 11/20] mt9m111: added mt9m111 format structure Michael Grzeschik
2010-08-01 16:48   ` Guennadi Liakhovetski
2010-07-30 14:53 ` [PATCH 12/20] mt9m111: s_crop add calculation of output size Michael Grzeschik
2010-08-01 19:38   ` Guennadi Liakhovetski
2010-07-30 14:53 ` [PATCH 13/20] mt9m111: s_crop check for VIDEO_CAPTURE type Michael Grzeschik
2010-07-30 14:53 ` [PATCH 14/20] mt9m111: added reg_mask function Michael Grzeschik
2010-07-30 14:53 ` [PATCH 15/20] mt9m111: rewrite setup_rect, added soft_crop for smooth panning Michael Grzeschik
2010-07-30 14:53 ` [PATCH 16/20] mt9m111: added more supported BE colour formats Michael Grzeschik
2010-07-30 14:53 ` [PATCH 17/20] mt9m111: rewrite set_pixfmt Michael Grzeschik
2010-07-30 14:53 ` [PATCH 18/20] mt9m111: make use of testpattern in debug mode Michael Grzeschik
2010-07-30 14:53 ` [PATCH 19/20] mt9m111: try_fmt rewrite to use preset values Michael Grzeschik
2010-07-30 14:53 ` [PATCH 20/20] mt9m111: s_fmt make use of try_fmt Michael Grzeschik
2010-07-30 15:38 ` [PATCH 00/20] MT9M111/MT9M131 Guennadi Liakhovetski
2010-07-31 10:33   ` Robert Jarzmik
2010-08-02 10:35   ` Michael Grzeschik

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=874off1j8b.fsf@free.fr \
    --to=robert.jarzmik@free.fr \
    --cc=g.liakhovetski@gmx.de \
    --cc=linux-media@vger.kernel.org \
    --cc=m.grzeschik@pengutronix.de \
    --cc=p.wiesner@phytec.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.