v4l: how to get blanking clock count?

v4l: how to get blanking clock count?

[Scott Jiang]

Hi Hans and Guennadi,

Our bridge driver needs to know line clock count including active
lines and blanking area.
I can compute active clock count according to pixel format, but how
can I get this in blanking area in current framework?

Thanks,
Scott

Re: v4l: how to get blanking clock count?

[Sakari Ailus]

Hi Scott,

On Fri, Dec 30, 2011 at 03:20:43PM +0800, Scott Jiang wrote:
> Hi Hans and Guennadi,
> 
> Our bridge driver needs to know line clock count including active
> lines and blanking area.
> I can compute active clock count according to pixel format, but how
> can I get this in blanking area in current framework?

Such information is not available currently over the V4L2 subdev interface.
Please see this patchset:

<URL:http://www.spinics.net/lists/linux-media/msg41765.html>

Patches 7 and 8 are probably the most interesting for you. This is an RFC
patchset so the final implementation could well still change.

Kind regards,

-- 
Sakari Ailus
e-mail: sakari.ailus@iki.fi	jabber/XMPP/Gmail: sailus@retiisi.org.uk

Re: v4l: how to get blanking clock count?

[Scott Jiang]

2011/12/31 Sakari Ailus <sakari.ailus@iki.fi>:
> Hi Scott,
>
> On Fri, Dec 30, 2011 at 03:20:43PM +0800, Scott Jiang wrote:
>> Hi Hans and Guennadi,
>>
>> Our bridge driver needs to know line clock count including active
>> lines and blanking area.
>> I can compute active clock count according to pixel format, but how
>> can I get this in blanking area in current framework?
>
> Such information is not available currently over the V4L2 subdev interface.
> Please see this patchset:
>
> <URL:http://www.spinics.net/lists/linux-media/msg41765.html>
>
> Patches 7 and 8 are probably the most interesting for you. This is an RFC
> patchset so the final implementation could well still change.
>
Hi Sakari,

Thanks for your reply. Your patch added VBLANK and HBLANK control, but
my case isn't a user control.
That is to say, you can't specify a blanking control value for sensor.
And you added pixel clock rate in mbus format, I think if I add two
more parametres such as VBLANK lines and HBLANK clocks I can solve
this problem. In fact, active lines and blanking lines are essential
params to define an image.

Regards,
Scott

Re: v4l: how to get blanking clock count?

[Sakari Ailus]

Hi Scott,

On Sat, Dec 31, 2011 at 02:57:31PM +0800, Scott Jiang wrote:
> 2011/12/31 Sakari Ailus <sakari.ailus@iki.fi>:
> > Hi Scott,
> >
> > On Fri, Dec 30, 2011 at 03:20:43PM +0800, Scott Jiang wrote:
> >> Hi Hans and Guennadi,
> >>
> >> Our bridge driver needs to know line clock count including active
> >> lines and blanking area.
> >> I can compute active clock count according to pixel format, but how
> >> can I get this in blanking area in current framework?
> >
> > Such information is not available currently over the V4L2 subdev interface.
> > Please see this patchset:
> >
> > <URL:http://www.spinics.net/lists/linux-media/msg41765.html>
> >
> > Patches 7 and 8 are probably the most interesting for you. This is an RFC
> > patchset so the final implementation could well still change.
> >
> Hi Sakari,
> 
> Thanks for your reply. Your patch added VBLANK and HBLANK control, but
> my case isn't a user control.
> That is to say, you can't specify a blanking control value for sensor.

I the case of your bridge, that may not be possible, but that's the only one
I've heard of so I think it's definitely a special case. In that case the
sensor driver can't be allowed to change the blanking periods while
streaming is ongoing.

framesamples proposed by Sylwester for v4l2_mbus_framefmt could, and
probably should, be exposed as a control with similar property.

> And you added pixel clock rate in mbus format, I think if I add two
> more parametres such as VBLANK lines and HBLANK clocks I can solve
> this problem. In fact, active lines and blanking lines are essential
> params to define an image.

Only the active lines and rows are, blanking period is just an idle period
where no image data is transferred. It does not affect the resulting image
in any way.

-- 
Sakari Ailus
e-mail: sakari.ailus@iki.fi	jabber/XMPP/Gmail: sailus@retiisi.org.uk

Re: v4l: how to get blanking clock count?

[Sylwester Nawrocki]

Hi Sakari,

On 12/31/2011 12:35 PM, Sakari Ailus wrote:
> On Sat, Dec 31, 2011 at 02:57:31PM +0800, Scott Jiang wrote:
>> 2011/12/31 Sakari Ailus <sakari.ailus@iki.fi>:
>>> On Fri, Dec 30, 2011 at 03:20:43PM +0800, Scott Jiang wrote:
>>>> Our bridge driver needs to know line clock count including active
>>>> lines and blanking area.
>>>> I can compute active clock count according to pixel format, but how
>>>> can I get this in blanking area in current framework?
>>>
>>> Such information is not available currently over the V4L2 subdev interface.
>>> Please see this patchset:
>>>
>>> <URL:http://www.spinics.net/lists/linux-media/msg41765.html>
>>>
>>> Patches 7 and 8 are probably the most interesting for you. This is an RFC
>>> patchset so the final implementation could well still change.
>>>
>> Hi Sakari,
>>
>> Thanks for your reply. Your patch added VBLANK and HBLANK control, but
>> my case isn't a user control.
>> That is to say, you can't specify a blanking control value for sensor.
> 
> I the case of your bridge, that may not be possible, but that's the only one
> I've heard of so I think it's definitely a special case. In that case the
> sensor driver can't be allowed to change the blanking periods while
> streaming is ongoing.

I agree, it's just a matter of adding proper logic at the sensor driver.
However it might be a bit tricky, the bridge would have to validate blanking
values before actually enabling streaming.

> framesamples proposed by Sylwester for v4l2_mbus_framefmt could, and
> probably should, be exposed as a control with similar property.

Yeah, I'm going to try to add it to your proposed image source control
class.

>> And you added pixel clock rate in mbus format, I think if I add two
>> more parametres such as VBLANK lines and HBLANK clocks I can solve
>> this problem. In fact, active lines and blanking lines are essential
>> params to define an image.
> 
> Only the active lines and rows are, blanking period is just an idle period
> where no image data is transferred. It does not affect the resulting image
> in any way.

--
Regards,
Sylwester

Re: v4l: how to get blanking clock count?

[Sakari Ailus]

Hi Syöweser,

On Sat, Dec 31, 2011 at 01:03:20PM +0100, Sylwester Nawrocki wrote:
> On 12/31/2011 12:35 PM, Sakari Ailus wrote:
> > On Sat, Dec 31, 2011 at 02:57:31PM +0800, Scott Jiang wrote:
> >> 2011/12/31 Sakari Ailus <sakari.ailus@iki.fi>:
> >>> On Fri, Dec 30, 2011 at 03:20:43PM +0800, Scott Jiang wrote:
> >>>> Our bridge driver needs to know line clock count including active
> >>>> lines and blanking area.
> >>>> I can compute active clock count according to pixel format, but how
> >>>> can I get this in blanking area in current framework?
> >>>
> >>> Such information is not available currently over the V4L2 subdev interface.
> >>> Please see this patchset:
> >>>
> >>> <URL:http://www.spinics.net/lists/linux-media/msg41765.html>
> >>>
> >>> Patches 7 and 8 are probably the most interesting for you. This is an RFC
> >>> patchset so the final implementation could well still change.
> >>>
> >> Hi Sakari,
> >>
> >> Thanks for your reply. Your patch added VBLANK and HBLANK control, but
> >> my case isn't a user control.
> >> That is to say, you can't specify a blanking control value for sensor.
> > 
> > I the case of your bridge, that may not be possible, but that's the only one
> > I've heard of so I think it's definitely a special case. In that case the
> > sensor driver can't be allowed to change the blanking periods while
> > streaming is ongoing.
> 
> I agree, it's just a matter of adding proper logic at the sensor driver.
> However it might be a bit tricky, the bridge would have to validate blanking
> values before actually enabling streaming.

I'd rather add a way to the control framework to set controls busy. The
busy state would likely need to be a count, since the driver itself also
must be able to set controls busy. It could also keep track of who did set
those controls busy to ease debugging.

The sensor driver also must set dependent controls busy.

> > framesamples proposed by Sylwester for v4l2_mbus_framefmt could, and
> > probably should, be exposed as a control with similar property.
> 
> Yeah, I'm going to try to add it to your proposed image source control
> class.

Sounds good to me.

-- 
Sakari Ailus
e-mail: sakari.ailus@iki.fi	jabber/XMPP/Gmail: sailus@retiisi.org.uk

Re: v4l: how to get blanking clock count?

[Scott Jiang]

>> I the case of your bridge, that may not be possible, but that's the only one
>> I've heard of so I think it's definitely a special case. In that case the
>> sensor driver can't be allowed to change the blanking periods while
>> streaming is ongoing.
>
> I agree, it's just a matter of adding proper logic at the sensor driver.
> However it might be a bit tricky, the bridge would have to validate blanking
> values before actually enabling streaming.
>
Yes, this value doesn't affect the result image. The hardware only
raises a error interrupt to signify that a horizontal tracking
overflow has
occurred, that means the programmed number of samples did not match up
with the actual number of samples counted between assertions of
HSYNC(I can only set active samples now).

Re: v4l: how to get blanking clock count?

[Sakari Ailus]

Hi Scott,

On Wed, Jan 04, 2012 at 01:50:17PM +0800, Scott Jiang wrote:
> >> I the case of your bridge, that may not be possible, but that's the only one
> >> I've heard of so I think it's definitely a special case. In that case the
> >> sensor driver can't be allowed to change the blanking periods while
> >> streaming is ongoing.
> >
> > I agree, it's just a matter of adding proper logic at the sensor driver.
> > However it might be a bit tricky, the bridge would have to validate blanking
> > values before actually enabling streaming.
> >
> Yes, this value doesn't affect the result image. The hardware only
> raises a error interrupt to signify that a horizontal tracking
> overflow has
> occurred, that means the programmed number of samples did not match up
> with the actual number of samples counted between assertions of
> HSYNC(I can only set active samples now).

Is there no way to disable this tracking, and just rely on hsync as everyone
else does? Sounds like the hardware tries to do something it shouldn't...

-- 
Sakari Ailus
e-mail: sakari.ailus@iki.fi	jabber/XMPP/Gmail: sailus@retiisi.org.uk

Re: v4l: how to get blanking clock count?

[Scott Jiang]

2012/1/4 Sakari Ailus <sakari.ailus@iki.fi>:
> Hi Scott,
>
> On Wed, Jan 04, 2012 at 01:50:17PM +0800, Scott Jiang wrote:
>> >> I the case of your bridge, that may not be possible, but that's the only one
>> >> I've heard of so I think it's definitely a special case. In that case the
>> >> sensor driver can't be allowed to change the blanking periods while
>> >> streaming is ongoing.
>> >
>> > I agree, it's just a matter of adding proper logic at the sensor driver.
>> > However it might be a bit tricky, the bridge would have to validate blanking
>> > values before actually enabling streaming.
>> >
>> Yes, this value doesn't affect the result image. The hardware only
>> raises a error interrupt to signify that a horizontal tracking
>> overflow has
>> occurred, that means the programmed number of samples did not match up
>> with the actual number of samples counted between assertions of
>> HSYNC(I can only set active samples now).
>
> Is there no way to disable this tracking, and just rely on hsync as everyone
> else does? Sounds like the hardware tries to do something it shouldn't...
>
If I disable this interrupt, other errors like fifo underflow are ignored.
Perhaps I can add a parameter in platform data to let user decide to
register this interrupt or not.

Scott

Re: v4l: how to get blanking clock count?

[Sakari Ailus]

On Wed, Jan 04, 2012 at 05:10:40PM +0800, Scott Jiang wrote:
> 2012/1/4 Sakari Ailus <sakari.ailus@iki.fi>:
> > Hi Scott,
> >
> > On Wed, Jan 04, 2012 at 01:50:17PM +0800, Scott Jiang wrote:
> >> >> I the case of your bridge, that may not be possible, but that's the only one
> >> >> I've heard of so I think it's definitely a special case. In that case the
> >> >> sensor driver can't be allowed to change the blanking periods while
> >> >> streaming is ongoing.
> >> >
> >> > I agree, it's just a matter of adding proper logic at the sensor driver.
> >> > However it might be a bit tricky, the bridge would have to validate blanking
> >> > values before actually enabling streaming.
> >> >
> >> Yes, this value doesn't affect the result image. The hardware only
> >> raises a error interrupt to signify that a horizontal tracking
> >> overflow has
> >> occurred, that means the programmed number of samples did not match up
> >> with the actual number of samples counted between assertions of
> >> HSYNC(I can only set active samples now).
> >
> > Is there no way to disable this tracking, and just rely on hsync as everyone
> > else does? Sounds like the hardware tries to do something it shouldn't...
> >
> If I disable this interrupt, other errors like fifo underflow are ignored.
> Perhaps I can add a parameter in platform data to let user decide to
> register this interrupt or not.

I think a more generic solution would be preferrable. If that causes
ignoring real errors, that's of course bad. I  wonder if there would be a
way around that.

Is there a publicly available datasheet for the bridge that I could take a
look at?

-- 
Sakari Ailus
e-mail: sakari.ailus@iki.fi	jabber/XMPP/Gmail: sailus@retiisi.org.uk

Re: v4l: how to get blanking clock count?

[Scott Jiang]

>> If I disable this interrupt, other errors like fifo underflow are ignored.
>> Perhaps I can add a parameter in platform data to let user decide to
>> register this interrupt or not.
>
> I think a more generic solution would be preferrable. If that causes
> ignoring real errors, that's of course bad. I  wonder if there would be a
> way around that.
>
> Is there a publicly available datasheet for the bridge that I could take a
> look at?
>
Yes, http://www.analog.com/en/processors-dsp/blackfin/adsp-bf548/processors/technical-documentation/index.html.
There is a hardware reference manual for bf54x, bridge is eppi.

Re: v4l: how to get blanking clock count?

[Sakari Ailus]

On Wed, Jan 04, 2012 at 05:59:45PM +0800, Scott Jiang wrote:
> >> If I disable this interrupt, other errors like fifo underflow are ignored.
> >> Perhaps I can add a parameter in platform data to let user decide to
> >> register this interrupt or not.
> >
> > I think a more generic solution would be preferrable. If that causes
> > ignoring real errors, that's of course bad. I  wonder if there would be a
> > way around that.
> >
> > Is there a publicly available datasheet for the bridge that I could take a
> > look at?
> >
> Yes, http://www.analog.com/en/processors-dsp/blackfin/adsp-bf548/processors/technical-documentation/index.html.
> There is a hardware reference manual for bf54x, bridge is eppi.

It's really an interesting design choice --- it also likely makes detecting
all too common errors easier. But it also makes it impossible to dynamically
change blanking periods...

Well, I think the solution could be that the host would set these sensor
controls read-only (or just make them return -EBUSY when written to); this
isn't yet supported in the control framework. Also the idea is rather new,
but I think it would have many more uses than this.

Hans?

-- 
Sakari Ailus
e-mail: sakari.ailus@iki.fi	jabber/XMPP/Gmail: sailus@retiisi.org.uk

Re: v4l: how to get blanking clock count?

[Sakari Ailus]

Hi Scott,

On Wed, Jan 04, 2012 at 05:59:45PM +0800, Scott Jiang wrote:
> >> If I disable this interrupt, other errors like fifo underflow are ignored.
> >> Perhaps I can add a parameter in platform data to let user decide to
> >> register this interrupt or not.
> >
> > I think a more generic solution would be preferrable. If that causes
> > ignoring real errors, that's of course bad. I  wonder if there would be a
> > way around that.
> >
> > Is there a publicly available datasheet for the bridge that I could take a
> > look at?
> >
> Yes, http://www.analog.com/en/processors-dsp/blackfin/adsp-bf548/processors/technical-documentation/index.html.
> There is a hardware reference manual for bf54x, bridge is eppi.

Yeah, indeed it's the first time I see hardware like this. So to support
this properly, we truly need the new sensor control interface and an ability
to make those blanking values unchangeable.

-- 
Sakari Ailus
e-mail: sakari.ailus@iki.fi	jabber/XMPP/Gmail: sailus@retiisi.org.uk