date:20160308

cron job: media_tree daily build: OK

2016-03-08 Thread Hans Verkuil

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Wed Mar  9 04:00:19 CET 2016
git branch: test
git hash:   de08b5a8be0df1eb7c796b0fe6b30cf1d03d14a6
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-51-ga53cea2
smatch version: v0.5.0-3228-g5cf65ab
host hardware:  x86_64
host os:4.4.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-4.4-i686: OK
linux-4.5-rc1-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: OK
linux-4.4-x86_64: OK
linux-4.5-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
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

[PATCH] Revert "[media] au0828: use v4l2_mc_create_media_graph()"

2016-03-08 Thread Shuah Khan

This reverts commit 9822f4173f84cb7c592edb5e1478b7903f69d018.
This commit breaks au0828_enable_handler() logic to find the tuner.
Audio, Video, and Digital applications are broken and fail to start
streaming with tuner busy error even when tuner is free.

Signed-off-by: Shuah Khan 
---
 drivers/media/usb/au0828/au0828-video.c | 103 ++--
 drivers/media/v4l2-core/v4l2-mc.c   |  21 +--
 2 files changed, 99 insertions(+), 25 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-video.c 
b/drivers/media/usb/au0828/au0828-video.c
index 13f6dab..5f7c8be 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -35,7 +35,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -653,6 +652,102 @@ void au0828_usb_v4l2_media_release(struct au0828_dev *dev)
 #endif
 }
 
+static int au0828_create_media_graph(struct au0828_dev *dev)
+{
+#ifdef CONFIG_MEDIA_CONTROLLER
+   struct media_device *mdev = dev->media_dev;
+   struct media_entity *entity;
+   struct media_entity *tuner = NULL, *decoder = NULL, *demod = NULL;
+   int i, ret;
+
+   if (!mdev)
+   return 0;
+
+   media_device_for_each_entity(entity, mdev) {
+   switch (entity->function) {
+   case MEDIA_ENT_F_TUNER:
+   tuner = entity;
+   break;
+   case MEDIA_ENT_F_ATV_DECODER:
+   decoder = entity;
+   break;
+   case MEDIA_ENT_F_DTV_DEMOD:
+   demod = entity;
+   break;
+   }
+   }
+
+   /* Analog setup, using tuner as a link */
+
+   /* Something bad happened! */
+   if (!decoder)
+   return -EINVAL;
+
+   if (tuner) {
+   dev->tuner = tuner;
+   ret = media_create_pad_link(tuner, TUNER_PAD_OUTPUT,
+   decoder, DEMOD_PAD_IF_INPUT, 0);
+   if (ret)
+   return ret;
+   }
+   ret = media_create_pad_link(decoder, DEMOD_PAD_VID_OUT,
+   >vdev.entity, 0,
+   MEDIA_LNK_FL_ENABLED);
+   if (ret)
+   return ret;
+   ret = media_create_pad_link(decoder, DEMOD_PAD_VBI_OUT,
+   >vbi_dev.entity, 0,
+   MEDIA_LNK_FL_ENABLED);
+   if (ret)
+   return ret;
+
+   for (i = 0; i < AU0828_MAX_INPUT; i++) {
+   struct media_entity *ent = >input_ent[i];
+
+   switch (AUVI_INPUT(i).type) {
+   case AU0828_VMUX_UNDEFINED:
+   break;
+   case AU0828_VMUX_CABLE:
+   case AU0828_VMUX_TELEVISION:
+   case AU0828_VMUX_DVB:
+   if (!tuner)
+   break;
+
+   ret = media_create_pad_link(ent, 0, tuner,
+   TUNER_PAD_RF_INPUT,
+   MEDIA_LNK_FL_ENABLED);
+   if (ret)
+   return ret;
+   break;
+   case AU0828_VMUX_COMPOSITE:
+   case AU0828_VMUX_SVIDEO:
+   /* FIXME: fix the decoder PAD */
+   ret = media_create_pad_link(ent, 0, decoder,
+   DEMOD_PAD_IF_INPUT, 0);
+   if (ret)
+   return ret;
+   break;
+   }
+   }
+
+   /*
+* Disable tuner to demod link to avoid disable step
+* when tuner is requested by video or audio
+   */
+   if (tuner && demod) {
+   struct media_link *link;
+
+   list_for_each_entry(link, >links, list) {
+   if (link->sink->entity == demod &&
+   link->source->entity == tuner) {
+   media_entity_setup_link(link, 0);
+   }
+   }
+   }
+#endif
+   return 0;
+}
+
 static void au0828_usb_v4l2_release(struct v4l2_device *v4l2_dev)
 {
struct au0828_dev *dev =
@@ -2039,16 +2134,14 @@ int au0828_analog_register(struct au0828_dev *dev,
ret = -ENODEV;
goto err_reg_vbi_dev;
}
-
-#ifdef CONFIG_MEDIA_CONTROLLER
-   retval = v4l2_mc_create_media_graph(dev->media_dev);
+   retval = au0828_create_media_graph(dev);
if (retval) {
pr_err("%s() au0282_dev_register failed to create graph\n",
__func__);
ret = -ENODEV;
goto err_reg_vbi_dev;
}
-#endif
+
 
dprintk(1, "%s completed!\n", __func__);
 
diff --git

Re: i.mx6 camera interface (CSI) and mainline kernel

2016-03-08 Thread Steve Longerbeam

On 03/07/2016 08:19 AM, Tim Harvey wrote:
> On Thu, Mar 3, 2016 at 9:45 AM, Steve Longerbeam
>  wrote:
>> Hi Philippe,
>>
>> On 03/03/2016 12:36 AM, Philippe De Muyter wrote:
>>> Just to be sure : do you mean  https://github.com/slongerbeam/mediatree.git
>>> or something else ?
>> Sorry, yes I meant https://github.com/slongerbeam/mediatree.git.
>>
> So far I have retested video capture with the SabreAuto/ADV7180 and
> the SabreSD/OV5640-mipi-csi2, and video capture is working fine on
> those platforms.
>
> There is also a mem2mem that should work fine, but haven't tested yet.
>
> I removed camera preview support. At Mentor Graphics we have made
> quite a few changes to ipu-v3 driver to allow camera preview to initialize
> and control an overlay display plane independently of imx-drm, by adding
> a subsystem independent ipu-plane sub-unit. Note we also have a video
> output overlay driver that also makes use of ipu-plane. But those changes 
> are
> extensive and touch imx-drm as well as ipu-v3, so I am leaving camera 
> preview
> and the output overlay driver out (in fact, camera preview is not of much
> utility so I probably won't bring it back in upstream version).
>
> The video capture driver is not quite ready for upstream review yet. It 
> still:
>
> - uses the old cropping APIs but should move forward to selection APIs.
>
> - uses custom sensor subdev drivers for ADV7180 and OV564x. Still
>   need to switch to upstream subdevs.
>>> Is it only a problem of those sensor drivers (which exact files ?) or
>>> is it a problem of the capture driver itself ?
>> The camera interface driver (drivers/staging/media/imx6/capture/mx6-camif.c)
>> is binding to these subdevs:
>>
>> drivers/staging/media/imx6/capture/adv7180.c
>> drivers/staging/media/imx6/capture/ov5642.c
>> drivers/staging/media/imx6/capture/ov5640-mipi.c
>>
>> But instead should use the subdevs under drivers/media/i2c, specifically:
>>
>> drivers/media/i2c/adv7180.c (and adding whatever standard subdev features
>> the imx6 interface driver requires).
>>
>> There is a drivers/media/i2c/soc_camera/ov5642.c, but there is no mipi-csi2
>> capable subdev for the ov5640 with the mipi-csi2 interface, so that would 
>> have
>> to be created.
>>
> Steve,
>
> I've built your mx6-media-staging branch and added device-tree config
> for the Gateworks Ventana boards which have an on-board ADV7180 and it
> works great. I've tested it capturing frames via v4l2-ctl as well as
> gstreamer.
>
> Please let me know what kind of testing you need. I would love to see
> this get mainlined!
>


Hi Tim, good to hear it works for you on the Ventana boards.

I've just pushed some more commits to the mx6-media-staging branch that
get the drivers/media/i2c/adv7180.c subdev working with the imx6 capture
backend. Images look perfect when switching to UYVY8_2X8 mbus code instead
of YUYV8_2X8. But I'm holding off on that change because this subdev is used
by Renesas targets and would likely corrupt captured images for those
targets. But I believe UYVY is the correct transmit order according to the
BT.656 standard.

Another thing that should also be changed in drivers/media/i2c/adv7180.c
is the field type. It should be V4L2_FIELD_SEQ_TB for NTSC and V4L2_FIELD_SEQ_BT
for PAL.

Steve


--
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: HVR-850 2040:b140 fails to initialize

2016-03-08 Thread Devin Heitmueller

> Appreciate some advice.

Return it and get an HVR-950q.  This has been a known issue for more
than 5 years and nobody's gotten around to fixing it (largely because
of limitations inside the V4L2 framework).

Devin
(a.k.a. the guy who added the original support for the HVR-850).

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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

HVR-850 2040:b140 fails to initialize

2016-03-08 Thread Scott Robinson

I am trying to above device with kernel 4.1.13-100.fc21.x86_64.

kernel: usb 2-2: New USB device found, idVendor=2040, idProduct=b140
kernel: usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
kernel: usb 2-2: Product: Hauppauge Device
kernel: usb 2-2: Manufacturer: Hauppauge
kernel: usb 2-2: SerialNumber: 4035391470
kernel: [5789620.592751] cx231xx 2-2:1.1: New device Hauppauge
Hauppauge Device @ 480 Mbps (2040:b140) with 7 interfaces
kernel: [5789620.592959] cx231xx 2-2:1.1: Identified as Hauppauge
EXETER (card=8)
kernel: cx231xx 2-2:1.1: New device Hauppauge Hauppauge Device @ 480
Mbps (2040:b140) with 7 interfaces
kernel: cx231xx 2-2:1.1: Identified as Hauppauge EXETER (card=8)
kernel: [5789620.593974] i2c i2c-8: Added multiplexed i2c bus 10
kernel: [5789620.594031] i2c i2c-8: Added multiplexed i2c bus 11
kernel: i2c i2c-8: Added multiplexed i2c bus 10
kernel: i2c i2c-8: Added multiplexed i2c bus 11
kernel: [5789620.755944] cx25840 7-0044: cx23102 A/V decoder found @
0x88 (cx231xx #0-0)
kernel: cx25840 7-0044: cx23102 A/V decoder found @ 0x88 (cx231xx #0-0)
kernel: [5789622.682697] cx25840 7-0044: loaded
v4l-cx231xx-avcore-01.fw firmware (16382 bytes)
kernel: cx25840 7-0044: loaded v4l-cx231xx-avcore-01.fw firmware (16382 bytes)
kernel: [5789622.719317] Chip ID is not zero. It is not a TEA5767
kernel: [5789622.719327] tuner 10-0060: Tuner -1 found with type(s) Radio TV.
kernel: [5789622.719349] tda18271 10-0060: creating new instance
kernel: Chip ID is not zero. It is not a TEA5767
kernel: tuner 10-0060: Tuner -1 found with type(s) Radio TV.
kernel: tda18271 10-0060: creating new instance
kernel: [5789622.721440] Unknown device (110) detected @ 10-0060,
device not supported.
kernel: [5789622.721445] tda18271_attach: [10-0060|M] error -22 on line 1285
kernel: [5789622.721447] tda18271 10-0060: destroying instance
kernel: Unknown device (110) detected @ 10-0060, device not supported.
kernel: tda18271_attach: [10-0060|M] error -22 on line 1285
kernel: tda18271 10-0060: destroying instance
kernel: [5789622.726935] tuner 10-0060: Tuner has no way to set tv freq
kernel: tuner 10-0060: Tuner has no way to set tv freq
kernel: [5789622.728068] cx231xx 2-2:1.1: v4l2 driver version 0.0.3
kernel: cx231xx 2-2:1.1: v4l2 driver version 0.0.3
kernel: [5789622.856428] tuner 10-0060: Tuner has no way to set tv freq
kernel: [5789622.856582] cx231xx 2-2:1.1: Registered video device video1 [v4l2]
kernel: [5789622.856695] cx231xx 2-2:1.1: Registered VBI device vbi1
kernel: [5789622.856964] cx231xx 2-2:1.1: audio EndPoint Addr 0x83,
Alternate settings: 3
kernel: tuner 10-0060: Tuner has no way to set tv freq
kernel: cx231xx 2-2:1.1: Registered video device video1 [v4l2]
kernel: cx231xx 2-2:1.1: Registered VBI device vbi1
kernel: cx231xx 2-2:1.1: audio EndPoint Addr 0x83, Alternate settings: 3
kernel: [5789622.893807] cx231xx 2-2:1.1: dvb_init: looking for tuner
/ demod on i2c bus: 10
kernel: cx231xx 2-2:1.1: dvb_init: looking for tuner / demod on i2c bus: 10
kernel: cx231xx 2-2:1.1: cx231xx_send_usb_command: failed with status --32
kernel: lgdt3305_read_reg: error (addr 0e reg 0001 error (ret == -32)
kernel: lgdt3305_attach: error -32 on line 1143
kernel: lgdt3305_attach: unable to detect LGDT3305 hardware
kernel: cx231xx 2-2:1.1: Failed to attach LG3305 front end
kernel: [5789622.894206] cx231xx 2-2:1.1: cx231xx_send_usb_command:
failed with status --32
kernel: [5789622.894210] lgdt3305_read_reg: error (addr 0e reg 0001
error (ret == -32)
kernel: [5789622.894212] lgdt3305_attach: error -32 on line 1143
kernel: [5789622.894214] lgdt3305_attach: unable to detect LGDT3305 hardware
kernel: [5789622.894218] cx231xx 2-2:1.1: Failed to attach LG3305 front end
kernel: [5789622.894919] cx231xx 2-2:1.1: video EndPoint Addr 0x84,
Alternate settings: 5
kernel: [5789622.894925] cx231xx 2-2:1.1: VBI EndPoint Addr 0x85,
Alternate settings: 2
kernel: [5789622.894928] cx231xx 2-2:1.1: sliced CC EndPoint Addr
0x86, Alternate settings: 2
kernel: [5789622.894931] cx231xx 2-2:1.1: TS EndPoint Addr 0x81,
Alternate settings: 6
kernel: cx231xx 2-2:1.1: video EndPoint Addr 0x84, Alternate settings: 5
kernel: cx231xx 2-2:1.1: VBI EndPoint Addr 0x85, Alternate settings: 2
kernel: cx231xx 2-2:1.1: sliced CC EndPoint Addr 0x86, Alternate settings: 2

Appreciate some advice.

Regards,
Scott
--
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

[RFC 4/7] drivers/media/pci/zoran: avoid fragile snprintf use

2016-03-08 Thread Rasmus Villemoes

Appending to a string by doing snprintf(buf, bufsize, "%s...", buf,
...) is not guaranteed to work.

Signed-off-by: Rasmus Villemoes 
---
 drivers/media/pci/zoran/videocodec.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/zoran/videocodec.c 
b/drivers/media/pci/zoran/videocodec.c
index c01071635290..13a3c07cd259 100644
--- a/drivers/media/pci/zoran/videocodec.c
+++ b/drivers/media/pci/zoran/videocodec.c
@@ -116,8 +116,9 @@ videocodec_attach (struct videocodec_master *master)
goto out_module_put;
}
 
-   snprintf(codec->name, sizeof(codec->name),
-"%s[%d]", codec->name, h->attached);
+   res = strlen(codec->name);
+   snprintf(codec->name + res, sizeof(codec->name) - res,
+"[%d]", h->attached);
codec->master_data = master;
res = codec->setup(codec);
if (res == 0) {
-- 
2.1.4

--
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

[RFC 6/7] [media] ati_remote: avoid fragile snprintf use

2016-03-08 Thread Rasmus Villemoes

Passing overlapping source and destination to snprintf is
fragile. Replace with a single (mostly) equivalent call. If one wants
to preserve the space preceding udev->product whether or not there was
a manufacturer, just remove udev->manufacturer from the && expression.

Signed-off-by: Rasmus Villemoes 
---
 drivers/media/rc/ati_remote.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index a35631891cc0..b6d367ba128a 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -866,13 +866,10 @@ static int ati_remote_probe(struct usb_interface 
*interface,
strlcat(ati_remote->rc_phys, "/input0", sizeof(ati_remote->rc_phys));
strlcat(ati_remote->mouse_phys, "/input1", 
sizeof(ati_remote->mouse_phys));
 
-   if (udev->manufacturer)
-   strlcpy(ati_remote->rc_name, udev->manufacturer,
-   sizeof(ati_remote->rc_name));
-
-   if (udev->product)
-   snprintf(ati_remote->rc_name, sizeof(ati_remote->rc_name),
-"%s %s", ati_remote->rc_name, udev->product);
+   snprintf(ati_remote->rc_name, sizeof(ati_remote->rc_name), "%s%s%s",
+   udev->manufacturer ?: "",
+   udev->manufacturer && udev->product ? " " : "",
+   udev->product ?: "");
 
if (!strlen(ati_remote->rc_name))
snprintf(ati_remote->rc_name, sizeof(ati_remote->rc_name),
-- 
2.1.4

--
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: [PATCH 4/7] scatterlist: add sg_alloc_table_from_buf() helper

2016-03-08 Thread Boris Brezillon

Hi Laurent,

On Tue, 08 Mar 2016 18:51:49 +0200
Laurent Pinchart  wrote:

> Hi Boris,
> 
> Thank you for the patch.
> 
> On Tuesday 08 March 2016 12:15:12 Boris Brezillon wrote:
> > sg_alloc_table_from_buf() provides an easy solution to create an sg_table
> > from a virtual address pointer. This function takes care of dealing with
> > vmallocated buffers, buffer alignment, or DMA engine limitations (maximum
> > DMA transfer size).
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> >  include/linux/scatterlist.h |  24 
> >  lib/scatterlist.c   | 142 +
> >  2 files changed, 166 insertions(+)
> > 
> > diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
> > index 556ec1e..4a75362 100644
> > --- a/include/linux/scatterlist.h
> > +++ b/include/linux/scatterlist.h
> > @@ -41,6 +41,27 @@ struct sg_table {
> > unsigned int orig_nents;/* original size of list */
> >  };
> > 
> > +/**
> > + * struct sg_constraints - SG constraints structure
> > + *
> > + * @max_chunk_len: maximum chunk buffer length. Each SG entry has to be
> > smaller
> > + *than this value. Zero means no constraint.
> > + * @required_alignment: minimum alignment. Is used for both size and
> > pointer
> > + * alignment. If this constraint is not met, the function
> > + * should return -EINVAL.
> > + * @preferred_alignment: preferred alignment. Mainly used to optimize
> > + *  throughput when the DMA engine performs better when
> > + *  doing aligned accesses.
> > + *
> > + * This structure is here to help sg_alloc_table_from_buf() create the
> > optimal
> > + * SG list based on DMA engine constraints.
> > + */
> > +struct sg_constraints {
> > +   size_t max_chunk_len;
> > +   size_t required_alignment;
> > +   size_t preferred_alignment;
> > +};
> > +
> >  /*
> >   * Notes on SG table design.
> >   *
> > @@ -265,6 +286,9 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
> > struct page **pages, unsigned int n_pages,
> > unsigned long offset, unsigned long size,
> > gfp_t gfp_mask);
> > +int sg_alloc_table_from_buf(struct sg_table *sgt, const void *buf, size_t
> > len,
> > +   const struct sg_constraints *constraints,
> > +   gfp_t gfp_mask);
> > 
> >  size_t sg_copy_buffer(struct scatterlist *sgl, unsigned int nents, void
> > *buf, size_t buflen, off_t skip, bool to_buffer);
> > diff --git a/lib/scatterlist.c b/lib/scatterlist.c
> > index bafa993..706b583 100644
> > --- a/lib/scatterlist.c
> > +++ b/lib/scatterlist.c
> > @@ -433,6 +433,148 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
> >  }
> >  EXPORT_SYMBOL(sg_alloc_table_from_pages);
> > 
> > +static size_t sg_buf_chunk_len(const void *buf, size_t len,
> > +  const struct sg_constraints *cons)
> > +{
> > +   size_t chunk_len = len;
> > +
> > +   if (cons->max_chunk_len)
> > +   chunk_len = min_t(size_t, chunk_len, cons->max_chunk_len);
> > +
> > +   if (is_vmalloc_addr(buf))
> > +   chunk_len = min_t(size_t, chunk_len,
> > + PAGE_SIZE - offset_in_page(buf));
> 
> This will lead to page-sized scatter-gather entries even for pages of the 
> vmalloc memory that happen to be physically contiguous. That works, but I 
> wonder whether we'd want to be more efficient.

Hm, I thought dma_map_sg() was taking care of merging pĥysically
contiguous memory regions, but maybe I'm wrong. Anyway, that's
definitely something I can add at this level.

> 
> > +   if (!IS_ALIGNED((unsigned long)buf, cons->preferred_alignment)) {
> > +   const void *aligned_buf = PTR_ALIGN(buf,
> > +   cons->preferred_alignment);
> > +   size_t unaligned_len = (unsigned long)(aligned_buf - buf);
> > +
> > +   chunk_len = min_t(size_t, chunk_len, unaligned_len);
> > +   } else if (chunk_len > cons->preferred_alignment) {
> > +   chunk_len &= ~(cons->preferred_alignment - 1);
> > +   }
> > +
> > +   return chunk_len;
> > +}
> > +
> > +#define sg_for_each_chunk_in_buf(buf, len, chunk_len, constraints) \
> > +   for (chunk_len = sg_buf_chunk_len(buf, len, constraints);   \
> > +len;   \
> > +len -= chunk_len, buf += chunk_len,\
> > +chunk_len = sg_buf_chunk_len(buf, len, constraints))
> > +
> > +static int sg_check_constraints(struct sg_constraints *cons,
> > +   const void *buf, size_t len)
> > +{
> > +   if (!cons->required_alignment)
> > +   cons->required_alignment = 1;
> > +
> > +   if (!cons->preferred_alignment)
> > +   cons->preferred_alignment = cons->required_alignment;
> > +
> > +   /* Test if buf and len are properly aligned. */
> > +   if

Re: [PATCH 4/7] scatterlist: add sg_alloc_table_from_buf() helper

2016-03-08 Thread Laurent Pinchart

Hi Boris,

Thank you for the patch.

On Tuesday 08 March 2016 12:15:12 Boris Brezillon wrote:
> sg_alloc_table_from_buf() provides an easy solution to create an sg_table
> from a virtual address pointer. This function takes care of dealing with
> vmallocated buffers, buffer alignment, or DMA engine limitations (maximum
> DMA transfer size).
> 
> Signed-off-by: Boris Brezillon 
> ---
>  include/linux/scatterlist.h |  24 
>  lib/scatterlist.c   | 142 +
>  2 files changed, 166 insertions(+)
> 
> diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
> index 556ec1e..4a75362 100644
> --- a/include/linux/scatterlist.h
> +++ b/include/linux/scatterlist.h
> @@ -41,6 +41,27 @@ struct sg_table {
>   unsigned int orig_nents;/* original size of list */
>  };
> 
> +/**
> + * struct sg_constraints - SG constraints structure
> + *
> + * @max_chunk_len: maximum chunk buffer length. Each SG entry has to be
> smaller
> + *  than this value. Zero means no constraint.
> + * @required_alignment: minimum alignment. Is used for both size and
> pointer
> + *   alignment. If this constraint is not met, the function
> + *   should return -EINVAL.
> + * @preferred_alignment: preferred alignment. Mainly used to optimize
> + *throughput when the DMA engine performs better when
> + *doing aligned accesses.
> + *
> + * This structure is here to help sg_alloc_table_from_buf() create the
> optimal
> + * SG list based on DMA engine constraints.
> + */
> +struct sg_constraints {
> + size_t max_chunk_len;
> + size_t required_alignment;
> + size_t preferred_alignment;
> +};
> +
>  /*
>   * Notes on SG table design.
>   *
> @@ -265,6 +286,9 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
>   struct page **pages, unsigned int n_pages,
>   unsigned long offset, unsigned long size,
>   gfp_t gfp_mask);
> +int sg_alloc_table_from_buf(struct sg_table *sgt, const void *buf, size_t
> len,
> + const struct sg_constraints *constraints,
> + gfp_t gfp_mask);
> 
>  size_t sg_copy_buffer(struct scatterlist *sgl, unsigned int nents, void
> *buf, size_t buflen, off_t skip, bool to_buffer);
> diff --git a/lib/scatterlist.c b/lib/scatterlist.c
> index bafa993..706b583 100644
> --- a/lib/scatterlist.c
> +++ b/lib/scatterlist.c
> @@ -433,6 +433,148 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
>  }
>  EXPORT_SYMBOL(sg_alloc_table_from_pages);
> 
> +static size_t sg_buf_chunk_len(const void *buf, size_t len,
> +const struct sg_constraints *cons)
> +{
> + size_t chunk_len = len;
> +
> + if (cons->max_chunk_len)
> + chunk_len = min_t(size_t, chunk_len, cons->max_chunk_len);
> +
> + if (is_vmalloc_addr(buf))
> + chunk_len = min_t(size_t, chunk_len,
> +   PAGE_SIZE - offset_in_page(buf));

This will lead to page-sized scatter-gather entries even for pages of the 
vmalloc memory that happen to be physically contiguous. That works, but I 
wonder whether we'd want to be more efficient.

> + if (!IS_ALIGNED((unsigned long)buf, cons->preferred_alignment)) {
> + const void *aligned_buf = PTR_ALIGN(buf,
> + cons->preferred_alignment);
> + size_t unaligned_len = (unsigned long)(aligned_buf - buf);
> +
> + chunk_len = min_t(size_t, chunk_len, unaligned_len);
> + } else if (chunk_len > cons->preferred_alignment) {
> + chunk_len &= ~(cons->preferred_alignment - 1);
> + }
> +
> + return chunk_len;
> +}
> +
> +#define sg_for_each_chunk_in_buf(buf, len, chunk_len, constraints)   \
> + for (chunk_len = sg_buf_chunk_len(buf, len, constraints);   \
> +  len;   \
> +  len -= chunk_len, buf += chunk_len,\
> +  chunk_len = sg_buf_chunk_len(buf, len, constraints))
> +
> +static int sg_check_constraints(struct sg_constraints *cons,
> + const void *buf, size_t len)
> +{
> + if (!cons->required_alignment)
> + cons->required_alignment = 1;
> +
> + if (!cons->preferred_alignment)
> + cons->preferred_alignment = cons->required_alignment;
> +
> + /* Test if buf and len are properly aligned. */
> + if (!IS_ALIGNED((unsigned long)buf, cons->required_alignment) ||
> + !IS_ALIGNED(len, cons->required_alignment))
> + return -EINVAL;
> +
> + /*
> +  * if the buffer has been vmallocated and required_alignment is
> +  * more than PAGE_SIZE we cannot guarantee it.
> +  */
> + if (is_vmalloc_addr(buf) && cons->required_alignment > PAGE_SIZE)
> + return -EINVAL;
> +
> + /*
> +  *

Re: Question regarding internal webcams of tablet devices

2016-03-08 Thread Daniel Glöckner

Hi,

On Tue, Mar 08, 2016 at 04:21:01PM +0100, Dennis Wassenberg wrote:
> However, at first there is the need to get a driver for the camera IO
> host controller PCI device. Is there anybody how knows a driver for that
> pci device or known if there will be a driver for that in the future? Is
> this the right way to support this kind of cameras or is there an other
> way to get such cameras working with linux?

I know that Intel wrote a GPLv2 driver for the CSI host controller in
Merrifield, Baytrail, Anniedale and Cherrytrail. It is part of their
Android kernel. You might have luck searching for an Android kernel
for a Skylake tablet. But be careful, the driver I know only supports
a fixed set of configurations. It seems like Intel expects every
manufacturer to just copy their reference design down to the GPIO
numbers used to reset the camera sensors.

Best regards,

  Daniel
--
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

Question regarding internal webcams of tablet devices

2016-03-08 Thread Dennis Wassenberg

Hi,

I have a couple of questions regarding support of internal webcams of
new/current generation of tablet devices. For example Lenovo X1, HP
Elite x2 1012 G1. There are internal webcams which are not connected via
USB. In fact they are connected via the

(00:14.3 Multimedia controller [0480]: Intel Corporation Device
[8086:9d32] (rev 01) / Intel Skylake-U/Y PCH - Camera IO Host Controller
(CSI2) [A1])

PCI device. The PCI device itself serves as a camera IO host controller
which communicates via CSI-2 over I2C to the camera sensors. As far as I
know there is currently no support for the CSI-2 host controller but I
have seen some support for camera sensors in general at v4l.

However, at first there is the need to get a driver for the camera IO
host controller PCI device. Is there anybody how knows a driver for that
pci device or known if there will be a driver for that in the future? Is
this the right way to support this kind of cameras or is there an other
way to get such cameras working with linux?

Thank you & best regards,

Dennis
--
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: Kernel docs: muddying the waters a bit

2016-03-08 Thread Mauro Carvalho Chehab

Em Tue, 8 Mar 2016 10:39:22 -0300
Mauro Carvalho Chehab  escreveu:

> Em Tue, 08 Mar 2016 05:13:13 -0700
> Dan Allen  escreveu:
> 
> > On Tue, Mar 8, 2016 at 4:29 AM, Mauro Carvalho Chehab <  
> > mche...@osg.samsung.com> wrote:
> >   
> > > pandoc did a really crap job on the conversion. To convert this
> > > into something useful, we'll need to spend a lot of time, as it lost
> > > most of the cross-references, as they were defined via DocBook macros.
> > >
> > 
> > I agree pandoc creates crappy AsciiDoc. We have a much better converter in
> > the works called DocBookRx.
> > 
> > https://github.com/opendevise/docbookrx
> > 
> > It has converted several very serious DocBook documents and we're
> > continuing to improve it. It's also a lot easier to hack than pandoc.  
> 
> Didn't work:
> 
> $ ./bin/docbookrx ~/devel/docbook_test/v4l2.xml 
> No visitor defined for ! Skipping.
> No visitor defined for ! Skipping.
> No visitor defined for ! Skipping.
> No visitor defined for ! Skipping.
> No visitor defined for ! Skipping.

I tried to use docbookrx for the bits that were not properly converted,
like the manpage-like pages:

$  ../docbookrx/bin/docbookrx Documentation/DocBook/media/v4l/func-ioctl.xml
No visitor defined for ! Skipping.

Dan, if you want to take a look on what's going wrong here, 
the XML I'm trying to convert is:


https://git.linuxtv.org/media_tree.git/tree/Documentation/DocBook/media/v4l/func-ioctl.xml

If this would work, it should be generating something like:
https://git.linuxtv.org/mchehab/asciidoc-poc.git/tree/func-ioctl.adoc

Pandoc failed to fully convert it, but at least it left all the texts,
with prevented rewriting it from scratch. This is the manual fix
I applied to it:

https://git.linuxtv.org/mchehab/asciidoc-poc.git/commit/func-ioctl.adoc?id=801d336c3742f26731e08c284290c32c0b4632fc

FYI, we have 133 xml files at the media uAPI doc with refmeta.

-- 
Thanks,
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: [PATCH 5/7] mtd: provide helper to prepare buffers for DMA operations

2016-03-08 Thread Boris Brezillon

On Tue, 8 Mar 2016 19:48:53 +0530
Vinod Koul  wrote:

> On Tue, Mar 08, 2016 at 12:15:13PM +0100, Boris Brezillon wrote:
> >  
> > +#ifdef CONFIG_HAS_DMA
> 
> Shouldn't this be CONFIG_DMA_ENGINE as you are preparing these descriptors
> for DMA transfer?
> 

Nope, scatterlist users are not necessarily using a dmaengine, some IPs
are directly embedding a dedicated DMA engine, which has no driver in
drivers/dma/.

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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: Build regressions/improvements in v4.5-rc7

2016-03-08 Thread James Hogan

Hi,

On Mon, Mar 07, 2016 at 10:01:09AM +0100, Geert Uytterhoeven wrote:
> On Mon, Mar 7, 2016 at 9:55 AM, Geert Uytterhoeven  
> wrote:
> > JFYI, when comparing v4.5-rc7[1] to v4.5-rc6[3], the summaries are:
> >   - build errors: +8/-7
>   + error: debugfs.c: undefined reference to `clk_round_rate':  =>
> .text+0x11b9e0)
> 
> arm-randconfig
> 
> While looking for more context, I noticed another regression that fell through
> the cracks of my script:
> 
> arch/arm/kernel/head.o: In function `stext':
> (.head.text+0x40): undefined reference to `CONFIG_PHYS_OFFSET'
> drivers/built-in.o: In function `v4l2_clk_set_rate':
> debugfs.c:(.text+0x11b9e0): undefined reference to `clk_round_rate'
> 
>   + error: misc.c: undefined reference to `ftrace_likely_update':  =>
> .text+0x714), .text+0x94c), .text+0x3b8), .text+0xc10)
> 
> sh-randconfig
> 
> arch/sh/boot/compressed/misc.o: In function `lzo1x_decompress_safe':
> misc.c:(.text+0x3b8): undefined reference to `ftrace_likely_update'
> misc.c:(.text+0x714): undefined reference to `ftrace_likely_update'
> misc.c:(.text+0x94c): undefined reference to `ftrace_likely_update'
> arch/sh/boot/compressed/misc.o: In function `unlzo.constprop.2':
> misc.c:(.text+0xc10): undefined reference to `ftrace_likely_update'
> 
>   + /tmp/cc52LvuK.s: Error: can't resolve `_start' {*UND* section} -
> `L0^A' {.text section}:  => 41, 403
>   + /tmp/ccHfoDA4.s: Error: can't resolve `_start' {*UND* section} -
> `L0^A' {.text section}:  => 43
>   + /tmp/cch1r0UQ.s: Error: can't resolve `_start' {*UND* section} -
> `L0^A' {.text section}:  => 49, 378
>   + /tmp/ccoHdFI8.s: Error: can't resolve `_start' {*UND* section} -
> `L0^A' {.text section}:  => 43
> 
> mips-allnoconfig
> bigsur_defconfig
> malta_defconfig
> cavium_octeon_defconfig
> 
> Not really new, but it would be great if the MIPS people could get this
> fixed for the final release.

This would appear to be related to the ld version check for VDSO
failing.

awk: /home/kisskb/slave/src/scripts/ld-version.sh: line 4: regular expression 
compile failed (missing '(')
.*)
/bin/sh: 1: [: -lt: unexpected operator

I.e. this line:
gsub(".*)", "");

appears to be trying to turn e.g. "GNU ld (Gentoo 2.25.1 p1.1) 2.25.1"
into " 2.25.1", so perhaps the bracket should be escaped. What version
of awk is it using? (GNU Awk 4.0.2 works for me).

Can somebody experiencing this please try:
${CROSS_COMPILE}ld --version | ./scripts/ld-version.sh

with the following patch, to see if it helps.

Thanks
James

diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh
index 198580d245e0..1659b409ef10 100755
--- a/scripts/ld-version.sh
+++ b/scripts/ld-version.sh
@@ -1,7 +1,7 @@
 #!/usr/bin/awk -f
 # extract linker version number from stdin and turn into single number
{
-   gsub(".*)", "");
+   gsub(".*\\)", "");
split($1,a, ".");
print a[1]*1000 + a[2]*10 + a[3]*1 + a[4]*100 + a[5];
exit


signature.asc
Description: Digital signature

[PATCH] [media] em28xx_dvb: add support for PLEX PX-BCUD (ISDB-S usb dongle)

2016-03-08 Thread Satoshi Nagahama

Hi Mauro, Akihiro,

I added em28xx_dvb to support for PLEX PX-BCUD (ISDB-S usb dongle).
Please move forward with this patch if there is no problem.
Or something wrong, please advise me what I should do.

PX-BCUD has the following components:
  USB interface: Empia EM28178
  Demodulator: Toshiba TC90532 (works by code for TC90522)
  Tuner: Next version of Sharp QM1D1C0042

em28xx_dvb_init(), add init code for PLEX PX-BCUD with calling
px_bcud_init() that does things like pin configuration.

qm1d1c0042_init(), support the next version of QM1D1C0042, change to
choose an appropriate array of initial registers by reading chip id.


Signed-off-by: Satoshi Nagahama 
---
 drivers/media/tuners/qm1d1c0042.c   |  35 +++---
 drivers/media/usb/em28xx/Kconfig|   2 +
 drivers/media/usb/em28xx/em28xx-cards.c |  27 
 drivers/media/usb/em28xx/em28xx-dvb.c   | 117 
 drivers/media/usb/em28xx/em28xx.h   |   1 +
 5 files changed, 171 insertions(+), 11 deletions(-)

diff --git a/drivers/media/tuners/qm1d1c0042.c 
b/drivers/media/tuners/qm1d1c0042.c
index 18bc745..8fd91a2 100644
--- a/drivers/media/tuners/qm1d1c0042.c
+++ b/drivers/media/tuners/qm1d1c0042.c
@@ -2,6 +2,7 @@
  * Sharp QM1D1C0042 8PSK tuner driver
  *
  * Copyright (C) 2014 Akihiro Tsukada 
+ * Copyright (C) 2016 Satoshi Nagahama 
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License as
@@ -32,14 +33,23 @@
 #include "qm1d1c0042.h"

 #define QM1D1C0042_NUM_REGS 0x20
-
-static const u8 reg_initval[QM1D1C0042_NUM_REGS] = {
-   0x48, 0x1c, 0xa0, 0x10, 0xbc, 0xc5, 0x20, 0x33,
-   0x06, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00,
-   0x00, 0xff, 0xf3, 0x00, 0x2a, 0x64, 0xa6, 0x86,
-   0x8c, 0xcf, 0xb8, 0xf1, 0xa8, 0xf2, 0x89, 0x00
+#define QM1D1C0042_NUM_REG_ROWS 2
+
+static const u8 reg_initval[QM1D1C0042_NUM_REG_ROWS][QM1D1C0042_NUM_REGS] = { {
+   0x48, 0x1c, 0xa0, 0x10, 0xbc, 0xc5, 0x20, 0x33,
+   0x06, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00,
+   0x00, 0xff, 0xf3, 0x00, 0x2a, 0x64, 0xa6, 0x86,
+   0x8c, 0xcf, 0xb8, 0xf1, 0xa8, 0xf2, 0x89, 0x00
+   }, {
+   0x68, 0x1c, 0xc0, 0x10, 0xbc, 0xc1, 0x11, 0x33,
+   0x03, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00,
+   0x00, 0xff, 0xf3, 0x00, 0x3f, 0x25, 0x5c, 0xd6,
+   0x55, 0xcf, 0x95, 0xf6, 0x36, 0xf2, 0x09, 0x00
+   }
 };

+static int reg_index;
+
 static const struct qm1d1c0042_config default_cfg = {
.xtal_freq = 16000,
.lpf = 1,
@@ -320,7 +330,6 @@ static int qm1d1c0042_init(struct dvb_frontend *fe)
int i, ret;

state = fe->tuner_priv;
-   memcpy(state->regs, reg_initval, sizeof(reg_initval));

reg_write(state, 0x01, 0x0c);
reg_write(state, 0x01, 0x0c);
@@ -330,15 +339,19 @@ static int qm1d1c0042_init(struct dvb_frontend *fe)
goto failed;
usleep_range(2000, 3000);

-   val = state->regs[0x01] | 0x10;
-   ret = reg_write(state, 0x01, val); /* soft reset off */
+   ret = reg_write(state, 0x01, 0x1c); /* soft reset off */
if (ret < 0)
goto failed;

-   /* check ID */
+   /* check ID and choose initial registers corresponding ID */
ret = reg_read(state, 0x00, );
-   if (ret < 0 || val != 0x48)
+   if (ret < 0)
+   goto failed;
+   for (reg_index = 0; reg_index < QM1D1C0042_NUM_REG_ROWS; reg_index++)
+   if (val == reg_initval[reg_index][0x00]) break;
+   if (reg_index >= QM1D1C0042_NUM_REG_ROWS)
goto failed;
+   memcpy(state->regs, reg_initval[reg_index], QM1D1C0042_NUM_REGS);
usleep_range(2000, 3000);

state->regs[0x0c] |= 0x40;
diff --git a/drivers/media/usb/em28xx/Kconfig b/drivers/media/usb/em28xx/Kconfig
index e382210..d917b0a 100644
--- a/drivers/media/usb/em28xx/Kconfig
+++ b/drivers/media/usb/em28xx/Kconfig
@@ -59,6 +59,8 @@ config VIDEO_EM28XX_DVB
select DVB_DRX39XYJ if MEDIA_SUBDRV_AUTOSELECT
select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_SI2157 if MEDIA_SUBDRV_AUTOSELECT
+   select DVB_TC90522 if MEDIA_SUBDRV_AUTOSELECT
+   select MEDIA_TUNER_QM1D1C0042 if MEDIA_SUBDRV_AUTOSELECT
---help---
  This adds support for DVB cards based on the
  Empiatech em28xx chips.
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers/media/usb/em28xx/em28xx-cards.c
index 930e3e3..772a8f8 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -492,6 +492,20 @@ static struct em28xx_reg_seq terratec_t2_stick_hd[] = {
{-1, -1,   -1, -1},
 };

+static struct em28xx_reg_seq plex_px_bcud[] = {
+   {EM2874_R80_GPIO_P0_CTRL,   0xff,   0xff,   0},
+   {0x0d,

Re: [PATCH 5/7] mtd: provide helper to prepare buffers for DMA operations

2016-03-08 Thread Vinod Koul

On Tue, Mar 08, 2016 at 12:15:13PM +0100, Boris Brezillon wrote:
>  
> +#ifdef CONFIG_HAS_DMA

Shouldn't this be CONFIG_DMA_ENGINE as you are preparing these descriptors
for DMA transfer?

-- 
~Vinod
--
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: Kernel docs: muddying the waters a bit

2016-03-08 Thread Jani Nikula

On Tue, 08 Mar 2016, Dan Allen  wrote:
> That's not entirely true. First, you can pre-split at the source level
> using includes and generate output for each of the masters. That's what I
> tend to do and it works really well since these are logical split points.

I need to look into this again. Is there a specific option or directive
to produce split output for includes? When I tried this, the result was
just one big output file. (And indeed we'd need both. Some includes we
want embedded, some includes should produce separate outputs.)

>> That actually makes choosing asciidoc harder, because
>> requiring another language environment complicates, not simplifies, the
>> toolchain. I'd really like to lower the bar for building the
>> documentation, for everyone, so much so that it becomes part of the
>> normal checks for patch inclusion.
>
> Pardon my bluntness here, but I don't buy that argument. This is Linux.
> Installing software couldn't be simpler, and we're talking about an
> extremely well supported language (Ruby).

Granted, that part works for me. I'm not so sensitive to the
dependencies; others may disagree.

> I think it's a huge exaggeration to say that Asciidoctor is any harder to
> install than AsciiDoc Python. It's also a heck of a lot smaller in size
> since AsciiDoc Python pulls in hundreds of MB of LaTeX packages.

For me, the comparison is really between Sphinx and Asciidoctor, not so
much doc vs. doctor. The native output format and extension support in
Sphinx is appealing; I am not yet convinced we could manage with
Asciidoctor but without DocBook. The extension offering seems better in
Sphinx.

> Whatever you decide, I wish you all the best with your documentation
> efforts!

Thanks!

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
--
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: Kernel docs: muddying the waters a bit

2016-03-08 Thread Mauro Carvalho Chehab

Em Tue, 08 Mar 2016 05:13:13 -0700
Dan Allen  escreveu:

> On Tue, Mar 8, 2016 at 4:29 AM, Mauro Carvalho Chehab <
> mche...@osg.samsung.com> wrote:  
> 
> > pandoc did a really crap job on the conversion. To convert this
> > into something useful, we'll need to spend a lot of time, as it lost
> > most of the cross-references, as they were defined via DocBook macros.
> >  
> 
> I agree pandoc creates crappy AsciiDoc. We have a much better converter in
> the works called DocBookRx.
> 
> https://github.com/opendevise/docbookrx
> 
> It has converted several very serious DocBook documents and we're
> continuing to improve it. It's also a lot easier to hack than pandoc.

Didn't work:

$ ./bin/docbookrx ~/devel/docbook_test/v4l2.xml 
No visitor defined for ! Skipping.
No visitor defined for ! Skipping.
No visitor defined for ! Skipping.
No visitor defined for ! Skipping.
No visitor defined for ! Skipping.


> 
> -Dan
> 
> 


-- 
Thanks,
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: Kernel docs: muddying the waters a bit

2016-03-08 Thread Mauro Carvalho Chehab

Em Tue, 08 Mar 2016 05:09:40 -0700
Dan Allen  escreveu:

> Jani wrote:
> 
> > there was no support for chunked, or split
> > to chapters, HTML, and the single page result was simply way too big.
> >  
> 
> That's not entirely true. First, you can pre-split at the source level
> using includes and generate output for each of the masters. That's what I
> tend to do and it works really well since these are logical split points.

The problem on pre-splitting the documents and process them in separate
is that this will break cross-references. At the media uAPI Docbook,
we use a lot of cross references.

Btw, we use a lot of includes. Currently, it has 187 separate files.

We even parse the header files looking for typedefs, structs, enums,
#defines and functions, in order to produce a document that will
cross-reference the documentation.

> Second, there is a custom converter in the works to split post-generate
> (which is really what we're talking about when we compare it to the DocBook
> toolchain).
> 
> https://github.com/asciidoctor/asciidoctor-extensions-lab/blob/master/lib/multipage-html5-converter.rb
> 
> It's just a prototype, but proves it is possible by design.

I didn't test it, but I saw some comments at the web that the part
that would handle cross-references between files is not ready.

> Personally, I don't like most chunked HTML approaches because they split
> arbitrarily. We are trying to find the right balance so that the output is
> actually sensible. There's still work to do, but there are options in the
> meantime.

Well, if it is capable of creating one chunk per include file, and do
cross-references between chunks, this would work for media UAPI book.

Yet, it would be good to have the multi-chunk extension packaged
on major distros, as I don't like the idea of installing it without
using my distro's package manager.

-- 
Thanks,
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: Kernel docs: muddying the waters a bit

2016-03-08 Thread Mauro Carvalho Chehab

Em Tue, 08 Mar 2016 11:49:35 +0200
Jani Nikula  escreveu:

> On Tue, 08 Mar 2016, Dan Allen  wrote:
> > One of the key goals of the Asciidoctor project is to be able to directly
> > produce a wide variety of outputs from the same source (without DocBook).
> > We've added flexibility and best practices into the syntax and matured the
> > converter mechanism to bridge this (sometimes very wide) gap.  
> 
> I think our conclusion so far was that the native AsciiDoc (and
> Asciidoctor) outputs fell short of our needs, forcing us to use the
> DocBook pipeline. I, for one, was hoping we could eventually simplify
> the toolchain. For example, there was no support for chunked, or split
> to chapters, HTML, and the single page result was simply way too big.
> 
> > Asciidoctor is the future of AsciiDoc. Even the AsciiDoc Python maintainers
> > acknowledge that (including the original creator).  
> 
> Thanks for the input. We've touched the topic of AsciiDoc
> vs. Asciidoctor before [1]. So we should be using Asciidoctor instead of
> AsciiDoc. That actually makes choosing asciidoc harder, because
> requiring another language environment complicates, not simplifies, the
> toolchain. I'd really like to lower the bar for building the
> documentation, for everyone, so much so that it becomes part of the
> normal checks for patch inclusion.

As I failed to find a way to solve the issues with Sphinx/RST, I started
a PoC using Asciidoctor for the Media uAPI docbook conversion, in order
to see if this would work for us.

I'm not a big fan of using a language that I don't domain, like
Ruby (and the same applies to Python), but, as I said before,
provided that the toolchain works, can easily be installed on
Fedora and Debian, and provide the functionality I need, I'm
ok with that. 

On my tests, Asciidoctor is really fast. It takes a fraction of the
time require to build from DocBook, with is a good thing.

Yet, I suspect that it doesn't have the strict checks that xmllint
have. For example, I didn't see any warning about a missing cross-ref.
We use those warnings to discover if something is added at the code,
but were not documented. Its error reports are also crappy, as it
doesn't tell where the problem is. For example:

$ asciidoctor -n -b docbook media_api.adoc
asciidoctor: WARNING: tables must have at least one body row

On a document with 33793 lines (this is the size of the uAPI doc
when converted to AsciiDoc format), the above warning doesn't help.

So, I'm actually planning to use AsciiDoc/xmllint to check for
documentation troubles, if possible.

Even with AsciiDoc/Asciidoctor, there are several features at the
media documents that aren't well supported. For example, we widely
use the Docbook's tags to generate a manpage-like description:

V4L2 open()

v4l2-open
Open a V4L2 device

  #include fcntl.h

int open
const char *device_name
int flags

Asciidoctor doesn't produce anything like that, if the booktype is not
"manpage". Well, the media documentation is a multi-part book.

So, all those tags should be manually converted (actually, pandoc
made a mess with those tags - so manual work is required anyway,
no matter what markdown language we use). It will be a hard work,
but, at least, this is doable. 

Also, it doesn't accept images with PDF format. We have a few PDF
images, although I we have them also in GIF. So, not a big issue here.

I also did lots of table conversions, to see if our complex tables
would fit. The answer is: Yes: on all cases I converted, it worked
fine.

There are two ways of doing that:
- Nested tables
- Merging cells

Some tables we use won't work fine with nested tables, as they have
cells merging the entire line of such tables.

Also, converting some tables to nested tables would be incredible hard,
as we have really big tables there that would need to add dozens of nested
tables inside, like this one:

https://linuxtv.org/downloads/v4l-dvb-apis/extended-controls.html#id-1.4.4.14.6.4

Using merging cells works fine, tough, and it is not hard to use.
The tables are easy to edit. The Asciidoctor syntax (not sure if AsciiDoc
also accepts this) is:

.MFC 5.1 Control IDs
[width="100%",cols="7%,40%,13%,40%",options="header",]
|===
|ID |Type 2+| Description

...

The "2+|" tells that the next content should be merged into two cells.

One of the good things is that we're not forced to use asciiart, with
would make it really hard to handle the tables.

For those wanting to see the results so far:

The html is at:

https://mchehab.fedorapeople.org/media-kabi-docs-test/asciidoc_tests/media_api.html

The testing tree is at:
https://git.linuxtv.org/mchehab/asciidoc-poc.git/

PS.: pandoc did a really crap job on the conversion. To convert this

[PATCH 0/7] mtd: nand: sunxi: add support for DMA operations

2016-03-08 Thread Boris Brezillon

Hello,

This patch series aims at adding support for DMA assisted operations to
the sunxi_nand driver.

The first 3 patches are just reworks in the existing driver preparing
things for DMA ->read/write_page() operations. Those ones are mainly
re-arranging existing functions, and moving some code into dedicated
functions so we can reuse them when adding the read/write_page()
implementation.

Patch 4 is an attempt to generalize some logic that are duplicated in a
lot of places. It provides a generic solution to create an SG table
from a buffer (passed by virtual address) and its length.
This generic implementation tries to take all possible constraints into
account, like:
- vmallocated buffers
- alignement requirement/preference
- maximum DMA transfer length

I may have missed other things (is there a need for a minimum DMA
transfer constraint?), so don't hesitate to point problems or missing
elements in this implementation.
Note that other subsystems doing the same kind of thing (like SPI of V4L)
could use this implementation. This is why I've put the SPI and V4L
maintainers in Cc.

Patch 5 is providing functions to map/unmap buffers for DMA operations
at the MTD level. This will hopefully limit the number of open-coded
implementations we're currently seeing in a lot of NAND drivers.
Of course, it's making use of sg_alloc_table_from_buf(), introduced in
patch 4.

Patch 6 and 7 are patching the sunxi NAND driver and its DT binding doc
to add DMA support.

I'm particularly interested in getting feedbacks on patch 4 and 5.
Is there a reason nobody ever tried to create such generic functions
(at the scatterlist and MTD levels), and if there are, could you detail
them?

Thanks,

Boris

Side note: patches touching the sunxi NAND driver are depending on
a series posted yesterday [1].

[1]https://lkml.org/lkml/2016/3/7/444

Boris Brezillon (7):
  mtd: nand: sunxi: move some ECC related operations to their own
functions
  mtd: nand: sunxi: make OOB retrieval optional
  mtd: nand: sunxi: make cur_off parameter optional in extra oob helpers
  scatterlist: add sg_alloc_table_from_buf() helper
  mtd: provide helper to prepare buffers for DMA operations
  mtd: nand: sunxi: add support for DMA assisted operations
  mtd: nand: sunxi: update DT bindings

 .../devicetree/bindings/mtd/sunxi-nand.txt |   4 +
 drivers/mtd/mtdcore.c  |  66 +++
 drivers/mtd/nand/sunxi_nand.c  | 483 ++---
 include/linux/mtd/mtd.h|  25 ++
 include/linux/scatterlist.h|  24 +
 lib/scatterlist.c  | 142 ++
 6 files changed, 679 insertions(+), 65 deletions(-)

-- 
2.1.4

--
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

[PATCH 4/7] scatterlist: add sg_alloc_table_from_buf() helper

2016-03-08 Thread Boris Brezillon

sg_alloc_table_from_buf() provides an easy solution to create an sg_table
from a virtual address pointer. This function takes care of dealing with
vmallocated buffers, buffer alignment, or DMA engine limitations (maximum
DMA transfer size).

Signed-off-by: Boris Brezillon 
---
 include/linux/scatterlist.h |  24 
 lib/scatterlist.c   | 142 
 2 files changed, 166 insertions(+)

diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 556ec1e..4a75362 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -41,6 +41,27 @@ struct sg_table {
unsigned int orig_nents;/* original size of list */
 };
 
+/**
+ * struct sg_constraints - SG constraints structure
+ *
+ * @max_chunk_len: maximum chunk buffer length. Each SG entry has to be smaller
+ *than this value. Zero means no constraint.
+ * @required_alignment: minimum alignment. Is used for both size and pointer
+ * alignment. If this constraint is not met, the function
+ * should return -EINVAL.
+ * @preferred_alignment: preferred alignment. Mainly used to optimize
+ *  throughput when the DMA engine performs better when
+ *  doing aligned accesses.
+ *
+ * This structure is here to help sg_alloc_table_from_buf() create the optimal
+ * SG list based on DMA engine constraints.
+ */
+struct sg_constraints {
+   size_t max_chunk_len;
+   size_t required_alignment;
+   size_t preferred_alignment;
+};
+
 /*
  * Notes on SG table design.
  *
@@ -265,6 +286,9 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
struct page **pages, unsigned int n_pages,
unsigned long offset, unsigned long size,
gfp_t gfp_mask);
+int sg_alloc_table_from_buf(struct sg_table *sgt, const void *buf, size_t len,
+   const struct sg_constraints *constraints,
+   gfp_t gfp_mask);
 
 size_t sg_copy_buffer(struct scatterlist *sgl, unsigned int nents, void *buf,
  size_t buflen, off_t skip, bool to_buffer);
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index bafa993..706b583 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -433,6 +433,148 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
 }
 EXPORT_SYMBOL(sg_alloc_table_from_pages);
 
+static size_t sg_buf_chunk_len(const void *buf, size_t len,
+  const struct sg_constraints *cons)
+{
+   size_t chunk_len = len;
+
+   if (cons->max_chunk_len)
+   chunk_len = min_t(size_t, chunk_len, cons->max_chunk_len);
+
+   if (is_vmalloc_addr(buf))
+   chunk_len = min_t(size_t, chunk_len,
+ PAGE_SIZE - offset_in_page(buf));
+
+   if (!IS_ALIGNED((unsigned long)buf, cons->preferred_alignment)) {
+   const void *aligned_buf = PTR_ALIGN(buf,
+   cons->preferred_alignment);
+   size_t unaligned_len = (unsigned long)(aligned_buf - buf);
+
+   chunk_len = min_t(size_t, chunk_len, unaligned_len);
+   } else if (chunk_len > cons->preferred_alignment) {
+   chunk_len &= ~(cons->preferred_alignment - 1);
+   }
+
+   return chunk_len;
+}
+
+#define sg_for_each_chunk_in_buf(buf, len, chunk_len, constraints) \
+   for (chunk_len = sg_buf_chunk_len(buf, len, constraints);   \
+len;   \
+len -= chunk_len, buf += chunk_len,\
+chunk_len = sg_buf_chunk_len(buf, len, constraints))
+
+static int sg_check_constraints(struct sg_constraints *cons,
+   const void *buf, size_t len)
+{
+   if (!cons->required_alignment)
+   cons->required_alignment = 1;
+
+   if (!cons->preferred_alignment)
+   cons->preferred_alignment = cons->required_alignment;
+
+   /* Test if buf and len are properly aligned. */
+   if (!IS_ALIGNED((unsigned long)buf, cons->required_alignment) ||
+   !IS_ALIGNED(len, cons->required_alignment))
+   return -EINVAL;
+
+   /*
+* if the buffer has been vmallocated and required_alignment is
+* more than PAGE_SIZE we cannot guarantee it.
+*/
+   if (is_vmalloc_addr(buf) && cons->required_alignment > PAGE_SIZE)
+   return -EINVAL;
+
+   /*
+* max_chunk_len has to be aligned to required_alignment to
+* guarantee that all buffer chunks are aligned correctly.
+*/
+   if (!IS_ALIGNED(cons->max_chunk_len, cons->required_alignment))
+   return -EINVAL;
+
+   /*
+* preferred_alignment has to be aligned to required_alignment
+* to avoid misalignment of buffer chunks.
+*/
+   if

[PATCH 7/7] mtd: nand: sunxi: update DT bindings

2016-03-08 Thread Boris Brezillon

Document dmas and dma-names properties.

Signed-off-by: Boris Brezillon 
---
 Documentation/devicetree/bindings/mtd/sunxi-nand.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/sunxi-nand.txt 
b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
index 086d6f4..6fdf8f6 100644
--- a/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
@@ -11,6 +11,10 @@ Required properties:
 * "ahb" : AHB gating clock
 * "mod" : nand controller clock
 
+Optional properties:
+- dmas : shall reference DMA channel associated to the NAND controller.
+- dma-names : shall be "rxtx".
+
 Optional children nodes:
 Children nodes represent the available nand chips.
 
-- 
2.1.4

--
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

[PATCH 6/7] mtd: nand: sunxi: add support for DMA assisted operations

2016-03-08 Thread Boris Brezillon

The sunxi NAND controller is able to pipeline ECC operations only when
operated in DMA mode, which improves a lot NAND throughput while keeping
CPU usage low.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand.c | 301 +-
 1 file changed, 297 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 07c3af7..7ba285e 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -277,6 +277,7 @@ struct sunxi_nfc {
unsigned long clk_rate;
struct list_head chips;
struct completion complete;
+   struct dma_chan *dmac;
 };
 
 static inline struct sunxi_nfc *to_sunxi_nfc(struct nand_hw_control *ctrl)
@@ -369,6 +370,68 @@ static int sunxi_nfc_rst(struct sunxi_nfc *nfc)
return ret;
 }
 
+static int sunxi_nfc_dma_op_prepare(struct mtd_info *mtd, const void *buf,
+   int chunksize, int nchunks,
+   enum dma_data_direction ddir,
+   struct sg_table *sgt)
+{
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+   struct dma_async_tx_descriptor *dmad;
+   enum dma_transfer_direction tdir;
+   dma_cookie_t dmat;
+   int ret;
+
+   if (ddir == DMA_FROM_DEVICE)
+   tdir = DMA_DEV_TO_MEM;
+   else
+   tdir = DMA_MEM_TO_DEV;
+
+   ret = mtd_map_buf(mtd, nfc->dev, sgt, buf, nchunks * chunksize,
+ NULL, ddir);
+   if (ret)
+   return ret;
+
+   dmad = dmaengine_prep_slave_sg(nfc->dmac, sgt->sgl, sgt->nents,
+  tdir, DMA_CTRL_ACK);
+   if (IS_ERR(dmad)) {
+   ret = PTR_ERR(dmad);
+   goto err_unmap_buf;
+   }
+
+   writel(readl(nfc->regs + NFC_REG_CTL) | NFC_RAM_METHOD,
+  nfc->regs + NFC_REG_CTL);
+   writel(nchunks, nfc->regs + NFC_REG_SECTOR_NUM);
+   writel(chunksize, nfc->regs + NFC_REG_CNT);
+   dmat = dmaengine_submit(dmad);
+
+   ret = dma_submit_error(dmat);
+   if (ret)
+   goto err_clr_dma_flag;
+
+   return 0;
+
+err_clr_dma_flag:
+   writel(readl(nfc->regs + NFC_REG_CTL) & ~NFC_RAM_METHOD,
+  nfc->regs + NFC_REG_CTL);
+
+err_unmap_buf:
+   mtd_unmap_buf(mtd, nfc->dev, sgt, ddir);
+   return ret;
+}
+
+static void sunxi_nfc_dma_op_cleanup(struct mtd_info *mtd,
+enum dma_data_direction ddir,
+struct sg_table *sgt)
+{
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+
+   mtd_unmap_buf(mtd, nfc->dev, sgt, ddir);
+   writel(readl(nfc->regs + NFC_REG_CTL) & ~NFC_RAM_METHOD,
+  nfc->regs + NFC_REG_CTL);
+}
+
 static int sunxi_nfc_dev_ready(struct mtd_info *mtd)
 {
struct nand_chip *nand = mtd_to_nand(mtd);
@@ -971,6 +1034,106 @@ static void sunxi_nfc_hw_ecc_read_extra_oob(struct 
mtd_info *mtd,
*cur_off = mtd->oobsize + mtd->writesize;
 }
 
+static int sunxi_nfc_hw_ecc_read_chunks_dma(struct mtd_info *mtd, uint8_t *buf,
+   int oob_required, int page,
+   int nchunks)
+{
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+   struct nand_ecc_ctrl *ecc = >ecc;
+   unsigned int max_bitflips = 0;
+   int ret, i, raw_mode = 0;
+   struct sg_table sgt;
+
+   ret = sunxi_nfc_wait_cmd_fifo_empty(nfc);
+   if (ret)
+   return ret;
+
+   ret = sunxi_nfc_dma_op_prepare(mtd, buf, ecc->size, nchunks,
+  DMA_FROM_DEVICE, );
+   if (ret)
+   return ret;
+
+   sunxi_nfc_hw_ecc_enable(mtd);
+   sunxi_nfc_randomizer_config(mtd, page, false);
+   sunxi_nfc_randomizer_enable(mtd);
+
+   writel((NAND_CMD_RNDOUTSTART << 16) | (NAND_CMD_RNDOUT << 8) |
+  NAND_CMD_READSTART, nfc->regs + NFC_REG_RCMD_SET);
+
+   dma_async_issue_pending(nfc->dmac);
+
+   writel(NFC_PAGE_OP | NFC_DATA_SWAP_METHOD | NFC_DATA_TRANS,
+  nfc->regs + NFC_REG_CMD);
+
+   ret = sunxi_nfc_wait_events(nfc, NFC_CMD_INT_FLAG, true, 0);
+   if (ret)
+   dmaengine_terminate_all(nfc->dmac);
+
+   sunxi_nfc_randomizer_disable(mtd);
+   sunxi_nfc_hw_ecc_disable(mtd);
+
+   sunxi_nfc_dma_op_cleanup(mtd, DMA_FROM_DEVICE, );
+
+   if (ret)
+   return ret;
+
+   for (i = 0; i < nchunks; i++) {
+   int data_off = i * ecc->size;
+   int oob_off = i * (ecc->bytes + 4);
+   u8 *data = buf + data_off;
+   u8 *oob = nand->oob_poi + oob_off;
+

[PATCH 1/7] mtd: nand: sunxi: move some ECC related operations to their own functions

2016-03-08 Thread Boris Brezillon

In order to support DMA operations in a clean way we need to extract some
of the logic coded in sunxi_nfc_hw_ecc_read/write_page() into their own
function.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand.c | 163 --
 1 file changed, 108 insertions(+), 55 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 0616f3b..90c121d 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -776,6 +776,94 @@ static inline void sunxi_nfc_user_data_to_buf(u32 
user_data, u8 *buf)
buf[3] = user_data >> 24;
 }
 
+static inline u32 sunxi_nfc_buf_to_user_data(const u8 *buf)
+{
+   return buf[0] | (buf[1] << 8) | (buf[2] << 16) | (buf[3] << 24);
+}
+
+static void sunxi_nfc_hw_ecc_get_prot_oob_bytes(struct mtd_info *mtd, u8 *oob,
+   int step, bool bbm, int page)
+{
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+
+   sunxi_nfc_user_data_to_buf(readl(nfc->regs + NFC_REG_USER_DATA(step)),
+  oob);
+
+   /* De-randomize the Bad Block Marker. */
+   if (bbm && (nand->options & NAND_NEED_SCRAMBLING))
+   sunxi_nfc_randomize_bbm(mtd, page, oob);
+}
+
+static void sunxi_nfc_hw_ecc_set_prot_oob_bytes(struct mtd_info *mtd,
+   const u8 *oob, int step,
+   bool bbm, int page)
+{
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+   u8 user_data[4];
+
+   /* Randomize the Bad Block Marker. */
+   if (bbm && (nand->options & NAND_NEED_SCRAMBLING)) {
+   memcpy(user_data, oob, sizeof(user_data));
+   sunxi_nfc_randomize_bbm(mtd, page, user_data);
+   oob = user_data;
+   }
+
+   writel(sunxi_nfc_buf_to_user_data(oob),
+  nfc->regs + NFC_REG_USER_DATA(step));
+}
+
+static void sunxi_nfc_hw_ecc_update_stats(struct mtd_info *mtd,
+ unsigned int *max_bitflips, int ret)
+{
+   if (ret < 0) {
+   mtd->ecc_stats.failed++;
+   } else {
+   mtd->ecc_stats.corrected += ret;
+   *max_bitflips = max_t(unsigned int, *max_bitflips, ret);
+   }
+}
+
+static int sunxi_nfc_hw_ecc_correct(struct mtd_info *mtd, u8 *data, u8 *oob,
+   int step, bool *erased)
+{
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+   struct nand_ecc_ctrl *ecc = >ecc;
+   u32 status, tmp;
+
+   *erased = false;
+
+   status = readl(nfc->regs + NFC_REG_ECC_ST);
+
+   if (status & NFC_ECC_ERR(step))
+   return -EBADMSG;
+
+   if (status & NFC_ECC_PAT_FOUND(step)) {
+   u8 pattern;
+
+   if (unlikely(!(readl(nfc->regs + NFC_REG_PAT_ID) & 0x1))) {
+   pattern = 0x0;
+   } else {
+   pattern = 0xff;
+   *erased = true;
+   }
+
+   if (data)
+   memset(data, pattern, ecc->size);
+
+   if (oob)
+   memset(oob, pattern, ecc->bytes + 4);
+
+   return 0;
+   }
+
+   tmp = readl(nfc->regs + NFC_REG_ECC_ERR_CNT(step));
+
+   return NFC_ECC_ERR_CNT(step, tmp);
+}
+
 static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info *mtd,
   u8 *data, int data_off,
   u8 *oob, int oob_off,
@@ -787,7 +875,7 @@ static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info *mtd,
struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
struct nand_ecc_ctrl *ecc = >ecc;
int raw_mode = 0;
-   u32 status;
+   bool erased;
int ret;
 
if (*cur_off != data_off)
@@ -813,27 +901,11 @@ static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info 
*mtd,
 
*cur_off = oob_off + ecc->bytes + 4;
 
-   status = readl(nfc->regs + NFC_REG_ECC_ST);
-   if (status & NFC_ECC_PAT_FOUND(0)) {
-   u8 pattern = 0xff;
-
-   if (unlikely(!(readl(nfc->regs + NFC_REG_PAT_ID) & 0x1)))
-   pattern = 0x0;
-
-   memset(data, pattern, ecc->size);
-   memset(oob, pattern, ecc->bytes + 4);
-
+   ret = sunxi_nfc_hw_ecc_correct(mtd, data, oob, 0, );
+   if (erased)
return 1;
-   }
-
-   ret = NFC_ECC_ERR_CNT(0, readl(nfc->regs + NFC_REG_ECC_ERR_CNT(0)));
-
-   memcpy_fromio(data, nfc->regs + NFC_RAM0_BASE, ecc->size);
 
-   nand->cmdfunc(mtd, NAND_CMD_RNDOUT, oob_off, -1);
-   sunxi_nfc_randomizer_read_buf(mtd, oob, ecc->bytes + 4, true, page);
-
-

[PATCH 2/7] mtd: nand: sunxi: make OOB retrieval optional

2016-03-08 Thread Boris Brezillon

sunxi_nfc_hw_ecc_read_chunk() always retrieves the ECC and protected free
bytes, no matter if the user really asked for it or not. This can take a
non negligible amount of time, especially on NAND chips exposing large OOB
areas (> 1KB). Make it optional.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand.c | 27 ---
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 90c121d..7b3ae72 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -869,7 +869,7 @@ static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info *mtd,
   u8 *oob, int oob_off,
   int *cur_off,
   unsigned int *max_bitflips,
-  bool bbm, int page)
+  bool bbm, bool oob_required, int page)
 {
struct nand_chip *nand = mtd_to_nand(mtd);
struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
@@ -901,7 +901,8 @@ static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info *mtd,
 
*cur_off = oob_off + ecc->bytes + 4;
 
-   ret = sunxi_nfc_hw_ecc_correct(mtd, data, oob, 0, );
+   ret = sunxi_nfc_hw_ecc_correct(mtd, data, oob_required ? oob : NULL, 0,
+  );
if (erased)
return 1;
 
@@ -929,12 +930,14 @@ static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info 
*mtd,
} else {
memcpy_fromio(data, nfc->regs + NFC_RAM0_BASE, ecc->size);
 
-   nand->cmdfunc(mtd, NAND_CMD_RNDOUT, oob_off, -1);
-   sunxi_nfc_randomizer_read_buf(mtd, oob, ecc->bytes + 4,
- true, page);
+   if (oob_required) {
+   nand->cmdfunc(mtd, NAND_CMD_RNDOUT, oob_off, -1);
+   sunxi_nfc_randomizer_read_buf(mtd, oob, ecc->bytes + 4,
+ true, page);
 
-   sunxi_nfc_hw_ecc_get_prot_oob_bytes(mtd, oob, 0,
-   bbm, page);
+   sunxi_nfc_hw_ecc_get_prot_oob_bytes(mtd, oob, 0,
+   bbm, page);
+   }
}
 
sunxi_nfc_hw_ecc_update_stats(mtd, max_bitflips, ret);
@@ -1048,7 +1051,7 @@ static int sunxi_nfc_hw_ecc_read_page(struct mtd_info 
*mtd,
ret = sunxi_nfc_hw_ecc_read_chunk(mtd, data, data_off, oob,
  oob_off + mtd->writesize,
  _off, _bitflips,
- !i, page);
+ !i, oob_required, page);
if (ret < 0)
return ret;
else if (ret)
@@ -1086,8 +1089,8 @@ static int sunxi_nfc_hw_ecc_read_subpage(struct mtd_info 
*mtd,
ret = sunxi_nfc_hw_ecc_read_chunk(mtd, data, data_off,
  oob,
  oob_off + mtd->writesize,
- _off, _bitflips,
- !i, page);
+ _off, _bitflips, !i,
+ false, page);
if (ret < 0)
return ret;
}
@@ -1149,7 +1152,9 @@ static int sunxi_nfc_hw_syndrome_ecc_read_page(struct 
mtd_info *mtd,
 
ret = sunxi_nfc_hw_ecc_read_chunk(mtd, data, data_off, oob,
  oob_off, _off,
- _bitflips, !i, page);
+ _bitflips, !i,
+ oob_required,
+ page);
if (ret < 0)
return ret;
else if (ret)
-- 
2.1.4

--
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

[PATCH 3/7] mtd: nand: sunxi: make cur_off parameter optional in extra oob helpers

2016-03-08 Thread Boris Brezillon

Allow for NULL cur_offs values when the caller does not know where the
NAND page register pointer point to.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 7b3ae72..07c3af7 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -957,7 +957,7 @@ static void sunxi_nfc_hw_ecc_read_extra_oob(struct mtd_info 
*mtd,
if (len <= 0)
return;
 
-   if (*cur_off != offset)
+   if (!cur_off || *cur_off != offset)
nand->cmdfunc(mtd, NAND_CMD_RNDOUT,
  offset + mtd->writesize, -1);
 
@@ -967,7 +967,8 @@ static void sunxi_nfc_hw_ecc_read_extra_oob(struct mtd_info 
*mtd,
sunxi_nfc_randomizer_read_buf(mtd, oob + offset, len,
  false, page);
 
-   *cur_off = mtd->oobsize + mtd->writesize;
+   if (cur_off)
+   *cur_off = mtd->oobsize + mtd->writesize;
 }
 
 static int sunxi_nfc_hw_ecc_write_chunk(struct mtd_info *mtd,
@@ -1022,13 +1023,14 @@ static void sunxi_nfc_hw_ecc_write_extra_oob(struct 
mtd_info *mtd,
if (len <= 0)
return;
 
-   if (*cur_off != offset)
+   if (!cur_off || *cur_off != offset)
nand->cmdfunc(mtd, NAND_CMD_RNDIN,
  offset + mtd->writesize, -1);
 
sunxi_nfc_randomizer_write_buf(mtd, oob + offset, len, false, page);
 
-   *cur_off = mtd->oobsize + mtd->writesize;
+   if (cur_off)
+   *cur_off = mtd->oobsize + mtd->writesize;
 }
 
 static int sunxi_nfc_hw_ecc_read_page(struct mtd_info *mtd,
-- 
2.1.4

--
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: videobuf2-dma-sg and multiple planes semantics

2016-03-08 Thread Robert Jarzmik

Hans Verkuil  writes:

> Hi Robert,
>
> In the case of PIX_FMT_YUV422P there is only *one* buffer and the planes are 
> laid out in
> that single buffer. So from the point of view of v4l2/vb2 this is a single 
> planar
> format and you have a single sglist.h
That's the piece of information I was missing, thanks.

> You'll have to use sg_split() to split up that single large sglist into 
> three, one for
> each channel.
Yeah, being the author of it, I should be able to use it again :)

Cheers.

--
Robert
--
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: Kernel docs: muddying the waters a bit

2016-03-08 Thread Jani Nikula

On Tue, 08 Mar 2016, Dan Allen  wrote:
> One of the key goals of the Asciidoctor project is to be able to directly
> produce a wide variety of outputs from the same source (without DocBook).
> We've added flexibility and best practices into the syntax and matured the
> converter mechanism to bridge this (sometimes very wide) gap.

I think our conclusion so far was that the native AsciiDoc (and
Asciidoctor) outputs fell short of our needs, forcing us to use the
DocBook pipeline. I, for one, was hoping we could eventually simplify
the toolchain. For example, there was no support for chunked, or split
to chapters, HTML, and the single page result was simply way too big.

> Asciidoctor is the future of AsciiDoc. Even the AsciiDoc Python maintainers
> acknowledge that (including the original creator).

Thanks for the input. We've touched the topic of AsciiDoc
vs. Asciidoctor before [1]. So we should be using Asciidoctor instead of
AsciiDoc. That actually makes choosing asciidoc harder, because
requiring another language environment complicates, not simplifies, the
toolchain. I'd really like to lower the bar for building the
documentation, for everyone, so much so that it becomes part of the
normal checks for patch inclusion.

BR,
Jani.

[1] http://mid.gmane.org/86pow31ddj@hiro.keithp.com

-- 
Jani Nikula, Intel Open Source Technology Center
--
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: videobuf2-dma-sg and multiple planes semantics

2016-03-08 Thread Hans Verkuil

Hi Robert,

On 03/07/16 19:08, Robert Jarzmik wrote:
> Robert Jarzmik  writes:
> 
>> Hi,
>>
>> I've been converting pxa_camera driver from videobuf to videobuf2, and I 
>> have a
>> question about multiple plane semantics.
>>
>> I have a case where I have 3 planes for a yuv422 capture :
>>  - 1 Y plane (total_size / 2 bytes)
>>  - 1 U plane (total_size / 4 bytes)
>>  - 1 V plane (total_size / 4 bytes)
>>
>> I would have expected vb2_dma_sg_plane_desc(vb, i) to return me 3 different
>> sg_tables, one for each plane. I would have been then able to feed them to 3
>> dmaengine channels (this is the case for pxa27x platform), so that the 3 
>> planes
>> are filled in concurrently.
>>
>> My understanding is that videobuf2-dma-sg has only 1 sg_table, which seems 
>> to be
>> enforced by vb2_dma_sg_cookie(), so the question is : is it on purpose, and 
>> how
>> do the multiple planes are handled within videobuf2-dma-sg ?
> 
> Oh I think I was a bit mislead, because I was looking at it from a userspace
> perspective. The in-kernel pxa_camera has 3 different sg_tables all right.
> 
> The issue is rather that from userspace, the call to VIDIOC_QUERYBUF, which is
> an old userspace program (such as capture_example.c, year 2008 version), 
> returns
> only half of the total_size.
> 
> Now looking at it more closely, I think this is because :
>  - in videobuf2-v4l2.c
>  - as my old program doesn't set the V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE bit
>  - __fill_v4l2_buffer() returns b->length = vb->planes[0].length
> 
> I would have expected to have b->length = sum(vb->planes[i].length).
> 
> Could someone explain to me the rationale behind returning only the first 
> plane
> length instead of the sum of all planes lengthes ?

I think the cause of your confusion is what 'multi-planar' means in the v4l2 
context.
The multi-planar formats are formats that have more than one plane where each 
plane
can be anywhere in memory. So two or three buffers are allocated separately and
each buffer has its own sglist (setup by vb2).

In the case of PIX_FMT_YUV422P there is only *one* buffer and the planes are 
laid out in
that single buffer. So from the point of view of v4l2/vb2 this is a single 
planar
format and you have a single sglist.

You'll have to use sg_split() to split up that single large sglist into three, 
one for
each channel.

An alternative might be to switch to use V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE and 
use
V4L2_PIX_FMT_YUV422M instead of PIX_FMT_YUV422P, but that would affect existing
applications that expect single planar formats and I cannot recommend this.

Especially since the sg_split function already exists, so it is not hard to 
split
the single sglist into three.

Regards,

Hans
--
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: [PATCH v2] media: sh_mobile_ceu_camera: Remove dependency on SUPERH

2016-03-08 Thread Geert Uytterhoeven

On Tue, Mar 8, 2016 at 2:03 AM, Simon Horman  wrote:
> A dependency on ARCH_SHMOBILE seems to be the best option for
> sh_mobile_ceu_camera:
>
> * For Super H based SoCs: sh_mobile_ceu is used on SH_AP325RXA, SH_ECOVEC,
>   SH_KFR2R09, SH_MIGOR, and SH_7724_SOLUTION_ENGINE which depend on
>   CPU_SUBTYPE_SH7722, CPU_SUBTYPE_SH7723, or CPU_SUBTYPE_SH7724 which all
>   select ARCH_SHMOBILE.
>
> * For ARM Based SoCs: Since the removal of legacy (non-multiplatform)
>   support this driver has not been used by any Renesas ARM based SoCs.
>   The Renesas ARM based SoCs currently select ARCH_SHMOBILE, however,
>   it is planned that this will no longer be the case.
>
> This is part of an ongoing process to migrate from ARCH_SHMOBILE to
> ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
> appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
>
> Thanks to Geert Uytterhoeven for analysis and portions of the
> change log text.
>
> Cc: Geert Uytterhoeven 
> Signed-off-by: Simon Horman 

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: [PATCH v2] media: rcar_vin: Use ARCH_RENESAS

2016-03-08 Thread Geert Uytterhoeven

On Tue, Mar 8, 2016 at 2:03 AM, Simon Horman  wrote:
> Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.
>
> This is part of an ongoing process to migrate from ARCH_SHMOBILE to
> ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
> appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
>
> Signed-off-by: Simon Horman 

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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

cron job: media_tree daily build: OK

[PATCH] Revert "[media] au0828: use v4l2_mc_create_media_graph()"

Re: i.mx6 camera interface (CSI) and mainline kernel

Re: HVR-850 2040:b140 fails to initialize

HVR-850 2040:b140 fails to initialize

[RFC 4/7] drivers/media/pci/zoran: avoid fragile snprintf use

[RFC 6/7] [media] ati_remote: avoid fragile snprintf use

Re: [PATCH 4/7] scatterlist: add sg_alloc_table_from_buf() helper

Re: [PATCH 4/7] scatterlist: add sg_alloc_table_from_buf() helper

Re: Question regarding internal webcams of tablet devices

Question regarding internal webcams of tablet devices

Re: Kernel docs: muddying the waters a bit

Re: [PATCH 5/7] mtd: provide helper to prepare buffers for DMA operations

Re: Build regressions/improvements in v4.5-rc7

[PATCH] [media] em28xx_dvb: add support for PLEX PX-BCUD (ISDB-S usb dongle)

Re: [PATCH 5/7] mtd: provide helper to prepare buffers for DMA operations

Re: Kernel docs: muddying the waters a bit

Re: Kernel docs: muddying the waters a bit

Re: Kernel docs: muddying the waters a bit

Re: Kernel docs: muddying the waters a bit

[PATCH 0/7] mtd: nand: sunxi: add support for DMA operations

[PATCH 4/7] scatterlist: add sg_alloc_table_from_buf() helper

[PATCH 7/7] mtd: nand: sunxi: update DT bindings

[PATCH 6/7] mtd: nand: sunxi: add support for DMA assisted operations

[PATCH 1/7] mtd: nand: sunxi: move some ECC related operations to their own functions

[PATCH 2/7] mtd: nand: sunxi: make OOB retrieval optional

[PATCH 3/7] mtd: nand: sunxi: make cur_off parameter optional in extra oob helpers

Re: videobuf2-dma-sg and multiple planes semantics

Re: Kernel docs: muddying the waters a bit

Re: videobuf2-dma-sg and multiple planes semantics

Re: [PATCH v2] media: sh_mobile_ceu_camera: Remove dependency on SUPERH

Re: [PATCH v2] media: rcar_vin: Use ARCH_RENESAS

32 matches

Site Navigation

Mail list logo

Footer information