* Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
From: Tony Lindgren @ 2014-04-30 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGhQ9Vwa8xXQEo5dNEKAvmaS9DoBjVSthtd8=owk+atVdFuiiA@mail.gmail.com>
* Joachim Eastwood <manabian@gmail.com> [140429 18:08]:
> On 30 April 2014 01:52, Tony Lindgren <tony@atomide.com> wrote:
> > Looks like quite a few omaps have sharp ls037v7dw01 that's configured
> > as various panel dpi entries for whatever legacy reasons. For device
> > tree based support, let's just configure these properly for panel
> > ls037v7dw01 instead of panel dpi.
> >
> > This patch creates a common file for panel ls037v7dw01, and makes
> > boards ldp and omap3-evm to use it. The panel for ldp is configured
> > in the qvga mode and omap3-evm panel in vga mode.
> >
> > The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
> > controller for the omaps, so let's add a basic configuration for
> > the touchscreen also using the default values.
> >
> > Note that we can now remove the regulator-name = "vdds_dsi"
> > entry for ldp, that's no longer needed as we have the entry
> > for vdds_dsi-supply = <&vpll2>.
> >
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> > .../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++++++++++++++++++++++
> > arch/arm/boot/dts/omap3-evm-37xx.dts | 50 +++++++++++++
> > arch/arm/boot/dts/omap3-evm-common.dtsi | 47 +++++++++++++
> > arch/arm/boot/dts/omap3-ldp.dts | 31 ++++++--
> > 4 files changed, 205 insertions(+), 5 deletions(-)
> > create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
>
> > diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
> > index 0abe986..50fdac9 100644
> > --- a/arch/arm/boot/dts/omap3-ldp.dts
> > +++ b/arch/arm/boot/dts/omap3-ldp.dts
> > @@ -164,6 +164,7 @@
> >
> > #include "twl4030.dtsi"
> > #include "twl4030_omap3.dtsi"
> > +#include "omap-panel-sharp-ls037v7dw01.dtsi"
> >
> > &i2c2 {
> > clock-frequency = <400000>;
> > @@ -173,6 +174,31 @@
> > clock-frequency = <400000>;
> > };
> >
> > +&lcd_3v3 {
> > + gpio = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > +};
> > +
> > +&lcd0 {
> > + reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>; /* gpio55, lcd RESB */
> > + gpios = <&gpio2 24 GPIO_ACTIVE_LOW /* gpio56, lcd MO */
>
> enable-gpios ?
Oops yes, changed from gpios to enable-gpios while reading the panel
binding doc, probably forgot to commit the change, will update.
Tony
^ permalink raw reply
* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tony Lindgren @ 2014-04-30 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5360948A.5020607@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140429 23:14]:
> On 29/04/14 20:38, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140429 09:33]:
> >> On 29/04/14 19:19, Tomi Valkeinen wrote:
> >>> On 29/04/14 18:05, Tony Lindgren wrote:
> >>>
> >>>>> omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives
> >>>>> a raw regmap to its memory area, the driver needs to know about the OMAP
> >>>>> control registers to use it.
> >>>>
> >>>> That would be probably best set up the same way we have already set up
> >>>> for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can
> >>>> access it using regmap, see how drivers/regulator/pbias-regulator.c
> >>>> sets up the pbias regulator with regmap for MMC.
> >>>
> >>> Right, but it means that the driver will contain platform specific code
> >>> for all the omap revisions it supports. Isn't that wrong?
> >>>
> >>> I already have a patch for DSI that uses the syscon-method, and it works
> >>> fine. But it's quite ugly, imo, to fiddle with the OMAP control
> >>> registers in a driver.
> >
> > Anything using the system control module registers should be a separate
> > driver. And it should ideally be implemeting some Linux generic framework
> > that the consumer driver can then use. That leaves out the need to export
> > custom functions.
>
> Ok.
>
> > I guess we don't have a PHY framework for displays though, so how about
> > just a separate minimal driver under drivers/video/omap2 that uses the
> > syscon?
>
> Well, this one is not really about DSI PHY. The CONTROL_DSIPHY register
> is not in the DSI PHY block, but in the control module, and it is used
> to enable/disable the pins (for omap4/5) and to set pull up/down for the
> pins (only for omap4). Oddly, for omap5, there's also a normal padconfig
> register for the DSI pins, but not so for omap4.
>
> To me it looks like a pad config register. I don't know why there's a
> separate odd register for it and it's not using the normal padconfig system.
>
> I'd like to use the pinctrl framework for it, but the pinctrl-single
> cannot handle such a funny register. So, if "Anything using the system
> control module registers should be a separate driver", then I guess I
> need to write a pinctrl driver for this single register?
Have you checked out pinctrl-single,bits binding? That should allow
you to map random bits in a single register to a pinctrl driver
instance.
> >> Oh, also, if I do that, I need to know both the SoC version and the DSS
> >> version in the driver.
> >
> > Don't you get all you need in the compatible string? Something like
> > compatible ti,dss-phy-omap5?
>
> We do use different compatible strings for different major versions of
> the DSS blocks, like ti,omap5-dsi. But that exactly same DSS block could
> be used on some other SoC, with different control stuff.
>
> We could use separate compatible string for each SoC that uses DSS, but
> then we're really encoding the SoC version into the compatible string,
> not DSS version.
>
> Of course, if there will be a separate driver managing the
> CONTROL_DSIPHY register, then that one should use compatible string
> specific to the SoC, as it's not a DSS driver at all.
Yeah probably using pinctrl-single,bits, or a separate driver with syscon
makes most sense here.
Regards,
Tony
^ permalink raw reply
* [PATCH] fbdev/fb.h: silence warning with -Wsign-compare
From: Brian W Hart @ 2014-05-01 19:32 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, linux-fbdev, linux-kernel, trivial
Silence the warning when building with -Wsign-compare when fb.h is
included:
include/linux/fb.h: In function ‘__fb_pad_aligned_buffer’:
include/linux/fb.h:650:17: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (j = 0; j < s_pitch; j++)
^
Signed-off-by: Brian W Hart <hartb@linux.vnet.ibm.com>
---
Compile tested only.
include/linux/fb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index fe6ac95..0da7634 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -641,7 +641,7 @@ static inline void unlock_fb_info(struct fb_info *info)
static inline void __fb_pad_aligned_buffer(u8 *dst, u32 d_pitch,
u8 *src, u32 s_pitch, u32 height)
{
- int i, j;
+ u32 i, j;
d_pitch -= s_pitch;
^ permalink raw reply related
* Re: [PATCH] fbdev/fb.h: silence warning with -Wsign-compare
From: Tomi Valkeinen @ 2014-05-02 12:59 UTC (permalink / raw)
To: Brian W Hart, plagnioj, linux-fbdev, linux-kernel, trivial
In-Reply-To: <20140501193235.GB6495@oc3347516403.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]
On 01/05/14 22:32, Brian W Hart wrote:
> Silence the warning when building with -Wsign-compare when fb.h is
> included:
>
> include/linux/fb.h: In function ‘__fb_pad_aligned_buffer’:
> include/linux/fb.h:650:17: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
> for (j = 0; j < s_pitch; j++)
> ^
>
> Signed-off-by: Brian W Hart <hartb@linux.vnet.ibm.com>
> ---
> Compile tested only.
>
> include/linux/fb.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index fe6ac95..0da7634 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -641,7 +641,7 @@ static inline void unlock_fb_info(struct fb_info *info)
> static inline void __fb_pad_aligned_buffer(u8 *dst, u32 d_pitch,
> u8 *src, u32 s_pitch, u32 height)
> {
> - int i, j;
> + u32 i, j;
>
> d_pitch -= s_pitch;
>
>
Thanks, queued for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing
From: Tomi Valkeinen @ 2014-05-02 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140430175651.GB12362@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]
On 30/04/14 20:56, Tony Lindgren wrote:
> Have you checked out pinctrl-single,bits binding? That should allow
> you to map random bits in a single register to a pinctrl driver
> instance.
If I recall right, the problem there was that we have one register,
which has bits for two separate devices, and the bits are mixed up. i.e.
not 16 upper bits for one, 16 lower for the other, but 5 bits for one
device, the next 5 bits for the other, then again few bits for the
first, etc.
pinctrl-single,bits didn't like it that.
>>>> Oh, also, if I do that, I need to know both the SoC version and the DSS
>>>> version in the driver.
>>>
>>> Don't you get all you need in the compatible string? Something like
>>> compatible ti,dss-phy-omap5?
>>
>> We do use different compatible strings for different major versions of
>> the DSS blocks, like ti,omap5-dsi. But that exactly same DSS block could
>> be used on some other SoC, with different control stuff.
>>
>> We could use separate compatible string for each SoC that uses DSS, but
>> then we're really encoding the SoC version into the compatible string,
>> not DSS version.
>>
>> Of course, if there will be a separate driver managing the
>> CONTROL_DSIPHY register, then that one should use compatible string
>> specific to the SoC, as it's not a DSS driver at all.
>
> Yeah probably using pinctrl-single,bits, or a separate driver with syscon
> makes most sense here.
Yep, I'll have to come up with something.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: some divide by zero bugs in >fb_check_var() functions
From: Dan Carpenter @ 2014-05-02 15:15 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20140124223503.GA4251@elgon.mountain>
Anyone want to look through these again? These of divide by
zero bugs in drivers/video/ are a massive pain. Is there no way to
prevent these crashing bugs that doesn't involve adding hundreds of
conditions?
regards,
dan carpenter
On Wed, Jan 29, 2014 at 12:41:37AM +0300, Dan Carpenter wrote:
> On Tue, Jan 28, 2014 at 01:28:06PM -0800, Kees Cook wrote:
> > On Fri, Jan 24, 2014 at 2:35 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > > My static checker find a number of divide by zero bugs in
> > > ->fb_check_var() functions. The call tree looks like this:
> > >
> > > do_fb_ioctl() <- get var from the user.
> > > -> fb_set_var()
> > > -> info->fbops->fb_check_var(var, info); <- divide by zero bugs
> > >
> > > I wonder if we could add some checking in fb_set_var() to prevent this.
> > >
> > > drivers/video/asiliantfb.c:230 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> > > drivers/video/asiliantfb.c:231 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> > > drivers/video/asiliantfb.c:232 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> > > drivers/video/cirrusfb.c:535 cirrusfb_check_var() error: potential divide by zero bug '/ var->bits_per_pixel'.
> > > drivers/video/cirrusfb.c:581 cirrusfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
> > > drivers/video/cyber2000fb.c:843 cyber2000fb_check_var() error: potential divide by zero bug '/ (var->bits_per_pixel * var->xres_virtual)'.
> > > drivers/video/imsttfb.c:843 imsttfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
> > > drivers/video/neofb.c:594 neofb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > > drivers/video/neofb.c:702 neofb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
> > > drivers/video/pm2fb.c:624 pm2fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > > drivers/video/pm3fb.c:1007 pm3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > > drivers/video/s3fb.c:601 s3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > > drivers/video/savage/savagefb_driver.c:952 savagefb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
> > > drivers/video/sstfb.c:359 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > > drivers/video/sstfb.c:361 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > > drivers/video/tdfxfb.c:518 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > > drivers/video/tdfxfb.c:519 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > > drivers/video/tridentfb.c:918 tridentfb_check_var() error: potential divide by zero bug '/ line_length'.
> > > drivers/video/tridentfb.c:973 tridentfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> >
> > Is it ever valid to have pixclock, xres_virtual, or bits_per_pixel be
> > zero? Seems like it'd be trivial to check for those in fb_set_var()?
> >
>
> It's not so simple as testing for zero, you also have to consider the
> maximum and integer overflows so "var->xres_virtual * var->bits_per_pixel"
> isn't zero.
>
> If I add another call to the call tree then there are more errors again.
>
> regards,
> dan carpenter
>
> drivers/video/savage/savagefb_driver.c:952 savagefb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
> drivers/video/savage/savagefb_driver.c:952 savagefb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
> drivers/video/fbmon.c:1147 fb_get_hblank_by_hfreq() error: potential divide by zero bug '/ hfreq'.
> drivers/video/fbmon.c:1147 fb_get_hblank_by_hfreq() error: potential divide by zero bug '/ hfreq'.
> drivers/video/fbmon.c:1232 fb_timings_hfreq() error: potential divide by zero bug '/ timings->vtotal'.
> drivers/video/fbmon.c:1232 fb_timings_hfreq() error: potential divide by zero bug '/ timings->vtotal'.
> drivers/video/fbmon.c:1244 fb_timings_dclk() error: potential divide by zero bug '/ timings->htotal'.
> drivers/video/fbmon.c:1244 fb_timings_dclk() error: potential divide by zero bug '/ timings->htotal'.
> drivers/video/fbmon.c:1247 fb_timings_dclk() error: potential divide by zero bug '/ timings->vtotal'.
> drivers/video/fbmon.c:1247 fb_timings_dclk() error: potential divide by zero bug '/ timings->vtotal'.
> drivers/video/fbmon.c:1364 fb_get_mode() error: potential divide by zero bug '/ (timings->dclk / 1000)'.
> drivers/video/fbmon.c:1364 fb_get_mode() error: potential divide by zero bug '/ (timings->dclk / 1000)'.
> drivers/video/fbmon.c:1544 fb_validate_mode() error: potential divide by zero bug '/ htotal'.
> drivers/video/fbmon.c:1544 fb_validate_mode() error: potential divide by zero bug '/ htotal'.
> drivers/video/fbmon.c:1547 fb_validate_mode() error: potential divide by zero bug '/ vtotal'.
> drivers/video/fbmon.c:1547 fb_validate_mode() error: potential divide by zero bug '/ vtotal'.
> drivers/video/via/viafbdev.c:196 get_var_refresh() error: potential divide by zero bug '/ (htotal * vtotal)'.
> drivers/video/via/viafbdev.c:196 get_var_refresh() error: potential divide by zero bug '/ (htotal * vtotal)'.
> drivers/video/via/viafbdev.c:196 get_var_refresh() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/via/viafbdev.c:196 get_var_refresh() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/pm3fb.c:338 pm3fb_init_engine() error: potential divide by zero bug '/ info->fix.line_length'.
> drivers/video/pm3fb.c:338 pm3fb_init_engine() error: potential divide by zero bug '/ info->fix.line_length'.
> drivers/video/pm3fb.c:834 pm3fb_write_mode() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/pm3fb.c:834 pm3fb_write_mode() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/pm3fb.c:1007 pm3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/pm3fb.c:1007 pm3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/tdfxfb.c:518 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/tdfxfb.c:518 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/tdfxfb.c:519 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/tdfxfb.c:519 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/tdfxfb.c:583 tdfxfb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/tdfxfb.c:583 tdfxfb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/sstfb.c:359 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/sstfb.c:359 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/sstfb.c:361 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/sstfb.c:361 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/sstfb.c:491 sstfb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/sstfb.c:491 sstfb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/sm501fb.c:263 sm501fb_ps_to_hz() error: potential divide by zero bug '/ __base'.
> drivers/video/sm501fb.c:263 sm501fb_ps_to_hz() error: potential divide by zero bug '/ __base'.
> drivers/video/sm501fb.c:263 sm501fb_ps_to_hz() error: potential divide by zero bug '/ __base'.
> drivers/video/sm501fb.c:263 sm501fb_ps_to_hz() error: potential divide by zero bug '/ __base'.
> drivers/video/sm501fb.c:593 sm501fb_pan_crt() error: potential divide by zero bug '/ bytes_pixel'.
> drivers/video/sm501fb.c:593 sm501fb_pan_crt() error: potential divide by zero bug '/ bytes_pixel'.
> drivers/video/cyber2000fb.c:843 cyber2000fb_check_var() error: potential divide by zero bug '/ (var->bits_per_pixel * var->xres_virtual)'.
> drivers/video/cyber2000fb.c:843 cyber2000fb_check_var() error: potential divide by zero bug '/ (var->bits_per_pixel * var->xres_virtual)'.
> drivers/video/kyro/STG4000OverlayDevice.c:379 SetOverlayViewPort() error: potential divide by zero bug '/ ulFxScale'.
> drivers/video/kyro/STG4000OverlayDevice.c:379 SetOverlayViewPort() error: potential divide by zero bug '/ ulFxScale'.
> drivers/video/kyro/STG4000OverlayDevice.c:477 SetOverlayViewPort() error: potential divide by zero bug '/ (ulRight - ulLeft + 2)'.
> drivers/video/kyro/STG4000OverlayDevice.c:477 SetOverlayViewPort() error: potential divide by zero bug '/ (ulRight - ulLeft + 2)'.
> drivers/video/kyro/STG4000OverlayDevice.c:481 SetOverlayViewPort() error: potential divide by zero bug '/ (ulRight - ulLeft + 2)'.
> drivers/video/kyro/STG4000OverlayDevice.c:481 SetOverlayViewPort() error: potential divide by zero bug '/ (ulRight - ulLeft + 2)'.
> drivers/video/kyro/fbdev.c:502 kyrofb_set_par() error: potential divide by zero bug '/ frameclock'.
> drivers/video/kyro/fbdev.c:502 kyrofb_set_par() error: potential divide by zero bug '/ frameclock'.
> drivers/video/kyro/fbdev.c:503 kyrofb_set_par() error: potential divide by zero bug '/ lineclock'.
> drivers/video/kyro/fbdev.c:503 kyrofb_set_par() error: potential divide by zero bug '/ lineclock'.
> drivers/video/kyro/fbdev.c:505 kyrofb_set_par() error: potential divide by zero bug '/ info->var.pixclock'.
> drivers/video/kyro/fbdev.c:505 kyrofb_set_par() error: potential divide by zero bug '/ info->var.pixclock'.
> drivers/video/modedb.c:809 fb_var_to_videomode() error: potential divide by zero bug '/ htotal'.
> drivers/video/modedb.c:809 fb_var_to_videomode() error: potential divide by zero bug '/ htotal'.
> drivers/video/modedb.c:810 fb_var_to_videomode() error: potential divide by zero bug '/ vtotal'.
> drivers/video/modedb.c:810 fb_var_to_videomode() error: potential divide by zero bug '/ vtotal'.
> drivers/video/mb862xx/mb862xxfbdrv.c:221 mb862xxfb_set_par() error: potential divide by zero bug '/ fbi->var.pixclock'.
> drivers/video/mb862xx/mb862xxfbdrv.c:221 mb862xxfb_set_par() error: potential divide by zero bug '/ fbi->var.pixclock'.
> drivers/video/smscufx.c:622 ufx_config_pix_clk() error: potential divide by zero bug '/ (pixclock)'.
> drivers/video/smscufx.c:622 ufx_config_pix_clk() error: potential divide by zero bug '/ (pixclock)'.
> drivers/video/s3fb.c:477 s3_set_pixclock() error: potential divide by zero bug '/ pixclock'.
> drivers/video/s3fb.c:477 s3_set_pixclock() error: potential divide by zero bug '/ pixclock'.
> drivers/video/s3fb.c:601 s3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/s3fb.c:601 s3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/imsttfb.c:843 imsttfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
> drivers/video/imsttfb.c:843 imsttfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
> drivers/video/asiliantfb.c:113 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
> drivers/video/asiliantfb.c:113 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
> drivers/video/asiliantfb.c:123 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
> drivers/video/asiliantfb.c:123 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
> drivers/video/asiliantfb.c:124 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
> drivers/video/asiliantfb.c:124 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
> drivers/video/asiliantfb.c:125 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
> drivers/video/asiliantfb.c:125 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
> drivers/video/asiliantfb.c:230 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/asiliantfb.c:230 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/asiliantfb.c:231 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/asiliantfb.c:231 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/asiliantfb.c:232 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/asiliantfb.c:232 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:435 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:435 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:437 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:437 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:444 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:444 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:446 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:446 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:453 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:453 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:455 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:455 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:461 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:461 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:463 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:463 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:655 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:655 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:662 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/i740fb.c:662 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/cirrusfb.c:482 cirrusfb_check_pixclock() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/cirrusfb.c:482 cirrusfb_check_pixclock() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/cirrusfb.c:535 cirrusfb_check_var() error: potential divide by zero bug '/ var->bits_per_pixel'.
> drivers/video/cirrusfb.c:535 cirrusfb_check_var() error: potential divide by zero bug '/ var->bits_per_pixel'.
> drivers/video/cirrusfb.c:581 cirrusfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
> drivers/video/cirrusfb.c:581 cirrusfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
> drivers/video/cirrusfb.c:836 cirrusfb_set_par_foo() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/cirrusfb.c:836 cirrusfb_set_par_foo() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/riva/fbdev.c:722 riva_load_video_mode() error: potential divide by zero bug '/ info->var.pixclock'.
> drivers/video/riva/fbdev.c:722 riva_load_video_mode() error: potential divide by zero bug '/ info->var.pixclock'.
> drivers/video/geode/lxfb_ops.c:169 lx_set_clock() error: potential divide by zero bug '/ info->var.pixclock'.
> drivers/video/geode/lxfb_ops.c:169 lx_set_clock() error: potential divide by zero bug '/ info->var.pixclock'.
> drivers/video/sis/sis_main.c:1082 sisfb_calc_maxyres() error: potential divide by zero bug '/ (var->xres_virtual * (var->bits_per_pixel >> 3))'.
> drivers/video/sis/sis_main.c:1082 sisfb_calc_maxyres() error: potential divide by zero bug '/ (var->xres_virtual * (var->bits_per_pixel >> 3))'.
> drivers/video/nvidia/nvidia.c:424 nvidia_calc_regs() error: potential divide by zero bug '/ info->var.pixclock'.
> drivers/video/nvidia/nvidia.c:424 nvidia_calc_regs() error: potential divide by zero bug '/ info->var.pixclock'.
> drivers/video/tridentfb.c:918 tridentfb_check_var() error: potential divide by zero bug '/ line_length'.
> drivers/video/tridentfb.c:918 tridentfb_check_var() error: potential divide by zero bug '/ line_length'.
> drivers/video/tridentfb.c:973 tridentfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/tridentfb.c:973 tridentfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/tridentfb.c:1176 tridentfb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/tridentfb.c:1176 tridentfb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/neofb.c:594 neofb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/neofb.c:594 neofb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/neofb.c:702 neofb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
> drivers/video/neofb.c:702 neofb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
> drivers/video/neofb.c:952 neofb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/neofb.c:952 neofb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/arkfb.c:517 ark_set_pixclock() error: potential divide by zero bug '/ pixclock'.
> drivers/video/arkfb.c:517 ark_set_pixclock() error: potential divide by zero bug '/ pixclock'.
> drivers/video/udlfb.c:266 dlfb_set_vid_cmds() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/udlfb.c:266 dlfb_set_vid_cmds() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/uvesafb.c:1270 uvesafb_set_par() error: potential divide by zero bug '/ (crtc->vert_total * crtc->horiz_total)'.
> drivers/video/uvesafb.c:1270 uvesafb_set_par() error: potential divide by zero bug '/ (crtc->vert_total * crtc->horiz_total)'.
> drivers/video/pm2fb.c:624 pm2fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/pm2fb.c:624 pm2fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/pm2fb.c:716 pm2fb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/pm2fb.c:716 pm2fb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
> drivers/video/vermilion/vermilion.c:609 vmlfb_check_var_locked() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/vermilion/vermilion.c:609 vmlfb_check_var_locked() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/matrox/matroxfb_Ti3026.c:320 Ti3026_setpclk() error: potential divide by zero bug '/ Bpp'.
> drivers/video/matrox/matroxfb_Ti3026.c:320 Ti3026_setpclk() error: potential divide by zero bug '/ Bpp'.
> drivers/video/matrox/matroxfb_Ti3026.c:323 Ti3026_setpclk() error: potential divide by zero bug '/ Bpp'.
> drivers/video/matrox/matroxfb_Ti3026.c:323 Ti3026_setpclk() error: potential divide by zero bug '/ Bpp'.
> drivers/video/matrox/matroxfb_base.c:578 matroxfb_decode_var() error: potential divide by zero bug '/ (var->xres_virtual * bpp)'.
> drivers/video/matrox/matroxfb_base.c:578 matroxfb_decode_var() error: potential divide by zero bug '/ (var->xres_virtual * bpp)'.
> drivers/video/matrox/matroxfb_base.c:601 matroxfb_decode_var() error: potential divide by zero bug '/ m2'.
> drivers/video/matrox/matroxfb_base.c:601 matroxfb_decode_var() error: potential divide by zero bug '/ m2'.
> drivers/video/matrox/matroxfb_base.c:787 matroxfb_set_par() error: potential divide by zero bug '/ var->bits_per_pixel'.
> drivers/video/matrox/matroxfb_base.c:787 matroxfb_set_par() error: potential divide by zero bug '/ var->bits_per_pixel'.
> drivers/video/aty/radeon_base.c:1595 radeonfb_set_par() error: potential divide by zero bug '/ pixClock'.
> drivers/video/aty/radeon_base.c:1595 radeonfb_set_par() error: potential divide by zero bug '/ pixClock'.
> drivers/video/aty/radeon_base.c:1670 radeonfb_set_par() error: potential divide by zero bug '/ ((mode->bits_per_pixel + 1) / 8)'.
> drivers/video/aty/radeon_base.c:1670 radeonfb_set_par() error: potential divide by zero bug '/ ((mode->bits_per_pixel + 1) / 8)'.
> drivers/video/aty/atyfb_base.c:1575 set_off_pitch() error: potential divide by zero bug '/ bpp'.
> drivers/video/aty/atyfb_base.c:1575 set_off_pitch() error: potential divide by zero bug '/ bpp'.
> drivers/video/aty/mach64_accel.c:69 aty_init_engine() error: potential divide by zero bug '/ (info->var.bits_per_pixel / 8)'.
> drivers/video/aty/mach64_accel.c:69 aty_init_engine() error: potential divide by zero bug '/ (info->var.bits_per_pixel / 8)'.
> drivers/video/aty/aty128fb.c:1342 aty128_var_to_pll() error: potential divide by zero bug '/ period_in_ps'.
> drivers/video/aty/aty128fb.c:1342 aty128_var_to_pll() error: potential divide by zero bug '/ period_in_ps'.
> drivers/video/sysfillrect.c:267 sys_fillrect() error: potential divide by zero bug '/ bpp'.
> drivers/video/sysfillrect.c:267 sys_fillrect() error: potential divide by zero bug '/ bpp'.
> drivers/video/sysfillrect.c:321 sys_fillrect() error: potential divide by zero bug '/ bpp'.
> drivers/video/sysfillrect.c:321 sys_fillrect() error: potential divide by zero bug '/ bpp'.
> drivers/video/cfbfillrect.c:302 cfb_fillrect() error: potential divide by zero bug '/ bpp'.
> drivers/video/cfbfillrect.c:302 cfb_fillrect() error: potential divide by zero bug '/ bpp'.
> drivers/video/cfbfillrect.c:357 cfb_fillrect() error: potential divide by zero bug '/ bpp'.
> drivers/video/cfbfillrect.c:357 cfb_fillrect() error: potential divide by zero bug '/ bpp'.
> drivers/video/vt8623fb.c:267 vt8623_set_pixclock() error: potential divide by zero bug '/ pixclock'.
> drivers/video/vt8623fb.c:267 vt8623_set_pixclock() error: potential divide by zero bug '/ pixclock'.
>
^ permalink raw reply
* Re: some divide by zero bugs in >fb_check_var() functions
From: Geert Uytterhoeven @ 2014-05-02 15:48 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20140124223503.GA4251@elgon.mountain>
On Tue, Jan 28, 2014 at 10:28 PM, Kees Cook <keescook@chromium.org> wrote:
> Is it ever valid to have pixclock, xres_virtual, or bits_per_pixel be
> zero? Seems like it'd be trivial to check for those in fb_set_var()?
pixclock could be zero for some special fixed type of display that doesn't
have timings. Hmm, you could use 1 for that. Are there any in-tree users?
Anyway, the checker reported issues with specific drivers, not with the core,
right?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Please Acknowledge My Proposal
From: Gva Abogados @ 2014-05-03 12:20 UTC (permalink / raw)
To: linux-fbdev
Please Acknowledge My Proposal!!
My name is Mr. Juan Martin Domingo a lawyer resident in Spain. I am
writing to let you know I have some FUNDS I want to transfer and am
seeking if you can be a beneficiary...Do not hesitate to Contact me for
more information if interested: gva_abogados@aim.com
Sincerely
Juan Martin Domingo.
Domijdo@aim.com
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Olof Johansson @ 2014-05-05 5:06 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
On Wed, Apr 30, 2014 at 04:36:29PM +0400, Alexander Shiyan wrote:
> Wed, 30 Apr 2014 14:14:36 +0300 от Tomi Valkeinen <tomi.valkeinen@ti.com>:
> > On 24/04/14 19:35, Alexander Shiyan wrote:
>
> Hello.
>
> I'm a reorder quotes a bit for convenience.
>
> > >> The right way to do it is, as I wrote above, by gradually changing the
> > >> old driver with a patch series. And my question is, why not do it that
> > >> way? Then it would be possible to review the patches one by one, seeing
> > >> what has changed.
> > >
> > > "gradually changing"...
> > > I repeat that this is not an old modified driver, but written new.
> >
> > Yes, I understand that. Again, my question is, why didn't you modify the
> > old driver? That's how things should normally be done. Instead, you made
> > a totally new one, making proper review against the old driver impossible.
> ...
> > Hmm what? So is the old driver totally broken, and cannot be used at the
> > moment? Or why you can't test on real hardware?
>
> Firstly, the driver uses a fixed values for xres, yres, pixclock and specific
> variable ac_precale.
> Secondly, the driver uses a fixed value for the physical address of the buffer.
> Totally, it does not give me the ability to use the driver in the current state.
> Unlikely that this will look good if I make these two significant changes in
> a single patch...
>
> At this time the driver has three user.
> Only one of them should theoretically work.
> clps711x-autcpu12 should not work in the absence of memblock_reserve().
> clps711x-p720t should not work due to physical address limitation as i
> noticed before. Board means to use SRAM instead of SDRAM.
> Only clps711x-edb7211 should work fine (in theory).
> Is this a good reason to replace the driver? I think yes.
>
> > Note that I don't know anything about the fb hardware in question, nor
> > the driver. Maybe there's a valid reason to write a new driver from
> > scratch. But there very rarely is.
> >
> > And "because I already wrote a new driver, and it's a waste of time for
> > me to throw away my work and patch the old one", is not a very good reason.
>
> > > if you imagine a new file as a diff to the old, this can be clearly seen.
> > >
> > > There is no reason to waste time on a series of changes since I
> > > can not even check these changes on real hardware, but only in the
> > > last stage when the driver will be the current version.
>
> Summing up, I want to ask why the driver can not be reviewed as a
> new and not compared to the old?
> And yes, the time can be spent on more productive things to do than
> to create a series, leading eventually to the same result.
> As far as I know, guide to creating kernel patches allows such cases.
We've definitely had cases like that in the past. Sometimes it's easier
to first post a patch that removes the old driver, then one that submits
the new one as a new piece of work. That, of course, assumes that the
driver indeed was a rewrite and not just a bunch of incremental changes
all squashed into one.
-Olof
^ permalink raw reply
* [PATCH v2] video: mx3fb: Add backlight support
From: Alexander Stein @ 2014-05-05 6:56 UTC (permalink / raw)
To: linux-fbdev
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
---
Changes in v2:
* rebased to v3.15-rc4
drivers/video/fbdev/mx3fb.c | 98 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 98 insertions(+)
diff --git a/drivers/video/fbdev/mx3fb.c b/drivers/video/fbdev/mx3fb.c
index 142e860..10a7244 100644
--- a/drivers/video/fbdev/mx3fb.c
+++ b/drivers/video/fbdev/mx3fb.c
@@ -27,6 +27,7 @@
#include <linux/clk.h>
#include <linux/mutex.h>
#include <linux/dma/ipu-dma.h>
+#include <linux/backlight.h>
#include <linux/platform_data/dma-imx.h>
#include <linux/platform_data/video-mx3fb.h>
@@ -34,6 +35,12 @@
#include <asm/io.h>
#include <asm/uaccess.h>
+#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) || \
+ (defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE) && \
+ defined(CONFIG_MX3FB_MODULE))
+#define PWM_BACKLIGHT_AVAILABLE
+#endif
+
#define MX3FB_NAME "mx3_sdc_fb"
#define MX3FB_REG_OFFSET 0xB4
@@ -242,6 +249,10 @@ struct mx3fb_data {
spinlock_t lock;
struct device *dev;
+#ifdef PWM_BACKLIGHT_AVAILABLE
+ struct backlight_device *bl;
+#endif
+
uint32_t h_start_width;
uint32_t v_start_width;
enum disp_data_mapping disp_data_fmt;
@@ -271,6 +282,74 @@ struct mx3fb_info {
struct fb_var_screeninfo cur_var; /* current var info */
};
+static void sdc_set_brightness(struct mx3fb_data *mx3fb, uint8_t value);
+
+#ifdef PWM_BACKLIGHT_AVAILABLE
+static u32 sdc_get_brightness(struct mx3fb_data *mx3fb);
+
+static int mx3fb_bl_get_brightness(struct backlight_device *bl)
+{
+ struct mx3fb_data *fbd = bl_get_data(bl);
+
+ return sdc_get_brightness(fbd);
+}
+
+static int mx3fb_bl_update_status(struct backlight_device *bl)
+{
+ struct mx3fb_data *fbd = bl_get_data(bl);
+ int brightness = bl->props.brightness;
+
+ if (bl->props.power != FB_BLANK_UNBLANK)
+ brightness = 0;
+ if (bl->props.fb_blank != FB_BLANK_UNBLANK)
+ brightness = 0;
+
+ fbd->backlight_level = (fbd->backlight_level & ~0xFF) | brightness;
+
+ sdc_set_brightness(fbd, fbd->backlight_level);
+
+ return 0;
+}
+
+static const struct backlight_ops mx3fb_lcdc_bl_ops = {
+ .update_status = mx3fb_bl_update_status,
+ .get_brightness = mx3fb_bl_get_brightness,
+};
+
+static void mx3fb_init_backlight(struct mx3fb_data *fbd)
+{
+ struct backlight_properties props;
+ struct backlight_device *bl;
+
+ if (fbd->bl)
+ return;
+
+ memset(&props, 0, sizeof(struct backlight_properties));
+ props.max_brightness = 0xff;
+ props.type = BACKLIGHT_RAW;
+ sdc_set_brightness(fbd, fbd->backlight_level);
+
+ bl = backlight_device_register("mx3fb-bl", fbd->dev, fbd,
+ &mx3fb_lcdc_bl_ops, &props);
+ if (IS_ERR(bl)) {
+ dev_err(fbd->dev, "error %ld on backlight register\n",
+ PTR_ERR(bl));
+ return;
+ }
+
+ fbd->bl = bl;
+ bl->props.power = FB_BLANK_UNBLANK;
+ bl->props.fb_blank = FB_BLANK_UNBLANK;
+ bl->props.brightness = mx3fb_bl_get_brightness(bl);
+}
+
+static void mx3fb_exit_backlight(struct mx3fb_data *fbd)
+{
+ if (fbd->bl)
+ backlight_device_unregister(fbd->bl);
+}
+#endif
+
static void mx3fb_dma_done(void *);
/* Used fb-mode and bpp. Can be set on kernel command line, therefore file-static. */
@@ -628,6 +707,18 @@ static int sdc_set_global_alpha(struct mx3fb_data *mx3fb, bool enable, uint8_t a
return 0;
}
+#ifdef PWM_BACKLIGHT_AVAILABLE
+static u32 sdc_get_brightness(struct mx3fb_data *mx3fb)
+{
+ u32 brightness;
+
+ brightness = mx3fb_read_reg(mx3fb, SDC_PWM_CTRL);
+ brightness = (brightness >> 16) & 0xFF;
+
+ return brightness;
+}
+#endif
+
static void sdc_set_brightness(struct mx3fb_data *mx3fb, uint8_t value)
{
dev_dbg(mx3fb->dev, "%s: value = %d\n", __func__, value);
@@ -1534,6 +1625,9 @@ static int mx3fb_probe(struct platform_device *pdev)
if (ret < 0)
goto eisdc0;
+#ifdef PWM_BACKLIGHT_AVAILABLE
+ mx3fb_init_backlight(mx3fb);
+#endif
return 0;
eisdc0:
@@ -1557,6 +1651,10 @@ static int mx3fb_remove(struct platform_device *dev)
chan = &mx3_fbi->idmac_channel->dma_chan;
release_fbi(fbi);
+#ifdef PWM_BACKLIGHT_AVAILABLE
+ mx3fb_exit_backlight(mx3fb);
+#endif
+
dma_release_channel(chan);
dmaengine_put();
--
1.8.5.5
^ permalink raw reply related
* Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
From: Tony Lindgren @ 2014-05-05 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140430174751.GA12362@atomide.com>
* Tony Lindgren <tony@atomide.com> [140430 10:48]:
> * Joachim Eastwood <manabian@gmail.com> [140429 18:08]:
> > On 30 April 2014 01:52, Tony Lindgren <tony@atomide.com> wrote:
> > > Looks like quite a few omaps have sharp ls037v7dw01 that's configured
> > > as various panel dpi entries for whatever legacy reasons. For device
> > > tree based support, let's just configure these properly for panel
> > > ls037v7dw01 instead of panel dpi.
> > >
> > > This patch creates a common file for panel ls037v7dw01, and makes
> > > boards ldp and omap3-evm to use it. The panel for ldp is configured
> > > in the qvga mode and omap3-evm panel in vga mode.
> > >
> > > The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
> > > controller for the omaps, so let's add a basic configuration for
> > > the touchscreen also using the default values.
> > >
> > > Note that we can now remove the regulator-name = "vdds_dsi"
> > > entry for ldp, that's no longer needed as we have the entry
> > > for vdds_dsi-supply = <&vpll2>.
> > >
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > > ---
> > > .../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++++++++++++++++++++++
> > > arch/arm/boot/dts/omap3-evm-37xx.dts | 50 +++++++++++++
> > > arch/arm/boot/dts/omap3-evm-common.dtsi | 47 +++++++++++++
> > > arch/arm/boot/dts/omap3-ldp.dts | 31 ++++++--
> > > 4 files changed, 205 insertions(+), 5 deletions(-)
> > > create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
> >
> > > diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
> > > index 0abe986..50fdac9 100644
> > > --- a/arch/arm/boot/dts/omap3-ldp.dts
> > > +++ b/arch/arm/boot/dts/omap3-ldp.dts
> > > @@ -164,6 +164,7 @@
> > >
> > > #include "twl4030.dtsi"
> > > #include "twl4030_omap3.dtsi"
> > > +#include "omap-panel-sharp-ls037v7dw01.dtsi"
> > >
> > > &i2c2 {
> > > clock-frequency = <400000>;
> > > @@ -173,6 +174,31 @@
> > > clock-frequency = <400000>;
> > > };
> > >
> > > +&lcd_3v3 {
> > > + gpio = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
> > > + enable-active-high;
> > > +};
> > > +
> > > +&lcd0 {
> > > + reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>; /* gpio55, lcd RESB */
> > > + gpios = <&gpio2 24 GPIO_ACTIVE_LOW /* gpio56, lcd MO */
> >
> > enable-gpios ?
>
> Oops yes, changed from gpios to enable-gpios while reading the panel
> binding doc, probably forgot to commit the change, will update.
Here's an updated version of this one.
Tony
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 28 Apr 2014 20:22:21 -0700
Subject: [PATCH] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
Looks like quite a few omaps have sharp ls037v7dw01 that's configured
as various panel dpi entries for whatever legacy reasons. For device
tree based support, let's just configure these properly for panel
ls037v7dw01 instead of panel dpi.
This patch creates a common file for panel ls037v7dw01, and makes
boards ldp and omap3-evm to use it. The panel for ldp is configured
in the qvga mode and omap3-evm panel in vga mode.
The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
controller for the omaps, so let's add a basic configuration for
the touchscreen also using the default values.
Note that we can now remove the regulator-name = "vdds_dsi"
entry for ldp, that's no longer needed as we have the entry
for vdds_dsi-supply = <&vpll2>.
Signed-off-by: Tony Lindgren <tony@atomide.com>
diff --git a/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
new file mode 100644
index 0000000..f5252da
--- /dev/null
+++ b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
@@ -0,0 +1,82 @@
+/*
+ * Common file for omap dpi panels with QVGA and reset pins
+ *
+ * Note that the board specifc DTS file needs to specify
+ * at minimum the GPIO enable-gpios for display, and
+ * gpios for gpio-backlight.
+ */
+
+/ {
+ aliases {
+ display0 = &lcd0;
+ };
+
+ backlight0: backlight {
+ compatible = "gpio-backlight";
+ };
+
+ /* 3.3V GPIO controlled regulator for LCD_ENVDD */
+ lcd_3v3: regulator-lcd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ startup-delay-us = <70000>;
+ regulator-always-on;
+ };
+
+ lcd0: display {
+ compatible = "sharp,ls037v7dw01";
+ label = "lcd";
+ power-supply = <&lcd_3v3>;
+ panel-timing {
+ clock-frequency = <5400000>;
+ hback-porch = <39>;
+ hactive = <240>;
+ hfront-porch = <3>;
+ hsync-len = <3>;
+ vback-porch = <7>;
+ vactive = <320>;
+ vfront-porch = <2>;
+ vsync-len = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+ };
+};
+
+&dss {
+ status = "ok";
+ vdds_dsi-supply = <&vpll2>;
+ port {
+ dpi_out: endpoint {
+ remote-endpoint = <&lcd_in>;
+ data-lines = <18>;
+ };
+ };
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ reg = <0>; /* CS0 */
+ compatible = "ti,tsc2046";
+ spi-max-frequency = <1000000>;
+ vcc-supply = <&lcd_3v3>;
+ ti,x-min = /bits/ 16 <0>;
+ ti,x-max = /bits/ 16 <8000>;
+ ti,y-min = /bits/ 16 <0>;
+ ti,y-max = /bits/ 16 <4800>;
+ ti,x-plate-ohms = /bits/ 16 <40>;
+ ti,pressure-max = /bits/ 16 <255>;
+ ti,swap-xy;
+ linux,wakeup;
+ };
+};
diff --git a/arch/arm/boot/dts/omap3-evm-37xx.dts b/arch/arm/boot/dts/omap3-evm-37xx.dts
index 4df68ad..a181e30 100644
--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -26,7 +26,44 @@
};
};
+&dss {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &dss_dpi_pins1
+ &dss_dpi_pins2
+ >;
+};
+
&omap3_pmx_core {
+ dss_dpi_pins1: pinmux_dss_dpi_pins2 {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
+ OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync */
+ OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync */
+ OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0) /* dss_acbias.dss_acbias */
+
+ OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6 */
+ OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7 */
+ OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8 */
+ OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9 */
+ OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0) /* dss_data10.dss_data10 */
+ OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0) /* dss_data11.dss_data11 */
+ OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0) /* dss_data12.dss_data12 */
+ OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0) /* dss_data13.dss_data13 */
+ OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0) /* dss_data14.dss_data14 */
+ OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0) /* dss_data15.dss_data15 */
+ OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0) /* dss_data16.dss_data16 */
+ OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0) /* dss_data17.dss_data17 */
+
+ OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE3) /* dss_data18.dss_data0 */
+ OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE3) /* dss_data19.dss_data1 */
+ OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE3) /* dss_data20.dss_data2 */
+ OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE3) /* dss_data21.dss_data3 */
+ OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE3) /* dss_data22.dss_data4 */
+ OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE3) /* dss_data23.dss_data5 */
+ >;
+ };
+
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins = <
0x114 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* sdmmc1_clk.sdmmc1_clk */
@@ -75,6 +112,19 @@
};
};
+&omap3_pmx_wkup {
+ dss_dpi_pins2: pinmux_dss_dpi_pins1 {
+ pinctrl-single,pins = <
+ 0x0a (PIN_OUTPUT | MUX_MODE3) /* sys_boot0.dss_data18 */
+ 0x0c (PIN_OUTPUT | MUX_MODE3) /* sys_boot1.dss_data19 */
+ 0x10 (PIN_OUTPUT | MUX_MODE3) /* sys_boot3.dss_data20 */
+ 0x12 (PIN_OUTPUT | MUX_MODE3) /* sys_boot4.dss_data21 */
+ 0x14 (PIN_OUTPUT | MUX_MODE3) /* sys_boot5.dss_data22 */
+ 0x16 (PIN_OUTPUT | MUX_MODE3) /* sys_boot6.dss_data23 */
+ >;
+ };
+};
+
&mmc1 {
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins>;
diff --git a/arch/arm/boot/dts/omap3-evm-common.dtsi b/arch/arm/boot/dts/omap3-evm-common.dtsi
index 3007e79..0ab9650 100644
--- a/arch/arm/boot/dts/omap3-evm-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -44,6 +44,11 @@
#include "twl4030.dtsi"
#include "twl4030_omap3.dtsi"
+#include "omap-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+ gpios = <&twl_gpio 18 GPIO_ACTIVE_HIGH>;
+};
&i2c2 {
clock-frequency = <400000>;
@@ -61,6 +66,48 @@
};
};
+&lcd_3v3 {
+ gpio = <&gpio5 25 GPIO_ACTIVE_LOW>; /* gpio153 */
+ enable-active-low;
+};
+
+&lcd0 {
+ reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
+ /*
+ * The LCD is sideways, so we want the VGA mode instead of
+ * QVGA mode. Probably also want to have omapfb.rotate=3
+ * in the kernel cmdline until there's a binding for that.
+ */
+ enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */
+ &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
+ &gpio1 3 GPIO_ACTIVE_HIGH /* gpio3, lcd UD */
+ &gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
+
+ panel-timing {
+ clock-frequency = <19200000>;
+ hback-porch = <28>;
+ hactive = <480>;
+ hfront-porch = <1>;
+ hsync-len = <2>;
+ vback-porch = <1>;
+ vactive = <640>;
+ vfront-porch = <1>;
+ vsync-len = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ interrupt-parent = <&gpio6>;
+ interrupts = <15 0>; /* gpio175 */
+ pendown-gpio = <&gpio6 15 0>;
+ };
+};
+
&mmc1 {
vmmc-supply = <&vmmc1>;
vmmc_aux-supply = <&vsim>;
diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
index 0abe986..01b0808 100644
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -164,6 +164,11 @@
#include "twl4030.dtsi"
#include "twl4030_omap3.dtsi"
+#include "omap-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+ gpios = <&twl_gpio 15 GPIO_ACTIVE_LOW>;
+};
&i2c2 {
clock-frequency = <400000>;
@@ -173,6 +178,27 @@
clock-frequency = <400000>;
};
+&lcd_3v3 {
+ gpio = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+};
+
+&lcd0 {
+ reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>; /* gpio55, lcd RESB */
+ enable-gpios = <&gpio2 24 GPIO_ACTIVE_LOW /* gpio56, lcd MO */
+ 0 /* lcd LR */
+ 0 /* lcd UD */
+ 0>; /* lcd INI */
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ interrupt-parent = <&gpio2>;
+ interrupts = <22 0>; /* gpio54 */
+ pendown-gpio = <&gpio2 22 0>;
+ };
+};
+
&mmc1 {
/* See 35xx errata 2.1.1.128 in SPRZ278F */
compatible = "ti,omap3-pre-es3-hsmmc";
@@ -247,8 +273,3 @@
/* Needed for ads7846 */
regulator-name = "vcc";
};
-
-&vpll2 {
- /* Needed for DSS */
- regulator-name = "vdds_dsi";
-};
^ permalink raw reply related
* Re: [PATCH 0/4] OMAPDSS: Add support for panel ls037v7dw01
From: Tony Lindgren @ 2014-05-05 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-1-git-send-email-tony@atomide.com>
* Tony Lindgren <tony@atomide.com> [140429 16:53]:
> Hi all,
>
> Here are few patches to add devicetree support for panel ls037v7dw01
> that's found on many omap3 boards. They seem to be often mis-configured
> as various panel dpi entries, but really should be move to use panel
> ls037v7dw01 instead. This panel is found at least on the omap3 sdp,
> ldp, omap3 evm and few other development boards.
Tomi, assuming no more comments, do you want to pick up the first
three patches of this series? I can queue the .dts changes or you
can also set up a separate .dts changes branch for DSS that I can
merge in too.
Tony
> Regards,
>
> Tony
>
> Tony Lindgren (4):
> OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
> OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod
> OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
> ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and
> ldp
>
> .../bindings/panel/sharp,ls037v7dw01.txt | 53 +++++++
> .../arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi | 82 ++++++++++
> arch/arm/boot/dts/omap3-evm-37xx.dts | 50 ++++++
> arch/arm/boot/dts/omap3-evm-common.dtsi | 47 ++++++
> arch/arm/boot/dts/omap3-ldp.dts | 31 +++-
> .../omap2/displays-new/panel-sharp-ls037v7dw01.c | 176 ++++++++++++++-------
> drivers/video/fbdev/omap2/dss/dss.c | 5 +-
> 7 files changed, 379 insertions(+), 65 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> create mode 100644 arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
>
> --
> 1.8.1.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v2 0/3] Add display support for gta04 device
From: Belisko Marek @ 2014-05-07 5:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398284120-4986-1-git-send-email-marek@goldelico.com>
Tomi,
any objections to this patch set? If not can you please take it? Thanks.
On Wed, Apr 23, 2014 at 10:15 PM, Marek Belisko <marek@goldelico.com> wrote:
> This 3 patches adding display support for openmoko gta04 device.
> First patch add DT bindings for topolly td028 panel. Second add description for
> dss + panel and third fix panel probing when panel is compiled as module.
>
> Changes from v1:
> - extend panel compatible string by 'omapdss'
> - add tpo-td028 panel to dss_compat_conv_list
> - add MODULE_ALIAS macro to properly probe panel when is compiled as module
>
> Marek Belisko (3):
> omapdss: panel-tpo-td028ec1: Add DT support.
> ARM: dts: oma3-gta04: Add display support
> omapdss: panel-tpo-td028ec1: Add module alias
>
> .../bindings/video/toppoly,td028ttec1.txt | 30 ++++++++
> arch/arm/boot/dts/omap3-gta04.dts | 86 ++++++++++++++++++++++
> arch/arm/mach-omap2/display.c | 1 +
> .../omap2/displays-new/panel-tpo-td028ttec1.c | 33 ++++++++-
> 4 files changed, 149 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt
>
> --
> 1.8.3.2
>
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
* Re: [PATCH v2 2/3] ARM: dts: oma3-gta04: Add display support
From: Tomi Valkeinen @ 2014-05-07 7:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398284120-4986-3-git-send-email-marek@goldelico.com>
[-- Attachment #1: Type: text/plain, Size: 797 bytes --]
On 23/04/14 23:15, Marek Belisko wrote:
> This patch add support for lcd display on gta04 board. Display control
> is connected on spi (used spi bitbang driver).
>
> Signed-off-by: Marek Belisko <marek@goldelico.com>
> ---
> arch/arm/boot/dts/omap3-gta04.dts | 86 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 86 insertions(+)
<snip>
> +&dss {
> + pinctrl-names = "default";
> + pinctrl-0 = < &dss_dpi_pins >;
> +
> + status = "okay";
> +
> + vdds_dsi-supply = <&vpll2>;
> +
> + dpi_out: endpoint {
> + remote-endpoint = <&lcd_in>;
> + data-lines = <24>;
> + };
> +
> +};
>
Did you try this on 3.15-rc? The above is not right, and I don't think
it works. You need 'port' node for the dpi_out endpoint.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] ARM: dts: oma3-gta04: Add display support
From: Belisko Marek @ 2014-05-07 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5369DAC6.6050608@ti.com>
Hi Tomi,
On Wed, May 7, 2014 at 9:03 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 23/04/14 23:15, Marek Belisko wrote:
>> This patch add support for lcd display on gta04 board. Display control
>> is connected on spi (used spi bitbang driver).
>>
>> Signed-off-by: Marek Belisko <marek@goldelico.com>
>> ---
>> arch/arm/boot/dts/omap3-gta04.dts | 86 +++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 86 insertions(+)
>
> <snip>
>
>> +&dss {
>> + pinctrl-names = "default";
>> + pinctrl-0 = < &dss_dpi_pins >;
>> +
>> + status = "okay";
>> +
>> + vdds_dsi-supply = <&vpll2>;
>> +
>> + dpi_out: endpoint {
>> + remote-endpoint = <&lcd_in>;
>> + data-lines = <24>;
>> + };
>> +
>> +};
>>
>
> Did you try this on 3.15-rc? The above is not right, and I don't think
> it works. You need 'port' node for the dpi_out endpoint.
This patches was tested against 3.15 series and it works. I'l recheck.
>
> Tomi
>
>
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-07 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-4-git-send-email-tony@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]
On 30/04/14 02:52, Tony Lindgren wrote:
> We can pass the GPIO configuration for ls037v7dw01 in a standard
> gpios property.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> .../bindings/panel/sharp,ls037v7dw01.txt | 53 ++++++++++++++
> .../omap2/displays-new/panel-sharp-ls037v7dw01.c | 84 ++++++++++++++++++++--
> 2 files changed, 133 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
>
> diff --git a/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> new file mode 100644
> index 0000000..7f6f5e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> @@ -0,0 +1,53 @@
> +SHARP LS037V7DW01 TFT-LCD panel
> +
> +Required properties:
> +- compatible: should be "sharp,ls037v7dw01"
> +
> +Optional properties:
> +- reset-gpios: a GPIO spec for the optional reset pin
> +- enable-gpios: a GPIO array for the optional configuration GPIOs
> + ordered MO, LR, UD, INI as specified in the LS037V7DW01.pdf file.
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> +
> +This panel can have zero to five GPIOs to configure
> +to change configuration between QVGA and VGA mode
> +and the scan direction. As these pins can be also
> +configured with external pulls, all the GPIOs are
> +considered optional with holes in the array.
> +
> +Example when connected to a omap2+ based device:
> +
> + lcd0: display {
> + compatible = "sharp,ls037v7dw01";
> + power-supply = <&lcd_3v3>;
> + reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
> + enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */
> + &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
> + &gpio1 3 GPIO_ACTIVE_HIGH /* gpio3, lcd UD */
> + &gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
Why are most of the gpios in 'enable-gpios'? MO, LR and UD don't really
have anything to do with enabling the panel. Why not just have one
'gpios' array with all the gpios, as they are quite a mixed bunch?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod
From: Tomi Valkeinen @ 2014-05-07 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-3-git-send-email-tony@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]
On 30/04/14 02:52, Tony Lindgren wrote:
> Using gpiod will make it easier to add device tree support
> for this panel in the following patches.
>
> Note that all the GPIOs for this panel are optional, any
> of the the GPIOs could be configured with external pulls
> instead of GPIOs, so let's not error out if GPIOs are not
> found to make the panel more generic.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> .../omap2/displays-new/panel-sharp-ls037v7dw01.c | 92 +++++++++-------------
> 1 file changed, 38 insertions(+), 54 deletions(-)
<snip>
> +static struct gpio_desc *
> +sharp_ls_get_gpio(struct device *dev, int gpio, unsigned long flags,
> + char *desc)
> +{
> + int r;
> +
> + r = devm_gpio_request_one(dev, gpio, flags, desc);
> + if (r) {
> + dev_err(dev, "no %s gpio\n", desc);
As it's fine to not have a gpio, I guess this error print should be removed.
Also, if the error is EPROBE_DEFER, the driver should fail and return
that. The same goes for the DT version in the next patch.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 13/13] video: omap: allow building on !MMU
From: Tomi Valkeinen @ 2014-05-07 9:14 UTC (permalink / raw)
To: Peter Griffin, Arnd Bergmann, Tony Lindgren
Cc: linux-kernel, linaro-kernel, Jean-Christophe Plagniol-Villard,
linux-fbdev, linux-omap
In-Reply-To: <1398342509-10243-14-git-send-email-peter.griffin@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
On 24/04/14 15:28, Peter Griffin wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The omap lcdc driver has an elaborate mmap_kern function
> to map the frame buffer into kernel address space as
> write-combined. This uses functions that are only available
> on MMU-enabled builds.
>
> It does seem equivalent to ioremap_wc though, so we should
> be able to just use that instead.
>
> This patch is build-tested only, it needs to be run on real
> hardware before applying.
I don't have omap1 boards, and I don't know anyone that has. I don't
even know if the omap1 fb is working or not...
Tony, any idea of omap1's fb? Are you able to test this?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Tomi Valkeinen @ 2014-05-07 9:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
[-- Attachment #1: Type: text/plain, Size: 3208 bytes --]
On 30/04/14 15:36, Alexander Shiyan wrote:
>> Hmm what? So is the old driver totally broken, and cannot be used at the
>> moment? Or why you can't test on real hardware?
>
> Firstly, the driver uses a fixed values for xres, yres, pixclock and specific
> variable ac_precale.
> Secondly, the driver uses a fixed value for the physical address of the buffer.
> Totally, it does not give me the ability to use the driver in the current state.
> Unlikely that this will look good if I make these two significant changes in
> a single patch...
>
> At this time the driver has three user.
> Only one of them should theoretically work.
> clps711x-autcpu12 should not work in the absence of memblock_reserve().
> clps711x-p720t should not work due to physical address limitation as i
> noticed before. Board means to use SRAM instead of SDRAM.
> Only clps711x-edb7211 should work fine (in theory).
> Is this a good reason to replace the driver? I think yes.
Ok, if the situation is that bad, maybe we can just switch to the new
driver. Have you verified that those boards do not work from anyone? Or
asked someone to test the new driver with those boards?
I'm still not really happy about it, and I'd much rather see the current
driver fixed. But if no one having those boards is up to the task
(probably not if they have not been working at all), maybe just ditching
the old driver and adding a new is the only way forward.
One change that I think would be good is to change the series to first
remove the old driver, and then add the new one, with the same file name
as the old one. That way git log will show the history for both the new
and the old driver.
>> Note that I don't know anything about the fb hardware in question, nor
>> the driver. Maybe there's a valid reason to write a new driver from
>> scratch. But there very rarely is.
>>
>> And "because I already wrote a new driver, and it's a waste of time for
>> me to throw away my work and patch the old one", is not a very good reason.
>
>>> if you imagine a new file as a diff to the old, this can be clearly seen.
>>>
>>> There is no reason to waste time on a series of changes since I
>>> can not even check these changes on real hardware, but only in the
>>> last stage when the driver will be the current version.
>
> Summing up, I want to ask why the driver can not be reviewed as a
> new and not compared to the old?
It can, of course. But we normally should not.
Fixing the old driver will keep all the fixes and tweaks that have been
debugged and solved with the old driver. Creating a new driver easily
makes those old fixes disappear.
Fixing the old driver also keeps the history, making it possible to see
where an issue was introduced etc.
> And yes, the time can be spent on more productive things to do than
> to create a series, leading eventually to the same result.
Yes, your time. But if, say, the new driver introduces bugs that already
were fixed in the old driver, causing problems to other people, and to
me as the maintainer, I'm sure the other people and me are not going to
say "well this is ok, as this saved Alexander's time" =).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-07 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5369EAE7.3030705@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 01:13]:
> On 30/04/14 02:52, Tony Lindgren wrote:
> > We can pass the GPIO configuration for ls037v7dw01 in a standard
> > gpios property.
> >
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> > .../bindings/panel/sharp,ls037v7dw01.txt | 53 ++++++++++++++
> > .../omap2/displays-new/panel-sharp-ls037v7dw01.c | 84 ++++++++++++++++++++--
> > 2 files changed, 133 insertions(+), 4 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> >
> > diff --git a/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> > new file mode 100644
> > index 0000000..7f6f5e1
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
> > @@ -0,0 +1,53 @@
> > +SHARP LS037V7DW01 TFT-LCD panel
> > +
> > +Required properties:
> > +- compatible: should be "sharp,ls037v7dw01"
> > +
> > +Optional properties:
> > +- reset-gpios: a GPIO spec for the optional reset pin
> > +- enable-gpios: a GPIO array for the optional configuration GPIOs
> > + ordered MO, LR, UD, INI as specified in the LS037V7DW01.pdf file.
> > +
> > +This binding is compatible with the simple-panel binding, which is specified
> > +in simple-panel.txt in this directory.
> > +
> > +This panel can have zero to five GPIOs to configure
> > +to change configuration between QVGA and VGA mode
> > +and the scan direction. As these pins can be also
> > +configured with external pulls, all the GPIOs are
> > +considered optional with holes in the array.
> > +
> > +Example when connected to a omap2+ based device:
> > +
> > + lcd0: display {
> > + compatible = "sharp,ls037v7dw01";
> > + power-supply = <&lcd_3v3>;
> > + reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
> > + enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */
> > + &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
> > + &gpio1 3 GPIO_ACTIVE_HIGH /* gpio3, lcd UD */
> > + &gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
>
> Why are most of the gpios in 'enable-gpios'? MO, LR and UD don't really
> have anything to do with enabling the panel. Why not just have one
> 'gpios' array with all the gpios, as they are quite a mixed bunch?
Yeah that's what I had initially, but reading simple-panel.txt noticed
there are some standardized GPIOs for reset and enable.
How about we set up one reset-gpios, one enable-gpios and an array of
three unlabelled GPIOs?
Or if we want to add something generic, we could add new mode-gpios
property that other panels might be able to use too?
BTW, I'm also personally fine with all five gpios showing in a single
gpios property, I'm not too exited about naming anything in DT..
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-07 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140507150343.GA9502@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]
On 07/05/14 18:03, Tony Lindgren wrote:
>>> + lcd0: display {
>>> + compatible = "sharp,ls037v7dw01";
>>> + power-supply = <&lcd_3v3>;
>>> + reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
>>> + enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */
>>> + &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
>>> + &gpio1 3 GPIO_ACTIVE_HIGH /* gpio3, lcd UD */
>>> + &gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
>>
>> Why are most of the gpios in 'enable-gpios'? MO, LR and UD don't really
>> have anything to do with enabling the panel. Why not just have one
>> 'gpios' array with all the gpios, as they are quite a mixed bunch?
>
> Yeah that's what I had initially, but reading simple-panel.txt noticed
> there are some standardized GPIOs for reset and enable.
I'm not sure if it's worth to try to make it compatible with
simple-panel. simple-panel bindings do not work with omapdss anyway, and
simple-panel doesn't have the support for input ports/endpoints.
Can the panel be used with only one gpio (I guess that would be INI or
RESB)? If not, simple-panel doesn't work.
> How about we set up one reset-gpios, one enable-gpios and an array of
> three unlabelled GPIOs?
>
> Or if we want to add something generic, we could add new mode-gpios
> property that other panels might be able to use too?
>
> BTW, I'm also personally fine with all five gpios showing in a single
> gpios property, I'm not too exited about naming anything in DT..
I don't have a strong opinion here. I don't have much experience with
DT, especially with making bindings compatible with other ones.
I'd just forget the simple-panel, and have single gpio array.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-07 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <536A5920.1020908@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 09:03]:
> On 07/05/14 18:03, Tony Lindgren wrote:
>
> >>> + lcd0: display {
> >>> + compatible = "sharp,ls037v7dw01";
> >>> + power-supply = <&lcd_3v3>;
> >>> + reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
> >>> + enable-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */
> >>> + &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
> >>> + &gpio1 3 GPIO_ACTIVE_HIGH /* gpio3, lcd UD */
> >>> + &gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
> >>
> >> Why are most of the gpios in 'enable-gpios'? MO, LR and UD don't really
> >> have anything to do with enabling the panel. Why not just have one
> >> 'gpios' array with all the gpios, as they are quite a mixed bunch?
> >
> > Yeah that's what I had initially, but reading simple-panel.txt noticed
> > there are some standardized GPIOs for reset and enable.
>
> I'm not sure if it's worth to try to make it compatible with
> simple-panel. simple-panel bindings do not work with omapdss anyway, and
> simple-panel doesn't have the support for input ports/endpoints.
>
> Can the panel be used with only one gpio (I guess that would be INI or
> RESB)? If not, simple-panel doesn't work.
I guess in theory yes.
> > How about we set up one reset-gpios, one enable-gpios and an array of
> > three unlabelled GPIOs?
> >
> > Or if we want to add something generic, we could add new mode-gpios
> > property that other panels might be able to use too?
> >
> > BTW, I'm also personally fine with all five gpios showing in a single
> > gpios property, I'm not too exited about naming anything in DT..
>
> I don't have a strong opinion here. I don't have much experience with
> DT, especially with making bindings compatible with other ones.
>
> I'd just forget the simple-panel, and have single gpio array.
Well if it's a don't care flag for both of us, let's try to use
the existing standard for simple-panel.txt and add mode-gpios
property. I'll post a patch for that.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new C =?UTF-8?B?aXJydXMgTG9naWMgQ
From: Alexander Shiyan @ 2014-05-08 8:27 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1398327006.501536964@f133.i.mail.ru>
V2VkLCA3IE1heSAyMDE0IDEyOjQwOjQ5ICswMzAwINC+0YIgVG9taSBWYWxrZWluZW4gPHRvbWku
dmFsa2VpbmVuQHRpLmNvbT46Cj4gT24gMzAvMDQvMTQgMTU6MzYsIEFsZXhhbmRlciBTaGl5YW4g
d3JvdGU6Cj4gCj4gPj4gSG1tIHdoYXQ/IFNvIGlzIHRoZSBvbGQgZHJpdmVyIHRvdGFsbHkgYnJv
a2VuLCBhbmQgY2Fubm90IGJlIHVzZWQgYXQgdGhlCj4gPj4gbW9tZW50PyBPciB3aHkgeW91IGNh
bid0IHRlc3Qgb24gcmVhbCBoYXJkd2FyZT8KPiA+IAo+ID4gRmlyc3RseSwgdGhlIGRyaXZlciB1
c2VzIGEgZml4ZWQgdmFsdWVzIGZvciB4cmVzLCB5cmVzLCBwaXhjbG9jayBhbmQgc3BlY2lmaWMK
PiA+IHZhcmlhYmxlIGFjX3ByZWNhbGUuCj4gPiBTZWNvbmRseSwgdGhlIGRyaXZlciB1c2VzIGEg
Zml4ZWQgdmFsdWUgZm9yIHRoZSBwaHlzaWNhbCBhZGRyZXNzIG9mIHRoZSBidWZmZXIuCj4gPiBU
b3RhbGx5LCBpdCBkb2VzIG5vdCBnaXZlIG1lIHRoZSBhYmlsaXR5IHRvIHVzZSB0aGUgZHJpdmVy
IGluIHRoZSBjdXJyZW50IHN0YXRlLgo+ID4gVW5saWtlbHkgdGhhdCB0aGlzIHdpbGwgbG9vayBn
b29kIGlmIEkgbWFrZSB0aGVzZSB0d28gc2lnbmlmaWNhbnQgY2hhbmdlcyBpbgo+ID4gYSBzaW5n
bGUgcGF0Y2guLi4KPiA+IAo+ID4gQXQgdGhpcyB0aW1lIHRoZSBkcml2ZXIgaGFzIHRocmVlIHVz
ZXIuCj4gPiBPbmx5IG9uZSBvZiB0aGVtIHNob3VsZCB0aGVvcmV0aWNhbGx5IHdvcmsuCj4gPiBj
bHBzNzExeC1hdXRjcHUxMiBzaG91bGQgbm90IHdvcmsgaW4gdGhlIGFic2VuY2Ugb2YgbWVtYmxv
Y2tfcmVzZXJ2ZSgpLgo+ID4gY2xwczcxMXgtcDcyMHQgc2hvdWxkIG5vdCB3b3JrIGR1ZSB0byBw
aHlzaWNhbCBhZGRyZXNzIGxpbWl0YXRpb24gYXMgaQo+ID4gbm90aWNlZCBiZWZvcmUuIEJvYXJk
IG1lYW5zIHRvIHVzZSBTUkFNIGluc3RlYWQgb2YgU0RSQU0uCj4gPiBPbmx5IGNscHM3MTF4LWVk
YjcyMTEgc2hvdWxkIHdvcmsgZmluZSAoaW4gdGhlb3J5KS4KPiA+IElzIHRoaXMgYSBnb29kIHJl
YXNvbiB0byByZXBsYWNlIHRoZSBkcml2ZXI/IEkgdGhpbmsgeWVzLgo+IAo+IE9rLCBpZiB0aGUg
c2l0dWF0aW9uIGlzIHRoYXQgYmFkLCBtYXliZSB3ZSBjYW4ganVzdCBzd2l0Y2ggdG8gdGhlIG5l
dwo+IGRyaXZlci4gSGF2ZSB5b3UgdmVyaWZpZWQgdGhhdCB0aG9zZSBib2FyZHMgZG8gbm90IHdv
cmsgZnJvbSBhbnlvbmU/IE9yCj4gYXNrZWQgc29tZW9uZSB0byB0ZXN0IHRoZSBuZXcgZHJpdmVy
IHdpdGggdGhvc2UgYm9hcmRzPwoKSSdtIG5vdCBmYW1pbGlhciB3aXRoIG90aGVyIHVzZXJzIG9m
IHRoaXMgcGxhdGZvcm0gLgpJIGFtIGRvIG5vdCBoYXZlIHRoZXNlIGJvYXJkcywgYWxsIHRoYXQg
SSBoYXZlIHdyaXR0ZW4gYmVmb3JlIHRoYXQgaXQncyBqdXN0IGEgdGhlb3J5LgpGaXJtIGluIHdo
aWNoIEkgd29yaywgdXNlcyBpdHMgb3duIGJvYXJkIHdpdGggQ0xQUzcxMVggQ1BVICwgdGhpcyBi
b2FyZCBpcyB0aGUKb25seSB3YXkgdG8gY2hlY2sgZm9yIGNoYW5nZXMgb24gcmVhbCBoYXJkd2Fy
ZSAuCgo+IEknbSBzdGlsbCBub3QgcmVhbGx5IGhhcHB5IGFib3V0IGl0LCBhbmQgSSdkIG11Y2gg
cmF0aGVyIHNlZSB0aGUgY3VycmVudAo+IGRyaXZlciBmaXhlZC4gQnV0IGlmIG5vIG9uZSBoYXZp
bmcgdGhvc2UgYm9hcmRzIGlzIHVwIHRvIHRoZSB0YXNrCj4gKHByb2JhYmx5IG5vdCBpZiB0aGV5
IGhhdmUgbm90IGJlZW4gd29ya2luZyBhdCBhbGwpLCBtYXliZSBqdXN0IGRpdGNoaW5nCj4gdGhl
IG9sZCBkcml2ZXIgYW5kIGFkZGluZyBhIG5ldyBpcyB0aGUgb25seSB3YXkgZm9yd2FyZC4KPiAK
PiBPbmUgY2hhbmdlIHRoYXQgSSB0aGluayB3b3VsZCBiZSBnb29kIGlzIHRvIGNoYW5nZSB0aGUg
c2VyaWVzIHRvIGZpcnN0Cj4gcmVtb3ZlIHRoZSBvbGQgZHJpdmVyLCBhbmQgdGhlbiBhZGQgdGhl
IG5ldyBvbmUsIHdpdGggdGhlIHNhbWUgZmlsZSBuYW1lCj4gYXMgdGhlIG9sZCBvbmUuIFRoYXQg
d2F5IGdpdCBsb2cgd2lsbCBzaG93IHRoZSBoaXN0b3J5IGZvciBib3RoIHRoZSBuZXcKPiBhbmQg
dGhlIG9sZCBkcml2ZXIuCgpJbiB0aGlzIGNhc2UgZ2l0LWJpc2VjdCB3aWxsIGJlIGJyb2tlbi4g
SXMgdGhpcyBPSz8KCi0tLQoK
^ permalink raw reply
* [RFC 1/6] omapdss: remove check for simpler port/endpoint binding
From: Archit Taneja @ 2014-05-08 9:27 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-fbdev, linux-omap, Archit Taneja
The support for simpler port/endpoint binding was removed in the merged version
of omapdss DT. But dss_init_ports still tries to get to an endpoint even if no
port exists. Remove this as this doesn't work.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/fbdev/omap2/dss/dss.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
index d55266c..31ef262 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -784,12 +784,8 @@ static int __init dss_init_ports(struct platform_device *pdev)
return 0;
port = omapdss_of_get_next_port(parent, NULL);
- if (!port) {
-#ifdef CONFIG_OMAP2_DSS_DPI
- dpi_init_port(pdev, parent);
-#endif
+ if (!port)
return 0;
- }
do {
u32 reg;
--
1.8.3.2
^ permalink raw reply related
* [RFC 2/6] omapdss: add init port functions for different omap revs
From: Archit Taneja @ 2014-05-08 9:27 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1399540517-17883-1-git-send-email-archit@ti.com>
The init/uninit port functions are used to set up the DPI and SDI outputs under
the dss platform device. A 'reg' property is used to determine whether the node
is DPI or SDI for OMAP34xx DSS revision. For other DSS revisions, only DPI
output exists.
For multiple DPI output instances(introduced in DRA7xx DSS), we would use the
'reg' property to specify the DPI output number.
The current functions work fine if there is only one DPI output instance in
DSS. For multiple DPI instances, it would get complicated to figure out whether
'reg' is used to specify whether the output is SDI, or a later DPI instance.
Create DSS revision specific init/uninit_port functions such that we have a
separate functions for OMAP34xx, this helps us deal with the SDI case
separately.
Also, make the uninit_port functions iterative since we will have multiple DPI
ports in the future.
dpi_uninit_port/sdi_uninit_port functions have to be removed from the exit
section as dss_features(which is initconst data) uses it, this prevents the
section mismatch.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/fbdev/omap2/dss/dpi.c | 2 +-
drivers/video/fbdev/omap2/dss/dss.c | 88 ++++++++++++++++++++++++++++++++++---
drivers/video/fbdev/omap2/dss/dss.h | 4 +-
drivers/video/fbdev/omap2/dss/sdi.c | 2 +-
4 files changed, 86 insertions(+), 10 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dpi.c b/drivers/video/fbdev/omap2/dss/dpi.c
index 157921d..6593c8b 100644
--- a/drivers/video/fbdev/omap2/dss/dpi.c
+++ b/drivers/video/fbdev/omap2/dss/dpi.c
@@ -765,7 +765,7 @@ err_datalines:
return r;
}
-void __exit dpi_uninit_port(void)
+void dpi_uninit_port(struct platform_device *pdev, struct device_node *port)
{
if (!dpi.port_initialized)
return;
diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
index 31ef262..c415029 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -65,12 +65,18 @@ struct dss_reg {
static int dss_runtime_get(void);
static void dss_runtime_put(void);
+static int __init dss_init_ports(struct platform_device *pdev);
+static int __init dss_init_ports_omap34xx(struct platform_device *pdev);
+static void dss_uninit_ports(struct platform_device *pdev);
+static void dss_uninit_ports_omap34xx(struct platform_device *pdev);
struct dss_features {
u8 fck_div_max;
u8 dss_fck_multiplier;
const char *parent_clk_name;
int (*dpi_select_source)(enum omap_channel channel);
+ int (*init_ports)(struct platform_device *pdev);
+ void (*uninit_ports)(struct platform_device *pdev);
};
static struct {
@@ -698,6 +704,8 @@ static const struct dss_features omap24xx_dss_feats __initconst = {
.dss_fck_multiplier = 2,
.parent_clk_name = "core_ck",
.dpi_select_source = &dss_dpi_select_source_omap2_omap3,
+ .init_ports = &dss_init_ports,
+ .uninit_ports = &dss_uninit_ports,
};
static const struct dss_features omap34xx_dss_feats __initconst = {
@@ -705,6 +713,8 @@ static const struct dss_features omap34xx_dss_feats __initconst = {
.dss_fck_multiplier = 2,
.parent_clk_name = "dpll4_ck",
.dpi_select_source = &dss_dpi_select_source_omap2_omap3,
+ .init_ports = &dss_init_ports_omap34xx,
+ .uninit_ports = &dss_uninit_ports_omap34xx,
};
static const struct dss_features omap3630_dss_feats __initconst = {
@@ -712,6 +722,8 @@ static const struct dss_features omap3630_dss_feats __initconst = {
.dss_fck_multiplier = 1,
.parent_clk_name = "dpll4_ck",
.dpi_select_source = &dss_dpi_select_source_omap2_omap3,
+ .init_ports = &dss_init_ports,
+ .uninit_ports = &dss_uninit_ports,
};
static const struct dss_features omap44xx_dss_feats __initconst = {
@@ -719,6 +731,8 @@ static const struct dss_features omap44xx_dss_feats __initconst = {
.dss_fck_multiplier = 1,
.parent_clk_name = "dpll_per_x2_ck",
.dpi_select_source = &dss_dpi_select_source_omap4,
+ .init_ports = &dss_init_ports,
+ .uninit_ports = &dss_uninit_ports,
};
static const struct dss_features omap54xx_dss_feats __initconst = {
@@ -726,6 +740,8 @@ static const struct dss_features omap54xx_dss_feats __initconst = {
.dss_fck_multiplier = 1,
.parent_clk_name = "dpll_per_x2_ck",
.dpi_select_source = &dss_dpi_select_source_omap5,
+ .init_ports = &dss_init_ports,
+ .uninit_ports = &dss_uninit_ports,
};
static int __init dss_init_features(struct platform_device *pdev)
@@ -774,7 +790,7 @@ static int __init dss_init_features(struct platform_device *pdev)
return 0;
}
-static int __init dss_init_ports(struct platform_device *pdev)
+static int __init dss_init_ports_omap34xx(struct platform_device *pdev)
{
struct device_node *parent = pdev->dev.of_node;
struct device_node *port;
@@ -809,15 +825,75 @@ static int __init dss_init_ports(struct platform_device *pdev)
return 0;
}
-static void dss_uninit_ports(void)
+static int __init dss_init_ports(struct platform_device *pdev)
{
+ struct device_node *parent = pdev->dev.of_node;
+ struct device_node *port;
+
+ if (parent = NULL)
+ return 0;
+
+ port = omapdss_of_get_next_port(parent, NULL);
+ if (!port)
+ return 0;
+
+ do {
#ifdef CONFIG_OMAP2_DSS_DPI
- dpi_uninit_port();
+ dpi_init_port(pdev, port);
+#endif
+ } while ((port = omapdss_of_get_next_port(parent, port)) != NULL);
+
+ return 0;
+}
+
+static void dss_uninit_ports_omap34xx(struct platform_device *pdev)
+{
+ struct device_node *parent = pdev->dev.of_node;
+ struct device_node *port;
+ int r;
+
+ if (parent = NULL)
+ return;
+
+ port = omapdss_of_get_next_port(parent, NULL);
+ if (!port)
+ return;
+
+ do {
+ u32 reg;
+
+ r = of_property_read_u32(port, "reg", ®);
+ if (r)
+ reg = 0;
+
+#ifdef CONFIG_OMAP2_DSS_DPI
+ if (reg = 0)
+ dpi_uninit_port(pdev, port);
#endif
#ifdef CONFIG_OMAP2_DSS_SDI
- sdi_uninit_port();
+ if (reg = 1)
+ sdi_uninit_port();
#endif
+ } while ((port = omapdss_of_get_next_port(parent, port)) != NULL);
+}
+
+static void dss_uninit_ports(struct platform_device *pdev)
+{
+ struct device_node *parent = pdev->dev.of_node;
+ struct device_node *port;
+
+ if (parent = NULL)
+ return;
+
+ port = omapdss_of_get_next_port(parent, NULL);
+ if (!port)
+ return;
+ do {
+#ifdef CONFIG_OMAP2_DSS_DPI
+ dpi_uninit_port(pdev, port);
+#endif
+ } while ((port = omapdss_of_get_next_port(parent, port)) != NULL);
}
/* DSS HW IP initialisation */
@@ -878,7 +954,7 @@ static int __init omap_dsshw_probe(struct platform_device *pdev)
dss.lcd_clk_source[0] = OMAP_DSS_CLK_SRC_FCK;
dss.lcd_clk_source[1] = OMAP_DSS_CLK_SRC_FCK;
- dss_init_ports(pdev);
+ dss.feat->init_ports(pdev);
rev = dss_read_reg(DSS_REVISION);
printk(KERN_INFO "OMAP DSS rev %d.%d\n",
@@ -899,7 +975,7 @@ err_setup_clocks:
static int __exit omap_dsshw_remove(struct platform_device *pdev)
{
- dss_uninit_ports();
+ dss.feat->uninit_ports(pdev);
pm_runtime_disable(&pdev->dev);
diff --git a/drivers/video/fbdev/omap2/dss/dss.h b/drivers/video/fbdev/omap2/dss/dss.h
index 560078f..9f4ee49 100644
--- a/drivers/video/fbdev/omap2/dss/dss.h
+++ b/drivers/video/fbdev/omap2/dss/dss.h
@@ -245,7 +245,7 @@ int sdi_init_platform_driver(void) __init;
void sdi_uninit_platform_driver(void) __exit;
int sdi_init_port(struct platform_device *pdev, struct device_node *port) __init;
-void sdi_uninit_port(void) __exit;
+void sdi_uninit_port(void);
/* DSI */
@@ -359,7 +359,7 @@ int dpi_init_platform_driver(void) __init;
void dpi_uninit_platform_driver(void) __exit;
int dpi_init_port(struct platform_device *pdev, struct device_node *port) __init;
-void dpi_uninit_port(void) __exit;
+void dpi_uninit_port(struct platform_device *pdev, struct device_node *port);
/* DISPC */
int dispc_init_platform_driver(void) __init;
diff --git a/drivers/video/fbdev/omap2/dss/sdi.c b/drivers/video/fbdev/omap2/dss/sdi.c
index 911dcc9..71a3083 100644
--- a/drivers/video/fbdev/omap2/dss/sdi.c
+++ b/drivers/video/fbdev/omap2/dss/sdi.c
@@ -424,7 +424,7 @@ err_datapairs:
return r;
}
-void __exit sdi_uninit_port(void)
+void sdi_uninit_port(void)
{
if (!sdi.port_initialized)
return;
--
1.8.3.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