[GIT PATCHES FOR 2.6.41] Add bitmask controls

[GIT PATCHES FOR 2.6.41] Add bitmask controls

[Hans Verkuil]

Hi Mauro,

These patches for 2.6.41 add support for bitmask controls, needed for the
upcoming Flash API and HDMI API.

Sakari, can you give your ack as well?

The patch is the same as the original one posted April 4, except for a small
change in the control logging based on feedback from Laurent and the new
DocBook documentation.

Regards,

	Hans

The following changes since commit 87cf028f3aa1ed51fe29c36df548aa714dc7438f:

  [media] dm1105: GPIO handling added, I2C on GPIO added, LNB control through GPIO reworked (2011-05-21 11:10:28 -0300)

are available in the git repository at:
  ssh://linuxtv.org/git/hverkuil/media_tree.git core3

Hans Verkuil (3):
      v4l2-ctrls: add new bitmask control type.
      vivi: add bitmask test control.
      DocBook: document V4L2_CTRL_TYPE_BITMASK.

 Documentation/DocBook/v4l/compat.xml           |    8 ++++++++
 Documentation/DocBook/v4l/v4l2.xml             |    9 ++++++++-
 Documentation/DocBook/v4l/vidioc-queryctrl.xml |   12 +++++++++++-
 drivers/media/video/v4l2-common.c              |    3 +++
 drivers/media/video/v4l2-ctrls.c               |   17 ++++++++++++++++-
 drivers/media/video/vivi.c                     |   18 ++++++++++++++++--
 include/linux/videodev2.h                      |    1 +
 7 files changed, 63 insertions(+), 5 deletions(-)

Re: [GIT PATCHES FOR 2.6.41] Add bitmask controls

[Sakari Ailus]

Hans Verkuil wrote:
> Hi Mauro,
> 
> These patches for 2.6.41 add support for bitmask controls, needed for the
> upcoming Flash API and HDMI API.
> 
> Sakari, can you give your ack as well?
> 
> The patch is the same as the original one posted April 4, except for a small
> change in the control logging based on feedback from Laurent and the new
> DocBook documentation.

Thanks, Hans!!

Acked-by: Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>

-- 
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com

Re: [GIT PATCHES FOR 2.6.41] Add bitmask controls

[Mauro Carvalho Chehab]

Hi Hans,

Em 23-05-2011 08:15, Hans Verkuil escreveu:
> Hi Mauro,
> 
> These patches for 2.6.41 add support for bitmask controls, needed for the
> upcoming Flash API and HDMI API.

DocBook changes need do a s/2.6.41/3.1/. 

That's said, I'm not sure if it is a good idea to add bitmask type, instead of
just using a set of boolean controls. One of the issues with bitmasks is the
endness type: LE, BE or machine endianness. The specs don't mention how this
is supposed to work.

Also, I'd like to see a patch like that submitting with a driver or feature
that needs it. Before you ask: no, vivi doesn't count ;)

> Sakari, can you give your ack as well?
> 
> The patch is the same as the original one posted April 4, except for a small
> change in the control logging based on feedback from Laurent and the new
> DocBook documentation.

Cheers,
Mauro

Re: [GIT PATCHES FOR 2.6.41] Add bitmask controls

[Hans Verkuil]

> Hi Hans,
>
> Em 23-05-2011 08:15, Hans Verkuil escreveu:
>> Hi Mauro,
>>
>> These patches for 2.6.41 add support for bitmask controls, needed for
>> the
>> upcoming Flash API and HDMI API.
>
> DocBook changes need do a s/2.6.41/3.1/.

Of course, I saw your DocBook changes going today.

> That's said, I'm not sure if it is a good idea to add bitmask type,
> instead of
> just using a set of boolean controls.

There are currently two use cases: Sakari's flash controller needs to
report errors which are a bitmask of possible error conditions. It is way
overkill to split that up in separate boolean controls, especially since
apps will also want to get an event whenever such an error is raised.

The other is in HDMI receivers where there can be multiple ports that do
EDID handling, but only one can stream. You need a way to tell which ports
received an EDID for example. Again, you can make multiple boolean
controls like HDMI_PORT0_EDID_REC, PORT1, PORT2, PORT3, etc. but that is a
waste of code and time.

> One of the issues with bitmasks is
> the
> endness type: LE, BE or machine endianness. The specs don't mention how
> this
> is supposed to work.

Good point. It's machine endianness, but that definitely has to be
documented. I'll do that.

> Also, I'd like to see a patch like that submitting with a driver or
> feature
> that needs it. Before you ask: no, vivi doesn't count ;)

Sakari will hopefully be the first 'real' user for this for a flash driver.

Regards,

        Hans

>
>> Sakari, can you give your ack as well?
>>
>> The patch is the same as the original one posted April 4, except for a
>> small
>> change in the control logging based on feedback from Laurent and the new
>> DocBook documentation.
>
> Cheers,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [GIT PATCHES FOR 2.6.41] Add bitmask controls

[Mauro Carvalho Chehab]

Em 01-06-2011 10:27, Hans Verkuil escreveu:
>> Hi Hans,
>>
>> Em 23-05-2011 08:15, Hans Verkuil escreveu:
>>> Hi Mauro,
>>>
>>> These patches for 2.6.41 add support for bitmask controls, needed for
>>> the
>>> upcoming Flash API and HDMI API.
>>
>> DocBook changes need do a s/2.6.41/3.1/.
> 
> Of course, I saw your DocBook changes going today.

Btw, you may need to adjust your daily scripts, as the patches changed
the place where the V4L API is placed.

>> That's said, I'm not sure if it is a good idea to add bitmask type,
>> instead of
>> just using a set of boolean controls.
> 
> There are currently two use cases: Sakari's flash controller needs to
> report errors which are a bitmask of possible error conditions. It is way
> overkill to split that up in separate boolean controls, especially since
> apps will also want to get an event whenever such an error is raised.

Hmm... returning errors via V4L2 controls don't seem to be a good implementation.
I need to review his RFC to better understand his idea.

> The other is in HDMI receivers where there can be multiple ports that do
> EDID handling, but only one can stream. You need a way to tell which ports
> received an EDID for example. Again, you can make multiple boolean
> controls like HDMI_PORT0_EDID_REC, PORT1, PORT2, PORT3, etc. but that is a
> waste of code and time.

Ok, this seems to be a good example.

>> One of the issues with bitmasks is
>> the
>> endness type: LE, BE or machine endianness. The specs don't mention how
>> this
>> is supposed to work.
> 
> Good point. It's machine endianness, but that definitely has to be
> documented. I'll do that.

OK, thanks!

>> Also, I'd like to see a patch like that submitting with a driver or
>> feature
>> that needs it. Before you ask: no, vivi doesn't count ;)
> 
> Sakari will hopefully be the first 'real' user for this for a flash driver.

Thanks,
Mauro

Re: [GIT PATCHES FOR 2.6.41] Add bitmask controls

[Sakari Ailus]

On Wed, Jun 01, 2011 at 10:41:21AM -0300, Mauro Carvalho Chehab wrote:
> > There are currently two use cases: Sakari's flash controller needs to
> > report errors which are a bitmask of possible error conditions. It is way
> > overkill to split that up in separate boolean controls, especially since
> > apps will also want to get an event whenever such an error is raised.
> 
> Hmm... returning errors via V4L2 controls don't seem to be a good implementation.
> I need to review his RFC to better understand his idea.

The "errors" are not errors in the traditional meaning --- they also are
called faults. They signal that there's either a temporary or a permanent
hardware problem with the flash controller. The user will be able to
mitigate with many of these. Also the faults do arrive asynchronously,
making traditional error handling unsuitable for them. For example, the LED
controller may overheat in some situations which cause immediate LED
shutdown, leading to only partially flash exposed frame. When this happens
the user has to be notified of the condition, and to avoid reading a large
set of controls, a single bitmask control telling directly the reason for
the trouble is ideal.

The full RFC may be found here: 

<USR:http://www.spinics.net/lists/linux-media/msg32030.html>

Cheers,

-- 
Sakari Ailus
sakari dot ailus at iki dot fi

Re: [GIT PATCHES FOR 2.6.41] Add bitmask controls

[Sakari Ailus]

On Sun, Jun 05, 2011 at 04:28:03PM +0300, Sakari Ailus wrote:
> On Wed, Jun 01, 2011 at 10:41:21AM -0300, Mauro Carvalho Chehab wrote:
> > > There are currently two use cases: Sakari's flash controller needs to
> > > report errors which are a bitmask of possible error conditions. It is way
> > > overkill to split that up in separate boolean controls, especially since
> > > apps will also want to get an event whenever such an error is raised.
> > 
> > Hmm... returning errors via V4L2 controls don't seem to be a good implementation.
> > I need to review his RFC to better understand his idea.
> 
> The "errors" are not errors in the traditional meaning --- they also are
> called faults. They signal that there's either a temporary or a permanent
> hardware problem with the flash controller. The user will be able to
> mitigate with many of these. Also the faults do arrive asynchronously,
> making traditional error handling unsuitable for them. For example, the LED
> controller may overheat in some situations which cause immediate LED
> shutdown, leading to only partially flash exposed frame. When this happens
> the user has to be notified of the condition, and to avoid reading a large
> set of controls, a single bitmask control telling directly the reason for
> the trouble is ideal.
> 
> The full RFC may be found here: 
> 
> <USR:http://www.spinics.net/lists/linux-media/msg32030.html>

That was supposed to be 

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

The adp1653 flash controller driver using the flash API. The patches have
been acked by Laurent already.

Regards,

-- 
Sakari Ailus
sakari.ailus@iki.fi

Re: [GIT PATCHES FOR 2.6.41] Add bitmask controls

[Hans Verkuil]

> On Sun, Jun 05, 2011 at 04:28:03PM +0300, Sakari Ailus wrote:
>> On Wed, Jun 01, 2011 at 10:41:21AM -0300, Mauro Carvalho Chehab wrote:
>> > > There are currently two use cases: Sakari's flash controller needs
>> to
>> > > report errors which are a bitmask of possible error conditions. It
>> is way
>> > > overkill to split that up in separate boolean controls, especially
>> since
>> > > apps will also want to get an event whenever such an error is
>> raised.
>> >
>> > Hmm... returning errors via V4L2 controls don't seem to be a good
>> implementation.
>> > I need to review his RFC to better understand his idea.
>>
>> The "errors" are not errors in the traditional meaning --- they also are
>> called faults. They signal that there's either a temporary or a
>> permanent
>> hardware problem with the flash controller. The user will be able to
>> mitigate with many of these. Also the faults do arrive asynchronously,
>> making traditional error handling unsuitable for them. For example, the
>> LED
>> controller may overheat in some situations which cause immediate LED
>> shutdown, leading to only partially flash exposed frame. When this
>> happens
>> the user has to be notified of the condition, and to avoid reading a
>> large
>> set of controls, a single bitmask control telling directly the reason
>> for
>> the trouble is ideal.
>>
>> The full RFC may be found here:
>>
>> <USR:http://www.spinics.net/lists/linux-media/msg32030.html>
>
> That was supposed to be
>
> <URL:http://www.spinics.net/lists/linux-media/msg32030.html>
>
> The adp1653 flash controller driver using the flash API. The patches have
> been acked by Laurent already.

Sakari, I think it is best if you combine that driver with my bitmask
patch series and have it pulled as a whole.

Regards,

       Hans

Re: [GIT PATCHES FOR 2.6.41] Add bitmask controls

[Sakari Ailus]

On Wed, Jun 08, 2011 at 01:04:05PM +0200, Hans Verkuil wrote:
> > On Sun, Jun 05, 2011 at 04:28:03PM +0300, Sakari Ailus wrote:
> >> On Wed, Jun 01, 2011 at 10:41:21AM -0300, Mauro Carvalho Chehab wrote:
> >> > > There are currently two use cases: Sakari's flash controller needs
> >> to
> >> > > report errors which are a bitmask of possible error conditions. It
> >> is way
> >> > > overkill to split that up in separate boolean controls, especially
> >> since
> >> > > apps will also want to get an event whenever such an error is
> >> raised.
> >> >
> >> > Hmm... returning errors via V4L2 controls don't seem to be a good
> >> implementation.
> >> > I need to review his RFC to better understand his idea.
> >>
> >> The "errors" are not errors in the traditional meaning --- they also are
> >> called faults. They signal that there's either a temporary or a
> >> permanent
> >> hardware problem with the flash controller. The user will be able to
> >> mitigate with many of these. Also the faults do arrive asynchronously,
> >> making traditional error handling unsuitable for them. For example, the
> >> LED
> >> controller may overheat in some situations which cause immediate LED
> >> shutdown, leading to only partially flash exposed frame. When this
> >> happens
> >> the user has to be notified of the condition, and to avoid reading a
> >> large
> >> set of controls, a single bitmask control telling directly the reason
> >> for
> >> the trouble is ideal.
> >>
> >> The full RFC may be found here:
> >>
> >> <USR:http://www.spinics.net/lists/linux-media/msg32030.html>
> >
> > That was supposed to be
> >
> > <URL:http://www.spinics.net/lists/linux-media/msg32030.html>
> >
> > The adp1653 flash controller driver using the flash API. The patches have
> > been acked by Laurent already.
> 
> Sakari, I think it is best if you combine that driver with my bitmask
> patch series and have it pulled as a whole.

Right; I'll do that.

Thanks.

-- 
Sakari Ailus
sakari.ailus@iki.fi