Hi Laurent,
On Fri, Mar 09, 2012 at 09:20:47PM +0100, Laurent Pinchart wrote:
> > Laurent Pinchart wrote:
> > ...
> >
> > > +static int mt9m032_setup_pll(struct mt9m032 *sensor)
> > > +{
> > > + static const struct aptina_pll_limits limits = {
> > > + .ext_clock_min = 8000000,
> > > + .ext_clock_max = 16500000,
> > > + .int_clock_min = 2000000,
> > > + .int_clock_max = 24000000,
> > > + .out_clock_min = 322000000,
> > > + .out_clock_max = 693000000,
> > > + .pix_clock_max = 99000000,
> > > + .n_min = 1,
> > > + .n_max = 64,
> > > + .m_min = 16,
> > > + .m_max = 255,
> > > + .p1_min = 1,
> > > + .p1_max = 128,
> > > + };
> > > +
> > > + struct i2c_client *client = v4l2_get_subdevdata(&sensor->subdev);
> > > + struct mt9m032_platform_data *pdata = sensor->pdata;
> > > + struct aptina_pll pll;
> > > + int ret;
> > > +
> > > + pll.ext_clock = pdata->ext_clock;
> > > + pll.pix_clock = pdata->pix_clock;
> > > +
> > > + ret = aptina_pll_calculate(&client->dev, &limits, &pll);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + sensor->pix_clock = pll.pix_clock;
> >
> > I wouldn't expect aptina_pll_calculate() to change the supplied pixel
> > clock. I'd consider it a bug if it does that. So you could use the pixel
> > clock from platform data equally well.
>
> But does it make a difference ? :-) Taking the value from pll.pix_clock seems
> more logical to me.
This is an input parameter rather than output. I don't see a reason to read
it back. It works even if you do, but makes no sense.
I've been thinking of splitting the similar struct on SMIA++ between input
and output parameters later on.
Regards,
--
Sakari Ailus
e-mail: sakari.ailus@xxxxxx jabber/XMPP/Gmail: sailus@xxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
