* Re: [PATCHv8][ 1/6] video: imxfb: Introduce regulator support.
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-10-30 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1383061860-25035-1-git-send-email-denis@eukrea.com>
On 16:50 Tue 29 Oct , Denis Carikli wrote:
> This commit is based on the following commit by Fabio Estevam:
> 4344429 video: mxsfb: Introduce regulator support
>
> Cc: Fabio Estevam <fabio.estevam@freescale.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> Cc: Eric Bénard <eric@eukrea.com>
> Signed-off-by: Denis Carikli <denis@eukrea.com>
> ---
> drivers/video/imxfb.c | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
> index 44ee678..4bf3837 100644
> --- a/drivers/video/imxfb.c
> +++ b/drivers/video/imxfb.c
> @@ -28,6 +28,7 @@
> #include <linux/cpufreq.h>
> #include <linux/clk.h>
> #include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
> #include <linux/dma-mapping.h>
> #include <linux/io.h>
> #include <linux/math64.h>
> @@ -145,6 +146,7 @@ struct imxfb_info {
> struct clk *clk_ipg;
> struct clk *clk_ahb;
> struct clk *clk_per;
> + struct regulator *reg_lcd;
> enum imxfb_type devtype;
> bool enabled;
>
> @@ -563,12 +565,23 @@ static void imxfb_exit_backlight(struct imxfb_info *fbi)
>
> static void imxfb_enable_controller(struct imxfb_info *fbi)
> {
> + int ret;
return the error so you can return it in imxfb_blank
>
> if (fbi->enabled)
> return;
>
> pr_debug("Enabling LCD controller\n");
>
> + if (fbi->reg_lcd) {
> + ret = regulator_enable(fbi->reg_lcd);
> + if (ret) {
> + dev_err(&fbi->pdev->dev,
> + "lcd regulator enable failed with error: %d\n",
> + ret);
> + return;
> + }
> + }
> +
> writel(fbi->screen_dma, fbi->regs + LCDC_SSA);
>
> /* panning offset 0 (0 pixel offset) */
> @@ -597,6 +610,8 @@ static void imxfb_enable_controller(struct imxfb_info *fbi)
>
> static void imxfb_disable_controller(struct imxfb_info *fbi)
> {
> + int ret;
> +
> if (!fbi->enabled)
> return;
>
> @@ -613,6 +628,14 @@ static void imxfb_disable_controller(struct imxfb_info *fbi)
> fbi->enabled = false;
>
> writel(0, fbi->regs + LCDC_RMCR);
> +
> + if (fbi->reg_lcd) {
> + ret = regulator_disable(fbi->reg_lcd);
> + if (ret)
> + dev_err(&fbi->pdev->dev,
> + "lcd regulator disable failed with error: %d\n",
> + ret);
> + }
ditto here
> }
>
> static int imxfb_blank(int blank, struct fb_info *info)
> @@ -1020,6 +1043,12 @@ static int imxfb_probe(struct platform_device *pdev)
> goto failed_register;
> }
>
> + fbi->reg_lcd = devm_regulator_get(&pdev->dev, "lcd");
> + if (IS_ERR(fbi->reg_lcd)) {
> + dev_info(&pdev->dev, "No lcd regulator used.\n");
> + fbi->reg_lcd = NULL;
> + }
> +
> imxfb_enable_controller(fbi);
> fbi->pdev = pdev;
> #ifdef PWMR_BACKLIGHT_AVAILABLE
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH 9/9] backlight: atmel-pwm-bl: use gpio_request_one
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-10-30 19:30 UTC (permalink / raw)
To: Johan Hovold
Cc: Richard Purdie, Jingoo Han, Nicolas Ferre, Tomi Valkeinen,
Andrew Morton, linux-fbdev, linux-kernel
In-Reply-To: <20131029132018.GC29615@localhost>
On 14:20 Tue 29 Oct , Johan Hovold wrote:
> On Fri, Oct 25, 2013 at 01:15:43PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 11:55 Wed 23 Oct , Johan Hovold wrote:
> > > Use devm_gpio_request_one rather than requesting and setting direction
> > > in two calls.
> >
> > this is the same I do not see any advantage
>
> It removes one error path.
>
> > and as I said for ather backligth It's wrong to enable or disable it at probe
> > as the bootloader might have already enable it for splash screen
>
> I agree with you on that, and it's actually the reason for the below
> clean up. I use a second patch:
>
> if (gpio_is_valid(pwmbl->gpio_on)) {
> - /* Turn display off by default. */
> - if (pdata->on_active_low)
> + /* Turn display off unless already enabled. */
> + if (pdata->gpio_on_enabled ^ pdata->on_active_low)
> flags = GPIOF_OUT_INIT_HIGH;
> else
> flags = GPIOF_OUT_INIT_LOW;
>
> to make sure the driver does not temporarily disable the backlight at
> probe.
>
> Decided not to submit it as part of this series when I realised that
> several other backlight drivers did the same, but perhaps I should?
I'm not happy with this idea to play with enable at probe time
we need to detect the current status if possible and only enable or disable
when requiered
Best Regards,
J.
>
> Thanks,
> Johan
>
> > >
> > > Acked-by: Jingoo Han <jg1.han@samsung.com>:w
> > > Signed-off-by: Johan Hovold <jhovold@gmail.com>
> > > ---
> > > drivers/video/backlight/atmel-pwm-bl.c | 15 ++++++++-------
> > > 1 file changed, 8 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/video/backlight/atmel-pwm-bl.c b/drivers/video/backlight/atmel-pwm-bl.c
> > > index 1277e0c..5ea2517 100644
> > > --- a/drivers/video/backlight/atmel-pwm-bl.c
> > > +++ b/drivers/video/backlight/atmel-pwm-bl.c
> > > @@ -124,6 +124,7 @@ static int atmel_pwm_bl_probe(struct platform_device *pdev)
> > > const struct atmel_pwm_bl_platform_data *pdata;
> > > struct backlight_device *bldev;
> > > struct atmel_pwm_bl *pwmbl;
> > > + int flags;
> > > int retval;
> > >
> > > pdata = dev_get_platdata(&pdev->dev);
> > > @@ -149,14 +150,14 @@ static int atmel_pwm_bl_probe(struct platform_device *pdev)
> > > return retval;
> > >
> > > if (gpio_is_valid(pwmbl->gpio_on)) {
> > > - retval = devm_gpio_request(&pdev->dev, pwmbl->gpio_on,
> > > - "gpio_atmel_pwm_bl");
> > > - if (retval)
> > > - goto err_free_pwm;
> > > -
> > > /* Turn display off by default. */
> > > - retval = gpio_direction_output(pwmbl->gpio_on,
> > > - 0 ^ pdata->on_active_low);
> > > + if (pdata->on_active_low)
> > > + flags = GPIOF_OUT_INIT_HIGH;
> > > + else
> > > + flags = GPIOF_OUT_INIT_LOW;
> > > +
> > > + retval = devm_gpio_request_one(&pdev->dev, pwmbl->gpio_on,
> > > + flags, "gpio_atmel_pwm_bl");
> > > if (retval)
> > > goto err_free_pwm;
> > > }
> > > --
> > > 1.8.4
> > >
^ permalink raw reply
* Re: outcome of DRM/KMS DT bindings session
From: Tomasz Figa @ 2013-10-30 18:26 UTC (permalink / raw)
To: dri-devel; +Cc: ksummit-2013-discuss, Linux Fbdev development list
In-Reply-To: <20131030120229.GF24559@pengutronix.de>
On Wednesday 30 of October 2013 13:02:29 Sascha Hauer wrote:
> On Tue, Oct 29, 2013 at 01:52:57PM +1000, Dave Airlie wrote:
> > So we had a sessions at kernel summit to discuss the driver model and
> > DT interactions for a display pipeline,
> >
> > we had good attendance from a few sides and I hope to summarise the
> > recommendations below,
> >
> > a) Device Tree bindings
> >
> > We should create a top-level virtual device binding that a top level
> > driver can bind to, like alsa asoc does.
> >
> > We should separate the CDF device tree model from CDF as a starting
> > point and refine it outside of CDF, and produce a set of bindings that
> > cover the current drivers we have, exynos, imx, tegra, msm, armada
> > etc. This set of bindings should not be tied on CDF being merged or
> > anything else.
> >
> > Display pipelines should be modelered in the device tree, but the
> > level of detail required for links between objects may be left up to
> > the SoC developer, esp wrt tightly coupled SoCs.
> >
> > Externally linked devices like bridges and panels should be explicitly
> > linked.
> >
> > b) Driver Model
> >
> > The big thing here is that the device tree description we use should
> > not dictate the driver model we use. This is the biggest thing I
> > learned, so what does it mean?
> >
> > We aren't required to write a device driver per device tree object.
> >
> > We shouldn't be writing device drivers per device tree object.
> >
> > For tightly-coupled SoCs where the blocks come from one vendor and are
> > reused a lot, a top level driver should use the DT as configuration
> > information source for the list of blocks it needs to initialise on
> > the card, not as a list of separate drivers. There may be some
> > external drivers required and the code should deal with this, like how
> > alsa asoc does.
> >
> > To share code between layers we should refactor it into a helper
> > library not a separate driver, the kms/v4l/fbdev can use the library.
> >
> > This should allow us to move forward a bit clearer esp with new
> > drivers and following these recommendations, and I think porting
> > current drivers to a sane model, especially exynos and imx.
> >
> > Now I saw we here but I'm only going to be donating my use of a big
> > stick and review abilities to making this happen, but I'm quite
> > willing to enforce some of these rules going forward as I think it
> > will make life easier.
> >
> > After looking at some of the ordering issues we've had with x86 GPUs
> > (which are really just a tightly coupled SoC) I don't want separate
> > drivers all having their own init, suspend/resume paths in them as I
> > know we'll have to start making special vtable entry points etc to
> > solve some random ordering issues that crop up.
>
> The DRM device has to be initialized/suspended/resumed as a whole, no
> doubt about that. If that's not the case you indeed open up the door for
> all kinds of ordering issues.
>
> Still the different components can be multiple devices, just initialize
> the drm device once all components are probed. Remove it again once a
> component is removed. Handle suspend in the DRM device, not in
> the individual component drivers. The suspend in the component drivers
> would only be called after the DRM device is completely quiesced.
> Similarly the resume in the component drivers would not reenable the
> components, this instead would be done in the DRM device when all
> components are there again.
>
> This way all components could be proper (driver model)devices with
> proper drivers without DRM even noticing that multiple components are
> involved.
>
> Side note: We have no choice anyway. All SoCs can (sometimes must)
> be extended with external I2C devices. On every SoC the I2C bus master
> is a separate device, so we have a multicomponent device (in the sense
> of driver model) already in many cases.
+1
Best regards,
Tomasz
^ permalink raw reply
* Re: [PATCH 1/1] video: exynos_mipi_dsi: Remove unused variable
From: Greg Kroah-Hartman @ 2013-10-30 17:50 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1382333533-32740-1-git-send-email-sachin.kamat@linaro.org>
On Wed, Oct 30, 2013 at 08:42:12AM +0530, Sachin Kamat wrote:
> On 30 October 2013 04:30, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > On Fri, Oct 25, 2013 at 10:51:48AM +0530, Sachin Kamat wrote:
> >> On 24 October 2013 21:25, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> >> > On Monday 21 October 2013 11:02 AM, Sachin Kamat wrote:
> >> >> 'pdev' is not used anymore (Removed vide commit 7e0be9f9 "video:
> >> >> exynos_mipi_dsim: Use the generic PHY driver"). Remove it and
> >> >> silence the following compilation warning:
> >> >> drivers/video/exynos/exynos_mipi_dsi.c:144:26: warning:
> >> >> unused variable ‘pdev’ [-Wunused-variable]
> >> >>
> >> >> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> >> > Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
> >>
> >> Thanks Kishon.
> >>
> >> I believe this patch should go through Greg's tree as your other
> >> patches are lined up there?
> >
> > I don't take drivers/video/* patches now, am I?
>
> Actually the patch that introduced this warning is lined up in your
> usb-next tree [1]
> as part of the phy series patches sent by Kishon. That is the reason I
> thought this
> one should go though your (usb) tree as well for now. Alternatively we
> can wait for
> rc-1 and then send it through the video tree if you prefer it that way.
>
> [1] https://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id~0be9f9f7cba3356f75b86737dbe3a005da067e
Please send it after 3.13-rc1 is out, as this isn't a big deal. That
way you can go through the "normal" tree.
thanks,
greg k-h
^ permalink raw reply
* Re: outcome of DRM/KMS DT bindings session
From: Sascha Hauer @ 2013-10-30 12:02 UTC (permalink / raw)
To: Dave Airlie; +Cc: ksummit-2013-discuss, Linux Fbdev development list, dri-devel
In-Reply-To: <CAPM=9twObPRhPavm9xD+7=JDPEVD+K_WFJxMGG=f5eXR12PvLw@mail.gmail.com>
On Tue, Oct 29, 2013 at 01:52:57PM +1000, Dave Airlie wrote:
> So we had a sessions at kernel summit to discuss the driver model and
> DT interactions for a display pipeline,
>
> we had good attendance from a few sides and I hope to summarise the
> recommendations below,
>
> a) Device Tree bindings
>
> We should create a top-level virtual device binding that a top level
> driver can bind to, like alsa asoc does.
>
> We should separate the CDF device tree model from CDF as a starting
> point and refine it outside of CDF, and produce a set of bindings that
> cover the current drivers we have, exynos, imx, tegra, msm, armada
> etc. This set of bindings should not be tied on CDF being merged or
> anything else.
>
> Display pipelines should be modelered in the device tree, but the
> level of detail required for links between objects may be left up to
> the SoC developer, esp wrt tightly coupled SoCs.
>
> Externally linked devices like bridges and panels should be explicitly linked.
>
> b) Driver Model
>
> The big thing here is that the device tree description we use should
> not dictate the driver model we use. This is the biggest thing I
> learned, so what does it mean?
>
> We aren't required to write a device driver per device tree object.
>
> We shouldn't be writing device drivers per device tree object.
>
> For tightly-coupled SoCs where the blocks come from one vendor and are
> reused a lot, a top level driver should use the DT as configuration
> information source for the list of blocks it needs to initialise on
> the card, not as a list of separate drivers. There may be some
> external drivers required and the code should deal with this, like how
> alsa asoc does.
>
> To share code between layers we should refactor it into a helper
> library not a separate driver, the kms/v4l/fbdev can use the library.
>
> This should allow us to move forward a bit clearer esp with new
> drivers and following these recommendations, and I think porting
> current drivers to a sane model, especially exynos and imx.
>
> Now I saw we here but I'm only going to be donating my use of a big
> stick and review abilities to making this happen, but I'm quite
> willing to enforce some of these rules going forward as I think it
> will make life easier.
>
> After looking at some of the ordering issues we've had with x86 GPUs
> (which are really just a tightly coupled SoC) I don't want separate
> drivers all having their own init, suspend/resume paths in them as I
> know we'll have to start making special vtable entry points etc to
> solve some random ordering issues that crop up.
The DRM device has to be initialized/suspended/resumed as a whole, no
doubt about that. If that's not the case you indeed open up the door for
all kinds of ordering issues.
Still the different components can be multiple devices, just initialize
the drm device once all components are probed. Remove it again once a
component is removed. Handle suspend in the DRM device, not in
the individual component drivers. The suspend in the component drivers
would only be called after the DRM device is completely quiesced.
Similarly the resume in the component drivers would not reenable the
components, this instead would be done in the DRM device when all
components are there again.
This way all components could be proper (driver model)devices with
proper drivers without DRM even noticing that multiple components are
involved.
Side note: We have no choice anyway. All SoCs can (sometimes must)
be extended with external I2C devices. On every SoC the I2C bus master
is a separate device, so we have a multicomponent device (in the sense
of driver model) already in many cases.
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 1/1] video: exynos_mipi_dsi: Unlock the mutex before returning
From: Tomi Valkeinen @ 2013-10-30 11:53 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1382677964-15298-1-git-send-email-sachin.kamat@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 847 bytes --]
On 2013-10-25 08:12, Sachin Kamat wrote:
> Mutex should be unlocked before returning. Fixes mutex lock-unlock
> imbalance issue.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> drivers/video/exynos/exynos_mipi_dsi_common.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/exynos/exynos_mipi_dsi_common.c b/drivers/video/exynos/exynos_mipi_dsi_common.c
> index 520fc9b..649d9e6 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi_common.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi_common.c
> @@ -376,6 +376,7 @@ int exynos_mipi_dsi_rd_data(struct mipi_dsim_device *dsim, unsigned int data_id,
> "data id %x is not supported current DSI spec.\n",
> data_id);
>
> + mutex_unlock(&dsim->lock);
> return -EINVAL;
> }
>
>
Thanks, queued for 3.13.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [Trivial PATCH] video: Remove unnecessary semicolons
From: Tomi Valkeinen @ 2013-10-30 11:35 UTC (permalink / raw)
To: Joe Perches; +Cc: linux-fbdev, LKML
In-Reply-To: <1381274604.23937.15.camel@joe-AO722>
[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]
On 2013-10-09 02:23, Joe Perches wrote:
> These aren't necessary after switch, for, and if blocks.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/video/cfbimgblt.c | 2 +-
> drivers/video/cg14.c | 4 ++--
> drivers/video/cg6.c | 2 +-
> drivers/video/exynos/exynos_mipi_dsi_common.c | 2 +-
> drivers/video/fsl-diu-fb.c | 2 +-
> drivers/video/leo.c | 2 +-
> drivers/video/matrox/matroxfb_DAC1064.c | 4 ++--
> drivers/video/matrox/matroxfb_Ti3026.c | 2 +-
> drivers/video/nvidia/nv_hw.c | 2 +-
> drivers/video/omap2/displays-new/panel-dsi-cm.c | 2 +-
> drivers/video/omap2/dss/dispc.c | 2 +-
> drivers/video/omap2/dss/dsi.c | 2 +-
> drivers/video/sbuslib.c | 2 +-
> drivers/video/sysimgblt.c | 2 +-
> drivers/video/tcx.c | 4 ++--
> drivers/video/vt8500lcdfb.c | 2 +-
> 16 files changed, 19 insertions(+), 19 deletions(-)
Thanks, queued for 3.13.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [RFC PATCH RESEND] fb: reorder the lock sequence to fix a potential lockdep
From: Tomi Valkeinen @ 2013-10-30 11:20 UTC (permalink / raw)
To: Gu Zheng, Jean-Christophe PLAGNIOL-VILLARD
Cc: Linux Fbdev development list, linux-kernel
In-Reply-To: <526DFDA8.7010806@cn.fujitsu.com>
[-- Attachment #1: Type: text/plain, Size: 714 bytes --]
Hi,
On 2013-10-28 08:01, Gu Zheng wrote:
> Following commits:
> 50e244cc79 fb: rework locking to fix lock ordering on takeover
> e93a9a8687 fb: Yet another band-aid for fixing lockdep mess
> 054430e773 fbcon: fix locking harder
>
> reworked locking to fix related lock ordering on takeover, and introduced console_lock
> into fbmem, but it seems that the new lock sequence(fb_info->lock ---> console_lock)
> is against with the one in console_callback(console_lock ---> fb_info->lock), and leads to
> a potential deadlock as following:
A quick grep shows that there are other places than fbmem.c which use
lock_fb_info and console_lock, for example drivers/video/sh_mobile_lcdcfb.c.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: outcome of DRM/KMS DT bindings session
From: Thierry Reding @ 2013-10-30 11:19 UTC (permalink / raw)
To: Dave Airlie; +Cc: ksummit-2013-discuss, Linux Fbdev development list, dri-devel
In-Reply-To: <CAPM=9twObPRhPavm9xD+7=JDPEVD+K_WFJxMGG=f5eXR12PvLw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3718 bytes --]
On Tue, Oct 29, 2013 at 01:52:57PM +1000, Dave Airlie wrote:
> So we had a sessions at kernel summit to discuss the driver model and
> DT interactions for a display pipeline,
>
> we had good attendance from a few sides and I hope to summarise the
> recommendations below,
>
> a) Device Tree bindings
>
> We should create a top-level virtual device binding that a top level
> driver can bind to, like alsa asoc does.
>
> We should separate the CDF device tree model from CDF as a starting
> point and refine it outside of CDF, and produce a set of bindings that
> cover the current drivers we have, exynos, imx, tegra, msm, armada
> etc. This set of bindings should not be tied on CDF being merged or
> anything else.
>
> Display pipelines should be modelered in the device tree, but the
> level of detail required for links between objects may be left up to
> the SoC developer, esp wrt tightly coupled SoCs.
>
> Externally linked devices like bridges and panels should be explicitly linked.
According to the above, the device tree bindings for simple panels that
I proposed earlier should be fine. However there was so much controversy
involved that I've decided not to make that part of my pull request this
cycle. Also they haven't been reviewed by DT bindings maintainers yes,
so according to our new rules they cannot be merged.
I think Laurent was more or less fine with them too, although he had
some objections to how DSI panels were represented and wanted those to
be sub-nodes of the DSI controller. I'll see if I can come up with
something to address that.
We should probably aim for a common binding for things like DSI.
> b) Driver Model
>
> The big thing here is that the device tree description we use should
> not dictate the driver model we use. This is the biggest thing I
> learned, so what does it mean?
>
> We aren't required to write a device driver per device tree object.
>
> We shouldn't be writing device drivers per device tree object.
I may remember this wrongly, but that's the opposite recommendation that
I got back when I started to work on Tegra DRM.
> For tightly-coupled SoCs where the blocks come from one vendor and are
> reused a lot, a top level driver should use the DT as configuration
> information source for the list of blocks it needs to initialise on
> the card, not as a list of separate drivers. There may be some
> external drivers required and the code should deal with this, like how
> alsa asoc does.
>
> To share code between layers we should refactor it into a helper
> library not a separate driver, the kms/v4l/fbdev can use the library.
>
> This should allow us to move forward a bit clearer esp with new
> drivers and following these recommendations, and I think porting
> current drivers to a sane model, especially exynos and imx.
>
> Now I saw we here but I'm only going to be donating my use of a big
> stick and review abilities to making this happen, but I'm quite
> willing to enforce some of these rules going forward as I think it
> will make life easier.
>
> After looking at some of the ordering issues we've had with x86 GPUs
> (which are really just a tightly coupled SoC) I don't want separate
> drivers all having their own init, suspend/resume paths in them as I
> know we'll have to start making special vtable entry points etc to
> solve some random ordering issues that crop up.
Where does that leave the Tegra driver? I've spent a significant amount
of time to get it to some sane state where having multiple subdrivers
are handled fairly nicely (in my opinion). Rewriting all of it isn't
something that I look forward to at all.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] simplefb: use write-combined remapping
From: Tomi Valkeinen @ 2013-10-30 10:54 UTC (permalink / raw)
To: David Herrmann
Cc: linux-kernel, Tom Gundersen, Alexandre Courbot, Stephen Warren,
dri-devel@lists.freedesktop.org, Jean-Christophe Plagniol-Villard,
linux-fbdev@vger.kernel.org
In-Reply-To: <CANq1E4SRWsKf4uqF01Rju-uSNF-gj9zL9_+0zAqsgPMjv8Q3Uw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]
On 2013-10-30 09:49, David Herrmann wrote:
> Hi Tomi
>
> Ping?
Thanks, queued this and the 1/2 patch for 3.13.
Tomi
>
> Thanks
> David
>
> On Wed, Oct 2, 2013 at 4:58 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> Framebuffers shouldn't be cached and it is usually very uncommon to read
>> them. Therefore, use ioremap_wc() to get significant speed improvements on
>> systems which provide it. On all other systems it's aliased to
>> ioremap_nocache() which is also fine.
>>
>> Reported-by: Tom Gundersen <teg@jklm.no>
>> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>> Tested-by: Tom Gundersen <teg@jklm.no>
>> Tested-by: Alexandre Courbot <acourbot@nvidia.com>
>> Tested-by: Stephen Warren <swarren@wwwdotorg.org>
>> ---
>> drivers/video/simplefb.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
>> index 74b016c..64db54a 100644
>> --- a/drivers/video/simplefb.c
>> +++ b/drivers/video/simplefb.c
>> @@ -219,8 +219,8 @@ static int simplefb_probe(struct platform_device *pdev)
>>
>> info->fbops = &simplefb_ops;
>> info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
>> - info->screen_base = ioremap(info->fix.smem_start,
>> - info->fix.smem_len);
>> + info->screen_base = ioremap_wc(info->fix.smem_start,
>> + info->fix.smem_len);
>> if (!info->screen_base) {
>> framebuffer_release(info);
>> return -ENODEV;
>> --
>> 1.8.4
>>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] simplefb: use write-combined remapping
From: David Herrmann @ 2013-10-30 7:49 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev@vger.kernel.org, Stephen Warren, linux-kernel,
dri-devel@lists.freedesktop.org, Alexandre Courbot,
Jean-Christophe Plagniol-Villard
In-Reply-To: <1380725919-1961-2-git-send-email-dh.herrmann@gmail.com>
Hi Tomi
Ping?
Thanks
David
On Wed, Oct 2, 2013 at 4:58 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> Framebuffers shouldn't be cached and it is usually very uncommon to read
> them. Therefore, use ioremap_wc() to get significant speed improvements on
> systems which provide it. On all other systems it's aliased to
> ioremap_nocache() which is also fine.
>
> Reported-by: Tom Gundersen <teg@jklm.no>
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> Tested-by: Tom Gundersen <teg@jklm.no>
> Tested-by: Alexandre Courbot <acourbot@nvidia.com>
> Tested-by: Stephen Warren <swarren@wwwdotorg.org>
> ---
> drivers/video/simplefb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
> index 74b016c..64db54a 100644
> --- a/drivers/video/simplefb.c
> +++ b/drivers/video/simplefb.c
> @@ -219,8 +219,8 @@ static int simplefb_probe(struct platform_device *pdev)
>
> info->fbops = &simplefb_ops;
> info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
> - info->screen_base = ioremap(info->fix.smem_start,
> - info->fix.smem_len);
> + info->screen_base = ioremap_wc(info->fix.smem_start,
> + info->fix.smem_len);
> if (!info->screen_base) {
> framebuffer_release(info);
> return -ENODEV;
> --
> 1.8.4
>
^ permalink raw reply
* Re: [PATCH 1/2] simplefb: fix unmapping fb during destruction
From: David Herrmann @ 2013-10-30 7:48 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev@vger.kernel.org, Stephen Warren, linux-kernel,
dri-devel@lists.freedesktop.org, Alexandre Courbot,
Jean-Christophe Plagniol-Villard
In-Reply-To: <CANq1E4TuzskdyXVza3YRbR7GmGzHnm9jFmeHmyO2ghuC9u_5WA@mail.gmail.com>
Hi Tomi
Could we get this in -next before the merge-window starts? Stephen
already ack'ed it.
Thanks
David
On Wed, Oct 2, 2013 at 6:23 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> Hi
>
> On Wed, Oct 2, 2013 at 6:16 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 10/02/2013 08:58 AM, David Herrmann wrote:
>>> Unfortunately, fbdev does not create its own "struct device" for
>>> framebuffers. Instead, it attaches to the device of the parent layer. This
>>> has the side-effect that devm_* managed resources are not cleaned up on
>>> framebuffer-destruction but rather during destruction of the
>>> parent-device. In case of fbdev this might be too late, though.
>>> remove_conflicting_framebuffer() may remove fbdev devices but keep the
>>> parent device as it is.
>>>
>>> Therefore, we now use plain ioremap() and unmap the framebuffer in the
>>> fb_destroy() callback. Note that we must not free the device here as this
>>> might race with the parent-device removal. Instead, we rely on
>>> unregister_framebuffer() as barrier and we're safe.
>>
>> So, once the .fb_destroy callback has been executed, there's no other
>> callback to resurrect it? The framebuffer itself is still registered
>> until the device's remove, yet after .fb_destroy, the memory is
>> unmapped, which would be dangerous if the FB can be re-started.
>
> fbdev lifetime tracking is weird.. ->fb_destroy() is called by
> unregister_framebuffer() _after_ it got unlinked. So no, the
> framebuffer is gone and cannot be resurrected. However, the
> unregistered/dead fbdev object itself stays around until you call
> framebuffer_release(). We cannot call it from fb_destroy(), though as
> the platform_data in your platform device still points to the fbdev
> device. Therefore we keep it and wait for the platform-driver to be
> removed which then again calls unregister_framebuffer() (which will
> immediately return as the fbdev device is not registered) and then you
> can finally call framebuffer_release().
>
> Note that even though there's fb_get_info() and fb_put_info(), both
> are not exported and never used. So there is *no* fbdev ref-counting
> (which would be horribly broken anyway) and the driver is the sole
> owner of the fbdev object.
>
>> If that's not an issue, this patch seems fine, so
>> Acked-by: Stephen Warren <swarren@nvidia.com>
>
> Thanks!
>
>>> I know that simplefb was supposed to stay "as simple as possible" but I really
>>> think this series is the last set of fixes I have. Unfortunately framebuffer DRM
>>> handover is mandatory so we cannot ignore it in simplefb.
>>
>> I don't think this patch adds any significant complexity, so I'm not
>> worried at least.
>
> Good to hear!
>
> Thanks
> David
^ permalink raw reply
* Re: [PATCH 1/1] video: exynos_mipi_dsi: Remove unused variable
From: Sachin Kamat @ 2013-10-30 3:24 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1382333533-32740-1-git-send-email-sachin.kamat@linaro.org>
On 30 October 2013 04:30, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Fri, Oct 25, 2013 at 10:51:48AM +0530, Sachin Kamat wrote:
>> On 24 October 2013 21:25, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>> > On Monday 21 October 2013 11:02 AM, Sachin Kamat wrote:
>> >> 'pdev' is not used anymore (Removed vide commit 7e0be9f9 "video:
>> >> exynos_mipi_dsim: Use the generic PHY driver"). Remove it and
>> >> silence the following compilation warning:
>> >> drivers/video/exynos/exynos_mipi_dsi.c:144:26: warning:
>> >> unused variable ‘pdev’ [-Wunused-variable]
>> >>
>> >> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
>> > Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
>>
>> Thanks Kishon.
>>
>> I believe this patch should go through Greg's tree as your other
>> patches are lined up there?
>
> I don't take drivers/video/* patches now, am I?
Actually the patch that introduced this warning is lined up in your
usb-next tree [1]
as part of the phy series patches sent by Kishon. That is the reason I
thought this
one should go though your (usb) tree as well for now. Alternatively we
can wait for
rc-1 and then send it through the video tree if you prefer it that way.
[1] https://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id~0be9f9f7cba3356f75b86737dbe3a005da067e
--
With warm regards,
Sachin
^ permalink raw reply
* Re: [RFC PATCH RESEND] fb: reorder the lock sequence to fix a potential lockdep
From: Gu Zheng @ 2013-10-30 3:18 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD, Tomi Valkeinen
Cc: Linux Fbdev development list, linux-kernel, guz.fnst
In-Reply-To: <526DFDA8.7010806@cn.fujitsu.com>
Hi Tomi, Jean,
How about this patch?
Thanks,
Gu
On 10/28/2013 02:01 PM, Gu Zheng wrote:
> Following commits:
> 50e244cc79 fb: rework locking to fix lock ordering on takeover
> e93a9a8687 fb: Yet another band-aid for fixing lockdep mess
> 054430e773 fbcon: fix locking harder
>
> reworked locking to fix related lock ordering on takeover, and introduced console_lock
> into fbmem, but it seems that the new lock sequence(fb_info->lock ---> console_lock)
> is against with the one in console_callback(console_lock ---> fb_info->lock), and leads to
> a potential deadlock as following:
> [ 601.079000] ===========================
> [ 601.079000] [ INFO: possible circular locking dependency detected ]
> [ 601.079000] 3.11.0 #189 Not tainted
> [ 601.079000] -------------------------------------------------------
> [ 601.079000] kworker/0:3/619 is trying to acquire lock:
> [ 601.079000] (&fb_info->lock){+.+.+.}, at: [<ffffffff81397566>] lock_fb_info+0x26/0x60
> [ 601.079000]
> but task is already holding lock:
> [ 601.079000] (console_lock){+.+.+.}, at: [<ffffffff8141aae3>] console_callback+0x13/0x160
> [ 601.079000]
> which lock already depends on the new lock.
>
> [ 601.079000]
> the existing dependency chain (in reverse order) is:
> [ 601.079000]
> -> #1 (console_lock){+.+.+.}:
> [ 601.079000] [<ffffffff810dc971>] lock_acquire+0xa1/0x140
> [ 601.079000] [<ffffffff810c6267>] console_lock+0x77/0x80
> [ 601.079000] [<ffffffff81399448>] register_framebuffer+0x1d8/0x320
> [ 601.079000] [<ffffffff81cfb4c8>] efifb_probe+0x408/0x48f
> [ 601.079000] [<ffffffff8144a963>] platform_drv_probe+0x43/0x80
> [ 601.079000] [<ffffffff8144853b>] driver_probe_device+0x8b/0x390
> [ 601.079000] [<ffffffff814488eb>] __driver_attach+0xab/0xb0
> [ 601.079000] [<ffffffff814463bd>] bus_for_each_dev+0x5d/0xa0
> [ 601.079000] [<ffffffff81447e6e>] driver_attach+0x1e/0x20
> [ 601.079000] [<ffffffff81447a07>] bus_add_driver+0x117/0x290
> [ 601.079000] [<ffffffff81448fea>] driver_register+0x7a/0x170
> [ 601.079000] [<ffffffff8144a10a>] __platform_driver_register+0x4a/0x50
> [ 601.079000] [<ffffffff8144a12d>] platform_driver_probe+0x1d/0xb0
> [ 601.079000] [<ffffffff81cfb0a1>] efifb_init+0x273/0x292
> [ 601.079000] [<ffffffff81002132>] do_one_initcall+0x102/0x1c0
> [ 601.079000] [<ffffffff81cb80a6>] kernel_init_freeable+0x15d/0x1ef
> [ 601.079000] [<ffffffff8166d2de>] kernel_init+0xe/0xf0
> [ 601.079000] [<ffffffff816914ec>] ret_from_fork+0x7c/0xb0
> [ 601.079000]
> -> #0 (&fb_info->lock){+.+.+.}:
> [ 601.079000] [<ffffffff810dc1d8>] __lock_acquire+0x1e18/0x1f10
> [ 601.079000] [<ffffffff810dc971>] lock_acquire+0xa1/0x140
> [ 601.079000] [<ffffffff816835ca>] mutex_lock_nested+0x7a/0x3b0
> [ 601.079000] [<ffffffff81397566>] lock_fb_info+0x26/0x60
> [ 601.079000] [<ffffffff813a4aeb>] fbcon_blank+0x29b/0x2e0
> [ 601.079000] [<ffffffff81418658>] do_blank_screen+0x1d8/0x280
> [ 601.079000] [<ffffffff8141ab34>] console_callback+0x64/0x160
> [ 601.079000] [<ffffffff8108d855>] process_one_work+0x1f5/0x540
> [ 601.079000] [<ffffffff8108e04c>] worker_thread+0x11c/0x370
> [ 601.079000] [<ffffffff81095fbd>] kthread+0xed/0x100
> [ 601.079000] [<ffffffff816914ec>] ret_from_fork+0x7c/0xb0
> [ 601.079000]
> other info that might help us debug this:
>
> [ 601.079000] Possible unsafe locking scenario:
>
> [ 601.079000] CPU0 CPU1
> [ 601.079000] ---- ----
> [ 601.079000] lock(console_lock);
> [ 601.079000] lock(&fb_info->lock);
> [ 601.079000] lock(console_lock);
> [ 601.079000] lock(&fb_info->lock);
> [ 601.079000]
> *** DEADLOCK ***
>
> so we reorder the lock sequence the same as it in console_callback() to
> avoid this issue.
> Not very sure this change is suitable, any comments is welcome.
>
> Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
> ---
> drivers/video/fbmem.c | 50 +++++++++++++++++++++++++++++++-----------------
> 1 files changed, 32 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index dacaf74..010d191 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1108,14 +1108,16 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
> case FBIOPUT_VSCREENINFO:
> if (copy_from_user(&var, argp, sizeof(var)))
> return -EFAULT;
> - if (!lock_fb_info(info))
> - return -ENODEV;
> console_lock();
> + if (!lock_fb_info(info)) {
> + console_unlock();
> + return -ENODEV;
> + }
> info->flags |= FBINFO_MISC_USEREVENT;
> ret = fb_set_var(info, &var);
> info->flags &= ~FBINFO_MISC_USEREVENT;
> - console_unlock();
> unlock_fb_info(info);
> + console_unlock();
> if (!ret && copy_to_user(argp, &var, sizeof(var)))
> ret = -EFAULT;
> break;
> @@ -1144,12 +1146,14 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
> case FBIOPAN_DISPLAY:
> if (copy_from_user(&var, argp, sizeof(var)))
> return -EFAULT;
> - if (!lock_fb_info(info))
> - return -ENODEV;
> console_lock();
> + if (!lock_fb_info(info)) {
> + console_unlock();
> + return -ENODEV;
> + }
> ret = fb_pan_display(info, &var);
> - console_unlock();
> unlock_fb_info(info);
> + console_unlock();
> if (ret = 0 && copy_to_user(argp, &var, sizeof(var)))
> return -EFAULT;
> break;
> @@ -1184,23 +1188,27 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
> break;
> }
> event.data = &con2fb;
> - if (!lock_fb_info(info))
> - return -ENODEV;
> console_lock();
> + if (!lock_fb_info(info)) {
> + console_unlock();
> + return -ENODEV;
> + }
> event.info = info;
> ret = fb_notifier_call_chain(FB_EVENT_SET_CONSOLE_MAP, &event);
> - console_unlock();
> unlock_fb_info(info);
> + console_unlock();
> break;
> case FBIOBLANK:
> - if (!lock_fb_info(info))
> - return -ENODEV;
> console_lock();
> + if (!lock_fb_info(info)) {
> + console_unlock();
> + return -ENODEV;
> + }
> info->flags |= FBINFO_MISC_USEREVENT;
> ret = fb_blank(info, arg);
> info->flags &= ~FBINFO_MISC_USEREVENT;
> - console_unlock();
> unlock_fb_info(info);
> + console_unlock();
> break;
> default:
> if (!lock_fb_info(info))
> @@ -1660,12 +1668,15 @@ static int do_register_framebuffer(struct fb_info *fb_info)
> registered_fb[i] = fb_info;
>
> event.info = fb_info;
> - if (!lock_fb_info(fb_info))
> - return -ENODEV;
> console_lock();
> + if (!lock_fb_info(fb_info)) {
> + console_unlock();
> + return -ENODEV;
> + }
> +
> fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, &event);
> - console_unlock();
> unlock_fb_info(fb_info);
> + console_unlock();
> return 0;
> }
>
> @@ -1678,13 +1689,16 @@ static int do_unregister_framebuffer(struct fb_info *fb_info)
> if (i < 0 || i >= FB_MAX || registered_fb[i] != fb_info)
> return -EINVAL;
>
> - if (!lock_fb_info(fb_info))
> - return -ENODEV;
> console_lock();
> + if (!lock_fb_info(fb_info)) {
> + console_unlock();
> + return -ENODEV;
> + }
> +
> event.info = fb_info;
> ret = fb_notifier_call_chain(FB_EVENT_FB_UNBIND, &event);
> - console_unlock();
> unlock_fb_info(fb_info);
> + console_unlock();
>
> if (ret)
> return -EINVAL;
^ permalink raw reply
* Re: [PATCH 3/7] video: exynos_mipi_dsim: Use the generic PHY driver
From: Sylwester Nawrocki @ 2013-10-30 0:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <526F7412.60004@samsung.com>
On 10/29/2013 09:38 AM, Donghwa Lee wrote:
> On Tue, OCT 28, 2013 21:24, Tomasz Figa wrote:
>> On Monday 28 of October 2013 15:12:08 Donghwa Lee wrote:
[...]
>> First of all, the exynos_mipi_dsim driver has currently no users in
>> mainline kernel, so it is essentially dead code. In addition, on
>> a platform that is the primary candidate for using it, which is Exynos,
>> there is no way to use it, due to no DT support.
>
> As I mentioned above, patches are submitted sometimes and I will update
> this driver as soon as possible to support DT.
>
>> As for the driver itself, it is not really a great example of good code.
>> It contains a hacks, like calling msleep() without any clear reason and
>> also many coding style issues. I'd prefer to replace it with the new
>> exynos-dsi driver rewritten completely in SRPOL, when CDF is finished.
>
> Yes, I know this drivers had been changed about only minor issues and
> it is not really good code style. And CDF is more good and light.
> But discussion for CDF is still remaining a kind of requests. If it is merged
> into linux kernel and many users use it, existing MIPI DSI drivers will be
> replaced with the new drivers naturally, isn't it?
Not necessarily. Our goal should be to have fairly stable DT binding at the
SoC side so all available panels can possibly be used with any SoC without
problems.
Then please refrain for a while from pushing entirely vendor specific DT
bindings upstream. Let's focus instead on an as much as possible common
framework and the DT bindings. Whether the CDF will be part of DRM or not
the DT bindings are supposed to be generic, so they work with whatever
driver architecture.
I guess you could try to come up with an unstable DT binding for the
MIPI DSIM and display panels it is used with, but at this stage it seems
just a waste of time.
If there were no SoC specific panel drivers in the kernel there would be
now much less trouble with DT support.
--
Thanks,
Sylwester
^ permalink raw reply
* Re: [PATCH 1/1] video: exynos_mipi_dsi: Remove unused variable
From: Greg Kroah-Hartman @ 2013-10-29 23:00 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1382333533-32740-1-git-send-email-sachin.kamat@linaro.org>
On Fri, Oct 25, 2013 at 10:51:48AM +0530, Sachin Kamat wrote:
> On 24 October 2013 21:25, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> > On Monday 21 October 2013 11:02 AM, Sachin Kamat wrote:
> >> 'pdev' is not used anymore (Removed vide commit 7e0be9f9 "video:
> >> exynos_mipi_dsim: Use the generic PHY driver"). Remove it and
> >> silence the following compilation warning:
> >> drivers/video/exynos/exynos_mipi_dsi.c:144:26: warning:
> >> unused variable ‘pdev’ [-Wunused-variable]
> >>
> >> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> > Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
>
> Thanks Kishon.
>
> I believe this patch should go through Greg's tree as your other
> patches are lined up there?
I don't take drivers/video/* patches now, am I?
greg k-h
^ permalink raw reply
* [PATCH v2 19/19] fbdev: sh-mobile-lcdcfb: Enable the driver on all ARM platforms
From: Laurent Pinchart @ 2013-10-29 22:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1383086274-11049-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Renesas ARM platforms are transitioning from single-platform to
multi-platform kernels using the new ARCH_SHMOBILE_MULTI. Make the
driver available on all ARM platforms to enable it on both ARCH_SHMOBILE
and ARCH_SHMOBILE_MULTI, and increase build testing coverage with
COMPILE_TEST.
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
drivers/video/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 84b685f..32b5c86 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -10,7 +10,7 @@ config HAVE_FB_ATMEL
config SH_MIPI_DSI
tristate
- depends on (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
+ depends on (SUPERH || ARM || COMPILE_TEST) && HAVE_CLK
config SH_LCD_MIPI_DSI
bool
@@ -1995,7 +1995,7 @@ config FB_W100
config FB_SH_MOBILE_LCDC
tristate "SuperH Mobile LCDC framebuffer support"
- depends on FB && (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
+ depends on FB && (SUPERH || ARM || COMPILE_TEST) && HAVE_CLK
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
@@ -2482,7 +2482,7 @@ endif
config FB_SH_MOBILE_MERAM
tristate "SuperH Mobile MERAM read ahead support"
- depends on (SUPERH || ARCH_SHMOBILE)
+ depends on (SUPERH || ARM || COMPILE_TEST)
select GENERIC_ALLOCATOR
---help---
Enable MERAM support for the SuperH controller.
--
1.8.1.5
^ permalink raw reply related
* [PATCH v3] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
From: Marek Belisko @ 2013-10-29 22:25 UTC (permalink / raw)
To: tomi.valkeinen, plagnioj
Cc: hns, linux-kernel, linux-omap, linux-fbdev, Marek Belisko
Signed-off-by: Marek Belisko <marek@goldelico.com>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
changes from v2:
- move tx_buf from driver data to functions where it's used
- update write functions names (to reflect how many bytes are transferred)
- update delays from 1s to 1ms (probably typo)
- remove unnecessary 90ms sleep (tested and works fine)
- disable dpi output after disable panel
changes from v1:
- reworked to be spi driver instead platform with custom spi bitbang
this configuration was tested with spi_gpio bitbang driver on gta04 board
and works fine (thanks Tomi and Lars-Peter for comments)
- address previous comments
drivers/video/omap2/displays-new/Kconfig | 6 +
drivers/video/omap2/displays-new/Makefile | 1 +
.../omap2/displays-new/panel-tpo-td028ttec1.c | 480 +++++++++++++++++++++
include/video/omap-panel-data.h | 13 +
4 files changed, 500 insertions(+)
create mode 100644 drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
diff --git a/drivers/video/omap2/displays-new/Kconfig b/drivers/video/omap2/displays-new/Kconfig
index 10b25e7..e6cfc38 100644
--- a/drivers/video/omap2/displays-new/Kconfig
+++ b/drivers/video/omap2/displays-new/Kconfig
@@ -57,6 +57,12 @@ config DISPLAY_PANEL_SHARP_LS037V7DW01
help
LCD Panel used in TI's SDP3430 and EVM boards
+config DISPLAY_PANEL_TPO_TD028TTEC1
+ tristate "TPO TD028TTEC1 LCD Panel"
+ depends on SPI
+ help
+ LCD panel used in Openmoko.
+
config DISPLAY_PANEL_TPO_TD043MTEA1
tristate "TPO TD043MTEA1 LCD Panel"
depends on SPI
diff --git a/drivers/video/omap2/displays-new/Makefile b/drivers/video/omap2/displays-new/Makefile
index 5aeb11b..0323a8a 100644
--- a/drivers/video/omap2/displays-new/Makefile
+++ b/drivers/video/omap2/displays-new/Makefile
@@ -8,5 +8,6 @@ obj-$(CONFIG_DISPLAY_PANEL_DSI_CM) += panel-dsi-cm.o
obj-$(CONFIG_DISPLAY_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
obj-$(CONFIG_DISPLAY_PANEL_LGPHILIPS_LB035Q02) += panel-lgphilips-lb035q02.o
obj-$(CONFIG_DISPLAY_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
+obj-$(CONFIG_DISPLAY_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DISPLAY_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DISPLAY_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
diff --git a/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c b/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
new file mode 100644
index 0000000..ca77721
--- /dev/null
+++ b/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
@@ -0,0 +1,480 @@
+/*
+ * Toppoly TD028TTEC1 panel support
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen <tomi.valkeinen@nokia.com>
+ *
+ * Neo 1973 code (jbt6k74.c):
+ * Copyright (C) 2006-2007 by OpenMoko, Inc.
+ * Author: Harald Welte <laforge@openmoko.org>
+ *
+ * Ported and adapted from Neo 1973 U-Boot by:
+ * H. Nikolaus Schaller <hns@goldelico.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/spi/spi.h>
+#include <linux/gpio.h>
+#include <video/omapdss.h>
+#include <video/omap-panel-data.h>
+
+struct panel_drv_data {
+ struct omap_dss_device dssdev;
+ struct omap_dss_device *in;
+
+ int data_lines;
+
+ struct omap_video_timings videomode;
+
+ struct spi_device *spi_dev;
+};
+
+static struct omap_video_timings td028ttec1_panel_timings = {
+ .x_res = 480,
+ .y_res = 640,
+ .pixel_clock = 22153,
+ .hfp = 24,
+ .hsw = 8,
+ .hbp = 8,
+ .vfp = 4,
+ .vsw = 2,
+ .vbp = 2,
+
+ .vsync_level = OMAPDSS_SIG_ACTIVE_LOW,
+ .hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
+
+ .data_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
+ .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
+ .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
+};
+
+#define JBT_COMMAND 0x000
+#define JBT_DATA 0x100
+
+int jbt_ret_write_0(struct panel_drv_data *ddata, u8 reg)
+{
+ int rc;
+ u16 tx_buf = JBT_COMMAND | reg;
+
+ rc = spi_write(ddata->spi_dev, (u8 *)&tx_buf,
+ 1*sizeof(u16));
+ if (rc != 0)
+ dev_err(&ddata->spi_dev->dev,
+ "jbt_ret_write_0 spi_write ret %d\n", rc);
+
+ return rc;
+}
+
+int jbt_reg_write_1(struct panel_drv_data *ddata, u8 reg, u8 data)
+{
+ int rc;
+ u16 tx_buf[2];
+
+ tx_buf[0] = JBT_COMMAND | reg;
+ tx_buf[1] = JBT_DATA | data;
+ rc = spi_write(ddata->spi_dev, (u8 *)tx_buf,
+ 2*sizeof(u16));
+ if (rc != 0)
+ dev_err(&ddata->spi_dev->dev,
+ "jbt_reg_write_1 spi_write ret %d\n", rc);
+
+ return rc;
+}
+
+int jbt_reg_write_2(struct panel_drv_data *ddata, u8 reg, u16 data)
+{
+ int rc;
+ u16 tx_buf[3];
+
+ tx_buf[0] = JBT_COMMAND | reg;
+ tx_buf[1] = JBT_DATA | (data >> 8);
+ tx_buf[2] = JBT_DATA | (data & 0xff);
+
+ rc = spi_write(ddata->spi_dev, (u8 *)tx_buf,
+ 3*sizeof(u16));
+
+ if (rc != 0)
+ dev_err(&ddata->spi_dev->dev,
+ "jbt_reg_write_2 spi_write ret %d\n", rc);
+
+ return rc;
+}
+
+enum jbt_register {
+ JBT_REG_SLEEP_IN = 0x10,
+ JBT_REG_SLEEP_OUT = 0x11,
+
+ JBT_REG_DISPLAY_OFF = 0x28,
+ JBT_REG_DISPLAY_ON = 0x29,
+
+ JBT_REG_RGB_FORMAT = 0x3a,
+ JBT_REG_QUAD_RATE = 0x3b,
+
+ JBT_REG_POWER_ON_OFF = 0xb0,
+ JBT_REG_BOOSTER_OP = 0xb1,
+ JBT_REG_BOOSTER_MODE = 0xb2,
+ JBT_REG_BOOSTER_FREQ = 0xb3,
+ JBT_REG_OPAMP_SYSCLK = 0xb4,
+ JBT_REG_VSC_VOLTAGE = 0xb5,
+ JBT_REG_VCOM_VOLTAGE = 0xb6,
+ JBT_REG_EXT_DISPL = 0xb7,
+ JBT_REG_OUTPUT_CONTROL = 0xb8,
+ JBT_REG_DCCLK_DCEV = 0xb9,
+ JBT_REG_DISPLAY_MODE1 = 0xba,
+ JBT_REG_DISPLAY_MODE2 = 0xbb,
+ JBT_REG_DISPLAY_MODE = 0xbc,
+ JBT_REG_ASW_SLEW = 0xbd,
+ JBT_REG_DUMMY_DISPLAY = 0xbe,
+ JBT_REG_DRIVE_SYSTEM = 0xbf,
+
+ JBT_REG_SLEEP_OUT_FR_A = 0xc0,
+ JBT_REG_SLEEP_OUT_FR_B = 0xc1,
+ JBT_REG_SLEEP_OUT_FR_C = 0xc2,
+ JBT_REG_SLEEP_IN_LCCNT_D = 0xc3,
+ JBT_REG_SLEEP_IN_LCCNT_E = 0xc4,
+ JBT_REG_SLEEP_IN_LCCNT_F = 0xc5,
+ JBT_REG_SLEEP_IN_LCCNT_G = 0xc6,
+
+ JBT_REG_GAMMA1_FINE_1 = 0xc7,
+ JBT_REG_GAMMA1_FINE_2 = 0xc8,
+ JBT_REG_GAMMA1_INCLINATION = 0xc9,
+ JBT_REG_GAMMA1_BLUE_OFFSET = 0xca,
+
+ JBT_REG_BLANK_CONTROL = 0xcf,
+ JBT_REG_BLANK_TH_TV = 0xd0,
+ JBT_REG_CKV_ON_OFF = 0xd1,
+ JBT_REG_CKV_1_2 = 0xd2,
+ JBT_REG_OEV_TIMING = 0xd3,
+ JBT_REG_ASW_TIMING_1 = 0xd4,
+ JBT_REG_ASW_TIMING_2 = 0xd5,
+
+ JBT_REG_HCLOCK_VGA = 0xec,
+ JBT_REG_HCLOCK_QVGA = 0xed,
+};
+
+#define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
+
+static int td028ttec1_panel_connect(struct omap_dss_device *dssdev)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+ int r;
+
+ if (omapdss_device_is_connected(dssdev))
+ return 0;
+
+ r = in->ops.dpi->connect(in, dssdev);
+ if (r)
+ return r;
+
+ return 0;
+}
+
+static void td028ttec1_panel_disconnect(struct omap_dss_device *dssdev)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+
+ if (!omapdss_device_is_connected(dssdev))
+ return;
+
+ in->ops.dpi->disconnect(in, dssdev);
+}
+
+static int td028ttec1_panel_enable(struct omap_dss_device *dssdev)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+ int r;
+
+ if (!omapdss_device_is_connected(dssdev))
+ return -ENODEV;
+
+ if (omapdss_device_is_enabled(dssdev))
+ return 0;
+
+ in->ops.dpi->set_data_lines(in, ddata->data_lines);
+ in->ops.dpi->set_timings(in, &ddata->videomode);
+
+ r = in->ops.dpi->enable(in);
+ if (r)
+ return r;
+
+ dev_dbg(dssdev->dev, "td028ttec1_panel_enable() - state %d\n",
+ dssdev->state);
+
+ /* three times command zero */
+ r |= jbt_ret_write_0(ddata, 0x00);
+ usleep_range(1000, 2000);
+ r |= jbt_ret_write_0(ddata, 0x00);
+ usleep_range(1000, 2000);
+ r |= jbt_ret_write_0(ddata, 0x00);
+ usleep_range(1000, 2000);
+
+ if (r) {
+ dev_warn(dssdev->dev, "transfer error\n");
+ goto transfer_err;
+ }
+
+ /* deep standby out */
+ r |= jbt_reg_write_1(ddata, JBT_REG_POWER_ON_OFF, 0x17);
+
+ /* RGB I/F on, RAM write off, QVGA through, SIGCON enable */
+ r |= jbt_reg_write_1(ddata, JBT_REG_DISPLAY_MODE, 0x80);
+
+ /* Quad mode off */
+ r |= jbt_reg_write_1(ddata, JBT_REG_QUAD_RATE, 0x00);
+
+ /* AVDD on, XVDD on */
+ r |= jbt_reg_write_1(ddata, JBT_REG_POWER_ON_OFF, 0x16);
+
+ /* Output control */
+ r |= jbt_reg_write_2(ddata, JBT_REG_OUTPUT_CONTROL, 0xfff9);
+
+ /* Sleep mode off */
+ r |= jbt_ret_write_0(ddata, JBT_REG_SLEEP_OUT);
+
+ /* at this point we have like 50% grey */
+
+ /* initialize register set */
+ r |= jbt_reg_write_1(ddata, JBT_REG_DISPLAY_MODE1, 0x01);
+ r |= jbt_reg_write_1(ddata, JBT_REG_DISPLAY_MODE2, 0x00);
+ r |= jbt_reg_write_1(ddata, JBT_REG_RGB_FORMAT, 0x60);
+ r |= jbt_reg_write_1(ddata, JBT_REG_DRIVE_SYSTEM, 0x10);
+ r |= jbt_reg_write_1(ddata, JBT_REG_BOOSTER_OP, 0x56);
+ r |= jbt_reg_write_1(ddata, JBT_REG_BOOSTER_MODE, 0x33);
+ r |= jbt_reg_write_1(ddata, JBT_REG_BOOSTER_FREQ, 0x11);
+ r |= jbt_reg_write_1(ddata, JBT_REG_BOOSTER_FREQ, 0x11);
+ r |= jbt_reg_write_1(ddata, JBT_REG_OPAMP_SYSCLK, 0x02);
+ r |= jbt_reg_write_1(ddata, JBT_REG_VSC_VOLTAGE, 0x2b);
+ r |= jbt_reg_write_1(ddata, JBT_REG_VCOM_VOLTAGE, 0x40);
+ r |= jbt_reg_write_1(ddata, JBT_REG_EXT_DISPL, 0x03);
+ r |= jbt_reg_write_1(ddata, JBT_REG_DCCLK_DCEV, 0x04);
+ /*
+ * default of 0x02 in JBT_REG_ASW_SLEW responsible for 72Hz requirement
+ * to avoid red / blue flicker
+ */
+ r |= jbt_reg_write_1(ddata, JBT_REG_ASW_SLEW, 0x04);
+ r |= jbt_reg_write_1(ddata, JBT_REG_DUMMY_DISPLAY, 0x00);
+
+ r |= jbt_reg_write_1(ddata, JBT_REG_SLEEP_OUT_FR_A, 0x11);
+ r |= jbt_reg_write_1(ddata, JBT_REG_SLEEP_OUT_FR_B, 0x11);
+ r |= jbt_reg_write_1(ddata, JBT_REG_SLEEP_OUT_FR_C, 0x11);
+ r |= jbt_reg_write_2(ddata, JBT_REG_SLEEP_IN_LCCNT_D, 0x2040);
+ r |= jbt_reg_write_2(ddata, JBT_REG_SLEEP_IN_LCCNT_E, 0x60c0);
+ r |= jbt_reg_write_2(ddata, JBT_REG_SLEEP_IN_LCCNT_F, 0x1020);
+ r |= jbt_reg_write_2(ddata, JBT_REG_SLEEP_IN_LCCNT_G, 0x60c0);
+
+ r |= jbt_reg_write_2(ddata, JBT_REG_GAMMA1_FINE_1, 0x5533);
+ r |= jbt_reg_write_1(ddata, JBT_REG_GAMMA1_FINE_2, 0x00);
+ r |= jbt_reg_write_1(ddata, JBT_REG_GAMMA1_INCLINATION, 0x00);
+ r |= jbt_reg_write_1(ddata, JBT_REG_GAMMA1_BLUE_OFFSET, 0x00);
+
+ r |= jbt_reg_write_2(ddata, JBT_REG_HCLOCK_VGA, 0x1f0);
+ r |= jbt_reg_write_1(ddata, JBT_REG_BLANK_CONTROL, 0x02);
+ r |= jbt_reg_write_2(ddata, JBT_REG_BLANK_TH_TV, 0x0804);
+
+ r |= jbt_reg_write_1(ddata, JBT_REG_CKV_ON_OFF, 0x01);
+ r |= jbt_reg_write_2(ddata, JBT_REG_CKV_1_2, 0x0000);
+
+ r |= jbt_reg_write_2(ddata, JBT_REG_OEV_TIMING, 0x0d0e);
+ r |= jbt_reg_write_2(ddata, JBT_REG_ASW_TIMING_1, 0x11a4);
+ r |= jbt_reg_write_1(ddata, JBT_REG_ASW_TIMING_2, 0x0e);
+
+ r |= jbt_ret_write_0(ddata, JBT_REG_DISPLAY_ON);
+
+ dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
+
+transfer_err:
+
+ return r ? -EIO : 0;
+}
+
+static void td028ttec1_panel_disable(struct omap_dss_device *dssdev)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+
+ if (!omapdss_device_is_enabled(dssdev))
+ return;
+
+ dev_dbg(dssdev->dev, "td028ttec1_panel_disable()\n");
+
+ jbt_ret_write_0(ddata, JBT_REG_DISPLAY_OFF);
+ jbt_reg_write_2(ddata, JBT_REG_OUTPUT_CONTROL, 0x8002);
+ jbt_ret_write_0(ddata, JBT_REG_SLEEP_IN);
+ jbt_reg_write_1(ddata, JBT_REG_POWER_ON_OFF, 0x00);
+
+ in->ops.dpi->disable(in);
+
+ dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
+}
+
+static void td028ttec1_panel_set_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+
+ ddata->videomode = *timings;
+ dssdev->panel.timings = *timings;
+
+ in->ops.dpi->set_timings(in, timings);
+}
+
+static void td028ttec1_panel_get_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+
+ *timings = ddata->videomode;
+}
+
+static int td028ttec1_panel_check_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata->in;
+
+ return in->ops.dpi->check_timings(in, timings);
+}
+
+static struct omap_dss_driver td028ttec1_ops = {
+ .connect = td028ttec1_panel_connect,
+ .disconnect = td028ttec1_panel_disconnect,
+
+ .enable = td028ttec1_panel_enable,
+ .disable = td028ttec1_panel_disable,
+
+ .set_timings = td028ttec1_panel_set_timings,
+ .get_timings = td028ttec1_panel_get_timings,
+ .check_timings = td028ttec1_panel_check_timings,
+};
+
+static int td028ttec1_panel_probe_pdata(struct spi_device *spi)
+{
+ const struct panel_tpo_td028ttec1_platform_data *pdata;
+ struct panel_drv_data *ddata = dev_get_drvdata(&spi->dev);
+ struct omap_dss_device *dssdev, *in;
+
+ pdata = dev_get_platdata(&spi->dev);
+
+ in = omap_dss_find_output(pdata->source);
+ if (in = NULL) {
+ dev_err(&spi->dev, "failed to find video source '%s'\n",
+ pdata->source);
+ return -EPROBE_DEFER;
+ }
+
+ ddata->in = in;
+
+ ddata->data_lines = pdata->data_lines;
+
+ dssdev = &ddata->dssdev;
+ dssdev->name = pdata->name;
+
+ return 0;
+}
+
+static int td028ttec1_panel_probe(struct spi_device *spi)
+{
+ struct panel_drv_data *ddata;
+ struct omap_dss_device *dssdev;
+ int r;
+
+ dev_dbg(&spi->dev, "%s\n", __func__);
+
+ spi->bits_per_word = 9;
+ spi->mode = SPI_MODE_3;
+
+ r = spi_setup(spi);
+ if (r < 0) {
+ dev_err(&spi->dev, "spi_setup failed: %d\n", r);
+ return r;
+ }
+
+ ddata = devm_kzalloc(&spi->dev, sizeof(*ddata), GFP_KERNEL);
+ if (ddata = NULL)
+ return -ENOMEM;
+
+ dev_set_drvdata(&spi->dev, ddata);
+
+ ddata->spi_dev = spi;
+
+ if (dev_get_platdata(&spi->dev)) {
+ r = td028ttec1_panel_probe_pdata(spi);
+ if (r)
+ return r;
+ } else {
+ return -ENODEV;
+ }
+
+ ddata->videomode = td028ttec1_panel_timings;
+
+ dssdev = &ddata->dssdev;
+ dssdev->dev = &spi->dev;
+ dssdev->driver = &td028ttec1_ops;
+ dssdev->type = OMAP_DISPLAY_TYPE_DPI;
+ dssdev->owner = THIS_MODULE;
+ dssdev->panel.timings = ddata->videomode;
+ dssdev->phy.dpi.data_lines = ddata->data_lines;
+
+ r = omapdss_register_display(dssdev);
+ if (r) {
+ dev_err(&spi->dev, "Failed to register panel\n");
+ goto err_reg;
+ }
+
+ return 0;
+
+err_reg:
+ omap_dss_put_device(ddata->in);
+ return r;
+}
+
+static int td028ttec1_panel_remove(struct spi_device *spi)
+{
+ struct panel_drv_data *ddata = dev_get_drvdata(&spi->dev);
+ struct omap_dss_device *dssdev = &ddata->dssdev;
+ struct omap_dss_device *in = ddata->in;
+
+ dev_dbg(&ddata->spi_dev->dev, "%s\n", __func__);
+
+ omapdss_unregister_display(dssdev);
+
+ td028ttec1_panel_disable(dssdev);
+ td028ttec1_panel_disconnect(dssdev);
+
+ omap_dss_put_device(in);
+
+ return 0;
+}
+
+static struct spi_driver td028ttec1_spi_driver = {
+ .probe = td028ttec1_panel_probe,
+ .remove = td028ttec1_panel_remove,
+
+ .driver = {
+ .name = "panel-tpo-td028ttec1",
+ .owner = THIS_MODULE,
+ },
+};
+
+module_spi_driver(td028ttec1_spi_driver);
+
+MODULE_AUTHOR("H. Nikolaus Schaller <hns@goldelico.com>");
+MODULE_DESCRIPTION("Toppoly TD028TTEC1 panel driver");
+MODULE_LICENSE("GPL");
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index f7ac8d9..69279c0 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -238,4 +238,17 @@ struct panel_nec_nl8048hl11_platform_data {
int qvga_gpio;
};
+/**
+ * panel-tpo-td028ttec1 platform data
+ * @name: name for display entity
+ * @source: name of the display entity used as a video source
+ * @data_lines: number of DPI datalines
+ */
+struct panel_tpo_td028ttec1_platform_data {
+ const char *name;
+ const char *source;
+
+ int data_lines;
+};
+
#endif /* __OMAP_PANEL_DATA_H */
--
1.8.1.2
^ permalink raw reply related
* [PATCH v2 9/9] backlight: atmel-pwm-bl: use gpio_request_one
From: Johan Hovold @ 2013-10-29 16:27 UTC (permalink / raw)
To: Richard Purdie, Jingoo Han
Cc: Nicolas Ferre, Tomi Valkeinen, Jean-Christophe Plagniol-Villard,
Andrew Morton, linux-fbdev, linux-kernel, Johan Hovold
In-Reply-To: <1383064064-4983-1-git-send-email-jhovold@gmail.com>
Use devm_gpio_request_one rather than requesting and setting direction
in two calls.
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
drivers/video/backlight/atmel-pwm-bl.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/video/backlight/atmel-pwm-bl.c b/drivers/video/backlight/atmel-pwm-bl.c
index bd1ed34..03b5f3b 100644
--- a/drivers/video/backlight/atmel-pwm-bl.c
+++ b/drivers/video/backlight/atmel-pwm-bl.c
@@ -124,6 +124,7 @@ static int atmel_pwm_bl_probe(struct platform_device *pdev)
const struct atmel_pwm_bl_platform_data *pdata;
struct backlight_device *bldev;
struct atmel_pwm_bl *pwmbl;
+ int flags;
int retval;
pdata = dev_get_platdata(&pdev->dev);
@@ -149,14 +150,14 @@ static int atmel_pwm_bl_probe(struct platform_device *pdev)
return retval;
if (gpio_is_valid(pwmbl->gpio_on)) {
- retval = devm_gpio_request(&pdev->dev, pwmbl->gpio_on,
- "gpio_atmel_pwm_bl");
- if (retval)
- goto err_free_pwm;
-
/* Turn display off by default. */
- retval = gpio_direction_output(pwmbl->gpio_on,
- 0 ^ pdata->on_active_low);
+ if (pdata->on_active_low)
+ flags = GPIOF_OUT_INIT_HIGH;
+ else
+ flags = GPIOF_OUT_INIT_LOW;
+
+ retval = devm_gpio_request_one(&pdev->dev, pwmbl->gpio_on,
+ flags, "gpio_atmel_pwm_bl");
if (retval)
goto err_free_pwm;
}
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 8/9] backlight: atmel-pwm-bl: refactor gpio_on handling
From: Johan Hovold @ 2013-10-29 16:27 UTC (permalink / raw)
To: Richard Purdie, Jingoo Han
Cc: Nicolas Ferre, Tomi Valkeinen, Jean-Christophe Plagniol-Villard,
Andrew Morton, linux-fbdev, linux-kernel, Johan Hovold
In-Reply-To: <1383064064-4983-1-git-send-email-jhovold@gmail.com>
Add helper function to control the gpio_on signal.
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
drivers/video/backlight/atmel-pwm-bl.c | 23 +++++++++++------------
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/video/backlight/atmel-pwm-bl.c b/drivers/video/backlight/atmel-pwm-bl.c
index c254209..bd1ed34 100644
--- a/drivers/video/backlight/atmel-pwm-bl.c
+++ b/drivers/video/backlight/atmel-pwm-bl.c
@@ -26,6 +26,14 @@ struct atmel_pwm_bl {
int gpio_on;
};
+static void atmel_pwm_bl_set_gpio_on(struct atmel_pwm_bl *pwmbl, int on)
+{
+ if (!gpio_is_valid(pwmbl->gpio_on))
+ return;
+
+ gpio_set_value(pwmbl->gpio_on, on ^ pwmbl->pdata->on_active_low);
+}
+
static int atmel_pwm_bl_set_intensity(struct backlight_device *bd)
{
struct atmel_pwm_bl *pwmbl = bl_get_data(bd);
@@ -48,19 +56,13 @@ static int atmel_pwm_bl_set_intensity(struct backlight_device *bd)
pwm_duty = pwmbl->pdata->pwm_duty_min;
if (!intensity) {
- if (gpio_is_valid(pwmbl->gpio_on)) {
- gpio_set_value(pwmbl->gpio_on,
- 0 ^ pwmbl->pdata->on_active_low);
- }
+ atmel_pwm_bl_set_gpio_on(pwmbl, 0);
pwm_channel_writel(&pwmbl->pwmc, PWM_CUPD, pwm_duty);
pwm_channel_disable(&pwmbl->pwmc);
} else {
pwm_channel_enable(&pwmbl->pwmc);
pwm_channel_writel(&pwmbl->pwmc, PWM_CUPD, pwm_duty);
- if (gpio_is_valid(pwmbl->gpio_on)) {
- gpio_set_value(pwmbl->gpio_on,
- 1 ^ pwmbl->pdata->on_active_low);
- }
+ atmel_pwm_bl_set_gpio_on(pwmbl, 1);
}
return 0;
@@ -196,10 +198,7 @@ static int atmel_pwm_bl_remove(struct platform_device *pdev)
{
struct atmel_pwm_bl *pwmbl = platform_get_drvdata(pdev);
- if (gpio_is_valid(pwmbl->gpio_on)) {
- gpio_set_value(pwmbl->gpio_on,
- 0 ^ pwmbl->pdata->on_active_low);
- }
+ atmel_pwm_bl_set_gpio_on(pwmbl, 0);
pwm_channel_disable(&pwmbl->pwmc);
pwm_channel_free(&pwmbl->pwmc);
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 7/9] backlight: atmel-pwm-bl: use gpio_is_valid
From: Johan Hovold @ 2013-10-29 16:27 UTC (permalink / raw)
To: Richard Purdie, Jingoo Han
Cc: Nicolas Ferre, Tomi Valkeinen, Jean-Christophe Plagniol-Villard,
Andrew Morton, linux-fbdev, linux-kernel, Johan Hovold
In-Reply-To: <1383064064-4983-1-git-send-email-jhovold@gmail.com>
Use gpio_is_valid rather than open coding the more restrictive != -1
test.
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
drivers/video/backlight/atmel-pwm-bl.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/atmel-pwm-bl.c b/drivers/video/backlight/atmel-pwm-bl.c
index bfd6a96..c254209 100644
--- a/drivers/video/backlight/atmel-pwm-bl.c
+++ b/drivers/video/backlight/atmel-pwm-bl.c
@@ -48,7 +48,7 @@ static int atmel_pwm_bl_set_intensity(struct backlight_device *bd)
pwm_duty = pwmbl->pdata->pwm_duty_min;
if (!intensity) {
- if (pwmbl->gpio_on != -1) {
+ if (gpio_is_valid(pwmbl->gpio_on)) {
gpio_set_value(pwmbl->gpio_on,
0 ^ pwmbl->pdata->on_active_low);
}
@@ -57,7 +57,7 @@ static int atmel_pwm_bl_set_intensity(struct backlight_device *bd)
} else {
pwm_channel_enable(&pwmbl->pwmc);
pwm_channel_writel(&pwmbl->pwmc, PWM_CUPD, pwm_duty);
- if (pwmbl->gpio_on != -1) {
+ if (gpio_is_valid(pwmbl->gpio_on)) {
gpio_set_value(pwmbl->gpio_on,
1 ^ pwmbl->pdata->on_active_low);
}
@@ -146,7 +146,7 @@ static int atmel_pwm_bl_probe(struct platform_device *pdev)
if (retval)
return retval;
- if (pwmbl->gpio_on != -1) {
+ if (gpio_is_valid(pwmbl->gpio_on)) {
retval = devm_gpio_request(&pdev->dev, pwmbl->gpio_on,
"gpio_atmel_pwm_bl");
if (retval)
@@ -196,7 +196,7 @@ static int atmel_pwm_bl_remove(struct platform_device *pdev)
{
struct atmel_pwm_bl *pwmbl = platform_get_drvdata(pdev);
- if (pwmbl->gpio_on != -1) {
+ if (gpio_is_valid(pwmbl->gpio_on)) {
gpio_set_value(pwmbl->gpio_on,
0 ^ pwmbl->pdata->on_active_low);
}
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 6/9] backlight: atmel-pwm-bl: remove unused include
From: Johan Hovold @ 2013-10-29 16:27 UTC (permalink / raw)
To: Richard Purdie, Jingoo Han
Cc: Nicolas Ferre, Tomi Valkeinen, Jean-Christophe Plagniol-Villard,
Andrew Morton, linux-fbdev, linux-kernel, Johan Hovold
In-Reply-To: <1383064064-4983-1-git-send-email-jhovold@gmail.com>
Remove unused include of clk.h.
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
drivers/video/backlight/atmel-pwm-bl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/backlight/atmel-pwm-bl.c b/drivers/video/backlight/atmel-pwm-bl.c
index abfaada..bfd6a96 100644
--- a/drivers/video/backlight/atmel-pwm-bl.c
+++ b/drivers/video/backlight/atmel-pwm-bl.c
@@ -12,7 +12,6 @@
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/fb.h>
-#include <linux/clk.h>
#include <linux/gpio.h>
#include <linux/backlight.h>
#include <linux/atmel_pwm.h>
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 5/9] backlight: atmel-pwm-bl: clean up get_intensity
From: Johan Hovold @ 2013-10-29 16:27 UTC (permalink / raw)
To: Richard Purdie, Jingoo Han
Cc: Nicolas Ferre, Tomi Valkeinen, Jean-Christophe Plagniol-Villard,
Andrew Morton, linux-fbdev, linux-kernel, Johan Hovold
In-Reply-To: <1383064064-4983-1-git-send-email-jhovold@gmail.com>
Clean up get_intensity to increase readability.
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
drivers/video/backlight/atmel-pwm-bl.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/video/backlight/atmel-pwm-bl.c b/drivers/video/backlight/atmel-pwm-bl.c
index 01af5c2..abfaada 100644
--- a/drivers/video/backlight/atmel-pwm-bl.c
+++ b/drivers/video/backlight/atmel-pwm-bl.c
@@ -70,15 +70,14 @@ static int atmel_pwm_bl_set_intensity(struct backlight_device *bd)
static int atmel_pwm_bl_get_intensity(struct backlight_device *bd)
{
struct atmel_pwm_bl *pwmbl = bl_get_data(bd);
+ u32 cdty;
u32 intensity;
- if (pwmbl->pdata->pwm_active_low) {
- intensity = pwm_channel_readl(&pwmbl->pwmc, PWM_CDTY) -
- pwmbl->pdata->pwm_duty_min;
- } else {
- intensity = pwmbl->pdata->pwm_duty_max -
- pwm_channel_readl(&pwmbl->pwmc, PWM_CDTY);
- }
+ cdty = pwm_channel_readl(&pwmbl->pwmc, PWM_CDTY);
+ if (pwmbl->pdata->pwm_active_low)
+ intensity = cdty - pwmbl->pdata->pwm_duty_min;
+ else
+ intensity = pwmbl->pdata->pwm_duty_max - cdty;
return intensity & 0xffff;
}
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 4/9] backlight: atmel-pwm-bl: clean up probe error handling
From: Johan Hovold @ 2013-10-29 16:27 UTC (permalink / raw)
To: Richard Purdie, Jingoo Han
Cc: Nicolas Ferre, Tomi Valkeinen, Jean-Christophe Plagniol-Villard,
Andrew Morton, linux-fbdev, linux-kernel, Johan Hovold
In-Reply-To: <1383064064-4983-1-git-send-email-jhovold@gmail.com>
Clean up probe error handling by checking parameters before any
allocations and removing an obsolete error label. Also remove
unnecessary reset of private gpio number.
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
drivers/video/backlight/atmel-pwm-bl.c | 31 ++++++++++++-------------------
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/video/backlight/atmel-pwm-bl.c b/drivers/video/backlight/atmel-pwm-bl.c
index 4886028..01af5c2 100644
--- a/drivers/video/backlight/atmel-pwm-bl.c
+++ b/drivers/video/backlight/atmel-pwm-bl.c
@@ -126,40 +126,33 @@ static int atmel_pwm_bl_probe(struct platform_device *pdev)
struct atmel_pwm_bl *pwmbl;
int retval;
+ pdata = dev_get_platdata(&pdev->dev);
+ if (!pdata)
+ return -ENODEV;
+
+ if (pdata->pwm_compare_max < pdata->pwm_duty_max ||
+ pdata->pwm_duty_min > pdata->pwm_duty_max ||
+ pdata->pwm_frequency = 0)
+ return -EINVAL;
+
pwmbl = devm_kzalloc(&pdev->dev, sizeof(struct atmel_pwm_bl),
GFP_KERNEL);
if (!pwmbl)
return -ENOMEM;
pwmbl->pdev = pdev;
-
- pdata = dev_get_platdata(&pdev->dev);
- if (!pdata) {
- retval = -ENODEV;
- goto err_free_mem;
- }
-
- if (pdata->pwm_compare_max < pdata->pwm_duty_max ||
- pdata->pwm_duty_min > pdata->pwm_duty_max ||
- pdata->pwm_frequency = 0) {
- retval = -EINVAL;
- goto err_free_mem;
- }
-
pwmbl->pdata = pdata;
pwmbl->gpio_on = pdata->gpio_on;
retval = pwm_channel_alloc(pdata->pwm_channel, &pwmbl->pwmc);
if (retval)
- goto err_free_mem;
+ return retval;
if (pwmbl->gpio_on != -1) {
retval = devm_gpio_request(&pdev->dev, pwmbl->gpio_on,
"gpio_atmel_pwm_bl");
- if (retval) {
- pwmbl->gpio_on = -1;
+ if (retval)
goto err_free_pwm;
- }
/* Turn display off by default. */
retval = gpio_direction_output(pwmbl->gpio_on,
@@ -197,7 +190,7 @@ static int atmel_pwm_bl_probe(struct platform_device *pdev)
err_free_pwm:
pwm_channel_free(&pwmbl->pwmc);
-err_free_mem:
+
return retval;
}
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 3/9] backlight: atmel-pwm-bl: fix module autoload
From: Johan Hovold @ 2013-10-29 16:27 UTC (permalink / raw)
To: Richard Purdie, Jingoo Han
Cc: Nicolas Ferre, Tomi Valkeinen, Jean-Christophe Plagniol-Villard,
Andrew Morton, linux-fbdev, linux-kernel, Johan Hovold
In-Reply-To: <1383064064-4983-1-git-send-email-jhovold@gmail.com>
Add missing module alias which is needed for module autoloading.
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
drivers/video/backlight/atmel-pwm-bl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/backlight/atmel-pwm-bl.c b/drivers/video/backlight/atmel-pwm-bl.c
index e21beb6..4886028 100644
--- a/drivers/video/backlight/atmel-pwm-bl.c
+++ b/drivers/video/backlight/atmel-pwm-bl.c
@@ -229,3 +229,4 @@ module_platform_driver(atmel_pwm_bl_driver);
MODULE_AUTHOR("Hans-Christian egtvedt <hans-christian.egtvedt@atmel.com>");
MODULE_DESCRIPTION("Atmel PWM backlight driver");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:atmel-pwm-bl");
--
1.8.4.2
^ permalink raw reply related
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