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 symp
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 +0000, Russell King wrote:
> > Greg,
> >
> > Please incorporate the latest imx-drm updates into staging, which can be
> > found at:
> >
> > git://ftp.arm.
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
good to keep my entire reply, all
> the more that it's going to be very short)
>
> On Thu, 2 Jan 2014, Russell King wrote:
>
> > Subsystems such as ALSA, DRM and others require a single card-level
> > device structure to represent a subsystem. However, firmware tends to
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 +, 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
e, we can always postpone the flush in
> flush_dcache_page(). A similar change was done for ARM64 in commit
> b5b6c9e9149d ("arm64: Avoid cache flushing in flush_dcache_page()").
>
> Reviewed-by: Catalin Marinas
> Signed-off-by: Rabin Vincent
> Sign
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
On Tue, Jan 31, 2017 at 12:45:11AM +, Russell King - ARM Linux wrote:
> Trying this driver with an imx219 camera (which works with Philipp's
> driver) results in not much happening... no /dev/media* node for it,
> no subdevs, no nothing. No clues as to what's missing eithe
On Mon, Jan 30, 2017 at 05:22:01PM -0800, Steve Longerbeam wrote:
> Edit: I see a subdev that is missing: the video mux. Did you enable
> CONFIG_VIDEO_MULTIPLEXER?
Yes, and that's where the problem is - the video-multiplexer is
missing the module aliases to allow it to be automatically loaded.
-
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
> ---
The lack of s_frame_interval/g_frame_interval in this driver means:
media-ctl -v -d /dev/media1 --set-v4l
On Mon, Jan 30, 2017 at 05:22:01PM -0800, Steve Longerbeam wrote:
> I'm also having trouble finding a datasheet for it, but from what
> I've read, it has a MIPI CSI-2 interface. It should work fine as long
> as it presents a single source pad, registers asynchronously, and
> sets its entity functio
On Fri, Jan 06, 2017 at 06:11:35PM -0800, Steve Longerbeam wrote:
> +static int csi_link_validate(struct v4l2_subdev *sd,
> + struct media_link *link,
> + struct v4l2_subdev_format *source_fmt,
> + struct v4l2_subdev_format
On Tue, Jan 31, 2017 at 11:09:24AM +0100, Philipp Zabel wrote:
> On Mon, 2017-01-30 at 13:06 +0000, Russell King - ARM Linux wrote:
> > To help illustrate my point, consider the difference between
> > MEDIA_BUS_FMT_RGB565_1X16 and MEDIA_BUS_FMT_RGB565_2X8_BE or
> > MEDIA_
On Fri, Jan 20, 2017 at 03:38:28PM +0100, Hans Verkuil wrote:
> Should be set to something like 'platform:imx-media-camif'. v4l2-compliance
> should complain about this.
... and more.
Driver Info:
Driver name : imx-media-camif
Card type : imx-media-camif
Bus info
On Tue, Jan 31, 2017 at 02:35:00PM +0100, Philipp Zabel wrote:
> On Tue, 2017-01-31 at 13:14 +0000, Russell King - ARM Linux wrote:
> > This isn't limited to the serial side - the parallel bus side between
> > the CSI2 interface and CSI2IPU wrapper, and the CSI2IPU wrapp
On Tue, Jan 31, 2017 at 03:25:10PM +0100, Philipp Zabel wrote:
> On Tue, 2017-01-31 at 14:54 +0100, Philipp Zabel wrote:
> > Hi Steve,
> >
> > I have just tested the imx-media-staging-md-wip branch on a Nitrogen6X
> > with a tc358743 (BD_HDMI_MIPI HDMI to MIPI CSI-2 receiver board). Some
> > obser
On Tue, Jan 31, 2017 at 10:21:26AM -0800, Steve Longerbeam wrote:
> On 01/31/2017 05:42 AM, Russell King - ARM Linux wrote:
> >On Fri, Jan 20, 2017 at 03:38:28PM +0100, Hans Verkuil wrote:
> >>Should be set to something like 'platform:imx-media-camif'. v4l2-complian
On Tue, Jan 31, 2017 at 09:55:29PM +, Ian Arkver wrote:
> On 31/01/17 20:33, Russell King - ARM Linux wrote:
> >On Tue, Jan 31, 2017 at 10:21:26AM -0800, Steve Longerbeam wrote:
> >>On 01/31/2017 05:42 AM, Russell King - ARM Linux wrote:
> >>>On Fri, Jan 20,
On Tue, Jan 31, 2017 at 02:36:53PM -0800, Steve Longerbeam wrote:
> On 01/31/2017 02:04 PM, Russell King - ARM Linux wrote:
> >I don't want master though, I want v4.10-rc1, and if I ask for that
> >it tells me it knows nothing about v4.10-rc1, despite the fact that's
On Tue, Jan 31, 2017 at 03:43:22PM -0800, Steve Longerbeam wrote:
>
>
> On 01/31/2017 03:00 AM, Russell King - ARM Linux wrote:
> >Just like smiapp, the camera sensor block (which is the very far end
> >of the pipeline) is marked with MEDIA_ENT_F_CAM_SENSOR. However, in
&g
On Tue, Jan 31, 2017 at 04:31:55PM -0800, Steve Longerbeam wrote:
>
>
> On 01/31/2017 03:20 AM, Russell King - ARM Linux wrote:
> >On Fri, Jan 06, 2017 at 06:11:35PM -0800, Steve Longerbeam wrote:
> >>+static int csi_link_validate(struct v4l2_subdev *sd,
> >&g
Hi Steve,
On Tue, Jan 31, 2017 at 05:02:40PM -0800, Steve Longerbeam wrote:
> But this also puts a requirement on MIPI sensors that s_power(ON)
> should only place the D_PHY in LP-11, and _not_ start the clock lane.
> But perhaps that is correct behavior anyway.
If the CSI2 DPHY is held in reset
On Tue, Jan 31, 2017 at 05:54:52PM -0800, Steve Longerbeam wrote:
> On 01/31/2017 04:23 PM, Russell King - ARM Linux wrote:
> First, thank you for the explanation, it clears up a lot.
>
> But of_parse_subdev() is used to parse the OF graph starting
> from the CSI ports, to discove
On Wed, Feb 01, 2017 at 10:30:57AM +0100, Philipp Zabel wrote:
> On Tue, 2017-01-31 at 17:26 -0800, Steve Longerbeam wrote:
> [...]
> > right, need to fix that. Probably by poking the attached
> > source subdev (csi or prpenc/vf) for its supported formats.
>
> You are right, in bayer/raw mode only
301 - 400 of 530 matches
Mail list logo
