cron job: media_tree daily build: WARNINGS
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 Apr 12 05:00:15 CEST 2017 media-tree git hash:4aed35ca73f6d9cfd5f7089ba5d04f5fb8623080 media_build git hash: 8a44f033b9899e3193da85b1d3369a9dbfcc9eab v4l-utils git hash: e748123b973e899cd6f0c08272a165661bd8386f gcc version:i686-linux-gcc (GCC) 6.2.0 sparse version: v0.5.0-3553-g78b2ea6 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.9.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: 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: WARNINGS linux-3.11.1-i686: OK linux-3.12.67-i686: OK linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0.9-i686: WARNINGS linux-4.1.33-i686: WARNINGS linux-4.2.8-i686: WARNINGS linux-4.3.6-i686: WARNINGS linux-4.4.22-i686: WARNINGS linux-4.5.7-i686: WARNINGS linux-4.6.7-i686: WARNINGS linux-4.7.5-i686: WARNINGS linux-4.8-i686: OK linux-4.9-i686: OK linux-4.10.1-i686: OK linux-4.11-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: WARNINGS linux-3.11.1-x86_64: OK linux-3.12.67-x86_64: OK linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: WARNINGS linux-3.18.7-x86_64: WARNINGS linux-3.19-x86_64: WARNINGS linux-4.0.9-x86_64: WARNINGS linux-4.1.33-x86_64: WARNINGS linux-4.2.8-x86_64: WARNINGS linux-4.3.6-x86_64: WARNINGS linux-4.4.22-x86_64: WARNINGS linux-4.5.7-x86_64: WARNINGS linux-4.6.7-x86_64: WARNINGS linux-4.7.5-x86_64: WARNINGS linux-4.8-x86_64: WARNINGS linux-4.9-x86_64: WARNINGS linux-4.10.1-x86_64: WARNINGS linux-4.11-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse: WARNINGS 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/index.html
Re: [PATCH v6 17/39] platform: add video-multiplexer subdevice driver
On 04/04/2017 05:47 AM, Sakari Ailus wrote:
Hi Steve, Philipp and Pavel,
On Mon, Mar 27, 2017 at 05:40:34PM -0700, Steve Longerbeam wrote:
From: Philipp Zabel
This driver can handle SoC internal and external video bus multiplexers,
controlled either by register bit fields or by a GPIO. The subdevice
passes through frame interval and mbus configuration of the active input
to the output side.
The MUX framework is already in linux-next. Could you use that instead of
adding new driver + bindings that are not compliant with the MUX framework?
I don't think it'd be much of a change in terms of code, using the MUX
framework appears quite simple.
I would prefer to wait on this, and get what we have merged now so I can
unload all these patches first.
Also this is Philipp's driver, so again I would prefer to get this
merged as-is and then Philipp can address these issues in a future
patch. But I will add my comments below...
In general the driver looks pretty good, especially regarding the user space
API implementation which is important for use with other drivers.
I have some more detailed comments below.
+
+struct vidsw {
+ struct v4l2_subdev subdev;
+ unsigned int num_pads;
You could use subdev.entity.num_pads instead of caching the value locally.
Agreed.
+ struct media_pad *pads;
+ struct v4l2_mbus_framefmt *format_mbus;
+ struct v4l2_of_endpoint *endpoint;
+ struct regmap_field *field;
+ struct gpio_desc *gpio;
+ int active;
+};
+
+static inline struct vidsw *v4l2_subdev_to_vidsw(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct vidsw, subdev);
+}
+
+static void vidsw_set_active(struct vidsw *vidsw, int active)
+{
+ vidsw->active = active;
+ if (active < 0)
+ return;
+
+ dev_dbg(vidsw->subdev.dev, "setting %d active\n", active);
+
+ if (vidsw->field)
+ regmap_field_write(vidsw->field, active);
+ else if (vidsw->gpio)
+ gpiod_set_value(vidsw->gpio, active);
+}
+
+static int vidsw_link_setup(struct media_entity *entity,
+ const struct media_pad *local,
+ const struct media_pad *remote, u32 flags)
+{
+ struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
+ struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
+
+ /* We have no limitations on enabling or disabling our output link */
+ if (local->index == vidsw->num_pads - 1)
+ return 0;
+
+ dev_dbg(sd->dev, "link setup %s -> %s", remote->entity->name,
+ local->entity->name);
+
+ if (!(flags & MEDIA_LNK_FL_ENABLED)) {
+ if (local->index == vidsw->active) {
+ dev_dbg(sd->dev, "going inactive\n");
+ vidsw->active = -1;
+ }
+ return 0;
+ }
+
+ if (vidsw->active >= 0) {
+ struct media_pad *pad;
+
+ if (vidsw->active == local->index)
+ return 0;
+
+ pad = media_entity_remote_pad(&vidsw->pads[vidsw->active]);
+ if (pad) {
+ struct media_link *link;
+ int ret;
+
+ link = media_entity_find_link(pad,
+ &vidsw->pads[vidsw->active]);
+ if (link) {
+ ret = __media_entity_setup_link(link, 0);
I wouldn't implicitly disable a link, even if only one can be active at a
given time. No other drivers do that either.
Perhaps returning an error might be a better thing to do: if you're
reconfiguring the pipeline anyway, there are likely issues elsewhere in it.
We could also change the behaviour later to allow implicit changes but we
can't later on go the other way without breaking the user space.
I think this whole if (vidsw->active >= 0) { ... } block should be
removed. This is left-over from the first implementation that tried
to propagate link setup upstream. This is not working yet, so for now
I think this should be removed.
+
+static bool vidsw_endpoint_disabled(struct device_node *ep)
+{
+ struct device_node *rpp;
+
+ if (!of_device_is_available(ep))
ep here is the endpoint, whereas the argument to of_device_is_available()
should correspond to the actual device.
Agreed, I think this if statement should be removed, and...
+ return true;
+
+ rpp = of_graph_get_remote_port_parent(ep);
+ if (!rpp)
+ return true;
this if statement can also be removed, since that is
handled automatically by of_device_is_available() below.
+
+ return !of_device_is_available(rpp);
+}
+
+static int vidsw_async_init(struct vidsw *vidsw, struct device_node *node)
I think I'd arrange this closer to probe as it's related to probe directly.
Up to you.
+{
+ struct device_node *ep;
+ u32 portno;
+
Re: [PATCH v3 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding
Hello, On Thursday 16 Feb 2017 11:02:55 Ramesh Shanmugasundaram wrote: > Hi Rob, > > Thank you for the review comments. > > > Subject: Re: [PATCH v3 6/7] dt-bindings: media: Add Renesas R-Car DRIF > > binding > > > > On Tue, Feb 07, 2017 at 03:02:36PM +, Ramesh Shanmugasundaram wrote: > >> Add binding documentation for Renesas R-Car Digital Radio Interface > >> (DRIF) controller. > >> > >> Signed-off-by: Ramesh Shanmugasundaram > >> > >> --- > >> > >> .../devicetree/bindings/media/renesas,drif.txt | 186 ++ > >> 1 file changed, 186 insertions(+) > >> create mode 100644 > >> > >> Documentation/devicetree/bindings/media/renesas,drif.txt > >> > >> diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt > >> b/Documentation/devicetree/bindings/media/renesas,drif.txt > >> new file mode 100644 > >> index 000..6315609 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt > >> @@ -0,0 +1,186 @@ > >> +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF) > >> + > >> + > >> +R-Car Gen3 DRIF is a SPI like receive only slave device. A general > >> +representation of DRIF interfacing with a master device is shown below. > >> + > >> ++-++-+ > >> +| |-SCK--->|CLK | > >> +| Master|-SS>|SYNC DRIFn (slave) | > >> +| |-SD0--->|D0 | > >> +| |-SD1--->|D1 | > >> ++-++-+ > >> + > >> +As per the datasheet, each DRIF channel (drifn) is made up of two > >> +internal channels (drifn0 & drifn1). These two internal channels > >> +share the common CLK & SYNC. Each internal channel has its own > >> +dedicated resources like irq, dma channels, address space & clock. > >> +This internal split is not visible to the external master device. > >> + > >> +The device tree model represents each internal channel as a separate > >> node. > >> +The internal channels sharing the CLK & SYNC are tied together by > >> +their phandles using a new property called "renesas,bonding". For the > >> +rest of the documentation, unless explicitly stated, the word channel > >> +implies an internal channel. > >> + > >> +When both internal channels are enabled they need to be managed > >> +together as one (i.e.) they cannot operate alone as independent > >> +devices. Out of the two, one of them needs to act as a primary device > >> +that accepts common properties of both the internal channels. This > >> +channel is identified by a new property called "renesas,primary-bond". > >> + > >> +To summarize, > >> + - When both the internal channels that are bonded together are > >> enabled, > >> + the zeroth channel is selected as primary-bond. This channels > >> accepts > >> + properties common to all the members of the bond. > >> + - When only one of the bonded channels need to be enabled, the > >> property > >> + "renesas,bonding" or "renesas,primary-bond" will have no effect. > >> That > >> + enabled channel can act alone as any other independent device. > >> + > >> +Required properties of an internal channel: > >> +--- > >> +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of > >> R8A7795 SoC. > >> +"renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible > >> device. > >> +When compatible with the generic version, nodes must list the > >> +SoC-specific version corresponding to the platform first > >> +followed by the generic version. > >> +- reg: offset and length of that channel. > >> +- interrupts: associated with that channel. > >> +- clocks: phandle and clock specifier of that channel. > >> +- clock-names: clock input name string: "fck". > >> +- dmas: phandles to the DMA channels. > >> +- dma-names: names of the DMA channel: "rx". > >> +- renesas,bonding: phandle to the other channel. > >> + > >> +Optional properties of an internal channel: > >> +--- > >> +- power-domains: phandle to the respective power domain. > >> + > >> +Required properties of an internal channel when: > >> + - It is the only enabled channel of the bond (or) > >> + - If it acts as primary among enabled bonds > >> + > >> +- pinctrl-0: pin control group to be used for this channel. > >> +- pinctrl-names: must be "default". > >> +- renesas,primary-bond: empty property indicating the channel acts as > >> primary > >> + among the bonded channels. > >> +- port: child port node of a channel that defines the local and remote > >> + endpoints. The remote endpoint is assumed to be a third party tuner > >> + device endpoint. > >> + > >> +Optional endpoint pro
Re: [PATCH v3 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding
Hi Ramesh, Thank you for the patch. On Tuesday 07 Feb 2017 15:02:36 Ramesh Shanmugasundaram wrote: > Add binding documentation for Renesas R-Car Digital Radio Interface > (DRIF) controller. > > Signed-off-by: Ramesh Shanmugasundaram > > --- > .../devicetree/bindings/media/renesas,drif.txt | 186 ++ > 1 file changed, 186 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt > > diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt > b/Documentation/devicetree/bindings/media/renesas,drif.txt new file mode > 100644 > index 000..6315609 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt > @@ -0,0 +1,186 @@ > +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF) > + > + > +R-Car Gen3 DRIF is a SPI like receive only slave device. A general > +representation of DRIF interfacing with a master device is shown below. > + > ++-++-+ > +| |-SCK--->|CLK | > +| Master|-SS>|SYNC DRIFn (slave) | > +| |-SD0--->|D0 | > +| |-SD1--->|D1 | > ++-++-+ > + > +As per the datasheet, each DRIF channel (drifn) is made up of two internal > +channels (drifn0 & drifn1). These two internal channels share the common > +CLK & SYNC. Each internal channel has its own dedicated resources like > +irq, dma channels, address space & clock. This internal split is not > +visible to the external master device. > + > +The device tree model represents each internal channel as a separate node. > +The internal channels sharing the CLK & SYNC are tied together by their > +phandles using a new property called "renesas,bonding". For the rest of > +the documentation, unless explicitly stated, the word channel implies an > +internal channel. > + > +When both internal channels are enabled they need to be managed together > +as one (i.e.) they cannot operate alone as independent devices. Out of the > +two, one of them needs to act as a primary device that accepts common > +properties of both the internal channels. This channel is identified by a > +new property called "renesas,primary-bond". > + > +To summarize, > + - When both the internal channels that are bonded together are enabled, > + the zeroth channel is selected as primary-bond. This channels accepts > + properties common to all the members of the bond. > + - When only one of the bonded channels need to be enabled, the property > + "renesas,bonding" or "renesas,primary-bond" will have no effect. That > + enabled channel can act alone as any other independent device. > + > +Required properties of an internal channel: > +--- > +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of > R8A7795 SoC. > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible > device. > + When compatible with the generic version, nodes must list the > + SoC-specific version corresponding to the platform first > + followed by the generic version. > +- reg: offset and length of that channel. > +- interrupts: associated with that channel. > +- clocks: phandle and clock specifier of that channel. > +- clock-names: clock input name string: "fck". > +- dmas: phandles to the DMA channels. > +- dma-names: names of the DMA channel: "rx". > +- renesas,bonding: phandle to the other channel. > + > +Optional properties of an internal channel: > +--- > +- power-domains: phandle to the respective power domain. > + > +Required properties of an internal channel when: > + - It is the only enabled channel of the bond (or) > + - If it acts as primary among enabled bonds > + > +- pinctrl-0: pin control group to be used for this channel. > +- pinctrl-names: must be "default". > +- renesas,primary-bond: empty property indicating the channel acts as > primary > + among the bonded channels. > +- port: child port node of a channel that defines the local and remote > + endpoints. The remote endpoint is assumed to be a third party tuner > + device endpoint. You should refer to the OF graphs bindings here. How about the following to document the port node ? - port: child port node corresponding to the data input, in accordance with the video interface bindings defined in Documentation/devicetree/bindings/media/video-interfaces.txt. The port node must contain at least one endpoint. > +Optional endpoint property: > +--- > +- renesas,sync-active : Indicates sync signal polarity, 0/1 for low/high > + respec
Re: [PATCH v3 7/7] media: platform: rcar_drif: Add DRIF support
Hi Ramesh,
Thank you for the patch.
On Tuesday 07 Feb 2017 15:02:37 Ramesh Shanmugasundaram wrote:
> This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 SoCs.
> The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
> device represents a channel and each channel can have one or two
> sub-channels respectively depending on the target board.
>
> DRIF supports only Rx functionality. It receives samples from a RF
> frontend tuner chip it is interfaced with. The combination of DRIF and the
> tuner device, which is registered as a sub-device, determines the receive
> sample rate and format.
>
> In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
> the tuner device, which can be provided by a third party vendor. DRIF acts
> as a slave device and the tuner device acts as a master transmitting the
> samples. The driver allows asynchronous binding of a tuner device that
> is registered as a v4l2 sub-device. The driver can learn about the tuner
> it is interfaced with based on port endpoint properties of the device in
> device tree. The V4L2 SDR device inherits the controls exposed by the
> tuner device.
>
> The device can also be configured to use either one or both of the data
> pins at runtime based on the master (tuner) configuration.
>
> Signed-off-by: Ramesh Shanmugasundaram
>
> ---
> drivers/media/platform/Kconfig | 25 +
> drivers/media/platform/Makefile|1 +
> drivers/media/platform/rcar_drif.c | 1534 +
> 3 files changed, 1560 insertions(+)
> create mode 100644 drivers/media/platform/rcar_drif.c
[snip]
> diff --git a/drivers/media/platform/rcar_drif.c
> b/drivers/media/platform/rcar_drif.c new file mode 100644
> index 000..88950e3
> --- /dev/null
> +++ b/drivers/media/platform/rcar_drif.c
> @@ -0,0 +1,1534 @@
[snip]
> +/*
> + * The R-Car DRIF is a receive only MSIOF like controller with an
> + * external master device driving the SCK. It receives data into a FIFO,
> + * then this driver uses the SYS-DMAC engine to move the data from
> + * the device to memory.
> + *
> + * Each DRIF channel DRIFx (as per datasheet) contains two internal
> + * channels DRIFx0 & DRIFx1 within itself with each having its own
> resources
> + * like module clk, register set, irq and dma. These internal channels
> share
> + * common CLK & SYNC from master. The two data pins D0 & D1 shall be
> + * considered to represent the two internal channels. This internal split
> + * is not visible to the master device.
> + *
> + * Depending on the master device, a DRIF channel can use
> + * (1) both internal channels (D0 & D1) to receive data in parallel (or)
> + * (2) one internal channel (D0 or D1) to receive data
> + *
> + * The primary design goal of this controller is to act as Digitial Radio
s/Digitial/Digital/
> + * Interface that receives digital samples from a tuner device. Hence the
> + * driver exposes the device as a V4L2 SDR device. In order to qualify as
> + * a V4L2 SDR device, it should possess tuner interface as mandated by the
> + * framework. This driver expects a tuner driver (sub-device) to bind
> + * asynchronously with this device and the combined drivers shall expose
> + * a V4L2 compliant SDR device. The DRIF driver is independent of the
> + * tuner vendor.
> + *
> + * The DRIF h/w can support I2S mode and Frame start synchronization pulse
> mode.
> + * This driver is tested for I2S mode only because of the availability of
> + * suitable master devices. Hence, not all configurable options of DRIF h/w
> + * like lsb/msb first, syncdl, dtdl etc. are exposed via DT and I2S
> defaults
> + * are used. These can be exposed later if needed after testing.
> + */
[snip]
> +#define to_rcar_drif_buf_pair(sdr, ch_num,
> idx) (sdr->ch[!(ch_num)]->buf[idx])
You should enclose both sdr and idx in parenthesis, as they can be
expressions.
> +
> +#define for_each_rcar_drif_channel(ch, ch_mask) \
> + for_each_set_bit(ch, ch_mask, RCAR_DRIF_MAX_CHANNEL)
> +
> +static const unsigned int num_hwbufs = 32;
Is there a specific reason to make this a static const instead of a #define ?
> +/* Debug */
> +static unsigned int debug;
> +module_param(debug, uint, 0644);
> +MODULE_PARM_DESC(debug, "activate debug info");
> +
> +#define rdrif_dbg(level, sdr, fmt, arg...) \
> + v4l2_dbg(level, debug, &sdr->v4l2_dev, fmt, ## arg)
> +
> +#define rdrif_err(sdr, fmt, arg...) \
> + dev_err(sdr->v4l2_dev.dev, fmt, ## arg)
> +
> +/* Stream formats */
> +struct rcar_drif_format {
> + u32 pixelformat;
> + u32 buffersize;
> + u32 wdlen;
> + u32 num_ch;
> +};
> +
> +/* Format descriptions for capture */
> +static const struct rcar_drif_format formats[] = {
> + {
> + .pixelformat= V4L2_SDR_FMT_PCU16BE,
> + .buffersize = RCAR_SDR_BUFFER_SIZE,
> + .wdlen = 16,
> +
[PATCH v2] staging: media/platform/bcm2835: remove gstreamer workaround
Gstreamer's v4l2src reacted poorly to certain outputs from the bcm2835
video driver's ioctl ops function vidioc_enum_framesizes, so a
workaround was created that could be activated by user input. This
workaround would replace the driver's ioctl ops struct with another,
similar struct--only with no function pointed to by
vidioc_enum_framesizes. With no response, gstreamer would attempt to
continue with some default settings that happened to work better.
However, this bug has been fixed in gstreamer since 2014, so we
shouldn't include this workaround in the stable version of the driver.
Signed-off-by: Kevin Wern
---
V2: patch against staging-next instead of torvalds/master
drivers/staging/vc04_services/bcm2835-camera/TODO | 5 --
.../vc04_services/bcm2835-camera/bcm2835-camera.c | 60 --
2 files changed, 65 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/TODO
b/drivers/staging/vc04_services/bcm2835-camera/TODO
index 61a5099..0ab9e88 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/TODO
+++ b/drivers/staging/vc04_services/bcm2835-camera/TODO
@@ -32,8 +32,3 @@ We should have VCHI create a platform device once it's
initialized,
and have this driver bind to it, so that we automatically load the
v4l2 module after VCHI loads.
-5) Drop the gstreamer workaround.
-
-This was a temporary workaround for a bug that was fixed mid-2014, and
-we should remove it before stabilizing the driver.
-
diff --git a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
index 86bbd6e..a11e047 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c
@@ -66,19 +66,6 @@ MODULE_PARM_DESC(max_video_width, "Threshold for video
mode");
module_param(max_video_height, int, 0644);
MODULE_PARM_DESC(max_video_height, "Threshold for video mode");
-/* Gstreamer bug https://bugzilla.gnome.org/show_bug.cgi?id=726521
- * v4l2src does bad (and actually wrong) things when the vidioc_enum_framesizes
- * function says type V4L2_FRMSIZE_TYPE_STEPWISE, which we do by default.
- * It's happier if we just don't say anything at all, when it then
- * sets up a load of defaults that it thinks might work.
- * If gst_v4l2src_is_broken is non-zero, then we remove the function from
- * our function table list (actually switch to an alternate set, but same
- * result).
- */
-static int gst_v4l2src_is_broken;
-module_param(gst_v4l2src_is_broken, int, 0644);
-MODULE_PARM_DESC(gst_v4l2src_is_broken, "If non-zero, enable workaround for
Gstreamer");
-
/* global device data array */
static struct bm2835_mmal_dev *gdev[MAX_BCM2835_CAMERAS];
@@ -1454,48 +1441,6 @@ static const struct v4l2_ioctl_ops camera0_ioctl_ops = {
.vidioc_unsubscribe_event = v4l2_event_unsubscribe,
};
-static const struct v4l2_ioctl_ops camera0_ioctl_ops_gstreamer = {
- /* overlay */
- .vidioc_enum_fmt_vid_overlay = vidioc_enum_fmt_vid_overlay,
- .vidioc_g_fmt_vid_overlay = vidioc_g_fmt_vid_overlay,
- .vidioc_try_fmt_vid_overlay = vidioc_try_fmt_vid_overlay,
- .vidioc_s_fmt_vid_overlay = vidioc_s_fmt_vid_overlay,
- .vidioc_overlay = vidioc_overlay,
- .vidioc_g_fbuf = vidioc_g_fbuf,
-
- /* inputs */
- .vidioc_enum_input = vidioc_enum_input,
- .vidioc_g_input = vidioc_g_input,
- .vidioc_s_input = vidioc_s_input,
-
- /* capture */
- .vidioc_querycap = vidioc_querycap,
- .vidioc_enum_fmt_vid_cap = vidioc_enum_fmt_vid_cap,
- .vidioc_g_fmt_vid_cap = vidioc_g_fmt_vid_cap,
- .vidioc_try_fmt_vid_cap = vidioc_try_fmt_vid_cap,
- .vidioc_s_fmt_vid_cap = vidioc_s_fmt_vid_cap,
-
- /* buffer management */
- .vidioc_reqbufs = vb2_ioctl_reqbufs,
- .vidioc_create_bufs = vb2_ioctl_create_bufs,
- .vidioc_prepare_buf = vb2_ioctl_prepare_buf,
- .vidioc_querybuf = vb2_ioctl_querybuf,
- .vidioc_qbuf = vb2_ioctl_qbuf,
- .vidioc_dqbuf = vb2_ioctl_dqbuf,
- /* Remove this function ptr to fix gstreamer bug
-* .vidioc_enum_framesizes = vidioc_enum_framesizes,
-*/
- .vidioc_enum_frameintervals = vidioc_enum_frameintervals,
- .vidioc_g_parm= vidioc_g_parm,
- .vidioc_s_parm= vidioc_s_parm,
- .vidioc_streamon = vb2_ioctl_streamon,
- .vidioc_streamoff = vb2_ioctl_streamoff,
-
- .vidioc_log_status = v4l2_ctrl_log_status,
- .vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
- .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
-};
-
/* --
* Driver init/finalise
* --
@@ -1811,11 +1756,6 @@ static int __init bm2835_mmal_init_device(struct
bm2835_mmal_dev *dev,
int ret;
*vfd = vdev_template;
- if (gst_v4l2src_i
Re: [PATCH v2 00/21] Convert USB documentation to ReST format
On Tue, 11 Apr 2017 16:58:40 +0200 Greg Kroah-Hartman wrote: > Nope, they don't apply to my tree, it was probably based on yours. And > the first two are ones I shouldn't be taking. > > So, feel free to take all of these with a: > Acked-by: Greg Kroah-Hartman > for the USB-related patches (2-21). I have now done that. Thanks, Mauro! jon
Re: [PATCH v2 00/21] Convert USB documentation to ReST format
On Tue, Apr 11, 2017 at 03:36:39PM -0300, Mauro Carvalho Chehab wrote: > Em Tue, 11 Apr 2017 16:58:40 +0200 > Greg Kroah-Hartman escreveu: > > > On Sat, Apr 08, 2017 at 10:04:33PM +0200, Greg Kroah-Hartman wrote: > > > On Sat, Apr 08, 2017 at 11:23:28AM -0600, Jonathan Corbet wrote: > > > > On Wed, 5 Apr 2017 10:22:54 -0300 > > > > Mauro Carvalho Chehab wrote: > > > > > > > > > Currently, there are several USB core documents that are at either > > > > > written in plain text or in DocBook format. Convert them to ReST > > > > > and add to the driver-api book. > > > > > > > > Greg, do you see any reason not to apply these for 4.12? A few of them > > > > touch comments outside of Documentation/; I'm happy to carry those or > > > > leave them to you, as you prefer. > > > > > > I'll queue them up in the next few days, thanks! > > > > Nope, they don't apply to my tree, it was probably based on yours. And > > the first two are ones I shouldn't be taking. > > Yeah, I based it at the docs-next tree. If you prefer, I can rebase > on your tree, but I guess that the docbook conversion patches > would likely conflict with some patches at docs-next, because of > the Makefile changes. Doesn't bother me, it can go through the Documentation tree as-is. thanks, greg k-h
Re: [PATCH v2 00/21] Convert USB documentation to ReST format
Em Tue, 11 Apr 2017 16:58:40 +0200 Greg Kroah-Hartman escreveu: > On Sat, Apr 08, 2017 at 10:04:33PM +0200, Greg Kroah-Hartman wrote: > > On Sat, Apr 08, 2017 at 11:23:28AM -0600, Jonathan Corbet wrote: > > > On Wed, 5 Apr 2017 10:22:54 -0300 > > > Mauro Carvalho Chehab wrote: > > > > > > > Currently, there are several USB core documents that are at either > > > > written in plain text or in DocBook format. Convert them to ReST > > > > and add to the driver-api book. > > > > > > Greg, do you see any reason not to apply these for 4.12? A few of them > > > touch comments outside of Documentation/; I'm happy to carry those or > > > leave them to you, as you prefer. > > > > I'll queue them up in the next few days, thanks! > > Nope, they don't apply to my tree, it was probably based on yours. And > the first two are ones I shouldn't be taking. Yeah, I based it at the docs-next tree. If you prefer, I can rebase on your tree, but I guess that the docbook conversion patches would likely conflict with some patches at docs-next, because of the Makefile changes. > So, feel free to take all of these with a: > Acked-by: Greg Kroah-Hartman > for the USB-related patches (2-21). > > thanks, > > greg k-h Thanks, Mauro
Re: [RFC] omap3isp: add support for CSI1 bus
On Fri 2017-03-10 14:41:31, Pavel Machek wrote:
> On Mon 2017-03-06 08:56:59, Pavel Machek wrote:
> > omap3isp: add rest of CSI1 support
> >
> > CSI1 needs one more bit to be set up. Do just that.
> >
> > Signed-off-by: Pavel Machek
> >
> > ---
> >
> > Hmm. Looking at that... num_data_lanes probably should be modified in
> > local variable, not globally like this. Should I do that?
> >
> > Anything else that needs fixing?
>
> Ping? Feedback here would be nice. This is last "interesting" piece of
> the hardware support...
Any news here? You complained that I was not pushy enough in the past
;-).
Pavel
> > index 24a9fc5..6feba36 100644
> > --- a/drivers/media/platform/omap3isp/ispccp2.c
> > +++ b/drivers/media/platform/omap3isp/ispccp2.c
> > @@ -21,6 +23,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "isp.h"
> > #include "ispreg.h"
> > @@ -1149,6 +1152,7 @@ int omap3isp_ccp2_init(struct isp_device *isp)
> > "Could not get regulator vdds_csib\n");
> > ccp2->vdds_csib = NULL;
> > }
> > + ccp2->phy = &isp->isp_csiphy2;
> > } else if (isp->revision == ISP_REVISION_15_0) {
> > ccp2->phy = &isp->isp_csiphy1;
> > }
> > diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c
> > b/drivers/media/platform/omap3isp/ispcsiphy.c
> > index 50c0f64..cd6351b 100644
> > --- a/drivers/media/platform/omap3isp/ispcsiphy.c
> > +++ b/drivers/media/platform/omap3isp/ispcsiphy.c
> > @@ -197,9 +200,10 @@ static int omap3isp_csiphy_config(struct isp_csiphy
> > *phy)
> > }
> >
> > if (buscfg->interface == ISP_INTERFACE_CCP2B_PHY1
> > - || buscfg->interface == ISP_INTERFACE_CCP2B_PHY2)
> > + || buscfg->interface == ISP_INTERFACE_CCP2B_PHY2) {
> > lanes = &buscfg->bus.ccp2.lanecfg;
> > - else
> > + phy->num_data_lanes = 1;
> > + } else
> > lanes = &buscfg->bus.csi2.lanecfg;
> >
> > /* Clock and data lanes verification */
> > @@ -302,13 +306,16 @@ int omap3isp_csiphy_acquire(struct isp_csiphy *phy)
> > if (rval < 0)
> > goto done;
> >
> > - rval = csiphy_set_power(phy, ISPCSI2_PHY_CFG_PWR_CMD_ON);
> > - if (rval) {
> > - regulator_disable(phy->vdd);
> > - goto done;
> > + if (phy->isp->revision == ISP_REVISION_15_0) {
> > + rval = csiphy_set_power(phy, ISPCSI2_PHY_CFG_PWR_CMD_ON);
> > + if (rval) {
> > + regulator_disable(phy->vdd);
> > + goto done;
> > + }
> > +
> > + csiphy_power_autoswitch_enable(phy, true);
> > }
> >
> > - csiphy_power_autoswitch_enable(phy, true);
> > phy->phy_in_use = 1;
> >
> > done:
> >
>
>
>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCHv3 13/22] staging: android: ion: Use CMA APIs directly
On 04/10/2017 11:47 PM, Laurent Pinchart wrote:
> Hi Laura,
>
> Thank you for the patch.
>
> On Monday 03 Apr 2017 11:57:55 Laura Abbott wrote:
>> When CMA was first introduced, its primary use was for DMA allocation
>> and the only way to get CMA memory was to call dma_alloc_coherent. This
>> put Ion in an awkward position since there was no device structure
>> readily available and setting one up messed up the coherency model.
>> These days, CMA can be allocated directly from the APIs. Switch to using
>> this model to avoid needing a dummy device. This also mitigates some of
>> the caching problems (e.g. dma_alloc_coherent only returning uncached
>> memory).
>
> Do we have a guarantee that the DMA mapping API, which we have to use for
> cache handling, will always support memory we allocate directly from CMA
> behind its back ?
>
CMA pages are no different than other pages allocated via the buddy
allocator. There should be no issue passing that memory to the
streaming API.
Thanks,
Laura
>> Signed-off-by: Laura Abbott
>> ---
>> drivers/staging/android/ion/Kconfig| 7 +++
>> drivers/staging/android/ion/Makefile | 3 +-
>> drivers/staging/android/ion/ion_cma_heap.c | 97 +++
>> 3 files changed, 35 insertions(+), 72 deletions(-)
>>
>> diff --git a/drivers/staging/android/ion/Kconfig
>> b/drivers/staging/android/ion/Kconfig index 206c4de..15108c4 100644
>> --- a/drivers/staging/android/ion/Kconfig
>> +++ b/drivers/staging/android/ion/Kconfig
>> @@ -10,3 +10,10 @@ menuconfig ION
>>If you're not using Android its probably safe to
>>say N here.
>>
>> +config ION_CMA_HEAP
>> +bool "Ion CMA heap support"
>> +depends on ION && CMA
>> +help
>> + Choose this option to enable CMA heaps with Ion. This heap is backed
>> + by the Contiguous Memory Allocator (CMA). If your system has these
>> + regions, you should say Y here.
>> diff --git a/drivers/staging/android/ion/Makefile
>> b/drivers/staging/android/ion/Makefile index 26672a0..66d0c4a 100644
>> --- a/drivers/staging/android/ion/Makefile
>> +++ b/drivers/staging/android/ion/Makefile
>> @@ -1,6 +1,7 @@
>> obj-$(CONFIG_ION) +=ion.o ion-ioctl.o ion_heap.o \
>> ion_page_pool.o ion_system_heap.o \
>> -ion_carveout_heap.o ion_chunk_heap.o ion_cma_heap.o
>> +ion_carveout_heap.o ion_chunk_heap.o
>> +obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
>> ifdef CONFIG_COMPAT
>> obj-$(CONFIG_ION) += compat_ion.o
>> endif
>> diff --git a/drivers/staging/android/ion/ion_cma_heap.c
>> b/drivers/staging/android/ion/ion_cma_heap.c index d562fd7..f3e0f59 100644
>> --- a/drivers/staging/android/ion/ion_cma_heap.c
>> +++ b/drivers/staging/android/ion/ion_cma_heap.c
>> @@ -19,24 +19,19 @@
>> #include
>> #include
>> #include
>> -#include
>> +#include
>> +#include
>>
>> #include "ion.h"
>> #include "ion_priv.h"
>>
>> struct ion_cma_heap {
>> struct ion_heap heap;
>> -struct device *dev;
>> +struct cma *cma;
>> };
>>
>> #define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap)
>>
>> -struct ion_cma_buffer_info {
>> -void *cpu_addr;
>> -dma_addr_t handle;
>> -struct sg_table *table;
>> -};
>> -
>>
>> /* ION CMA heap operations functions */
>> static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer
>> *buffer, @@ -44,93 +39,53 @@ static int ion_cma_allocate(struct ion_heap
>> *heap, struct ion_buffer *buffer, unsigned long flags)
>> {
>> struct ion_cma_heap *cma_heap = to_cma_heap(heap);
>> -struct device *dev = cma_heap->dev;
>> -struct ion_cma_buffer_info *info;
>> -
>> -dev_dbg(dev, "Request buffer allocation len %ld\n", len);
>> -
>> -if (buffer->flags & ION_FLAG_CACHED)
>> -return -EINVAL;
>> +struct sg_table *table;
>> +struct page *pages;
>> +int ret;
>>
>> -info = kzalloc(sizeof(*info), GFP_KERNEL);
>> -if (!info)
>> +pages = cma_alloc(cma_heap->cma, len, 0, GFP_KERNEL);
>> +if (!pages)
>> return -ENOMEM;
>>
>> -info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle),
>> -GFP_HIGHUSER | __GFP_ZERO);
>> -
>> -if (!info->cpu_addr) {
>> -dev_err(dev, "Fail to allocate buffer\n");
>> +table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
>> +if (!table)
>> goto err;
>> -}
>>
>> -info->table = kmalloc(sizeof(*info->table), GFP_KERNEL);
>> -if (!info->table)
>> +ret = sg_alloc_table(table, 1, GFP_KERNEL);
>> +if (ret)
>> goto free_mem;
>>
>> -if (dma_get_sgtable(dev, info->table, info->cpu_addr, info->handle,
>> -len))
>> -goto free_table;
>> -/* keep this for memory release */
>> -buffer->priv_virt = info;
>> -buffer->sg_table = info->table;
>> -dev_dbg(dev, "Allocate buffer %p\n", buffer);
>> +sg_set_page(table->sg
Re: [PATCH 1/5] media: rc: meson-ir: remove irq from struct meson_ir
On Tue, Apr 11, 2017 at 11:50:45AM +0200, Neil Armstrong wrote:
> On 04/11/2017 07:53 AM, Heiner Kallweit wrote:
> > The irq number is used in the probe function only, therefore just use
> > a local variable.
> >
> > Signed-off-by: Heiner Kallweit
> > ---
> > drivers/media/rc/meson-ir.c | 11 +--
> > 1 file changed, 5 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c
> > index 5576dbd6..a4128d7c 100644
> > --- a/drivers/media/rc/meson-ir.c
> > +++ b/drivers/media/rc/meson-ir.c
> > @@ -68,7 +68,6 @@
> > struct meson_ir {
> > void __iomem*reg;
> > struct rc_dev *rc;
> > - int irq;
> > spinlock_t lock;
> > };
> >
> > @@ -112,7 +111,7 @@ static int meson_ir_probe(struct platform_device *pdev)
> > struct resource *res;
> > const char *map_name;
> > struct meson_ir *ir;
> > - int ret;
> > + int irq, ret;
> >
> > ir = devm_kzalloc(dev, sizeof(struct meson_ir), GFP_KERNEL);
> > if (!ir)
> > @@ -125,10 +124,10 @@ static int meson_ir_probe(struct platform_device
> > *pdev)
> > return PTR_ERR(ir->reg);
> > }
> >
> > - ir->irq = platform_get_irq(pdev, 0);
> > - if (ir->irq < 0) {
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq < 0) {
> > dev_err(dev, "no irq resource\n");
> > - return ir->irq;
> > + return irq;
> > }
> >
> > ir->rc = rc_allocate_device(RC_DRIVER_IR_RAW);
> > @@ -158,7 +157,7 @@ static int meson_ir_probe(struct platform_device *pdev)
> > goto out_free;
> > }
> >
> > - ret = devm_request_irq(dev, ir->irq, meson_ir_irq, 0, "ir-meson", ir);
> > + ret = devm_request_irq(dev, irq, meson_ir_irq, 0, "ir-meson", ir);
> > if (ret) {
> > dev_err(dev, "failed to request irq\n");
> > goto out_unreg;
> >
>
> Hi Heiner,
>
> I'm not really convinced this is useful, if somehow for future enhancements
> we need the IRQ
> number, this will need to be reverted...
It's bad form having unused members in a struct, and if it really is needed
in some future enhancement, it is easily reintroduced in that future
enhancement patch.
Sean
Re: [PATCH v2 00/21] Convert USB documentation to ReST format
On Sat, Apr 08, 2017 at 10:04:33PM +0200, Greg Kroah-Hartman wrote: > On Sat, Apr 08, 2017 at 11:23:28AM -0600, Jonathan Corbet wrote: > > On Wed, 5 Apr 2017 10:22:54 -0300 > > Mauro Carvalho Chehab wrote: > > > > > Currently, there are several USB core documents that are at either > > > written in plain text or in DocBook format. Convert them to ReST > > > and add to the driver-api book. > > > > Greg, do you see any reason not to apply these for 4.12? A few of them > > touch comments outside of Documentation/; I'm happy to carry those or > > leave them to you, as you prefer. > > I'll queue them up in the next few days, thanks! Nope, they don't apply to my tree, it was probably based on yours. And the first two are ones I shouldn't be taking. So, feel free to take all of these with a: Acked-by: Greg Kroah-Hartman for the USB-related patches (2-21). thanks, greg k-h
[GIT PULL FOR v4.12] New ov5645 driver
The following changes since commit 4aed35ca73f6d9cfd5f7089ba5d04f5fb8623080: [media] v4l2-tpg: don't clamp XV601/709 to lim range (2017-04-10 14:58:06 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git ov5645 for you to fetch changes up to 7dbf0345e6d4ca1ba7af572e6d6722bac3f22db2: media: Add a driver for the ov5645 camera sensor. (2017-04-11 15:19:07 +0200) Todor Tomov (2): media: i2c/ov5645: add the device tree binding document media: Add a driver for the ov5645 camera sensor. Documentation/devicetree/bindings/media/i2c/ov5645.txt | 54 drivers/media/i2c/Kconfig | 12 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/ov5645.c | 1345 4 files changed, 1412 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5645.txt create mode 100644 drivers/media/i2c/ov5645.c
[GIT PULL FOR v4.12] Remaining vsp patches, V4L2_CTRL_FLAG_MODIFY_LAYOUT support
Hi Mauro, These are the remaining vsp1 patches, plus the V4L2_CTRL_FLAG_MODIFY_LAYOUT control & documentation and the buffer.rst documentation improvements. Regards, Hans The following changes since commit 4aed35ca73f6d9cfd5f7089ba5d04f5fb8623080: [media] v4l2-tpg: don't clamp XV601/709 to lim range (2017-04-10 14:58:06 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git vsp1 for you to fetch changes up to e387b8ba72a471b471b977ccee21f63dd0f7c9f4: vsp1: set V4L2_CTRL_FLAG_MODIFY_LAYOUT for histogram controls (2017-04-11 15:22:27 +0200) Hans Verkuil (5): vidioc-queryctrl.rst: document V4L2_CTRL_FLAG_MODIFY_LAYOUT videodev.h: add V4L2_CTRL_FLAG_MODIFY_LAYOUT v4l2-ctrls.c: set V4L2_CTRL_FLAG_MODIFY_LAYOUT for ROTATE buffer.rst: clarify how V4L2_CTRL_FLAG_MODIFY_LAYOUT/GRABBER are used vsp1: set V4L2_CTRL_FLAG_MODIFY_LAYOUT for histogram controls Laurent Pinchart (8): v4l: Clearly document interactions between formats, controls and buffers v4l: vsp1: wpf: Implement rotation support v4l: Add metadata buffer type and format v4l: vsp1: Add histogram support v4l: vsp1: Support histogram generators in pipeline configuration v4l: vsp1: Fix HGO and HGT routing register addresses v4l: Define a pixel format for the R-Car VSP1 1-D histogram engine v4l: vsp1: Add HGO support Niklas Söderlund (2): v4l: Define a pixel format for the R-Car VSP1 2-D histogram engine v4l: vsp1: Add HGT support Documentation/media/uapi/v4l/buffer.rst | 122 Documentation/media/uapi/v4l/dev-meta.rst | 58 ++ Documentation/media/uapi/v4l/devices.rst | 1 + Documentation/media/uapi/v4l/meta-formats.rst | 16 +++ Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst | 168 +++ Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst | 120 +++ Documentation/media/uapi/v4l/pixfmt.rst | 1 + Documentation/media/uapi/v4l/vidioc-querycap.rst | 3 + Documentation/media/uapi/v4l/vidioc-queryctrl.rst | 13 +++ Documentation/media/videodev2.h.rst.exceptions| 3 + drivers/media/platform/Kconfig| 1 + drivers/media/platform/vsp1/Makefile | 1 + drivers/media/platform/vsp1/vsp1.h| 6 + drivers/media/platform/vsp1/vsp1_drm.c| 2 +- drivers/media/platform/vsp1/vsp1_drv.c| 70 +-- drivers/media/platform/vsp1/vsp1_entity.c | 154 ++--- drivers/media/platform/vsp1/vsp1_entity.h | 8 +- drivers/media/platform/vsp1/vsp1_hgo.c| 230 drivers/media/platform/vsp1/vsp1_hgo.h| 45 drivers/media/platform/vsp1/vsp1_hgt.c| 222 +++ drivers/media/platform/vsp1/vsp1_hgt.h| 42 +++ drivers/media/platform/vsp1/vsp1_histo.c | 646 ++ drivers/media/platform/vsp1/vsp1_histo.h | 84 ++ drivers/media/platform/vsp1/vsp1_pipe.c | 38 +- drivers/media/platform/vsp1/vsp1_pipe.h | 4 + drivers/media/platform/vsp1/vsp1_regs.h | 33 +- drivers/media/platform/vsp1/vsp1_rpf.c| 2 +- drivers/media/platform/vsp1/vsp1_rwpf.c | 5 + drivers/media/platform/vsp1/vsp1_rwpf.h | 7 +- drivers/media/platform/vsp1/vsp1_video.c | 42 +-- drivers/media/platform/vsp1/vsp1_wpf.c| 205 + drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 19 +++ drivers/media/v4l2-core/v4l2-ctrls.c | 4 + drivers/media/v4l2-core/v4l2-dev.c| 16 ++- drivers/media/v4l2-core/v4l2-ioctl.c | 36 ++ drivers/media/v4l2-core/videobuf2-v4l2.c | 3 + include/media/v4l2-ioctl.h| 17 +++ include/trace/events/v4l2.h | 1 + include/uapi/linux/videodev2.h| 18 +++ 39 files changed, 2364 insertions(+), 102 deletions(-) create mode 100644 Documentation/media/uapi/v4l/dev-meta.rst create mode 100644 Documentation/media/uapi/v4l/meta-formats.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst create mode 100644 drivers/media/platform/vsp1/vsp1_hgo.c create mode 100644 drivers/media/platform/vsp1/vsp1_hgo.h create mode 100644 drivers/media/platform/vsp1/vsp1_hgt.c create mode 100644 drivers/media/pla
Re: [PATCHv4 04/15] v4l: vsp1: Add histogram support
Em Tue, 11 Apr 2017 15:27:12 +0200 Hans Verkuil escreveu: > On 04/11/17 13:17, Mauro Carvalho Chehab wrote: > > Em Mon, 10 Apr 2017 21:26:40 +0200 > > Hans Verkuil escreveu: > > > >> From: Laurent Pinchart > >> > >> The histogram common code will be used to implement support for both the > >> HGO and HGT histogram computation engines. > >> > >> Signed-off-by: Laurent Pinchart > >> --- > >> drivers/media/platform/Kconfig | 1 + > >> drivers/media/platform/vsp1/Makefile | 1 + > >> drivers/media/platform/vsp1/vsp1_histo.c | 646 > >> +++ > >> drivers/media/platform/vsp1/vsp1_histo.h | 84 > >> 4 files changed, 732 insertions(+) > >> create mode 100644 drivers/media/platform/vsp1/vsp1_histo.c > >> create mode 100644 drivers/media/platform/vsp1/vsp1_histo.h > > > >> diff --git a/drivers/media/platform/vsp1/vsp1_histo.c > >> b/drivers/media/platform/vsp1/vsp1_histo.c > >> new file mode 100644 > >> index ..afab77cf4fa5 > >> --- /dev/null > >> +++ b/drivers/media/platform/vsp1/vsp1_histo.c > > > > ... > > > >> + crop = vsp1_entity_get_pad_selection(&histo->entity, config, sel->pad, > >> + V4L2_SEL_TGT_CROP); > >> + > >> + /* > >> + * Clamp the width and height to acceptable values first and then > >> + * compute the closest rounded dividing ratio. > >> + * > >> + * RatioRounded ratio > >> + * -- > >> + * [1.0 1.5[1 > > > > Nitpick: > > > > 1.0 1.5]1 > > No, the notation [a b[ means the range 'a to, but not including, b'. > > So this is correct. > > I'm used to writing this as [a b), but according to wikipedia both notations > are allowed. Ah! Yeah, it occurred to me that it could be using such notation from set theory, but as all the other ranges there were using [a b], I assumed it was a typo. > > Regards, > > Hans > > > > > Thanks, > > Mauro > > > Thanks, Mauro
Re: [PATCHv4 04/15] v4l: vsp1: Add histogram support
On 04/11/17 13:17, Mauro Carvalho Chehab wrote: > Em Mon, 10 Apr 2017 21:26:40 +0200 > Hans Verkuil escreveu: > >> From: Laurent Pinchart >> >> The histogram common code will be used to implement support for both the >> HGO and HGT histogram computation engines. >> >> Signed-off-by: Laurent Pinchart >> --- >> drivers/media/platform/Kconfig | 1 + >> drivers/media/platform/vsp1/Makefile | 1 + >> drivers/media/platform/vsp1/vsp1_histo.c | 646 >> +++ >> drivers/media/platform/vsp1/vsp1_histo.h | 84 >> 4 files changed, 732 insertions(+) >> create mode 100644 drivers/media/platform/vsp1/vsp1_histo.c >> create mode 100644 drivers/media/platform/vsp1/vsp1_histo.h > >> diff --git a/drivers/media/platform/vsp1/vsp1_histo.c >> b/drivers/media/platform/vsp1/vsp1_histo.c >> new file mode 100644 >> index ..afab77cf4fa5 >> --- /dev/null >> +++ b/drivers/media/platform/vsp1/vsp1_histo.c > > ... > >> +crop = vsp1_entity_get_pad_selection(&histo->entity, config, sel->pad, >> + V4L2_SEL_TGT_CROP); >> + >> +/* >> + * Clamp the width and height to acceptable values first and then >> + * compute the closest rounded dividing ratio. >> + * >> + * RatioRounded ratio >> + * -- >> + * [1.0 1.5[1 > > Nitpick: > > 1.0 1.5]1 No, the notation [a b[ means the range 'a to, but not including, b'. So this is correct. I'm used to writing this as [a b), but according to wikipedia both notations are allowed. Regards, Hans > > Thanks, > Mauro >
Re: [PATCH v3 2/7] dt-bindings: media: Add MAX2175 binding description
Hi Ramesh, On Tuesday 11 Apr 2017 12:19:54 Ramesh Shanmugasundaram wrote: > > On Tuesday 11 Apr 2017 09:57:45 Ramesh Shanmugasundaram wrote: > >>> On Tuesday 07 Feb 2017 15:02:32 Ramesh Shanmugasundaram wrote: > Add device tree binding documentation for MAX2175 Rf to bits tuner > device. > > Signed-off-by: Ramesh Shanmugasundaram > > --- > .../devicetree/bindings/media/i2c/max2175.txt | 61 + > .../devicetree/bindings/property-units.txt | 1 + > 2 files changed, 62 insertions(+) > create mode 100644 > > Documentation/devicetree/bindings/media/i2c/max2175.txt > diff --git > a/Documentation/devicetree/bindings/media/i2c/max2175.txt > b/Documentation/devicetree/bindings/media/i2c/max2175.txt new file > mode 100644 index 000..f591ab4 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt > > > > [snip] > > > +- maxim,am-hiz: empty property indicates AM Hi-Z filter > path is > +selected for AM antenna input. By default this > +filter path is not used. > >>> > >>> Isn't this something that should be selected at runtime through a > >>> control ? Or does the hardware design dictate whether the filter has > >>> to be used or must not be used ? > >> > >> This is dictated by the h/w design and not selectable at run-time. > >> I will update these changes in the next patchset. > > > > In that case I'm fine with a property, but could we name it in such a way > > that it describes the hardware instead of instructing the software on how > > to configure the device ? For instance (and this is a made-up example as I > > don't know exactly how this works), if the AM Hi-Z filter is required when > > dealing with AM frequencies and forbidden when dealing with other > > frequency bands, and *if* boards have to be designed specifically for one > > frequency band (AM, FM, VHF, L, ...) without any way to accept different > > bands, then you could instead use > > > > maxim,frequency-band = "AM"; > > > > and enable the filter accordingly in the driver. This would be in my > > opinion a better system hardware description. > > I am not sure. The AM antenna input path has a default filter and AM Hi-Z > filter. H/W dictates the path to be used for AM input only and this is > fixed. The device can be configured to use different bands at runtime & not > AM only. I could edit the description as below: > > - maxim,am-hiz : empty property indicates AM Hi-Z filter path > usage for AM antenna input as dictated by hardware design. By default this > filter path is not used. > > Is it any better? Do you still think the property name should be changed > please? I still think this should be renamed, but possibly because I don't understand all the details of this particular feature :-). The property, as named and documented above, describes a software features. It requests the driver to enable the AM Hi-Z filter. DT properties should instead describe the hardware. You should use a property that describes the hardware design, and use that to infer, in the driver, whether to enable or disable the filter. -- Regards, Laurent Pinchart
Re: [PATCH v3 5/7] doc_rst: media: New SDR formats PC16, PC18 & PC20
Hi Ramesh,
Thank you for the patch.
On Tuesday 07 Feb 2017 15:02:35 Ramesh Shanmugasundaram wrote:
> This patch adds documentation for the three new SDR formats
>
> V4L2_SDR_FMT_PCU16BE
> V4L2_SDR_FMT_PCU18BE
> V4L2_SDR_FMT_PCU20BE
>
> Signed-off-by: Ramesh Shanmugasundaram
> ---
> .../media/uapi/v4l/pixfmt-sdr-pcu16be.rst | 55 +++
> .../media/uapi/v4l/pixfmt-sdr-pcu18be.rst | 55 +++
> .../media/uapi/v4l/pixfmt-sdr-pcu20be.rst | 54 +++
> Documentation/media/uapi/v4l/sdr-formats.rst | 3 ++
> 4 files changed, 167 insertions(+)
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst
>
> diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
> b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst new file mode 100644
> index 000..2de1b1a
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
> @@ -0,0 +1,55 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _V4L2-SDR-FMT-PCU16BE:
> +
> +**
> +V4L2_SDR_FMT_PCU16BE ('PC16')
> +**
> +
> +Planar complex unsigned 16-bit big endian IQ sample
> +
> +Description
> +===
> +
> +This format contains a sequence of complex number samples. Each complex
> +number consist of two parts called In-phase and Quadrature (IQ). Both I
> +and Q are represented as a 16 bit unsigned big endian number stored in
> +32 bit space. The remaining unused bits within the 32 bit space will be
> +padded with 0. I value starts first and Q value starts at an offset
> +equalling half of the buffer size (i.e.) offset = buffersize/2. Out of
> +the 16 bits, bit 15:2 (14 bit) is data and bit 1:0 (2 bit) can be any
> +value.
This sounds very strange to me. Are the two lower bits always random ? What is
that used for ?
> +**Byte Order.**
> +Each cell is one byte.
> +
> +.. flat-table::
> +:header-rows: 1
> +:stub-columns: 0
> +
> +* - Offset:
> + - Byte B0
> + - Byte B1
> + - Byte B2
> + - Byte B3
> +* - start + 0:
> + - I'\ :sub:`0[13:6]`
> + - I'\ :sub:`0[5:0]; B1[1:0]=pad`
> + - pad
> + - pad
> +* - start + 4:
> + - I'\ :sub:`1[13:6]`
> + - I'\ :sub:`1[5:0]; B1[1:0]=pad`
> + - pad
> + - pad
> +* - ...
> +* - start + offset:
> + - Q'\ :sub:`0[13:6]`
> + - Q'\ :sub:`0[5:0]; B1[1:0]=pad`
> + - pad
> + - pad
> +* - start + offset + 4:
> + - Q'\ :sub:`1[13:6]`
> + - Q'\ :sub:`1[5:0]; B1[1:0]=pad`
> + - pad
> + - pad
> diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
> b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst new file mode 100644
> index 000..da8b26b
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
> @@ -0,0 +1,55 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _V4L2-SDR-FMT-PCU18BE:
> +
> +**
> +V4L2_SDR_FMT_PCU18BE ('PC18')
> +**
> +
> +Planar complex unsigned 18-bit big endian IQ sample
> +
> +Description
> +===
> +
> +This format contains a sequence of complex number samples. Each complex
> +number consist of two parts called In-phase and Quadrature (IQ). Both I
> +and Q are represented as a 18 bit unsigned big endian number stored in
> +32 bit space. The remaining unused bits within the 32 bit space will be
> +padded with 0. I value starts first and Q value starts at an offset
> +equalling half of the buffer size (i.e.) offset = buffersize/2. Out of
> +the 18 bits, bit 17:2 (16 bit) is data and bit 1:0 (2 bit) can be any
> +value.
> +
> +**Byte Order.**
> +Each cell is one byte.
> +
> +.. flat-table::
> +:header-rows: 1
> +:stub-columns: 0
> +
> +* - Offset:
> + - Byte B0
> + - Byte B1
> + - Byte B2
> + - Byte B3
> +* - start + 0:
> + - I'\ :sub:`0[17:10]`
> + - I'\ :sub:`0[9:2]`
> + - I'\ :sub:`0[1:0]; B2[5:0]=pad`
> + - pad
> +* - start + 4:
> + - I'\ :sub:`1[17:10]`
> + - I'\ :sub:`1[9:2]`
> + - I'\ :sub:`1[1:0]; B2[5:0]=pad`
> + - pad
> +* - ...
> +* - start + offset:
> + - Q'\ :sub:`0[17:10]`
> + - Q'\ :sub:`0[9:2]`
> + - Q'\ :sub:`0[1:0]; B2[5:0]=pad`
> + - pad
> +* - start + offset + 4:
> + - Q'\ :sub:`1[17:10]`
> + - Q'\ :sub:`1[9:2]`
> + - Q'\ :sub:`1[1:0]; B2[5:0]=pad`
> + - pad
> diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst
> b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst new file mode 100644
> index 000..5499eed
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst
> @@ -0,0 +1,54 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +.. _V4L2-SDR-FMT-PCU20BE:
RE: [PATCH v3 2/7] dt-bindings: media: Add MAX2175 binding description
Hi Laurent, > On Tuesday 11 Apr 2017 09:57:45 Ramesh Shanmugasundaram wrote: > > > On Tuesday 07 Feb 2017 15:02:32 Ramesh Shanmugasundaram wrote: > > >> Add device tree binding documentation for MAX2175 Rf to bits tuner > > >> device. > > >> > > >> Signed-off-by: Ramesh Shanmugasundaram > > >> --- > > >> > > >> .../devicetree/bindings/media/i2c/max2175.txt | 61 > +++ > > >> .../devicetree/bindings/property-units.txt | 1 + > > >> 2 files changed, 62 insertions(+) > > >> create mode 100644 > > >> > > >> Documentation/devicetree/bindings/media/i2c/max2175.txt > > >> > > >> diff --git > > >> a/Documentation/devicetree/bindings/media/i2c/max2175.txt > > >> b/Documentation/devicetree/bindings/media/i2c/max2175.txt new file > > >> mode 100644 index 000..f591ab4 > > >> --- /dev/null > > >> +++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt > > [snip] > > > >> +- maxim,am-hiz: empty property indicates AM Hi-Z filter > path > > >> is > > >> +selected for AM antenna input. By default this > > >> +filter path is not used. > > > > > > Isn't this something that should be selected at runtime through a > > > control ? Or does the hardware design dictate whether the filter has > > > to be used or must not be used ? > > > > This is dictated by the h/w design and not selectable at run-time. > > I will update these changes in the next patchset. > > In that case I'm fine with a property, but could we name it in such a way > that it describes the hardware instead of instructing the software on how > to configure the device ? For instance (and this is a made-up example as I > don't know exactly how this works), if the AM Hi-Z filter is required when > dealing with AM frequencies and forbidden when dealing with other > frequency bands, and > *if* boards have to be designed specifically for one frequency band (AM, > FM, VHF, L, ...) without any way to accept different bands, then you could > instead use > > maxim,frequency-band = "AM"; > > and enable the filter accordingly in the driver. This would be in my > opinion a better system hardware description. I am not sure. The AM antenna input path has a default filter and AM Hi-Z filter. H/W dictates the path to be used for AM input only and this is fixed. The device can be configured to use different bands at runtime & not AM only. I could edit the description as below: - maxim,am-hiz: empty property indicates AM Hi-Z filter path usage for AM antenna input as dictated by hardware design. By default this filter path is not used. Is it any better? Do you still think the property name should be changed please? Thanks, Ramesh
Re: [PATCHv4 00/15] R-Car VSP1 Histogram Support
On 04/10/17 22:26, Hans Verkuil wrote: > From: Hans Verkuil > > This patch series is the rebased version of this pull request: > > https://www.mail-archive.com/linux-media@vger.kernel.org/msg111025.html > > It slightly modifies 'Add metadata buffer type and format' (remove > experimental note and add newline after label) and it adds support > for V4L2_CTRL_FLAG_MODIFY_LAYOUT, as requested by Mauro. > > No other changes were made. For patches 11--15: Acked-by: Sakari Ailus -- Sakari Ailus sakari.ai...@linux.intel.com
Re: [PATCHv4 00/15] R-Car VSP1 Histogram Support
Hi Hans, Em Mon, 10 Apr 2017 21:26:36 +0200 Hans Verkuil escreveu: > From: Hans Verkuil > > This patch series is the rebased version of this pull request: > > https://www.mail-archive.com/linux-media@vger.kernel.org/msg111025.html > > It slightly modifies 'Add metadata buffer type and format' (remove > experimental note and add newline after label) and it adds support > for V4L2_CTRL_FLAG_MODIFY_LAYOUT, as requested by Mauro. > > No other changes were made. Patch series look ok. I found just one typo on one of the patches. What seems to be missing here is to set the GRABBED flag for controls that modify layout but don't allow control update while streaming. While it is OK to do such change for the existing drivers later (as this is actually a bug fix), I would be expecting such change for the controls used at the vsp1 driver, as, from what I'm seeing at the code, vsp1_wpf_s_ctrl() will block changing any controls in runtime. So, wpf_init_controls() should mark all such controls with V4L2_CTRL_FLAG_GRABBED[1]. Could you please add such patch at the end of this patchset? Thanks! Mauro [1] I don't see any reason why not allowing HFLIP/VFLIP controls to be handled in realtime (except if the hardware itself doesn't allow), but the current code doesn't allow such changes in realtime anymore. Perhaps the code could be less pick in the future. Thanks, Mauro
[PATCH v9 2/2] media: Add a driver for the ov5645 camera sensor.
The ov5645 sensor from Omnivision supports up to 2592x1944
and CSI2 interface.
The driver adds support for the following modes:
- 1280x960
- 1920x1080
- 2592x1944
Output format is packed 8bit UYVY.
Signed-off-by: Todor Tomov
Reviewed-by: Laurent Pinchart
Acked-by: Sakari Ailus
---
drivers/media/i2c/Kconfig | 12 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ov5645.c | 1345
3 files changed, 1358 insertions(+)
create mode 100644 drivers/media/i2c/ov5645.c
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cee1dae..be4ded8 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -531,6 +531,18 @@ config VIDEO_OV2659
To compile this driver as a module, choose M here: the
module will be called ov2659.
+config VIDEO_OV5645
+ tristate "OmniVision OV5645 sensor support"
+ depends on OF
+ depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on MEDIA_CAMERA_SUPPORT
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV5645 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov5645.
+
config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 5bc7bbe..8b0b8ca 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
+obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
diff --git a/drivers/media/i2c/ov5645.c b/drivers/media/i2c/ov5645.c
new file mode 100644
index 000..57bd591
--- /dev/null
+++ b/drivers/media/i2c/ov5645.c
@@ -0,0 +1,1345 @@
+/*
+ * Driver for the OV5645 camera sensor.
+ *
+ * Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2015 By Tech Design S.L. All Rights Reserved.
+ * Copyright (C) 2012-2013 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * Based on:
+ * - the OV5645 driver from QC msm-3.10 kernel on codeaurora.org:
+ * https://us.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/drivers/
+ * media/platform/msm/camera_v2/sensor/ov5645.c?h=LA.BR.1.2.4_rb1.41
+ * - the OV5640 driver posted on linux-media:
+ * https://www.mail-archive.com/linux-media%40vger.kernel.org/msg92671.html
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define OV5645_VOLTAGE_ANALOG 280
+#define OV5645_VOLTAGE_DIGITAL_CORE 150
+#define OV5645_VOLTAGE_DIGITAL_IO 180
+
+#define OV5645_SYSTEM_CTRL00x3008
+#defineOV5645_SYSTEM_CTRL0_START 0x02
+#defineOV5645_SYSTEM_CTRL0_STOP0x42
+#define OV5645_CHIP_ID_HIGH0x300a
+#defineOV5645_CHIP_ID_HIGH_BYTE0x56
+#define OV5645_CHIP_ID_LOW 0x300b
+#defineOV5645_CHIP_ID_LOW_BYTE 0x45
+#define OV5645_AWB_MANUAL_CONTROL 0x3406
+#defineOV5645_AWB_MANUAL_ENABLEBIT(0)
+#define OV5645_AEC_PK_MANUAL 0x3503
+#defineOV5645_AEC_MANUAL_ENABLEBIT(0)
+#defineOV5645_AGC_MANUAL_ENABLEBIT(1)
+#define OV5645_TIMING_TC_REG20 0x3820
+#defineOV5645_SENSOR_VFLIP BIT(1)
+#defineOV5645_ISP_VFLIPBIT(2)
+#define OV5645_TIMING_TC_REG21 0x3821
+#defineOV5645_SENSOR_MIRRORBIT(1)
+#define OV5645_PRE_ISP_TEST_SETTING_1 0x503d
+#defineOV5645_TEST_PATTERN_MASK0x3
+#defineOV5645_SET_TEST_PATTERN(x) ((x) &
OV5645_TEST_PATTERN_MASK)
+#defineOV5645_TEST_PATTERN_ENABLE BIT(7)
+#define OV5645_SDE_SAT_U 0x5583
+#define OV5645_SDE_SAT_V 0x5584
+
+struct reg_value {
+ u16 reg;
+ u8 val;
+};
+
+struct ov5645_mode_info {
+ u32 width;
+ u32 height;
+
[PATCH v9 1/2] media: i2c/ov5645: add the device tree binding document
Add the document for ov5645 device tree binding.
Signed-off-by: Todor Tomov
Reviewed-by: Laurent Pinchart
Acked-by: Sakari Ailus
Acked-by: Rob Herring
---
.../devicetree/bindings/media/i2c/ov5645.txt | 54 ++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5645.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/ov5645.txt
b/Documentation/devicetree/bindings/media/i2c/ov5645.txt
new file mode 100644
index 000..fd7aec9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5645.txt
@@ -0,0 +1,54 @@
+* Omnivision 1/4-Inch 5Mp CMOS Digital Image Sensor
+
+The Omnivision OV5645 is a 1/4-Inch CMOS active pixel digital image sensor with
+an active array size of 2592H x 1944V. It is programmable through a serial I2C
+interface.
+
+Required Properties:
+- compatible: Value should be "ovti,ov5645".
+- clocks: Reference to the xclk clock.
+- clock-names: Should be "xclk".
+- clock-frequency: Frequency of the xclk clock.
+- enable-gpios: Chip enable GPIO. Polarity is GPIO_ACTIVE_HIGH. This
corresponds
+ to the hardware pin PWDNB which is physically active low.
+- reset-gpios: Chip reset GPIO. Polarity is GPIO_ACTIVE_LOW. This corresponds
to
+ the hardware pin RESETB.
+- vdddo-supply: Chip digital IO regulator.
+- vdda-supply: Chip analog regulator.
+- vddd-supply: Chip digital core regulator.
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ &i2c1 {
+ ...
+
+ ov5645: ov5645@78 {
+ compatible = "ovti,ov5645";
+ reg = <0x78>;
+
+ enable-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio5 20 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&camera_rear_default>;
+
+ clocks = <&clks 200>;
+ clock-names = "xclk";
+ clock-frequency = <2388>;
+
+ vdddo-supply = <&camera_dovdd_1v8>;
+ vdda-supply = <&camera_avdd_2v8>;
+ vddd-supply = <&camera_dvdd_1v2>;
+
+ port {
+ ov5645_ep: endpoint {
+ clock-lanes = <1>;
+ data-lanes = <0 2>;
+ remote-endpoint = <&csi0_ep>;
+ };
+ };
+ };
+ };
--
1.9.1
[PATCH v9 0/2] OV5645 camera sensor driver
Resending once again to remove an unused empty struct in second patch. I have kept the received tags because the change is rather trivial. Changes since version 8: - removed unused empty struct ov5645_subdev_internal_ops; - removed two redundant new lines above and under ov5645_remove(). Changes since version 7: - "unsigned int i" changed to "int i" in ov5645_find_nearest_mode(); - unused varialbe removed from ov5645_entity_init_cfg(). Changes since version 6 include: - keep a pointer to the current sensor mode and remove enum ov5645_mode; - do not keep v4l2 control values and xclk frequency in the main data struct; - add caching variables in then main data struct for some of the register values to avoid i2c read commands; - use reference counting for power state; - enable xclk only after regulators are enabled; - add check for xclk rate that it is supported; - register v4l2 subdev only at the end of probe when the rest is succeeded; - add hardware pin names in gpio descriptions in the dt binding document; - other minor changes: uppercase to lowercase, add const modifier, remove unnecessary local variables, fix return values. Changes since version 5 include: - external clock frequency set in DT; - added v4l2_subdev_pad_ops.init_cfg function to initialize formats; - current sensor mode not updated if set_fmt is TRY (not ACTIVE); - other small changes - debug messages removed, register addresses defines renamed, redundant safety checks removed, unnecessary labels removed, mutex_destroy added. Two one-line changes since version 4: - return current format on set_format; - return all frame sizes when enumerating them. Only one change since version 3: - build failure on kernel v4.7-rc1 fixed: s/media_entity_init/media_entity_pads_init/ Changes from version 2 include: - external camera clock configuration is moved from DT to driver; - pwdn-gpios renamed to enable-gpios; - switched polarity of reset-gpios to the more intuitive active low; - added Kconfig dependency to OF; - return values checks; - regulators and gpios are now required (not optional); - regulators names renamed; - power counter variable changed to a bool power state; - ov5645_registered() is removed and sensor id reading moved to probe(). Changes from version 1 include: - patch split to dt binding doc patch and driver patch; - changes in power on/off logic - s_power is now not called on open/close; - using assigned-clock-rates in dt for setting camera external clock rate; - correct api for gpio handling; - return values checks; - style fixes. Todor Tomov (2): media: i2c/ov5645: add the device tree binding document media: Add a driver for the ov5645 camera sensor. .../devicetree/bindings/media/i2c/ov5645.txt | 54 + drivers/media/i2c/Kconfig | 12 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/ov5645.c | 1345 4 files changed, 1412 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5645.txt create mode 100644 drivers/media/i2c/ov5645.c -- 1.9.1
Re: [PATCH v3 2/7] dt-bindings: media: Add MAX2175 binding description
Hi Ramesh, On Tuesday 11 Apr 2017 09:57:45 Ramesh Shanmugasundaram wrote: > > On Tuesday 07 Feb 2017 15:02:32 Ramesh Shanmugasundaram wrote: > >> Add device tree binding documentation for MAX2175 Rf to bits tuner > >> device. > >> > >> Signed-off-by: Ramesh Shanmugasundaram > >> --- > >> > >> .../devicetree/bindings/media/i2c/max2175.txt | 61 +++ > >> .../devicetree/bindings/property-units.txt | 1 + > >> 2 files changed, 62 insertions(+) > >> create mode 100644 > >> > >> Documentation/devicetree/bindings/media/i2c/max2175.txt > >> > >> diff --git a/Documentation/devicetree/bindings/media/i2c/max2175.txt > >> b/Documentation/devicetree/bindings/media/i2c/max2175.txt new file > >> mode 100644 > >> index 000..f591ab4 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt [snip] > >> +- maxim,am-hiz : empty property indicates AM Hi-Z filter path > >> is > >> + selected for AM antenna input. By default this > >> + filter path is not used. > > > > Isn't this something that should be selected at runtime through a control > > ? Or does the hardware design dictate whether the filter has to be used or > > must not be used ? > > This is dictated by the h/w design and not selectable at run-time. > I will update these changes in the next patchset. In that case I'm fine with a property, but could we name it in such a way that it describes the hardware instead of instructing the software on how to configure the device ? For instance (and this is a made-up example as I don't know exactly how this works), if the AM Hi-Z filter is required when dealing with AM frequencies and forbidden when dealing with other frequency bands, and *if* boards have to be designed specifically for one frequency band (AM, FM, VHF, L, ...) without any way to accept different bands, then you could instead use maxim,frequency-band = "AM"; and enable the filter accordingly in the driver. This would be in my opinion a better system hardware description. -- Regards, Laurent Pinchart
Re: [Patch v3 10/11] [media] s5p-mfc: Add support for HEVC encoder (fwd)
On Tue, 2017-04-11 at 11:00 +0200, Sylwester Nawrocki wrote: > Hi, > > On 04/03/2017 08:17 AM, Smitha T Murthy wrote: > > On Mon, 2017-04-03 at 08:00 +0200, Julia Lawall wrote: > >> See line 2101 > >> > >> julia > >> > > Thank you for bringing it to my notice, I had not checked on this git. > > I will upload the next version of patches soon corresponding to this > > git. > > In general please use the media master branch as a base for your patches > (git://linuxtv.org/media_tree.git master). Or latest branch in my > git repository, currently it's "for-v4.12/media/next-2" as can be seen > here: https://git.linuxtv.org/snawrocki/samsung.git > I have submitted the next version(v4) of mfcv10.10 patches based on git://linuxtv.org/snawrocki/samsung.git for-v4.12/media/next. But I will keep this in mind next time I submit fresh patches. Thank you for the information :) Regards, Smitha
Re: [PATCHv4 04/15] v4l: vsp1: Add histogram support
Em Mon, 10 Apr 2017 21:26:40 +0200 Hans Verkuil escreveu: > From: Laurent Pinchart > > The histogram common code will be used to implement support for both the > HGO and HGT histogram computation engines. > > Signed-off-by: Laurent Pinchart > --- > drivers/media/platform/Kconfig | 1 + > drivers/media/platform/vsp1/Makefile | 1 + > drivers/media/platform/vsp1/vsp1_histo.c | 646 > +++ > drivers/media/platform/vsp1/vsp1_histo.h | 84 > 4 files changed, 732 insertions(+) > create mode 100644 drivers/media/platform/vsp1/vsp1_histo.c > create mode 100644 drivers/media/platform/vsp1/vsp1_histo.h > diff --git a/drivers/media/platform/vsp1/vsp1_histo.c > b/drivers/media/platform/vsp1/vsp1_histo.c > new file mode 100644 > index ..afab77cf4fa5 > --- /dev/null > +++ b/drivers/media/platform/vsp1/vsp1_histo.c ... > + crop = vsp1_entity_get_pad_selection(&histo->entity, config, sel->pad, > + V4L2_SEL_TGT_CROP); > + > + /* > + * Clamp the width and height to acceptable values first and then > + * compute the closest rounded dividing ratio. > + * > + * RatioRounded ratio > + * -- > + * [1.0 1.5[1 Nitpick: 1.0 1.5]1 Thanks, Mauro
RE: [PATCH v3 2/7] dt-bindings: media: Add MAX2175 binding description
Hi Laurent, Thanks for the review comments. > > On Tuesday 07 Feb 2017 15:02:32 Ramesh Shanmugasundaram wrote: > > Add device tree binding documentation for MAX2175 Rf to bits tuner > > device. > > > > Signed-off-by: Ramesh Shanmugasundaram > > --- > > .../devicetree/bindings/media/i2c/max2175.txt | 61 > +++ > > .../devicetree/bindings/property-units.txt | 1 + > > 2 files changed, 62 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/media/i2c/max2175.txt > > > > diff --git a/Documentation/devicetree/bindings/media/i2c/max2175.txt > > b/Documentation/devicetree/bindings/media/i2c/max2175.txt new file > > mode > > 100644 > > index 000..f591ab4 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt > > @@ -0,0 +1,61 @@ > > +Maxim Integrated MAX2175 RF to Bits tuner > > +- > > + > > +The MAX2175 IC is an advanced analog/digital hybrid-radio receiver > > +with RF to Bits(r) front-end designed for software-defined radio > solutions. > > + > > +Required properties: > > + > > +- compatible: "maxim,max2175" for MAX2175 RF-to-bits tuner. > > +- clocks: phandle to the fixed xtal clock. > > +- clock-names: name of the fixed xtal clock. > > I would mention that the name has to be "xtal". Maybe something like > > - clock-names: name of the fixed xtal clock, shall be "xtal". Agreed. > > > +- port: child port node of a tuner that defines the local and remote > > + endpoints. The remote endpoint is assumed to be an SDR device > > + that is capable of receiving the digital samples from the tuner. > > You should refer to the OF graphs bindings here. How about the following > to document the port node ? > > - port: child port node corresponding to the I2S output, in accordance > with the video interface bindings defined in > Documentation/devicetree/bindings/media/video-interfaces.txt. The port > node must contain at least one endpoint. Agreed. > > > +Optional properties: > > + > > +- maxim,slave: phandle to the master tuner if it is a slave. > This > > + is used to define two tuners in diversity mode > > + (1 master, 1 slave). By default each tuner is an > > + individual master. > > It seems weird to me to name a property "slave" when it points to the > master tuner. Shouldn't it be named "maxim,master" ? Agreed. > > > +- maxim,refout-load-pF: load capacitance value (in pF) on reference > > + output drive level. The possible load values are > > +0 (default - refout disabled) > > + 10 > > + 20 > > + 30 > > + 40 > > + 60 > > + 70 > > +- maxim,am-hiz : empty property indicates AM Hi-Z filter path > is > > + selected for AM antenna input. By default this > > + filter path is not used. > > Isn't this something that should be selected at runtime through a control > ? Or does the hardware design dictate whether the filter has to be used or > must not be used ? This is dictated by the h/w design and not selectable at run-time. I will update these changes in the next patchset. Thanks, Ramesh
Re: [Patch v3 10/11] [media] s5p-mfc: Add support for HEVC encoder (fwd)
On 04/11/2017 11:23 AM, Julia Lawall wrote: On Tue, 11 Apr 2017, Sylwester Nawrocki wrote: Hi, On 04/03/2017 08:17 AM, Smitha T Murthy wrote: On Mon, 2017-04-03 at 08:00 +0200, Julia Lawall wrote: See line 2101 julia Thank you for bringing it to my notice, I had not checked on this git. I will upload the next version of patches soon corresponding to this git. In general please use the media master branch as a base for your patches (git://linuxtv.org/media_tree.git master). Or latest branch in my git repository, currently it's "for-v4.12/media/next-2" as can be seen here: https://git.linuxtv.org/snawrocki/samsung.git > I'm not making the patch. It comes to me from kbuild. If you would prefer some tree not to be included, you can notify Fengguang about this: Oops, my message was addressed to Smitha only, apologies for the confusion. kbuild works fine. Thank you for your efforts. -- Regards, Sylwester
Re: [PATCH 1/5] media: rc: meson-ir: remove irq from struct meson_ir
On 04/11/2017 07:53 AM, Heiner Kallweit wrote:
> The irq number is used in the probe function only, therefore just use
> a local variable.
>
> Signed-off-by: Heiner Kallweit
> ---
> drivers/media/rc/meson-ir.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c
> index 5576dbd6..a4128d7c 100644
> --- a/drivers/media/rc/meson-ir.c
> +++ b/drivers/media/rc/meson-ir.c
> @@ -68,7 +68,6 @@
> struct meson_ir {
> void __iomem*reg;
> struct rc_dev *rc;
> - int irq;
> spinlock_t lock;
> };
>
> @@ -112,7 +111,7 @@ static int meson_ir_probe(struct platform_device *pdev)
> struct resource *res;
> const char *map_name;
> struct meson_ir *ir;
> - int ret;
> + int irq, ret;
>
> ir = devm_kzalloc(dev, sizeof(struct meson_ir), GFP_KERNEL);
> if (!ir)
> @@ -125,10 +124,10 @@ static int meson_ir_probe(struct platform_device *pdev)
> return PTR_ERR(ir->reg);
> }
>
> - ir->irq = platform_get_irq(pdev, 0);
> - if (ir->irq < 0) {
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0) {
> dev_err(dev, "no irq resource\n");
> - return ir->irq;
> + return irq;
> }
>
> ir->rc = rc_allocate_device(RC_DRIVER_IR_RAW);
> @@ -158,7 +157,7 @@ static int meson_ir_probe(struct platform_device *pdev)
> goto out_free;
> }
>
> - ret = devm_request_irq(dev, ir->irq, meson_ir_irq, 0, "ir-meson", ir);
> + ret = devm_request_irq(dev, irq, meson_ir_irq, 0, "ir-meson", ir);
> if (ret) {
> dev_err(dev, "failed to request irq\n");
> goto out_unreg;
>
Hi Heiner,
I'm not really convinced this is useful, if somehow for future enhancements we
need the IRQ
number, this will need to be reverted...
Neil
Re: [PATCH v3 2/7] dt-bindings: media: Add MAX2175 binding description
Hi Ramesh,
Thank you for the patch.
On Tuesday 07 Feb 2017 15:02:32 Ramesh Shanmugasundaram wrote:
> Add device tree binding documentation for MAX2175 Rf to bits tuner
> device.
>
> Signed-off-by: Ramesh Shanmugasundaram
> ---
> .../devicetree/bindings/media/i2c/max2175.txt | 61 +++
> .../devicetree/bindings/property-units.txt | 1 +
> 2 files changed, 62 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/max2175.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/max2175.txt
> b/Documentation/devicetree/bindings/media/i2c/max2175.txt new file mode
> 100644
> index 000..f591ab4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt
> @@ -0,0 +1,61 @@
> +Maxim Integrated MAX2175 RF to Bits tuner
> +-
> +
> +The MAX2175 IC is an advanced analog/digital hybrid-radio receiver with
> +RF to Bits® front-end designed for software-defined radio solutions.
> +
> +Required properties:
> +
> +- compatible: "maxim,max2175" for MAX2175 RF-to-bits tuner.
> +- clocks: phandle to the fixed xtal clock.
> +- clock-names: name of the fixed xtal clock.
I would mention that the name has to be "xtal". Maybe something like
- clock-names: name of the fixed xtal clock, shall be "xtal".
> +- port: child port node of a tuner that defines the local and remote
> + endpoints. The remote endpoint is assumed to be an SDR device
> + that is capable of receiving the digital samples from the tuner.
You should refer to the OF graphs bindings here. How about the following to
document the port node ?
- port: child port node corresponding to the I2S output, in accordance with
the video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt. The port node
must contain at least one endpoint.
> +Optional properties:
> +
> +- maxim,slave : phandle to the master tuner if it is a slave.
This
> + is used to define two tuners in diversity mode
> + (1 master, 1 slave). By default each tuner is an
> + individual master.
It seems weird to me to name a property "slave" when it points to the master
tuner. Shouldn't it be named "maxim,master" ?
> +- maxim,refout-load-pF: load capacitance value (in pF) on reference
> + output drive level. The possible load values are
> + 0 (default - refout disabled)
> + 10
> + 20
> + 30
> + 40
> + 60
> + 70
> +- maxim,am-hiz : empty property indicates AM Hi-Z filter path
is
> + selected for AM antenna input. By default this
> + filter path is not used.
Isn't this something that should be selected at runtime through a control ? Or
does the hardware design dictate whether the filter has to be used or must not
be used ?
> +Example:
> +
> +
> +Board specific DTS file
> +
> +/* Fixed XTAL clock node */
> +maxim_xtal: clock {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <36864000>;
> +};
> +
> +/* A tuner device instance under i2c bus */
> +max2175_0: tuner@60 {
> + compatible = "maxim,max2175";
> + reg = <0x60>;
> + clocks = <&maxim_xtal>;
> + clock-names = "xtal";
> + maxim,refout-load-pF = <10>;
> +
> + port {
> + max2175_0_ep: endpoint {
> + remote-endpoint = <&slave_rx_device>;
> + };
> + };
> +
> +};
> diff --git a/Documentation/devicetree/bindings/property-units.txt
> b/Documentation/devicetree/bindings/property-units.txt index
> 12278d7..f1f1c22 100644
> --- a/Documentation/devicetree/bindings/property-units.txt
> +++ b/Documentation/devicetree/bindings/property-units.txt
> @@ -28,6 +28,7 @@ Electricity
> -ohms: Ohms
> -micro-ohms : micro Ohms
> -microvolt : micro volts
> +-pF : pico farads
>
> Temperature
>
--
Regards,
Laurent Pinchart
Re: [Patch v3 10/11] [media] s5p-mfc: Add support for HEVC encoder (fwd)
On Tue, 11 Apr 2017, Sylwester Nawrocki wrote: > Hi, > > On 04/03/2017 08:17 AM, Smitha T Murthy wrote: > > On Mon, 2017-04-03 at 08:00 +0200, Julia Lawall wrote: > > > See line 2101 > > > > > > julia > > > > > Thank you for bringing it to my notice, I had not checked on this git. > > I will upload the next version of patches soon corresponding to this > > git. > > In general please use the media master branch as a base for your patches > (git://linuxtv.org/media_tree.git master). Or latest branch in my > git repository, currently it's "for-v4.12/media/next-2" as can be seen > here: https://git.linuxtv.org/snawrocki/samsung.git I'm not making the patch. It comes to me from kbuild. If you would prefer some tree not to be included, you can notify Fengguang about this: fengguang...@intel.com julia > > -- > Thanks, > Sylwester >
Re: [git:media_tree/master] [media] ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi
On Tue, Apr 11, 2017 at 10:54 AM, Mauro Carvalho Chehab wrote: > Em Tue, 11 Apr 2017 10:36:58 +0200 > Krzysztof Kozlowski escreveu: > >> On Mon, Apr 10, 2017 at 6:12 PM, Mauro Carvalho Chehab >> wrote: >> > This is an automatic generated email to let you know that the following >> > patch were queued: >> > >> > Subject: [media] ARM: dts: exynos: add HDMI controller phandle to >> > exynos4.dtsi >> > Author: Hans Verkuil >> > Date:Tue Dec 13 12:37:16 2016 -0200 >> > >> > Add the new hdmi phandle to exynos4.dtsi. This phandle is needed by the >> > s5p-cec driver to initialize the CEC notifier framework. >> > >> > Tested with my Odroid U3. >> > >> > Signed-off-by: Hans Verkuil >> > Tested-by: Marek Szyprowski >> > CC: linux-samsung-...@vger.kernel.org >> > CC: devicet...@vger.kernel.org >> > CC: Krzysztof Kozlowski >> > Signed-off-by: Mauro Carvalho Chehab >> > >> > arch/arm/boot/dts/exynos4.dtsi | 1 + >> > 1 file changed, 1 insertion(+) >> > >> >> Mauro, you should not apply it. It is already going through samsung-soc [1]. >> if you need this patch for bisectability or any other reasons, I >> provided a tag with it here: >> https://www.spinics.net/lists/devicetree/msg171182.html >> >> Please drop the patch because now it will get duplicated. > > Having exactly the same patch applied on multiple trees usually is > not a problem, provided that it doesn't rise a non-trivial > conflict. > > I avoid rebase the tree where this patch is applied, as rebasing it > affect the workflow of other developers. > > I'm afraid that, if I revert this patch, it will cause more harm than > good. Of course, revert is wrong. The patch should be dropped with rebase, assuming that you accept the rebase itself. But if you do not rebase... then it has to stay. > So, I guess the best solution to fix the issue would be to pull from > a stable branch on your tree with has this patch and solve conflicts, > if any. This way, nothing will popup when merging upstream. This is why I provided it in separate tag, in first place! That is a proper solution for avoiding any patch duplication and conflicts. Indeed you are right that duplication of commits should not do any harm... but it is not a proper way of development, right? Anyway, it is up to you. I provided you a tag with it so you can merge it if needed (which would require rebasing). If not, then of course please do not revert it. Best regards, Krzysztof
Re: [Patch v3 10/11] [media] s5p-mfc: Add support for HEVC encoder (fwd)
Hi, On 04/03/2017 08:17 AM, Smitha T Murthy wrote: On Mon, 2017-04-03 at 08:00 +0200, Julia Lawall wrote: See line 2101 julia Thank you for bringing it to my notice, I had not checked on this git. I will upload the next version of patches soon corresponding to this git. In general please use the media master branch as a base for your patches (git://linuxtv.org/media_tree.git master). Or latest branch in my git repository, currently it's "for-v4.12/media/next-2" as can be seen here: https://git.linuxtv.org/snawrocki/samsung.git -- Thanks, Sylwester
Re: [git:media_tree/master] [media] ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi
Em Tue, 11 Apr 2017 10:36:58 +0200 Krzysztof Kozlowski escreveu: > On Mon, Apr 10, 2017 at 6:12 PM, Mauro Carvalho Chehab > wrote: > > This is an automatic generated email to let you know that the following > > patch were queued: > > > > Subject: [media] ARM: dts: exynos: add HDMI controller phandle to > > exynos4.dtsi > > Author: Hans Verkuil > > Date:Tue Dec 13 12:37:16 2016 -0200 > > > > Add the new hdmi phandle to exynos4.dtsi. This phandle is needed by the > > s5p-cec driver to initialize the CEC notifier framework. > > > > Tested with my Odroid U3. > > > > Signed-off-by: Hans Verkuil > > Tested-by: Marek Szyprowski > > CC: linux-samsung-...@vger.kernel.org > > CC: devicet...@vger.kernel.org > > CC: Krzysztof Kozlowski > > Signed-off-by: Mauro Carvalho Chehab > > > > arch/arm/boot/dts/exynos4.dtsi | 1 + > > 1 file changed, 1 insertion(+) > > > > Mauro, you should not apply it. It is already going through samsung-soc [1]. > if you need this patch for bisectability or any other reasons, I > provided a tag with it here: > https://www.spinics.net/lists/devicetree/msg171182.html > > Please drop the patch because now it will get duplicated. Having exactly the same patch applied on multiple trees usually is not a problem, provided that it doesn't rise a non-trivial conflict. I avoid rebase the tree where this patch is applied, as rebasing it affect the workflow of other developers. I'm afraid that, if I revert this patch, it will cause more harm than good. So, I guess the best solution to fix the issue would be to pull from a stable branch on your tree with has this patch and solve conflicts, if any. This way, nothing will popup when merging upstream. Regards, Mauro > > Best regards, > Krzysztof > > [1] https://www.spinics.net/lists/arm-kernel/msg575229.html Thanks, Mauro
Re: [git:media_tree/master] [media] ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi
On 04/11/17 10:36, Krzysztof Kozlowski wrote: > On Mon, Apr 10, 2017 at 6:12 PM, Mauro Carvalho Chehab > wrote: >> This is an automatic generated email to let you know that the following >> patch were queued: >> >> Subject: [media] ARM: dts: exynos: add HDMI controller phandle to >> exynos4.dtsi >> Author: Hans Verkuil >> Date:Tue Dec 13 12:37:16 2016 -0200 >> >> Add the new hdmi phandle to exynos4.dtsi. This phandle is needed by the >> s5p-cec driver to initialize the CEC notifier framework. >> >> Tested with my Odroid U3. >> >> Signed-off-by: Hans Verkuil >> Tested-by: Marek Szyprowski >> CC: linux-samsung-...@vger.kernel.org >> CC: devicet...@vger.kernel.org >> CC: Krzysztof Kozlowski >> Signed-off-by: Mauro Carvalho Chehab >> >> arch/arm/boot/dts/exynos4.dtsi | 1 + >> 1 file changed, 1 insertion(+) >> > > Mauro, you should not apply it. It is already going through samsung-soc [1]. > if you need this patch for bisectability or any other reasons, I > provided a tag with it here: > https://www.spinics.net/lists/devicetree/msg171182.html > > Please drop the patch because now it will get duplicated. I apologize for that. I realized that I shouldn't have included this in my pull request when it was already merged. My fault completely. Regards, Hans
Re: [git:media_tree/master] [media] ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi
On Mon, Apr 10, 2017 at 6:12 PM, Mauro Carvalho Chehab wrote: > This is an automatic generated email to let you know that the following patch > were queued: > > Subject: [media] ARM: dts: exynos: add HDMI controller phandle to exynos4.dtsi > Author: Hans Verkuil > Date:Tue Dec 13 12:37:16 2016 -0200 > > Add the new hdmi phandle to exynos4.dtsi. This phandle is needed by the > s5p-cec driver to initialize the CEC notifier framework. > > Tested with my Odroid U3. > > Signed-off-by: Hans Verkuil > Tested-by: Marek Szyprowski > CC: linux-samsung-...@vger.kernel.org > CC: devicet...@vger.kernel.org > CC: Krzysztof Kozlowski > Signed-off-by: Mauro Carvalho Chehab > > arch/arm/boot/dts/exynos4.dtsi | 1 + > 1 file changed, 1 insertion(+) > Mauro, you should not apply it. It is already going through samsung-soc [1]. if you need this patch for bisectability or any other reasons, I provided a tag with it here: https://www.spinics.net/lists/devicetree/msg171182.html Please drop the patch because now it will get duplicated. Best regards, Krzysztof [1] https://www.spinics.net/lists/arm-kernel/msg575229.html
Re: [PATCH v3 1/7] media: v4l2-ctrls: Reserve controls for MAX217X
Hi Ramesh,
Thank you for the patch.
On Tuesday 07 Feb 2017 15:02:31 Ramesh Shanmugasundaram wrote:
> Reserve controls for MAX217X RF to Bits tuner family. These hybrid
> radio receiver chips are highly programmable and hence reserving 32
> controls.
>
> Signed-off-by: Ramesh Shanmugasundaram
>
Acked-by: Laurent Pinchart
> ---
> include/uapi/linux/v4l2-controls.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/uapi/linux/v4l2-controls.h
> b/include/uapi/linux/v4l2-controls.h index 0d2e1e0..83b28b4 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -180,6 +180,11 @@ enum v4l2_colorfx {
> * We reserve 16 controls for this driver. */
> #define V4L2_CID_USER_TC358743_BASE (V4L2_CID_USER_BASE + 0x1080)
>
> +/* The base for the max217x driver controls.
> + * We reserve 32 controls for this driver
> + */
> +#define V4L2_CID_USER_MAX217X_BASE (V4L2_CID_USER_BASE + 0x1090)
> +
> /* MPEG-class control IDs */
> /* The MPEG controls are applicable to all codec controls
> * and the 'MPEG' part of the define is historical */
--
Regards,
Laurent Pinchart
Re: [PATCH 0/9] Unify i2c_mux_add_adapter error reporting
On 2017-04-03 10:38, Peter Rosin wrote: > Hi! > > Many users of the i2c_mux_add_adapter interface log a message > on failure, but the function already logs such a message. One > or two of those users actually add more information than already > provided by the central failure message. > > So, first fix the central error reporting to provide as much > information as any current user, and then remove the surplus > error reporting at the call sites. I have now pushed patches 1-7 to i2c-mux/for-next. Jonathan grabbed patch 8 and it's going through the iio tree. Still waiting on patch 9 and the media maintainers. Cheers, Peter > > Cheers, > peda > > Peter Rosin (9): > i2c: mux: provide more info on failure in i2c_mux_add_adapter > i2c: arb: gpio-challenge: stop double error reporting > i2c: mux: gpio: stop double error reporting > i2c: mux: pca9541: stop double error reporting > i2c: mux: pca954x: stop double error reporting > i2c: mux: pinctrl: stop double error reporting > i2c: mux: reg: stop double error reporting > iio: gyro: mpu3050: stop double error reporting > [media] cx231xx: stop double error reporting > > drivers/i2c/i2c-mux.c | 9 ++--- > drivers/i2c/muxes/i2c-arb-gpio-challenge.c | 4 +--- > drivers/i2c/muxes/i2c-mux-gpio.c | 4 +--- > drivers/i2c/muxes/i2c-mux-pca9541.c| 4 +--- > drivers/i2c/muxes/i2c-mux-pca954x.c| 7 +-- > drivers/i2c/muxes/i2c-mux-pinctrl.c| 4 +--- > drivers/i2c/muxes/i2c-mux-reg.c| 4 +--- > drivers/iio/gyro/mpu3050-i2c.c | 5 ++--- > drivers/media/usb/cx231xx/cx231xx-i2c.c| 15 --- > 9 files changed, 18 insertions(+), 38 deletions(-) >
Re: [PATCH 3/5] media: rc: meson-ir: switch to managed rc device allocation / registration
On 04/11/2017 08:02 AM, Heiner Kallweit wrote:
> Switch to the managed versions of rc_allocate_device/rc_register_device,
> thus simplifying the code.
>
> Signed-off-by: Heiner Kallweit
> ---
> drivers/media/rc/meson-ir.c | 18 --
> 1 file changed, 4 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c
> index a52036c5..d56ef27e 100644
> --- a/drivers/media/rc/meson-ir.c
> +++ b/drivers/media/rc/meson-ir.c
> @@ -128,7 +128,7 @@ static int meson_ir_probe(struct platform_device *pdev)
> return irq;
> }
>
> - ir->rc = rc_allocate_device(RC_DRIVER_IR_RAW);
> + ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
> if (!ir->rc) {
> dev_err(dev, "failed to allocate rc device\n");
> return -ENOMEM;
> @@ -140,7 +140,6 @@ static int meson_ir_probe(struct platform_device *pdev)
> ir->rc->input_id.bustype = BUS_HOST;
> map_name = of_get_property(node, "linux,rc-map-name", NULL);
> ir->rc->map_name = map_name ? map_name : RC_MAP_EMPTY;
> - ir->rc->dev.parent = dev;
> ir->rc->allowed_protocols = RC_BIT_ALL_IR_DECODER;
> ir->rc->rx_resolution = US_TO_NS(MESON_TRATE);
> ir->rc->timeout = MS_TO_NS(200);
> @@ -149,16 +148,16 @@ static int meson_ir_probe(struct platform_device *pdev)
> spin_lock_init(&ir->lock);
> platform_set_drvdata(pdev, ir);
>
> - ret = rc_register_device(ir->rc);
> + ret = devm_rc_register_device(dev, ir->rc);
> if (ret) {
> dev_err(dev, "failed to register rc device\n");
> - goto out_free;
> + return ret;
> }
>
> ret = devm_request_irq(dev, irq, meson_ir_irq, 0, "ir-meson", ir);
> if (ret) {
> dev_err(dev, "failed to request irq\n");
> - goto out_unreg;
> + return ret;
> }
>
> /* Reset the decoder */
> @@ -184,13 +183,6 @@ static int meson_ir_probe(struct platform_device *pdev)
> dev_info(dev, "receiver initialized\n");
>
> return 0;
> -out_unreg:
> - rc_unregister_device(ir->rc);
> - ir->rc = NULL;
> -out_free:
> - rc_free_device(ir->rc);
> -
> - return ret;
> }
>
> static int meson_ir_remove(struct platform_device *pdev)
> @@ -203,8 +195,6 @@ static int meson_ir_remove(struct platform_device *pdev)
> meson_ir_set_mask(ir, IR_DEC_REG1, REG1_ENABLE, 0);
> spin_unlock_irqrestore(&ir->lock, flags);
>
> - rc_unregister_device(ir->rc);
> -
> return 0;
> }
>
>
Reviewed-by: Neil Armstrong
Re: [PATCH 4/5] media: rc: meson-ir: use readl_relaxed in the interrupt handler
On 04/11/2017 08:05 AM, Heiner Kallweit wrote:
> We don't need the memory barriers here and an interrupt handler should
> be as fast as possible. Therefore switch to readl_relaxed.
>
> Signed-off-by: Heiner Kallweit
> ---
> drivers/media/rc/meson-ir.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c
> index d56ef27e..246da2db 100644
> --- a/drivers/media/rc/meson-ir.c
> +++ b/drivers/media/rc/meson-ir.c
> @@ -83,16 +83,17 @@ static void meson_ir_set_mask(struct meson_ir *ir,
> unsigned int reg,
> static irqreturn_t meson_ir_irq(int irqno, void *dev_id)
> {
> struct meson_ir *ir = dev_id;
> - u32 duration;
> + u32 duration, status;
> DEFINE_IR_RAW_EVENT(rawir);
>
> spin_lock(&ir->lock);
>
> - duration = readl(ir->reg + IR_DEC_REG1);
> + duration = readl_relaxed(ir->reg + IR_DEC_REG1);
> duration = FIELD_GET(REG1_TIME_IV_MASK, duration);
> rawir.duration = US_TO_NS(duration * MESON_TRATE);
>
> - rawir.pulse = !!(readl(ir->reg + IR_DEC_STATUS) & STATUS_IR_DEC_IN);
> + status = readl_relaxed(ir->reg + IR_DEC_STATUS);
> + rawir.pulse = !!(status & STATUS_IR_DEC_IN);
>
> ir_raw_event_store_with_filter(ir->rc, &rawir);
> ir_raw_event_handle(ir->rc);
>
Reviewed-by: Neil Armstrong
