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
>
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 widt
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 = sd_to_dev(sd
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
NU
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-fre
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
>
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 *nplanes
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 = &camif_fops,
> + .ioctl_ops = &ca
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 media_dev
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)
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>;
> > >
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 pointin
On Fri, Apr 03, 2015 at 03:27:40PM +0200, Geert Uytterhoeven wrote:
> On Fri, Apr 3, 2015 at 2:57 PM, Dan Carpenter
> wrote:
> >> + error = clk_register_clkdev(clk, bsc->con_id, bsc->dev_id);
> >> + if (error)
> >> + pr_err("Failed to register clock %s (%d)\n", bsc->clk,
> >>
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("Regi
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_*)
> + */
On Mon, Oct 31, 2016 at 12:53:13PM -0700, Michael Zoran wrote:
> On Mon, 2016-10-31 at 11:40 -0700, Michael Zoran wrote:
> > The comment is easy to change.
> >
> > I don't have the log available ATM, but if I remember the DMA API's
> > bugcheck the first time that are used.
> >
> > I think this
On Thu, Sep 26, 2013 at 10:23:08PM +0200, Rafał Miłecki wrote:
> 2013/9/19 Russell King - ARM Linux :
> > This email is only being sent to the mailing lists in question, not to
> > anyone personally. The list of individuals is far to great to do that.
> > I'm hoping n
A suggestion to IMX developers: please run your test kernels with
PROVE_LOCKING enabled (and preferably other debugging options too.)
Thanks.
==
[ INFO: possible circular locking dependency detected ]
3.12.0-rc3+ #43 Not tainted
-
On Wed, Oct 09, 2013 at 08:07:12PM -0300, Fabio Estevam wrote:
> In order to avoid this lockdep warning, remove the locking from
> imx_drm_encoder_get_mux_id() and imx_drm_crtc_panel_format_pins().
>
> Tested on a mx6sabrelite and mx53qsb.
>
> Reported-by: Russell King
>
Another thing that my build testing (and use on cubox-i) picked up:
On Thu, Oct 03, 2013 at 03:51:26PM -0300, Fabio Estevam wrote:
> diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> index 9e8ae11..65e54b4 100644
> --- a/arch/arm/boot/dts/imx6dl.dtsi
> +++ b/arch/arm/boo
On Thu, Oct 03, 2013 at 03:51:26PM -0300, Fabio Estevam wrote:
> diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> index 9e8ae11..65e54b4 100644
> --- a/arch/arm/boot/dts/imx6dl.dtsi
> +++ b/arch/arm/boot/dts/imx6dl.dtsi
> @@ -88,3 +88,7 @@
> crtcs = <&ipu1
On Mon, Oct 14, 2013 at 06:40:30PM +0100, Russell King - ARM Linux wrote:
> Another thing that my build testing (and use on cubox-i) picked up:
>
> On Thu, Oct 03, 2013 at 03:51:26PM -0300, Fabio Estevam wrote:
> > diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/
On Tue, Oct 15, 2013 at 09:46:18AM +0200, Sascha Hauer wrote:
> On Mon, Oct 14, 2013 at 11:50:29PM +0100, Russell King - ARM Linux wrote:
> > Answers to these two questions may help stop me wasting a lot of time
> > chasing what is a really weird bug.
> >
> > So, I h
On Mon, Oct 14, 2013 at 11:47:17PM -0300, Fabio Estevam wrote:
> On Mon, Oct 14, 2013 at 2:38 PM, Russell King - ARM Linux
> wrote:
>
> > Shouldn't the above be in patch 1 (or 1.5) rather than patch 2? Patch 2
> > advertises itself as adding support for the wandboa
On Tue, Oct 15, 2013 at 10:18:30AM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 15, 2013 at 09:46:18AM +0200, Sascha Hauer wrote:
> > This sounds like the wrong clock polarity. Could you try inverting
> > sig_cfg.clk_pol in imx-drm/ipuv3-crtc.c?
>
> I tweaked it a d
r array to be empty, and userspace KMS to fail.
There's also bugs in the CSC setting too - it runs off the end of the
array and gcc warns about this. The code was clearly wrong.
You may wish to combine this patch with patch 1 to sort all that out.
For the patch below:
Signed-off-by: Russe
On Tue, Oct 15, 2013 at 10:17:07AM -0300, Fabio Estevam wrote:
> On Tue, Oct 15, 2013 at 10:10 AM, Russell King - ARM Linux
> wrote:
> > Another point on patch 1. Sorry, I don't have patch 1 to reply to, it
> > seems it was deleted from linux-arm-ke
On Wed, Oct 16, 2013 at 06:03:42PM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 15, 2013 at 10:17:07AM -0300, Fabio Estevam wrote:
> > On Tue, Oct 15, 2013 at 10:10 AM, Russell King - ARM Linux
> > wrote:
> > > Another point on patch 1. Sorry, I don't
On Wed, Oct 16, 2013 at 11:31:07AM -0700, Greg Kroah-Hartman wrote:
> On Wed, Oct 16, 2013 at 07:07:35PM +0100, Russell King - ARM Linux wrote:
> > Sorry, but I don't think imx-drm is driving the hardware correctly, and
> > I know that Greg wants it moved out of drivers/sta
On Wed, Oct 16, 2013 at 12:37:42PM -0700, Troy Kisky wrote:
> On 10/16/2013 10:03 AM, Russell King - ARM Linux wrote:
>> On Tue, Oct 15, 2013 at 10:17:07AM -0300, Fabio Estevam wrote:
>>> On Tue, Oct 15, 2013 at 10:10 AM, Russell King - ARM Linux
>>> wrote:
>>&g
On Wed, Oct 16, 2013 at 02:03:17PM -0700, Troy Kisky wrote:
> Freescale's kernel(imx_3.0.35_4.1.0) has this code
>
> video/mxc_hdmi.c-/* Workaround to clear the overflow condition */
> video/mxc_hdmi.c-static void mxc_hdmi_clear_overflow(void)
> video/mxc_hdmi.c-{
> video/mxc_hdmi.c- int coun
Okay, next problem...
As I described via the Cubox-i community last night on google+...
I'm now at the point where certain resolutions and refreshes work fine
(eg, 720p @ 50 or 60Hz, 1366x768, 1024x768).
Others either don't display (1080p, 800x600, 848x480, 640x480), or have
speckles, a line of
On Wed, Oct 16, 2013 at 11:31:07AM -0700, Greg Kroah-Hartman wrote:
> On Wed, Oct 16, 2013 at 07:07:35PM +0100, Russell King - ARM Linux wrote:
> > Sorry, but I don't think imx-drm is driving the hardware correctly, and
> > I know that Greg wants it moved out of drivers/sta
Another problem.
After performing several modesets, the IPU seems to lock up and produce
no syncs or output data.
I've seen this many times over the last week while testing out various
aspects of imx-drm, and had put it down to problems with the clocking
arrangement getting its settings wrong. N
On Sun, Oct 20, 2013 at 01:04:34AM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 16, 2013 at 11:31:07AM -0700, Greg Kroah-Hartman wrote:
> > On Wed, Oct 16, 2013 at 07:07:35PM +0100, Russell King - ARM Linux wrote:
> > > Sorry, but I don't think imx-drm is driving
On Sun, Oct 20, 2013 at 02:00:57PM +0100, Russell King - ARM Linux wrote:
> As for imx-drm, there was a warning which preceded that oops. Here's the
> full log, below the "-" marker - this is from unbinding the imx-drm
> module, and then trying to reboot.
>
On Sun, Oct 20, 2013 at 05:31:56PM +0100, Russell King - ARM Linux wrote:
> On Sun, Oct 20, 2013 at 02:00:57PM +0100, Russell King - ARM Linux wrote:
> > As for imx-drm, there was a warning which preceded that oops. Here's the
> > full log, below the "-" m
On Mon, Oct 28, 2013 at 06:26:49PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam
>
> This is based on the initial work done by Sascha Hauer and Tony Prisk.
It looks like you've also taken some of the suggestions I've made too -
like the voltage drive and symbol transmit control settings.
It
On Tue, Oct 29, 2013 at 01:45:50PM -0200, Fabio Estevam wrote:
> On Tue, Oct 29, 2013 at 1:00 PM, Fabio Estevam wrote:
>
> > Today I was able to get access to a wandboard solo and the HDMI image
> > does look different compared to a wandboard quad board:
> >
> > - The Linux logo penguins are stea
clk_pol)
> di_gen |= DI_GEN_POLARITY_DISP_CLK;
>
> With 'di0_polarity_disp_clk' bit set we do not have stable HDMI output on
> mx6solo: contours of pictures look jittery and the white colour does not
> appear really white.
>
> Russell King initially repor
On Tue, Oct 29, 2013 at 08:01:46PM -0200, Fabio Estevam wrote:
> Hi Greg,
>
> On Mon, Oct 28, 2013 at 7:03 PM, Greg KH wrote:
> > And why is new support being added to this driver instead of working to
> > get it out of staging?
>
> Philipp Zabel mentioned that he will submit the imx-drm driver
On Mon, Oct 28, 2013 at 06:26:49PM -0200, Fabio Estevam wrote:
> + /*Wait for PHY PLL lock */
> + msec = 4;
> + val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
> + while (!val) {
> + udelay(1000);
> + if (msec-- == 0) {
> +
On Thu, Oct 31, 2013 at 09:46:40AM -0200, Mauro Carvalho Chehab wrote:
> Hi Russell,
>
> Em Mon, 30 Sep 2013 13:57:47 +0200
> Hans Verkuil escreveu:
>
> > On 09/19/2013 11:44 PM, Russell King wrote:
> > > Replace the following sequence:
> &g
On Thu, Oct 31, 2013 at 06:45:41PM -0200, Fabio Estevam wrote:
> Hi Troy,
>
> On Thu, Oct 31, 2013 at 6:38 PM, Troy Kisky
> wrote:
>
> >> I get a magenta line down the left side of the screen unless I replace the
> >> 5 with a 6.
> >> ie.
> >>
> >> +for (count = 0; count < 6; count++)
> >> +
On Tue, Nov 12, 2013 at 05:49:18PM +0100, Denis Carikli wrote:
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index fc2adb6..586c12f 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -537,6 +537,15 @@ int drm_display_mode_from_videomode(
On Wed, Nov 13, 2013 at 08:53:18AM +0100, Eric Bénard wrote:
> Hi Russell,
>
> Le Tue, 12 Nov 2013 17:04:55 +,
> Russell King - ARM Linux a écrit :
> > On Tue, Nov 12, 2013 at 05:49:18PM +0100, Denis Carikli wrote:
> > > diff --git a/drivers/gpu/drm/drm_modes.c b/
On Wed, Nov 13, 2013 at 11:43:44AM -0700, Troy Kisky wrote:
> On 11/13/2013 2:23 AM, Denis Carikli wrote:
>> + /* rgb666 */
>> +ipu_dc_map_clear(priv, IPU_DC_MAP_RGB666);
>> +ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 2, 17, 0xfc); /* red */
>> +ipu_dc_map_config(priv, IPU_DC_MAP_RGB
On Mon, Dec 02, 2013 at 04:39:26PM +0100, Marek Vasut wrote:
> Add DRM flags for the LCD display clock polarity so the pixelclk-active DT
> property can be properly handled by drivers using the DRM API.
I still say that not even this should be part of the DRM mode API to
userspace. The hint that
On Tue, Dec 03, 2013 at 07:44:52PM +0800, Shawn Guo wrote:
> On Mon, Dec 02, 2013 at 04:39:26PM +0100, Marek Vasut wrote:
> > Add DRM flags for the LCD display clock polarity so the pixelclk-active DT
> > property can be properly handled by drivers using the DRM API.
> >
> > Signed-off-by: Marek V
-drm/ipuv3-plane.c | 10
3 files changed, 41 insertions(+), 22 deletions(-)
Russell King (4):
imx-drm: imx-drm-core: fix error cleanup path for imx_drm_add_crtc()
imx-drm: imx-drm-core: fix DRM cleanup paths
imx-drm: fix missing symbol exports
imx-drm: ipu-v3
On Mon, Dec 16, 2013 at 11:33:01AM +, Russell King - ARM Linux wrote:
> The following patch series fixes some bugs and races in the imx-drm
> code, which should probably be applied to an -rc kernel.
>
> drivers/staging/imx-drm/imx-drm-core.c | 21 -
>
On Tue, Dec 17, 2013 at 12:28:37PM +0800, Shawn Guo wrote:
> On Mon, Dec 16, 2013 at 11:34:05AM +0000, Russell King wrote:
> > Trying to build a modular imx-drm results in a number of missing symbol
> > exports, caused by the recent changes to this driver. Add the necessary
>
On Tue, Dec 17, 2013 at 01:04:20PM +0800, Shawn Guo wrote:
> On Mon, Dec 16, 2013 at 12:38:23PM +0000, Russell King - ARM Linux wrote:
> > Russell King (8):
> > imx-drm: imx-drm-core: fix error cleanup path for imx_drm_add_crtc()
> > imx-drm: imx-drm-core:
On Tue, Dec 17, 2013 at 08:05:41AM -0800, Greg Kroah-Hartman wrote:
> On Tue, Dec 17, 2013 at 03:17:02PM +0000, Russell King - ARM Linux wrote:
> > On Tue, Dec 17, 2013 at 01:04:20PM +0800, Shawn Guo wrote:
> > > On Mon, Dec 16, 2013 at 12:38:23PM +, Russell King
Here is my large patch series which cleans up imx-drm, and gets it ready
to move out of drivers/staging. This is a preview only.
One of these patches introduces a generic helper in drivers/base which
can be used by any subsystem to assemble a sub-devices together and
complete the probe of a subsy
On Thu, Jan 02, 2014 at 07:10:55PM -0800, Greg Kroah-Hartman wrote:
> On Thu, Jan 02, 2014 at 09:27:58PM +0000, 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 Fri, Jan 03, 2014 at 12:58:16PM +0100, Rafael J. Wysocki wrote:
> On Friday, January 03, 2014 11:00:30 AM Russell King - ARM Linux wrote:
> > On Thu, Jan 02, 2014 at 07:10:55PM -0800, Greg Kroah-Hartman wrote:
> > > On Thu, Jan 02, 2014 at 09:27:58PM +,
On Fri, Jan 03, 2014 at 02:24:26PM +0100, Rafael J. Wysocki wrote:
> On Friday, January 03, 2014 12:18:13 PM Russell King - ARM Linux wrote:
> > I'm not sure what I'm looking for. I've tried looking at the results of
> > searching your linux-next branch f
On Fri, Jan 03, 2014 at 05:05:46PM +0100, David Herrmann wrote:
> Hi
>
> On Thu, Jan 2, 2014 at 10:27 PM, Russell King
> wrote:
> > The encoder possible_crtcs mask identifies which CRTCs can be bound to
> > a particular encoder. Each bit from bit 0 defines an index in th
On Fri, Jan 03, 2014 at 05:26:14PM +0100, David Herrmann wrote:
> Hi
>
> On Fri, Jan 3, 2014 at 5:13 PM, Russell King - ARM Linux
> wrote:
> > I'm not so sure - since the only place this mask gets used is with
> > the "possible_crtcs" field. It's got
On Fri, Jan 03, 2014 at 05:48:57PM +0100, Philipp Zabel wrote:
> Hi Russell,
>
> I've tested this series on a BD-SL (SabreLite) with HDMI. Right now
> the HPD signal doesn't seem to work, but after overwriting the
> connection check, I got a stable and correct picture on the monitor:
Hmm. Does t
On Fri, Jan 03, 2014 at 06:26:44PM +0100, Philipp Zabel wrote:
> Am Freitag, den 03.01.2014, 17:07 + schrieb Russell King - ARM
> Linux:
> > On Fri, Jan 03, 2014 at 05:48:57PM +0100, Philipp Zabel wrote:
> > > Hi Russell,
> > >
> > > I've tested
On Mon, Jan 06, 2014 at 06:41:28PM +0100, Philipp Zabel wrote:
> Hi Eric,
>
> Am Freitag, den 03.01.2014, 12:14 -0700 schrieb Eric Nelson:
> > This is an issue we've seen before. The SABRE Lite board has
> > a voltage divider on the HPD pins and some monitors (esp. DVI
> > monitors) either don't d
On Tue, Jan 07, 2014 at 02:38:05PM +0800, Shawn Guo wrote:
> On Thu, Jan 02, 2014 at 09:27:48PM +0000, Russell King wrote:
> > diff --git a/drivers/staging/imx-drm/imx-drm.h
> > b/drivers/staging/imx-drm/imx-drm.h
> > index 5649f180dc44..4eb594ce9cff 100644
> > --- a/
On Tue, Jan 07, 2014 at 02:49:50PM +0800, Shawn Guo wrote:
> On Thu, Jan 02, 2014 at 09:28:19PM +0000, Russell King wrote:
> > @@ -449,6 +458,24 @@ static int imx_drm_driver_load(struct drm_device *drm,
> > unsigned long flags)
> > }
> > }
>
On Tue, Jan 07, 2014 at 04:59:35PM +0800, Shawn Guo wrote:
> On Thu, Jan 02, 2014 at 09:28:03PM +0000, Russell King wrote:
> > diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > index e75e11b36dff..0e005f21d241 100644
> &
On Tue, Jan 07, 2014 at 03:18:21PM -0500, Sean Paul wrote:
> On Thu, Jan 2, 2014 at 4:27 PM, 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
> > describ
On Tue, Jan 07, 2014 at 05:29:55PM +0100, Philipp Zabel wrote:
> Thanky you. This is what I came up with so far:
>
> From: Philipp Zabel
> Subject: [PATCH 1/2] staging: imx-hdmi: use RX_SENSE0 for plug detection if
> HPD is unreliable
>
> On some boards HPD might not reliably detect DVI monitor
On Tue, Jan 07, 2014 at 02:33:22PM +0800, Shawn Guo wrote:
> On Thu, Jan 02, 2014 at 09:25:28PM +0000, Russell King - ARM Linux wrote:
> > Here is my large patch series which cleans up imx-drm, and gets it ready
> > to move out of drivers/staging. This is a preview only.
>
&g
On Thu, Jan 09, 2014 at 11:25:38PM +0800, Shawn Guo wrote:
> Yea, adding all four into imx-drm crtcs works for imx6q, but it doesn't
> for imx6dl, because &ipu2 is unavailable for imx6dl at all.
>
> Here is how I get around it.
Thanks, I've rolled your change into this commit now.
--
FTTC broad
On Fri, Jan 10, 2014 at 03:22:24PM +0100, Philipp Zabel wrote:
> Due to the voltage divider on the HPD line, the HDMI connector on
> imx6q-sabrelite doesn't reliably detect connected DVI monitors.
> This patch allows to use the RX_SENSE0 signal as a workaround when
> enabled by a boolean device tre
On Thu, Jan 02, 2014 at 07:10:55PM -0800, Greg Kroah-Hartman wrote:
> On Thu, Jan 02, 2014 at 09:27:58PM +0000, 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 Fri, Jan 10, 2014 at 07:07:02AM -0800, Greg Kroah-Hartman wrote:
> On Fri, Jan 10, 2014 at 02:54:44PM +0000, Russell King - ARM Linux wrote:
> > Greg,
> >
> > Not sure if you saw the outcome to your comment above. My conclusion
> > was:
> >
> > &quo
On Fri, Jan 10, 2014 at 07:35:30AM -0800, Greg Kroah-Hartman wrote:
> On Fri, Jan 10, 2014 at 03:11:23PM +0000, Russell King - ARM Linux wrote:
> > On Fri, Jan 10, 2014 at 07:07:02AM -0800, Greg Kroah-Hartman wrote:
> > > On Fri, Jan 10, 2014 at 02:54:44PM +, Russell King
rest of this patch series.
Thanks, here it is. Only change from the previously posted one is a
few checkpatch cleanups.
8<===
From: Russell King
Cc: Greg Kroah-Hartman
Subject: [PATCH] drivers/base: provide an infrastructure for componentised
subsystems
Subsystems such as ALSA, DRM and ot
On Sat, Jan 11, 2014 at 12:31:19PM +0100, Robert Schwebel wrote:
> On Fri, Jan 10, 2014 at 11:23:37PM +0000, Russell King - ARM Linux wrote:
> > We do this in DT by providing a "superdevice" node which specifies
> > the components, eg:
> >
> > imx-drm {
On Wed, Feb 05, 2014 at 12:02:49PM -0800, Greg Kroah-Hartman wrote:
> On Tue, Dec 17, 2013 at 05:13:48PM -0800, Greg Kroah-Hartman wrote:
> > I'll apply these after the first round goes into Linus's tree to make
> > the merging easier (i.e. after the next -rc).
>
> Now applied.
Thanks. I'll see
On Mon, Jun 09, 2014 at 10:44:14AM -0300, Fabio Estevam wrote:
> Russell,
>
> On Fri, Jun 6, 2014 at 10:56 AM, Russell King
> wrote:
> > The initial state at boot is assumed to be disconnected, and we hope
> > to receive an interrupt to update the status. Let's b
On Mon, Jun 09, 2014 at 11:29:28AM -0300, Fabio Estevam wrote:
> On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux
> wrote:
>
> > Please check the status in /sys/class/drm/card0-HDMI-A-1/status. This
> > should report the current state of the hotplug detection.
>
On Mon, Jun 09, 2014 at 03:15:16PM -0300, Fabio Estevam wrote:
> With HDMI cable connected (no image is seen on HDMI, only on lvds cable):
>
> imx-drm display-subsystem.11: bound 12.hdmi (ops hdmi_ops)
> imx-hdmi 12.hdmi: EVENT=plugin
> imx-hdmi 12.hdmi: Non-CEA mode used in HDMI
> imx
On Mon, Jun 09, 2014 at 03:38:55PM -0300, Fabio Estevam wrote:
> On Mon, Jun 9, 2014 at 3:15 PM, Fabio Estevam wrote:
> >> I wonder if the problem is that HDMI and LVDS are interfering with each
> >> other wrt the required pixel clock, and LVDS is winning. If we have
> >> HDMI enabled, many HDMI
: Parent DI clocks to video PLL via di_pre_sel
>
> Route the video PLL to the display interface clocks via the di_pre_sel
> and di_sel muxes by default.
>
> Signed-off-by: Sascha Hauer
> Signed-off-by: Philipp Zabel
> Tested-by: Russell King
> Sig
On Tue, Jun 10, 2014 at 09:58:54AM -0300, Fabio Estevam wrote:
> Booting the kernel with the HDMI cable connected (no image is seen on
> HDMI, only on LVDS):
Reformatting a bit:
> disp 0: panel size = 1920 x 1080
> Clocks: IPU 26400Hz DI 2400Hz Needed 13850Hz
> IPU clock can give 13
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 ---
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:
> >
&
On Tue, Jun 10, 2014 at 10:32:25AM -0300, Fabio Estevam wrote:
> On Tue, Jun 10, 2014 at 9:58 AM, Fabio Estevam wrote:
> > On Mon, Jun 9, 2014 at 5:09 PM, Russell King - ARM Linux
> > wrote:
> >
> >> Right, so the problem isn't at the HDMI level, but at the
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
On Mon, Jun 16, 2014 at 12:11:16PM +0200, Denis Carikli wrote:
> Signed-off-by: Denis Carikli
> Acked-by: Philipp Zabel
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,
but due to the number of patches I wa
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
> Acked-by: Philipp Zabel
As I said probably around v10 time, I a
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
> 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
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
This patch needs an ack from the
On Mon, Jun 16, 2014 at 12:11:19PM +0200, Denis Carikli wrote:
> The imx-drm driver can't use the de-active and
> pixelclk-active display-timings properties yet.
>
> Instead the data-enable and the pixel data clock
> polarity are hardcoded in the imx-drm driver.
>
> So theses properties are now s
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 th
On Mon, Jun 16, 2014 at 12:11:18PM +0200, Denis Carikli wrote:
> Signed-off-by: Denis Carikli
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 already have:
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: us
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 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;
> > unsig
cation of
the current code, and allows better decisions about things like clk_pol
to be made.
I'm sending it here because it is relevent to Denis' patch set - I will
also send it out separately if people want it separately, though that
will go to a reduced Cc list.
From: Russell King
Subj
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
> wrote:
> [...]
> > +/*
> > + * Add a component to be matched.
> > + *
> > + * The match array is first created or ex
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
401 - 500 of 530 matches
Mail list logo
