Linux Framebuffer Layer development
 help / color / mirror / Atom feed

* [RESEND PATCH 2/2] video: mxsfb: manage LCD_RESET signal according to reset-active property
From: Mans Rullgard @ 2016-01-12 10:22 UTC (permalink / raw)
  To: Rob Herring, Tomi Valkeinen
  Cc: Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
	Jean-Christophe Plagniol-Villard, devicetree, linux-kernel,
	linux-fbdev
In-Reply-To: <1452594141-26073-1-git-send-email-mans@mansr.com>

Activate/deactivate the LCD_RESET signal as specified by the
reset-active DT property when the controller is disabled/enabled.
If the property is missing, leave the signal unchanged.

Signed-off-by: Mans Rullgard <mans@mansr.com>
---
 drivers/video/fbdev/mxsfb.c | 28 +++++++++++++++++++++++++---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/mxsfb.c b/drivers/video/fbdev/mxsfb.c
index 4e6608ceac09..0200a0f16675 100644
--- a/drivers/video/fbdev/mxsfb.c
+++ b/drivers/video/fbdev/mxsfb.c
@@ -99,6 +99,7 @@
 #define CTRL1_FIFO_CLEAR		(1 << 21)
 #define CTRL1_SET_BYTE_PACKAGING(x)	(((x) & 0xf) << 16)
 #define CTRL1_GET_BYTE_PACKAGING(x)	(((x) >> 16) & 0xf)
+#define CTRL1_RESET			(1 << 0)
 
 #define TRANSFER_COUNT_SET_VCOUNT(x)	(((x) & 0xffff) << 16)
 #define TRANSFER_COUNT_GET_VCOUNT(x)	(((x) >> 16) & 0xffff)
@@ -152,6 +153,9 @@
 #define MXSFB_SYNC_DATA_ENABLE_HIGH_ACT	(1 << 6)
 #define MXSFB_SYNC_DOTCLK_FALLING_ACT	(1 << 7) /* negtive edge sampling */
 
+#define MXSFB_RESET_LOW			1
+#define MXSFB_RESET_HIGH		2
+
 enum mxsfb_devtype {
 	MXSFB_V3,
 	MXSFB_V4,
@@ -181,6 +185,7 @@ struct mxsfb_info {
 	unsigned dotclk_delay;
 	const struct mxsfb_devdata *devdata;
 	u32 sync;
+	u32 reset;
 	struct regulator *reg_lcd;
 };
 
@@ -362,6 +367,11 @@ static void mxsfb_enable_controller(struct fb_info *fb_info)
 
 	writel(CTRL_RUN, host->base + LCDC_CTRL + REG_SET);
 
+	if (host->reset = MXSFB_RESET_HIGH)
+		writel(CTRL1_RESET, host->base + LCDC_CTRL1 + REG_CLR);
+	else if (host->reset = MXSFB_RESET_LOW)
+		writel(CTRL1_RESET, host->base + LCDC_CTRL1 + REG_SET);
+
 	host->enabled = 1;
 }
 
@@ -388,6 +398,11 @@ static void mxsfb_disable_controller(struct fb_info *fb_info)
 		loop--;
 	}
 
+	if (host->reset = MXSFB_RESET_HIGH)
+		writel(CTRL1_RESET, host->base + LCDC_CTRL1 + REG_SET);
+	else if (host->reset = MXSFB_RESET_LOW)
+		writel(CTRL1_RESET, host->base + LCDC_CTRL1 + REG_CLR);
+
 	reg = readl(host->base + LCDC_VDCTRL4);
 	writel(reg & ~VDCTRL4_SYNC_SIGNALS_ON, host->base + LCDC_VDCTRL4);
 
@@ -410,7 +425,7 @@ static void mxsfb_disable_controller(struct fb_info *fb_info)
 static int mxsfb_set_par(struct fb_info *fb_info)
 {
 	struct mxsfb_info *host = to_imxfb_host(fb_info);
-	u32 ctrl, vdctrl0, vdctrl4;
+	u32 ctrl, ctrl1, vdctrl0, vdctrl4;
 	int line_size, fb_size;
 	int reenable = 0;
 
@@ -439,12 +454,13 @@ static int mxsfb_set_par(struct fb_info *fb_info)
 
 	ctrl = CTRL_BYPASS_COUNT | CTRL_MASTER |
 		CTRL_SET_BUS_WIDTH(host->ld_intf_width);
+	ctrl1 = readl(host->base + LCDC_CTRL1) & CTRL1_RESET;
 
 	switch (fb_info->var.bits_per_pixel) {
 	case 16:
 		dev_dbg(&host->pdev->dev, "Setting up RGB565 mode\n");
 		ctrl |= CTRL_SET_WORD_LENGTH(0);
-		writel(CTRL1_SET_BYTE_PACKAGING(0xf), host->base + LCDC_CTRL1);
+		ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0xf);
 		break;
 	case 32:
 		dev_dbg(&host->pdev->dev, "Setting up RGB888/666 mode\n");
@@ -462,7 +478,7 @@ static int mxsfb_set_par(struct fb_info *fb_info)
 			break;
 		}
 		/* do not use packed pixels = one pixel per word instead */
-		writel(CTRL1_SET_BYTE_PACKAGING(0x7), host->base + LCDC_CTRL1);
+		ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0x7);
 		break;
 	default:
 		mxsfb_disable_axi_clk(host);
@@ -472,6 +488,7 @@ static int mxsfb_set_par(struct fb_info *fb_info)
 	}
 
 	writel(ctrl, host->base + LCDC_CTRL);
+	writel(ctrl1, host->base + LCDC_CTRL1);
 
 	writel(TRANSFER_COUNT_SET_VCOUNT(fb_info->var.yres) |
 			TRANSFER_COUNT_SET_HCOUNT(fb_info->var.xres),
@@ -736,6 +753,7 @@ static int mxsfb_init_fbinfo_dt(struct mxsfb_info *host,
 	struct device_node *display_np;
 	struct videomode vm;
 	u32 width;
+	u32 reset;
 	int ret;
 
 	display_np = of_parse_phandle(np, "display", 0);
@@ -776,6 +794,10 @@ static int mxsfb_init_fbinfo_dt(struct mxsfb_info *host,
 		goto put_display_node;
 	}
 
+	ret = of_property_read_u32(display_np, "reset-active", &reset);
+	if (!ret)
+		host->reset = reset ? MXSFB_RESET_HIGH : MXSFB_RESET_LOW;
+
 	ret = of_get_videomode(display_np, &vm, OF_USE_NATIVE_MODE);
 	if (ret) {
 		dev_err(dev, "failed to get videomode from DT\n");
-- 
2.7.0


^ permalink raw reply related

* [RESEND PATCH 1/2] devicetree: mxsfb: add reset-active property
From: Mans Rullgard @ 2016-01-12 10:22 UTC (permalink / raw)
  To: Rob Herring, Tomi Valkeinen
  Cc: Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
	Jean-Christophe Plagniol-Villard, devicetree, linux-kernel,
	linux-fbdev

Some boards connect the LCD_RESET pin to a reset input on the
display panel.  On these boards, this pin must be set to the
proper level for the display to function.

This adds an optional "reset-active" property to the "display"
subnode such that devicetrees can specify the desired polarity
of the LCD_RESET pin.

Signed-off-by: Mans Rullgard <mans@mansr.com>
---
 Documentation/devicetree/bindings/display/mxsfb.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt b/Documentation/devicetree/bindings/display/mxsfb.txt
index 96ec5179c8a0..cb7212a6bdf2 100644
--- a/Documentation/devicetree/bindings/display/mxsfb.txt
+++ b/Documentation/devicetree/bindings/display/mxsfb.txt
@@ -13,6 +13,11 @@ Required properties:
 - bits-per-pixel : <16> for RGB565, <32> for RGB888/666.
 - bus-width : number of data lines.  Could be <8>, <16>, <18> or <24>.
 
+Optional properties:
+- reset-active : <0>: reset pin is active low
+                 <1>: reset pin is active high
+                 omitted: reset pin not used
+
 Required sub-node:
 - display-timings : Refer to binding doc display-timing.txt for details.
 
-- 
2.7.0


^ permalink raw reply related

* Re: imxfb does not turn on automatically
From: Fabio Estevam @ 2016-01-11 16:32 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20160111071631.GI13058@pengutronix.de>

Hi Sascha,

On Mon, Jan 11, 2016 at 5:16 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:

> Unfortunately this LCD controller does not have an enable bit. The
> controller starts directly when the clocks are enabled. If the clocks
> are enabled when the controller is not yet programmed with proper
> register values then it just goes into some undefined state. What I
> suspect is that the clocks already were enabled before driver probe,
> presumably by the bootloader, so the controller is already in undefined
> state when entering Linux. Now by dis/enabling the ipg clock you
> effectively reset the controller. Since you have programmed it with
> valid register values in the mean time it starts working after this
> reset.
> To verify you could try to disable the LCDC related clock gates with
> direct register writes in drivers/clk/imx/clk-imx25.c.

Excellent! I did as you suggested and now the LCD turns on by default.

U-boot was enabling the LCD IPG clock.

Will submit a formal patch soon.

Thanks!

^ permalink raw reply

* Re: [PATCH 2/2] video: mxsfb: manage LCD_RESET signal according to reset-active property
From: Måns Rullgård @ 2016-01-11 14:38 UTC (permalink / raw)
  To: Jean-Christophe Plagniol-Villard
  Cc: Tomi Valkeinen, linux-fbdev, linux-kernel, marex
In-Reply-To: <1450200297-19243-2-git-send-email-mans@mansr.com>

Mans Rullgard <mans@mansr.com> writes:

> Activate/deactivate the LCD_RESET signal as specified by the
> reset-active DT property when the controller is disabled/enabled.
> If the property is missing, leave the signal unchanged.
>
> Signed-off-by: Mans Rullgard <mans@mansr.com>
> ---

Any comments on this?

>  drivers/video/fbdev/mxsfb.c | 28 +++++++++++++++++++++++++---
>  1 file changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/mxsfb.c b/drivers/video/fbdev/mxsfb.c
> index 4e6608c..0200a0f 100644
> --- a/drivers/video/fbdev/mxsfb.c
> +++ b/drivers/video/fbdev/mxsfb.c
> @@ -99,6 +99,7 @@
>  #define CTRL1_FIFO_CLEAR		(1 << 21)
>  #define CTRL1_SET_BYTE_PACKAGING(x)	(((x) & 0xf) << 16)
>  #define CTRL1_GET_BYTE_PACKAGING(x)	(((x) >> 16) & 0xf)
> +#define CTRL1_RESET			(1 << 0)
>
>  #define TRANSFER_COUNT_SET_VCOUNT(x)	(((x) & 0xffff) << 16)
>  #define TRANSFER_COUNT_GET_VCOUNT(x)	(((x) >> 16) & 0xffff)
> @@ -152,6 +153,9 @@
>  #define MXSFB_SYNC_DATA_ENABLE_HIGH_ACT	(1 << 6)
>  #define MXSFB_SYNC_DOTCLK_FALLING_ACT	(1 << 7) /* negtive edge sampling */
>
> +#define MXSFB_RESET_LOW			1
> +#define MXSFB_RESET_HIGH		2
> +
>  enum mxsfb_devtype {
>  	MXSFB_V3,
>  	MXSFB_V4,
> @@ -181,6 +185,7 @@ struct mxsfb_info {
>  	unsigned dotclk_delay;
>  	const struct mxsfb_devdata *devdata;
>  	u32 sync;
> +	u32 reset;
>  	struct regulator *reg_lcd;
>  };
>
> @@ -362,6 +367,11 @@ static void mxsfb_enable_controller(struct fb_info *fb_info)
>
>  	writel(CTRL_RUN, host->base + LCDC_CTRL + REG_SET);
>
> +	if (host->reset = MXSFB_RESET_HIGH)
> +		writel(CTRL1_RESET, host->base + LCDC_CTRL1 + REG_CLR);
> +	else if (host->reset = MXSFB_RESET_LOW)
> +		writel(CTRL1_RESET, host->base + LCDC_CTRL1 + REG_SET);
> +
>  	host->enabled = 1;
>  }
>
> @@ -388,6 +398,11 @@ static void mxsfb_disable_controller(struct fb_info *fb_info)
>  		loop--;
>  	}
>
> +	if (host->reset = MXSFB_RESET_HIGH)
> +		writel(CTRL1_RESET, host->base + LCDC_CTRL1 + REG_SET);
> +	else if (host->reset = MXSFB_RESET_LOW)
> +		writel(CTRL1_RESET, host->base + LCDC_CTRL1 + REG_CLR);
> +
>  	reg = readl(host->base + LCDC_VDCTRL4);
>  	writel(reg & ~VDCTRL4_SYNC_SIGNALS_ON, host->base + LCDC_VDCTRL4);
>
> @@ -410,7 +425,7 @@ static void mxsfb_disable_controller(struct fb_info *fb_info)
>  static int mxsfb_set_par(struct fb_info *fb_info)
>  {
>  	struct mxsfb_info *host = to_imxfb_host(fb_info);
> -	u32 ctrl, vdctrl0, vdctrl4;
> +	u32 ctrl, ctrl1, vdctrl0, vdctrl4;
>  	int line_size, fb_size;
>  	int reenable = 0;
>
> @@ -439,12 +454,13 @@ static int mxsfb_set_par(struct fb_info *fb_info)
>
>  	ctrl = CTRL_BYPASS_COUNT | CTRL_MASTER |
>  		CTRL_SET_BUS_WIDTH(host->ld_intf_width);
> +	ctrl1 = readl(host->base + LCDC_CTRL1) & CTRL1_RESET;
>
>  	switch (fb_info->var.bits_per_pixel) {
>  	case 16:
>  		dev_dbg(&host->pdev->dev, "Setting up RGB565 mode\n");
>  		ctrl |= CTRL_SET_WORD_LENGTH(0);
> -		writel(CTRL1_SET_BYTE_PACKAGING(0xf), host->base + LCDC_CTRL1);
> +		ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0xf);
>  		break;
>  	case 32:
>  		dev_dbg(&host->pdev->dev, "Setting up RGB888/666 mode\n");
> @@ -462,7 +478,7 @@ static int mxsfb_set_par(struct fb_info *fb_info)
>  			break;
>  		}
>  		/* do not use packed pixels = one pixel per word instead */
> -		writel(CTRL1_SET_BYTE_PACKAGING(0x7), host->base + LCDC_CTRL1);
> +		ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0x7);
>  		break;
>  	default:
>  		mxsfb_disable_axi_clk(host);
> @@ -472,6 +488,7 @@ static int mxsfb_set_par(struct fb_info *fb_info)
>  	}
>
>  	writel(ctrl, host->base + LCDC_CTRL);
> +	writel(ctrl1, host->base + LCDC_CTRL1);
>
>  	writel(TRANSFER_COUNT_SET_VCOUNT(fb_info->var.yres) |
>  			TRANSFER_COUNT_SET_HCOUNT(fb_info->var.xres),
> @@ -736,6 +753,7 @@ static int mxsfb_init_fbinfo_dt(struct mxsfb_info *host,
>  	struct device_node *display_np;
>  	struct videomode vm;
>  	u32 width;
> +	u32 reset;
>  	int ret;
>
>  	display_np = of_parse_phandle(np, "display", 0);
> @@ -776,6 +794,10 @@ static int mxsfb_init_fbinfo_dt(struct mxsfb_info *host,
>  		goto put_display_node;
>  	}
>
> +	ret = of_property_read_u32(display_np, "reset-active", &reset);
> +	if (!ret)
> +		host->reset = reset ? MXSFB_RESET_HIGH : MXSFB_RESET_LOW;
> +
>  	ret = of_get_videomode(display_np, &vm, OF_USE_NATIVE_MODE);
>  	if (ret) {
>  		dev_err(dev, "failed to get videomode from DT\n");
> -- 
> 2.6.3
>

-- 
Måns Rullgård

^ permalink raw reply

* Re: [PATCH] video: fbdev: pxafb: fix out of memory error path
From: Tomi Valkeinen @ 2016-01-11 11:51 UTC (permalink / raw)
  To: Robert Jarzmik, Jean-Christophe Plagniol-Villard
  Cc: linux-fbdev, linux-kernel, Julia Lawall
In-Reply-To: <87io31dvsj.fsf@belgarion.home>

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]



On 10/01/16 22:27, Robert Jarzmik wrote:
> Robert Jarzmik <robert.jarzmik@free.fr> writes:
> 
>> As seen by Julia, the initial allocation memory is not checked anymore
>> after commit "video: fbdev: pxafb: initial devicetree conversion".
>> Introduce back the removed test.
>>
>> Reported-by: Julia Lawall <julia.lawall@lip6.fr>
>> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
>> ---
>>  drivers/video/fbdev/pxafb.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
>> index 8588dd683105..54666424a720 100644
>> --- a/drivers/video/fbdev/pxafb.c
>> +++ b/drivers/video/fbdev/pxafb.c
>> @@ -2252,6 +2252,8 @@ static int pxafb_probe(struct platform_device *dev)
>>  	ret = -ENOMEM;
>>  	pdata = dev_get_platdata(&dev->dev);
>>  	inf = devm_kmalloc(&dev->dev, sizeof(*inf), GFP_KERNEL);
>> +	if (!inf)
>> +		goto failed;
>>  
>>  	if (pdata) {
>>  		*inf = *pdata;
> Tomi, Jean-Christophe,
> 
> Can you carry out this fix please ?

Thanks, queued for 4.5.

 Tomi


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply

* Re: [PATCH] backlight: pwm: free pwm requested by legacy API on error path
From: Lee Jones @ 2016-01-11  9:39 UTC (permalink / raw)
  To: Vladimir Zapolskiy; +Cc: Jingoo Han, Thierry Reding, linux-pwm, linux-fbdev
In-Reply-To: <568A8DCA.6010301@mentor.com>

On Mon, 04 Jan 2016, Vladimir Zapolskiy wrote:
> On 22.09.2015 02:23, Lee Jones wrote:
> > On Sun, 14 Jun 2015, Vladimir Zapolskiy wrote:
> > 
> >> If pwm is requested by legacy pwm_request() and if the following
> >> backlight_device_register() call fails, add pwm_free() clean-up.
> >>
> >> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> >> ---
> >>  drivers/video/backlight/pwm_bl.c | 2 ++
> >>  1 file changed, 2 insertions(+)
> > 
> > Applied, thanks.
> > 
> 
> I've just encountered that this change is not present in v4.4-rc, also it is
> not in yours for-backlight-next branch, could you please double check the
> status of the change?

Looks like this slipped though the gaps.

Reapplied, thanks.

> >> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> >> index 9991cdb..a691247 100644
> >> --- a/drivers/video/backlight/pwm_bl.c
> >> +++ b/drivers/video/backlight/pwm_bl.c
> >> @@ -307,6 +307,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> >>  	if (IS_ERR(bl)) {
> >>  		dev_err(&pdev->dev, "failed to register backlight\n");
> >>  		ret = PTR_ERR(bl);
> >> +		if (pb->legacy)
> >> +			pwm_free(pb->pwm);
> >>  		goto err_alloc;
> >>  	}
> >>  
> > 
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* Re: [PATCH] backlight: adp8860: fix another uninitialized variable use
From: Lee Jones @ 2016-01-11  7:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <3284846.T0rzz6n1As@wuerfel>

On Mon, 30 Nov 2015, Arnd Bergmann wrote:

> A recent patch I did fixed two potential uses of uninitialized
> variables in the adp8870 and adp8860 drivers. Unfortunately,
> I missed another one:
> 
> drivers/video/backlight/adp8860_bl.c: In function 'adp8860_bl_ambient_light_level_show':
> drivers/video/backlight/adp8860_bl.c:570:11: warning: 'reg_val' may be used uninitialized in this function
> 
> This does the same change as before in one additional function,
> and also changes the check for the return value in a way that
> avoids another false positive warning with a similar message.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 6be3a5a9cd91 ("backlight: adp88x0: Fix uninitialized variable use")
> ---
> Sorry for missing this third hunk the first time around.

Where's your diff?

Applied anyway, thanks.

> diff --git a/drivers/video/backlight/adp8860_bl.c b/drivers/video/backlight/adp8860_bl.c
> index f0d4c0324580..510e559c060e 100644
> --- a/drivers/video/backlight/adp8860_bl.c
> +++ b/drivers/video/backlight/adp8860_bl.c
> @@ -566,11 +566,13 @@ static ssize_t adp8860_bl_ambient_light_level_show(struct device *dev,
>  
>  	mutex_lock(&data->lock);
>  	error = adp8860_read(data->client, ADP8860_PH1LEVL, &reg_val);
> -	ret_val = reg_val;
> -	error |= adp8860_read(data->client, ADP8860_PH1LEVH, &reg_val);
> +	if (!error) {
> +		ret_val = reg_val;
> +		error = adp8860_read(data->client, ADP8860_PH1LEVH, &reg_val);
> +	}
>  	mutex_unlock(&data->lock);
>  
> -	if (error < 0)
> +	if (error)
>  		return error;
>  
>  	/* Return 13-bit conversion value for the first light sensor */
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* Re: imxfb does not turn on automatically
From: Sascha Hauer @ 2016-01-11  7:16 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAD7j7Q8gANUxM5zGmn3YyhUr9yZv02x4oxi_WWLnxCYemBRYZA@mail.gmail.com>

Hi Carlos,

On Fri, Jan 08, 2016 at 09:18:41PM +0100, Carlos Soto wrote:
> 2015-02-21 16:18 GMT+01:00 Fabio Estevam <festevam@gmail.com>:
> >
> > Hi,
> >
> > Carlos Soto uses a Karo mx25 and he noticed that the LCD only works if we do:
> >
> > echo 1 > /sys/class/graphics/fb0/blank
> > echo 0 > /sys/class/graphics/fb0/blank
> >
> > I can confirm the same on mx25pdk running 3.19 [1], but I could not
> > understand why the display does not start turned on by default.
> >
> > [1] http://www.spinics.net/lists/arm-kernel/msg399949.html
> >
> > Any ideas?
> >
> > Thanks,
> >
> > Fabio Estevam
> 
> 
> 
> Hi,
> I know it's been a long time since Fabio posted the issue but recently
> I had some time to work on it again, and I've narrowed it down a
> little.
> 
> The problem seems to be related to the IPG clock used by the iMX25
> framebuffer. All clocks used by the fb are enabled in
> imxfb_enable_controller(...)
> 
> ...
> clk_prepare_enable(fbi->clk_ipg);
> clk_prepare_enable(fbi->clk_ahb);
> clk_prepare_enable(fbi->clk_per);
> fbi->enabled = true;
> 
> ...
> 
> 
> But if the IPG clock is disabled and enabled right after, the LCD
> works fine.
> 
> The changes made in imxfb.c were:
> ...
> 
> clk_prepare_enable(fbi->clk_ipg);
> clk_disable_unprepare(fbi->clk_ipg);
> clk_prepare_enable(fbi->clk_ipg);
> 
> clk_prepare_enable(fbi->clk_ahb);
> clk_prepare_enable(fbi->clk_per);
> fbi->enabled = true;
> 
> ...
> 
> It was suggested by Fabio that this could be caused by a wrong clock
> reference count which prevented the IPG fb clock to be enabled, but
> I've checked in debugfs, and both enable_cnt  and prepare_cnt seem OK
> for all three FB clocks.

Unfortunately this LCD controller does not have an enable bit. The
controller starts directly when the clocks are enabled. If the clocks
are enabled when the controller is not yet programmed with proper
register values then it just goes into some undefined state. What I
suspect is that the clocks already were enabled before driver probe,
presumably by the bootloader, so the controller is already in undefined
state when entering Linux. Now by dis/enabling the ipg clock you
effectively reset the controller. Since you have programmed it with
valid register values in the mean time it starts working after this
reset.
To verify you could try to disable the LCDC related clock gates with
direct register writes in drivers/clk/imx/clk-imx25.c.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply

* Re: [PATCH] backlight: gpio-backlight: use default-on on GPIO request
From: Lee Jones @ 2016-01-11  6:40 UTC (permalink / raw)
  To: Stefan Agner; +Cc: jingoohan1, linux-fbdev, linux-kernel
In-Reply-To: <1445643883-30726-1-git-send-email-stefan@agner.ch>

On Fri, 23 Oct 2015, Stefan Agner wrote:

> There are situations where the backlight should be on at boot time
> (e.g. if the boot loader already turned the display on). The DT
> bindings specify the "default-on" property for that purpose.
> Currently, the initial state of the GPIO at request time is always
> set to logical off (high or low depending on whether it is an
> active high or low GPIO). Since the GPIO is requested as an output,
> the GPIO will be driven low for a short period of time, which leads
> to a flickering display in the above use-case.
> 
> Initialize the GPIO depending on the default-on property to be
> logical on or off.
> 
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
>  drivers/video/backlight/gpio_backlight.c | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)

Applied, thanks.

> diff --git a/drivers/video/backlight/gpio_backlight.c b/drivers/video/backlight/gpio_backlight.c
> index 5fbbc2e..1813441 100644
> --- a/drivers/video/backlight/gpio_backlight.c
> +++ b/drivers/video/backlight/gpio_backlight.c
> @@ -89,6 +89,7 @@ static int gpio_backlight_probe(struct platform_device *pdev)
>  	struct backlight_device *bl;
>  	struct gpio_backlight *gbl;
>  	struct device_node *np = pdev->dev.of_node;
> +	unsigned long flags = GPIOF_DIR_OUT;
>  	int ret;
>  
>  	if (!pdata && !np) {
> @@ -114,9 +115,12 @@ static int gpio_backlight_probe(struct platform_device *pdev)
>  		gbl->def_value = pdata->def_value;
>  	}
>  
> -	ret = devm_gpio_request_one(gbl->dev, gbl->gpio, GPIOF_DIR_OUT |
> -				    (gbl->active ? GPIOF_INIT_LOW
> -						 : GPIOF_INIT_HIGH),
> +	if (gbl->active)
> +		flags |= gbl->def_value ? GPIOF_INIT_HIGH : GPIOF_INIT_LOW;
> +	else
> +		flags |= gbl->def_value ? GPIOF_INIT_LOW : GPIOF_INIT_HIGH;
> +
> +	ret = devm_gpio_request_one(gbl->dev, gbl->gpio, flags,
>  				    pdata ? pdata->name : "backlight");
>  	if (ret < 0) {
>  		dev_err(&pdev->dev, "unable to request GPIO\n");

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* Re: [PATCH v2] backlight: tps65217_bl: Add MODULE_DEVICE_TABLE.
From: Lee Jones @ 2016-01-11  6:08 UTC (permalink / raw)
  To: Enric Balletbo i Serra
  Cc: devicetree, jingoohan1, plagnioj, tomi.valkeinen, linux-fbdev,
	linux-kernel
In-Reply-To: <1448814586-17117-1-git-send-email-enric.balletbo@collabora.com>

On Sun, 29 Nov 2015, Enric Balletbo i Serra wrote:

> The device table is required to load modules based on modaliases.
> 
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
> Changes since last version:
> - Use of_match_ptr (Lee Jones)
> 
>  drivers/video/backlight/tps65217_bl.c | 9 +++++++++
>  1 file changed, 9 insertions(+)

Applied, thanks.

> diff --git a/drivers/video/backlight/tps65217_bl.c b/drivers/video/backlight/tps65217_bl.c
> index 61d72bf..fd524ad 100644
> --- a/drivers/video/backlight/tps65217_bl.c
> +++ b/drivers/video/backlight/tps65217_bl.c
> @@ -320,10 +320,19 @@ static int tps65217_bl_probe(struct platform_device *pdev)
>  	return 0;
>  }
>  
> +#ifdef CONFIG_OF
> +static const struct of_device_id tps65217_bl_of_match[] = {
> +	{ .compatible = "ti,tps65217-bl", },
> +	{ /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, tps65217_bl_of_match);
> +#endif
> +
>  static struct platform_driver tps65217_bl_driver = {
>  	.probe		= tps65217_bl_probe,
>  	.driver		= {
>  		.name	= "tps65217-bl",
> +		.of_match_table = of_match_ptr(tps65217_bl_of_match),
>  	},
>  };
>  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* Re: [PATCH] video: fbdev: pxafb: fix out of memory error path
From: Robert Jarzmik @ 2016-01-10 20:27 UTC (permalink / raw)
  To: Tomi Valkeinen, Jean-Christophe Plagniol-Villard
  Cc: linux-fbdev, linux-kernel, Julia Lawall
In-Reply-To: <1450527271-21841-1-git-send-email-robert.jarzmik@free.fr>

Robert Jarzmik <robert.jarzmik@free.fr> writes:

> As seen by Julia, the initial allocation memory is not checked anymore
> after commit "video: fbdev: pxafb: initial devicetree conversion".
> Introduce back the removed test.
>
> Reported-by: Julia Lawall <julia.lawall@lip6.fr>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
>  drivers/video/fbdev/pxafb.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
> index 8588dd683105..54666424a720 100644
> --- a/drivers/video/fbdev/pxafb.c
> +++ b/drivers/video/fbdev/pxafb.c
> @@ -2252,6 +2252,8 @@ static int pxafb_probe(struct platform_device *dev)
>  	ret = -ENOMEM;
>  	pdata = dev_get_platdata(&dev->dev);
>  	inf = devm_kmalloc(&dev->dev, sizeof(*inf), GFP_KERNEL);
> +	if (!inf)
> +		goto failed;
>  
>  	if (pdata) {
>  		*inf = *pdata;
Tomi, Jean-Christophe,

Can you carry out this fix please ?

Cheers.

-- 
Robert

^ permalink raw reply

* Re: imxfb does not turn on automatically
From: Carlos Soto @ 2016-01-08 20:18 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAOMZO5CZ3aFGbfb39XoXpFvbn4TTrCbTHOXtQKruruCis3Ptvw@mail.gmail.com>

2015-02-21 16:18 GMT+01:00 Fabio Estevam <festevam@gmail.com>:
>
> Hi,
>
> Carlos Soto uses a Karo mx25 and he noticed that the LCD only works if we do:
>
> echo 1 > /sys/class/graphics/fb0/blank
> echo 0 > /sys/class/graphics/fb0/blank
>
> I can confirm the same on mx25pdk running 3.19 [1], but I could not
> understand why the display does not start turned on by default.
>
> [1] http://www.spinics.net/lists/arm-kernel/msg399949.html
>
> Any ideas?
>
> Thanks,
>
> Fabio Estevam



Hi,
I know it's been a long time since Fabio posted the issue but recently
I had some time to work on it again, and I've narrowed it down a
little.

The problem seems to be related to the IPG clock used by the iMX25
framebuffer. All clocks used by the fb are enabled in
imxfb_enable_controller(...)

...
clk_prepare_enable(fbi->clk_ipg);
clk_prepare_enable(fbi->clk_ahb);
clk_prepare_enable(fbi->clk_per);
fbi->enabled = true;

...


But if the IPG clock is disabled and enabled right after, the LCD
works fine.

The changes made in imxfb.c were:
...

clk_prepare_enable(fbi->clk_ipg);
clk_disable_unprepare(fbi->clk_ipg);
clk_prepare_enable(fbi->clk_ipg);

clk_prepare_enable(fbi->clk_ahb);
clk_prepare_enable(fbi->clk_per);
fbi->enabled = true;

...

It was suggested by Fabio that this could be caused by a wrong clock
reference count which prevented the IPG fb clock to be enabled, but
I've checked in debugfs, and both enable_cnt  and prepare_cnt seem OK
for all three FB clocks.

So, I'm really stuck here. Any hints would be greatly appreciated.

Thanks,
Carlos Soto

2015-02-21 16:18 GMT+01:00 Fabio Estevam <festevam@gmail.com>:
> Hi,
>
> Carlos Soto uses a Karo mx25 and he noticed that the LCD only works if we do:
>
> echo 1 > /sys/class/graphics/fb0/blank
> echo 0 > /sys/class/graphics/fb0/blank
>
> I can confirm the same on mx25pdk running 3.19 [1], but I could not
> understand why the display does not start turned on by default.
>
> [1] http://www.spinics.net/lists/arm-kernel/msg399949.html
>
> Any ideas?
>
> Thanks,
>
> Fabio Estevam

^ permalink raw reply

* Re: [PATCH] backlight: pwm: free pwm requested by legacy API on error path
From: Vladimir Zapolskiy @ 2016-01-04 15:20 UTC (permalink / raw)
  To: Lee Jones; +Cc: Jingoo Han, Thierry Reding, linux-pwm, linux-fbdev
In-Reply-To: <20150921232338.GG11284@x1>

Hi Lee,

On 22.09.2015 02:23, Lee Jones wrote:
> On Sun, 14 Jun 2015, Vladimir Zapolskiy wrote:
> 
>> If pwm is requested by legacy pwm_request() and if the following
>> backlight_device_register() call fails, add pwm_free() clean-up.
>>
>> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
>> ---
>>  drivers/video/backlight/pwm_bl.c | 2 ++
>>  1 file changed, 2 insertions(+)
> 
> Applied, thanks.
> 

I've just encountered that this change is not present in v4.4-rc, also it is
not in yours for-backlight-next branch, could you please double check the
status of the change?

Thank you in advance.

Best wishes,
Vladimir

>> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
>> index 9991cdb..a691247 100644
>> --- a/drivers/video/backlight/pwm_bl.c
>> +++ b/drivers/video/backlight/pwm_bl.c
>> @@ -307,6 +307,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
>>  	if (IS_ERR(bl)) {
>>  		dev_err(&pdev->dev, "failed to register backlight\n");
>>  		ret = PTR_ERR(bl);
>> +		if (pb->legacy)
>> +			pwm_free(pb->pwm);
>>  		goto err_alloc;
>>  	}
>>  
> 


^ permalink raw reply

* re: omapfb: copy omapdss & displays for omapfb
From: Dan Carpenter @ 2016-01-04 13:27 UTC (permalink / raw)
  To: linux-fbdev
In-Reply-To: <20160104132534.GA24840@mwanda>

Hello Tomi Valkeinen,

The patch f76ee892a99e: "omapfb: copy omapdss & displays for omapfb"
from Dec 9, 2015, leads to the following static checker warning:

	drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c:213 sharp_ls_get_gpio()
	warn: 'gd' isn't an ERR_PTR

drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c
   200  static int sharp_ls_get_gpio(struct device *dev, int gpio, unsigned long flags,
   201                    char *desc, struct gpio_desc **gpiod)
   202  {
   203          struct gpio_desc *gd;
   204          int r;
   205  
   206          *gpiod = NULL;
   207  
   208          r = devm_gpio_request_one(dev, gpio, flags, desc);
   209          if (r)
   210                  return r = -ENOENT ? 0 : r;
   211  
   212          gd = gpio_to_desc(gpio);
   213          if (IS_ERR(gd))
   214                  return PTR_ERR(gd) = -ENOENT ? 0 : PTR_ERR(gd);

This doesn't work.  It's either compiled out (ENOENT) or NULL.

   215  
   216          *gpiod = gd;
   217          return 0;
   218  }

regards,
dan carpenter

^ permalink raw reply

* re: omapfb: copy omapdss & displays for omapfb
From: Dan Carpenter @ 2016-01-04 13:25 UTC (permalink / raw)
  To: linux-fbdev

Hello Tomi Valkeinen,

This is a semi-automatic email about new static checker warnings.

The patch f76ee892a99e: "omapfb: copy omapdss & displays for omapfb" 
from Dec 9, 2015, leads to the following Smatch complaint:

drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c:113 sharp_ls_enable()
	 error: we previously assumed 'ddata->vcc' could be null (see line 105)

drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c
   104	
   105		if (ddata->vcc) {
                    ^^^^^^^^^^
Check for NULL.

   106			r = regulator_enable(ddata->vcc);
   107			if (r != 0)
   108				return r;
   109		}
   110	
   111		r = in->ops.dpi->enable(in);
   112		if (r) {
   113			regulator_disable(ddata->vcc);
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Unchecked deref inside function.

   114			return r;
   115		}

regards,
dan carpenter

^ permalink raw reply

* Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
From: Daniel Vetter @ 2016-01-04  7:08 UTC (permalink / raw)
  To: Tomi Valkeinen
  Cc: Sebastian Frias, linux-fbdev, Måns Rullgård, mason,
	LKML, dri-devel, laurent.pinchart, Frans Klaver,
	Jean-Christophe Plagniol-Villard
In-Reply-To: <5683B2A0.9090901@ti.com>

On Wed, Dec 30, 2015 at 12:32:00PM +0200, Tomi Valkeinen wrote:
> 
> 
> On 30/12/15 11:31, Sebastian Frias wrote:
> > Hi,
> > 
> > On 12/30/2015 09:06 AM, Tomi Valkeinen wrote:
> >>
> >> Also note that I don't want new fbdev drivers into the mainline kernel.
> >> You should implement a DRM based driver instead.
> >>
> > 
> > Thanks, is there a porting guide to go from fbdev to DRM?
> 
> I don't think you should "port" the driver from fbdev to DRM, as the
> frameworks are just so different. You should implement the driver from
> scratch. Of course, the bits of code that actually touch the hardware
> can possibly be copied directly.
> 
> Kernel docs contain documentation about DRM, but I don't know if there's
> really a "how to write a DRM driver" style documentation. There's an
> active mailing list and irc channel, though.

Laurent Pinchart has a presentation which gives a good overview over drm
for display drivers:

https://www.youtube.com/watch?v=5uHMpjz68HE

DRM docs are at http://dri.freedesktop.org/docs/drm/ (this version is
using asciidoc for more pretties, but you can also build it locally with
make htmldocs and then look at it in
Documentation/DocBook/drm/index.html).

> > Does DRM provides a "fbdev" backward compatible API? Would that be
> > feasible?
> 
> DRM provides an fbdev "emulation". I think it's mainly aimed at
> providing fb console, but many fbdev applications should work fine on
> top of it.

Modeset side should be full featured out of the box (i.e. you can change
modes), drivers have the option to overallocate (to allow the fake page
flipping using set_par) and adding 2d accel is possible.

> > I did not find much about that.
> > 
> > Currently our stack is something like:
> > 
> >    Qt -> eglfs -> Mali -> fbdev -> mem -> output
> >                   (HW)                     (HW)
> > 
> > We don't control the eglfs/Mali (GPU) part.
> > From what I could see, Mali uses DRM with X11 which we do not need
> > (note: I'm not a Mali expert and just took a quick look at the code so I
> > may be wrong), which could be a problem.
> 
> I'm not familiar with Mali, so I have no idea.
> 
> > If "implement a DRM driver" is a lot of work, it would end up as a
> > business decision and probably would not happen.
> 
> True. It's, of course, up to you. If the fbdev driver works fine for you
> and provides all the features, and you're happy with it, and there's no
> requirement to get the driver to the mainline Linux, there's not much
> point in going for a DRM driver.
> 
> > Would you say there are good solid arguments to shake our current stack
> > (other than for dusting it off)?
> 
> Fbdev is the legacy framework, hopefully deprecated at some point, and
> DRM is the current display framework. So DRM has much more features, is
> actively developed, has a community that may help you with your issues, etc.
> 
> From purely technical point of view, it depends on the hardware in
> question. If the HW supports hardware overlays and multiple outputs, DRM
> supports those fully, whereas fbdev does not.
> 
> I'm not that familiar with the 3D side, but I think that can be
> implemented properly with DRM, whereas on fbdev supporting 3D is always
> more or less a hack.
> 
> > By the way, does DRM improves 2D acceleration support over fbdev?
> 
> I don't know enough about 2D acceleration to answer that.

We've tried in-kernel accel of 2d fbdev ops in i915 and realized it's too
much work and pretty pointless. But it's definitely possible to do that,
on top of the provided fbdev emulation (e.g. gma500 has some scrolling
accel tricks). Otherwise same as 3D really, using the split
kernel/userspace driver approach.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

^ permalink raw reply

* Charity Donation
From: Jeff Skoll @ 2016-01-03 10:31 UTC (permalink / raw)
  To: linux-fbdev
In-Reply-To: <auto-000000701762@mailadmin.uni-kassel.de>

Hi,
My name is Jeffrey Skoll, a philanthropist and the founder of one of the largest private foundations in the world. I believe strongly in ‘giving while living.’ I had one idea that never changed in my mind — that you should use your wealth to help people and I have decided to secretly give USD2.498 Million to a randomly selected individual. On receipt of this email, you should count yourself as the individual. Kindly get back to me at your earliest convenience, so I know your email address is valid.

Visit the web page to know more about me: http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/ or you can read an article of me on Wikipedia.

Regards,
Jeffrey Skoll.

^ permalink raw reply

* Charity Donation
From: Jeff Skoll @ 2016-01-03  9:34 UTC (permalink / raw)
  To: linux-fbdev

Hi,
My name is Jeffrey Skoll, a philanthropist and the founder of one of the largest private foundations in the world. I believe strongly in ‘giving while living.’ I had one idea that never changed in my mind — that you should use your wealth to help people and I have decided to secretly give USD2.498 Million to a randomly selected individual. On receipt of this email, you should count yourself as the individual. Kindly get back to me at your earliest convenience, so I know your email address is valid.

Visit the web page to know more about me: http://www.theglobeandmail.com/news/national/meet-the-canadian-billionaire-whos-giving-it-all-away/article4209888/ or you can read an article of me on Wikipedia.

Regards,
Jeffrey Skoll.

^ permalink raw reply

* Re: [PATCH 1/1] video: ARM CLCD: Add the framebuffer parameters setting in probe
From: Russell King - ARM Linux @ 2016-01-02 12:39 UTC (permalink / raw)
  To: Rongjun Ying
  Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
	linux-kernel
In-Reply-To: <1451435928-22903-1-git-send-email-rjying@aliyun.com>

On Wed, Dec 30, 2015 at 08:38:48AM +0800, Rongjun Ying wrote:
> This patch fixes the user space applications can't get the framebuffer
> parameters, if disable the fb console feature.
> 
> Signed-off-by: Rongjun Ying <rjying@aliyun.com>

I think this behaviour is intentional: userspace is expected to
set the initial mode for non-console frame buffers by using
FBIOPUT_VSCREENINFO.

Otherwise, register_fb() would always set an initial mode on all
framebuffers.

I remember this being discussed years ago (more than a decade)
when the FB layer was relatively new.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply

* Re: [PATCH v2] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks
From: Ivaylo Dimitrov @ 2016-01-01 12:25 UTC (permalink / raw)
  To: Tomi Valkeinen
  Cc: plagnioj, pali.rohar, pavel, linux-omap, linux-fbdev,
	linux-kernel, Ivaylo Dimitrov, Aaro Koskinen
In-Reply-To: <56823A49.7080508@ti.com>



On 29.12.2015 09:46, Tomi Valkeinen wrote:
>
> Oh, I'm sorry, I must have forgotten about that. Please, send a new patch.
>
>   Tomi
>

Actually it is me to be sorry for making noise, I've missed 
0eb0dafb674cd6bfac2e3204b2f8b907e26b1138 with all those patches moving 
files around.

Ivo

^ permalink raw reply

* Re: [PATCH v4 14/24] clk: pwm: use pwm_get/set_default_xxx() helpers where appropriate
From: Michael Turquette @ 2015-12-30 21:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1447664207-24370-15-git-send-email-boris.brezillon@free-electrons.com>

Hi Boris,

Quoting Boris Brezillon (2015-11-16 00:56:37)
> pwm_set/get_default_xxx() helpers have been introduced to differentiate
> the default PWM states (those retrieved through DT, PWM lookup table or
> statically assigned by the driver) and the current ones.
> Make use of those helpers where appropriate.
> 
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
>  drivers/clk/clk-pwm.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
> index b6306a2..642a49a 100644
> --- a/drivers/clk/clk-pwm.c
> +++ b/drivers/clk/clk-pwm.c
> @@ -71,23 +71,23 @@ static int clk_pwm_probe(struct platform_device *pdev)
>         if (IS_ERR(pwm))
>                 return PTR_ERR(pwm);
>  
> -       if (!pwm_get_period((pwm))) {
> +       if (!pwm_get_default_period((pwm))) {

The change itself looks fine, but the semantic patch added extra parens.
Can you remove them? After doing so feel free to add:

Acked-by: Michael Turquette <mturquette@baylibre.com>

^ permalink raw reply

* Re: [PATCH v4 03/24] clk: pwm: use pwm_get_xxx() helpers where appropriate
From: Michael Turquette @ 2015-12-30 21:03 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1447664207-24370-4-git-send-email-boris.brezillon@free-electrons.com>

Hi Boris,

Quoting Boris Brezillon (2015-11-16 00:56:26)
> diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
> index 328fcfc..b6306a2 100644
> --- a/drivers/clk/clk-pwm.c
> +++ b/drivers/clk/clk-pwm.c
> @@ -71,22 +71,23 @@ static int clk_pwm_probe(struct platform_device *pdev)
>         if (IS_ERR(pwm))
>                 return PTR_ERR(pwm);
>  
> -       if (!pwm->period) {
> +       if (!pwm_get_period((pwm))) {

The change itself looks fine, but the semantic patch added extra parens.
Can you remove them? After doing so feel free to add:

Acked-by: Michael Turquette <mturquette@baylibre.com>

^ permalink raw reply

* Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
From: Carlos Palminha @ 2015-12-30 18:53 UTC (permalink / raw)
  To: laurent.pinchart, dri-devel, linux-fbdev; +Cc: tomi.valkeinen, CARLOS.PALMINHA
In-Reply-To: <5684268E.2000607@synopsys.com>

Hi guys,

I'm writing a DRM driver for a framebuffer embedded hardware that uses 
an i2c encoder (adv7511), following the basic steps suggested by Laurent 
in "anatomy of an embedded KMS driver": 
https://www.youtube.com/watch?v=Ja8fM7rTae4

After initiliazing all kms, crtc, encoder, i2c, connector functions and 
structures i'm calling drm_fbdev_cma_init to create a fbdev.

When booting i'm getting an error message saying "No connectors reported 
connected with modes", but the driver init is ok and i can find the 
/dev/dri/* and /dev/fb0 devices.

Any clue what i might be missing during the driver load?

Thanks...

Regards,
C.Palminha

--- boot log snippet ---
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes
[drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48
drm-arcpgu e0017000.pgu: fb0:  frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0
--- boot log snippet ---

^ permalink raw reply

* Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
From: Carlos Palminha @ 2015-12-30 18:46 UTC (permalink / raw)
  To: linux-fbdev

Hi guys,

I'm writing a DRM driver for a framebuffer embedded hardware that uses 
an i2c encoder (adv7511), following the basic steps suggested by Laurent 
in "anatomy of an embedded KMS driver": 
https://www.youtube.com/watch?v=Ja8fM7rTae4

After initiliazing all kms, crtc, encoder, i2c, connector functions and 
structures i'm calling drm_fbdev_cma_init to create a fbdev.

When booting i'm getting an error message saying "No connectors reported 
connected with modes", but the driver init is ok and i can find the 
/dev/dri/* and /dev/fb0 devices.

Any clue what i might be missing during the driver load?

Thanks...

Regards,
C.Palminha

--- boot log snippet ---
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes
[drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48
drm-arcpgu e0017000.pgu: fb0:  frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0
--- boot log snippet ---

^ permalink raw reply

* Re: [PATCH v2 1/3] devicetree/bindings: add reset-gpios and vcc-supply for panel-dpi
From: Rob Herring @ 2015-12-30 14:44 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Uwe Kleine-König, Tomi Valkeinen,
	Jean-Christophe Plagniol-Villard, Linux Fbdev development list,
	linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Sascha Hauer,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdUJPUeyhtM3=S4dOgevpnyd0TgkJy7QchPewO4KOxsWvA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Wed, Dec 30, 2015 at 4:29 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Tue, Dec 29, 2015 at 9:54 PM, Rob Herring <robh@kernel.org> wrote:
>> On Sun, Dec 20, 2015 at 12:13:20PM +0100, Uwe Kleine-König wrote:
>>> Some displays have a reset input and/or need a regulator to function
>>> properly. Allow to specify them for panel-dpi devices.
>>>
>>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>>> ---
>>>  Documentation/devicetree/bindings/display/panel/panel-dpi.txt | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>>> index 216c894d4f99..b52ac52757df 100644
>>> --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>>> +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>>> @@ -7,6 +7,8 @@ Required properties:
>>>  Optional properties:
>>>  - label: a symbolic name for the panel
>>>  - enable-gpios: panel enable gpio
>>> +- reset-gpios: GPIO to control the RESET pin
>>
>> The problem with this in a generic binding is what if the panel has
>> ordering requirements like enable gpio has to be inactive when reset
>> is deasserted?
>>
>>> +- vcc-supply: phandle of regulator that will be used to enable power to the display
>>
>> What if there are 2 supplies?
>
> So it should be "vcc-supplies". Most properties containing phandles use plural
> naming, even if Linux supports a single phandle only (e.g. "power-domains").
> You also may want to add an optional "vcc-supply-names" property to
> differentiate.

True, but the regulator binding is an exception and we don't do that
with it. The prefix is the name and other supplies are not going to be
called Vcc.

Rob

^ permalink raw reply

page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox