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

2014-06-09 Thread Fabio Estevam
On Mon, Jun 9, 2014 at 3:38 PM, 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 sinks will o

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

2014-06-09 Thread Russell King - ARM Linux
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

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

2014-06-09 Thread Russell King - ARM Linux
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

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

2014-06-09 Thread Russell King - ARM Linux
On Mon, Jun 09, 2014 at 03:47:46PM -0300, Fabio Estevam wrote: > Also tested keeping LVDS parent as PLL5 and reverted this commit: > > commit 17b9b3b9e88ac6564689283a08034faf2c048fdb > Author: Sascha Hauer > Date: Mon Apr 14 16:20:39 2014 +0200 > > ARM: imx6q: clk: Parent DI clocks to vide

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

2014-06-09 Thread Fabio Estevam
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 DI level... so > that's where we need to debug what's being setup. I left some debugging > in ipu-di.c - could you try enabling that please? Sure, will capture the logs to

[PATCH] Staging/comedi: Fixes static analysis warning raised by sparse

2014-06-09 Thread Marcos A. Di Pietro
Fixes warning static analysis warning raised by sparse in drivers/staging/comedi/drivers/ni_stc.h warning: shift too big (4294967295) for type int Signed-off-by: Marcos A. Di Pietro --- drivers/staging/comedi/drivers/ni_stc.h | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff -

Re: [PATCH v2 04/05] staging: board: Initial board staging support

2014-06-09 Thread Simon Horman
On Fri, Jun 06, 2014 at 09:07:44PM +0900, Magnus Damm wrote: > On Fri, May 30, 2014 at 8:10 AM, Simon Horman wrote: > > On Thu, May 29, 2014 at 10:27:30PM +0900, Magnus Damm wrote: > >> Hi Dan, > >> > >> On Thu, May 29, 2014 at 10:20 PM, Dan Carpenter > >> wrote: > >> > On Thu, May 29, 2014 at 10

Re: [PATCH v3 00/05] staging: Emma Mobile USB driver and KZM9D board code V3

2014-06-09 Thread Simon Horman
On Mon, Jun 09, 2014 at 02:14:38PM +0900, Magnus Damm wrote: > On Sat, Jun 7, 2014 at 12:39 AM, Greg KH wrote: > > On Fri, Jun 06, 2014 at 07:44:08PM +0900, Magnus Damm wrote: > >> staging: Emma Mobile USB driver and KZM9D board code V3 > >> > >> [PATCH v3 01/05] staging: emxx_udc: Add Emma Mobile

Re: [PATCH] Staging/comedi: Fixes static analysis warning raised by sparse

2014-06-09 Thread Dan Carpenter
On Mon, Jun 09, 2014 at 09:24:35PM -0400, Marcos A. Di Pietro wrote: > Fixes warning static analysis warning raised by sparse in > drivers/staging/comedi/drivers/ni_stc.h > > warning: shift too big (4294967295) for type int This warning seems wrong. I don't even understand how it thinks the shi

Re: [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void

2014-06-09 Thread Andrzej Hajda
On 06/09/2014 03:43 PM, David Laight wrote: > From: Of Andrzej Hajda > ... >>> You can't error out on module unload, although that's not really relevant >>> here. gpiochip_remove() is typically called when the device that registered >>> the GPIO chip is unbound. And despite some remove() callbacks

Re: [PATCH] staging: usbip: stub_main.c: Cleaning up missing null-terminate after strncpy call

2014-06-09 Thread Dan Carpenter
On Wed, Jun 04, 2014 at 11:39:49PM +0200, Rickard Strandqvist wrote: > Added a guaranteed null-terminate after call to strncpy. > > This was partly found using a static code analysis program called cppcheck. > We already knew that the string was NUL terminated because we checked strnlen() on the

<    1   2