* [PATCH 4/4] [resend] tridentfb: Add DDC support
From: Ondrej Zary @ 2015-03-03 20:56 UTC (permalink / raw)
To: Krzysztof Helt; +Cc: linux-fbdev, Kernel development list
In-Reply-To: <1425416163-10700-1-git-send-email-linux@rainbow-software.org>
Add DDC support for Trident cards.
Tested on TGUI9440, TGUI9680, 3DImage 9750, Blade3D 9880 and Blade XP.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
---
drivers/video/fbdev/Kconfig | 9 ++
drivers/video/fbdev/tridentfb.c | 192 ++++++++++++++++++++++++++++++++++++++-
2 files changed, 196 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 4916c97..08a7a04 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1682,6 +1682,15 @@ config FB_TRIDENT
To compile this driver as a module, choose M here: the
module will be called tridentfb.
+config FB_TRIDENT_DDC
+ bool "DDC for Trident support"
+ depends on FB_TRIDENT
+ select FB_DDC
+ select FB_MODE_HELPERS
+ default y
+ help
+ Say Y here if you want DDC support for your Trident graphics card.
+
config FB_ARK
tristate "ARK 2000PV support"
depends on FB && PCI
diff --git a/drivers/video/fbdev/tridentfb.c b/drivers/video/fbdev/tridentfb.c
index 01b43e9..59471a0 100644
--- a/drivers/video/fbdev/tridentfb.c
+++ b/drivers/video/fbdev/tridentfb.c
@@ -25,6 +25,9 @@
#include <video/vga.h>
#include <video/trident.h>
+#include <linux/i2c.h>
+#include <linux/i2c-algo-bit.h>
+
struct tridentfb_par {
void __iomem *io_virt; /* iospace virtual memory address */
u32 pseudo_pal[16];
@@ -40,6 +43,11 @@ struct tridentfb_par {
(struct tridentfb_par *par, const char*,
u32, u32, u32, u32, u32, u32);
unsigned char eng_oper; /* engine operation... */
+#ifdef CONFIG_FB_TRIDENT_DDC
+ bool ddc_registered;
+ struct i2c_adapter ddc_adapter;
+ struct i2c_algo_bit_data ddc_algo;
+#endif
};
static struct fb_fix_screeninfo tridentfb_fix = {
@@ -53,7 +61,7 @@ static struct fb_fix_screeninfo tridentfb_fix = {
/* defaults which are normally overriden by user values */
/* video mode */
-static char *mode_option = "640x480-8@60";
+static char *mode_option;
static int bpp = 8;
static int noaccel;
@@ -174,6 +182,124 @@ static inline u32 readmmr(struct tridentfb_par *par, u16 r)
return fb_readl(par->io_virt + r);
}
+#ifdef CONFIG_FB_TRIDENT_DDC
+
+#define DDC_SDA_TGUI BIT(0)
+#define DDC_SCL_TGUI BIT(1)
+#define DDC_SCL_DRIVE_TGUI BIT(2)
+#define DDC_SDA_DRIVE_TGUI BIT(3)
+#define DDC_MASK_TGUI (DDC_SCL_DRIVE_TGUI | DDC_SDA_DRIVE_TGUI)
+
+static void tridentfb_ddc_setscl_tgui(void *data, int val)
+{
+ struct tridentfb_par *par = data;
+ u8 reg = vga_mm_rcrt(par->io_virt, I2C) & DDC_MASK_TGUI;
+
+ if (val)
+ reg &= ~DDC_SCL_DRIVE_TGUI; /* disable drive - don't drive hi */
+ else
+ reg |= DDC_SCL_DRIVE_TGUI; /* drive low */
+
+ vga_mm_wcrt(par->io_virt, I2C, reg);
+}
+
+static void tridentfb_ddc_setsda_tgui(void *data, int val)
+{
+ struct tridentfb_par *par = data;
+ u8 reg = vga_mm_rcrt(par->io_virt, I2C) & DDC_MASK_TGUI;
+
+ if (val)
+ reg &= ~DDC_SDA_DRIVE_TGUI; /* disable drive - don't drive hi */
+ else
+ reg |= DDC_SDA_DRIVE_TGUI; /* drive low */
+
+ vga_mm_wcrt(par->io_virt, I2C, reg);
+}
+
+static int tridentfb_ddc_getsda_tgui(void *data)
+{
+ struct tridentfb_par *par = data;
+
+ return !!(vga_mm_rcrt(par->io_virt, I2C) & DDC_SDA_TGUI);
+}
+
+#define DDC_SDA_IN BIT(0)
+#define DDC_SCL_OUT BIT(1)
+#define DDC_SDA_OUT BIT(3)
+#define DDC_SCL_IN BIT(6)
+#define DDC_MASK (DDC_SCL_OUT | DDC_SDA_OUT)
+
+static void tridentfb_ddc_setscl(void *data, int val)
+{
+ struct tridentfb_par *par = data;
+ unsigned char reg;
+
+ reg = vga_mm_rcrt(par->io_virt, I2C) & DDC_MASK;
+ if (val)
+ reg |= DDC_SCL_OUT;
+ else
+ reg &= ~DDC_SCL_OUT;
+ vga_mm_wcrt(par->io_virt, I2C, reg);
+}
+
+static void tridentfb_ddc_setsda(void *data, int val)
+{
+ struct tridentfb_par *par = data;
+ unsigned char reg;
+
+ reg = vga_mm_rcrt(par->io_virt, I2C) & DDC_MASK;
+ if (!val)
+ reg |= DDC_SDA_OUT;
+ else
+ reg &= ~DDC_SDA_OUT;
+ vga_mm_wcrt(par->io_virt, I2C, reg);
+}
+
+static int tridentfb_ddc_getscl(void *data)
+{
+ struct tridentfb_par *par = data;
+
+ return !!(vga_mm_rcrt(par->io_virt, I2C) & DDC_SCL_IN);
+}
+
+static int tridentfb_ddc_getsda(void *data)
+{
+ struct tridentfb_par *par = data;
+
+ return !!(vga_mm_rcrt(par->io_virt, I2C) & DDC_SDA_IN);
+}
+
+static int tridentfb_setup_ddc_bus(struct fb_info *info)
+{
+ struct tridentfb_par *par = info->par;
+
+ strlcpy(par->ddc_adapter.name, info->fix.id,
+ sizeof(par->ddc_adapter.name));
+ par->ddc_adapter.owner = THIS_MODULE;
+ par->ddc_adapter.class = I2C_CLASS_DDC;
+ par->ddc_adapter.algo_data = &par->ddc_algo;
+ par->ddc_adapter.dev.parent = info->device;
+ if (is_oldclock(par->chip_id)) { /* not sure if this check is OK */
+ par->ddc_algo.setsda = tridentfb_ddc_setsda_tgui;
+ par->ddc_algo.setscl = tridentfb_ddc_setscl_tgui;
+ par->ddc_algo.getsda = tridentfb_ddc_getsda_tgui;
+ /* no getscl */
+ } else {
+ par->ddc_algo.setsda = tridentfb_ddc_setsda;
+ par->ddc_algo.setscl = tridentfb_ddc_setscl;
+ par->ddc_algo.getsda = tridentfb_ddc_getsda;
+ par->ddc_algo.getscl = tridentfb_ddc_getscl;
+ }
+ par->ddc_algo.udelay = 10;
+ par->ddc_algo.timeout = 20;
+ par->ddc_algo.data = par;
+
+ i2c_set_adapdata(&par->ddc_adapter, par);
+
+ return i2c_bit_add_bus(&par->ddc_adapter);
+}
+#endif /* CONFIG_FB_TRIDENT_DDC */
+
/*
* Blade specific acceleration.
*/
@@ -1346,6 +1472,7 @@ static int trident_pci_probe(struct pci_dev *dev,
struct tridentfb_par *default_par;
int chip3D;
int chip_id;
+ bool found = false;
err = pci_enable_device(dev);
if (err)
@@ -1499,6 +1626,7 @@ static int trident_pci_probe(struct pci_dev *dev,
info->pixmap.scan_align = 1;
info->pixmap.access_align = 32;
info->pixmap.flags = FB_PIXMAP_SYSTEM;
+ info->var.bits_per_pixel = 8;
if (default_par->image_blit) {
info->flags |= FBINFO_HWACCEL_IMAGEBLIT;
@@ -1511,11 +1639,57 @@ static int trident_pci_probe(struct pci_dev *dev,
info->pixmap.scan_align = 1;
}
- if (!fb_find_mode(&info->var, info,
- mode_option, NULL, 0, NULL, bpp)) {
- err = -EINVAL;
- goto out_unmap2;
+#ifdef CONFIG_FB_TRIDENT_DDC
+ if (tridentfb_setup_ddc_bus(info) = 0) {
+ u8 *edid = fb_ddc_read(&default_par->ddc_adapter);
+
+ default_par->ddc_registered = true;
+ if (edid) {
+ fb_edid_to_monspecs(edid, &info->monspecs);
+ kfree(edid);
+ if (!info->monspecs.modedb)
+ dev_err(info->device, "error getting mode database\n");
+ else {
+ const struct fb_videomode *m;
+
+ fb_videomode_to_modelist(info->monspecs.modedb,
+ info->monspecs.modedb_len,
+ &info->modelist);
+ m = fb_find_best_display(&info->monspecs,
+ &info->modelist);
+ if (m) {
+ fb_videomode_to_var(&info->var, m);
+ /* fill all other info->var's fields */
+ if (tridentfb_check_var(&info->var,
+ info) = 0)
+ found = true;
+ }
+ }
+ }
}
+#endif
+ if (!mode_option && !found)
+ mode_option = "640x480-8@60";
+
+ /* Prepare startup mode */
+ if (mode_option) {
+ err = fb_find_mode(&info->var, info, mode_option,
+ info->monspecs.modedb,
+ info->monspecs.modedb_len,
+ NULL, info->var.bits_per_pixel);
+ if (!err || err = 4) {
+ err = -EINVAL;
+ dev_err(info->device, "mode %s not found\n",
+ mode_option);
+ fb_destroy_modedb(info->monspecs.modedb);
+ info->monspecs.modedb = NULL;
+ goto out_unmap2;
+ }
+ }
+
+ fb_destroy_modedb(info->monspecs.modedb);
+ info->monspecs.modedb = NULL;
+
err = fb_alloc_cmap(&info->cmap, 256, 0);
if (err < 0)
goto out_unmap2;
@@ -1536,6 +1710,10 @@ static int trident_pci_probe(struct pci_dev *dev,
return 0;
out_unmap2:
+#ifdef CONFIG_FB_TRIDENT_DDC
+ if (default_par->ddc_registered)
+ i2c_del_adapter(&default_par->ddc_adapter);
+#endif
kfree(info->pixmap.addr);
if (info->screen_base)
iounmap(info->screen_base);
@@ -1555,6 +1733,10 @@ static void trident_pci_remove(struct pci_dev *dev)
struct tridentfb_par *par = info->par;
unregister_framebuffer(info);
+#ifdef CONFIG_FB_TRIDENT_DDC
+ if (par->ddc_registered)
+ i2c_del_adapter(&par->ddc_adapter);
+#endif
iounmap(par->io_virt);
iounmap(info->screen_base);
release_mem_region(tridentfb_fix.smem_start, tridentfb_fix.smem_len);
--
Ondrej Zary
^ permalink raw reply related
* [PATCH 3/4] [resend] fb_ddc: Allow I2C adapters without SCL read capability
From: Ondrej Zary @ 2015-03-03 20:56 UTC (permalink / raw)
To: Krzysztof Helt; +Cc: linux-fbdev, Kernel development list
In-Reply-To: <1425416163-10700-1-git-send-email-linux@rainbow-software.org>
i2c-algo-bit allows I2C adapters without SCL read capability to work but
fb_ddc_read fails to work on them.
Fix fb_ddc_read to work with I2C adapters not capable of reading SCL.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Acked-by: Krzysztof Helt <krzysztof.h1@wp.pl>
---
drivers/video/fbdev/core/fb_ddc.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/core/fb_ddc.c b/drivers/video/fbdev/core/fb_ddc.c
index 94322cc..22c694a 100644
--- a/drivers/video/fbdev/core/fb_ddc.c
+++ b/drivers/video/fbdev/core/fb_ddc.c
@@ -69,10 +69,11 @@ unsigned char *fb_ddc_read(struct i2c_adapter *adapter)
algo_data->setscl(algo_data->data, 1);
for (j = 0; j < 5; j++) {
msleep(10);
- if (algo_data->getscl(algo_data->data))
+ if (algo_data->getscl &&
+ algo_data->getscl(algo_data->data))
break;
}
- if (j = 5)
+ if (algo_data->getscl && j = 5)
continue;
algo_data->setsda(algo_data->data, 0);
@@ -91,7 +92,8 @@ unsigned char *fb_ddc_read(struct i2c_adapter *adapter)
algo_data->setscl(algo_data->data, 1);
for (j = 0; j < 10; j++) {
msleep(10);
- if (algo_data->getscl(algo_data->data))
+ if (algo_data->getscl &&
+ algo_data->getscl(algo_data->data))
break;
}
--
Ondrej Zary
^ permalink raw reply related
* [PATCH 2/4] [resend] tridentfb: Fix set_lwidth on TGUI9440 and CYBER9320
From: Ondrej Zary @ 2015-03-03 20:56 UTC (permalink / raw)
To: Krzysztof Helt; +Cc: linux-fbdev, Kernel development list
In-Reply-To: <1425416163-10700-1-git-send-email-linux@rainbow-software.org>
According to X.Org driver, chips older than TGUI9660 have only 1 width bit
in AddColReg. Touching the 2nd one causes I2C/DDC to fail on TGUI9440.
Set only 1 bit of width in AddColReg on TGUI9440 and CYBER9320.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
---
drivers/video/fbdev/tridentfb.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/tridentfb.c b/drivers/video/fbdev/tridentfb.c
index 7429713..01b43e9 100644
--- a/drivers/video/fbdev/tridentfb.c
+++ b/drivers/video/fbdev/tridentfb.c
@@ -673,8 +673,14 @@ static int get_nativex(struct tridentfb_par *par)
static inline void set_lwidth(struct tridentfb_par *par, int width)
{
write3X4(par, VGA_CRTC_OFFSET, width & 0xFF);
- write3X4(par, AddColReg,
- (read3X4(par, AddColReg) & 0xCF) | ((width & 0x300) >> 4));
+ /* chips older than TGUI9660 have only 1 width bit in AddColReg */
+ /* touching the other one breaks I2C/DDC */
+ if (par->chip_id = TGUI9440 || par->chip_id = CYBER9320)
+ write3X4(par, AddColReg,
+ (read3X4(par, AddColReg) & 0xEF) | ((width & 0x100) >> 4));
+ else
+ write3X4(par, AddColReg,
+ (read3X4(par, AddColReg) & 0xCF) | ((width & 0x300) >> 4));
}
/* For resolutions smaller than FP resolution stretch */
--
Ondrej Zary
^ permalink raw reply related
* [PATCH 1/4] [resend] tridentfb: fix hang on Blade3D with CONFIG_CC_OPTIMIZE_FOR_SIZE
From: Ondrej Zary @ 2015-03-03 20:56 UTC (permalink / raw)
To: Krzysztof Helt; +Cc: linux-fbdev, Kernel development list
When the kernel is compiled with -Os (CONFIG_CC_OPTIMIZE_FOR_SIZE), tridentfb
hangs the machine upon load with Blade3D cards unless acceleration is disabled.
This is caused by memcpy() which copies data byte-by-byte (rep movsb) when
compiled with -Os. The card does not like that - it requires 32-bit access.
Use iowrite_32() instead.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Acked-by: Krzysztof Helt <krzysztof.h1@wp.pl>
---
drivers/video/fbdev/tridentfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/tridentfb.c b/drivers/video/fbdev/tridentfb.c
index 7ed9a22..7429713 100644
--- a/drivers/video/fbdev/tridentfb.c
+++ b/drivers/video/fbdev/tridentfb.c
@@ -226,7 +226,7 @@ static void blade_image_blit(struct tridentfb_par *par, const char *data,
writemmr(par, DST1, point(x, y));
writemmr(par, DST2, point(x + w - 1, y + h - 1));
- memcpy(par->io_virt + 0x10000, data, 4 * size);
+ iowrite32_rep(par->io_virt + 0x10000, data, size);
}
static void blade_copy_rect(struct tridentfb_par *par,
--
Ondrej Zary
^ permalink raw reply related
* Re: [PATCHv2 02/10] fbdev: ssd1307fb: Use vmalloc to allocate video memory.
From: Thomas Niederprüm @ 2015-03-03 19:04 UTC (permalink / raw)
To: Maxime Ripard; +Cc: plagnioj, tomi.valkeinen, linux-fbdev, linux-kernel
In-Reply-To: <20150303085255.GB4911@lukather>
Am Tue, 3 Mar 2015 09:52:55 +0100
schrieb Maxime Ripard <maxime.ripard@free-electrons.com>:
> Hi,
>
> On Sun, Mar 01, 2015 at 11:27:55PM +0100, Thomas Niederprüm wrote:
> > 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 | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/video/fbdev/ssd1307fb.c
> > b/drivers/video/fbdev/ssd1307fb.c index 61e0ce8..25dd08d 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;
>
> Don't you need the vfree in the remove too?
Yes, of course. Memory will be freed in v3
>
> Maxime
>
^ permalink raw reply
* [PATCH,RESEND] framebuffer: don't link fb_devio into kernel image unconditionally
From: Harald Geyer @ 2015-03-03 13:09 UTC (permalink / raw)
To: linux-fbdev
CONFIG_FB_DEFERRED_IO is defined as bool while CONFIG_FB is defined as
tristate. Currently fb_defio.o is linked into the kernel image even if
CONFIG_FB=m.
I fix this by updating the Makefile to link fb_defio.o into fb.o and thus
go into one place with the other core framebuffer code.
This has been tested on arm/sunxi and arm/mxs.
Signed-off-by: Harald Geyer <harald@ccbib.org>
---
Resending this patch as I didn't get any reply for over two weeks.
drivers/video/fbdev/core/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/Makefile b/drivers/video/fbdev/core/Makefile
index 67f28e2..23d86a8 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_FB_CMDLINE) += fb_cmdline.o
obj-$(CONFIG_FB) += fb.o
fb-y := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
modedb.o fbcvt.o
+fb-$(CONFIG_FB_DEFERRED_IO) += fb_defio.o
fb-objs := $(fb-y)
obj-$(CONFIG_FB_CFB_FILLRECT) += cfbfillrect.o
@@ -14,4 +15,3 @@ obj-$(CONFIG_FB_SYS_IMAGEBLIT) += sysimgblt.o
obj-$(CONFIG_FB_SYS_FOPS) += fb_sys_fops.o
obj-$(CONFIG_FB_SVGALIB) += svgalib.o
obj-$(CONFIG_FB_DDC) += fb_ddc.o
-obj-$(CONFIG_FB_DEFERRED_IO) += fb_defio.o
--
2.1.4
^ permalink raw reply related
* [PATCH 2/2] MAINTAINERS: update for sm750fb driver
From: Sudip Mukherjee @ 2015-03-03 10:52 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Sudip Mukherjee, linux-kernel, devel, linux-fbdev
In-Reply-To: <1425379867-2176-1-git-send-email-sudipm.mukherjee@gmail.com>
add myself and Teddy Wang as the Maintainer of the sm750
frame buffer driver.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9ee5466..1a51043 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9340,6 +9340,14 @@ L: linux-fbdev@vger.kernel.org
S: Maintained
F: drivers/staging/sm7xxfb/
+STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER
+M: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+M: Teddy Wang <teddy.wang@siliconmotion.com>
+M: Sudip Mukherjee <sudip@vectorindia.org>
+L: linux-fbdev@vger.kernel.org
+S: Maintained
+F: drivers/staging/sm750fb/
+
STAGING - SLICOSS
M: Lior Dotan <liodot@gmail.com>
M: Christopher Harrer <charrer@alacritech.com>
--
1.8.1.2
^ permalink raw reply related
* [PATCH 0/2] add SM750 framebuffer driver
From: Sudip Mukherjee @ 2015-03-03 10:51 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Sudip Mukherjee, linux-kernel, devel, linux-fbdev
Hi Greg,
As discussed with you previously, this series contains the SM750
driver. This driver was given to me by Silicon Motion and has been
modified so that it compiles with the current kernel version and has
been tested with next-20150303.
I have a demo board (given by Silicon Motion) and it has been tested
before sending to you.
as of now, it has lots of checkpatch warnings and errors. if checked
with --strict option then i get -
total: 3682 errors, 1905 warnings, 1832 checks, 9974 lines checked
as it is a vendor driver crud, so will take some time to clear all
warnings.
regards
sudip
Sudip Mukherjee (2):
staging: sm750fb: add sm750 to staging
MAINTAINERS: update for sm750fb driver
MAINTAINERS | 8 +
drivers/staging/Kconfig | 2 +
drivers/staging/Makefile | 1 +
drivers/staging/sm750fb/Kconfig | 10 +
drivers/staging/sm750fb/Makefile | 4 +
drivers/staging/sm750fb/TODO | 15 +
drivers/staging/sm750fb/ddk750.h | 24 +
drivers/staging/sm750fb/ddk750_chip.c | 639 ++++++++
drivers/staging/sm750fb/ddk750_chip.h | 83 +
drivers/staging/sm750fb/ddk750_display.c | 318 ++++
drivers/staging/sm750fb/ddk750_display.h | 160 ++
drivers/staging/sm750fb/ddk750_dvi.c | 99 ++
drivers/staging/sm750fb/ddk750_dvi.h | 67 +
drivers/staging/sm750fb/ddk750_help.c | 19 +
drivers/staging/sm750fb/ddk750_help.h | 29 +
drivers/staging/sm750fb/ddk750_hwi2c.c | 271 ++++
drivers/staging/sm750fb/ddk750_hwi2c.h | 10 +
drivers/staging/sm750fb/ddk750_mode.c | 205 +++
drivers/staging/sm750fb/ddk750_mode.h | 43 +
drivers/staging/sm750fb/ddk750_power.c | 239 +++
drivers/staging/sm750fb/ddk750_power.h | 71 +
drivers/staging/sm750fb/ddk750_reg.h | 2616 ++++++++++++++++++++++++++++++
drivers/staging/sm750fb/ddk750_sii164.c | 425 +++++
drivers/staging/sm750fb/ddk750_sii164.h | 172 ++
drivers/staging/sm750fb/ddk750_swi2c.c | 535 ++++++
drivers/staging/sm750fb/ddk750_swi2c.h | 92 ++
drivers/staging/sm750fb/modedb.h | 221 +++
drivers/staging/sm750fb/readme | 38 +
drivers/staging/sm750fb/sm750.c | 1451 +++++++++++++++++
drivers/staging/sm750fb/sm750.h | 185 +++
drivers/staging/sm750fb/sm750_accel.c | 516 ++++++
drivers/staging/sm750fb/sm750_accel.h | 276 ++++
drivers/staging/sm750fb/sm750_cursor.c | 254 +++
drivers/staging/sm750fb/sm750_cursor.h | 17 +
drivers/staging/sm750fb/sm750_help.h | 111 ++
drivers/staging/sm750fb/sm750_hw.c | 640 ++++++++
drivers/staging/sm750fb/sm750_hw.h | 104 ++
37 files changed, 9970 insertions(+)
create mode 100644 drivers/staging/sm750fb/Kconfig
create mode 100644 drivers/staging/sm750fb/Makefile
create mode 100644 drivers/staging/sm750fb/TODO
create mode 100644 drivers/staging/sm750fb/ddk750.h
create mode 100644 drivers/staging/sm750fb/ddk750_chip.c
create mode 100644 drivers/staging/sm750fb/ddk750_chip.h
create mode 100644 drivers/staging/sm750fb/ddk750_display.c
create mode 100644 drivers/staging/sm750fb/ddk750_display.h
create mode 100644 drivers/staging/sm750fb/ddk750_dvi.c
create mode 100644 drivers/staging/sm750fb/ddk750_dvi.h
create mode 100644 drivers/staging/sm750fb/ddk750_help.c
create mode 100644 drivers/staging/sm750fb/ddk750_help.h
create mode 100644 drivers/staging/sm750fb/ddk750_hwi2c.c
create mode 100644 drivers/staging/sm750fb/ddk750_hwi2c.h
create mode 100644 drivers/staging/sm750fb/ddk750_mode.c
create mode 100644 drivers/staging/sm750fb/ddk750_mode.h
create mode 100644 drivers/staging/sm750fb/ddk750_power.c
create mode 100644 drivers/staging/sm750fb/ddk750_power.h
create mode 100644 drivers/staging/sm750fb/ddk750_reg.h
create mode 100644 drivers/staging/sm750fb/ddk750_sii164.c
create mode 100644 drivers/staging/sm750fb/ddk750_sii164.h
create mode 100644 drivers/staging/sm750fb/ddk750_swi2c.c
create mode 100644 drivers/staging/sm750fb/ddk750_swi2c.h
create mode 100644 drivers/staging/sm750fb/modedb.h
create mode 100644 drivers/staging/sm750fb/readme
create mode 100644 drivers/staging/sm750fb/sm750.c
create mode 100644 drivers/staging/sm750fb/sm750.h
create mode 100644 drivers/staging/sm750fb/sm750_accel.c
create mode 100644 drivers/staging/sm750fb/sm750_accel.h
create mode 100644 drivers/staging/sm750fb/sm750_cursor.c
create mode 100644 drivers/staging/sm750fb/sm750_cursor.h
create mode 100644 drivers/staging/sm750fb/sm750_help.h
create mode 100644 drivers/staging/sm750fb/sm750_hw.c
create mode 100644 drivers/staging/sm750fb/sm750_hw.h
--
1.8.1.2
^ permalink raw reply
* Re: [PATCH] video: ARM CLCD: Added dt support to set tim2 register
From: Pawel Moll @ 2015-03-03 10:22 UTC (permalink / raw)
To: Arun Ramamurthy
Cc: Rob Herring, Mark Rutland, Ian Campbell, Kumar Gala, Russell King,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Dmitry Torokhov, Anatol Pomazau, Jonathan Richardson,
Scott Branden, Ray Jui,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org
In-Reply-To: <1425376977.3092.26.camel-5wv7dgnIgG8@public.gmane.org>
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 :-)
So how about solving the problem by extending the clock-names definition
like this (feel free to use own wording):
- clock-names: should contain two clocks, either "clcdclk" or "hclk"
(depending on which input is to be used as a reference
clock by the controller logic) and "apb_pclk"
That way you're precisely describing the way the hardware is wired up.
And the driver simply tries to get clcdclk first, if it's defined -
cool, set clksel to 1, if not - try hclk and set clksel to 0. If neither
of them is present - bail out.
Does this make any sense?
Pawel
^ permalink raw reply
* Re: [PATCH] video: ARM CLCD: Added dt support to set tim2 register
From: Pawel Moll @ 2015-03-03 10:02 UTC (permalink / raw)
To: Arun Ramamurthy
Cc: Rob Herring, Mark Rutland, Ian Campbell, Kumar Gala, Russell King,
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: <54F4B583.4000005@broadcom.com>
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 :-)
Pawel
^ permalink raw reply
* Re: [PATCH] video: ARM CLCD: Added support for FBIO_WAITFORVSYNC
From: Pawel Moll @ 2015-03-03 10:01 UTC (permalink / raw)
To: Arun Ramamurthy
Cc: Rob Herring, Mark Rutland, Ian Campbell, Kumar Gala, Russell King,
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: <54F4B576.5030702@broadcom.com>
On Mon, 2015-03-02 at 19:09 +0000, Arun Ramamurthy wrote:
> On 15-03-02 08:00 AM, Pawel Moll wrote:
> > On Wed, 2015-02-25 at 21:01 +0000, Arun Ramamurthy wrote:
> >> Added ioctl and interrupt handler functions to support FBIO_WAITFORVSYNC
> >> Also corrected documentation to make interrupts and interrupt-names
> >> optional as they are not required properties.
> >
> > You may not be aware of this fact, but its the "documentation" what
> > defines what properties are required...
> >
> Pawel, I was not aware of that. Since the driver code did not require
> the interrupts or interrupt-names bindings to load properly, I moved it
> out of the required properties. I can remove that change.
Cool. Drivers don't have to use all available properties :-) The
interrupt names are required because CLCD can be wired up with a single,
combined interrupt or with 4 separate interrupt lines (see "A.4. On-chip
signals", in the TRM) and the binding has to provide ways of describing
this. Yes, one could say "1 number = combined, 4 numbers = split", but
I personally prefer to be explicit than implicit.
Just request the interrupt by name and you'll be fine.
> Any other comments on this change? Thanks
I have no experience with the vsync ioctl, so can't really comment on
it. One minor thing I did spot is your use of curly brackets in one of
the switch cases:
On Wed, 2015-02-25 at 21:01 +0000, Arun Ramamurthy wrote:
@@ -466,6 +468,73 @@ static int clcdfb_pan_display(struct fb_var_screeninfo *var,
> return 0;
> }
>
> +static int clcdfb_ioctl(struct fb_info *info,
> + unsigned int cmd, unsigned long args)
> +{
> + struct clcd_fb *fb = to_clcd(info);
> + int retval = 0;
> + u32 val, ienb_val;
> +
> + switch (cmd) {
> + case FBIO_WAITFORVSYNC:{
In the line above...
> + if (fb->lcd_irq <= 0) {
> + retval = -EINVAL;
> + break;
> + }
> + /* disable Vcomp interrupts */
> + ienb_val = readl(fb->regs + fb->off_ienb);
> + ienb_val &= ~CLCD_PL111_IENB_VCOMP;
> + writel(ienb_val, fb->regs + fb->off_ienb);
> +
> + /* clear Vcomp interrupt */
> + writel(CLCD_PL111_IENB_VCOMP, fb->regs + CLCD_PL111_ICR);
> +
> + /* Generate Interrupt at the start of Vsync */
> + reinit_completion(&fb->wait);
> + val = readl(fb->regs + fb->off_cntl);
> + val &= ~(CNTL_LCDVCOMP(3));
> + writel(val, fb->regs + fb->off_cntl);
> +
> + /* enable Vcomp interrupt */
> + ienb_val = readl(fb->regs + fb->off_ienb);
> + ienb_val |= CLCD_PL111_IENB_VCOMP;
> + writel(ienb_val, fb->regs + fb->off_ienb);
> + if (!wait_for_completion_interruptible_timeout
> + (&fb->wait, HZ/10))
> + retval = -ETIMEDOUT;
> + break;
> + }
... and here.
Not sure it's needed?
Pawel
^ permalink raw reply
* Re: [PATCHv2 10/10] fbdev: ssd1307fb: Turn off display on driver unload.
From: Maxime Ripard @ 2015-03-03 9:40 UTC (permalink / raw)
To: Thomas Niederprüm
Cc: plagnioj, tomi.valkeinen, linux-fbdev, linux-kernel
In-Reply-To: <1425248883-25367-11-git-send-email-niederp@physik.uni-kl.de>
[-- Attachment #1: Type: text/plain, Size: 385 bytes --]
On Sun, Mar 01, 2015 at 11:28:03PM +0100, Thomas Niederprüm wrote:
> This patch turns off the display when the driver is unloaded.
>
> Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCHv2 05/10] fbdev: ssd1307fb: fix in tree users of ssd1306
From: Maxime Ripard @ 2015-03-03 9:31 UTC (permalink / raw)
To: Thomas Niederprüm
Cc: plagnioj, tomi.valkeinen, linux-fbdev, linux-kernel
In-Reply-To: <1425248883-25367-6-git-send-email-niederp@physik.uni-kl.de>
[-- Attachment #1: Type: text/plain, Size: 449 bytes --]
On Sun, Mar 01, 2015 at 11:27:58PM +0100, Thomas Niederprüm wrote:
> introducing the new DT properties the in tree users of the SSD1306
> controller are updated to be up to date.
>
> Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
This should be prefixed by "ARM: mxs:", and sent to the MXS
maintainers.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCHv2 02/10] fbdev: ssd1307fb: Use vmalloc to allocate video memory.
From: Maxime Ripard @ 2015-03-03 8:52 UTC (permalink / raw)
To: Thomas Niederprüm
Cc: plagnioj, tomi.valkeinen, linux-fbdev, linux-kernel
In-Reply-To: <1425248883-25367-3-git-send-email-niederp@physik.uni-kl.de>
[-- Attachment #1: Type: text/plain, Size: 1626 bytes --]
Hi,
On Sun, Mar 01, 2015 at 11:27:55PM +0100, Thomas Niederprüm wrote:
> 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 | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index 61e0ce8..25dd08d 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;
Don't you need the vfree in the remove too?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v11 0/6] Add Skyworks SKY81452 device drivers
From: Lee Jones @ 2015-03-03 7:42 UTC (permalink / raw)
To: Gyungoh Yoo
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: <20150303022430.GA3667@jack-ThinkPad-T520>
On Tue, 03 Mar 2015, Gyungoh Yoo wrote:
> On Fri, Feb 27, 2015 at 08:39:38PM +0000, Lee Jones wrote:
> > On Fri, 27 Feb 2015, gyungoh@gmail.com wrote:
> >
> > > From: Gyungoh Yoo <jack.yoo@skyworksinc.com>
> > >
> > > This patch set includes regulator and backlight driver for SKY81452.
> > > Also it includes documents for device tree and module.
> > > sky81452-regulator was already applied. So this series doesn't
> > > include it.
> > >
> > > v11:
> > > Renamed 'skyworks,en-channels' property to led-sources.
> > > Removed unused property 'skyworks,ovp-level'.
> > >
> > > v10:
> > > Removed trivial get_brightness implementations for sky81452-backlight
> > >
> > > v9:
> > > Removed the change to remove MODULE_VERSION() for sky81452-regulator
> > >
> > > v8:
> > > Renamed property names for backlight with vendor prefix
> > > Modified gpio-enable property to generic property for GPIO
> > > Made up the example for backlight DT
> > > Changed the DT parsing of regulator using regulator_node and of_match
> > >
> > > v7:
> > > Modified licensing text to GPLv2
> > > Split Kconfig renaming from DT patch
> > >
> > > v6:
> > > Added new line character at the end of line of dev_err()
> > >
> > > v5:
> > > Changed DT for regulator : 'lout' node should be defined under 'regulator'
> > > Removed compatible string from sky81452-regulator driver
> > > Modified sky81452-regulator to return EINVAL when of_node is NULL
> > > Move sky81452-backlight.h to include/linux/platform_data
> > >
> > > v4:
> > > Removed MODULE_VERSION()
> > > Modified license to GPLv2
> > > Removed calling to backlight_device_unregister() in sky81452-backlight
> > >
> > > v3:
> > > Cleaned-up DBG messages
> > > Cleaned-up DT
> > > Fixed the backlight name from 'sky81452-bl' to 'sky81452-backlight'
> > > Assigned mfd_cell.of_compatible for binding device node
> > > Modified error messages
> > > Modified sky81452-regulator to return ENODATA when of_node is NULL
> > >
> > > v2:
> > > Split the patches for each sub-system
> > > Added 'reg' attribute for I2C address in device tree documents
> > > Added 'compatible' attribute in child drivers
> > > Renamed CONFIG_SKY81452 to CONFIG_MFD_SKY81452
> > > Changed the dependency from I2C=y to I2C, for CONFIG_MFD_SKY81452
> > > Added message for exception or errors.
> > > Added vendor prefix for Skyworks Solutions, Inc.
> > > Add SKY81452 to the Trivial Devices list
> > >
> > > Gyungoh Yoo (6):
> > > mfd: Add support for Skyworks SKY81452 driver
> > > backlight: Add support Skyworks SKY81452 backlight driver
> > > devicetree: Add new SKY81452 mfd binding
> > > devicetree: Add new SKY81452 backlight binding
> > > devicetree: Add vendor prefix for Skyworks Solutions, Inc.
> > > devicetree: Add SKY81452 to the Trivial Devices list
> > >
> > > .../devicetree/bindings/i2c/trivial-devices.txt | 1 +
> > > Documentation/devicetree/bindings/mfd/sky81452.txt | 35 ++
> > > .../devicetree/bindings/vendor-prefixes.txt | 1 +
> > > .../video/backlight/sky81452-backlight.txt | 29 ++
> > > drivers/mfd/Kconfig | 12 +
> > > drivers/mfd/Makefile | 1 +
> > > drivers/mfd/sky81452.c | 108 +++++++
> > > drivers/video/backlight/Kconfig | 10 +
> > > drivers/video/backlight/Makefile | 1 +
> > > drivers/video/backlight/sky81452-backlight.c | 353 +++++++++++++++++++++
> > > include/linux/mfd/sky81452.h | 31 ++
> > > include/linux/platform_data/sky81452-backlight.h | 46 +++
> > > 12 files changed, 628 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/mfd/sky81452.txt
> > > create mode 100644 Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
> > > create mode 100644 drivers/mfd/sky81452.c
> > > create mode 100644 drivers/video/backlight/sky81452-backlight.c
> > > create mode 100644 include/linux/mfd/sky81452.h
> > > create mode 100644 include/linux/platform_data/sky81452-backlight.h
> >
> > Correct me if I'm wrong, but I believe you have all of the relevant
> > Acks now. If so, I plan to pick this up next week and take it
> > through the MFD tree.
>
> I had got all Acks except DT on v10.
> Rob from DT reviewed, and v11 includes what he asked.
Let's wait to see if he cares to re-review. If after a few more days
he has chosen not to, I'll pick up the set.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCHv2 01/10] fbdev: ssd1307fb: fix memory address smem_start.
From: Maxime Ripard @ 2015-03-03 7:17 UTC (permalink / raw)
To: Thomas Niederprüm
Cc: plagnioj, tomi.valkeinen, linux-fbdev, linux-kernel
In-Reply-To: <1425248883-25367-2-git-send-email-niederp@physik.uni-kl.de>
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
On Sun, Mar 01, 2015 at 11:27:54PM +0100, Thomas Niederprüm wrote:
> 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>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v11 0/6] Add Skyworks SKY81452 device drivers
From: Gyungoh Yoo @ 2015-03-03 2:24 UTC (permalink / raw)
To: Lee Jones
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: <20150227203938.GA12821@x1>
On Fri, Feb 27, 2015 at 08:39:38PM +0000, Lee Jones wrote:
> On Fri, 27 Feb 2015, gyungoh@gmail.com wrote:
>
> > From: Gyungoh Yoo <jack.yoo@skyworksinc.com>
> >
> > This patch set includes regulator and backlight driver for SKY81452.
> > Also it includes documents for device tree and module.
> > sky81452-regulator was already applied. So this series doesn't
> > include it.
> >
> > v11:
> > Renamed 'skyworks,en-channels' property to led-sources.
> > Removed unused property 'skyworks,ovp-level'.
> >
> > v10:
> > Removed trivial get_brightness implementations for sky81452-backlight
> >
> > v9:
> > Removed the change to remove MODULE_VERSION() for sky81452-regulator
> >
> > v8:
> > Renamed property names for backlight with vendor prefix
> > Modified gpio-enable property to generic property for GPIO
> > Made up the example for backlight DT
> > Changed the DT parsing of regulator using regulator_node and of_match
> >
> > v7:
> > Modified licensing text to GPLv2
> > Split Kconfig renaming from DT patch
> >
> > v6:
> > Added new line character at the end of line of dev_err()
> >
> > v5:
> > Changed DT for regulator : 'lout' node should be defined under 'regulator'
> > Removed compatible string from sky81452-regulator driver
> > Modified sky81452-regulator to return EINVAL when of_node is NULL
> > Move sky81452-backlight.h to include/linux/platform_data
> >
> > v4:
> > Removed MODULE_VERSION()
> > Modified license to GPLv2
> > Removed calling to backlight_device_unregister() in sky81452-backlight
> >
> > v3:
> > Cleaned-up DBG messages
> > Cleaned-up DT
> > Fixed the backlight name from 'sky81452-bl' to 'sky81452-backlight'
> > Assigned mfd_cell.of_compatible for binding device node
> > Modified error messages
> > Modified sky81452-regulator to return ENODATA when of_node is NULL
> >
> > v2:
> > Split the patches for each sub-system
> > Added 'reg' attribute for I2C address in device tree documents
> > Added 'compatible' attribute in child drivers
> > Renamed CONFIG_SKY81452 to CONFIG_MFD_SKY81452
> > Changed the dependency from I2C=y to I2C, for CONFIG_MFD_SKY81452
> > Added message for exception or errors.
> > Added vendor prefix for Skyworks Solutions, Inc.
> > Add SKY81452 to the Trivial Devices list
> >
> > Gyungoh Yoo (6):
> > mfd: Add support for Skyworks SKY81452 driver
> > backlight: Add support Skyworks SKY81452 backlight driver
> > devicetree: Add new SKY81452 mfd binding
> > devicetree: Add new SKY81452 backlight binding
> > devicetree: Add vendor prefix for Skyworks Solutions, Inc.
> > devicetree: Add SKY81452 to the Trivial Devices list
> >
> > .../devicetree/bindings/i2c/trivial-devices.txt | 1 +
> > Documentation/devicetree/bindings/mfd/sky81452.txt | 35 ++
> > .../devicetree/bindings/vendor-prefixes.txt | 1 +
> > .../video/backlight/sky81452-backlight.txt | 29 ++
> > drivers/mfd/Kconfig | 12 +
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/sky81452.c | 108 +++++++
> > drivers/video/backlight/Kconfig | 10 +
> > drivers/video/backlight/Makefile | 1 +
> > drivers/video/backlight/sky81452-backlight.c | 353 +++++++++++++++++++++
> > include/linux/mfd/sky81452.h | 31 ++
> > include/linux/platform_data/sky81452-backlight.h | 46 +++
> > 12 files changed, 628 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mfd/sky81452.txt
> > create mode 100644 Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
> > create mode 100644 drivers/mfd/sky81452.c
> > create mode 100644 drivers/video/backlight/sky81452-backlight.c
> > create mode 100644 include/linux/mfd/sky81452.h
> > create mode 100644 include/linux/platform_data/sky81452-backlight.h
>
> Correct me if I'm wrong, but I believe you have all of the relevant
> Acks now. If so, I plan to pick this up next week and take it
> through the MFD tree.
I had got all Acks except DT on v10.
Rob from DT reviewed, and v11 includes what he asked.
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH] video: ARM CLCD: Added support for FBIO_WAITFORVSYNC
From: Rob Herring @ 2015-03-02 23:29 UTC (permalink / raw)
To: Arun Ramamurthy
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Dmitry Torokhov, Anatol Pomazau, Jonathan Richardson,
Scott Branden, Ray Jui,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w
In-Reply-To: <1424898082-1522-3-git-send-email-arun.ramamurthy-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Wed, Feb 25, 2015 at 3:01 PM, Arun Ramamurthy
<arun.ramamurthy@broadcom.com> wrote:
> Added ioctl and interrupt handler functions to support FBIO_WAITFORVSYNC
> Also corrected documentation to make interrupts and interrupt-names
> optional as they are not required properties.
>
> Reviewed-by: Ray Jui <rjui@broadcom.com>
> Reviewed-by: Scott Branden <sbranden@broadcom.com>
> Signed-off-by: Arun Ramamurthy <arun.ramamurthy@broadcom.com>0
> ---
> .../devicetree/bindings/video/arm,pl11x.txt | 11 +--
Please split bindings to separate patches.
> drivers/video/fbdev/amba-clcd.c | 82 ++++++++++++++++++++++
> include/linux/amba/clcd.h | 4 ++
> 3 files changed, 89 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt b/Documentation/devicetree/bindings/video/arm,pl11x.txt
> index 2262cdb..7d19024 100644
> --- a/Documentation/devicetree/bindings/video/arm,pl11x.txt
> +++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
> @@ -10,14 +10,6 @@ Required properties:
>
> - reg: base address and size of the control registers block
>
> -- interrupt-names: either the single entry "combined" representing a
> - combined interrupt output (CLCDINTR), or the four entries
> - "mbe", "vcomp", "lnbu", "fuf" representing the individual
> - CLCDMBEINTR, CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR interrupts
> -
> -- interrupts: contains an interrupt specifier for each entry in
> - interrupt-names
> -
> - clock-names: should contain "clcdclk" and "apb_pclk"
>
> - clocks: contains phandle and clock specifier pairs for the entries
> @@ -54,6 +46,9 @@ Optional properties:
> It can be used to configure a virtual y resolution. It
> must be a value larger than the actual y resolution.
>
> +- interrupts: contains an interrupt specifier for the clcd vcomp interrupt
> + This is required for the driver to handle FBIO_WAITFORVSYNC ioctls.
> +
What happened to interrupt-names?
Rob
^ permalink raw reply
* Re: [PATCH] video: ARM CLCD: Added support for FBIO_WAITFORVSYNC
From: Rob Herring @ 2015-03-02 23:27 UTC (permalink / raw)
To: Pawel Moll
Cc: Arun Ramamurthy, Rob Herring, Mark Rutland, Ian Campbell,
Kumar Gala, Russell King, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Dmitry Torokhov, Anatol Pomazau, Jonathan Richardson,
Scott Branden, Ray Jui,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org
In-Reply-To: <1425312029.3092.1.camel-5wv7dgnIgG8@public.gmane.org>
On Mon, Mar 2, 2015 at 10:00 AM, Pawel Moll <pawel.moll@arm.com> wrote:
> On Wed, 2015-02-25 at 21:01 +0000, Arun Ramamurthy wrote:
>> Added ioctl and interrupt handler functions to support FBIO_WAITFORVSYNC
>> Also corrected documentation to make interrupts and interrupt-names
>> optional as they are not required properties.
>
> You may not be aware of this fact, but its the "documentation" what
> defines what properties are required...
Except when docs are wrong. Then dts files win.
>> Reviewed-by: Ray Jui <rjui@broadcom.com>
>> Reviewed-by: Scott Branden <sbranden@broadcom.com>
>> Signed-off-by: Arun Ramamurthy <arun.ramamurthy@broadcom.com>0
>> ---
>> .../devicetree/bindings/video/arm,pl11x.txt | 11 +--
>> drivers/video/fbdev/amba-clcd.c | 82 ++++++++++++++++++++++
>> include/linux/amba/clcd.h | 4 ++
>> 3 files changed, 89 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt b/Documentation/devicetree/bindings/video/arm,pl11x.txt
>> index 2262cdb..7d19024 100644
>> --- a/Documentation/devicetree/bindings/video/arm,pl11x.txt
>> +++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
>> @@ -10,14 +10,6 @@ Required properties:
>>
>> - reg: base address and size of the control registers block
>>
>> -- interrupt-names: either the single entry "combined" representing a
>> - combined interrupt output (CLCDINTR), or the four entries
>> - "mbe", "vcomp", "lnbu", "fuf" representing the individual
>> - CLCDMBEINTR, CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR interrupts
>> -
>> -- interrupts: contains an interrupt specifier for each entry in
>> - interrupt-names
>> -
>> - clock-names: should contain "clcdclk" and "apb_pclk"
>>
>> - clocks: contains phandle and clock specifier pairs for the entries
>
> So no, you can't do that.
You can't do the other way around (making optional ones required), but
I think this is okay if the h/w interrupt lines are not physically
connected. However, if it is simply because the driver doesn't use
them, then I agree this should not be changed.
Rob
^ permalink raw reply
* Re: [PATCH] video: ARM CLCD: Added support for FBIOPAN_DISPLAY and virtual y resolution
From: Rob Herring @ 2015-03-02 23:22 UTC (permalink / raw)
To: Arun Ramamurthy
Cc: Russell King - ARM Linux, Pawel Moll, Rob Herring, Mark Rutland,
Ian Campbell, Kumar Gala, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Dmitry Torokhov, Anatol Pomazau, Jonathan Richardson,
Scott Branden, Ray Jui,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org
In-Reply-To: <54F4B57F.3030306-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Mon, Mar 2, 2015 at 1:09 PM, Arun Ramamurthy
<arun.ramamurthy@broadcom.com> wrote:
>
>
> On 15-03-02 08:11 AM, Russell King - ARM Linux wrote:
>>
>> On Mon, Mar 02, 2015 at 04:08:29PM +0000, Pawel Moll wrote:
>>>
>>> I'm not sure about this... The word "virtual" never works well with
>>> device tree nodes defined as "hardware description".
>>>
>>> I understand what you're doing, but adding this property to the display
>>> controller's node doesn't sound right. How does this describe hardware?
>>> If anywhere, it's more like a job for the panel node?
>>
>>
> I see what you are saying Pawel, I can follow Russell's recommendation of
> adding a RAM size node called max-memory-available or something similar
We've already got a binding for reserved memory regions for this
purpose. And there is also simplefb binding.
Rob
^ permalink raw reply
* Re: [PATCH] OMAP: DSS: DPI: disable vt-switch on suspend/resume.
From: Pavel Machek @ 2015-03-02 21:03 UTC (permalink / raw)
To: NeilBrown
Cc: Tomi Valkeinen, linux-omap, linux-fbdev, linux-kernel,
GTA04 owners, Rafael J. Wysocki
In-Reply-To: <20150226092646.7e20df30@notabene.brown>
Hi!
> > Looking at the drivers/tty/vt/vt_ioctl.c, it sounds to me that we should
> > always do pm_set_vt_switch(0), as omapdss restores everything just fine
> > on resume. Although it makes me wonder how it works if there are two
> > display controllers, one needing the switch and the other not...
>
> I wondered that too. It would seem to make more sense for
> pm_set_vt_switch(0) to be the default, that drivers which need the textmode
> switch should call (1). But I suspect there are "historical reasons" for the
> current situation.
Well... historically, we did not have drivers for graphics cards --
kernel did not know how to handle it, only X knew. For cards that do
not have kernel driver, only X one, we need to switch vts.
For cards that have proper driver, we should be able to survive
without VT switch.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH] video: ARM CLCD: Added support for FBIOPAN_DISPLAY and virtual y resolution
From: Russell King - ARM Linux @ 2015-03-02 19:12 UTC (permalink / raw)
To: Arun Ramamurthy
Cc: Pawel Moll, 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: <54F4B57F.3030306@broadcom.com>
On Mon, Mar 02, 2015 at 11:09:51AM -0800, Arun Ramamurthy wrote:
>
>
> On 15-03-02 08:11 AM, Russell King - ARM Linux wrote:
> >On Mon, Mar 02, 2015 at 04:08:29PM +0000, Pawel Moll wrote:
> >>I'm not sure about this... The word "virtual" never works well with
> >>device tree nodes defined as "hardware description".
> >>
> >>I understand what you're doing, but adding this property to the display
> >>controller's node doesn't sound right. How does this describe hardware?
> >>If anywhere, it's more like a job for the panel node?
> >
> I see what you are saying Pawel, I can follow Russell's recommendation of
> adding a RAM size node called max-memory-available or something similar
> >A better description (and implementation) would be to describe the size
> >of the RAM available for video purposes. The driver can then use the
> >requested virtual X resolution to limit (and/or compute) the virtual Y
> >resolution to allow Y panning/wrapping of the display.
> >
>
> In this scenario, where would I specify the virtual X resolution? I am
> assuming it would be in the panel-timing node as Pawel suggested?
virtual X should default to real X if it's not set, otherwise it
should come from the selected mode.
Drivers which get this right are things like acornfb, where we've
used ywrap scolling since it was merged.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH] video: ARM CLCD: Added dt support to set tim2 register
From: Arun Ramamurthy @ 2015-03-02 19:09 UTC (permalink / raw)
To: Pawel Moll
Cc: Rob Herring, Mark Rutland, Ian Campbell, Kumar Gala, Russell King,
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: <1425312688.3092.10.camel@arm.com>
On 15-03-02 08:11 AM, Pawel Moll wrote:
> On Wed, 2015-02-25 at 21:01 +0000, Arun Ramamurthy wrote:
>> Added code based on linaro tree:
>> http://git.linaro.org/kernel/linux-linaro-stable.git
>> with commit id:6846e7822c4cab5a84672baace3b768c2d0db142
>> at drivers/video/amba-clcd.c. This lets the driver set
>> certain tim2 register bits after reading them from
>> device tree.
>>
>> Reviewed-by: Ray Jui <rjui@broadcom.com>
>> Reviewed-by: Scott Branden <sbranden@broadcom.com>
>> Signed-off-by: Arun Ramamurthy <arun.ramamurthy@broadcom.com>
>> ---
>> .../devicetree/bindings/video/arm,pl11x.txt | 17 ++++++++-
>> drivers/video/fbdev/amba-clcd.c | 41 ++++++++++++++++++++++
>> 2 files changed, 57 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt b/Documentation/devicetree/bindings/video/arm,pl11x.txt
>> index 3e3039a..14d6f87 100644
>> --- a/Documentation/devicetree/bindings/video/arm,pl11x.txt
>> +++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
>> @@ -35,6 +35,21 @@ Optional properties:
>> cell's memory interface can handle; if not present, the memory
>> interface is fast enough to handle all possible video modes
>>
>> +- tim2: Used to set certain bits in LCDTiming2 register.
>> + It can be TIM2_CLKSEL or TIM2_IOE or both
>> +
>> + TIM2_CLKSEL: This bit drives the CLCDCLKSEL signal. It is the select
>> + signal for the external LCD clock multiplexor.
>> +
>> + TIM2_IOE: Invert output enable:
>> + 0 = CLAC output pin is active HIGH in TFT mode
>> + 1 = CLAC output pin is active LOW in TFT mode.
>> + This bit selects the active polarity of the output enable signal in
>> + TFT mode. In this mode, the CLAC pin is an enable that indicates to
>> + the LCD panel when valid display data is available. In active
>> + display mode, data is driven onto the LCD data lines at the
>> + programmed edge of CLCP when CLAC is in its active state.
>> +
>
> 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?
> Pawel
>
^ permalink raw reply
* Re: [PATCH] video: ARM CLCD: Added support for FBIOPAN_DISPLAY and virtual y resolution
From: Arun Ramamurthy @ 2015-03-02 19:09 UTC (permalink / raw)
To: Russell King - ARM Linux, Pawel Moll
Cc: 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: <20150302161122.GP8656@n2100.arm.linux.org.uk>
On 15-03-02 08:11 AM, Russell King - ARM Linux wrote:
> On Mon, Mar 02, 2015 at 04:08:29PM +0000, Pawel Moll wrote:
>> I'm not sure about this... The word "virtual" never works well with
>> device tree nodes defined as "hardware description".
>>
>> I understand what you're doing, but adding this property to the display
>> controller's node doesn't sound right. How does this describe hardware?
>> If anywhere, it's more like a job for the panel node?
>
I see what you are saying Pawel, I can follow Russell's recommendation
of adding a RAM size node called max-memory-available or something similar
> A better description (and implementation) would be to describe the size
> of the RAM available for video purposes. The driver can then use the
> requested virtual X resolution to limit (and/or compute) the virtual Y
> resolution to allow Y panning/wrapping of the display.
>
In this scenario, where would I specify the virtual X resolution? I am
assuming it would be in the panel-timing node as Pawel suggested?
> This would match some hardware where the video RAM is indeed a separate
> physical set of RAM (such as the IM-PD/1).
>
^ permalink raw reply
* Re: [PATCH] video: ARM CLCD: Added support for FBIO_WAITFORVSYNC
From: Arun Ramamurthy @ 2015-03-02 19:09 UTC (permalink / raw)
To: Pawel Moll
Cc: Rob Herring, Mark Rutland, Ian Campbell, Kumar Gala, Russell King,
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: <1425312029.3092.1.camel@arm.com>
On 15-03-02 08:00 AM, Pawel Moll wrote:
> On Wed, 2015-02-25 at 21:01 +0000, Arun Ramamurthy wrote:
>> Added ioctl and interrupt handler functions to support FBIO_WAITFORVSYNC
>> Also corrected documentation to make interrupts and interrupt-names
>> optional as they are not required properties.
>
> You may not be aware of this fact, but its the "documentation" what
> defines what properties are required...
>
Pawel, I was not aware of that. Since the driver code did not require
the interrupts or interrupt-names bindings to load properly, I moved it
out of the required properties. I can remove that change.
Any other comments on this change? Thanks
>> Reviewed-by: Ray Jui <rjui@broadcom.com>
>> Reviewed-by: Scott Branden <sbranden@broadcom.com>
>> Signed-off-by: Arun Ramamurthy <arun.ramamurthy@broadcom.com>0
>> ---
>> .../devicetree/bindings/video/arm,pl11x.txt | 11 +--
>> drivers/video/fbdev/amba-clcd.c | 82 ++++++++++++++++++++++
>> include/linux/amba/clcd.h | 4 ++
>> 3 files changed, 89 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt b/Documentation/devicetree/bindings/video/arm,pl11x.txt
>> index 2262cdb..7d19024 100644
>> --- a/Documentation/devicetree/bindings/video/arm,pl11x.txt
>> +++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
>> @@ -10,14 +10,6 @@ Required properties:
>>
>> - reg: base address and size of the control registers block
>>
>> -- interrupt-names: either the single entry "combined" representing a
>> - combined interrupt output (CLCDINTR), or the four entries
>> - "mbe", "vcomp", "lnbu", "fuf" representing the individual
>> - CLCDMBEINTR, CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR interrupts
>> -
>> -- interrupts: contains an interrupt specifier for each entry in
>> - interrupt-names
>> -
>> - clock-names: should contain "clcdclk" and "apb_pclk"
>>
>> - clocks: contains phandle and clock specifier pairs for the entries
>
> So no, you can't do that.
>
> Pawel
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox