Re: [PULL] soc-camera and mediabus

2010-01-10 Thread Mauro Carvalho Chehab 
Guennadi Liakhovetski wrote:
 Hi Mauro
 
 On Mon, 14 Dec 2009, Mauro Carvalho Chehab wrote:
 
 Guennadi Liakhovetski wrote:
 So, is the doc patch, that I've sent to the list ok? Ok, the hunk for the 
 automatically (in hg) generated file will get dropped, and otherwise does 
 it look correct?
 It looks correctly on my eyes. The only thing I noticed is that you've added
 emacs headers at the end of the new patches:

 +
 +  !--
 +Local Variables:
 +mode: sgml
 +sgml-parent-document: pixfmt.sgml
 +indent-tabs-mode: nil
 +End:
 +  --

 Please remove those tags when submitting the final version.
 
 I tried to just through away the media-specs/media-entities.tmpl hunk, as 
 that file should be auto-generated, but the new version doesn't include 
 the new formats either. What am I doing wrong? The patch attached below.

As you're adding new files, you need to tell Makefile to take a look on them
also. So, just add the new files to V4L_SGMLS list at Makefile should do
the job.


Cheers,
Mauro.

 
 Thanks
 Guennadi
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/
 
 # HG changeset patch
 # User Guennadi Liakhovetski g.liakhovet...@gmx.de
 # Date 1261648434 -3600
 # Node ID 52e14d4799279a860fe158e8bf4f1993d6c6
 # Parent  4506e2d541265bfa0c0fd5187c6a39d39a456559
 document new pixel formats
 
 Document all four 10-bit Bayer formats, 10-bit monochrome and a missing
 8-bit Bayer formats.
 
 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 
 diff -r 4506e2d54126 -r 52e14d479927 
 linux/Documentation/DocBook/v4l/pixfmt-srggb10.xml
 --- /dev/null Thu Jan 01 00:00:00 1970 +
 +++ b/linux/Documentation/DocBook/v4l/pixfmt-srggb10.xml  Thu Dec 24 
 10:53:54 2009 +0100
 @@ -0,0 +1,90 @@
 +refentry
 +  refmeta
 + refentrytitleV4L2_PIX_FMT_SRGGB10 ('RG10'),
 +  V4L2_PIX_FMT_SGRBG10 ('BA10'),
 +  V4L2_PIX_FMT_SGBRG10 ('GB10'),
 +  V4L2_PIX_FMT_SBGGR10 ('BG10'),
 +  /refentrytitle
 + manvol;
 +  /refmeta
 +  refnamediv
 + refname 
 id=V4L2-PIX-FMT-SRGGB10constantV4L2_PIX_FMT_SRGGB10/constant/refname
 + refname 
 id=V4L2-PIX-FMT-SGRBG10constantV4L2_PIX_FMT_SGRBG10/constant/refname
 + refname 
 id=V4L2-PIX-FMT-SGBRG10constantV4L2_PIX_FMT_SGBRG10/constant/refname
 + refname 
 id=V4L2-PIX-FMT-SBGGR10constantV4L2_PIX_FMT_SBGGR10/constant/refname
 + refpurpose10-bit Bayer formats expanded to 16 bits/refpurpose
 +  /refnamediv
 +  refsect1
 + titleDescription/title
 +
 + paraThe following four pixel formats are raw sRGB / Bayer formats with
 +10 bits per colour. Each colour component is stored in a 16-bit word, with 6
 +unused high bits filled with zeros. Each n-pixel row contains n/2 green 
 samples
 +and n/2 blue or red samples, with alternating red and blue rows. Bytes are
 +stored in memory in little endian order. They are conventionally described
 +as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
 +formats/para
 +
 +example
 +  titleconstantV4L2_PIX_FMT_SBGGR10/constant 4 times; 4
 +pixel image/title
 +
 +  formalpara
 + titleByte Order./title
 + paraEach cell is one byte, high 6 bits in high bytes are 0.
 +   informaltable frame=none
 + tgroup cols=5 align=center
 +   colspec align=left colwidth=2* /
 +   tbody valign=top
 + row
 +   entrystartnbsp;+nbsp;0:/entry
 +   entryBsubscript00low/subscript/entry
 +   entryBsubscript00high/subscript/entry
 +   entryGsubscript01low/subscript/entry
 +   entryGsubscript01high/subscript/entry
 +   entryBsubscript02low/subscript/entry
 +   entryBsubscript02high/subscript/entry
 +   entryGsubscript03low/subscript/entry
 +   entryGsubscript03high/subscript/entry
 + /row
 + row
 +   entrystartnbsp;+nbsp;8:/entry
 +   entryGsubscript10low/subscript/entry
 +   entryGsubscript10high/subscript/entry
 +   entryRsubscript11low/subscript/entry
 +   entryRsubscript11high/subscript/entry
 +   entryGsubscript12low/subscript/entry
 +   entryGsubscript12high/subscript/entry
 +   entryRsubscript13low/subscript/entry
 +   entryRsubscript13high/subscript/entry
 + /row
 + row
 +   entrystartnbsp;+nbsp;16:/entry
 +   entryBsubscript20low/subscript/entry
 +   entryBsubscript20high/subscript/entry
 +   entryGsubscript21low/subscript/entry
 +   entryGsubscript21high/subscript/entry
 +   entryBsubscript22low/subscript/entry
 +   entryBsubscript22high/subscript/entry
 +   entryGsubscript23low/subscript/entry
 +   entryGsubscript23high/subscript/entry
 + /row
 + row
 +

Re: [PULL] soc-camera and mediabus

2009-12-24 Thread Guennadi Liakhovetski 
Hi Mauro

On Mon, 14 Dec 2009, Mauro Carvalho Chehab wrote:

 Guennadi Liakhovetski wrote:
  
  So, is the doc patch, that I've sent to the list ok? Ok, the hunk for the 
  automatically (in hg) generated file will get dropped, and otherwise does 
  it look correct?
 
 It looks correctly on my eyes. The only thing I noticed is that you've added
 emacs headers at the end of the new patches:
 
 +
 +  !--
 +Local Variables:
 +mode: sgml
 +sgml-parent-document: pixfmt.sgml
 +indent-tabs-mode: nil
 +End:
 +  --
 
 Please remove those tags when submitting the final version.

I tried to just through away the media-specs/media-entities.tmpl hunk, as 
that file should be auto-generated, but the new version doesn't include 
the new formats either. What am I doing wrong? The patch attached below.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

# HG changeset patch
# User Guennadi Liakhovetski g.liakhovet...@gmx.de
# Date 1261648434 -3600
# Node ID 52e14d4799279a860fe158e8bf4f1993d6c6
# Parent  4506e2d541265bfa0c0fd5187c6a39d39a456559
document new pixel formats

Document all four 10-bit Bayer formats, 10-bit monochrome and a missing
8-bit Bayer formats.

Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de

diff -r 4506e2d54126 -r 52e14d479927 
linux/Documentation/DocBook/v4l/pixfmt-srggb10.xml
--- /dev/null   Thu Jan 01 00:00:00 1970 +
+++ b/linux/Documentation/DocBook/v4l/pixfmt-srggb10.xmlThu Dec 24 
10:53:54 2009 +0100
@@ -0,0 +1,90 @@
+refentry
+  refmeta
+   refentrytitleV4L2_PIX_FMT_SRGGB10 ('RG10'),
+V4L2_PIX_FMT_SGRBG10 ('BA10'),
+V4L2_PIX_FMT_SGBRG10 ('GB10'),
+V4L2_PIX_FMT_SBGGR10 ('BG10'),
+/refentrytitle
+   manvol;
+  /refmeta
+  refnamediv
+   refname 
id=V4L2-PIX-FMT-SRGGB10constantV4L2_PIX_FMT_SRGGB10/constant/refname
+   refname 
id=V4L2-PIX-FMT-SGRBG10constantV4L2_PIX_FMT_SGRBG10/constant/refname
+   refname 
id=V4L2-PIX-FMT-SGBRG10constantV4L2_PIX_FMT_SGBRG10/constant/refname
+   refname 
id=V4L2-PIX-FMT-SBGGR10constantV4L2_PIX_FMT_SBGGR10/constant/refname
+   refpurpose10-bit Bayer formats expanded to 16 bits/refpurpose
+  /refnamediv
+  refsect1
+   titleDescription/title
+
+   paraThe following four pixel formats are raw sRGB / Bayer formats with
+10 bits per colour. Each colour component is stored in a 16-bit word, with 6
+unused high bits filled with zeros. Each n-pixel row contains n/2 green samples
+and n/2 blue or red samples, with alternating red and blue rows. Bytes are
+stored in memory in little endian order. They are conventionally described
+as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
+formats/para
+
+example
+  titleconstantV4L2_PIX_FMT_SBGGR10/constant 4 times; 4
+pixel image/title
+
+  formalpara
+   titleByte Order./title
+   paraEach cell is one byte, high 6 bits in high bytes are 0.
+ informaltable frame=none
+   tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+   row
+ entrystartnbsp;+nbsp;0:/entry
+ entryBsubscript00low/subscript/entry
+ entryBsubscript00high/subscript/entry
+ entryGsubscript01low/subscript/entry
+ entryGsubscript01high/subscript/entry
+ entryBsubscript02low/subscript/entry
+ entryBsubscript02high/subscript/entry
+ entryGsubscript03low/subscript/entry
+ entryGsubscript03high/subscript/entry
+   /row
+   row
+ entrystartnbsp;+nbsp;8:/entry
+ entryGsubscript10low/subscript/entry
+ entryGsubscript10high/subscript/entry
+ entryRsubscript11low/subscript/entry
+ entryRsubscript11high/subscript/entry
+ entryGsubscript12low/subscript/entry
+ entryGsubscript12high/subscript/entry
+ entryRsubscript13low/subscript/entry
+ entryRsubscript13high/subscript/entry
+   /row
+   row
+ entrystartnbsp;+nbsp;16:/entry
+ entryBsubscript20low/subscript/entry
+ entryBsubscript20high/subscript/entry
+ entryGsubscript21low/subscript/entry
+ entryGsubscript21high/subscript/entry
+ entryBsubscript22low/subscript/entry
+ entryBsubscript22high/subscript/entry
+ entryGsubscript23low/subscript/entry
+ entryGsubscript23high/subscript/entry
+   /row
+   row
+ entrystartnbsp;+nbsp;24:/entry
+ entryGsubscript30low/subscript/entry
+ entryGsubscript30high/subscript/entry
+ entryRsubscript31low/subscript/entry
+

Re: [PULL] soc-camera and mediabus

2009-12-17 Thread Mauro Carvalho Chehab 
Hans Verkuil wrote:
 On Monday 14 December 2009 21:41:20 Guennadi Liakhovetski wrote:
 On Mon, 14 Dec 2009, Jonathan Cameron wrote:

 
 Having bridge-specific code in a sub-device driver will be a disaster in the
 long run. Well, we've seen what happens when you do it that way.

True.

 As far as I know the only soc-dependency left now is for bus configuration.
 Proposals were made some time ago and we should pick that up again and remove
 that last dependency.

We should really go on that direction. V4L i2c drivers shouldn't depend on
platform_data. I've experienced some very bad time fixing conflicts
and waiting for arch merges in order to try to avoid conflicts related
to platform_data changes that should be reflected into V4L drivers.

Even after migrating to -git, this problem won't solve, since the header
files that holds platform_data are highly volatile: on all kernel versions,
they had several changes, and the platform_data patch made while changing
the V4L code needs to be changed during the next merge window.

Due to that, I don't doubt that some earlier merges had broke git bisect
capabilities on those drivers that rely on the highly volatile platform_data
header files applied on arch tree and a separate patch applied on v4l tree.

It seems that we'll need to have some code that will be responsible to
handle arch/platform_data glue, to be merged in the same subsystem that
holds the *.h files, taking care on the required differences for drivers
that need platform_data to work, and a separate code to handle the V4L
functionalities.

In other words, drivers like soc_camera and omap core should be broken
internally into two separate files (or modules), one with V4L bits and
the other with arch/platform_data glue, where the second one should be
be maintained together with the corresponding arch code.

Cheers,
Mauro.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] soc-camera and mediabus

2009-12-14 Thread Mauro Carvalho Chehab 
Guennadi Liakhovetski wrote:
 Hi Mauro,
 
 At last soc-camera and mediabus lot for 2.6.33. Note, that one of this 
 patches adds new fourcc codes. A patch for their documentation will be 
 submitted immediately.
 
 Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb
 
 for the following 30 changesets:
 
 01/30: tw9910: The driver can also handle revision 1 of the chip
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f1e67c4ca734
 
 02/30: soc-camera: remove no longer needed struct members
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ac42a43c9d3c
 
 03/30: v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in 
 soc-camera
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f3ce29815a19
 
 04/30: soc-camera: fix multi-line comment coding style
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=e893641bb109
 
 05/30: sh_mobile_ceu_camera: do not mark host occupied, when adding a client 
 fails
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=9505453960fb
 
 06/30: v4l: Add a 10-bit monochrome and missing 8- and 10-bit Bayer fourcc 
 codes
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=fc70aabadc59
 
 07/30: soc-camera: add a private field to struct soc_camera_link
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8144ecd97132
 
 08/30: Subject: kernel-sync for arch/sh/boards/mach-ap325rxa/setup.c
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ea27f790755c
 
 09/30: soc-camera: switch drivers and platforms to use .priv in struct 
 soc_camera_link
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=54707961f633
 
 10/30: sh_mobile_ceu_camera: document the scaling and cropping algorithm
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f490679b43c3
 
 11/30: tw9910: Add revision control
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4d27f0bec0f3
 
 12/30: tw9910: simplify chip ID calculation
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=b919641bdf84
 
 13/30: tw9910: Tri-state pins when idle
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=bb97c53db3c0
 
 14/30: tw9910: Add power control
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2d8774ea617f
 
 15/30: tw9910: tw9910_set_hsync clean up
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=669d0a9ca121
 
 16/30: tw9910: Add revision control to tw9910_set_hsync
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=d3619f5f5679
 
 17/30: v4l: add a media-bus API for configuring v4l2 subdev pixel and frame 
 formats
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2c60bd900a7a
 
 18/30: soc-camera: convert to the new mediabus API
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2a8289e3de7b
 
 19/30: Subject: kernel-sync for arch/sh/boards/mach-kfr2r09/setup.c
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4e1dcff622e0
 
 20/30: rj54n1cb0c: Add cropping, auto white balance, restrict sizes, add 
 platform data
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c2ede215a03c
 
 21/30: mt9t031: make the use of the soc-camera client API optional
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be8b7a9252d8
 
 22/30: sh_mobile_ceu: Add V4L2_FIELD_INTERLACED_BT/TB support
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=1a36ae75bdb1
 
 23/30: tw9910: use V4L2_FIELD_INTERLACED_BT
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be43ab8c8490
 
 24/30: sh_mobile_ceu_camera: Add support for sync polarity selection
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=596e9b685f9b
 
 25/30: tw9910: modify V/H outpit pin setting to use VALID
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8e7ca505b942
 
 26/30: tw9910: modify output format
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a42544f649b1
 
 27/30: tw9910: remove cropping
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c141cc75045a
 
 28/30: tw9910: Add sync polarity support
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=750376b279e0
 
 29/30: soc-camera: Add mt9t112 camera driver
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=37cdd4e97937
 
 30/30: sh_mobile_ceu_camera: Remove frame size page alignment
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8da6f7deee9f
 
 
  a/linux/arch/sh/boards/board-ap325rxa.c|  606 --
  b/linux/Documentation/video4linux/sh_mobile_ceu_camera.txt |  157 +
  b/linux/arch/sh/boards/mach-ap325rxa/setup.c   |  657 +++
  b/linux/arch/sh/boards/mach-kfr2r09/setup.c|  622 ++
  b/linux/drivers/media/video/mt9t112.c  | 1177 
 +
  b/linux/drivers/media/video/soc_mediabus.c |  157 +

Re: [PULL] soc-camera and mediabus

2009-12-14 Thread Guennadi Liakhovetski 
On Mon, 14 Dec 2009, Mauro Carvalho Chehab wrote:

 Guennadi Liakhovetski wrote:
  Hi Mauro,
  
  At last soc-camera and mediabus lot for 2.6.33. Note, that one of this 
  patches adds new fourcc codes. A patch for their documentation will be 
  submitted immediately.
  
  Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb
  
  for the following 30 changesets:
  
  01/30: tw9910: The driver can also handle revision 1 of the chip
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f1e67c4ca734
  
  02/30: soc-camera: remove no longer needed struct members
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ac42a43c9d3c
  
  03/30: v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in 
  soc-camera
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f3ce29815a19
  
  04/30: soc-camera: fix multi-line comment coding style
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=e893641bb109
  
  05/30: sh_mobile_ceu_camera: do not mark host occupied, when adding a 
  client fails
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=9505453960fb
  
  06/30: v4l: Add a 10-bit monochrome and missing 8- and 10-bit Bayer fourcc 
  codes
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=fc70aabadc59
  
  07/30: soc-camera: add a private field to struct soc_camera_link
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8144ecd97132
  
  08/30: Subject: kernel-sync for arch/sh/boards/mach-ap325rxa/setup.c
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ea27f790755c
  
  09/30: soc-camera: switch drivers and platforms to use .priv in struct 
  soc_camera_link
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=54707961f633
  
  10/30: sh_mobile_ceu_camera: document the scaling and cropping algorithm
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f490679b43c3
  
  11/30: tw9910: Add revision control
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4d27f0bec0f3
  
  12/30: tw9910: simplify chip ID calculation
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=b919641bdf84
  
  13/30: tw9910: Tri-state pins when idle
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=bb97c53db3c0
  
  14/30: tw9910: Add power control
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2d8774ea617f
  
  15/30: tw9910: tw9910_set_hsync clean up
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=669d0a9ca121
  
  16/30: tw9910: Add revision control to tw9910_set_hsync
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=d3619f5f5679
  
  17/30: v4l: add a media-bus API for configuring v4l2 subdev pixel and frame 
  formats
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2c60bd900a7a
  
  18/30: soc-camera: convert to the new mediabus API
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2a8289e3de7b
  
  19/30: Subject: kernel-sync for arch/sh/boards/mach-kfr2r09/setup.c
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4e1dcff622e0
  
  20/30: rj54n1cb0c: Add cropping, auto white balance, restrict sizes, add 
  platform data
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c2ede215a03c
  
  21/30: mt9t031: make the use of the soc-camera client API optional
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be8b7a9252d8
  
  22/30: sh_mobile_ceu: Add V4L2_FIELD_INTERLACED_BT/TB support
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=1a36ae75bdb1
  
  23/30: tw9910: use V4L2_FIELD_INTERLACED_BT
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be43ab8c8490
  
  24/30: sh_mobile_ceu_camera: Add support for sync polarity selection
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=596e9b685f9b
  
  25/30: tw9910: modify V/H outpit pin setting to use VALID
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8e7ca505b942
  
  26/30: tw9910: modify output format
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a42544f649b1
  
  27/30: tw9910: remove cropping
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c141cc75045a
  
  28/30: tw9910: Add sync polarity support
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=750376b279e0
  
  29/30: soc-camera: Add mt9t112 camera driver
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=37cdd4e97937
  
  30/30: sh_mobile_ceu_camera: Remove frame size page alignment
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8da6f7deee9f
  
  
   a/linux/arch/sh/boards/board-ap325rxa.c|  606 --
   b/linux/Documentation/video4linux/sh_mobile_ceu_camera.txt |  157 +
   b/linux/arch/sh/boards/mach-ap325rxa/setup.c   |  657 +++
   b/linux/arch/sh/boards/mach-kfr2r09/setup.c|  622 ++

Re: [PULL] soc-camera and mediabus

2009-12-14 Thread Jonathan Cameron 
Hi All,

 3) it would be interesting to patch the other sensor drivers to be compatible
with soc_camera (mt9v011/ov7670);
 
 Well, this could be done, yes, but does it make sense to do this blindly 
 without any hardware to test? I would rather add such conversions on a 
 one-by-one basis as need arises.
 
I'm working on the ov7670. I've added the media bus stuff to what I've
previously posted but I haven't tested as yet.  For reference, a quick and dirty
cut of the patch is below.  Some thought is needed on how to deal with the 
sections
that currently need to be different for the soc-camera and non soc camera uses.
(mainly the registration code in probe).

On another note, does anyone have an objection to making the set_bus_param
function optional?   At the moment we are adding null functions for those
devices that can't actually change anything which seems a little pointless.

Jonathan


diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
index 0e2184e..e57c3b5 100644
--- a/drivers/media/video/ov7670.c
+++ b/drivers/media/video/ov7670.c
@@ -18,6 +18,7 @@
 #include media/v4l2-device.h
 #include media/v4l2-chip-ident.h
 #include media/v4l2-i2c-drv.h
+#include media/soc_camera.h
 
 
 MODULE_AUTHOR(Jonathan Corbet cor...@lwn.net);
@@ -545,7 +546,7 @@ static struct ov7670_format_struct {
.bpp= 1
},
 };
-#define N_OV7670_FMTS ARRAY_SIZE(ov7670_formats)
+
 
 
 /*
@@ -668,52 +669,37 @@ static int ov7670_set_hw(struct v4l2_subdev *sd, int 
hstart, int hstop,
return ret;
 }
 
+static enum v4l2_mbus_pixelcode ov7670_codes[] = {
+   V4L2_MBUS_FMT_YUYV8_2X8,
+   V4L2_MBUS_FMT_RGB565_2X8_LE,
+};
 
-static int ov7670_enum_fmt(struct v4l2_subdev *sd, struct v4l2_fmtdesc *fmt)
+static int ov7670_enum_fmt(struct v4l2_subdev *sd, int index, enum 
v4l2_mbus_pixelcode *code)
 {
-   struct ov7670_format_struct *ofmt;
-
-   if (fmt-index = N_OV7670_FMTS)
+   if (index = ARRAY_SIZE(ov7670_codes))
return -EINVAL;
 
-   ofmt = ov7670_formats + fmt-index;
-   fmt-flags = 0;
-   strcpy(fmt-description, ofmt-desc);
-   fmt-pixelformat = ofmt-pixelformat;
+   *code = ov7670_codes[index];
return 0;
 }
 
 
 static int ov7670_try_fmt_internal(struct v4l2_subdev *sd,
-   struct v4l2_format *fmt,
-   struct ov7670_format_struct **ret_fmt,
-   struct ov7670_win_size **ret_wsize)
+  struct v4l2_mbus_framefmt *mf,
+  struct ov7670_format_struct **ret_fmt,
+  struct ov7670_win_size **ret_wsize)
 {
int index;
struct ov7670_win_size *wsize;
-   struct v4l2_pix_format *pix = fmt-fmt.pix;
 
-   for (index = 0; index  N_OV7670_FMTS; index++)
-   if (ov7670_formats[index].pixelformat == pix-pixelformat)
-   break;
-   if (index = N_OV7670_FMTS) {
-   /* default to first format */
-   index = 0;
-   pix-pixelformat = ov7670_formats[0].pixelformat;
-   }
-   if (ret_fmt != NULL)
-   *ret_fmt = ov7670_formats + index;
-   /*
-* Fields: the OV devices claim to be progressive.
-*/
-   pix-field = V4L2_FIELD_NONE;
+   mf-field = V4L2_FIELD_NONE;
/*
 * Round requested image size down to the nearest
 * we support, but not below the smallest.
 */
for (wsize = ov7670_win_sizes; wsize  ov7670_win_sizes + N_WIN_SIZES;
 wsize++)
-   if (pix-width = wsize-width  pix-height = wsize-height)
+   if ( mf-width = wsize-width  mf-height = wsize-height)
break;
if (wsize = ov7670_win_sizes + N_WIN_SIZES)
wsize--;   /* Take the smallest one */
@@ -722,22 +708,34 @@ static int ov7670_try_fmt_internal(struct v4l2_subdev *sd,
/*
 * Note the size we'll actually handle.
 */
-   pix-width = wsize-width;
-   pix-height = wsize-height;
-   pix-bytesperline = pix-width*ov7670_formats[index].bpp;
-   pix-sizeimage = pix-height*pix-bytesperline;
+   mf-width = wsize-width;
+   mf-height = wsize-height;
+   switch (mf-code) {
+   case V4L2_MBUS_FMT_RGB565_2X8_LE:
+   mf-colorspace = V4L2_COLORSPACE_SRGB;
+   if (ret_fmt != NULL)
+   *ret_fmt = ov7670_formats + 2;
+   break;
+   default:
+   mf-code = V4L2_MBUS_FMT_YUYV8_2X8;
+   case V4L2_MBUS_FMT_YUYV8_2X8:
+   mf-colorspace = V4L2_COLORSPACE_JPEG;
+   if (ret_fmt != NULL)
+   *ret_fmt = ov7670_formats;
+   break;
+   }
return 0;
 }
 
-static int ov7670_try_fmt(struct v4l2_subdev *sd, struct v4l2_format *fmt)
+static int ov7670_try_fmt(struct v4l2_subdev *sd, struct v4l2_mbus_framefmt 
*mf)
 {
-   return

Re: [PULL] soc-camera and mediabus

2009-12-14 Thread Mauro Carvalho Chehab 
Guennadi Liakhovetski wrote:
 On Mon, 14 Dec 2009, Mauro Carvalho Chehab wrote:
 
 Guennadi Liakhovetski wrote:
 Hi Mauro,

 At last soc-camera and mediabus lot for 2.6.33. Note, that one of this 
 patches adds new fourcc codes. A patch for their documentation will be 
 submitted immediately.

 Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb

 for the following 30 changesets:

 01/30: tw9910: The driver can also handle revision 1 of the chip
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f1e67c4ca734

 02/30: soc-camera: remove no longer needed struct members
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ac42a43c9d3c

 03/30: v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in 
 soc-camera
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f3ce29815a19

 04/30: soc-camera: fix multi-line comment coding style
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=e893641bb109

 05/30: sh_mobile_ceu_camera: do not mark host occupied, when adding a 
 client fails
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=9505453960fb

 06/30: v4l: Add a 10-bit monochrome and missing 8- and 10-bit Bayer fourcc 
 codes
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=fc70aabadc59

 07/30: soc-camera: add a private field to struct soc_camera_link
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8144ecd97132

 08/30: Subject: kernel-sync for arch/sh/boards/mach-ap325rxa/setup.c
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ea27f790755c

 09/30: soc-camera: switch drivers and platforms to use .priv in struct 
 soc_camera_link
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=54707961f633

 10/30: sh_mobile_ceu_camera: document the scaling and cropping algorithm
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f490679b43c3

 11/30: tw9910: Add revision control
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4d27f0bec0f3

 12/30: tw9910: simplify chip ID calculation
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=b919641bdf84

 13/30: tw9910: Tri-state pins when idle
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=bb97c53db3c0

 14/30: tw9910: Add power control
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2d8774ea617f

 15/30: tw9910: tw9910_set_hsync clean up
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=669d0a9ca121

 16/30: tw9910: Add revision control to tw9910_set_hsync
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=d3619f5f5679

 17/30: v4l: add a media-bus API for configuring v4l2 subdev pixel and frame 
 formats
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2c60bd900a7a

 18/30: soc-camera: convert to the new mediabus API
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2a8289e3de7b

 19/30: Subject: kernel-sync for arch/sh/boards/mach-kfr2r09/setup.c
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4e1dcff622e0

 20/30: rj54n1cb0c: Add cropping, auto white balance, restrict sizes, add 
 platform data
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c2ede215a03c

 21/30: mt9t031: make the use of the soc-camera client API optional
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be8b7a9252d8

 22/30: sh_mobile_ceu: Add V4L2_FIELD_INTERLACED_BT/TB support
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=1a36ae75bdb1

 23/30: tw9910: use V4L2_FIELD_INTERLACED_BT
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be43ab8c8490

 24/30: sh_mobile_ceu_camera: Add support for sync polarity selection
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=596e9b685f9b

 25/30: tw9910: modify V/H outpit pin setting to use VALID
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8e7ca505b942

 26/30: tw9910: modify output format
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a42544f649b1

 27/30: tw9910: remove cropping
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c141cc75045a

 28/30: tw9910: Add sync polarity support
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=750376b279e0

 29/30: soc-camera: Add mt9t112 camera driver
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=37cdd4e97937

 30/30: sh_mobile_ceu_camera: Remove frame size page alignment
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8da6f7deee9f


  a/linux/arch/sh/boards/board-ap325rxa.c|  606 --
  b/linux/Documentation/video4linux/sh_mobile_ceu_camera.txt |  157 +
  b/linux/arch/sh/boards/mach-ap325rxa/setup.c   |  657 +++
  b/linux/arch/sh/boards/mach-kfr2r09/setup.c|  622 ++
  b/linux/drivers/media/video/mt9t112.c  | 1177 
 +

Re: [PULL] soc-camera and mediabus

2009-12-14 Thread Mauro Carvalho Chehab 
Jonathan Cameron wrote:
 Hi All,
 
 3) it would be interesting to patch the other sensor drivers to be 
 compatible
with soc_camera (mt9v011/ov7670);
 Well, this could be done, yes, but does it make sense to do this blindly 
 without any hardware to test? I would rather add such conversions on a 
 one-by-one basis as need arises.

 I'm working on the ov7670. I've added the media bus stuff to what I've
 previously posted but I haven't tested as yet.  For reference, a quick and 
 dirty
 cut of the patch is below.  Some thought is needed on how to deal with the 
 sections
 that currently need to be different for the soc-camera and non soc camera 
 uses.
 (mainly the registration code in probe).

True. Couldn't this be a library that handles the code difference between
soc-camera platform-data bits and normal subdev?

Even better: couldn't this code be handled by soc_camera core and just use
subdev interface for both cases?

After finishing the patch, please ping me. I have here an OLPC with ov7670 where
I can test if the new code doesn't break the cafe_ccic driver. You'll probably
need to touch on it, as it will need to use the new mediabus API to talk with 
ov7670.

 On another note, does anyone have an objection to making the set_bus_param
 function optional?   At the moment we are adding null functions for those
 devices that can't actually change anything which seems a little pointless.

Agreed.

Cheers,
Mauro.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] soc-camera and mediabus

2009-12-14 Thread Guennadi Liakhovetski 
On Mon, 14 Dec 2009, Jonathan Cameron wrote:

 Hi All,
 
  3) it would be interesting to patch the other sensor drivers to be 
  compatible
 with soc_camera (mt9v011/ov7670);
  
  Well, this could be done, yes, but does it make sense to do this blindly 
  without any hardware to test? I would rather add such conversions on a 
  one-by-one basis as need arises.
  
 I'm working on the ov7670. I've added the media bus stuff to what I've
 previously posted but I haven't tested as yet.  For reference, a quick and 
 dirty
 cut of the patch is below.  Some thought is needed on how to deal with the 
 sections
 that currently need to be different for the soc-camera and non soc camera 
 uses.
 (mainly the registration code in probe).

Look at my patch for mt9t031. First you do not have to fail if 
client-dev.platform_data == NULL. You have to look at the bridge driver, 
that's currently working with ov7670. If it is not setting platform_data, 
you can use it to detect whether you're in soc-camera environment or not. 
Otherwise, if the bridge driver were also using that pointer, we would 
have to come up with a ov7670-specific struct to be linked from that 
pointer. I was actually thinking about a way to pass soc-camera data to 
client drivers in a way, that would not imped non soc-camera use. So, how 
about:


I soc-camera environment

1. platform defines a

static struct ov7670_platform_data ov7670 = {
.link = ov7670_link,
};

2. and a

static struct soc_camera_link ov7670_link = {
.client_data = ov7670,
};

3. soc-camera core gets ov7670_link in its probe, same as this is done 
now, then it does

icl-icd = icd;
icl-board_info-platform_data = icl-client_data;

subdev = v4l2_i2c_new_subdev_board(ici-v4l2_dev, adap,
icl-module_name, icl-board_info, NULL);

4. ov7670 probe is called with client platform data pointing to its own 
data:

static int ov7670_probe(struct i2c_client *client,
const struct i2c_device_id *did)
{
struct ov7670_platform_data *pdata = client-dev.platform_data;
struct soc_camera_link *icl = pdata-link;
struct soc_camera_device *icd;

if (icl)
icd = icl-icd;


II Non soc-camera environment

1. the bridge driver fills in sensor data and does

struct ov7670_platform_data *ov7670_pdata = kzalloc(sizeof(*pdata));

ov7670_pdata-... = ...;
board_info-platform_data = ov7670_pdata;

subdev = v4l2_i2c_new_subdev_board(v4l2_dev, adap,
module_name, board_info, NULL);

2. ov7670_probe() gets called and finds its data as above, but without an 
soc-camera link this time.


The advantage of the above is, that each client driver is free to define 
its own platform data struct, and for soc-camera it only has to provide 
one pointer in it. The ugly side is the cross-referencing between I.1. and 
I.2. above.

Alternatively we could agree, that all client drivers get in their i2c 
client platform data a standard struct with only pointers in it to client 
data and to various bridging models:

struct v4l2_client {
void *client;
struct soc_camera_link *icl;
struct int_device_link *int;
...
};

or a bit more hidden

struct v4l2_client {
void *client;
void *bridge_data;
enum V4L2_BRIDGE_TYPE bridge_type;
};

 On another note, does anyone have an objection to making the set_bus_param
 function optional?   At the moment we are adding null functions for those
 devices that can't actually change anything which seems a little pointless.

Yes, it can.

 
 Jonathan
 
 
 diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
 index 0e2184e..e57c3b5 100644
 --- a/drivers/media/video/ov7670.c
 +++ b/drivers/media/video/ov7670.c
 @@ -18,6 +18,7 @@
  #include media/v4l2-device.h
  #include media/v4l2-chip-ident.h
  #include media/v4l2-i2c-drv.h
 +#include media/soc_camera.h
  
  
  MODULE_AUTHOR(Jonathan Corbet cor...@lwn.net);
 @@ -545,7 +546,7 @@ static struct ov7670_format_struct {
   .bpp= 1
   },
  };
 -#define N_OV7670_FMTS ARRAY_SIZE(ov7670_formats)
 +
  
  
  /*
 @@ -668,52 +669,37 @@ static int ov7670_set_hw(struct v4l2_subdev *sd, int 
 hstart, int hstop,
   return ret;
  }
  
 +static enum v4l2_mbus_pixelcode ov7670_codes[] = {
 + V4L2_MBUS_FMT_YUYV8_2X8,
 + V4L2_MBUS_FMT_RGB565_2X8_LE,
 +};
  
 -static int ov7670_enum_fmt(struct v4l2_subdev *sd, struct v4l2_fmtdesc *fmt)
 +static int ov7670_enum_fmt(struct v4l2_subdev *sd, int index, enum 
 v4l2_mbus_pixelcode *code)
  {
 - struct ov7670_format_struct *ofmt;
 -
 - if (fmt-index = N_OV7670_FMTS)
 + if (index = ARRAY_SIZE(ov7670_codes))
   return -EINVAL;
  
 - ofmt = ov7670_formats + fmt-index;
 - fmt-flags = 0;
 - strcpy(fmt-description, ofmt-desc);
 - fmt-pixelformat = ofmt-pixelformat;
 +

Re: [PULL] soc-camera and mediabus

2009-12-14 Thread Hans Verkuil 
On Monday 14 December 2009 21:41:20 Guennadi Liakhovetski wrote:
 On Mon, 14 Dec 2009, Jonathan Cameron wrote:
 
  Hi All,
  
   3) it would be interesting to patch the other sensor drivers to be 
   compatible
  with soc_camera (mt9v011/ov7670);
   
   Well, this could be done, yes, but does it make sense to do this blindly 
   without any hardware to test? I would rather add such conversions on a 
   one-by-one basis as need arises.
   
  I'm working on the ov7670. I've added the media bus stuff to what I've
  previously posted but I haven't tested as yet.  For reference, a quick and 
  dirty
  cut of the patch is below.  Some thought is needed on how to deal with the 
  sections
  that currently need to be different for the soc-camera and non soc camera 
  uses.
  (mainly the registration code in probe).
 
 Look at my patch for mt9t031. First you do not have to fail if 
 client-dev.platform_data == NULL. You have to look at the bridge driver, 
 that's currently working with ov7670. If it is not setting platform_data, 
 you can use it to detect whether you're in soc-camera environment or not. 
 Otherwise, if the bridge driver were also using that pointer, we would 
 have to come up with a ov7670-specific struct to be linked from that 
 pointer. I was actually thinking about a way to pass soc-camera data to 
 client drivers in a way, that would not imped non soc-camera use. So, how 
 about:
 
 
   I soc-camera environment
 
 1. platform defines a
 
 static struct ov7670_platform_data ov7670 = {
   .link = ov7670_link,
 };
 
 2. and a
 
 static struct soc_camera_link ov7670_link = {
   .client_data = ov7670,
 };
 
 3. soc-camera core gets ov7670_link in its probe, same as this is done 
 now, then it does
 
   icl-icd = icd;
   icl-board_info-platform_data = icl-client_data;
 
   subdev = v4l2_i2c_new_subdev_board(ici-v4l2_dev, adap,
   icl-module_name, icl-board_info, NULL);
 
 4. ov7670 probe is called with client platform data pointing to its own 
 data:
 
 static int ov7670_probe(struct i2c_client *client,
   const struct i2c_device_id *did)
 {
   struct ov7670_platform_data *pdata = client-dev.platform_data;
   struct soc_camera_link *icl = pdata-link;
   struct soc_camera_device *icd;
 
   if (icl)
   icd = icl-icd;
 
 
   II Non soc-camera environment
 
 1. the bridge driver fills in sensor data and does
 
   struct ov7670_platform_data *ov7670_pdata = kzalloc(sizeof(*pdata));
 
   ov7670_pdata-... = ...;
   board_info-platform_data = ov7670_pdata;
 
   subdev = v4l2_i2c_new_subdev_board(v4l2_dev, adap,
   module_name, board_info, NULL);
 
 2. ov7670_probe() gets called and finds its data as above, but without an 
 soc-camera link this time.
 
 
 The advantage of the above is, that each client driver is free to define 
 its own platform data struct, and for soc-camera it only has to provide 
 one pointer in it. The ugly side is the cross-referencing between I.1. and 
 I.2. above.
 
 Alternatively we could agree, that all client drivers get in their i2c 
 client platform data a standard struct with only pointers in it to client 
 data and to various bridging models:
 
 struct v4l2_client {
   void *client;
   struct soc_camera_link *icl;
   struct int_device_link *int;
   ...
 };
 
 or a bit more hidden
 
 struct v4l2_client {
   void *client;
   void *bridge_data;
   enum V4L2_BRIDGE_TYPE bridge_type;
 };

Before this goes too far let me just say that I will NAK any attempt in this
direction. Subdevice drivers must eventually be completely independent from
bridge driver. The same driver should work out of the box for soc-camera,
gspca, omap3, davinci, saa7134 and whatever other bridge driver is out there.

Having bridge-specific code in a sub-device driver will be a disaster in the
long run. Well, we've seen what happens when you do it that way.

As far as I know the only soc-dependency left now is for bus configuration.
Proposals were made some time ago and we should pick that up again and remove
that last dependency.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html