* Re: Using s3virge card in Sun Blade 2000
From: Francois Romieu @ 2011-01-06 20:42 UTC (permalink / raw)
To: Alex Buell; +Cc: David Miller, linux-fbdev, linux-kernel
In-Reply-To: <1294274029.24378.11.camel@lithium>
Hi Alex,
Alex Buell <alex.buell@munted.org.uk> :
[...]
> The above code seems to work, and crashes after this point:
>
> /* Identify chip type */
> par->chip = id->driver_data & CHIP_MASK;
> par->rev = vga_rcrt(par->vga_iobase, 0x2f);
> if (par->chip & CHIP_UNDECIDED_FLAG)
> par->chip = s3_identification(par->chip);
^^^^^^^^^ ?
Sorry for the obvious but you modified s3_identification() so that it
stops emitting vga_rcrt(NULL, ...), right ?
--
Ueimor
^ permalink raw reply
* [PATCH 3/3] fbdev: sh_mobile_hdmi: simplify pointer handling
From: Guennadi Liakhovetski @ 2011-01-06 18:24 UTC (permalink / raw)
To: linux-fbdev
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
drivers/video/sh_mobile_hdmi.c | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c
index 4a1f3f4..ac7e5d8 100644
--- a/drivers/video/sh_mobile_hdmi.c
+++ b/drivers/video/sh_mobile_hdmi.c
@@ -821,9 +821,9 @@ static int sh_hdmi_read_edid(struct sh_hdmi *hdmi)
* driver, and passing ->info with HDMI platform data.
*/
if (info && !found) {
- modelist = hdmi->info->modelist.next &&
- !list_empty(&hdmi->info->modelist) ?
- list_entry(hdmi->info->modelist.next,
+ modelist = info->modelist.next &&
+ !list_empty(&info->modelist) ?
+ list_entry(info->modelist.next,
struct fb_modelist, list) :
NULL;
@@ -1055,6 +1055,7 @@ static void sh_hdmi_edid_work_fn(struct work_struct *work)
mutex_lock(&hdmi->mutex);
if (hdmi->hp_state = HDMI_HOTPLUG_EDID_DONE) {
+ struct fb_info *info = hdmi->info;
/* A device has been plugged in */
pm_runtime_get_sync(hdmi->dev);
@@ -1073,22 +1074,21 @@ static void sh_hdmi_edid_work_fn(struct work_struct *work)
/* Switched to another (d) power-save mode */
msleep(10);
- if (!hdmi->info)
+ if (!info)
goto out;
- ch = hdmi->info->par;
+ ch = info->par;
acquire_console_sem();
/* HDMI plug in */
if (!sh_hdmi_must_reconfigure(hdmi) &&
- hdmi->info->state = FBINFO_STATE_RUNNING) {
+ info->state = FBINFO_STATE_RUNNING) {
/*
* First activation with the default monitor - just turn
* on, if we run a resume here, the logo disappears
*/
- if (lock_fb_info(hdmi->info)) {
- struct fb_info *info = hdmi->info;
+ if (lock_fb_info(info)) {
info->var.width = hdmi->var.width;
info->var.height = hdmi->var.height;
sh_hdmi_display_on(hdmi, info);
@@ -1096,7 +1096,7 @@ static void sh_hdmi_edid_work_fn(struct work_struct *work)
}
} else {
/* New monitor or have to wake up */
- fb_set_suspend(hdmi->info, 0);
+ fb_set_suspend(info, 0);
}
release_console_sem();
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/3] fbdev: sh_mobile_hdmi: framebuffer notifiers have to be
From: Guennadi Liakhovetski @ 2011-01-06 18:23 UTC (permalink / raw)
To: linux-fbdev
A previous patch added a framebuffer notifier to sh_mobile_hdmi.c,
but did not register it with the framebuffer core. This patch adds
such a registration and moves the notifier block into dynamically
allocated per-device private data.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
On the one hand this patch fixes a bug - a notifier has been added to the
driver, but it had never been registered. OTOH, this notifier will only be
called on sh_mobile_lcdcfb module unloading, but modular functionality of
sh-mobile framebuffer drivers seems to be largely broken to me. So, this
patch only makes this driver look correct, but the functionality has to be
fixed further.
drivers/video/sh_mobile_hdmi.c | 19 +++++++++----------
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c
index f18a619..4a1f3f4 100644
--- a/drivers/video/sh_mobile_hdmi.c
+++ b/drivers/video/sh_mobile_hdmi.c
@@ -217,6 +217,7 @@ struct sh_hdmi {
struct delayed_work edid_work;
struct fb_var_screeninfo var;
struct fb_monspecs monspec;
+ struct notifier_block notifier;
};
static void hdmi_write(struct sh_hdmi *hdmi, u8 data, u8 reg)
@@ -1126,13 +1127,6 @@ out:
}
static int sh_hdmi_notify(struct notifier_block *nb,
- unsigned long action, void *data);
-
-static struct notifier_block sh_hdmi_notifier = {
- .notifier_call = sh_hdmi_notify,
-};
-
-static int sh_hdmi_notify(struct notifier_block *nb,
unsigned long action, void *data)
{
struct fb_event *event = data;
@@ -1141,7 +1135,7 @@ static int sh_hdmi_notify(struct notifier_block *nb,
struct sh_mobile_lcdc_board_cfg *board_cfg = &ch->cfg.board_cfg;
struct sh_hdmi *hdmi = board_cfg->board_data;
- if (nb != &sh_hdmi_notifier || !hdmi || hdmi->info != info)
+ if (!hdmi || nb != &hdmi->notifier || hdmi->info != info)
return NOTIFY_DONE;
switch(action) {
@@ -1160,11 +1154,11 @@ static int sh_hdmi_notify(struct notifier_block *nb,
* temporarily, synchronise with the work queue and re-acquire
* the info->lock.
*/
- unlock_fb_info(hdmi->info);
+ unlock_fb_info(info);
mutex_lock(&hdmi->mutex);
hdmi->info = NULL;
mutex_unlock(&hdmi->mutex);
- lock_fb_info(hdmi->info);
+ lock_fb_info(info);
return NOTIFY_OK;
}
return NOTIFY_DONE;
@@ -1253,6 +1247,9 @@ static int __init sh_hdmi_probe(struct platform_device *pdev)
goto ecodec;
}
+ hdmi->notifier.notifier_call = sh_hdmi_notify;
+ fb_register_client(&hdmi->notifier);
+
return 0;
ecodec:
@@ -1283,6 +1280,8 @@ static int __exit sh_hdmi_remove(struct platform_device *pdev)
snd_soc_unregister_codec(&pdev->dev);
+ fb_unregister_client(&hdmi->notifier);
+
board_cfg->display_on = NULL;
board_cfg->display_off = NULL;
board_cfg->board_data = NULL;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/3] fbdev: sh_mobile_hdmi: add command line option to use
From: Guennadi Liakhovetski @ 2011-01-06 18:23 UTC (permalink / raw)
To: linux-fbdev
Currently, if no command-line option is specified, the sh_mobile_hdmi
will use the default 720p video mode. If a command line option of the
form "video=sh_mobile_lcdc:<width>x<height>@<refresh>" is provided,
the driver will look for that mode among those, available in the
monitor EDID. This patch adds the ability to request the driver to
use monitor's preferred mode by specifying 0 as width and hight in
the above string. If that mode is not supported by the system, the
driver will continue scanning through EDID modes, until it finds a
suitable one.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
drivers/video/sh_mobile_hdmi.c | 59 +++++++++++++++++++++++++++------------
1 files changed, 41 insertions(+), 18 deletions(-)
diff --git a/drivers/video/sh_mobile_hdmi.c b/drivers/video/sh_mobile_hdmi.c
index fcda0e9..f18a619 100644
--- a/drivers/video/sh_mobile_hdmi.c
+++ b/drivers/video/sh_mobile_hdmi.c
@@ -713,7 +713,7 @@ static int sh_hdmi_read_edid(struct sh_hdmi *hdmi)
struct fb_modelist *modelist = NULL;
unsigned int f_width = 0, f_height = 0, f_refresh = 0;
unsigned long found_rate_error = ULONG_MAX; /* silly compiler... */
- bool exact_match = false;
+ bool scanning = false, preferred_bad = false;
u8 edid[128];
char *forced;
int i;
@@ -745,6 +745,9 @@ static int sh_hdmi_read_edid(struct sh_hdmi *hdmi)
if (i < 2) {
f_width = 0;
f_height = 0;
+ } else {
+ /* The user wants us to use the EDID data */
+ scanning = true;
}
dev_dbg(hdmi->dev, "Forced mode %ux%u@%uHz\n",
f_width, f_height, f_refresh);
@@ -752,34 +755,54 @@ static int sh_hdmi_read_edid(struct sh_hdmi *hdmi)
/* Walk monitor modes to find the best or the exact match */
for (i = 0, mode = hdmi->monspec.modedb;
- f_width && f_height && i < hdmi->monspec.modedb_len && !exact_match;
+ i < hdmi->monspec.modedb_len && scanning;
i++, mode++) {
- unsigned long rate_error = sh_hdmi_rate_error(hdmi, mode);
+ unsigned long rate_error;
- /* No interest in unmatching modes */
- if (f_width != mode->xres || f_height != mode->yres)
- continue;
- if (f_refresh = mode->refresh || (!f_refresh && !rate_error))
- /*
- * Exact match if either the refresh rate matches or it
- * hasn't been specified and we've found a mode, for
- * which we can configure the clock precisely
- */
- exact_match = true;
- else if (found && found_rate_error <= rate_error)
+ if (!f_width && !f_height) {
/*
- * We otherwise search for the closest matching clock
- * rate - either if no refresh rate has been specified
- * or we cannot find an exactly matching one
+ * A parameter string "video=sh_mobile_lcdc:0x0" means
+ * use the preferred EDID mode. If it is rejected by
+ * .fb_check_var(), keep looking, until an acceptable
+ * one is found.
*/
+ if ((mode->flag & FB_MODE_IS_FIRST) || preferred_bad)
+ scanning = false;
+ else
+ continue;
+ } else if (f_width != mode->xres || f_height != mode->yres) {
+ /* No interest in unmatching modes */
continue;
+ }
+
+ rate_error = sh_hdmi_rate_error(hdmi, mode);
+
+ if (scanning) {
+ if (f_refresh = mode->refresh || (!f_refresh && !rate_error))
+ /*
+ * Exact match if either the refresh rate
+ * matches or it hasn't been specified and we've
+ * found a mode, for which we can configure the
+ * clock precisely
+ */
+ scanning = false;
+ else if (found && found_rate_error <= rate_error)
+ /*
+ * We otherwise search for the closest matching
+ * clock rate - either if no refresh rate has
+ * been specified or we cannot find an exactly
+ * matching one
+ */
+ continue;
+ }
/* Check if supported: sufficient fb memory, supported clock-rate */
fb_videomode_to_var(var, mode);
if (info && info->fbops->fb_check_var &&
info->fbops->fb_check_var(var, info)) {
- exact_match = false;
+ scanning = true;
+ preferred_bad = true;
continue;
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH 0/3] fbdev: sh-mobile HDMI
From: Guennadi Liakhovetski @ 2011-01-06 18:23 UTC (permalink / raw)
To: linux-fbdev
3 not really logically connected HDMI patches for 2.6.38.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [GIT PULL] fbdev updates for 2.6.38-rc1
From: Paul Mundt @ 2011-01-06 15:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-fbdev, linux-kernel
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/lethal/fbdev-2.6.git
Which contains:
Aaro Koskinen (13):
sisfb: eliminate unused variable compiler warning
sisfb: delete HAVE_CONFIG_H checks
sisfb: remove duplicate function declarations
sisfb: change register I/O functions to use fixed size types
sisfb: replace inSISREG with SiS_GetRegByte
sisfb: replace outSISREG with SiS_SetRegByte
sisfb: replace inSISIDXREG with SiS_GetReg
sisfb: replace outSISIDXREG with SiS_SetReg
sisfb: replace orSISIDXREG with SiS_SetRegOR
sisfb: replace andSISIDXREG with SiS_SetRegAND
sisfb: replace setSISIDXREG with SiS_SetRegANDOR
sisfb: delete unused register I/O macros
sisfb: eliminate compiler warnings
Alexey Charkov (3):
ARM: Add support for the display controllers in VT8500 and WM8505
fbdev: Minor cleanup in WM8505-related code
fbdev: Modify vsync timing calculation in wm8505fb
Andres Salomon (1):
s1d13xxxfb: drop unused code
Arnd Hannemann (1):
fbdev: modedb: fix CEA modes
Brent Cook (1):
video: Fix the HGA framebuffer driver
Daniel Drake (2):
viafb: General power management infrastructure
viafb: Add OLPC XO-1.5 port configs
Erik Gilling (1):
video: add fb_edid_add_monspecs for parsing extended edid information
Fabio Estevam (1):
video: imxfb: Fix the maximum value for yres
Guennadi Liakhovetski (13):
fbdev: sh_mobile_hdmi: add support for more precise HDMI clock configuration
fbdev: sh_mobile_hdmi: improve support for more video modes
fbdev: sh_mobile_lcdc: increase maximum framebuffer size to support 1080p
fbdev: sh_mobile_hdmi: add support for 1080p modes
ARM: mach-shmobile: optimize PLLC2 frequency for HDMI
fbdev: export fb_edid_add_monspecs() for modules, improve algorithm
fbdev: when parsing E-EDID blocks, also use SVD entries
fbdev: sh_mobile_hdmi: add support for E-EDID parsing
fbdev: sh-mobile: implement MIPI DSI runtime PM support
ARM: mach-shmobile: improve MIPI DSI clock configuration
fbdev: sh_mipi_dsi: support different register layouts
ARM: mach-shmobile: specify sh7372 MIPI DSI register layout
fbdev: sh_mipi_dsi: use platform provided register layout and values
Jingoo Han (1):
s3c-fb: add support for runtime pm
Joe Perches (1):
video: mx3fb: Use vsprintf extension %pR for struct resource
Jonathan Corbet (1):
viafb: suspend/resume for GPIOs
Julia Lawall (1):
drivers/video/carminefb.c: improve error handling
Magnus Damm (5):
fbdev: sh_mipi_dsi: Make use of register names
ARM: mach-shmobile: Extend AP4EVB MIPI-DSI resources
fbdev: sh_mipi_dsi: Require two I/O resources V2
fbdev: sh_mipi_dsi: Allow LCDC board callbacks
fbdev: sh_mobile_lcdcfb: Enable 32 bpp and 24 bpp support
Mayuresh Janorkar (1):
fbdev: modedb: Add a new mode for 864x480 TAAL panels.
Michael Hennerich (2):
fbdev: bf537-lq035: new Blackfin Sharp LQ035 framebuffer driver
fbdev: bfin_adv7393fb: new Blackfin ADV7393 driver
Paul Mundt (6):
fbdev: sh_mobile_lcdcfb: fix up compiler warnings.
fbdev: sh_mobile_hdmi: fix up compiler warnings.
fbdev: move udlfb out of staging.
video: udlfb: deifdefify (yes, that's a word).
video: udlfb: Kill off some magic constants for EDID sizing.
video: udlfb: Kill off special printk wrappers, use pr_fmt().
Stefani Seibold (1):
drivers/video/i810/i810-i2c.c: fix i2c bus handling
.../staging/udlfb => Documentation/fb}/udlfb.txt | 0
arch/arm/mach-shmobile/board-ap4evb.c | 70 +-
arch/arm/mach-shmobile/clock-sh7372.c | 13 +-
drivers/staging/Kconfig | 2 -
drivers/staging/Makefile | 1 -
drivers/staging/udlfb/Kconfig | 14 -
drivers/staging/udlfb/Makefile | 1 -
drivers/video/Kconfig | 120 ++-
drivers/video/Makefile | 6 +
drivers/video/bf537-lq035.c | 914 +++++++++++++++
drivers/video/bfin_adv7393fb.c | 832 ++++++++++++++
drivers/video/bfin_adv7393fb.h | 321 ++++++
drivers/video/carminefb.c | 6 +-
drivers/video/fbmon.c | 88 ++
drivers/video/hgafb.c | 22 +-
drivers/video/i810/i810-i2c.c | 12 +-
drivers/video/modedb.c | 51 +
drivers/video/mx3fb.c | 3 +-
drivers/video/s1d13xxxfb.c | 50 -
drivers/video/s3c-fb.c | 111 ++-
drivers/video/sh_mipi_dsi.c | 129 ++-
drivers/video/sh_mobile_hdmi.c | 219 +++--
drivers/video/sh_mobile_lcdcfb.c | 76 ++-
drivers/video/sis/init.c | 46 +-
drivers/video/sis/init.h | 13 -
drivers/video/sis/init301.c | 8 +-
drivers/video/sis/init301.h | 11 -
drivers/video/sis/sis.h | 65 +-
drivers/video/sis/sis_main.c | 1196 ++++++++++----------
drivers/{staging/udlfb => video}/udlfb.c | 135 +--
drivers/video/via/via-core.c | 96 ++-
drivers/video/via/via-gpio.c | 29 +
drivers/video/via/viafbdev.c | 34 +-
drivers/video/via/viafbdev.h | 2 -
drivers/video/vt8500lcdfb.c | 447 ++++++++
drivers/video/vt8500lcdfb.h | 34 +
drivers/video/wm8505fb.c | 422 +++++++
drivers/video/wm8505fb_regs.h | 76 ++
drivers/video/wmt_ge_rops.c | 186 +++
drivers/video/wmt_ge_rops.h | 5 +
include/linux/fb.h | 3 +
include/linux/via-core.h | 15 +
include/video/s1d13xxxfb.h | 6 -
include/video/sh_mipi_dsi.h | 6 +
include/video/sh_mobile_hdmi.h | 3 +
{drivers/staging/udlfb => include/video}/udlfb.h | 22 -
46 files changed, 4820 insertions(+), 1101 deletions(-)
rename {drivers/staging/udlfb => Documentation/fb}/udlfb.txt (100%)
delete mode 100644 drivers/staging/udlfb/Kconfig
delete mode 100644 drivers/staging/udlfb/Makefile
create mode 100644 drivers/video/bf537-lq035.c
create mode 100644 drivers/video/bfin_adv7393fb.c
create mode 100644 drivers/video/bfin_adv7393fb.h
rename drivers/{staging/udlfb => video}/udlfb.c (94%)
create mode 100644 drivers/video/vt8500lcdfb.c
create mode 100644 drivers/video/vt8500lcdfb.h
create mode 100644 drivers/video/wm8505fb.c
create mode 100644 drivers/video/wm8505fb_regs.h
create mode 100644 drivers/video/wmt_ge_rops.c
create mode 100644 drivers/video/wmt_ge_rops.h
rename {drivers/staging/udlfb => include/video}/udlfb.h (78%)
^ permalink raw reply
* Memory sharing issue by application on V4L2 based device driver with
From: daeinki @ 2011-01-06 12:57 UTC (permalink / raw)
To: linux-arm-kernel
Hello, all.
I'd like to discuss memory sharing issue by application on v4l2 based
device driver with system mmu and get some advices about that.
Now I am working on Samsung SoC C210 platform and this platform has some
multimedia devices with system mmu such as fimc, and mfc also we have
implemented device drivers for them. those drivers are based on V4L2
framework with videobuf2. for system mmu of each device, we used
VCM(Virtual Contiguous Memory) framework.
Simply, VCM framework provides physical memory, device virtual memory
allocation and memory mapping between them. when device driver is
initialized or operated by user application, each driver allocates
physical memory and device virtual memory and then mapping using VCM
interface.
refer to below link for more detail.
http://www.spinics.net/lists/linux-media/msg26548.html
Physical memory access process is as the following.
DVA PA
device --------------> system mmu ------------------> physical memory
DVA : device virtual address.
PA : physical address.
like this, device virtual address should be set to buffer(source or
destination) register of multimedia device.
the problem is that application want to share own memory with any device
driver to avoid memory copy. in other words, user-allocated memory could
be source or destination memory of multimedia device driver.
let's see the diagram below.
user application
|
|
|
|
| 1. UVA(allocated by malloc)
|
|
¡¬|/ 2. UVA(in page unit)
-----> multimedia device driver -------------------> videobuf2
|
| | ^ |
| | | |
| | -------------------------------------------
| | 3. PA(in page unit)
| |
| | 4. PA(in page unit)
6. DVA | |
| |
| |
| ¡¬|/
|
| Virtual Contiguous Memory ---------
| |
| | ^ |
| | | | 5. map PA to DVA
| | | |
| | | |
------------- -------------------------
PA : physical address.
UVA : user virtual address.
DVA : device virtual address.
1. user application allocates user space memory through malloc function
and sending it to multimedia device driver based on v4l2 framework
through userptr feature.
2, 3. multimedia device driver gets translated physical address from
videobuf2 framework in page unit.
4, 5. multimedia device driver gets allocated device virtual address and
mapping it to physical address and then mapping them through VCM interface.
6. multimedia device driver sets device virtual address from VCM to
buffer register.
the diagram above is fully theoretical so I wonder that this way is
reasonable and has some problems also what should be considered.
thank you for your interesting.
^ permalink raw reply
* Re: [RESEND #2] [PATCH v2] LEDS: Add output invertion option to
From: Richard Purdie @ 2011-01-06 12:02 UTC (permalink / raw)
To: Paul Mundt, Andrew Morton
Cc: Janusz Krzysztofik, linux-fbdev@vger.kernel.org, linux-kernel,
linux-omap@vger.kernel.org
In-Reply-To: <20110106070816.GA15914@linux-sh.org>
On Thu, 2011-01-06 at 16:08 +0900, Paul Mundt wrote:
> (Trying an alternate address for Richard, and adding Andrew to Cc..)
>
> On Thu, Dec 09, 2010 at 02:41:50PM +0100, Janusz Krzysztofik wrote:
> > This patch extends the LED backlight tirgger driver with an option that allows
> > for inverting the trigger output polarity.
> >
> > With the invertion option provided, I (ab)use the backlight trigger for
> > driving a LED that indicates LCD display blank condtition on my Amstrad Delta
> > videophone. Since the machine has no dedicated power LED, it was not possible
> > to distinguish if the display was blanked, or the machine was turned off,
> > without touching it.
> >
> > The invert sysfs control is patterned after a similiar function of the GPIO
> > trigger driver.
> >
> > Created and tested against linux-2.6.36-rc5 on Amstrad Delta.
> > Retested on linux-2.6.37-rc4.
> >
> > Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
> > Cc: Richard Purdie <rpurdie@rpsys.net>
Acked-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I'll let Andrew take the patch though.
> > ---
> >
> > Resent because I still can't see any response received, while yet another
> > merge window is going to pass away soon.
> >
> > Applies cleanly on top of 2.6.37-rc4, so no need for yet another refresh. Only
> > tried to clean up the commit message slightly - maybe my English is not good
> > enough to bother with, if not the code?
> >
> > v1 -> v2 changes:
> > - improve some conditional expressions to be more readable; thanks to Ralph
> > Corderoy (from e3-hacking) and Lars-Peter Clausen for their suggestions,
> > - refresh against linux-2.6.36-rc5.
> >
> > drivers/leds/ledtrig-backlight.c | 60
> > ++++++++++++++++++++++++++++++++++++---
> > 1 file changed, 56 insertions(+), 4 deletions(-)
> >
> > diff -upr linux-2.6.36-rc5.orig/drivers/leds/ledtrig-backlight.c linux-2.6.36-rc5/drivers/leds/ledtrig-backlight.c
> > --- linux-2.6.36-rc5.orig/drivers/leds/ledtrig-backlight.c 2010-09-24 15:35:13.000000000 +0200
> > +++ linux-2.6.36-rc5/drivers/leds/ledtrig-backlight.c 2010-10-03 15:59:49.000000000 +0200
> > @@ -26,6 +26,7 @@ struct bl_trig_notifier {
> > int brightness;
> > int old_status;
> > struct notifier_block notifier;
> > + unsigned invert;
> > };
> >
> > static int fb_notifier_callback(struct notifier_block *p,
> > @@ -36,23 +37,63 @@ static int fb_notifier_callback(struct n
> > struct led_classdev *led = n->led;
> > struct fb_event *fb_event = data;
> > int *blank = fb_event->data;
> > + int new_status = *blank ? BLANK : UNBLANK;
> >
> > switch (event) {
> > case FB_EVENT_BLANK :
> > - if (*blank && n->old_status = UNBLANK) {
> > + if (new_status = n->old_status)
> > + break;
> > +
> > + if ((n->old_status = UNBLANK) ^ n->invert) {
> > n->brightness = led->brightness;
> > led_set_brightness(led, LED_OFF);
> > - n->old_status = BLANK;
> > - } else if (!*blank && n->old_status = BLANK) {
> > + } else {
> > led_set_brightness(led, n->brightness);
> > - n->old_status = UNBLANK;
> > }
> > +
> > + n->old_status = new_status;
> > +
> > break;
> > }
> >
> > return 0;
> > }
> >
> > +static ssize_t bl_trig_invert_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + struct led_classdev *led = dev_get_drvdata(dev);
> > + struct bl_trig_notifier *n = led->trigger_data;
> > +
> > + return sprintf(buf, "%s\n", n->invert ? "yes" : "no");
> > +}
> > +
> > +static ssize_t bl_trig_invert_store(struct device *dev,
> > + struct device_attribute *attr, const char *buf, size_t num)
> > +{
> > + struct led_classdev *led = dev_get_drvdata(dev);
> > + struct bl_trig_notifier *n = led->trigger_data;
> > + unsigned invert;
> > + int ret;
> > +
> > + ret = sscanf(buf, "%u", &invert);
> > + if (ret < 1) {
> > + dev_err(dev, "invalid value\n");
> > + return -EINVAL;
> > + }
> > +
> > + n->invert = !!invert;
> > +
> > + /* After inverting, we need to update the LED. */
> > + if ((n->old_status = BLANK) ^ n->invert)
> > + led_set_brightness(led, LED_OFF);
> > + else
> > + led_set_brightness(led, n->brightness);
> > +
> > + return num;
> > +}
> > +static DEVICE_ATTR(invert, 0644, bl_trig_invert_show, bl_trig_invert_store);
> > +
> > static void bl_trig_activate(struct led_classdev *led)
> > {
> > int ret;
> > @@ -66,6 +107,10 @@ static void bl_trig_activate(struct led_
> > return;
> > }
> >
> > + ret = device_create_file(led->dev, &dev_attr_invert);
> > + if (ret)
> > + goto err_invert;
> > +
> > n->led = led;
> > n->brightness = led->brightness;
> > n->old_status = UNBLANK;
> > @@ -74,6 +119,12 @@ static void bl_trig_activate(struct led_
> > ret = fb_register_client(&n->notifier);
> > if (ret)
> > dev_err(led->dev, "unable to register backlight trigger\n");
> > +
> > + return;
> > +
> > +err_invert:
> > + led->trigger_data = NULL;
> > + kfree(n);
> > }
> >
> > static void bl_trig_deactivate(struct led_classdev *led)
> > @@ -82,6 +133,7 @@ static void bl_trig_deactivate(struct le
> > (struct bl_trig_notifier *) led->trigger_data;
> >
> > if (n) {
> > + device_remove_file(led->dev, &dev_attr_invert);
> > fb_unregister_client(&n->notifier);
> > kfree(n);
> > }
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 4/9] fb: export fb mode db table
From: Sascha Hauer @ 2011-01-06 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106072658.GB15914@linux-sh.org>
On Thu, Jan 06, 2011 at 04:26:58PM +0900, Paul Mundt wrote:
> On Thu, Dec 09, 2010 at 02:47:16PM +0100, Sascha Hauer wrote:
> > The different modes can be useful for drivers. Currently there is
> > no way to expose the modes to sysfs, so export them.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>
> I'll admit I don't really like the idea of exposing the modedb to drivers
> in this way, but given that we're already doing it for the vesa and cea
> modes, allowing drivers to copy ranges in to their modelist from the
> standard db is probably something we can live with.
>
> The mode list dumping is basically a blatant sysfs abuse already though,
You mean the available modes should not be exposed to sysfs? I found it
quite convenient to have during development. Exporting the modedb seemed
to be the only way to populate sysfs with a sane set of modes.
> and it would be much cleaner simply to back the mode store with an
> fb_find/try_mode() pair that grovels all the right places in addition to
> doing a pass over the fb_info's modelist.
The kernel provides no way to query the modelist other than sysfs. So
when the modelist dumping is a sysfs abuse, what purpose does the
modelist have anyway?
Right now the behaviour is quite strange. Each time a new (formerly
unknown) mode is selected the modelist magically gets a new entry. So
the kernel normally starts with an empty (or one entry from startup)
modelist and gets populated over time with the modes the user used.
I could understand when we say: "We do not keep the modelist in kernel,
do this in userspace". I could also understand when we say "we keep a
list of sane modes in the kernel, use fbset to switch to exotic modes".
ATM we do the worst of both: We keep a list but we do not populate it
with sane modes. Even worse, we use it to store the history of modes.
I know much of this comes from the fact that the fb subsystem does not
have a maintainer and nowadays the big desktop guys are not using the fb
subsystem at all, but it's really hard to find a way through and every
driver seems to have it's own idea of how things should work.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [Xen-devel] Re: [patch] xenfb: fix xenfb suspend/resume race
From: Ian Campbell @ 2011-01-06 8:47 UTC (permalink / raw)
To: Joe Jin
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
gurudas.pai@oracle.com, Konrad Rzeszutek Wilk,
guru.anbalagane@oracle.com, greg.marsden@oracle.com,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
Andrew Morton
In-Reply-To: <1294300924.13733.42.camel@localhost.localdomain>
On Thu, 2011-01-06 at 08:02 +0000, Ian Campbell wrote:
>
> > Check if irq is valid will fix this issue.
>
> No, it papers over the issue, the code should never have been allowed
> to get this far if the connection to the backend is not yet fully
> resumed (i.e. when irq = -1).
On the other hand changing a kernel crash into a WARN_ON has merit in
its own right, I just think it is a stretch to say the xenfb issue is
fixed by it! You'd need to also make the warning go away to be able to
say that.
> @@ -175,6 +175,10 @@ static struct irq_info *info_for_irq(unsigned irq)
>
> static unsigned int evtchn_from_irq(unsigned irq)
> {
> + if (unlikely(irq < 0 || irq >= nr_irqs)) {
> + WARN_ON(1, "[%s]: Invalid irq(%d)!\n", __func__, irq);
Did this compile without warnings? That isn't the correct syntax for a
WARN_ON since it takes only a condition and not the additional message.
I think this can simplified as:
if (WARN(irq < 0 || irq >= nr_irqs, "invalid irq %d!\n", irq))
return 0;
I think WARN includes the file name and line number as well as a stack
trace so including the function name is unnecessary.
I'm not sure the condition used is totally valid for a modern kernel
with sparse IRQs (it probably needs to do a irq_to_desc lookup) but I
think we can defer that until events.c moves to the more dynamic scheme
this implies (I should resurrect those patches now that thiongs have
settled down after the dom0 merge).
Ian.
^ permalink raw reply
* Re: [patch] xenfb: fix xenfb suspend/resume race
From: Joe Jin @ 2011-01-06 8:14 UTC (permalink / raw)
To: Ian Campbell
Cc: Konrad Rzeszutek Wilk, jeremy@goop.org, Andrew Morton,
linux-fbdev@vger.kernel.org, xen-devel@lists.xensource.com,
linux-kernel@vger.kernel.org, gurudas.pai@oracle.com,
greg.marsden@oracle.com, guru.anbalagane@oracle.com
In-Reply-To: <1294300924.13733.42.camel@localhost.localdomain>
>
> No, it papers over the issue, the code should never have been allowed to
> get this far if the connection to the backend is not yet fully resumed
> (i.e. when irq = -1).
>
> The call to xenfb_send_event should have been gated further up the call
> chain, AFAICT by the check of info->update_wanted in xenfb_refresh. This
> suggests that the correct fix is to set info->update_wanted = 0 in
> xenfb_resume.
>
> I said all this in my previous mail and you ignored it. Did you try this
> approach?
Will try this then update you.
Thanks,
Joe
^ permalink raw reply
* Re: [PATCH] fbdev: sh_mobile_lcdcfb: Enable 32 bpp and 24 bpp support
From: Paul Mundt @ 2011-01-06 8:07 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20110105102100.13620.6354.sendpatchset@t400s>
On Wed, Jan 05, 2011 at 07:21:00PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm@opensource.se>
>
> This patch extends the LCDC driver with 24 bpp
> and 32 bpp support.
>
> These modes have been kept disabled earlier due
> to dependencies between the potential two LCDC
> channels that are exported as two separate
> framebuffer devices. The dependency boils down
> to a byte swap register that is shared between
> multiple channels.
>
> With this patch applied all single channel LCDC
> hardware can chose freely from 16, 24 and 32 bpp.
> Dual channel LCDC must stick to the same setup
> for both channels.
>
> Without this patch only 16 bpp is fully supported.
>
> Signed-off-by: Magnus Damm <damm@opensource.se>
Applied, thanks.
^ permalink raw reply
* Re: [patch] xenfb: fix xenfb suspend/resume race
From: Ian Campbell @ 2011-01-06 8:02 UTC (permalink / raw)
To: Joe Jin
Cc: Konrad Rzeszutek Wilk, jeremy@goop.org, Andrew Morton,
linux-fbdev@vger.kernel.org, xen-devel@lists.xensource.com,
linux-kernel@vger.kernel.org, gurudas.pai@oracle.com,
greg.marsden@oracle.com, guru.anbalagane@oracle.com
In-Reply-To: <4D256BC7.1080501@oracle.com>
On Thu, 2011-01-06 at 07:14 +0000, Joe Jin wrote:
> On 01/04/11 19:15, Ian Campbell wrote:
> > On Thu, 2010-12-30 at 16:40 +0000, Konrad Rzeszutek Wilk wrote:
> >> On Thu, Dec 30, 2010 at 08:56:16PM +0800, Joe Jin wrote:
> >>> Hi,
> >>
> >> Joe,
> >>
> >> Patch looks good, however..
> >>
> >> I am unclear from your description whether the patch fixes
> >> the problem (I would presume so). Or does it take a long time
> >> to hit this race?
> >
> > I also don't see how the patch relates to the stack trace.
> >
> > Is the issue is that xenfb_send_event is called between xenfb_resume
> > (which tears down the state, including evtchn->irq binding) and the
> > probe/connect of the new fb?
>
> Yes, when hit this issue, with debugging kernel found irq is invalid(-1).
But why is it -1? I really don't think you have identified the root
cause here. If you really have identified the root cause then your
changelog needs to go into much greater depth regarding your analysis.
> Check if irq is valid will fix this issue.
No, it papers over the issue, the code should never have been allowed to
get this far if the connection to the backend is not yet fully resumed
(i.e. when irq = -1).
The call to xenfb_send_event should have been gated further up the call
chain, AFAICT by the check of info->update_wanted in xenfb_refresh. This
suggests that the correct fix is to set info->update_wanted = 0 in
xenfb_resume.
I said all this in my previous mail and you ignored it. Did you try this
approach?
> And, when failed to connect to backend, need to release the resource.
So the changes to xenfb_connect_backend are independent of the irq = -1
issue? In which case this part, which seems like a reasonable and valid
fix, should be split into a separate patch.
> Please review new patch for this issue.
Nacked-by: Ian Campbell <ian.campbell@citrix.com>
Ian.
> Thanks,
> Joe
>
>
> Signed-off-by: Joe Jin <joe.jin@oracle.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
>
> ---
> video/xen-fbfront.c | 19 +++++++++++--------
> xen/events.c | 4 ++++
> 2 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
> index dc72563..367fb1c 100644
> --- a/drivers/video/xen-fbfront.c
> +++ b/drivers/video/xen-fbfront.c
> @@ -561,26 +561,24 @@ static void xenfb_init_shared_page(struct xenfb_info *info,
> static int xenfb_connect_backend(struct xenbus_device *dev,
> struct xenfb_info *info)
> {
> - int ret, evtchn;
> + int ret, evtchn, irq;
> struct xenbus_transaction xbt;
>
> ret = xenbus_alloc_evtchn(dev, &evtchn);
> if (ret)
> return ret;
> - ret = bind_evtchn_to_irqhandler(evtchn, xenfb_event_handler,
> + irq = bind_evtchn_to_irqhandler(evtchn, xenfb_event_handler,
> 0, dev->devicetype, info);
> - if (ret < 0) {
> + if (irq < 0) {
> xenbus_free_evtchn(dev, evtchn);
> xenbus_dev_fatal(dev, ret, "bind_evtchn_to_irqhandler");
> - return ret;
> + return irq;
> }
> - info->irq = ret;
> -
> again:
> ret = xenbus_transaction_start(&xbt);
> if (ret) {
> xenbus_dev_fatal(dev, ret, "starting transaction");
> - return ret;
> + goto unbind_irq;
> }
> ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
> virt_to_mfn(info->page));
> @@ -602,15 +600,20 @@ static int xenfb_connect_backend(struct xenbus_device *dev,
> if (ret = -EAGAIN)
> goto again;
> xenbus_dev_fatal(dev, ret, "completing transaction");
> - return ret;
> + goto unbind_irq;
> }
>
> xenbus_switch_state(dev, XenbusStateInitialised);
> + info->irq = irq;
> return 0;
>
> error_xenbus:
> xenbus_transaction_end(xbt, 1);
> xenbus_dev_fatal(dev, ret, "writing xenstore");
> + unbind_irq:
> + printk(KERN_ERR "xenfb_connect_backend failed!\n");
> + unbind_from_irqhandler(irq, info);
> + xenbus_free_evtchn(dev, evtchn);
> return ret;
> }
>
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index ac7b42f..4028704 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -175,6 +175,10 @@ static struct irq_info *info_for_irq(unsigned irq)
>
> static unsigned int evtchn_from_irq(unsigned irq)
> {
> + if (unlikely(irq < 0 || irq >= nr_irqs)) {
> + WARN_ON(1, "[%s]: Invalid irq(%d)!\n", __func__, irq);
> + return 0;
> + }
> return info_for_irq(irq)->evtchn;
> }
>
^ permalink raw reply
* Re: [PATCH 4/9] fb: export fb mode db table
From: Paul Mundt @ 2011-01-06 7:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1291902441-24712-5-git-send-email-s.hauer@pengutronix.de>
On Thu, Dec 09, 2010 at 02:47:16PM +0100, Sascha Hauer wrote:
> The different modes can be useful for drivers. Currently there is
> no way to expose the modes to sysfs, so export them.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
I'll admit I don't really like the idea of exposing the modedb to drivers
in this way, but given that we're already doing it for the vesa and cea
modes, allowing drivers to copy ranges in to their modelist from the
standard db is probably something we can live with.
The mode list dumping is basically a blatant sysfs abuse already though,
and it would be much cleaner simply to back the mode store with an
fb_find/try_mode() pair that grovels all the right places in addition to
doing a pass over the fb_info's modelist.
^ permalink raw reply
* Re: [patch] xenfb: fix xenfb suspend/resume race
From: Joe Jin @ 2011-01-06 7:14 UTC (permalink / raw)
To: Ian Campbell
Cc: Konrad Rzeszutek Wilk, jeremy@goop.org, Andrew Morton,
linux-fbdev@vger.kernel.org, xen-devel@lists.xensource.com,
linux-kernel@vger.kernel.org, gurudas.pai@oracle.com,
greg.marsden@oracle.com, guru.anbalagane@oracle.com
In-Reply-To: <1294139733.3831.141.camel@zakaz.uk.xensource.com>
On 01/04/11 19:15, Ian Campbell wrote:
> On Thu, 2010-12-30 at 16:40 +0000, Konrad Rzeszutek Wilk wrote:
>> On Thu, Dec 30, 2010 at 08:56:16PM +0800, Joe Jin wrote:
>>> Hi,
>>
>> Joe,
>>
>> Patch looks good, however..
>>
>> I am unclear from your description whether the patch fixes
>> the problem (I would presume so). Or does it take a long time
>> to hit this race?
>
> I also don't see how the patch relates to the stack trace.
>
> Is the issue is that xenfb_send_event is called between xenfb_resume
> (which tears down the state, including evtchn->irq binding) and the
> probe/connect of the new fb?
Yes, when hit this issue, with debugging kernel found irq is invalid(-1).
Check if irq is valid will fix this issue.
And, when failed to connect to backend, need to release the resource.
Please review new patch for this issue.
Thanks,
Joe
Signed-off-by: Joe Jin <joe.jin@oracle.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
video/xen-fbfront.c | 19 +++++++++++--------
xen/events.c | 4 ++++
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index dc72563..367fb1c 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -561,26 +561,24 @@ static void xenfb_init_shared_page(struct xenfb_info *info,
static int xenfb_connect_backend(struct xenbus_device *dev,
struct xenfb_info *info)
{
- int ret, evtchn;
+ int ret, evtchn, irq;
struct xenbus_transaction xbt;
ret = xenbus_alloc_evtchn(dev, &evtchn);
if (ret)
return ret;
- ret = bind_evtchn_to_irqhandler(evtchn, xenfb_event_handler,
+ irq = bind_evtchn_to_irqhandler(evtchn, xenfb_event_handler,
0, dev->devicetype, info);
- if (ret < 0) {
+ if (irq < 0) {
xenbus_free_evtchn(dev, evtchn);
xenbus_dev_fatal(dev, ret, "bind_evtchn_to_irqhandler");
- return ret;
+ return irq;
}
- info->irq = ret;
-
again:
ret = xenbus_transaction_start(&xbt);
if (ret) {
xenbus_dev_fatal(dev, ret, "starting transaction");
- return ret;
+ goto unbind_irq;
}
ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
virt_to_mfn(info->page));
@@ -602,15 +600,20 @@ static int xenfb_connect_backend(struct xenbus_device *dev,
if (ret = -EAGAIN)
goto again;
xenbus_dev_fatal(dev, ret, "completing transaction");
- return ret;
+ goto unbind_irq;
}
xenbus_switch_state(dev, XenbusStateInitialised);
+ info->irq = irq;
return 0;
error_xenbus:
xenbus_transaction_end(xbt, 1);
xenbus_dev_fatal(dev, ret, "writing xenstore");
+ unbind_irq:
+ printk(KERN_ERR "xenfb_connect_backend failed!\n");
+ unbind_from_irqhandler(irq, info);
+ xenbus_free_evtchn(dev, evtchn);
return ret;
}
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index ac7b42f..4028704 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -175,6 +175,10 @@ static struct irq_info *info_for_irq(unsigned irq)
static unsigned int evtchn_from_irq(unsigned irq)
{
+ if (unlikely(irq < 0 || irq >= nr_irqs)) {
+ WARN_ON(1, "[%s]: Invalid irq(%d)!\n", __func__, irq);
+ return 0;
+ }
return info_for_irq(irq)->evtchn;
}
^ permalink raw reply related
* Re: [RESEND #2] [PATCH v2] LEDS: Add output invertion option to backlight trigger
From: Paul Mundt @ 2011-01-06 7:08 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Richard Purdie, linux-fbdev@vger.kernel.org, linux-kernel,
linux-omap@vger.kernel.org, Richard Purdie, Andrew Morton
In-Reply-To: <201012091441.51846.jkrzyszt@tis.icnet.pl>
(Trying an alternate address for Richard, and adding Andrew to Cc..)
On Thu, Dec 09, 2010 at 02:41:50PM +0100, Janusz Krzysztofik wrote:
> This patch extends the LED backlight tirgger driver with an option that allows
> for inverting the trigger output polarity.
>
> With the invertion option provided, I (ab)use the backlight trigger for
> driving a LED that indicates LCD display blank condtition on my Amstrad Delta
> videophone. Since the machine has no dedicated power LED, it was not possible
> to distinguish if the display was blanked, or the machine was turned off,
> without touching it.
>
> The invert sysfs control is patterned after a similiar function of the GPIO
> trigger driver.
>
> Created and tested against linux-2.6.36-rc5 on Amstrad Delta.
> Retested on linux-2.6.37-rc4.
>
> Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
> Cc: Richard Purdie <rpurdie@rpsys.net>
> ---
>
> Resent because I still can't see any response received, while yet another
> merge window is going to pass away soon.
>
> Applies cleanly on top of 2.6.37-rc4, so no need for yet another refresh. Only
> tried to clean up the commit message slightly - maybe my English is not good
> enough to bother with, if not the code?
>
> v1 -> v2 changes:
> - improve some conditional expressions to be more readable; thanks to Ralph
> Corderoy (from e3-hacking) and Lars-Peter Clausen for their suggestions,
> - refresh against linux-2.6.36-rc5.
>
> drivers/leds/ledtrig-backlight.c | 60
> ++++++++++++++++++++++++++++++++++++---
> 1 file changed, 56 insertions(+), 4 deletions(-)
>
> diff -upr linux-2.6.36-rc5.orig/drivers/leds/ledtrig-backlight.c linux-2.6.36-rc5/drivers/leds/ledtrig-backlight.c
> --- linux-2.6.36-rc5.orig/drivers/leds/ledtrig-backlight.c 2010-09-24 15:35:13.000000000 +0200
> +++ linux-2.6.36-rc5/drivers/leds/ledtrig-backlight.c 2010-10-03 15:59:49.000000000 +0200
> @@ -26,6 +26,7 @@ struct bl_trig_notifier {
> int brightness;
> int old_status;
> struct notifier_block notifier;
> + unsigned invert;
> };
>
> static int fb_notifier_callback(struct notifier_block *p,
> @@ -36,23 +37,63 @@ static int fb_notifier_callback(struct n
> struct led_classdev *led = n->led;
> struct fb_event *fb_event = data;
> int *blank = fb_event->data;
> + int new_status = *blank ? BLANK : UNBLANK;
>
> switch (event) {
> case FB_EVENT_BLANK :
> - if (*blank && n->old_status = UNBLANK) {
> + if (new_status = n->old_status)
> + break;
> +
> + if ((n->old_status = UNBLANK) ^ n->invert) {
> n->brightness = led->brightness;
> led_set_brightness(led, LED_OFF);
> - n->old_status = BLANK;
> - } else if (!*blank && n->old_status = BLANK) {
> + } else {
> led_set_brightness(led, n->brightness);
> - n->old_status = UNBLANK;
> }
> +
> + n->old_status = new_status;
> +
> break;
> }
>
> return 0;
> }
>
> +static ssize_t bl_trig_invert_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct led_classdev *led = dev_get_drvdata(dev);
> + struct bl_trig_notifier *n = led->trigger_data;
> +
> + return sprintf(buf, "%s\n", n->invert ? "yes" : "no");
> +}
> +
> +static ssize_t bl_trig_invert_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t num)
> +{
> + struct led_classdev *led = dev_get_drvdata(dev);
> + struct bl_trig_notifier *n = led->trigger_data;
> + unsigned invert;
> + int ret;
> +
> + ret = sscanf(buf, "%u", &invert);
> + if (ret < 1) {
> + dev_err(dev, "invalid value\n");
> + return -EINVAL;
> + }
> +
> + n->invert = !!invert;
> +
> + /* After inverting, we need to update the LED. */
> + if ((n->old_status = BLANK) ^ n->invert)
> + led_set_brightness(led, LED_OFF);
> + else
> + led_set_brightness(led, n->brightness);
> +
> + return num;
> +}
> +static DEVICE_ATTR(invert, 0644, bl_trig_invert_show, bl_trig_invert_store);
> +
> static void bl_trig_activate(struct led_classdev *led)
> {
> int ret;
> @@ -66,6 +107,10 @@ static void bl_trig_activate(struct led_
> return;
> }
>
> + ret = device_create_file(led->dev, &dev_attr_invert);
> + if (ret)
> + goto err_invert;
> +
> n->led = led;
> n->brightness = led->brightness;
> n->old_status = UNBLANK;
> @@ -74,6 +119,12 @@ static void bl_trig_activate(struct led_
> ret = fb_register_client(&n->notifier);
> if (ret)
> dev_err(led->dev, "unable to register backlight trigger\n");
> +
> + return;
> +
> +err_invert:
> + led->trigger_data = NULL;
> + kfree(n);
> }
>
> static void bl_trig_deactivate(struct led_classdev *led)
> @@ -82,6 +133,7 @@ static void bl_trig_deactivate(struct le
> (struct bl_trig_notifier *) led->trigger_data;
>
> if (n) {
> + device_remove_file(led->dev, &dev_attr_invert);
> fb_unregister_client(&n->notifier);
> kfree(n);
> }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] Adding a timings for panel-taal in mode database
From: Paul Mundt @ 2011-01-06 7:00 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB03232B6B13@dbde02.ent.ti.com>
On Mon, Jan 03, 2011 at 04:31:40PM +0530, Janorkar, Mayuresh wrote:
> Adding a new entry n mode database file for PANEL-TAAL.
> PANEL-TAAL is the default panel used for OMAP boards. The resolution is 864 X 480.
> This new entry would enable us to make use of bootarg omapfb.mode.
>
> Signed-off-by: Mayuresh Janorkar <mayur@ti.com>
This one looks fine, I've applied it by hand, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] Cleaning up modedb file
From: Paul Mundt @ 2011-01-06 6:55 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB03232B6B12@dbde02.ent.ti.com>
On Mon, Jan 03, 2011 at 04:31:38PM +0530, Janorkar, Mayuresh wrote:
> A part of file: drivers/video/modedb.c was not as per the coding guidelines.
>
> The cleanup includes:
> 1) Converting spcaes to tabs
> 2) Adding spaces on either sides of "|" operator
>
> Signed-off-by: Mayuresh Janorkar <mayur@ti.com>
> ---
> drivers/video/modedb.c | 316 ++++++++++++++++++++----------------------------
> 1 files changed, 134 insertions(+), 182 deletions(-)
>
The irony here is that your mailer has in turn converted your tabs back
to spaces, so it doesn't apply. :-)
^ permalink raw reply
* Re: [PATCH] fix i810 i2c bug
From: Paul Mundt @ 2011-01-06 6:53 UTC (permalink / raw)
To: Stefani Seibold
Cc: linux-kernel, akpm, linux-fbdev, adaplas, Maik Broemme,
Dave Airlie
In-Reply-To: <1294046939.20021.12.camel@wall-e>
On Mon, Jan 03, 2011 at 10:28:59AM +0100, Stefani Seibold wrote:
> These patch fix a longstanding bug in the i810 frame buffer driver.
>
> The handling of the i2c bus is wrong: A 1 bit should not written to the
> i2c, these will be done by switch the i2c to input. Driving an 1 bit
> active is against the i2c spec.
>
> An active driven of a 1 bit will result in very strange error, depending
> which side is the more powerful one. In my case it depends on the
> temperature of the Display-Controller-EEprom: With an cold eprom a got
> the correct EDID datas, with a warm one some of the 1 bits was 0 :-(
>
> The same bug is also in the intelfb driver in the file
> drivers/video/intelfb/intelfb_i2c.c. The functions intelfb_gpio_setscl()
> and intelfb_gpio_setsda() do drive the 1 bit active to the i2c bus. But
> since i have no card which is used by the intelfb driver i cannot fix
> it.
>
> The patch is against linux next-20101231
>
> - Stefani
>
> Signed-off-by: Stefani Seibold <stefani@seibold.net>
Applied, thanks.
Also adding intelfb people to the Cc so they're aware of the problem, and
can follow suit.
^ permalink raw reply
* Re: [PATCH RE-SEND] s3c-fb: Add support S5PV310 FIMD
From: daeinki @ 2011-01-06 6:51 UTC (permalink / raw)
To: Kukjin Kim
Cc: linux-samsung-soc, linux-fbdev, ben-linux, akpm, lethal,
'Jonghun Han', 'Sangbeom Kim'
In-Reply-To: <00db01cbad61$4a308d80$de91a880$%kim@samsung.com>
Hello, Mr. Kukjin.
Kukjin Kim 쓴 글:
> Inki Dae wrote:
>> Hello, Mr. Kukjin.
>>
> Hi,
>
>> I know we had a discussion about your patch below.
>> after that, did you have some discussion about that?
>> If not, Paul advised to use clkdev lookup.
>>
>> Please, refer to below mail.
>>
> http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg03448.html
>
> I think it's different with your approach even though the purpose is similar
> and I know, Mr. Han explained about clock configurable by call.
please, refer to below.
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg03445.html
for identify clock types("lcd" for bus clock or "fimd" for sclk_fimd),
using switch-case seems to be bad. for avoiding this one I suggested
other way and the way clock type selection from platform data is also
bad so Paul adviced us to use clk_dev lookup.
>
> Paul, how do you think about this?
>
> Personally, if we want to support S5PV310 FIMD now, this patch is good to
> support it and to us now.
> Of course, I think, we can upgrade it later.
>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
>>> -----Original Message-----
>>> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
>>> owner@vger.kernel.org] On Behalf Of Kukjin Kim
>>> Sent: Tuesday, January 04, 2011 5:06 PM
>>> To: linux-samsung-soc@vger.kernel.org; linux-fbdev@vger.kernel.org
>>> Cc: ben-linux@fluff.org; akpm@linux-foundation.org; lethal@linux-sh.org;
>>> Jonghun Han; Sangbeom Kim; InKi Dae; Kukjin Kim
>>> Subject: [PATCH RE-SEND] s3c-fb: Add support S5PV310 FIMD
>>>
>>> From: Jonghun Han <jonghun.han@samsung.com>
>>>
>>> This patch adds struct s3c_fb_driverdata s3c_fb_data_s5pv310 for S5PV310
>>> and S5PC210. The clk_type is added to distinguish clock type in it and
>>> lcd_clk is added in structure s3c_fb to calculate divider for lcd panel.
>>>
>>> Please refer to below diagrams about clocks of FIMD IP. FIMD driver
> needs
>>> two clocks for FIMD IP and LCD pixel clock. Actually, the LCD pixel
> clock
>>> can be selected from 1.clk 'lcd' and 2.SCLK_FIMD before S5PV310. But
> from
>>> S5PV310, the 2.SCLK_FIMD can be used only for source of LCD pixel clock.
>>>
>>> FIMD_CLK_TYPE0:
>>> ------------------------------------
>>> dsys bus
>>> ----------------+-------------------
>>> |
>>> |1.clk 'lcd'
>>> |
>>> | FIMD block
>>> +---+-----------+
>>> 4.mout_mpll |\ | | |
>>> --------|m| | +-+-+ +----+ |
>>> |u|-+ | | +-+core| |
>>> |x| | | | +----+ |
>>> |/ | | | |\ |
>>> | | +-|m| +---+ |
>>> | | |u|--+div| |
>>> +------+---|x| +---+ |
>>> 2.SCLK_FIMD | |/ | |
>>> | | |
>>> +----------+----+
>>> |
>>> inside of SoC |
>>> -----------------------+--------------------------
>>> outside of SoC |
>>> | 3.LCD pixel clock
>>> |
>>> +--------------+
>>> | LCD module |
>>> +--------------+
>>>
>>> FIMD_CLK_TYPE1:
>>> ------------------------------------
>>> dsys bus
>>> ----------------+-------------------
>>> |
>>> |1.clk 'fimd'
>>> |
>>> | FIMD block
>>> +---+-----------+
>>> 4.mout_mpll |\ | | |
>>> --------|m| | | +----+ |
>>> |u|-+ | +---+core| |
>>> |x| | | +----+ |
>>> |/ | | |
>>> | | +---+ |
>>> | | +--+div| |
>>> +------+-----+ +---+ |
>>> 2.SCLK_FIMD | | |
>>> | | |
>>> +----------+----+
>>> |
>>> inside of SoC |
>>> -----------------------+--------------------------
>>> outside of SoC |
>>> | 3.LCD pixel clock
>>> |
>>> +--------------+
>>> | LCD module |
>>> +--------------+
>>>
>>> Signed-off-by: Jonghun Han <jonghun.han@samsung.com>
>>> Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
>>> Cc: InKi Dae <inki.dae@samsung.com>
>>> Cc: Ben Dooks <ben-linux@fluff.org>
>>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
>>> ---
>>> Hi Paul,
>>>
>>> I and Mr. Han, Jonghun sent below patch several weeks ago.
>>> But I couldn't find it in your tree...
>>> (Re-made against on your latest fbdev-2.6.git #master)
>>>
>>> I think this should be merged for supporting S5PV310/S5PC210 frame
> buffer.
>>> So could you please let me know your opinion or plan about this?
>>>
>>> NOTE: Needs following platform device patches for S5PV310/S5PC210 frame
>>> buffer.
>>> And I already applied that in my tree as S5P SoCs architecture
> maintainer.
>>> 0001-ARM-S5PV310-Add-FIMD-resource-definition.patch
>>> 0002-ARM-S5PV310-Add-platform-device-and-helper-functio.patch
>>> 0004-ARM-S5PV310-Add-support-FIMD0-and-LTE480WV-LCD-for.patch
>>>
>>> drivers/video/Kconfig | 2 +-
>>> drivers/video/s3c-fb.c | 125
>>> +++++++++++++++++++++++++++++++++++++++++++-----
>>> 2 files changed, 113 insertions(+), 14 deletions(-)
>
>
^ permalink raw reply
* Re: [PATCH] Fix the HGA framebuffer driver
From: Paul Mundt @ 2011-01-06 6:47 UTC (permalink / raw)
To: linux-fbdev
On Thu, Dec 30, 2010 at 11:56:50PM -0600, Brent Cook wrote:
> Resurrected some old hardware and fixed up the hgafb driver to work again. Only
> tested with fbcon, since most fbdev-based software appears to only support
> 12bpp and up. It does not appear that this driver has worked for at least the
> entire 2.6.x series, perhaps since 2002.
>
> I sent this to the sourceforge mailing list before realizing the list had
> moved. http://www.linux-fbdev.org/ has the wrong mailing list info.
>
> Regards,
> Brent
>
> Signed-off-by: Brent Cook <busterb@gmail.com>
>
> Hercules graphics hardware uses packed pixels horizontally, but rows are not
> linear. In other words, the pixels are not packed vertically. This means that
> custom imageblit, fillrect and copyarea need to be written specific to the
> hardware.
>
> * Removed the experimental acceleration option, since it is required for the
> hardware to work.
> * Fixed imageblit to work with fb_image's wider than 8 pixels.
> * Updated configuration text (HGA hardware is from 1984)
I shuffled the changelog around to include these bits and applied it,
thanks.
^ permalink raw reply
* Re: [PATCH] drivers/video/carminefb.c: improve error handling
From: Paul Mundt @ 2011-01-06 6:45 UTC (permalink / raw)
To: Julia Lawall; +Cc: linux-fbdev, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.1101021527220.10933@ask.diku.dk>
On Sun, Jan 02, 2011 at 03:27:42PM +0100, Julia Lawall wrote:
> From: Julia Lawall <julia@diku.dk>
>
> This code had an error handling goto to the wrong place, a misplaced
> release_mem_region, and a duplicated release_mem_region.
>
> The semantic match that finds the double release_mem_region is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @r@
> expression e1,e2,e3;
> position p1,p2,p3;
> @@
> release_mem_region@p1(e1, e2)@p3;
> ... when != request_mem_region(e1,e2,e3)
> release_mem_region(e1, e2)@p2;
>
> @@
> expression e <= r.e1,e3;
> expression r.e1,e2;
> position r.p1,r.p2,r.p3,p!=r.p1;
> @@
> *release_mem_region(e1, e2)@p3;
> ... when != e = e3
> *release_mem_region@p(e1, e2)@p2;// </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3] video: imxfb: Fix the maximum value for yres
From: Paul Mundt @ 2011-01-06 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1293193704-2855-1-git-send-email-fabio.estevam@freescale.com>
On Fri, Dec 24, 2010 at 10:28:24AM -0200, Fabio Estevam wrote:
> MX27 and MX25 have 10 bits in the YMAX field of LCDC Size Register.
>
> Fix the maximum value for yres.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] gx1fb: Fix section mismatch derived from gx1fb_driver variable
From: Paul Mundt @ 2011-01-06 6:39 UTC (permalink / raw)
To: Sedat Dilek; +Cc: linux-geode, linux-fbdev, linux-kernel, Sedat Dilek
In-Reply-To: <1294018289-3911-1-git-send-email-sedat.dilek@gmail.com>
On Mon, Jan 03, 2011 at 02:31:29AM +0100, Sedat Dilek wrote:
> diff --git a/drivers/video/geode/gx1fb_core.c b/drivers/video/geode/gx1fb_core.c
> index c6b554f..9fdb115 100644
> --- a/drivers/video/geode/gx1fb_core.c
> +++ b/drivers/video/geode/gx1fb_core.c
> @@ -437,7 +437,7 @@ static struct pci_device_id gx1fb_id_table[] = {
>
> MODULE_DEVICE_TABLE(pci, gx1fb_id_table);
>
> -static struct pci_driver gx1fb_driver = {
> +static struct pci_driver gx1fb_driver __refdata = {
> .name = "gx1fb",
> .id_table = gx1fb_id_table,
> .probe = gx1fb_probe,
The problem seems to be because gx1fb_probe is annotated __init. In the
PCI case you want it to be __devinit, and you're also going to want to
annotate the remove function as __devexit and wrap it up with a
__devexit_p().
^ permalink raw reply
* Re: [PATCH] Corrected matroxfb video option in comments and kernel config help.
From: Paul Mundt @ 2011-01-06 6:35 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <AANLkTikqCduraRjVvtaU3u1ikQyR-3GryovdTMe-z5HD@mail.gmail.com>
On Tue, Dec 28, 2010 at 11:03:50AM +0100, Vicente Jim?nez wrote:
> From 81561bbf722613794c77cd03c537f4139b2d0976 Mon Sep 17 00:00:00 2001
> From: Vicente Jimenez Aguilar <googuy@gmail.com>
> Date: Tue, 28 Dec 2010 11:35:24 +0100
> Subject: [PATCH 2/2] Corrected matroxfb video option in comments and kernel config help.
>
> Configuring the kernel I found that the Matrox frame buffer help has a
> different option than the one in the docs (Documentation/fb/matroxfb.txt).
> I decided to check the source code to see what is the correct option.
> drivers/video/matrox/matroxfb_base.c has a lot of comments that sugests
> that the video option is "matrox".
> However in line 2452 of this same file you have:
> fb_get_options("matroxfb", &option)
>
> video=matroxfb:XXX is the correct video option not video=matrox:XXX.
Missing Signed-off-by.
^ 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