* Re: [PATCH v11 6/6] devicetree: Add SKY81452 to the Trivial Devices list
From: Lee Jones @ 2015-03-09 9:41 UTC (permalink / raw)
To: gyungoh
Cc: sameo, robh+dt, jg1.han, pawel.moll, mark.rutland, ijc+devicetree,
galak, trivial, broonie, florian.vaussard, andrew, antonynpavlov,
hytszk, plagnioj, tomi.valkeinen, jack.yoo, linux-fbdev,
linux-kernel, devicetree, treding, p.zabel, arno,
kuninori.morimoto.gx
In-Reply-To: <1425019346-4559-7-git-send-email-jack.yoo@skyworksinc.com>
Applied, thanks.
On Fri, 27 Feb 2015, gyungoh@gmail.com wrote:
> From: Gyungoh Yoo <jack.yoo@skyworksinc.com>
>
> Signed-off-by: Gyungoh Yoo <jack.yoo@skyworksinc.com>
> ---
> Changes v11:
> Nothing
>
> Changes v10:
> Nothing
>
> Changes v9:
> Nothing
>
> Changes v8:
> Nothing
>
> Changes v7:
> Nothing
>
> Changes v6:
> Nothing
>
> Changes v5:
> Nothing
>
> Changes v4:
> Nothing
>
> Changes v3:
> Nothing
>
> Changes v2:
> Add SKY81452 to the Trivial Devices list
>
> Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> index aaa8325..003bd77 100644
> --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> @@ -89,6 +89,7 @@ ricoh,rv5c386 I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
> ricoh,rv5c387a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
> samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
> sii,s35390a 2-wire CMOS real-time clock
> +skyworks,sky81452 Skyworks SKY81452: Six-Channel White LED Driver with Touch Panel Bias Supply
> st-micro,24c256 i2c serial eeprom (24cxx)
> stm,m41t00 Serial Access TIMEKEEPER
> stm,m41t62 Serial real-time clock (RTC) with alarm
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 1/4] staging: sm750fb: wrong type for print
From: Sudip Mukherjee @ 2015-03-09 9:47 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Greg Kroah-Hartman, devel, linux-fbdev, linux-kernel
In-Reply-To: <20150309092209.GB10964@mwanda>
On Mon, Mar 09, 2015 at 12:22:09PM +0300, Dan Carpenter wrote:
> On Sun, Mar 08, 2015 at 06:01:23PM +0530, Sudip Mukherjee wrote:
> > diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
> > index 711676c..2ab7b74 100644
> > --- a/drivers/staging/sm750fb/sm750.h
> > +++ b/drivers/staging/sm750fb/sm750.h
> > @@ -59,10 +59,10 @@ struct lynx_share{
> > }mtrr;
> > #endif
> > /* all smi graphic adaptor got below attributes */
> > - resource_size_t vidmem_start;
> > - resource_size_t vidreg_start;
> > - resource_size_t vidmem_size;
> > - resource_size_t vidreg_size;
> > + unsigned long vidmem_start;
> > + unsigned long vidreg_start;
> > + unsigned long vidmem_size;
> > + unsigned long vidreg_size;
> > volatile unsigned char __iomem * pvReg;
> > unsigned char __iomem * pvMem;
> > /* locks*/
>
> This seems like a very risky sort of change. It's not explained very
> well in the changelog. What's the deal?
it mainly started with the build warnings of incorrect format specifier.
v2 gives a little more details in the comments section. copying that here for your convenience:
"V2: Giedrius commented resource_size_t can be either u64 or u32
depending on if CONFIG_PHYS_ADDR_T_64BIT. based on his comments i
should have kept the datatype as resource_size_t and used %pa as the
format specifier. But since this is a framebuffer device and it
should follow what the framebuffer layer is suggesting in
struct fb_fix_screeninfo at smem_start and mmio_start."
so accoringly, like all other framebuffer devices, vidmem_start and vidreg_start should be unsigned long and vidmem_size and vidreg_size should be __u32.
regards
sudip
>
> regards,
> dan carpenter
>
^ permalink raw reply
* Re: [PATCH v2 1/4] staging: sm750fb: wrong type for print
From: Dan Carpenter @ 2015-03-09 11:53 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Tomi Valkeinen, Greg Kroah-Hartman, devel, linux-fbdev,
linux-kernel
In-Reply-To: <1425886506-8643-1-git-send-email-sudipm.mukherjee@gmail.com>
On Mon, Mar 09, 2015 at 01:05:03PM +0530, Sudip Mukherjee wrote:
> mention correct format specifier while printing.
> fixes all the build warnings about incorrect argument type while
> printing.
>
> Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
> ---
>
> V2: Giedrius commented resource_size_t can be either u64 or u32
> depending on if CONFIG_PHYS_ADDR_T_64BIT. based on his comments i
> should have kept the datatype as resource_size_t and used %pa as the
> format specifier. But since this is a framebuffer device and it
> should follow what the framebuffer layer is suggesting in
> struct fb_fix_screeninfo at smem_start and mmio_start.
> adding Tomi for his comments.
This should all have gone into the changelog because it changes how the
code works.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v2 1/4] staging: sm750fb: wrong type for print
From: Sudip Mukherjee @ 2015-03-09 12:23 UTC (permalink / raw)
To: Dan Carpenter
Cc: Tomi Valkeinen, Greg Kroah-Hartman, devel, linux-fbdev,
linux-kernel
In-Reply-To: <20150309115337.GD10964@mwanda>
On Mon, Mar 09, 2015 at 02:53:37PM +0300, Dan Carpenter wrote:
> On Mon, Mar 09, 2015 at 01:05:03PM +0530, Sudip Mukherjee wrote:
> >
> > V2: Giedrius commented resource_size_t can be either u64 or u32
> > depending on if CONFIG_PHYS_ADDR_T_64BIT. based on his comments i
> > should have kept the datatype as resource_size_t and used %pa as the
> > format specifier. But since this is a framebuffer device and it
> > should follow what the framebuffer layer is suggesting in
> > struct fb_fix_screeninfo at smem_start and mmio_start.
> > adding Tomi for his comments.
>
>
> This should all have gone into the changelog because it changes how the
> code works.
ok, then should i send a v3 of only this patch or the whole series?
regards
sudip
>
> regards,
> dan carpenter
>
^ permalink raw reply
* Re: [PATCH v2 4/4] staging: sm750fb: fix undeclared function
From: Dan Carpenter @ 2015-03-09 12:42 UTC (permalink / raw)
To: Sudip Mukherjee; +Cc: Greg Kroah-Hartman, devel, linux-fbdev, linux-kernel
In-Reply-To: <1425886506-8643-4-git-send-email-sudipm.mukherjee@gmail.com>
On Mon, Mar 09, 2015 at 01:05:06PM +0530, Sudip Mukherjee wrote:
> kbuild test robot reported that for microblaze-allyesconfig
> chan_to_field() and lynxfb_ops_set_par() were not defined. These two
> functions were defined under CONFIG_PM, so for any archtecture if
> CONFIG_PM is not defined we will have this error.
>
> while moving the lynxfb_suspend() function some very obvious
> checkpatch errors, like space after comma, space after if, space
> before opening brace, were taken care of.
I have a script to review patches moving functions around but these
white space changes break my script so I have to review it by hand.
Sucks.
> static int lynxfb_ops_set_par(struct fb_info * info)
> {
> struct lynxfb_par * par;
> @@ -369,7 +313,6 @@ static int lynxfb_ops_set_par(struct fb_info * info)
> struct fb_fix_screeninfo * fix;
> int ret;
> unsigned int line_length;
> -
>
> if(!info)
> return -EINVAL;
> @@ -441,6 +384,7 @@ static int lynxfb_ops_set_par(struct fb_info * info)
> ret = output->proc_setMode(output,var,fix);
> return ret;
> }
> +
> static inline unsigned int chan_to_field(unsigned int chan,struct fb_bitfield * bf)
> {
> chan &= 0xffff;
These white space changes are not related.
regards,
dan carpenter
^ permalink raw reply
* [GIT PULL] fbdev fixes for 4.0
From: Tomi Valkeinen @ 2015-03-09 12:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Fbdev development list, LKML
[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]
Hi Linus,
Please pull fbdev fixes:
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:
Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/fbdev-fixes-4.0
for you to fetch changes up to a38bb793eaebe1178fbd8ef6ab66ccc062bad505:
OMAPDSS: fix regression with display sysfs files (2015-02-26 10:23:15 +0200)
----------------------------------------------------------------
fbdev fixes for 4.0
* Fix regression in with omapdss when using i2c displays
* Fix possible null deref in fbmon
* Check kalloc return value in AMBA CLCD
----------------------------------------------------------------
Kiran Padwal (1):
video: ARM CLCD: Add missing error check for devm_kzalloc
Sudip Mukherjee (1):
video: fbdev: fix possible null dereference
Tomi Valkeinen (1):
OMAPDSS: fix regression with display sysfs files
drivers/video/fbdev/amba-clcd.c | 3 +
drivers/video/fbdev/core/fbmon.c | 6 +-
drivers/video/fbdev/omap2/dss/display-sysfs.c | 179 ++++++++++++++------------
include/video/omapdss.h | 1 +
4 files changed, 102 insertions(+), 87 deletions(-)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 4/4] staging: sm750fb: fix undeclared function
From: Sudip Mukherjee @ 2015-03-09 12:55 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Greg Kroah-Hartman, devel, linux-fbdev, linux-kernel
In-Reply-To: <20150309124222.GE10964@mwanda>
On Mon, Mar 09, 2015 at 03:42:22PM +0300, Dan Carpenter wrote:
> On Mon, Mar 09, 2015 at 01:05:06PM +0530, Sudip Mukherjee wrote:
> > kbuild test robot reported that for microblaze-allyesconfig
> > chan_to_field() and lynxfb_ops_set_par() were not defined. These two
> > functions were defined under CONFIG_PM, so for any archtecture if
> > CONFIG_PM is not defined we will have this error.
> >
> > while moving the lynxfb_suspend() function some very obvious
> > checkpatch errors, like space after comma, space after if, space
> > before opening brace, were taken care of.
>
> I have a script to review patches moving functions around but these
> white space changes break my script so I have to review it by hand.
> Sucks.
oops . sorry ..
>
> > static int lynxfb_ops_set_par(struct fb_info * info)
<snip>
> > static inline unsigned int chan_to_field(unsigned int chan,struct fb_bitfield * bf)
> > {
> > chan &= 0xffff;
>
> These white space changes are not related.
if you want i can break it into multiple patches, so that reviewing can be easy and your script will not break :) .
Actually I thought, since this is a vendor crude driver there will be many such changes, so if i can combine some changes together then atleast the number of patches can be kept low and also i thought of clubbing these changes together as Joe Perches once told me "Don't get carried away with patch type separation" (reference: https://lkml.org/lkml/2015/1/1/2).
regards
sudip
>
> regards,
> dan carpenter
>
^ permalink raw reply
* Re: [PATCH 3/3] staging: sm7xxfb: change return of sm7xx_vga_setup
From: Dan Carpenter @ 2015-03-09 13:13 UTC (permalink / raw)
To: Sudip Mukherjee; +Cc: Greg Kroah-Hartman, devel, linux-fbdev, linux-kernel
In-Reply-To: <1425836411-15481-3-git-send-email-sudipm.mukherjee@gmail.com>
On Sun, Mar 08, 2015 at 11:10:11PM +0530, Sudip Mukherjee wrote:
> change return type of sm7xx_vga_setup() to void as we are not using
> the return type anywhere. if this function fails we fall back to the
> default configuration.
>
> Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
This patch is fine but if you wanted you could send a follow on which
set it to SCREEN_X_RES, SCREEN_Y_RES, SCREEN_BPP if there were no
options. Then remove the "if (smtc_scr_info.lfb_width != 0) " condition
in smtcfb_pci_probe().
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v2 4/4] staging: sm750fb: fix undeclared function
From: Dan Carpenter @ 2015-03-09 13:29 UTC (permalink / raw)
To: Sudip Mukherjee; +Cc: devel, Greg Kroah-Hartman, linux-fbdev, linux-kernel
In-Reply-To: <20150309125503.GB11724@sudip-PC>
On Mon, Mar 09, 2015 at 06:25:03PM +0530, Sudip Mukherjee wrote:
> Actually I thought, since this is a vendor crude driver there will be many such changes, so if i can combine some changes together then atleast the number of patches can be kept low and also i thought of clubbing these changes together as Joe Perches once told me "Don't get carried away with patch type separation" (reference: https://lkml.org/lkml/2015/1/1/2).
How to break up patches is more art than science. I wouldn't have
complained about the minor extra white space changes except that I was
already going to email you about breaking my scripts.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 3/3] staging: sm7xxfb: change return of sm7xx_vga_setup
From: Dan Carpenter @ 2015-03-09 13:38 UTC (permalink / raw)
To: Sudip Mukherjee, Greg Kroah-Hartman; +Cc: devel, linux-fbdev, linux-kernel
In-Reply-To: <20150309133032.GA13002@sudip-PC>
On Mon, Mar 09, 2015 at 07:00:33PM +0530, Sudip Mukherjee wrote:
> On Mon, Mar 09, 2015 at 04:13:43PM +0300, Dan Carpenter wrote:
> > On Sun, Mar 08, 2015 at 11:10:11PM +0530, Sudip Mukherjee wrote:
> > > change return type of sm7xx_vga_setup() to void as we are not using
> > > the return type anywhere. if this function fails we fall back to the
> > > default configuration.
> > >
> > > Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
> >
> > Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
> >
> > This patch is fine but if you wanted you could send a follow on which
> > set it to SCREEN_X_RES, SCREEN_Y_RES, SCREEN_BPP if there were no
> > options. Then remove the "if (smtc_scr_info.lfb_width != 0) " condition
> > in smtcfb_pci_probe().
>
> yes, i could have. But actually I am thinking to totally remove this function and use more conventional fb_get_mode() in its places. But if i do so then the boot parameters will change. Currently it is like vga=sm712fb:0x301 but if i change it to use fb_get_mode() then the boot parameters will change to vga=sm712fb:640x480@60-8 , and that is why I am hesitating. But it will be more conventional to what all framebuffer drivers follows.
>
Hm... That's a good question.
I suspect we should just go with fb_get_mode() and do it quickly. This
driver is so new in the kernel that there are no users to get upset.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 3/3] staging: sm7xxfb: change return of sm7xx_vga_setup
From: Sudip Mukherjee @ 2015-03-09 13:42 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Greg Kroah-Hartman, devel, linux-fbdev, linux-kernel
In-Reply-To: <20150309131343.GG10964@mwanda>
On Mon, Mar 09, 2015 at 04:13:43PM +0300, Dan Carpenter wrote:
> On Sun, Mar 08, 2015 at 11:10:11PM +0530, Sudip Mukherjee wrote:
> > change return type of sm7xx_vga_setup() to void as we are not using
> > the return type anywhere. if this function fails we fall back to the
> > default configuration.
> >
> > Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
>
> Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> This patch is fine but if you wanted you could send a follow on which
> set it to SCREEN_X_RES, SCREEN_Y_RES, SCREEN_BPP if there were no
> options. Then remove the "if (smtc_scr_info.lfb_width != 0) " condition
> in smtcfb_pci_probe().
yes, i could have. But actually I am thinking to totally remove this function and use more conventional fb_get_mode() in its places. But if i do so then the boot parameters will change. Currently it is like vga=sm712fb:0x301 but if i change it to use fb_get_mode() then the boot parameters will change to vga=sm712fb:640x480@60-8 , and that is why I am hesitating. But it will be more conventional to what all framebuffer drivers follows.
regards
sudip
>
> regards,
> dan carpenter
>
^ permalink raw reply
* Re: [PATCH 3/3] staging: sm7xxfb: change return of sm7xx_vga_setup
From: Sudip Mukherjee @ 2015-03-09 13:53 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Greg Kroah-Hartman, devel, linux-fbdev, linux-kernel
In-Reply-To: <20150309133805.GI10964@mwanda>
On Mon, Mar 09, 2015 at 04:38:05PM +0300, Dan Carpenter wrote:
>
>
> On Mon, Mar 09, 2015 at 07:00:33PM +0530, Sudip Mukherjee wrote:
> > On Mon, Mar 09, 2015 at 04:13:43PM +0300, Dan Carpenter wrote:
> > > On Sun, Mar 08, 2015 at 11:10:11PM +0530, Sudip Mukherjee wrote:
> > > > change return type of sm7xx_vga_setup() to void as we are not using
> > > > the return type anywhere. if this function fails we fall back to the
> > > > default configuration.
> > > >
> > > > Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
> > >
> > > Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
> > >
> > > This patch is fine but if you wanted you could send a follow on which
> > > set it to SCREEN_X_RES, SCREEN_Y_RES, SCREEN_BPP if there were no
> > > options. Then remove the "if (smtc_scr_info.lfb_width != 0) " condition
> > > in smtcfb_pci_probe().
> >
> > yes, i could have. But actually I am thinking to totally remove this function and use more conventional fb_get_mode() in its places. But if i do so then the boot parameters will change. Currently it is like vga=sm712fb:0x301 but if i change it to use fb_get_mode() then the boot parameters will change to vga=sm712fb:640x480@60-8 , and that is why I am hesitating. But it will be more conventional to what all framebuffer drivers follows.
> >
>
> Hm... That's a good question.
>
> I suspect we should just go with fb_get_mode() and do it quickly. This
> driver is so new in the kernel that there are no users to get upset.
i am afraid that is not correct. this driver was in staging from long back, and Greg removed it from staging as no one was working with it. But after that removal Lemote Yeeloong laptop of Steven Rostedt stopped working. (https://lkml.org/lkml/2014/11/20/698) , so i guess there will be many such users.
regards
sudip
>
> regards,
> dan carpenter
>
^ permalink raw reply
* Re: [PATCH 3/3] staging: sm7xxfb: change return of sm7xx_vga_setup
From: Dan Carpenter @ 2015-03-09 14:04 UTC (permalink / raw)
To: Sudip Mukherjee, Greg Kroah-Hartman; +Cc: devel, linux-fbdev, linux-kernel
In-Reply-To: <20150309135343.GC13002@sudip-PC>
On Mon, Mar 09, 2015 at 07:23:43PM +0530, Sudip Mukherjee wrote:
> On Mon, Mar 09, 2015 at 04:38:05PM +0300, Dan Carpenter wrote:
> >
> >
> > On Mon, Mar 09, 2015 at 07:00:33PM +0530, Sudip Mukherjee wrote:
> > > On Mon, Mar 09, 2015 at 04:13:43PM +0300, Dan Carpenter wrote:
> > > > On Sun, Mar 08, 2015 at 11:10:11PM +0530, Sudip Mukherjee wrote:
> > > > > change return type of sm7xx_vga_setup() to void as we are not using
> > > > > the return type anywhere. if this function fails we fall back to the
> > > > > default configuration.
> > > > >
> > > > > Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
> > > >
> > > > Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > >
> > > > This patch is fine but if you wanted you could send a follow on which
> > > > set it to SCREEN_X_RES, SCREEN_Y_RES, SCREEN_BPP if there were no
> > > > options. Then remove the "if (smtc_scr_info.lfb_width != 0) " condition
> > > > in smtcfb_pci_probe().
> > >
> > > yes, i could have. But actually I am thinking to totally remove this function and use more conventional fb_get_mode() in its places. But if i do so then the boot parameters will change. Currently it is like vga=sm712fb:0x301 but if i change it to use fb_get_mode() then the boot parameters will change to vga=sm712fb:640x480@60-8 , and that is why I am hesitating. But it will be more conventional to what all framebuffer drivers follows.
> > >
> >
> > Hm... That's a good question.
> >
> > I suspect we should just go with fb_get_mode() and do it quickly. This
> > driver is so new in the kernel that there are no users to get upset.
>
> i am afraid that is not correct. this driver was in staging from long
> back, and Greg removed it from staging as no one was working with it.
> But after that removal Lemote Yeeloong laptop of Steven Rostedt
> stopped working. (https://lkml.org/lkml/2014/11/20/698) , so i guess
> there will be many such users.
Hm... I suspect we should still change it so it matches the other FB
drivers but I don't know.
Perhaps Greg has an opinion?
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] video: ARM CLCD: Added dt support to set tim2 register
From: Russell King - ARM Linux @ 2015-03-09 16:16 UTC (permalink / raw)
To: Pawel Moll
Cc: Arun Ramamurthy, Rob Herring, Mark Rutland, Ian Campbell,
Kumar Gala, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org, Dmitry Torokhov, Anatol Pomazau,
Jonathan Richardson, Scott Branden, Ray Jui,
bcm-kernel-feedback-list@broadcom.com
In-Reply-To: <1425378127.3092.38.camel@arm.com>
On Tue, Mar 03, 2015 at 10:22:07AM +0000, Pawel Moll wrote:
> On Tue, 2015-03-03 at 10:02 +0000, Pawel Moll wrote:
> > On Mon, 2015-03-02 at 19:09 +0000, Arun Ramamurthy wrote:
> > > > The existing bindings intentionally avoided quoting internal registers -
> > > > they are supposed to describe how the hardware is wired up...
> > > >
> > > > So how about something like "arm,pl11x,tft-invert-clac"? Then the driver
> > > > sets the bit or not, depending on the property existance?
> > > >
> > > Sure, I can change it to two properties called arm,pl11x,tft-invert-clac
> > > and arm,pl11x,tft-clksel. Would that be acceptable?
> >
> > That would be fine by me :-)
>
> Or (after having a look at the TRM) I should rather say: the invert-clac
> is fine by me :-) but the tft-clksel doesn't work, I afraid.
>
> If I'm not mistaken, there are two problems with it.
>
> Number one: it's not TFT-specific, is it? So it certainly should not
> have the "tft-" bit.
>
> Number two: setting this bit says "do not use CLCDCLK for the logic; use
> HCLK instead", correct? If so, have a look at the clock properties. They
> say:
>
> - clock-names: should contain "clcdclk" and "apb_pclk"
>
> - clocks: contains phandle and clock specifier pairs for the entries
> in the clock-names property. See
>
> So if your hardware has the reference clock wired to HCLK, and you
> defining the clocks as "clcdclk", you are (no offence meant ;-)
> lying :-)
No. The CLCD block always takes two clock signals - the AHB bus clock
(HCLK) for the slave interface, and a CLCD clock.
The CLCDCLKSEL is a bit which affects a signal sent to the world outside
of the CLCD block, which is used to drive an _external_ multiplexer to
select the CLCD clock source. (See the description for bit 5 of the
LCDTiming2 register.)
So, the clock is still input to the CLCDCLK input, even if it is ultimately
derived from HCLK.
Remember, the clock API does not deal with names describing the source of
the clock, but the consumer of the clock. The consumer in this case is
the PL11x CLCD block, which takes a CLCDCLK input.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] staging: sm750fb: Fix sparse warning
From: Lorenzo Stoakes @ 2015-03-09 20:57 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, devel, linux-kernel, Lorenzo Stoakes
This patch fixes the following sparse warning:-
drivers/staging/sm750fb/ddk750_help.c: warning: incorrect type in assignment (different address spaces)
Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
---
drivers/staging/sm750fb/ddk750_chip.h | 4 +++-
drivers/staging/sm750fb/ddk750_help.c | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_chip.h b/drivers/staging/sm750fb/ddk750_chip.h
index 1c78875..a4e5bcc 100644
--- a/drivers/staging/sm750fb/ddk750_chip.h
+++ b/drivers/staging/sm750fb/ddk750_chip.h
@@ -3,6 +3,8 @@
#define DEFAULT_INPUT_CLOCK 14318181 /* Default reference clock */
#define SM750LE_REVISION_ID (char)0xfe
+#include <asm/io.h>
+
/* This is all the chips recognized by this library */
typedef enum _logical_chip_type_t
{
@@ -70,7 +72,7 @@ logical_chip_type_t getChipType(void);
unsigned int calcPllValue(unsigned int request,pll_value_t *pll);
unsigned int calcPllValue2(unsigned int,pll_value_t *);
unsigned int formatPllReg(pll_value_t *pPLL);
-void ddk750_set_mmio(volatile unsigned char *,unsigned short,char);
+void ddk750_set_mmio(volatile unsigned char __iomem *,unsigned short,char);
unsigned int ddk750_getVMSize(void);
int ddk750_initHw(initchip_param_t *);
unsigned int getPllValue(clock_type_t clockType, pll_value_t *pPLL);
diff --git a/drivers/staging/sm750fb/ddk750_help.c b/drivers/staging/sm750fb/ddk750_help.c
index cc00d2b..6ad4dec 100644
--- a/drivers/staging/sm750fb/ddk750_help.c
+++ b/drivers/staging/sm750fb/ddk750_help.c
@@ -7,7 +7,7 @@ char revId750 = 0;
unsigned short devId750 = 0;
/* after driver mapped io registers, use this function first */
-void ddk750_set_mmio(volatile unsigned char * addr,unsigned short devId,char revId)
+void ddk750_set_mmio(volatile unsigned char __iomem * addr,unsigned short devId,char revId)
{
mmio750 = addr;
devId750 = devId;
--
2.3.2
^ permalink raw reply related
* [PATCHv3 00/10] fbdev: ssd1307fb: Cleanup and add support for SSD1305
From: Thomas Niederprüm @ 2015-03-09 22:22 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, maxime.ripard, kernel, shawn.guo,
robh+dt
Cc: linux-fbdev, linux-kernel, Thomas Niederprüm
In-Reply-To: <1423261694-5939-1-git-send-email-niederp@physik.uni-kl.de>
This patch series is the result of making the ssd1307fb driver work with
a Newhaven OLED display using the Solomon SSD1305 controller. To achieve
this the intialization code for the SSD1306 and the SSD1307 is merged
and based on DT configuration to reflect the various possible wirings
of the SSD130X controller (04/10). Based on these changes it is straight
forward to add support for the SSD1305 controller (06/10).
While working on the driver I realized that it was not possible to
correctly mmap the video memory from userspace since the address handed
to the userspace app is a virtual one where it should be a physical one.
Patch 01/10 fixes this. Furthermore the memory reserved by kzalloc is
not page aligned while the address handed to userspace is aligned to the
next page frame. This problem is fixed by using vmalloc in 02/10.
Furthermore module parameters are added to set the bits per pixel
and the delay for the deferred io update. It makes sense to set
the bits per pixel for the video memory to 8 bits since there is
only very poor userspace support for 1 bit framebuffers.
Also sysfs handles are added to make the contrast settings and dim
mode setting available in userspace.
changes since v1 (thanks to Maxime for the feedback):
- dedicated patch for fixing smem_start address
- remove page reserve upon vmalloc
- remove return value check upon display turn-off at module unload
- use a module parameter refreshrate rather than delaydivider
- allocate fbdefio dynamically
- use sysfs_create_groups to create sysfs entries
- remove contrast, vhcom and dclk properties from DT since they are
not part of hw description. The contrast module parameter was added
to set contrast at load time. vhcom and dclk stays at it's default
values for now.
- add new DT properties to in tree users of ssd130X
- rebased to apply on top of linux-next
changes since v2 (thanks to Maxime again):
- free memory allocated by vmalloc on driver unload
- set default values in the init code to the ones of the existing ssd1307
init code
- added two ACKs (Maxime Ripard)
Thomas Niederprüm (10):
fbdev: ssd1307fb: fix memory address smem_start.
fbdev: ssd1307fb: Use vmalloc to allocate video memory.
of: Add Solomon Systech vendor prefix.
fbdev: ssd1307fb: Unify init code and obtain hw specific bits from DT
ARM: mxs: fix in tree users of ssd1306
fbdev: ssd1307fb: Add support for SSD1305
fbdev: ssd1307fb: Add module parameter to set refresh rate of the
display
fbdev: ssd1307fb: Add module parameter bitsperpixel.
fbdev: ssd1307fb: Add sysfs handles to expose contrast and dim setting
to userspace.
fbdev: ssd1307fb: Turn off display on driver unload.
.../devicetree/bindings/vendor-prefixes.txt | 1 +
.../devicetree/bindings/video/ssd1307fb.txt | 23 +-
arch/arm/boot/dts/imx28-cfa10036.dts | 4 +
drivers/video/fbdev/ssd1307fb.c | 355 +++++++++++++++------
4 files changed, 286 insertions(+), 97 deletions(-)
--
2.3.0
^ permalink raw reply
* [PATCHv3 01/10] fbdev: ssd1307fb: fix memory address smem_start.
From: Thomas Niederprüm @ 2015-03-09 22:22 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, maxime.ripard, kernel, shawn.guo,
robh+dt
Cc: linux-fbdev, linux-kernel, Thomas Niederprüm
In-Reply-To: <1425939732-18386-1-git-send-email-niederp@physik.uni-kl.de>
the smem_start pointer of the framebuffer info struct needs to hold the
physical address rather than the virtual address. This patch fixes a
driver crash on mmaping the framebuffer memory due to an access to the
memory address.
Note however that the memory allocated by kzalloc is not page aligned,
while the address presented on a mmap call is aligned to the next page
boudary.
Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/video/fbdev/ssd1307fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index f7ed6d9..61e0ce8 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -515,7 +515,7 @@ static int ssd1307fb_probe(struct i2c_client *client,
info->var.blue.offset = 0;
info->screen_base = (u8 __force __iomem *)vmem;
- info->fix.smem_start = (unsigned long)vmem;
+ info->fix.smem_start = __pa(vmem);
info->fix.smem_len = vmem_size;
fb_deferred_io_init(info);
--
2.3.0
^ permalink raw reply related
* [PATCHv3 02/10] fbdev: ssd1307fb: Use vmalloc to allocate video memory.
From: Thomas Niederprüm @ 2015-03-09 22:22 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, maxime.ripard, kernel, shawn.guo,
robh+dt
Cc: linux-fbdev, linux-kernel, Thomas Niederprüm
In-Reply-To: <1425939732-18386-1-git-send-email-niederp@physik.uni-kl.de>
It makes sense to use vmalloc to allocate the video buffer since it has to be
page aligned memory for using it with mmap. Also deffered io seems buggy in
combination with kmalloc'ed memory (crash on unloading the module).
Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
---
drivers/video/fbdev/ssd1307fb.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 61e0ce8..310474a 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -11,6 +11,7 @@
#include <linux/i2c.h>
#include <linux/fb.h>
#include <linux/uaccess.h>
+#include <linux/vmalloc.h>
#include <linux/of_device.h>
#include <linux/of_gpio.h>
#include <linux/pwm.h>
@@ -489,7 +490,7 @@ static int ssd1307fb_probe(struct i2c_client *client,
vmem_size = par->width * par->height / 8;
- vmem = devm_kzalloc(&client->dev, vmem_size, GFP_KERNEL);
+ vmem = vzalloc(vmem_size);
if (!vmem) {
dev_err(&client->dev, "Couldn't allocate graphical memory.\n");
ret = -ENOMEM;
@@ -559,6 +560,7 @@ panel_init_error:
par->ops->remove(par);
reset_oled_error:
fb_deferred_io_cleanup(info);
+ vfree(vmem);
fb_alloc_error:
framebuffer_release(info);
return ret;
@@ -573,6 +575,7 @@ static int ssd1307fb_remove(struct i2c_client *client)
if (par->ops->remove)
par->ops->remove(par);
fb_deferred_io_cleanup(info);
+ vfree(__va(info->fix.smem_start));
framebuffer_release(info);
return 0;
--
2.3.0
^ permalink raw reply related
* [PATCHv3 03/10] of: Add Solomon Systech vendor prefix.
From: Thomas Niederprüm @ 2015-03-09 22:22 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, maxime.ripard, kernel, shawn.guo,
robh+dt
Cc: linux-fbdev, linux-kernel, Thomas Niederprüm
In-Reply-To: <1425939732-18386-1-git-send-email-niederp@physik.uni-kl.de>
This patch adds the solomon prefix for Solomon Systech Limited.
Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d3f4809..933c8f5 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -169,6 +169,7 @@ sitronix Sitronix Technology Corporation
smsc Standard Microsystems Corporation
snps Synopsys, Inc.
solidrun SolidRun
+solomon Solomon Systech Limited
sony Sony Corporation
spansion Spansion Inc.
sprd Spreadtrum Communications Inc.
--
2.3.0
^ permalink raw reply related
* [PATCHv3 04/10] fbdev: ssd1307fb: Unify init code and obtain hw specific bits from DT
From: Thomas Niederprüm @ 2015-03-09 22:22 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, maxime.ripard, kernel, shawn.guo,
robh+dt
Cc: linux-fbdev, linux-kernel, Thomas Niederprüm
In-Reply-To: <1425939732-18386-1-git-send-email-niederp@physik.uni-kl.de>
The 130X controllers are very similar from the configuration point of view.
The configuration registers for the SSD1305/6/7 are bit identical (except the
the VHCOM register and the the default values for clock setup register). This
patch unifies the init code of the controller and adds hardware specific
properties to DT that are needed to correctly initialize the device.
The SSD130X can be wired to the OLED panel in various ways. Even for the
same controller this wiring can differ from one display module to another
and can not be probed by software. The added DT properties reflect these
hardware decisions of the display module manufacturer.
The 'com-sequential', 'com-lrremap' and 'com-invdir' values define different
possibilities for the COM signals pin configuration and readout direction
of the video memory. The 'segment-no-remap' allows the inversion of the
memory-to-pin mapping ultimately inverting the order of the controllers
output pins. The 'prechargepX' values need to be adapted according the
capacitance of the OLEDs pixel cells.
So far these hardware specific bits are hard coded in the init code, making
the driver usable only for one certain wiring of the controller. This patch
makes the driver usable with all possible hardware setups, given a valid hw
description in DT. If these values are not set in DT the default values,
as they are set in the ssd1307 init code right now, are used. This implies
that without the corresponding DT property "segment-no-remap" the segment
remap of the ssd130X controller gets activated. Even though this is not the
default behaviour according to the datasheet it maintains backward
compatibility with older DTBs.
Note that the SSD1306 does not seem to be using the configuration written to
the registers at all. Therefore this patch does not try to maintain these
values without changes in DT. For reference an example is added to the DT
bindings documentation that reproduces the configuration that is set in the
current init code.
Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
---
.../devicetree/bindings/video/ssd1307fb.txt | 21 +++
drivers/video/fbdev/ssd1307fb.c | 195 ++++++++++++---------
2 files changed, 137 insertions(+), 79 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt b/Documentation/devicetree/bindings/video/ssd1307fb.txt
index 7a12542..be27562 100644
--- a/Documentation/devicetree/bindings/video/ssd1307fb.txt
+++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
@@ -15,6 +15,16 @@ Required properties:
Optional properties:
- reset-active-low: Is the reset gpio is active on physical low?
+ - solomon,segment-no-remap: Display needs normal (non-inverted) data column
+ to segment mapping
+ - solomon,com-sequential: Display uses sequential COM pin configuration
+ - solomon,com-lrremap: Display uses left-right COM pin remap
+ - solomon,com-invdir: Display uses inverted COM pin scan direction
+ - solomon,com-offset: Offset of the first COM pin wired to the panel
+ - solomon,prechargep1: Length of deselect period (phase 1) in clock cycles.
+ - solomon,prechargep2: Length of precharge period (phase 2) in clock cycles.
+ This needs to be the higher, the higher the capacitance
+ of the OLED's pixels is
[0]: Documentation/devicetree/bindings/pwm/pwm.txt
@@ -26,3 +36,14 @@ ssd1307: oled@3c {
reset-gpios = <&gpio2 7>;
reset-active-low;
};
+
+ssd1306: oled@3c {
+ compatible = "solomon,ssd1306fb-i2c";
+ reg = <0x3c>;
+ pwms = <&pwm 4 3000>;
+ reset-gpios = <&gpio2 7>;
+ reset-active-low;
+ solomon,com-lrremap;
+ solomon,com-invdir;
+ solomon,com-offset = <32>;
+};
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 310474a..b451361 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -17,6 +17,9 @@
#include <linux/pwm.h>
#include <linux/delay.h>
+#define DEVID_SSD1306 6
+#define DEVID_SSD1307 7
+
#define SSD1307FB_DATA 0x40
#define SSD1307FB_COMMAND 0x80
@@ -39,22 +42,38 @@
#define SSD1307FB_SET_COM_PINS_CONFIG 0xda
#define SSD1307FB_SET_VCOMH 0xdb
+static u_int contrast = 128;
+module_param(contrast, uint, S_IRUGO);
+
struct ssd1307fb_par;
-struct ssd1307fb_ops {
- int (*init)(struct ssd1307fb_par *);
- int (*remove)(struct ssd1307fb_par *);
+struct ssd1307fb_deviceinfo {
+ int device_id;
+ u32 default_vcomh;
+ u32 default_dclk_div;
+ u32 default_dclk_frq;
};
struct ssd1307fb_par {
+ u32 com_invdir;
+ u32 com_lrremap;
+ u32 com_offset;
+ u32 com_seq;
+ u32 contrast;
+ u32 dclk_div;
+ u32 dclk_frq;
+ struct ssd1307fb_deviceinfo *device_info;
struct i2c_client *client;
u32 height;
struct fb_info *info;
- struct ssd1307fb_ops *ops;
u32 page_offset;
+ u32 prechargep1;
+ u32 prechargep2;
struct pwm_device *pwm;
u32 pwm_period;
int reset;
+ u32 seg_remap;
+ u32 vcomh;
u32 width;
};
@@ -255,69 +274,46 @@ static struct fb_deferred_io ssd1307fb_defio = {
.deferred_io = ssd1307fb_deferred_io,
};
-static int ssd1307fb_ssd1307_init(struct ssd1307fb_par *par)
+static int ssd1307fb_init(struct ssd1307fb_par *par)
{
int ret;
+ u32 precharge, dclk, com_invdir, compins;
- par->pwm = pwm_get(&par->client->dev, NULL);
- if (IS_ERR(par->pwm)) {
- dev_err(&par->client->dev, "Could not get PWM from device tree!\n");
- return PTR_ERR(par->pwm);
- }
-
- par->pwm_period = pwm_get_period(par->pwm);
- /* Enable the PWM */
- pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
- pwm_enable(par->pwm);
-
- dev_dbg(&par->client->dev, "Using PWM%d with a %dns period.\n",
- par->pwm->pwm, par->pwm_period);
-
- /* Map column 127 of the OLED to segment 0 */
- ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SEG_REMAP_ON);
- if (ret < 0)
- return ret;
-
- /* Turn on the display */
- ret = ssd1307fb_write_cmd(par->client, SSD1307FB_DISPLAY_ON);
- if (ret < 0)
- return ret;
-
- return 0;
-}
-
-static int ssd1307fb_ssd1307_remove(struct ssd1307fb_par *par)
-{
- pwm_disable(par->pwm);
- pwm_put(par->pwm);
- return 0;
-}
+ if (par->device_info->device_id = DEVID_SSD1307) {
+ par->pwm = pwm_get(&par->client->dev, NULL);
+ if (IS_ERR(par->pwm)) {
+ dev_err(&par->client->dev, "Could not get PWM from device tree!\n");
+ return PTR_ERR(par->pwm);
+ }
-static struct ssd1307fb_ops ssd1307fb_ssd1307_ops = {
- .init = ssd1307fb_ssd1307_init,
- .remove = ssd1307fb_ssd1307_remove,
-};
+ par->pwm_period = pwm_get_period(par->pwm);
+ /* Enable the PWM */
+ pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
+ pwm_enable(par->pwm);
-static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
-{
- int ret;
+ dev_dbg(&par->client->dev, "Using PWM%d with a %dns period.\n",
+ par->pwm->pwm, par->pwm_period);
+ };
/* Set initial contrast */
ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CONTRAST);
if (ret < 0)
return ret;
- ret = ssd1307fb_write_cmd(par->client, 0x7f);
- if (ret < 0)
- return ret;
-
- /* Set COM direction */
- ret = ssd1307fb_write_cmd(par->client, 0xc8);
+ ret = ssd1307fb_write_cmd(par->client, par->contrast);
if (ret < 0)
return ret;
/* Set segment re-map */
- ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SEG_REMAP_ON);
+ if (par->seg_remap) {
+ ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SEG_REMAP_ON);
+ if (ret < 0)
+ return ret;
+ };
+
+ /* Set COM direction */
+ com_invdir = 0xc0 | (par->com_invdir & 0xf) << 3;
+ ret = ssd1307fb_write_cmd(par->client, com_invdir);
if (ret < 0)
return ret;
@@ -335,34 +331,38 @@ static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
if (ret < 0)
return ret;
- ret = ssd1307fb_write_cmd(par->client, 0x20);
+ ret = ssd1307fb_write_cmd(par->client, par->com_offset);
if (ret < 0)
return ret;
/* Set clock frequency */
+ dclk = (par->dclk_div & 0xf) | (par->dclk_frq & 0xf) << 4;
ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_CLOCK_FREQ);
if (ret < 0)
return ret;
- ret = ssd1307fb_write_cmd(par->client, 0xf0);
+ ret = ssd1307fb_write_cmd(par->client, dclk);
if (ret < 0)
return ret;
/* Set precharge period in number of ticks from the internal clock */
+ precharge = (par->prechargep1 & 0xf) | (par->prechargep2 & 0xf) << 4;
ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_PRECHARGE_PERIOD);
if (ret < 0)
return ret;
- ret = ssd1307fb_write_cmd(par->client, 0x22);
+ ret = ssd1307fb_write_cmd(par->client, precharge);
if (ret < 0)
return ret;
/* Set COM pins configuration */
+ compins = 0x02 | (!par->com_seq & 0x1) << 4
+ | (par->com_lrremap & 0x1) << 5;
ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_COM_PINS_CONFIG);
if (ret < 0)
return ret;
- ret = ssd1307fb_write_cmd(par->client, 0x22);
+ ret = ssd1307fb_write_cmd(par->client, compins);
if (ret < 0)
return ret;
@@ -371,18 +371,20 @@ static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
if (ret < 0)
return ret;
- ret = ssd1307fb_write_cmd(par->client, 0x49);
+ ret = ssd1307fb_write_cmd(par->client, par->vcomh);
if (ret < 0)
return ret;
- /* Turn on the DC-DC Charge Pump */
- ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CHARGE_PUMP);
- if (ret < 0)
- return ret;
+ if (par->device_info->device_id = DEVID_SSD1306) {
+ /* Turn on the DC-DC Charge Pump */
+ ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CHARGE_PUMP);
+ if (ret < 0)
+ return ret;
- ret = ssd1307fb_write_cmd(par->client, 0x14);
- if (ret < 0)
- return ret;
+ ret = ssd1307fb_write_cmd(par->client, 0x14);
+ if (ret < 0)
+ return ret;
+ };
/* Switch to horizontal addressing mode */
ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_ADDRESS_MODE);
@@ -394,6 +396,7 @@ static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
if (ret < 0)
return ret;
+ /* Set column range */
ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_COL_RANGE);
if (ret < 0)
return ret;
@@ -406,6 +409,7 @@ static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
if (ret < 0)
return ret;
+ /* Set page range */
ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_PAGE_RANGE);
if (ret < 0)
return ret;
@@ -427,18 +431,28 @@ static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
return 0;
}
-static struct ssd1307fb_ops ssd1307fb_ssd1306_ops = {
- .init = ssd1307fb_ssd1306_init,
+static struct ssd1307fb_deviceinfo ssd1307fb_ssd1306_deviceinfo = {
+ .device_id = DEVID_SSD1306,
+ .default_vcomh = 0x20,
+ .default_dclk_div = 0,
+ .default_dclk_frq = 8,
+};
+
+static struct ssd1307fb_deviceinfo ssd1307fb_ssd1307_deviceinfo = {
+ .device_id = DEVID_SSD1307,
+ .default_vcomh = 0x20,
+ .default_dclk_div = 1,
+ .default_dclk_frq = 12,
};
static const struct of_device_id ssd1307fb_of_match[] = {
{
.compatible = "solomon,ssd1306fb-i2c",
- .data = (void *)&ssd1307fb_ssd1306_ops,
+ .data = (void *)&ssd1307fb_ssd1306_deviceinfo,
},
{
.compatible = "solomon,ssd1307fb-i2c",
- .data = (void *)&ssd1307fb_ssd1307_ops,
+ .data = (void *)&ssd1307fb_ssd1307_deviceinfo,
},
{},
};
@@ -469,8 +483,8 @@ static int ssd1307fb_probe(struct i2c_client *client,
par->info = info;
par->client = client;
- par->ops = (struct ssd1307fb_ops *)of_match_device(ssd1307fb_of_match,
- &client->dev)->data;
+ par->device_info = (struct ssd1307fb_deviceinfo *)of_match_device(
+ ssd1307fb_of_match, &client->dev)->data;
par->reset = of_get_named_gpio(client->dev.of_node,
"reset-gpios", 0);
@@ -488,6 +502,27 @@ static int ssd1307fb_probe(struct i2c_client *client,
if (of_property_read_u32(node, "solomon,page-offset", &par->page_offset))
par->page_offset = 1;
+ if (of_property_read_u32(node, "solomon,com-offset", &par->com_offset))
+ par->com_offset = 0;
+
+ if (of_property_read_u32(node, "solomon,prechargep1", &par->prechargep1))
+ par->prechargep1 = 2;
+
+ if (of_property_read_u32(node, "solomon,prechargep2", &par->prechargep2))
+ par->prechargep2 = 0;
+
+ par->seg_remap = !of_property_read_bool(node, "solomon,segment-no-remap");
+ par->com_seq = of_property_read_bool(node, "solomon,com-sequential");
+ par->com_lrremap = of_property_read_bool(node, "solomon,com-lrremap");
+ par->com_invdir = of_property_read_bool(node, "solomon,com-invdir");
+
+ par->contrast = contrast;
+ par->vcomh = par->device_info->default_vcomh;
+
+ /* Setup display timing */
+ par->dclk_div = par->device_info->default_dclk_div;
+ par->dclk_frq = par->device_info->default_dclk_frq;
+
vmem_size = par->width * par->height / 8;
vmem = vzalloc(vmem_size);
@@ -539,11 +574,9 @@ static int ssd1307fb_probe(struct i2c_client *client,
gpio_set_value(par->reset, 1);
udelay(4);
- if (par->ops->init) {
- ret = par->ops->init(par);
- if (ret)
- goto reset_oled_error;
- }
+ ret = ssd1307fb_init(par);
+ if (ret)
+ goto reset_oled_error;
ret = register_framebuffer(info);
if (ret) {
@@ -556,8 +589,10 @@ static int ssd1307fb_probe(struct i2c_client *client,
return 0;
panel_init_error:
- if (par->ops->remove)
- par->ops->remove(par);
+ if (par->device_info->device_id = DEVID_SSD1307) {
+ pwm_disable(par->pwm);
+ pwm_put(par->pwm);
+ };
reset_oled_error:
fb_deferred_io_cleanup(info);
vfree(vmem);
@@ -572,8 +607,10 @@ static int ssd1307fb_remove(struct i2c_client *client)
struct ssd1307fb_par *par = info->par;
unregister_framebuffer(info);
- if (par->ops->remove)
- par->ops->remove(par);
+ if (par->device_info->device_id = DEVID_SSD1307) {
+ pwm_disable(par->pwm);
+ pwm_put(par->pwm);
+ };
fb_deferred_io_cleanup(info);
vfree(__va(info->fix.smem_start));
framebuffer_release(info);
--
2.3.0
^ permalink raw reply related
* [PATCHv3 05/10] ARM: mxs: fix in tree users of ssd1306
From: Thomas Niederprüm @ 2015-03-09 22:22 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, maxime.ripard, kernel, shawn.guo,
robh+dt
Cc: linux-fbdev, linux-kernel, Thomas Niederprüm
In-Reply-To: <1425939732-18386-1-git-send-email-niederp@physik.uni-kl.de>
This patch updates the in tree-users of the SSD1306 controller for using
the newly introduced DT properties.
Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
---
arch/arm/boot/dts/imx28-cfa10036.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/imx28-cfa10036.dts b/arch/arm/boot/dts/imx28-cfa10036.dts
index b04b6b8..faeaa2e 100644
--- a/arch/arm/boot/dts/imx28-cfa10036.dts
+++ b/arch/arm/boot/dts/imx28-cfa10036.dts
@@ -99,6 +99,10 @@
solomon,height = <32>;
solomon,width = <128>;
solomon,page-offset = <0>;
+ solomon,segment-remap;
+ solomon,com-lrremap;
+ solomon,com-invdir;
+ solomon,com-offset = <32>;
};
};
--
2.3.0
^ permalink raw reply related
* [PATCHv3 06/10] fbdev: ssd1307fb: Add support for SSD1305
From: Thomas Niederprüm @ 2015-03-09 22:22 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, maxime.ripard, kernel, shawn.guo,
robh+dt
Cc: linux-fbdev, linux-kernel, Thomas Niederprüm
In-Reply-To: <1425939732-18386-1-git-send-email-niederp@physik.uni-kl.de>
This patch adds support for the SSD1305 OLED controller.
Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
---
Documentation/devicetree/bindings/video/ssd1307fb.txt | 2 +-
drivers/video/fbdev/ssd1307fb.c | 13 +++++++++++++
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt b/Documentation/devicetree/bindings/video/ssd1307fb.txt
index be27562..a878fd2 100644
--- a/Documentation/devicetree/bindings/video/ssd1307fb.txt
+++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
@@ -2,7 +2,7 @@
Required properties:
- compatible: Should be "solomon,<chip>fb-<bus>". The only supported bus for
- now is i2c, and the supported chips are ssd1306 and ssd1307.
+ now is i2c, and the supported chips are ssd1305, ssd1306 and ssd1307.
- reg: Should contain address of the controller on the I2C bus. Most likely
0x3c or 0x3d
- pwm: Should contain the pwm to use according to the OF device tree PWM
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index b451361..08720be 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -17,6 +17,7 @@
#include <linux/pwm.h>
#include <linux/delay.h>
+#define DEVID_SSD1305 5
#define DEVID_SSD1306 6
#define DEVID_SSD1307 7
@@ -431,6 +432,13 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
return 0;
}
+static struct ssd1307fb_deviceinfo ssd1307fb_ssd1305_deviceinfo = {
+ .device_id = DEVID_SSD1305,
+ .default_vcomh = 0x34,
+ .default_dclk_div = 0,
+ .default_dclk_frq = 7,
+};
+
static struct ssd1307fb_deviceinfo ssd1307fb_ssd1306_deviceinfo = {
.device_id = DEVID_SSD1306,
.default_vcomh = 0x20,
@@ -447,6 +455,10 @@ static struct ssd1307fb_deviceinfo ssd1307fb_ssd1307_deviceinfo = {
static const struct of_device_id ssd1307fb_of_match[] = {
{
+ .compatible = "solomon,ssd1305fb-i2c",
+ .data = (void *)&ssd1307fb_ssd1305_deviceinfo,
+ },
+ {
.compatible = "solomon,ssd1306fb-i2c",
.data = (void *)&ssd1307fb_ssd1306_deviceinfo,
},
@@ -619,6 +631,7 @@ static int ssd1307fb_remove(struct i2c_client *client)
}
static const struct i2c_device_id ssd1307fb_i2c_id[] = {
+ { "ssd1305fb", 0 },
{ "ssd1306fb", 0 },
{ "ssd1307fb", 0 },
{ }
--
2.3.0
^ permalink raw reply related
* [PATCHv3 07/10] fbdev: ssd1307fb: Add module parameter to set refresh rate of the display
From: Thomas Niederprüm @ 2015-03-09 22:22 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, maxime.ripard, kernel, shawn.guo,
robh+dt
Cc: linux-fbdev, linux-kernel, Thomas Niederprüm
In-Reply-To: <1425939732-18386-1-git-send-email-niederp@physik.uni-kl.de>
This patch adds the module parameter "refreshrate" to set delay for the
deferred io. The refresh rate is given in units of Hertz. The default
refresh rate is 1 Hz.
Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
---
drivers/video/fbdev/ssd1307fb.c | 23 +++++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 08720be..7c8e627 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -43,6 +43,11 @@
#define SSD1307FB_SET_COM_PINS_CONFIG 0xda
#define SSD1307FB_SET_VCOMH 0xdb
+#define REFRASHRATE 1
+
+static u_int refreshrate = REFRASHRATE;
+module_param(refreshrate, uint, 0);
+
static u_int contrast = 128;
module_param(contrast, uint, S_IRUGO);
@@ -270,11 +275,6 @@ static void ssd1307fb_deferred_io(struct fb_info *info,
ssd1307fb_update_display(info->par);
}
-static struct fb_deferred_io ssd1307fb_defio = {
- .delay = HZ,
- .deferred_io = ssd1307fb_deferred_io,
-};
-
static int ssd1307fb_init(struct ssd1307fb_par *par)
{
int ret;
@@ -475,6 +475,7 @@ static int ssd1307fb_probe(struct i2c_client *client,
{
struct fb_info *info;
struct device_node *node = client->dev.of_node;
+ struct fb_deferred_io *ssd1307fb_defio;
u32 vmem_size;
struct ssd1307fb_par *par;
u8 *vmem;
@@ -544,10 +545,20 @@ static int ssd1307fb_probe(struct i2c_client *client,
goto fb_alloc_error;
}
+ ssd1307fb_defio = devm_kzalloc(&client->dev, sizeof(struct fb_deferred_io), GFP_KERNEL);
+ if (!ssd1307fb_defio) {
+ dev_err(&client->dev, "Couldn't allocate deferred io.\n");
+ ret = -ENOMEM;
+ goto fb_alloc_error;
+ }
+
+ ssd1307fb_defio->delay = HZ / refreshrate;
+ ssd1307fb_defio->deferred_io = ssd1307fb_deferred_io;
+
info->fbops = &ssd1307fb_ops;
info->fix = ssd1307fb_fix;
info->fix.line_length = par->width / 8;
- info->fbdefio = &ssd1307fb_defio;
+ info->fbdefio = ssd1307fb_defio;
info->var = ssd1307fb_var;
info->var.xres = par->width;
--
2.3.0
^ permalink raw reply related
* [PATCHv3 08/10] fbdev: ssd1307fb: Add module parameter bitsperpixel.
From: Thomas Niederprüm @ 2015-03-09 22:22 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, maxime.ripard, kernel, shawn.guo,
robh+dt
Cc: linux-fbdev, linux-kernel, Thomas Niederprüm
In-Reply-To: <1425939732-18386-1-git-send-email-niederp@physik.uni-kl.de>
This patch adds a module parameter 'bitsperpixel' to adjust the colordepth
of the framebuffer. All values >1 will result in memory map of the requested
color depth. However only the MSB of each pixel will be sent to the device.
The framebuffer identifies itself as a grayscale display with the specified
depth.
Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
---
drivers/video/fbdev/ssd1307fb.c | 25 ++++++++++++++++---------
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 7c8e627..3cf4da1 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -44,6 +44,10 @@
#define SSD1307FB_SET_VCOMH 0xdb
#define REFRASHRATE 1
+#define BITSPERPIXEL 1
+
+static u_int bitsperpixel = BITSPERPIXEL;
+module_param(bitsperpixel, uint, 0);
static u_int refreshrate = REFRASHRATE;
module_param(refreshrate, uint, 0);
@@ -99,7 +103,8 @@ static struct fb_fix_screeninfo ssd1307fb_fix = {
};
static struct fb_var_screeninfo ssd1307fb_var = {
- .bits_per_pixel = 1,
+ .bits_per_pixel = BITSPERPIXEL,
+ .grayscale = 1,
};
static struct ssd1307fb_array *ssd1307fb_alloc_array(u32 len, u8 type)
@@ -194,10 +199,11 @@ static void ssd1307fb_update_display(struct ssd1307fb_par *par)
array->data[array_idx] = 0;
for (k = 0; k < 8; k++) {
u32 page_length = par->width * i;
- u32 index = page_length + (par->width * k + j) / 8;
+ u32 index = page_length * bitsperpixel + (par->width * k + j) * bitsperpixel / 8;
u8 byte = *(vmem + index);
- u8 bit = byte & (1 << (j % 8));
- bit = bit >> (j % 8);
+ u8 bit = byte & (((1 << (bitsperpixel))-1) << (j % 8/bitsperpixel));
+
+ bit = (bit >> (j % 8/bitsperpixel)) >> (bitsperpixel-1);
array->data[array_idx] |= bit << k;
}
}
@@ -536,7 +542,7 @@ static int ssd1307fb_probe(struct i2c_client *client,
par->dclk_div = par->device_info->default_dclk_div;
par->dclk_frq = par->device_info->default_dclk_frq;
- vmem_size = par->width * par->height / 8;
+ vmem_size = par->width * par->height * bitsperpixel / 8;
vmem = vzalloc(vmem_size);
if (!vmem) {
@@ -557,20 +563,21 @@ static int ssd1307fb_probe(struct i2c_client *client,
info->fbops = &ssd1307fb_ops;
info->fix = ssd1307fb_fix;
- info->fix.line_length = par->width / 8;
+ info->fix.line_length = par->width * bitsperpixel / 8;
info->fbdefio = ssd1307fb_defio;
info->var = ssd1307fb_var;
+ info->var.bits_per_pixel = bitsperpixel;
info->var.xres = par->width;
info->var.xres_virtual = par->width;
info->var.yres = par->height;
info->var.yres_virtual = par->height;
- info->var.red.length = 1;
+ info->var.red.length = bitsperpixel;
info->var.red.offset = 0;
- info->var.green.length = 1;
+ info->var.green.length = bitsperpixel;
info->var.green.offset = 0;
- info->var.blue.length = 1;
+ info->var.blue.length = bitsperpixel;
info->var.blue.offset = 0;
info->screen_base = (u8 __force __iomem *)vmem;
--
2.3.0
^ permalink raw reply related
* [PATCHv3 09/10] fbdev: ssd1307fb: Add sysfs handles to expose contrast and dim setting to userspace.
From: Thomas Niederprüm @ 2015-03-09 22:22 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, maxime.ripard, kernel, shawn.guo,
robh+dt
Cc: linux-fbdev, linux-kernel, Thomas Niederprüm
In-Reply-To: <1425939732-18386-1-git-send-email-niederp@physik.uni-kl.de>
This patch adds sysfs handles to enable userspace control over the display
contrast as well as the dim mode. The handles are available as "contrast"
and "dim" in the framebuffers sysfs domain.
Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
---
drivers/video/fbdev/ssd1307fb.c | 90 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 90 insertions(+)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 3cf4da1..fee6324 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -33,6 +33,7 @@
#define SSD1307FB_CONTRAST 0x81
#define SSD1307FB_CHARGE_PUMP 0x8d
#define SSD1307FB_SEG_REMAP_ON 0xa1
+#define SSD1307FB_DISPLAY_DIM 0xac
#define SSD1307FB_DISPLAY_OFF 0xae
#define SSD1307FB_SET_MULTIPLEX_RATIO 0xa8
#define SSD1307FB_DISPLAY_ON 0xaf
@@ -43,6 +44,9 @@
#define SSD1307FB_SET_COM_PINS_CONFIG 0xda
#define SSD1307FB_SET_VCOMH 0xdb
+#define MIN_CONTRAST 0
+#define MAX_CONTRAST 255
+
#define REFRASHRATE 1
#define BITSPERPIXEL 1
@@ -73,6 +77,7 @@ struct ssd1307fb_par {
u32 dclk_div;
u32 dclk_frq;
struct ssd1307fb_deviceinfo *device_info;
+ u32 dim;
struct i2c_client *client;
u32 height;
struct fb_info *info;
@@ -476,6 +481,87 @@ static const struct of_device_id ssd1307fb_of_match[] = {
};
MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
+static ssize_t show_contrast(struct device *device,
+ struct device_attribute *attr, char *buf)
+{
+ struct fb_info *info = dev_get_drvdata(device);
+ struct ssd1307fb_par *par = info->par;
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", par->contrast);
+}
+
+static ssize_t store_contrast(struct device *device,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct fb_info *info = dev_get_drvdata(device);
+ struct ssd1307fb_par *par = info->par;
+ unsigned long contrastval;
+ int ret;
+
+ ret = kstrtoul(buf, 0, &contrastval);
+ if (ret < 0)
+ return ret;
+
+ par->contrast = max_t(ulong, min_t(ulong, contrastval,
+ (ulong)MAX_CONTRAST), (ulong)MIN_CONTRAST);
+
+ ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CONTRAST);
+ ret = ret & ssd1307fb_write_cmd(par->client, par->contrast);
+ if (ret < 0)
+ return ret;
+
+ return count;
+}
+
+
+static ssize_t show_dim(struct device *device,
+ struct device_attribute *attr, char *buf)
+{
+ struct fb_info *info = dev_get_drvdata(device);
+ struct ssd1307fb_par *par = info->par;
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", par->dim);
+}
+
+static ssize_t store_dim(struct device *device,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct fb_info *info = dev_get_drvdata(device);
+ struct ssd1307fb_par *par = info->par;
+ unsigned long dimval;
+ int ret;
+
+ ret = kstrtoul(buf, 0, &dimval);
+ if (ret < 0)
+ return ret;
+
+ par->dim = max_t(ulong, min_t(ulong, dimval, (ulong)1), (ulong)0);
+ if (par->dim)
+ ret = ssd1307fb_write_cmd(par->client, SSD1307FB_DISPLAY_DIM);
+ else
+ ret = ssd1307fb_write_cmd(par->client, SSD1307FB_DISPLAY_ON);
+ if (ret < 0)
+ return ret;
+
+ return count;
+}
+
+static DEVICE_ATTR(contrast, S_IRUGO|S_IWUSR, show_contrast, store_contrast);
+static DEVICE_ATTR(dim, S_IRUGO|S_IWUSR, show_dim, store_dim);
+
+static struct attribute *panel_attrs[] = {
+ &dev_attr_contrast.attr,
+ &dev_attr_dim.attr,
+ NULL,
+};
+
+static struct attribute_group brightness_attr_grp = {
+ .name = "brightness",
+ .attrs = panel_attrs,
+};
+
static int ssd1307fb_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -614,6 +700,10 @@ static int ssd1307fb_probe(struct i2c_client *client,
goto panel_init_error;
}
+ ret = sysfs_create_group(&info->dev->kobj, &brightness_attr_grp);
+ if (ret)
+ dev_err(&client->dev, "Couldn't register sysfs nodes\n");
+
dev_info(&client->dev, "fb%d: %s framebuffer device registered, using %d bytes of video memory\n", info->node, info->fix.id, vmem_size);
return 0;
--
2.3.0
^ 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