Linux Framebuffer Layer development
 help / color / mirror / Atom feed
* [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111
From: tom.cooksey @ 2013-07-25 17:17 UTC (permalink / raw)
  To: dri-devel; +Cc: linux-fbdev, pawel.moll, linux-arm-kernel, Tom Cooksey

From: Tom Cooksey <tom.cooksey@arm.com>

Please find below the current state of our pl111 DRM/KMS driver. This
is lightly tested on a Versatile Express using X running the
xf86-video-armsoc DDX driver[i] with the patches applied to drm-next
as of ~last week. To actually see anything on the DVI output, you
must also apply Pawel Moll's VExpress DVI mux driver[ii] to select
the video signal from the ca9x4 core tile.

[i] <https://git.linaro.org/gitweb?p=arm/xorg/driver/xf86-video-armsoc.git;a=summary>
[ii] <https://patchwork.kernel.org/patch/1765981/>


Known issues:
 * It uses KDS. We intend to switch to whatever implicit per-buffer
   synchronisation mechanism gets merged, once something is merged.
 * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
   allocate buffers for the GPU. Still not sure how to resolve this
   as we don't use DRM for our GPU driver.
 * Doesn't handle page flip event sequence numbers and timestamps
 * The v_sync handling needs work in general - a work queue is a
   little overkill
 * Doesn't support the import half of PRIME properly, only export
 * Need to validate src rectangle size in
   pl111_drm_cursor_plane_update()
 * Only supports 640x480 mode, which is hard-coded. We intend to
   rebase on top of CDF once it is merged, which hopefully will
   handle a lot of the EDID parsing & mode setting for us (once
   Pawel's CDF patches for VExpress also land).

I appreciate that's a fairly hefty list of known issues already!
However, we're waiting for both CDF & dma_buf sync mechanisms to land
before we can address some of those. So in the mean-time, I thought
someone might be interested in taking a look at what we have so far,
which is why I'm posting this now. Needless to say the code will need
to be refactored a fair bit, however I'm keen to get and additional
feedback anyone cares to give.


Cheers,

Tom

Tom Cooksey (1):
  drm/pl111: Initial drm/kms driver for pl111 display controller

 drivers/gpu/drm/Kconfig                     |    2 +
 drivers/gpu/drm/Makefile                    |    1 +
 drivers/gpu/drm/pl111/Kbuild                |   14 +
 drivers/gpu/drm/pl111/Kconfig               |    9 +
 drivers/gpu/drm/pl111/pl111_clcd_ext.h      |   78 ++++
 drivers/gpu/drm/pl111/pl111_drm.h           |  227 ++++++++++++
 drivers/gpu/drm/pl111/pl111_drm_connector.c |  166 +++++++++
 drivers/gpu/drm/pl111/pl111_drm_crtc.c      |  432 ++++++++++++++++++++++
 drivers/gpu/drm/pl111/pl111_drm_cursor.c    |   97 +++++
 drivers/gpu/drm/pl111/pl111_drm_device.c    |  319 +++++++++++++++++
 drivers/gpu/drm/pl111/pl111_drm_dma_buf.c   |  339 ++++++++++++++++++
 drivers/gpu/drm/pl111/pl111_drm_encoder.c   |  106 ++++++
 drivers/gpu/drm/pl111/pl111_drm_fb.c        |  152 ++++++++
 drivers/gpu/drm/pl111/pl111_drm_funcs.h     |  127 +++++++
 drivers/gpu/drm/pl111/pl111_drm_gem.c       |  287 +++++++++++++++
 drivers/gpu/drm/pl111/pl111_drm_pl111.c     |  513 +++++++++++++++++++++++++++
 drivers/gpu/drm/pl111/pl111_drm_platform.c  |  150 ++++++++
 drivers/gpu/drm/pl111/pl111_drm_suspend.c   |   35 ++
 drivers/gpu/drm/pl111/pl111_drm_vma.c       |  214 +++++++++++
 19 files changed, 3268 insertions(+)
 create mode 100644 drivers/gpu/drm/pl111/Kbuild
 create mode 100644 drivers/gpu/drm/pl111/Kconfig
 create mode 100644 drivers/gpu/drm/pl111/pl111_clcd_ext.h
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm.h
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_connector.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_crtc.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_cursor.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_device.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_dma_buf.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_encoder.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_fb.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_funcs.h
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_gem.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_pl111.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_platform.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_suspend.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_drm_vma.c

-- 
1.7.9.5



^ permalink raw reply

* Re: [PATCH 2/2] video: imxfb: Add feature to setup PWM Contrast Control Register
From: Alexander Shiyan @ 2013-07-25 17:20 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20130725133824.GD16871@s25.your-server.de>

On Thu, 25 Jul 2013 15:38:56 +0200
Markus Pargmann <mpa@pengutronix.de> wrote:

> Hi,
> 
> On Sun, Jul 21, 2013 at 12:35:09PM +0400, Alexander Shiyan wrote:
> > This patch adds feature to setup PWM Contrast Control Register.
> > This register is used to control the signal output at the contrast pin,
> > which controls contrast of the LCD panel.
> 
> http://www.spinics.net/lists/linux-fbdev/msg10002.html

PWM? I can not understand how the PWM driver will be connected to the
framebuffer driver. It is not backlight, this is contrast.
Even if we imagine that the driver will be connected through phandle,
then we will need to have at least 4! additional parameters in the framebuffer
driver: freq source, frequency and active pulse period + phandle to PWM.
Is it worth it, given that these parameters should not be adjustable?
On my opinion, the only one additional parameter in framebuffer is enough.
Thanks.

[...]
> > ---
> >  Documentation/devicetree/bindings/video/fsl,imx-fb.txt | 1 +
> >  drivers/video/imxfb.c                                  | 2 +-
> >  2 files changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > index 46da08d..be10c65 100644
> > --- a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
> > @@ -18,6 +18,7 @@ Optional properties:
> >  - fsl,dmacr: DMA Control Register value. This is optional. By default, the
> >  	register is not modified as recommended by the datasheet.
> >  - fsl,lscr1: LCDC Sharp Configuration Register value.
> > +- fsl,pwmr: LCDC PWM Contrast Control Register value.
> >  
> >  Example:
> >  
> > diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
> > index 8e104c4..d98299a 100644
> > --- a/drivers/video/imxfb.c
> > +++ b/drivers/video/imxfb.c
> > @@ -806,8 +806,8 @@ static int imxfb_init_fbinfo(struct platform_device *pdev,
> >  
> >  		fbi->lscr1 = IMXFB_LSCR1_DEFAULT;
> >  		of_property_read_u32(np, "fsl,lscr1", &fbi->lscr1);
> > -
> >  		of_property_read_u32(np, "fsl,dmacr", &fbi->dmacr);
> > +		of_property_read_u32(np, "fsl,pwmr", &fbi->pwmr);
> >  
> >  		/* These two function pointers could be used by some specific
> >  		 * platforms. */
> > -- 

-- 
Alexander Shiyan <shc_work@mail.ru>

^ permalink raw reply

* Re: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111
From: Rob Clark @ 2013-07-25 18:21 UTC (permalink / raw)
  To: tom.cooksey; +Cc: linux-arm-kernel, linux-fbdev, pawel.moll, dri-devel
In-Reply-To: <1374772648-19151-1-git-send-email-tom.cooksey@arm.com>

On Thu, Jul 25, 2013 at 1:17 PM,  <tom.cooksey@arm.com> wrote:
> From: Tom Cooksey <tom.cooksey@arm.com>
>
> Please find below the current state of our pl111 DRM/KMS driver. This
> is lightly tested on a Versatile Express using X running the
> xf86-video-armsoc DDX driver[i] with the patches applied to drm-next
> as of ~last week. To actually see anything on the DVI output, you
> must also apply Pawel Moll's VExpress DVI mux driver[ii] to select
> the video signal from the ca9x4 core tile.
>
> [i] <https://git.linaro.org/gitweb?p=arm/xorg/driver/xf86-video-armsoc.git;a=summary>
> [ii] <https://patchwork.kernel.org/patch/1765981/>
>
>
> Known issues:
>  * It uses KDS. We intend to switch to whatever implicit per-buffer
>    synchronisation mechanism gets merged, once something is merged.
>  * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also
>    allocate buffers for the GPU. Still not sure how to resolve this
>    as we don't use DRM for our GPU driver.

any thoughts/plans about a DRM GPU driver?  Ideally long term (esp.
once the dma-fence stuff is in place), we'd have gpu-specific drm
(gpu-only, no kms) driver, and SoC/display specific drm/kms driver,
using prime/dmabuf to share between the two.

>  * Doesn't handle page flip event sequence numbers and timestamps
>  * The v_sync handling needs work in general - a work queue is a
>    little overkill
>  * Doesn't support the import half of PRIME properly, only export
>  * Need to validate src rectangle size in
>    pl111_drm_cursor_plane_update()
>  * Only supports 640x480 mode, which is hard-coded. We intend to
>    rebase on top of CDF once it is merged, which hopefully will
>    handle a lot of the EDID parsing & mode setting for us (once
>    Pawel's CDF patches for VExpress also land).

note that drm core already handles EDID parsing quite nicely.. I'm not
entirely sure why CDF would be needed for this?

>
> I appreciate that's a fairly hefty list of known issues already!
> However, we're waiting for both CDF & dma_buf sync mechanisms to land
> before we can address some of those. So in the mean-time, I thought
> someone might be interested in taking a look at what we have so far,
> which is why I'm posting this now. Needless to say the code will need
> to be refactored a fair bit, however I'm keen to get and additional
> feedback anyone cares to give.
>

What is the dependency on CDF?  Is there an external encoder/bridge
that could be shared between platforms?

btw, I think that having some share-able KMS objects is a good idea.
I'm not entirely sure that the directions that the current CDF
proposals are headed is necessarily the right way forward.  I'd prefer
to see small/incremental evolution of KMS (ie. add drm_bridge and
drm_panel, and refactor the existing encoder-slave).  Keeping it
inside drm means that we can evolve it more easily, and avoid layers
of glue code for no good reason.

BR,
-R


>
> Cheers,
>
> Tom
>
> Tom Cooksey (1):
>   drm/pl111: Initial drm/kms driver for pl111 display controller
>
>  drivers/gpu/drm/Kconfig                     |    2 +
>  drivers/gpu/drm/Makefile                    |    1 +
>  drivers/gpu/drm/pl111/Kbuild                |   14 +
>  drivers/gpu/drm/pl111/Kconfig               |    9 +
>  drivers/gpu/drm/pl111/pl111_clcd_ext.h      |   78 ++++
>  drivers/gpu/drm/pl111/pl111_drm.h           |  227 ++++++++++++
>  drivers/gpu/drm/pl111/pl111_drm_connector.c |  166 +++++++++
>  drivers/gpu/drm/pl111/pl111_drm_crtc.c      |  432 ++++++++++++++++++++++
>  drivers/gpu/drm/pl111/pl111_drm_cursor.c    |   97 +++++
>  drivers/gpu/drm/pl111/pl111_drm_device.c    |  319 +++++++++++++++++
>  drivers/gpu/drm/pl111/pl111_drm_dma_buf.c   |  339 ++++++++++++++++++
>  drivers/gpu/drm/pl111/pl111_drm_encoder.c   |  106 ++++++
>  drivers/gpu/drm/pl111/pl111_drm_fb.c        |  152 ++++++++
>  drivers/gpu/drm/pl111/pl111_drm_funcs.h     |  127 +++++++
>  drivers/gpu/drm/pl111/pl111_drm_gem.c       |  287 +++++++++++++++
>  drivers/gpu/drm/pl111/pl111_drm_pl111.c     |  513 +++++++++++++++++++++++++++
>  drivers/gpu/drm/pl111/pl111_drm_platform.c  |  150 ++++++++
>  drivers/gpu/drm/pl111/pl111_drm_suspend.c   |   35 ++
>  drivers/gpu/drm/pl111/pl111_drm_vma.c       |  214 +++++++++++
>  19 files changed, 3268 insertions(+)
>  create mode 100644 drivers/gpu/drm/pl111/Kbuild
>  create mode 100644 drivers/gpu/drm/pl111/Kconfig
>  create mode 100644 drivers/gpu/drm/pl111/pl111_clcd_ext.h
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm.h
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_connector.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_crtc.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_cursor.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_device.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_dma_buf.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_encoder.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_fb.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_funcs.h
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_gem.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_pl111.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_platform.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_suspend.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_drm_vma.c
>
> --
> 1.7.9.5
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v3] video: xilinxfb: Fix compilation warning
From: Jingoo Han @ 2013-07-25 23:14 UTC (permalink / raw)
  To: 'Michal Simek',
	'Jean-Christophe Plagniol-Villard'
  Cc: 'Michal Simek', 'Tomi Valkeinen', linux-fbdev,
	linux-kernel, 'Geert Uytterhoeven', Jingoo Han
In-Reply-To: <b8701d73538d37495b41ef465440a6d5f3018870.1374759923.git.michal.simek@xilinx.com>

On Thursday, July 25, 2013 10:45 PM, Michal Simek wrote:
> 
> regs_phys is phys_addr_t (u32 or u64).
> Lets use %pa printk format specifier.
> 
> Fixes compilation warning introduced by:
> video: xilinxfb: Use drvdata->regs_phys instead of physaddr
> (sha1: c88fafef0135e1e1c3e23c3e32ccbeeabc587f81)
> 
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>

It looks good.

Reviewed-by: Jingoo Han <jg1.han@samsung.com>

Best regards,
Jingoo Han

> ---
> Changes in v3:
> - Fix commit message reported by Geert
> 
> Changes in v2:
> - Use %pa instead of casting
> 
> ppc44x_defconfig
> Fixes regressions in v3.11-rc2
> 
> ---
>  drivers/video/xilinxfb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
> index f3d4a69..6629b29 100644
> --- a/drivers/video/xilinxfb.c
> +++ b/drivers/video/xilinxfb.c
> @@ -341,8 +341,8 @@ static int xilinxfb_assign(struct platform_device *pdev,
> 
>  	if (drvdata->flags & BUS_ACCESS_FLAG) {
>  		/* Put a banner in the log (for DEBUG) */
> -		dev_dbg(dev, "regs: phys=%x, virt=%p\n", drvdata->regs_phys,
> -					drvdata->regs);
> +		dev_dbg(dev, "regs: phys=%pa, virt=%p\n",
> +			&drvdata->regs_phys, drvdata->regs);
>  	}
>  	/* Put a banner in the log (for DEBUG) */
>  	dev_dbg(dev, "fb: phys=%llx, virt=%p, size=%x\n",
> --
> 1.8.2.3
>


^ permalink raw reply

* Re: [PATCHv2 2/3] video: hx8357: Make IM pins optional
From: Jingoo Han @ 2013-07-25 23:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1374757513-2253-3-git-send-email-maxime.ripard@free-electrons.com>

On Thursday, July 25, 2013 10:05 PM, Maxime Ripard wrote:
> 
> The IM pins of the HX8357 controller are used to define the interface
> used to feed pixel stream to the LCD panel.
> 
> Most of the time, these pins are directly routed to either the ground or
> the VCC to set their values.
> 
> Remove the need to assign GPIOs to these pins when we are in such a case.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  drivers/video/backlight/hx8357.c | 53 +++++++++++++++++++++++-----------------
>  1 file changed, 31 insertions(+), 22 deletions(-)
> 

[.....]

> +	if (of_find_property(spi->dev.of_node, "im-gpios", NULL)) {
> +		lcd->use_im_pins = 1;
> +
> +		for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
> +			lcd->im_pins[i] = of_get_named_gpio(spi->dev.of_node,
> +							    "im-gpios", i);
> +			if (lcd->im_pins[i] = -EPROBE_DEFER) {
> +				dev_info(&spi->dev, "GPIO requested is not here yet, deferring the
> probe\n");
> +				return -EPROBE_DEFER;
> +			}
> +			if (!gpio_is_valid(lcd->im_pins[i])) {
> +				dev_err(&spi->dev, "Missing dt property: im-gpios\n");
> +				return -EINVAL;
> +			}
> +
> +			ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
> +						    GPIOF_OUT_INIT_LOW,
> +						    "im_pins");
> +			if (ret) {
> +				dev_err(&spi->dev, "failed to request gpio %d: %d\n",
> +					lcd->im_pins[i], ret);
> +				return -EINVAL;
> +			}
>  		}
> -
> -		ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
> -					GPIOF_OUT_INIT_LOW, "im_pins");
> -		if (ret) {
> -			dev_err(&spi->dev, "failed to request gpio %d: %d\n",
> -				lcd->im_pins[i], ret);
> -			return -EINVAL;
> -		}
> -	}
> +	} else
> +		lcd->use_im_pins = 0;

According to the 'Documentation/CodingStyle', braces are necessary as below.

	} else {
		lcd->use_im_pins = 0;
	}

Others look good.
Acked-by: Jingoo Han <jg1.han@samsung.com>

Best regards,
Jingoo Han



^ permalink raw reply

* Re: [PATCHv2 3/3] fb: backlight: HX8357: Add HX8369 support
From: Jingoo Han @ 2013-07-25 23:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1374757513-2253-4-git-send-email-maxime.ripard@free-electrons.com>

On Thursday, July 25, 2013 10:05 PM, Maxime Ripard wrote:
> 
> From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> 
> Add support for the Himax HX8369 controller as it is quite similar to the
> hx8357.
> 
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Acked-by: Jingoo Han <jg1.han@samsung.com>
> ---
>  drivers/video/backlight/hx8357.c | 221 ++++++++++++++++++++++++++++++++++++---
>  1 file changed, 206 insertions(+), 15 deletions(-)
> 

[....]

> +	ret = hx8357_spi_write_byte(lcdev, HX8357_SET_DISPLAY_ON);
> +	if (ret < 0)
> +		return ret;
> +
> +	msleep(100);

Hi Maxime Ripard,

Could you add comment on this huge delay, too?

Best regards,
Jingoo Han



^ permalink raw reply

* Re: [PATCH] vga16fb: Remove unused variable
From: Tomi Valkeinen @ 2013-07-26  7:30 UTC (permalink / raw)
  To: Luis Henriques
  Cc: linux-fbdev, Jean-Christophe Plagniol-Villard, linux-kernel
In-Reply-To: <20130710225659.GA14107@hercules>

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

On 11/07/13 01:57, Luis Henriques wrote:
> Fix build warning of unused variable:
> 
> drivers/video/vga16fb.c:1268:26: warning: unused variable ‘dev’ [-Wunused-variable]
> 
> Signed-off-by: Luis Henriques<luis.henriques@canonical.com>
> ---
>  drivers/video/vga16fb.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/video/vga16fb.c b/drivers/video/vga16fb.c
> index 830ded4..2827333 100644
> --- a/drivers/video/vga16fb.c
> +++ b/drivers/video/vga16fb.c
> @@ -1265,7 +1265,6 @@ static void vga16fb_imageblit(struct fb_info *info, const struct fb_image *image
>  
>  static void vga16fb_destroy(struct fb_info *info)
>  {
> -	struct platform_device *dev = container_of(info->device, struct platform_device, dev);
>  	iounmap(info->screen_base);
>  	fb_dealloc_cmap(&info->cmap);
>  	/* XXX unshare VGA regions */
> 

Thanks, I've applied this into my 3.12/fbdev branch.

 Tomi



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

^ permalink raw reply

* Re: [PATCH V2] driver/vga16fb.c: remove the unused variable "dev" of function vga16fb_destroy()
From: Tomi Valkeinen @ 2013-07-26  7:31 UTC (permalink / raw)
  To: Paul Bolle
  Cc: Geert Uytterhoeven, Gu Zheng, Jean-Christophe PLAGNIOL-VILLARD,
	Linux Fbdev development list, linux-kernel
In-Reply-To: <1374747739.29835.45.camel@x61.thuisdomein>

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

On 25/07/13 13:22, Paul Bolle wrote:
> On Thu, 2013-07-25 at 12:11 +0200, Geert Uytterhoeven wrote:
>> Please send a v3, which has the version info under the above "---",
>> instead of making it a part of the patch description to be committed.
> 
> Grepping through my mail tells me this is the fourth time a patch has
> been submitted to fix this trivial issue. Perhaps (one of) the
> maintainers can indicate which patch, if any, the maintainers have taken
> or will be taking.

I took the the oldest patch for this in my mailbox, from Luis.

 Tomi



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

^ permalink raw reply

* Re: [PATCH v3] video: xilinxfb: Fix compilation warning
From: Tomi Valkeinen @ 2013-07-26  7:33 UTC (permalink / raw)
  To: Michal Simek
  Cc: Jean-Christophe Plagniol-Villard, Jingoo Han, Geert Uytterhoeven,
	Michal Simek, linux-fbdev, linux-kernel
In-Reply-To: <b8701d73538d37495b41ef465440a6d5f3018870.1374759923.git.michal.simek@xilinx.com>

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

On 25/07/13 16:45, Michal Simek wrote:
> regs_phys is phys_addr_t (u32 or u64).
> Lets use %pa printk format specifier.
> 
> Fixes compilation warning introduced by:
> video: xilinxfb: Use drvdata->regs_phys instead of physaddr
> (sha1: c88fafef0135e1e1c3e23c3e32ccbeeabc587f81)
> 
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
> Changes in v3:
> - Fix commit message reported by Geert
> 
> Changes in v2:
> - Use %pa instead of casting
> 
> ppc44x_defconfig
> Fixes regressions in v3.11-rc2
> 
> ---
>  drivers/video/xilinxfb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
> index f3d4a69..6629b29 100644
> --- a/drivers/video/xilinxfb.c
> +++ b/drivers/video/xilinxfb.c
> @@ -341,8 +341,8 @@ static int xilinxfb_assign(struct platform_device *pdev,
> 
>  	if (drvdata->flags & BUS_ACCESS_FLAG) {
>  		/* Put a banner in the log (for DEBUG) */
> -		dev_dbg(dev, "regs: phys=%x, virt=%p\n", drvdata->regs_phys,
> -					drvdata->regs);
> +		dev_dbg(dev, "regs: phys=%pa, virt=%p\n",
> +			&drvdata->regs_phys, drvdata->regs);
>  	}
>  	/* Put a banner in the log (for DEBUG) */
>  	dev_dbg(dev, "fb: phys=%llx, virt=%p, size=%x\n",
> --
> 1.8.2.3
> 

Thanks, I've applied this into my 3.12/fbdev branch.

 Tomi



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

^ permalink raw reply

* Re: [PATCH v3] video: xilinxfb: Fix compilation warning
From: Tomi Valkeinen @ 2013-07-26  7:35 UTC (permalink / raw)
  To: Michal Simek
  Cc: Jean-Christophe Plagniol-Villard, Jingoo Han, Geert Uytterhoeven,
	Michal Simek, linux-fbdev, linux-kernel
In-Reply-To: <51F2262F.1020203@ti.com>

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

On 26/07/13 10:33, Tomi Valkeinen wrote:
> On 25/07/13 16:45, Michal Simek wrote:
>> regs_phys is phys_addr_t (u32 or u64).
>> Lets use %pa printk format specifier.
>>
>> Fixes compilation warning introduced by:
>> video: xilinxfb: Use drvdata->regs_phys instead of physaddr
>> (sha1: c88fafef0135e1e1c3e23c3e32ccbeeabc587f81)
>>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>

> Thanks, I've applied this into my 3.12/fbdev branch.

Actually, let's put this into 3.11-fixes/fbdev branch.

 Tomi



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

^ permalink raw reply

* Re: [PATCH 2/2] video: imxfb: Add feature to setup PWM Contrast Control Register
From: Sascha Hauer @ 2013-07-26  7:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20130725212053.b39198a8610efc157a91b7be@mail.ru>

On Thu, Jul 25, 2013 at 09:20:53PM +0400, Alexander Shiyan wrote:
> On Thu, 25 Jul 2013 15:38:56 +0200
> Markus Pargmann <mpa@pengutronix.de> wrote:
> 
> > Hi,
> > 
> > On Sun, Jul 21, 2013 at 12:35:09PM +0400, Alexander Shiyan wrote:
> > > This patch adds feature to setup PWM Contrast Control Register.
> > > This register is used to control the signal output at the contrast pin,
> > > which controls contrast of the LCD panel.
> > 
> > http://www.spinics.net/lists/linux-fbdev/msg10002.html
> 
> PWM? I can not understand how the PWM driver will be connected to the
> framebuffer driver. It is not backlight, this is contrast.
> Even if we imagine that the driver will be connected through phandle,
> then we will need to have at least 4! additional parameters in the framebuffer
> driver: freq source, frequency and active pulse period + phandle to PWM.
> Is it worth it, given that these parameters should not be adjustable?
> On my opinion, the only one additional parameter in framebuffer is enough.
> Thanks.

Why should the contrast of a display not be adjustable?

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 RESEND] video: mxsfb: Let device core handle pinctrl
From: Tomi Valkeinen @ 2013-07-26  7:46 UTC (permalink / raw)
  To: linux-fbdev
In-Reply-To: <1373923884-13332-1-git-send-email-festevam@gmail.com>

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

On 16/07/13 00:31, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
> 
> Since commit ab78029 (drivers/pinctrl: grab default handles from device core)
> we can rely on device core for handling pinctrl, so remove 
> devm_pinctrl_get_select_default() from the driver.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> Acked-by: Shawn Guo <shawn.guo@linaro.org>

Thanks, I've applied this into my 3.12/fbdev branch.

 Tomi



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

^ permalink raw reply

* Re: [PATCH] video: nuc900fb: fix to pass correct device identity to request_irq()
From: Tomi Valkeinen @ 2013-07-26  7:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAPgLHd9CZ=VponJTbTGKTXVTdvMQM6_T+-RWuPMrk0WYZPbW1Q@mail.gmail.com>

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

On 16/07/13 03:07, Wei Yongjun wrote:
> The IRQ handler nuc900fb_irqhandler() use dev_id as a type of
> struct nuc900fb_info *, so we should pass fbi as the device
> identity to request_irq().
> 
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> ---
> Was 'video: nuc900fb: fix to pass correct device identity to free_irq()'
> ---
>  drivers/video/nuc900fb.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
> index 8c527e5..796e511 100644
> --- a/drivers/video/nuc900fb.c
> +++ b/drivers/video/nuc900fb.c
> @@ -587,8 +587,7 @@ static int nuc900fb_probe(struct platform_device *pdev)
>  	fbinfo->flags			= FBINFO_FLAG_DEFAULT;
>  	fbinfo->pseudo_palette		= &fbi->pseudo_pal;
>  
> -	ret = request_irq(irq, nuc900fb_irqhandler, 0,
> -			  pdev->name, fbinfo);
> +	ret = request_irq(irq, nuc900fb_irqhandler, 0, pdev->name, fbi);
>  	if (ret) {
>  		dev_err(&pdev->dev, "cannot register irq handler %d -err %d\n",
>  			irq, ret);
> 

Thanks, I've applied this into my 3.11-fixes/fbdev branch.

 Tomi



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

^ permalink raw reply

* Re: [PATCH 2/2] video: imxfb: Add feature to  =?UTF-8?B?c2V0dXAgUFdNIENvb
From: Alexander Shiyan @ 2013-07-26  7:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20130726073848.GF2737@pengutronix.de>

PiBPbiBUaHUsIEp1bCAyNSwgMjAxMyBhdCAwOToyMDo1M1BNICswNDAwLCBBbGV4YW5kZXIgU2hp
eWFuIHdyb3RlOgo+ID4gT24gVGh1LCAyNSBKdWwgMjAxMyAxNTozODo1NiArMDIwMAo+ID4gTWFy
a3VzIFBhcmdtYW5uIDxtcGFAcGVuZ3V0cm9uaXguZGU+IHdyb3RlOgo+ID4gCj4gPiA+IEhpLAo+
ID4gPiAKPiA+ID4gT24gU3VuLCBKdWwgMjEsIDIwMTMgYXQgMTI6MzU6MDlQTSArMDQwMCwgQWxl
eGFuZGVyIFNoaXlhbiB3cm90ZToKPiA+ID4gPiBUaGlzIHBhdGNoIGFkZHMgZmVhdHVyZSB0byBz
ZXR1cCBQV00gQ29udHJhc3QgQ29udHJvbCBSZWdpc3Rlci4KPiA+ID4gPiBUaGlzIHJlZ2lzdGVy
IGlzIHVzZWQgdG8gY29udHJvbCB0aGUgc2lnbmFsIG91dHB1dCBhdCB0aGUgY29udHJhc3QgcGlu
LAo+ID4gPiA+IHdoaWNoIGNvbnRyb2xzIGNvbnRyYXN0IG9mIHRoZSBMQ0QgcGFuZWwuCj4gPiA+
IAo+ID4gPiBodHRwOi8vd3d3LnNwaW5pY3MubmV0L2xpc3RzL2xpbnV4LWZiZGV2L21zZzEwMDAy
Lmh0bWwKPiA+IAo+ID4gUFdNPyBJIGNhbiBub3QgdW5kZXJzdGFuZCBob3cgdGhlIFBXTSBkcml2
ZXIgd2lsbCBiZSBjb25uZWN0ZWQgdG8gdGhlCj4gPiBmcmFtZWJ1ZmZlciBkcml2ZXIuIEl0IGlz
IG5vdCBiYWNrbGlnaHQsIHRoaXMgaXMgY29udHJhc3QuCj4gPiBFdmVuIGlmIHdlIGltYWdpbmUg
dGhhdCB0aGUgZHJpdmVyIHdpbGwgYmUgY29ubmVjdGVkIHRocm91Z2ggcGhhbmRsZSwKPiA+IHRo
ZW4gd2Ugd2lsbCBuZWVkIHRvIGhhdmUgYXQgbGVhc3QgNCEgYWRkaXRpb25hbCBwYXJhbWV0ZXJz
IGluIHRoZSBmcmFtZWJ1ZmZlcgo+ID4gZHJpdmVyOiBmcmVxIHNvdXJjZSwgZnJlcXVlbmN5IGFu
ZCBhY3RpdmUgcHVsc2UgcGVyaW9kICsgcGhhbmRsZSB0byBQV00uCj4gPiBJcyBpdCB3b3J0aCBp
dCwgZ2l2ZW4gdGhhdCB0aGVzZSBwYXJhbWV0ZXJzIHNob3VsZCBub3QgYmUgYWRqdXN0YWJsZT8K
PiA+IE9uIG15IG9waW5pb24sIHRoZSBvbmx5IG9uZSBhZGRpdGlvbmFsIHBhcmFtZXRlciBpbiBm
cmFtZWJ1ZmZlciBpcyBlbm91Z2guCj4gPiBUaGFua3MuCj4gCj4gV2h5IHNob3VsZCB0aGUgY29u
dHJhc3Qgb2YgYSBkaXNwbGF5IG5vdCBiZSBhZGp1c3RhYmxlPwoKSSBzdGlsbCBjYW4gbm90IHVu
ZGVyc3RhbmQgdGhlIGludGVyZmFjZSB0aHJvdWdoIHdoaWNoIGl0IGNhbiBiZSBjaGFuZ2VkLgpT
YW1lIGFzIGhvdyB0aGUgZGVmYXVsdCBzZXR0aW5ncyBjYW4gYmUgcGFzc2VkIHRvIHRoZSBmcmFt
ZWJ1ZmZlciBkcml2ZXIuCgotLS0K

^ permalink raw reply

* Re: [PATCH v3] video: xilinxfb: Fix compilation warning
From: Michal Simek @ 2013-07-26  8:27 UTC (permalink / raw)
  To: Tomi Valkeinen
  Cc: Michal Simek, Jean-Christophe Plagniol-Villard, Jingoo Han,
	Geert Uytterhoeven, linux-fbdev, linux-kernel
In-Reply-To: <51F226C2.9000206@ti.com>

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

On 07/26/2013 09:35 AM, Tomi Valkeinen wrote:
> On 26/07/13 10:33, Tomi Valkeinen wrote:
>> On 25/07/13 16:45, Michal Simek wrote:
>>> regs_phys is phys_addr_t (u32 or u64).
>>> Lets use %pa printk format specifier.
>>>
>>> Fixes compilation warning introduced by:
>>> video: xilinxfb: Use drvdata->regs_phys instead of physaddr
>>> (sha1: c88fafef0135e1e1c3e23c3e32ccbeeabc587f81)
>>>
>>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> 
>> Thanks, I've applied this into my 3.12/fbdev branch.
> 
> Actually, let's put this into 3.11-fixes/fbdev branch.
> 

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform



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

^ permalink raw reply

* Re: [patch -next] fb: fix recent breakage in correct_chipset()
From: Tomi Valkeinen @ 2013-07-26  8:34 UTC (permalink / raw)
  To: linux-fbdev
In-Reply-To: <20130702062821.GC24410@elgon.mountain>

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

On 02/07/13 09:28, Dan Carpenter wrote:
> The 6e36308a6f "fb: fix atyfb build warning" isn't right.  It makes all
> the indexes off by one.  This patch reverts it and casts the
> ARRAY_SIZE() to int to silence the build warning.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> 
> diff --git a/drivers/video/aty/atyfb_base.c b/drivers/video/aty/atyfb_base.c
> index a89c15d..9b0f12c 100644
> --- a/drivers/video/aty/atyfb_base.c
> +++ b/drivers/video/aty/atyfb_base.c
> @@ -435,8 +435,8 @@ static int correct_chipset(struct atyfb_par *par)
>  	const char *name;
>  	int i;
>  
> -	for (i = ARRAY_SIZE(aty_chips); i > 0; i--)
> -		if (par->pci_id == aty_chips[i - 1].pci_id)
> +	for (i = (int)ARRAY_SIZE(aty_chips) - 1; i >= 0; i--)
> +		if (par->pci_id == aty_chips[i].pci_id)
>  			break;
>  
>  	if (i < 0)
> 

Thanks, I've applied this into my 3.11-fixes/fbdev branch.

 Tomi



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

^ permalink raw reply

* Re: [PATCH] matroxfb: replace kmalloc and memset with kzalloc.
From: Tomi Valkeinen @ 2013-07-26  8:36 UTC (permalink / raw)
  To: Alexandru Juncu; +Cc: plagnioj, linux-fbdev, linux-kernel
In-Reply-To: <1373637618-10529-1-git-send-email-alexj@rosedu.org>

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

On 12/07/13 17:00, Alexandru Juncu wrote:
> Signed-off-by: Alexandru Juncu <alexj@rosedu.org>
> ---
>  drivers/video/matrox/matroxfb_base.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/video/matrox/matroxfb_base.c b/drivers/video/matrox/matroxfb_base.c
> index 401a56e..2456529 100644
> --- a/drivers/video/matrox/matroxfb_base.c
> +++ b/drivers/video/matrox/matroxfb_base.c
> @@ -2029,10 +2029,9 @@ static int matroxfb_probe(struct pci_dev* pdev, const struct pci_device_id* dumm
>  		return -1;
>  	}
>  
> -	minfo = kmalloc(sizeof(*minfo), GFP_KERNEL);
> +	minfo = kzalloc(sizeof(*minfo), GFP_KERNEL);
>  	if (!minfo)
>  		return -1;
> -	memset(minfo, 0, sizeof(*minfo));
>  
>  	minfo->pcidev = pdev;
>  	minfo->dead = 0;
> 

Thanks, I've applied this into my 3.12/fbdev branch.

 Tomi



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

^ permalink raw reply

* Re: [PATCH] video: sh7760fb: fix to pass correct device identity to free_irq()
From: Tomi Valkeinen @ 2013-07-26  8:38 UTC (permalink / raw)
  To: linux-fbdev
In-Reply-To: <CAPgLHd9+d0Csf0kad8fnYQc4UQLdoJCo+-MZNNGKi_PTxeBJjQ@mail.gmail.com>

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

On 12/07/13 16:20, Wei Yongjun wrote:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> 
> free_irq() expects the same device identity that was passed to
> corresponding request_irq(), otherwise the IRQ is not freed.
> 
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> ---
>  drivers/video/sh7760fb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/sh7760fb.c b/drivers/video/sh7760fb.c
> index a8c6c43..1265b25 100644
> --- a/drivers/video/sh7760fb.c
> +++ b/drivers/video/sh7760fb.c
> @@ -567,7 +567,7 @@ static int sh7760fb_remove(struct platform_device *dev)
>  	fb_dealloc_cmap(&info->cmap);
>  	sh7760fb_free_mem(info);
>  	if (par->irq >= 0)
> -		free_irq(par->irq, par);
> +		free_irq(par->irq, &par->vsync);
>  	iounmap(par->base);
>  	release_mem_region(par->ioarea->start, resource_size(par->ioarea));
>  	framebuffer_release(info);
> 

Thanks, I've applied this into my 3.11-fixes/fbdev branch.

 Tomi



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

^ permalink raw reply

* Re: [PATCH] drivers/video: remove unused parameter in Kconfig
From: Tomi Valkeinen @ 2013-07-26  8:41 UTC (permalink / raw)
  To: Michael Opdenacker; +Cc: plagnioj, linux-fbdev, linux-kernel
In-Reply-To: <1373259806-23067-1-git-send-email-michael.opdenacker@free-electrons.com>

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

On 08/07/13 08:03, Michael Opdenacker wrote:
> This patch proposes to remove the FB_NUC900_DEBUG kernel configuration
> parameter defined in drivers/video/Kconfig, but used nowhere
> in the makefiles and source code.
> 
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
> ---
>  drivers/video/Kconfig | 7 -------
>  1 file changed, 7 deletions(-)
> 
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 2e937bd..a9c0964 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2098,13 +2098,6 @@ config GPM1040A0_320X240
>          bool "Giantplus Technology GPM1040A0 320x240 Color TFT LCD"
>          depends on FB_NUC900
>  
> -config FB_NUC900_DEBUG
> -        bool "NUC900 lcd debug messages"
> -        depends on FB_NUC900
> -        help
> -          Turn on debugging messages. Note that you can set/unset at run time
> -          through sysfs
> -
>  config FB_SM501
>  	tristate "Silicon Motion SM501 framebuffer support"
>  	depends on FB && MFD_SM501
> 

Thanks, I've applied this into my 3.12/fbdev branch.

 Tomi



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

^ permalink raw reply

* Re: [PATCH] backlight: lp855x: set zero brightness at FBBLANK
From: Tomi Valkeinen @ 2013-07-26  8:45 UTC (permalink / raw)
  To: Oskar Andero
  Cc: linux-kernel, linux-fbdev, Jean-Christophe Plagniol-Villard,
	Radovan Lekanovic, Shingo Nakao, Milo Kim, Richard Purdie
In-Reply-To: <1372767354-16499-1-git-send-email-oskar.andero@sonymobile.com>

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

On 02/07/13 15:15, Oskar Andero wrote:
> From: Shingo Nakao <shingo.x.nakao@sonymobile.com>
> 
> When backlight turns on early from display, a white line can be
> seen on the screen. Therefore make sure backlight is off when we
> are under an fb blank event.
> 
> Signed-off-by: Shingo Nakao <shingo.x.nakao@sonymobile.com>
> Cc: Milo Kim <milo.kim@ti.com>
> Cc: Richard Purdie <rpurdie@rpsys.net>
> Signed-off-by: Oskar Andero <oskar.andero@sonymobile.com>
> ---
>  drivers/video/backlight/lp855x_bl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/backlight/lp855x_bl.c b/drivers/video/backlight/lp855x_bl.c
> index a0e1e02..c0b41f1 100644
> --- a/drivers/video/backlight/lp855x_bl.c
> +++ b/drivers/video/backlight/lp855x_bl.c
> @@ -246,7 +246,7 @@ static int lp855x_bl_update_status(struct backlight_device *bl)
>  {
>  	struct lp855x *lp = bl_get_data(bl);
>  
> -	if (bl->props.state & BL_CORE_SUSPENDED)
> +	if (bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
>  		bl->props.brightness = 0;
>  
>  	if (lp->mode == PWM_BASED) {
> 

Thanks, I've applied this into my 3.12/fbdev branch.

 Tomi



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

^ permalink raw reply

* Re: [PATCH v3] simplefb: add support for a8b8g8r8 pixel format
From: Tomi Valkeinen @ 2013-07-26  8:51 UTC (permalink / raw)
  To: Alexandre Courbot
  Cc: Jean-Christophe Plagniol-Villard, Stephen Warren, Olof Johansson,
	gnurou, linux-kernel, linux-fbdev
In-Reply-To: <1370590290-13467-1-git-send-email-acourbot@nvidia.com>

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

On 07/06/13 10:31, Alexandre Courbot wrote:
> A framebuffer of this format is set up by SHIELD's bootloader.
> 
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> Acked-by: Olof Johansson <olof@lixom.net>
> ---
> Changes from v2:
> - Fixed typo in format (Thanks Alexander van Heukelum!)
> 
> Changes from v1:
> - Added description to motivate the change
> - Added ack
> 
>  Documentation/devicetree/bindings/video/simple-framebuffer.txt | 1 +
>  drivers/video/simplefb.c                                       | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> index 3ea4605..70c26f3 100644
> --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> @@ -12,6 +12,7 @@ Required properties:
>  - stride: The number of bytes in each line of the framebuffer.
>  - format: The format of the framebuffer surface. Valid values are:
>    - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
> +  - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
>  
>  Example:
>  
> diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
> index e2e9e3e..f015482 100644
> --- a/drivers/video/simplefb.c
> +++ b/drivers/video/simplefb.c
> @@ -84,6 +84,7 @@ struct simplefb_format {
>  
>  static struct simplefb_format simplefb_formats[] = {
>  	{ "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
> +	{ "a8b8g8r8", 32, {0, 8}, {8, 8}, {16, 8}, {24, 8} },
>  };
>  
>  struct simplefb_params {

Thanks, I've applied this into my 3.12/fbdev branch.

 Tomi



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

^ permalink raw reply

* [RESEND PATCH v10 8/8] usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops
From: Kishon Vijay Abraham I @ 2013-07-26 12:51 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1374842963-13545-1-git-send-email-kishon@ti.com>

Now that twl4030-usb is adapted to the new generic PHY framework,
*set_suspend* and *phy_init* ops can be removed from twl4030-usb driver.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
 drivers/phy/phy-twl4030-usb.c |   57 ++++++++++-------------------------------
 1 file changed, 13 insertions(+), 44 deletions(-)

diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 494f107..c437211 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -422,25 +422,20 @@ static void twl4030_phy_power(struct twl4030_usb *twl, int on)
 	}
 }
 
-static void twl4030_phy_suspend(struct twl4030_usb *twl, int controller_off)
+static int twl4030_phy_power_off(struct phy *phy)
 {
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
 	if (twl->asleep)
-		return;
+		return 0;
 
 	twl4030_phy_power(twl, 0);
 	twl->asleep = 1;
 	dev_dbg(twl->dev, "%s\n", __func__);
-}
-
-static int twl4030_phy_power_off(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	twl4030_phy_suspend(twl, 0);
 	return 0;
 }
 
-static void __twl4030_phy_resume(struct twl4030_usb *twl)
+static void __twl4030_phy_power_on(struct twl4030_usb *twl)
 {
 	twl4030_phy_power(twl, 1);
 	twl4030_i2c_access(twl, 1);
@@ -449,11 +444,13 @@ static void __twl4030_phy_resume(struct twl4030_usb *twl)
 		twl4030_i2c_access(twl, 0);
 }
 
-static void twl4030_phy_resume(struct twl4030_usb *twl)
+static int twl4030_phy_power_on(struct phy *phy)
 {
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
+
 	if (!twl->asleep)
-		return;
-	__twl4030_phy_resume(twl);
+		return 0;
+	__twl4030_phy_power_on(twl);
 	twl->asleep = 0;
 	dev_dbg(twl->dev, "%s\n", __func__);
 
@@ -466,13 +463,6 @@ static void twl4030_phy_resume(struct twl4030_usb *twl)
 		cancel_delayed_work(&twl->id_workaround_work);
 		schedule_delayed_work(&twl->id_workaround_work, HZ);
 	}
-}
-
-static int twl4030_phy_power_on(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	twl4030_phy_resume(twl);
 	return 0;
 }
 
@@ -604,9 +594,9 @@ static void twl4030_id_workaround_work(struct work_struct *work)
 	}
 }
 
-static int twl4030_usb_phy_init(struct usb_phy *phy)
+static int twl4030_phy_init(struct phy *phy)
 {
-	struct twl4030_usb *twl = phy_to_twl(phy);
+	struct twl4030_usb *twl = phy_get_drvdata(phy);
 	enum omap_musb_vbus_id_status status;
 
 	/*
@@ -621,32 +611,13 @@ static int twl4030_usb_phy_init(struct usb_phy *phy)
 
 	if (status = OMAP_MUSB_ID_GROUND || status = OMAP_MUSB_VBUS_VALID) {
 		omap_musb_mailbox(twl->linkstat);
-		twl4030_phy_resume(twl);
+		twl4030_phy_power_on(phy);
 	}
 
 	sysfs_notify(&twl->dev->kobj, NULL, "vbus");
 	return 0;
 }
 
-static int twl4030_phy_init(struct phy *phy)
-{
-	struct twl4030_usb *twl = phy_get_drvdata(phy);
-
-	return twl4030_usb_phy_init(&twl->phy);
-}
-
-static int twl4030_set_suspend(struct usb_phy *x, int suspend)
-{
-	struct twl4030_usb *twl = phy_to_twl(x);
-
-	if (suspend)
-		twl4030_phy_suspend(twl, 1);
-	else
-		twl4030_phy_resume(twl);
-
-	return 0;
-}
-
 static int twl4030_set_peripheral(struct usb_otg *otg,
 					struct usb_gadget *gadget)
 {
@@ -719,8 +690,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	twl->phy.label		= "twl4030";
 	twl->phy.otg		= otg;
 	twl->phy.type		= USB_PHY_TYPE_USB2;
-	twl->phy.set_suspend	= twl4030_set_suspend;
-	twl->phy.init		= twl4030_usb_phy_init;
 
 	otg->phy		= &twl->phy;
 	otg->set_host		= twl4030_set_host;
-- 
1.7.10.4


^ permalink raw reply related

* [RESEND PATCH v10 7/8] usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
From: Kishon Vijay Abraham I @ 2013-07-26 12:51 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1374842963-13545-1-git-send-email-kishon@ti.com>

Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
 drivers/phy/phy-omap-usb2.c |   25 -------------------------
 1 file changed, 25 deletions(-)

diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 25e0f3c..dec3fab 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -97,29 +97,6 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
 	return 0;
 }
 
-static int omap_usb2_suspend(struct usb_phy *x, int suspend)
-{
-	u32 ret;
-	struct omap_usb *phy = phy_to_omapusb(x);
-
-	if (suspend && !phy->is_suspended) {
-		omap_control_usb_phy_power(phy->control_dev, 0);
-		pm_runtime_put_sync(phy->dev);
-		phy->is_suspended = 1;
-	} else if (!suspend && phy->is_suspended) {
-		ret = pm_runtime_get_sync(phy->dev);
-		if (ret < 0) {
-			dev_err(phy->dev, "get_sync failed with err %d\n",
-									ret);
-			return ret;
-		}
-		omap_control_usb_phy_power(phy->control_dev, 1);
-		phy->is_suspended = 0;
-	}
-
-	return 0;
-}
-
 static int omap_usb_power_off(struct phy *x)
 {
 	struct omap_usb *phy = phy_get_drvdata(x);
@@ -167,7 +144,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 
 	phy->phy.dev		= phy->dev;
 	phy->phy.label		= "omap-usb2";
-	phy->phy.set_suspend	= omap_usb2_suspend;
 	phy->phy.otg		= otg;
 	phy->phy.type		= USB_PHY_TYPE_USB2;
 
@@ -182,7 +158,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
-	phy->is_suspended	= 1;
 	omap_control_usb_phy_power(phy->control_dev, 0);
 
 	otg->set_host		= omap_usb_set_host;
-- 
1.7.10.4


^ permalink raw reply related

* [RESEND PATCH v10 6/8] usb: musb: omap2430: use the new generic PHY framework
From: Kishon Vijay Abraham I @ 2013-07-26 12:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1374842963-13545-1-git-send-email-kishon@ti.com>

Use the generic PHY framework API to get the PHY. The usb_phy_set_resume
and usb_phy_set_suspend is replaced with power_on and
power_off to align with the new PHY framework.

musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
---
 drivers/usb/musb/Kconfig     |    1 +
 drivers/usb/musb/musb_core.h |    2 ++
 drivers/usb/musb/omap2430.c  |   26 ++++++++++++++++++++------
 3 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 797e3fd..25e2e57 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -76,6 +76,7 @@ config USB_MUSB_TUSB6010
 config USB_MUSB_OMAP2PLUS
 	tristate "OMAP2430 and onwards"
 	depends on ARCH_OMAP2PLUS
+	select GENERIC_PHY
 
 config USB_MUSB_AM35X
 	tristate "AM35x"
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7d341c3..6e567bd 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
 #include <linux/usb.h>
 #include <linux/usb/otg.h>
 #include <linux/usb/musb.h>
+#include <linux/phy/phy.h>
 
 struct musb;
 struct musb_hw_ep;
@@ -346,6 +347,7 @@ struct musb {
 	u16			int_tx;
 
 	struct usb_phy		*xceiv;
+	struct phy		*phy;
 
 	int nIrq;
 	unsigned		irq_wake:1;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 6708a3b..f7b33f4 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -348,11 +348,21 @@ static int omap2430_musb_init(struct musb *musb)
 	 * up through ULPI.  TWL4030-family PMICs include one,
 	 * which needs a driver, drivers aren't always needed.
 	 */
-	if (dev->parent->of_node)
+	if (dev->parent->of_node) {
+		musb->phy = devm_phy_get(dev->parent, "usb2-phy");
+
+		/* We can't totally remove musb->xceiv as of now because
+		 * musb core uses xceiv.state and xceiv.otg. Once we have
+		 * a separate state machine to handle otg, these can be moved
+		 * out of xceiv and then we can start using the generic PHY
+		 * framework
+		 */
 		musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
 		    "usb-phy", 0);
-	else
+	} else {
 		musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+		musb->phy = devm_phy_get(dev, "usb");
+	}
 
 	if (IS_ERR(musb->xceiv)) {
 		status = PTR_ERR(musb->xceiv);
@@ -364,6 +374,10 @@ static int omap2430_musb_init(struct musb *musb)
 		return -EPROBE_DEFER;
 	}
 
+	if (IS_ERR(musb->phy)) {
+		pr_err("HS USB OTG: no PHY configured\n");
+		return PTR_ERR(musb->phy);
+	}
 	musb->isr = omap2430_musb_interrupt;
 
 	status = pm_runtime_get_sync(dev);
@@ -397,7 +411,7 @@ static int omap2430_musb_init(struct musb *musb)
 	if (glue->status != OMAP_MUSB_UNKNOWN)
 		omap_musb_set_mailbox(glue);
 
-	usb_phy_init(musb->xceiv);
+	phy_init(musb->phy);
 
 	pm_runtime_put_noidle(musb->controller);
 	return 0;
@@ -460,6 +474,7 @@ static int omap2430_musb_exit(struct musb *musb)
 	del_timer_sync(&musb_idle_timer);
 
 	omap2430_low_level_exit(musb);
+	phy_exit(musb->phy);
 
 	return 0;
 }
@@ -633,7 +648,7 @@ static int omap2430_runtime_suspend(struct device *dev)
 				OTG_INTERFSEL);
 
 		omap2430_low_level_exit(musb);
-		usb_phy_set_suspend(musb->xceiv, 1);
+		phy_power_off(musb->phy);
 	}
 
 	return 0;
@@ -648,8 +663,7 @@ static int omap2430_runtime_resume(struct device *dev)
 		omap2430_low_level_init(musb);
 		musb_writel(musb->mregs, OTG_INTERFSEL,
 				musb->context.otg_interfsel);
-
-		usb_phy_set_suspend(musb->xceiv, 0);
+		phy_power_on(musb->phy);
 	}
 
 	return 0;
-- 
1.7.10.4


^ permalink raw reply related

* [RESEND PATCH v10 5/8] ARM: dts: omap: update usb_otg_hs data
From: Kishon Vijay Abraham I @ 2013-07-26 12:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1374842963-13545-1-git-send-email-kishon@ti.com>

Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |    5 +++++
 Documentation/devicetree/bindings/usb/usb-phy.txt  |    6 ++++++
 arch/arm/boot/dts/omap3-beagle-xm.dts              |    2 ++
 arch/arm/boot/dts/omap3-evm.dts                    |    2 ++
 arch/arm/boot/dts/omap3-overo.dtsi                 |    2 ++
 arch/arm/boot/dts/omap4.dtsi                       |    3 +++
 arch/arm/boot/dts/twl4030.dtsi                     |    1 +
 7 files changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 57e71f6..825790d 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
  - power : Should be "50". This signifies the controller can supply up to
    100mA when operating in host mode.
  - usb-phy : the phandle for the PHY device
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+   *phy* phandle.
 
 Optional properties:
  - ctrl-module : phandle of the control module this glue uses to write to
@@ -33,6 +36,8 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
 	num-eps = <16>;
 	ram-bits = <12>;
 	ctrl-module = <&omap_control_usb>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 };
 
 Board specific device node entry
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 61496f5..c0245c8 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -5,6 +5,8 @@ OMAP USB2 PHY
 Required properties:
  - compatible: Should be "ti,omap-usb2"
  - reg : Address and length of the register set for the device.
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -16,6 +18,7 @@ usb2phy@4a0ad080 {
 	compatible = "ti,omap-usb2";
 	reg = <0x4a0ad080 0x58>;
 	ctrl-module = <&omap_control_usb>;
+	#phy-cells = <0>;
 };
 
 OMAP USB3 PHY
@@ -25,6 +28,8 @@ Required properties:
  - reg : Address and length of the register set for the device.
  - reg-names: The names of the register addresses corresponding to the registers
    filled in "reg".
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -39,4 +44,5 @@ usb3phy@4a084400 {
 	      <0x4a084c00 0x40>;
 	reg-names = "phy_rx", "phy_tx", "pll_ctrl";
 	ctrl-module = <&omap_control_usb>;
+	#phy-cells = <0>;
 };
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index afdb164..533b2da 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -144,6 +144,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 7d4329d..4134dd0 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -70,6 +70,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
index 8f1abec..a461d2f 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -76,6 +76,8 @@
 &usb_otg_hs {
 	interface-type = <0>;
 	usb-phy = <&usb2_phy>;
+	phys = <&usb2_phy>;
+	phy-names = "usb2-phy";
 	mode = <3>;
 	power = <50>;
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..1e8e2fe 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -520,6 +520,7 @@
 				compatible = "ti,omap-usb2";
 				reg = <0x4a0ad080 0x58>;
 				ctrl-module = <&omap_control_usb>;
+				#phy-cells = <0>;
 			};
 		};
 
@@ -658,6 +659,8 @@
 			interrupt-names = "mc", "dma";
 			ti,hwmods = "usb_otg_hs";
 			usb-phy = <&usb2_phy>;
+			phys = <&usb2_phy>;
+			phy-names = "usb2-phy";
 			multipoint = <1>;
 			num-eps = <16>;
 			ram-bits = <12>;
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index b3034da..ce4cd6f 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -80,6 +80,7 @@
 		usb1v8-supply = <&vusb1v8>;
 		usb3v1-supply = <&vusb3v1>;
 		usb_mode = <1>;
+		#phy-cells = <0>;
 	};
 
 	twl_pwm: pwm {
-- 
1.7.10.4


^ permalink raw reply related


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