Re: [PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

On Tue, Jun 10, 2014 at 04:13:06PM +0100, Russell King - ARM Linux wrote: where 'M' is the IPU DI clock muxer. However, we're currently setting this up as: LM --+ LDB serial `- /7 -+ LDB DI clock IPM --- /N IM --- IPU DI clock and hoping that the LDB

Re: [PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

On Tue, Jun 10, 2014 at 05:14:21PM +0100, Russell King - ARM Linux wrote: On Tue, Jun 10, 2014 at 04:13:06PM +0100, Russell King - ARM Linux wrote: where 'M' is the IPU DI clock muxer. However, we're currently setting this up as: LM --+ LDB serial `- /7

Re: [PATCH v14 01/10] [media] v4l2: add new V4L2_PIX_FMT_RGB666 pixel format.

On Mon, Jun 16, 2014 at 12:11:15PM +0200, Denis Carikli wrote: That new macro is needed by the imx_drm staging driver for supporting the QVGA display of the eukrea-cpuimx51 board. As I said probably around v10 time, I already have this patch queued, and I was going to send it to Greg before

Re: [PATCH v14 02/10] imx-drm: Add RGB666 support for parallel display.

On Mon, Jun 16, 2014 at 12:11:16PM +0200, Denis Carikli wrote: Signed-off-by: Denis Carikli de...@eukrea.com Acked-by: Philipp Zabel p.za...@pengutronix.de As I said probably around v10 time, I already have this patch queued, and I was going to send it to Greg before the previous merge window,

Re: [PATCH v14 03/10] imx-drm: Correct BGR666 and the board's dts that use them.

On Mon, Jun 16, 2014 at 12:11:17PM +0200, Denis Carikli wrote: The current BGR666 is not consistent with the other color mapings like BGR24. BGR666 should be in the same byte order than BGR24. Signed-off-by: Denis Carikli de...@eukrea.com Acked-by: Philipp Zabel p.za...@pengutronix.de As I

Re: [PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

On Mon, Jun 16, 2014 at 11:13:02AM -0300, Fabio Estevam wrote: On Wed, Jun 11, 2014 at 5:17 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: The problem here is that we need more inteligence from CCF in order to do that - we need it to be able to reprogram the dividers so

Re: [PATCH v14 06/10] drm: drm_display_mode: add signal polarity flags

On Mon, Jun 16, 2014 at 12:11:20PM +0200, Denis Carikli wrote: We need a way to pass signal polarity informations between DRM panels, and the display drivers. To do that, a pol_flags field was added to drm_display_mode. Signed-off-by: Denis Carikli de...@eukrea.com This patch needs an

Re: [PATCH v14 08/10] drm/panel: Add Eukrea mbimxsd51 displays.

Denis, This patch creates binding documentation. Any patch which does so should be copied to the DT people so they can review the bindings and give appropriate acks. It would be better if you separate the binding documentation updates from the other functional changes too. I've added them on

Re: [PATCH v14 04/10] imx-drm: use defines for clock polarity settings

On Mon, Jun 16, 2014 at 12:11:18PM +0200, Denis Carikli wrote: Signed-off-by: Denis Carikli de...@eukrea.com It would be nice to have a little more explanation in the commit messages for these patches. If you'd like to send me better commit messages for these patches, I'll add them to what I

Re: [PATCH v14 04/10] imx-drm: use defines for clock polarity settings

On Tue, Jun 24, 2014 at 06:25:19PM +0200, Denis Carikli wrote: On 06/24/2014 05:13 PM, Russell King - ARM Linux wrote: [...] If you'd like to send me better commit messages for these patches, I'll add them to what I already have: imx-drm: use defines for clock polarity settings

Re: [PATCH v14 04/10] imx-drm: use defines for clock polarity settings

On Wed, Jun 25, 2014 at 06:48:45AM +0200, Sascha Hauer wrote: On Mon, Jun 16, 2014 at 12:11:18PM +0200, Denis Carikli wrote: + /* * Bitfield of Display Interface signal polarities. */ @@ -37,7 +43,7 @@ struct ipu_di_signal_cfg { unsigned clksel_en:1; unsigned

Re: [PATCH v14 07/10] imx-drm: Use drm_display_mode timings flags.

On Mon, Jun 16, 2014 at 12:11:21PM +0200, Denis Carikli wrote: The previous hardware behaviour was kept if the flags are not set. I'd like to throw in a patch that I've been carrying for a bit now. It conflicts with your patches, but I'm happy to fix that conflict locally (and have been doing

Re: [PATCH RFC v2 3/8] component: add support for component match array

On Thu, Jun 26, 2014 at 02:34:17PM +0200, Philipp Zabel wrote: Hi Russell, On Tue, Jun 24, 2014 at 9:29 PM, Russell King rmk+ker...@arm.linux.org.uk wrote: [...] +/* + * Add a component to be matched. + * + * The match array is first created or extended if necessary. + */ +void

Re: [PATCH v14 04/10] imx-drm: use defines for clock polarity settings

On Wed, Jun 25, 2014 at 11:44:47AM +0200, Denis Carikli wrote: On 06/25/2014 06:48 AM, Sascha Hauer wrote: +#define ENABLE_POL_LOW 0 +#define ENABLE_POL_HIGH1 Adding defines without a proper namespace (IPU_) outside a driver private header file is not nice. Anyway,

[PATCH 0/2] imx-drm: two unbind bugs

The following two patches fix a couple of oopses I've found while re-testing the unbind support for imx-drm. Can I suggest that people check that it's possible to successfully unbind and rebind the driver when they add stuff (like the ipu plane support)? I have these queued for Greg to pull.

Re: [PATCH RFC v2 3/8] component: add support for component match array

On Thu, Jun 26, 2014 at 03:46:01PM +0100, Russell King - ARM Linux wrote: On Thu, Jun 26, 2014 at 02:34:17PM +0200, Philipp Zabel wrote: Hi Russell, On Tue, Jun 24, 2014 at 9:29 PM, Russell King rmk+ker...@arm.linux.org.uk wrote: [...] +/* + * Add a component to be matched

[PATCH v3 0/8] component helper improvements

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

Re: [RFC PATCH 0/8] component helper improvements

On Wed, May 14, 2014 at 08:42:17PM +0200, Thierry Reding wrote: I've been looking at converting the Tegra DRM driver to the component helpers for a while now and had to make some changes to make it work for that particular use-case. While updating the imx-drm and msm DRM drivers for those

Re: [PATCH RFC v2 3/8] component: add support for component match array

On Thu, Jul 03, 2014 at 12:26:39AM +0900, Inki Dae wrote: It's has been just a week. I will check and look into your patch series. I think Exynos drm should also be considered for the use of component match array. Actually, this series has been around for much longer than just a week. Your

Re: [PATCH v3 0/8] component helper improvements

On Thu, Jul 03, 2014 at 01:51:19AM +0200, Laurent Pinchart wrote: On Wednesday 02 July 2014 15:59:04 Russell King - ARM Linux wrote: On Tue, Jul 01, 2014 at 03:40:11PM +0100, Russell King - ARM Linux wrote: A while back, Laurent raised some comments about the component helper, which

Re: [GIT PULL] component helper updates for 3.17

On Thu, Jul 03, 2014 at 01:20:03PM -0700, Greg Kroah-Hartman wrote: On Thu, Jul 03, 2014 at 03:10:40PM +0100, Russell King wrote: Greg, Please incorporate the latest component updates, which can be found at: git://ftp.arm.linux.org.uk/~rmk/linux-arm.git component-for-driver

Re: [PATCH v3 3/8] component: add support for component match array

On Fri, Jul 04, 2014 at 04:17:35PM +0530, Sachin Kamat wrote: Hi Russell +int component_master_add_with_match(struct device *dev, + const struct component_master_ops *ops, + struct component_match *match) { struct master *master; int ret; + if

Re: [PATCH v3 3/8] component: add support for component match array

On Fri, Jul 04, 2014 at 05:00:36PM +0530, Sachin Kamat wrote: On Fri, Jul 4, 2014 at 4:22 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Jul 04, 2014 at 04:17:35PM +0530, Sachin Kamat wrote: Hi Russell +int component_master_add_with_match(struct device *dev

Re: [PATCH v5 06/11] imx-drm: imx-tve: Fix DDC I2C bus property

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:

Re: [PATCH v9][ 4/8] imx-drm: Match ipu_di_signal_cfg's clk_pol with its description.

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 de...@eukrea.com --- ChangeLog v8-v9: - New patch that

Re: [PATCH 2/2] imx-drm: imx-ldb: Use OF graph to find connected panel

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

Re: [PATCH 1/2] imx-drm: imx-ldb: Add drm_panel support

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 into

Re: [PATCH v5 00/11] imx-drm dt bindings

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

Re: [PATCH v5 00/11] imx-drm dt bindings

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 gre...@linuxfoundation.org wrote: On Fri, Mar 07, 2014 at 05:56:12PM +, Russell King - ARM Linux wrote: On Wed, Mar 05, 2014 at 10:20:51AM +0100

Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags

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 pixel data is

Re: [PATCH 07/12] drm: drm_display_mode: add signal polarity flags

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 sampled

Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems

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

Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems

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-

Re: [PATCH v5 00/11] imx-drm dt bindings

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) LoadModule:

Re: [PATCH v12][ 03/12] imx-drm: Correct BGR666 and the board's dts that use them.

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

Re: [PATCH 2/4] staging: imx-hdmi: correct connector detect and hotplug

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 other

Re: [PATCH 3/4] staging: imx-hdmi: clear all hotplug IRQs on bind

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 l.st...@pengutronix.de --- drivers/staging/imx-drm/imx-hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH 2/4] staging: imx-hdmi: correct connector detect and hotplug

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 of previous hotplug events. Don't

Re: [PATCH 2/4] staging: imx-hdmi: correct connector detect and hotplug

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 Linux: On Fri, Apr 11

Re: [PATCH 0/7] Reorder i.MX IPU display enable/disable sequence

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

Re: [PATCH 2/4] staging: imx-hdmi: correct connector detect and hotplug

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 attempt while HPD may

Re: [PATCH 0/7] Reorder i.MX IPU display enable/disable sequence

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 that

Re: [PATCH 4/7] imx-drm: ipu-dc: Wait for DC_FC_1 / DP_SF_END interrupt

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 p.za...@pengutronix.de --- drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 71

Re: [PATCH v2 0/8] Reorder i.MX IPU display enable/disable sequence

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

Re: [PATCH v2 0/8] Reorder i.MX IPU display enable/disable sequence

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 reorders

Re: [PATCH] imx-drm: fix hdmi hotplug detection initial state

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

Re: [PATCH] imx-drm: fix hdmi hotplug detection initial state

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 li...@arm.linux.org.uk 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 Gateworks

Re: [RFC PATCH 0/8] component helper improvements

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 li...@arm.linux.org.uk wrote: A while back, Laurent raised some comments about the component helper, which this patch set starts to address. The first point

Re: [PATCH 1/1] staging: imx-drm: Lines over 80 characters fixed.

On Tue, Aug 19, 2014 at 05:36:10PM +0300, Yannis Damigos wrote: diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c b/drivers/staging/imx-drm/ipuv3-crtc.c index 720868b..d6657a0 100644 --- a/drivers/staging/imx-drm/ipuv3-crtc.c +++ b/drivers/staging/imx-drm/ipuv3-crtc.c @@ -201,9 +201,10 @@

Re: [PATCH RFC v2 3/8] component: add support for component match array

On Thu, Jul 03, 2014 at 12:26:39AM +0900, Inki Dae wrote: 2014-07-01 23:22 GMT+09:00 Russell King - ARM Linux li...@arm.linux.org.uk: On Thu, Jun 26, 2014 at 03:46:01PM +0100, Russell King - ARM Linux wrote: On Thu, Jun 26, 2014 at 02:34:17PM +0200, Philipp Zabel wrote: Hi Russell

Re: [PATCH v18 12/12] drm: bridge/dw_hdmi: add rockchip rk3288 support

On Thu, Dec 11, 2014 at 12:24:15PM +0100, Heiko Stübner wrote: Past practices suggest that having the dw in the name is a sane solution too, like in dw_mmc-foo (mmc/host), dwmac-foo (net/ethernet/stmicro/stmmac). And personally I'd keep to this already established naming scheme ... i.e.

Re: [PATCH v18 04/12] drm: imx: imx-hdmi: split phy configuration to platform driver

On Fri, Dec 05, 2014 at 02:25:50PM +0800, Andy Yan wrote: hdmi phy configuration is platform specific, which can be adusted Minor typo: adjusted -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. ___

Re: [PATCH v18.1 03/12] drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode

On Tue, Jan 06, 2015 at 12:52:24PM +0100, Heiko Stübner wrote: +static void imx_hdmi_bridge_nope(struct drm_bridge *bridge) _nope ? As in No? Or should this be _nop for no-operation ? -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net.

Re: [PATCH/RFC 5/6] staging: board: Add support for devices with complex dependencies

On Fri, Apr 03, 2015 at 03:57:27PM +0300, Dan Carpenter wrote: On Fri, Apr 03, 2015 at 02:42:02PM +0200, Geert Uytterhoeven wrote: +int __init board_staging_register_clock(const struct board_staging_clk *bsc) +{ + struct clk *clk; + int error; + + pr_debug(Registering clock

Re: [PATCH/RFC 5/6] staging: board: Add support for devices with complex dependencies

On Fri, Apr 03, 2015 at 03:27:40PM +0200, Geert Uytterhoeven wrote: On Fri, Apr 3, 2015 at 2:57 PM, Dan Carpenter dan.carpen...@oracle.com wrote: + error = clk_register_clkdev(clk, bsc-con_id, bsc-dev_id); + if (error) + pr_err(Failed to register clock %s (%d)\n,

Re: [PATCH] arch:arm:mm:Correction in the boundary check for module end address.

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

Re: [RFC][PATCH 1/3] staging: ion: Move away from the DMA APIs for cache flushing

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

Re: [PATCH] staging: ion: make the pte default none PTE_RDONLY

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

Re: [RFCv2][PATCH 2/5] arm: Implement ARCH_HAS_FORCE_CACHE

On Mon, Aug 08, 2016 at 10:49:34AM -0700, Laura Abbott wrote: > +/* > + * Make an area consistent for devices. > + * Note: Drivers should NOT use this function directly, as it will break > + * platforms with CONFIG_DMABOUNCE. > + * Use the driver DMA support - see dma-mapping.h (dma_sync_*) > + */

Re: [PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote: > +static int imxcsi2_get_fmt(struct v4l2_subdev *sd, > +struct v4l2_subdev_pad_config *cfg, > +struct v4l2_subdev_format *sdformat) > +{ > + struct imxcsi2_dev *csi2 =

Re: [PATCH v3 00/24] i.MX Media Driver

On Thu, Feb 02, 2017 at 10:26:55AM -0800, Steve Longerbeam wrote: > On 02/02/2017 09:56 AM, Russell King - ARM Linux wrote: > >and for whatever reason we end up falling out through free_ring. This > >is VERY bad news, because it means that the ring which SMFC took a copy >

Re: [PATCH v3 00/24] i.MX Media Driver

On Thu, Feb 02, 2017 at 11:12:41AM -0800, Steve Longerbeam wrote: > Here is the current .queue_setup() op in imx-media-capture.c: > > static int capture_queue_setup(struct vb2_queue *vq, >unsigned int *nbuffers, >unsigned int

Re: [PATCH v3 16/24] media: Add i.MX media core driver

On Fri, Jan 06, 2017 at 06:11:34PM -0800, Steve Longerbeam wrote: > +struct imx_media_dev { > + struct media_device md; > + struct v4l2_device v4l2_dev; This is similarly buggy. struct v4l2_device { struct device *dev; #if defined(CONFIG_MEDIA_CONTROLLER) struct

Re: [PATCH v3 16/24] media: Add i.MX media core driver

On Fri, Jan 06, 2017 at 06:11:34PM -0800, Steve Longerbeam wrote: > +/* register an internal subdev as a platform device */ > +static struct imx_media_subdev * > +add_internal_subdev(struct imx_media_dev *imxmd, > + const struct internal_subdev *isd, > + int ipu_id)

Re: [PATCH v3 20/24] media: imx: Add Camera Interface subdev driver

On Fri, Jan 06, 2017 at 06:11:38PM -0800, Steve Longerbeam wrote: > +struct camif_priv { > + struct device *dev; > + struct video_devicevfd; You can't do this. > +static struct video_device camif_videodev = { > + .fops = _fops, > + .ioctl_ops =

Re: [PATCH v3 00/24] i.MX Media Driver

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.

Re: [PATCH v3 17/24] media: imx: Add CSI subdev driver

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:

Re: [PATCH v3 00/24] i.MX Media Driver

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

Re: [PATCH v3 17/24] media: imx: Add CSI subdev driver

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

Re: [PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

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

Re: [PATCH v3 17/24] media: imx: Add CSI subdev driver

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

Re: [PATCH v3 00/24] i.MX Media Driver

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.

Re: [PATCH v3 00/24] i.MX Media Driver

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

Re: [PATCH v3 00/24] i.MX Media Driver

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

Re: [PATCH v3 00/24] i.MX Media Driver

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_

Re: [PATCH v3 20/24] media: imx: Add Camera Interface subdev driver

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

Re: [PATCH v3 00/24] i.MX Media Driver

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

Re: [PATCH v3 00/24] i.MX Media Driver

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

Re: [PATCH v3 00/24] i.MX Media Driver

On Wed, Feb 01, 2017 at 11:42:31AM +0100, Philipp Zabel wrote: > On Wed, 2017-02-01 at 10:11 +0000, Russell King - ARM Linux wrote: > Right, it's just that in the latest version there is no v4l2_subdev for > fifos and idmac. There is the capture interface entity that represents > one

Re: [PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

On Wed, Feb 08, 2017 at 03:23:53PM -0800, Steve Longerbeam wrote: > >Actually, this exact function already exists as dw_mipi_dsi_phy_write in > >drivers/gpu/drm/rockchip/dw-mipi-dsi.c, and it looks like the D-PHY > >register 0x44 might contain a field called HSFREQRANGE_SEL. > > Thanks for

Re: [PATCH v3 06/24] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

On Sun, Feb 05, 2017 at 05:24:30PM +0200, Laurent Pinchart wrote: > Hi Russell, > > On Monday 30 Jan 2017 22:51:33 Russell King - ARM Linux wrote: > > > + ov5640_to_mipi_csi: endpoint@1 { > > > + reg = <1>; > > >

Re: [PATCH v3 00/24] i.MX Media Driver

I seem to be getting some sort of memory corruption with this driver. I've had two instances now of uninitialised spinlocks in imx_media_dma_buf_get_active() which show that the spinlock being taken in this function is all-zeros. That very quickly leads to an oops, where I've seen buf->ring is

Re: [PATCH v3 18/24] media: imx: Add SMFC subdev driver

Hi Steve, On Fri, Jan 06, 2017 at 06:11:36PM -0800, Steve Longerbeam wrote: > +/* > + * Min/Max supported width and heights. > + * > + * We allow planar output from the SMFC, so we have to align > + * output width by 16 pixels to meet IDMAC alignment requirements, > + * which also means input

Re: [PATCH v3 20/24] media: imx: Add Camera Interface subdev driver

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-compliance > &g

Re: [PATCH v3 00/24] i.MX Media Driver

On Thu, Feb 02, 2017 at 05:22:46PM +, Russell King - ARM Linux wrote: > I thought, maybe, it's the IPU overwriting past the end of the buffer, > but I've added checks and that doesn't seem to have fired. I also > wondered if it was some kind of use-after-free of the ring,

Re: [PATCH v3 20/24] media: imx: Add Camera Interface subdev driver

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,

Re: [PATCH v3 20/24] media: imx: Add Camera Interface subdev driver

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

Re: [PATCH v3 00/24] i.MX Media Driver

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

Re: [PATCH v3 16/24] media: Add i.MX media core driver

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

Re: [PATCH v3 19/24] media: imx: Add IC subdev drivers

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

Re: [PATCH v3 17/24] media: imx: Add CSI subdev driver

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

Re: [PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

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

Re: [PATCH v3 06/24] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

On Fri, Jan 06, 2017 at 06:11:24PM -0800, Steve Longerbeam wrote: > + ov5640: camera@40 { > + compatible = "ovti,ov5640"; > + pinctrl-names = "default"; > + pinctrl-0 = <_ov5640>; > + clocks = <_xclk>; > + clock-names = "xclk"; > +

Re: [PATCH v3 06/24] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

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

Re: [PATCH v3 16/24] media: Add i.MX media core driver

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

Re: [PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

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.

Re: [PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

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

Re: [PATCH v3 00/24] i.MX Media Driver

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 either. Only &

Re: [PATCH v3 22/24] media: imx: Add MIPI CSI-2 OV5640 sensor subdev driver

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

Re: [PATCH v3 00/24] i.MX Media Driver

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

<    1   2   3   4   >