On Mon, Mar 20, 2017 at 05:29:07PM +0100, Philipp Zabel wrote:
> According to the documentation [1], you are doing the right thing:
>
> The struct v4l2_subdev_frame_interval pad references a non-existing
> pad, or the pad doesn’t support frame intervals.
>
> But v4l2_subdev_call returns -
On Mon, Mar 20, 2017 at 02:17:05PM +, Russell King - ARM Linux wrote:
> On Mon, Mar 20, 2017 at 03:00:51PM +0100, Philipp Zabel wrote:
> > On Mon, 2017-03-20 at 12:08 +, Russell King - ARM Linux wrote:
> > > The same document says:
> > >
> > > Scaling
On Mon, Mar 20, 2017 at 06:40:21PM +0100, Philipp Zabel wrote:
> On Mon, 2017-03-20 at 14:17 +0000, Russell King - ARM Linux wrote:
> > I have tripped over a bug in media-ctl when specifying both a crop and
> > compose rectangle - the --help output suggests that "," shoul
On Mon, Mar 20, 2017 at 06:23:24PM +0100, Philipp Zabel wrote:
> --8<--
> >From 2830aebc404bdfc9d7fc1ec94e5282d0b668e8f6 Mon Sep 17 00:00:00 2001
> From: Philipp Zabel
> Date: Mon, 20 Mar 2017 17:10:21 +0100
> Subject: [PATCH] media: imx: csi: add sink selection rectangles
>
> Mov
On Mon, Mar 20, 2017 at 06:23:24PM +0100, Philipp Zabel wrote:
> @@ -1173,15 +1196,8 @@ static void csi_try_fmt(struct csi_priv *priv,
> incc = imx_media_find_mbus_format(infmt->code,
> CS_SEL_ANY, true);
>
> - if (sdformat
On Tue, Mar 21, 2017 at 11:59:02AM +0100, Hans Verkuil wrote:
> Ah, good to hear that -s works with MC. I was not sure about that.
> Thanks for the feedback!
Not soo good on iMX6:
$ v4l2-compliance -d /dev/video10 -s --expbuf-device=/dev/video0
...
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM
On Tue, Mar 28, 2017 at 07:21:34PM -0500, Rob Herring wrote:
> On Mon, Mar 27, 2017 at 7:40 PM, Steve Longerbeam
> wrote:
> > Add bindings documentation for the i.MX media driver.
> >
> > Signed-off-by: Steve Longerbeam
> > ---
> > Documentation/devicetree/bindings/media/imx.txt | 74
> > +
This fails at step 1. The removal of the frame interval support now
means my setup script fails when trying to set the frame interval on
the camera:
Enumerating pads and links
Setting up format SRGGB8_1X8 816x616 on pad imx219 0-0010/0
Format set: SRGGB8_1X8 816x616
Setting up frame interval 1/25
On Thu, Mar 30, 2017 at 09:12:29AM -0700, Steve Longerbeam wrote:
>
>
> On 03/30/2017 04:02 AM, Russell King - ARM Linux wrote:
> >This fails at step 1. The removal of the frame interval support now
> >means my setup script fails when trying to set the frame inte
On Fri, Feb 07, 2014 at 10:04:30AM +0100, Daniel Vetter wrote:
> I've chatted a bit with Hans Verkuil about this topic at fosdem and
> apparently both v4l and alsa have something like this already in their
> helper libraries. Adding more people as fyi in case they want to
> switch to the new driver
On Fri, Feb 07, 2014 at 12:57:21PM +0100, Jean-Francois Moine wrote:
> I started to use your code (which works fine, thanks), and it avoids a
> lot of problems, especially, about probe_defer in a DT context.
>
> I was wondering if your componentised mechanism could be extended to the
> devices def
On Fri, Feb 07, 2014 at 04:55:00PM +0100, Jean-Francois Moine wrote:
> Some simple components don't need to do any specific action on
> bind to / unbind from a master component.
>
> This patch permits such components to omit the bind/unbind
> operations.
>
> Signed-off-by: Jean-Francois Moine
>
On Fri, Feb 07, 2014 at 06:11:08PM +0100, Jean-Francois Moine wrote:
> This patch series tries to simplify the code of simple devices in case
> they are part of componentised subsystems, are declared in a DT, and
> are not using the component bin/unbind functions.
I wonder - I said earlier today t
On Fri, Feb 07, 2014 at 05:53:27PM +0100, Jean-Francois Moine wrote:
> At system startup time, some devices depends on the availability of
> some other devices before starting. The infrastructure for componentised
> subsystems permits to handle this dependence, each driver defining
> its own role.
On Fri, Feb 07, 2014 at 07:42:04PM +0100, Jean-Francois Moine wrote:
> On Fri, 7 Feb 2014 17:33:26 +
> Russell King - ARM Linux wrote:
>
> > On Fri, Feb 07, 2014 at 06:11:08PM +0100, Jean-Francois Moine wrote:
> > > This patch series tries to simplify the code o
On Fri, Feb 07, 2014 at 06:11:08PM +0100, Jean-Francois Moine wrote:
> This patch series tries to simplify the code of simple devices in case
> they are part of componentised subsystems, are declared in a DT, and
> are not using the component bin/unbind functions.
Here's my changes to the TDA998x
On Fri, Feb 07, 2014 at 06:59:11PM +, Russell King - ARM Linux wrote:
> Sorry. Deferred probe does work, it's been tested with imx-drm, not
> only from the master component but also the sub-components. There's
> no problem here.
Here's the proof that it also works wi
On Sat, Feb 08, 2014 at 06:49:49PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Since commit 020a9ea7c2 (imx-drm: imx-drm-core: avoid going the long route
> round
> for drm_device) the 'imxdrm' variable is not used anymore, which causes the
> following build warning:
>
> drivers/stagin
On Sun, Feb 09, 2014 at 10:22:19AM +0100, Jean-Francois Moine wrote:
> On Fri, 7 Feb 2014 20:23:51 +
> Russell King - ARM Linux wrote:
>
> > Here's my changes to the TDA998x driver to add support for the component
> > helper. The TDA998x driver retains suppo
On Mon, Feb 10, 2014 at 06:29:45PM +0800, Liu Ying wrote:
> This patch removes an unnecessary local variable defined
> in the function imx_drm_driver_unload() so as to fix the
> following build warning.
>
> drivers/staging/imx-drm/imx-drm-core.c: \
> In function ‘imx_drm_driver_unload’:
> drivers/
On Mon, Feb 10, 2014 at 06:42:57PM +0800, Liu Ying wrote:
> On 02/10/2014 06:29 PM, Russell King - ARM Linux wrote:
> > On Mon, Feb 10, 2014 at 06:29:45PM +0800, Liu Ying wrote:
> >> This patch removes an unnecessary local variable defined
> >> in the function imx_drm_d
This is the latest revision of my series cleaning up imx-drm and
hopefully getting it ready to be moved out of drivers/staging.
This series is updated to v3.14-rc2.
Since the last round of patches were posted, the component support
has been merged into mainline, and thus dropped from this series.
On Mon, Feb 10, 2014 at 01:53:08PM +0100, Thierry Reding wrote:
> On Fri, Feb 07, 2014 at 04:55:00PM +0100, Jean-Francois Moine wrote:
> > Some simple components don't need to do any specific action on
> > bind to / unbind from a master component.
> >
> > This patch permits such components to omit
On Mon, Feb 10, 2014 at 03:35:51PM +0100, Jean-Francois Moine wrote:
> On Mon, 10 Feb 2014 13:12:33 +
> Russell King - ARM Linux wrote:
>
> > I've NAK'd these patches already - I believe they're based on a
> > mis-understanding of how this should be us
On Mon, Feb 10, 2014 at 04:12:19PM +0100, Philipp Zabel wrote:
> Am Montag, den 10.02.2014, 12:28 + schrieb Russell King - ARM Linux:
> > This is the latest revision of my series cleaning up imx-drm and
> > hopefully getting it ready to be moved out of drivers/staging.
>
On Mon, Jan 06, 2014 at 03:52:01PM +0100, Philipp Zabel wrote:
> @@ -438,24 +453,21 @@ int imx_drm_encoder_parse_of(struct drm_device *drm,
> struct drm_encoder *encoder, struct device_node *np)
> {
> struct imx_drm_device *imxdrm = drm->dev_private;
> + struct device_node *ep, *la
On Mon, Feb 10, 2014 at 06:37:26PM +0100, Philipp Zabel wrote:
> I'd like all of them to go through, too. If you don't want to have the DT
> changes integrated, I'd appreciate if you could have a look at my
> patches on top of your series and possibly append them to your
> series or let me synchro
On Mon, Feb 10, 2014 at 12:28:03PM +, Russell King - ARM Linux wrote:
> This is the latest revision of my series cleaning up imx-drm and
> hopefully getting it ready to be moved out of drivers/staging.
> This series is updated to v3.14-rc2.
>
> Since the last round of patches w
On Wed, Feb 12, 2014 at 01:04:30PM +0100, Christian Gmeiner wrote:
> 2014-02-12 12:53 GMT+01:00 Fabio Estevam :
> > On Mon, Feb 10, 2014 at 10:28 AM, Russell King - ARM Linux
> > wrote:
> >> This is the latest revision of my series cleaning up imx-drm and
> >>
remove_proc_subtree() doesn't work here as local->ddev has already
been removed, and NULLed out. Use proc_remove() instead.
Signed-off-by: Russell King
Tested-by: Russell King
---
I would include an oops, however the machine I discovered this on has
a page 0 populated - so the symptoms are mult
On Tue, Feb 18, 2014 at 12:45:09PM +0100, Philipp Zabel wrote:
> Thanks for your comments there. I have just updated and resent this
> series ([RFC PATCH v3 0/9] imx-drm dt bindings), still with a temporary
> local copy of the v4l2_of functions, as long as the final resting place
> of the v4l2_of/o
On Tue, Feb 18, 2014 at 12:36:02PM +0100, Philipp Zabel wrote:
> From: Lucas Stach
>
> Since imx_drm_encoder_parse_of is called from the encoder bind callbacks,
> it is too late to request probe deferral. Rather the core should make sure
> that the crtcs are bound before the encoders, after all n
On Tue, Feb 18, 2014 at 12:36:03PM +0100, Philipp Zabel wrote:
> From: Philipp Zabel
>
> The existing v4l2-of parser functions for the video interface bindings
> described in Documentation/device-tree/bindings/media/video-interfaces.txt
> are useful for DRM drivers, too. They will be moved to dri
On Mon, Feb 24, 2014 at 05:56:38PM +0100, Philipp Zabel wrote:
> Am Montag, den 24.02.2014, 15:49 + schrieb Russell King - ARM Linux:
> One issue was that the DT parsing code would try to add the imx-ldb
> component right after the first crtc, and then its bind would
On Mon, Feb 24, 2014 at 12:41:41PM -0800, Greg KH wrote:
> On Mon, Feb 24, 2014 at 02:20:20PM +, Russell King wrote:
> > Greg,
> >
> > Please incorporate the latest imx-drm updates into staging, which can be
> > found at:
> >
> > git://ftp.arm.linux.org.uk/~rmk/linux-arm.git imx-drm-staging
On Wed, Feb 26, 2014 at 11:39:03AM +0300, Dan Carpenter wrote:
>
> Please fix the following static checker complaints before moving out of
> staging:
>
> drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c:164 ipu_dmfc_setup_channel() warn:
> variable dereferenced before check 'dmfc' (see line 157)
Note
On Wed, Feb 26, 2014 at 10:00:25PM +0100, Guennadi Liakhovetski wrote:
> Hi Russell
>
> (I suspect this my email will be rejected by ALKML too like other my
> recent emails, but at least other MLs will pick it up and individual CCs
> too, so, if replying, maybe it would be good to keep my entire
On Wed, Feb 26, 2014 at 06:44:36PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Fix the following static checker warning:
>
> drivers/staging/imx-drm/imx-ldb.c:340 imx_ldb_get_clk() error: format string
> overflow. buf_size: 16 length: 18
> probably 18 is theory and not real li
On Wed, Feb 26, 2014 at 07:44:33PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Fix the following static checker warning:
>
> drivers/staging/imx-drm/imx-ldb.c:340 imx_ldb_get_clk() error: format string
> overflow. buf_size: 16 length: 18
> probably 18 is theory and not real life, but
On Thu, Feb 27, 2014 at 01:06:52PM +0200, Tomi Valkeinen wrote:
> On 25/02/14 16:23, Philipp Zabel wrote:
>
> > +Freescale i.MX DRM master device
> > +
> > +
> > +The freescale i.MX DRM master device is a virtual device needed to list all
> > +IPU or other display i
On Thu, Feb 27, 2014 at 02:06:25PM +0100, Philipp Zabel wrote:
> For the i.MX6 display subsystem there is no clear single master device,
> and the physical configuration changes across the SoC family. The
> i.MX6Q/i.MX6D SoCs have two separate display controller devices IPU1 and
> IPU2, with two ou
On Thu, Feb 27, 2014 at 03:16:03PM +0200, Tomi Valkeinen wrote:
> On 27/02/14 13:56, Russell King - ARM Linux wrote:
>
> >> Is there even need for such a master device? You can find all the
> >> connected display devices from any single display device, by just
> >
On Thu, Feb 27, 2014 at 02:54:43PM -0800, Greg KH wrote:
> On Wed, Feb 26, 2014 at 08:53:41PM -0300, Fabio Estevam wrote:
> > diff --git a/drivers/staging/imx-drm/imx-ldb.c
> > b/drivers/staging/imx-drm/imx-ldb.c
> > index abf8517..daa54df 100644
> > --- a/drivers/staging/imx-drm/imx-ldb.c
> > +++
On Thu, Feb 27, 2014 at 02:52:34PM -0800, Greg KH wrote:
> On Wed, Feb 26, 2014 at 08:53:39PM -0300, Fabio Estevam wrote:
> > From: Fabio Estevam
> >
> > Fix the following static checker warning:
> >
> > drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c:164 ipu_dmfc_setup_channel()
> > warn: variable d
On Tue, Feb 25, 2014 at 12:43:42PM +0100, Philipp Zabel wrote:
> Since msleep(2) can sleep up to 20ms anyway, make this explicit by using
> usleep_range(2000, 2).
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 dele
On Wed, Mar 05, 2014 at 10:20:52AM +0100, Philipp Zabel wrote:
> +struct imx_drm_component {
> + struct device_node *of_node;
> + struct list_head list;
> +};
> +
The only thing this structure appears to be doing is ensuring that a
single component doesn't get added twice - is that correct
On Wed, Mar 05, 2014 at 10:20:57AM +0100, Philipp Zabel wrote:
> This patch fixes the TV Encoder DDC I2C bus property to use the common
> 'ddc-i2c-bus' property name instead of 'ddc'.
Looking at both hdmi and tve, the ddc part is very similar. The difference
is how the probe is handled:
imx-hdmi
On Thu, Mar 06, 2014 at 05:04:25PM +0100, Denis Carikli wrote:
> According to the datasheet, setting the di0_polarity_disp_clk
> field in the GENERAL di register sets the output clock polarity
> to active high.
>
> Signed-off-by: Denis Carikli
> ---
> ChangeLog v8->v9:
> - New patch that is now n
On Thu, Mar 06, 2014 at 05:04:26PM +0100, Denis Carikli wrote:
> diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-di.c
> b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
> index 849b3e1..5d273c1 100644
> --- a/drivers/staging/imx-drm/ipu-v3/ipu-di.c
> +++ b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
> @@ -59
On Thu, Mar 06, 2014 at 02:54:40PM +0100, Philipp Zabel wrote:
> @@ -566,9 +566,18 @@ static int imx_ldb_bind(struct device *dev, struct
> device *master, void *data)
> return -EINVAL;
> }
>
> - panel_node = of_parse_phandle(child, "fsl,panel", 0);
On Thu, Mar 06, 2014 at 02:54:39PM +0100, Philipp Zabel wrote:
> This patch allows to optionally attach the lvds-channel to a panel
> supported by a drm_panel driver instead of supplying the modes via
> device tree.
Hmm, I think something may be missing in this patch... you're introducing
calls in
On Wed, Mar 05, 2014 at 10:20:51AM +0100, Philipp Zabel wrote:
> Hi,
>
> this latest version of the imx-drm DT binding patches applies
> on top of staging-next and also depends on the OF graph binding
> patchset that moves the v4l2_of helpers to drivers/of.
> Currently, the two patchsets are also
On Fri, Mar 07, 2014 at 07:57:51PM +0100, Philipp Zabel wrote:
> [Added Shawn to Cc:]
>
> On Fri, Mar 7, 2014 at 7:28 PM, Greg Kroah-Hartman
> wrote:
> > On Fri, Mar 07, 2014 at 05:56:12PM +0000, Russell King - ARM Linux wrote:
> >> On Wed, Mar 05, 2014 at 10:20:51AM
On Tue, Mar 18, 2014 at 08:50:30AM +0100, Lothar Waßmann wrote:
> Hi,
>
> Laurent Pinchart wrote:
> > Hi Lothar,
> >
> > On Monday 17 March 2014 16:14:36 Lothar Waßmann wrote:
> > > DE is not a clock signal, but an 'Enable' signal whose value (high or
> > > low) defines the window in which the pi
On Tue, Mar 18, 2014 at 01:41:54PM +0100, Laurent Pinchart wrote:
> Hi Lothar,
>
> That's not my point. I *know* that DE is a data gating signal with a polarity
> already defined by the DRM_MODE_FLAG_POL_DE_(LOW|HIGH) flags. Like all other
> signals it gets generated on a clock edge and is sampl
On Wed, Mar 19, 2014 at 06:22:14PM +0100, Laurent Pinchart wrote:
> Hi Russell,
>
> (CC'ing Philipp Zabel who might be able to provide feedback as a user of the
> component framework)
>
> Could you please have a look at the questions below and provide an answer
> when
> you'll have time ? I'd
On Fri, Mar 07, 2014 at 12:24:33AM +0100, Laurent Pinchart wrote:
> However, we (as in the V4L2 community, and me personally) would have
> appreciated to be CC'ed on the proposal. As you might know we already had a
> solution for this problem, albeit V4L2-specific, in drivers/media/v4l2-
> core/v
On Mon, Apr 07, 2014 at 12:23:37PM +0800, Shawn Guo wrote:
> And I see another HDMI regression with my testing on mainline kernel. I
> can have my HDMI work at 1920x1080 with v3.14 kernel, but it can only
> probes 1024x768 with the mainline today.
Works for me here.
> [20.606] (II) LoadModul
On Mon, Apr 07, 2014 at 02:44:42PM +0200, Denis Carikli wrote:
> arch/arm/boot/dts/imx51-apf51dev.dts|2 +-
> arch/arm/boot/dts/imx53-m53evk.dts |2 +-
> drivers/staging/imx-drm/imx-ldb.c |4 ++--
> drivers/staging/imx-drm/ipu-v3/ipu-dc.c |4 ++--
> 4 files changed,
Hi,
The following patches are those which I currently have queued up for
Greg for merging into his stable tree when he's next accepting patches.
If you have any concerns about these patches, please let me know in
a timely fashion.
I've re-ordered and cherry-picked some of Denis' patches, as I can
On Fri, Apr 11, 2014 at 04:13:33PM +0200, Lucas Stach wrote:
> Make sure that we probe for a display on detect regardless
> of previous hotplug events. Don't handle connector
> hotplug state ourselves, but let DRM do the right thing
> for us. This brings our hotplug handling in line with
> what oth
On Fri, Apr 11, 2014 at 04:13:34PM +0200, Lucas Stach wrote:
> Makes sure we don't receive a stray IRQ on startup.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/staging/imx-drm/imx-hdmi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/imx-drm/imx-hdmi.
On Mon, Apr 14, 2014 at 10:42:32AM +0200, Lucas Stach wrote:
> Am Sonntag, den 13.04.2014, 15:58 +0100 schrieb Russell King - ARM
> Linux:
> > On Fri, Apr 11, 2014 at 04:13:33PM +0200, Lucas Stach wrote:
> > > Make sure that we probe for a display on detect regardless
>
On Mon, Apr 14, 2014 at 11:38:43AM +0200, Lucas Stach wrote:
> Am Montag, den 14.04.2014, 10:10 +0100 schrieb Russell King - ARM Linux:
> > On Mon, Apr 14, 2014 at 10:42:32AM +0200, Lucas Stach wrote:
> > > Am Sonntag, den 13.04.2014, 15:58 +0100 schrieb Russell King - ARM
>
On Mon, Apr 14, 2014 at 05:21:28PM +0200, Philipp Zabel wrote:
> Repeatedly enabling and disabling the display currently can lead to a state
> in which the IPU doesn't produce a valid signal anymore because we disable
> IPU submodules before they can finish their interaction.
Well done at finding
On Mon, Apr 14, 2014 at 12:24:45PM +0200, Lucas Stach wrote:
> Am Montag, den 14.04.2014, 11:09 +0100 schrieb Russell King - ARM Linux:
> > Now *you* please go back and read what you said about kms/userspace being
> > able to poll the connector, thereby causing an EDID read attemp
On Mon, Apr 14, 2014 at 05:21:28PM +0200, Philipp Zabel wrote:
> Repeatedly enabling and disabling the display currently can lead to a state
> in which the IPU doesn't produce a valid signal anymore because we disable
> IPU submodules before they can finish their interaction.
I'm afraid to say tha
On Mon, Apr 14, 2014 at 05:21:32PM +0200, Philipp Zabel wrote:
> Wait for the DC Frame Complete or DP Sync Flow End interrupts
> before disabling DC channels.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 71
> +++--
> 1 file chan
On Mon, Apr 14, 2014 at 11:53:15PM +0200, Philipp Zabel wrote:
> Repeatedly enabling and disabling the display currently can lead to a state
> in which the IPU doesn't produce a valid signal anymore because we disable
> IPU submodules before they can finish their interaction.
Yes, this appears to
On Mon, Apr 14, 2014 at 11:53:15PM +0200, Philipp Zabel wrote:
> Repeatedly enabling and disabling the display currently can lead to a state
> in which the IPU doesn't produce a valid signal anymore because we disable
> IPU submodules before they can finish their interaction.
>
> This series reord
On Thu, Apr 24, 2014 at 02:00:49PM -0700, Tim Harvey wrote:
> I'm still seeing issues with HDMI detect on powerup, at least on my
> Gateworks Ventana boards (which have no voltage devider or anything
> else on the HPD line to the IMX6 other than a TVS). I'm currently
> using your latest imx-drm-sta
On Thu, Apr 24, 2014 at 03:57:27PM -0700, Tim Harvey wrote:
> On Thu, Apr 24, 2014 at 3:07 PM, Russell King - ARM Linux
> wrote:
> > On Thu, Apr 24, 2014 at 02:00:49PM -0700, Tim Harvey wrote:
> >> I'm still seeing issues with HDMI detect on powerup, at least on my
>
A while back, Laurent raised some comments about the component helper,
which this patch set starts to address.
The first point it addresses is the repeated parsing inefficiency when
deferred probing occurs. When DT is used, the structure of the
component helper today means that masters end up par
On Sun, Apr 27, 2014 at 02:51:30PM +0200, Daniel Vetter wrote:
> On Sun, Apr 27, 2014 at 1:00 AM, Russell King - ARM Linux
> wrote:
> > A while back, Laurent raised some comments about the component helper,
> > which this patch set starts to address.
> >
> > The f
On Mon, Apr 03, 2017 at 09:11:35AM -0500, Rob Herring wrote:
> On Wed, Mar 29, 2017 at 09:39:05AM +0100, Russell King - ARM Linux wrote:
> > On Tue, Mar 28, 2017 at 07:21:34PM -0500, Rob Herring wrote:
> > > On Mon, Mar 27, 2017 at 7:40 PM, Steve Longerbeam
> > >
On Mon, Apr 03, 2017 at 09:07:43AM -0500, Rob Herring wrote:
> On Tue, Mar 28, 2017 at 05:35:52PM -0700, Steve Longerbeam wrote:
> > I assume if there's another binding doc in progress, it means
> > someone is working on another Synopsys DW CSI-2 subdevice driver.
>
> Yes. see http://patchwork.ozl
On Thu, Mar 30, 2017 at 07:25:49PM +0200, Philipp Zabel wrote:
> The TVP5150 DT bindings specify a single output port (port 0) that
> corresponds to the video output pad (pad 1, DEMOD_PAD_VID_OUT).
>
> Signed-off-by: Philipp Zabel
> ---
> I'm trying to get this to work with a TVP5150 analog TV de
On Tue, Apr 04, 2017 at 05:44:05PM -0700, Steve Longerbeam wrote:
>
>
> On 04/04/2017 05:40 PM, Steve Longerbeam wrote:
> >
> >
> >On 04/04/2017 04:10 PM, Russell King - ARM Linux wrote:
> >>On Thu, Mar 30, 2017 at 07:25:49PM +0200, Philipp Zabel wrote:
&g
On Thu, Apr 06, 2017 at 03:55:29PM +0200, Philipp Zabel wrote:
> +
> + /* Retain current field setting as default */
> + if (sdformat->format.field == V4L2_FIELD_ANY)
> + sdformat->format.field = fmt->field;
> +
> + /* Retain current colorspace setting as default */
> +
On Thu, Apr 06, 2017 at 04:20:21PM +0200, Hans Verkuil wrote:
> On 04/06/2017 03:55 PM, Philipp Zabel wrote:
> > If the the field order is set to ANY in set_fmt, choose the currently
> > set field order. If the colorspace is set to DEFAULT, choose the current
> > colorspace. If any of xfer_func, y
On Thu, Apr 06, 2017 at 05:01:52PM +0200, Philipp Zabel wrote:
> On Thu, 2017-04-06 at 15:05 +0100, Russell King - ARM Linux wrote:
> > On Thu, Apr 06, 2017 at 03:55:29PM +0200, Philipp Zabel wrote:
> > > +
> > > + /* Retain current field setting as default */
> &g
On Thu, Apr 13, 2017 at 07:41:48PM +0200, Stefan Wahren wrote:
> > Stefan Wahren hat am 11. April 2017 um 20:10
> > geschrieben:
> >
> >
> > Hi,
> >
> > recently i found that vchiq_test -f doesn't work anymore with current
> > mainline (4.11-rc6) and linux-next (20170404) on my Raspberry Pi Z
On Mon, Apr 24, 2017 at 06:12:09PM +0200, Stefan Wahren wrote:
> Am 20.04.2017 um 21:58 schrieb Rabin Vincent:
> > On Thu, Apr 20, 2017 at 11:27:38AM -0700, Eric Anholt wrote:
> >> I'm confused by what you're saying here. The driver has already been
> >> converted to not use dmac_map_area (commit
On Mon, Apr 24, 2017 at 07:42:27PM +0200, Stefan Wahren wrote:
> > What I can't see is how changing flush_dcache_page() has possibly broken
> > this: it seems to imply that you're getting flush_dcache_page() somehow
> > called inbetween mapping it for DMA, using it for DMA and CPU accesses
> > occu
On Sat, May 13, 2017 at 11:07:28AM +0200, Stefan Wahren wrote:
> In the meantime this issue has been fixed by Phil [1].
Right - definitely a driver bug. Mapping more memory for DMA than is
actually going to be DMA'd to and expecting data to be preserved is
really horrid.
> Unfortunately i found
On Tue, Nov 10, 2015 at 12:35:50AM +0900, Jungseung Lee wrote:
> Hi,
>
> 2015-11-09 16:57 GMT+09:00 Shailendra Verma :
> > From: Shailendra Verma
> >
> > The module end boundary check is not proper.The out of bound value
> > of module end can produce undesired results.
> >
> > Signed-off-by: Shai
On Thu, May 26, 2016 at 10:58:35AM +0100, Liviu Dudau wrote:
> On Wed, May 25, 2016 at 12:48:02PM -0700, Laura Abbott wrote:
> >
> > Ion is currently using the DMA APIs in non-compliant ways for cache
> > maintaince. The issue is Ion needs to do cache operations outside of
> > the regular DMA mode
On Fri, Jan 15, 2016 at 03:03:42PM -0800, Laura Abbott wrote:
> (adding linux-arm and a few people)
>
> On 01/14/2016 06:42 PM, Chen Feng wrote:
> >The page is already alloc at ion_alloc function,
> >ion_mmap map the alloced pages to user-space.
> >
> >The default prot can be PTE_RDONLY. Take a lo
> The central issue seems to be that I think media pad links / media bus
> formats should describe physical links, such as parallel or serial
> buses, and the formats of pixels flowing through them, whereas Steve
> would like to extend them to describe software transports and in-memory
> formats.
On Mon, Jan 23, 2017 at 12:13:26PM +0100, Philipp Zabel wrote:
> Hi Steve,
>
> On Sun, 2017-01-22 at 18:31 -0800, Steve Longerbeam wrote:
> > Second, ignoring the above locking issue for a moment,
> > v4l2_pipeline_pm_use()
> > will call s_power on the sensor _first_, then the mipi csi-2 s_power,
On Fri, Jan 06, 2017 at 06:11:24PM -0800, Steve Longerbeam wrote:
> diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts
> b/arch/arm/boot/dts/imx6q-sabrelite.dts
> index 66d10d8..9e2d26d 100644
> --- a/arch/arm/boot/dts/imx6q-sabrelite.dts
> +++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
> @@ -52,3 +5
On Fri, Jan 06, 2017 at 06:11:34PM -0800, Steve Longerbeam wrote:
> Add the core media driver for i.MX SOC.
>
> Signed-off-by: Steve Longerbeam
Applying: media: Add i.MX media core driver
.git/rebase-apply/patch:516: new blank line at EOF.
+
.git/rebase-apply/patch:528: new blank line at EOF.
+
On Fri, Jan 06, 2017 at 06:11:35PM -0800, Steve Longerbeam wrote:
> This is a media entity subdevice for the i.MX Camera
> Serial Interface module.
>
> Signed-off-by: Steve Longerbeam
warning: 3 lines add whitespace errors.
Applying: media: imx: Add CSI subdev driver
.git/rebase-apply/patch:38:
On Fri, Jan 06, 2017 at 06:11:37PM -0800, Steve Longerbeam wrote:
> This is a set of three media entity subdevice drivers for the i.MX
> Image Converter. The i.MX IC module contains three independent
> "tasks":
>
> - Pre-processing Encode task: video frames are routed directly from
> the CSI and
On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:
> Adds MIPI CSI-2 Receiver subdev driver. This subdev is required
> for sensors with a MIPI CSI2 interface.
>
> Signed-off-by: Steve Longerbeam
Applying: media: imx: Add MIPI CSI-2 Receiver subdev driver
.git/rebase-apply/patch:52
On Fri, Jan 06, 2017 at 06:11:24PM -0800, Steve Longerbeam wrote:
> + ov5640: camera@40 {
> + compatible = "ovti,ov5640";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ov5640>;
> + clocks = <&mipi_xclk>;
> + clock-names = "x
On Fri, Jan 06, 2017 at 06:11:40PM -0800, Steve Longerbeam wrote:
> +config IMX_OV5640_MIPI
> + tristate "OmniVision OV5640 MIPI CSI-2 camera support"
> + depends on GPIOLIB && VIDEO_IMX_CAMERA
> + select IMX_MIPI_CSI2
> + default y
Why is this defaulting to y? New drivers
On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:
> +static void imxcsi2_enable(struct imxcsi2_dev *csi2, bool enable)
> +{
> + if (enable) {
> + imxcsi2_write(csi2, 0x, CSI2_PHY_SHUTDOWNZ);
> + imxcsi2_write(csi2, 0x, CSI2_DPHY_RSTZ);
> +
On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:
> +++ b/drivers/staging/media/imx/imx-mipi-csi2.c
...
> +#define DEVICE_NAME "imx6-mipi-csi2"
Why is the device/driver named imx6-mipi-csi2, but the module named
imx-mipi-csi2 - could there be some consistency here please?
Thanks.
On Fri, Jan 06, 2017 at 06:11:18PM -0800, Steve Longerbeam wrote:
> Philipp Zabel (3):
> ARM: dts: imx6qdl: Add mipi_ipu1/2 multiplexers, mipi_csi, and their
> connections
> add mux and video interface bridge entity functions
> platform: add video-multiplexer subdevice driver
>
> Steve L
101 - 200 of 347 matches
Mail list logo
