* [PATCH v2 12/12] video: da8xx-fb: set upstream clock rate (if reqd)
From: Afzal Mohammed @ 2013-01-15 13:56 UTC (permalink / raw)
To: Florian Tobias Schandinat, Tomi Valkeinen, Grant Likely,
Rob Herring, Rob Landley, Mike Turquette, Sekhar Nori, linux-omap,
linux-fbdev, devicetree-discuss, linux-doc, linux-kernel
In-Reply-To: <cover.1358251447.git.afzal@ti.com>
LCDC IP has a clock divider to adjust pixel clock, this limits pixel
clock range to fck/255 - fck/2(fck - rate of input clock to LCDC IP).
In the case of AM335x, where this IP is present, default fck is not
sufficient to provide normal pixel clock rates, hence rendering this
driver unusable on AM335x.
If input clock too is configurable, allowable range of pixel clock
would increase. Here initially it is checked whether with present fck,
divider in IP could be configured to obtain required rate, if not,
fck is adjusted. This makes it usable on AM335x.
Note:
A better (if allowable) solution may be to represent clock divider in
LCDC IP as a basic divider clock - the one defined in common clock
framework. But for this to happen, all the platform's using this driver
should be using common clock framework (DaVinci is yet to be converted
to use common clock framework). And it has to be determined whether
common clock framework allows this kind of a clock modelling inside a
driver and for this to be part of clock tree. Advantage of doing so
would be better resolution for pixel clock, even though without this
existing use cases are working properly. Or another extreme alternative
would be to replicate clk-divider of common clock framework inside the
driver, but that probably is not preferred and not worth as it would be
duplication and without much advantage to existing users.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
v2: new patch
drivers/video/da8xx-fb.c | 76 +++++++++++++++++++++++++++++++++++-----------
1 file changed, 58 insertions(+), 18 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 5455682..09dfa12 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -133,6 +133,9 @@
#define WSI_TIMEOUT 50
#define PALETTE_SIZE 256
+#define CLK_MIN_DIV 2
+#define CLK_MAX_DIV 255
+
static void __iomem *da8xx_fb_reg_base;
static struct resource *lcdc_regs;
static unsigned int lcd_revision;
@@ -683,23 +686,21 @@ static void da8xx_fb_lcd_reset(void)
}
}
-static inline unsigned da8xx_fb_calc_clk_divider(struct da8xx_fb_par *par,
- unsigned pixclock)
-{
- return par->lcd_fck_rate / (PICOS2KHZ(pixclock) * 1000);
-}
-
-static inline unsigned da8xx_fb_round_clk(struct da8xx_fb_par *par,
- unsigned pixclock)
+static int da8xx_fb_config_clk_divider(struct da8xx_fb_par *par,
+ unsigned div, unsigned rate)
{
- unsigned div;
+ int ret;
- div = da8xx_fb_calc_clk_divider(par, pixclock);
- return KHZ2PICOS(par->lcd_fck_rate / (1000 * div));
-}
+ if (par->lcd_fck_rate != rate) {
+ ret = clk_set_rate(par->lcdc_clk, rate);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(par->dev,
+ "unable to set clock rate at %u\n", rate);
+ return ret;
+ }
+ par->lcd_fck_rate = clk_get_rate(par->lcdc_clk);
+ }
-static inline void da8xx_fb_config_clk_divider(unsigned div)
-{
/* Configure the LCD clock divisor. */
lcdc_write(LCD_CLK_DIVISOR(div) |
(LCD_RASTER_MODE & 0x1), LCD_CTRL_REG);
@@ -707,14 +708,49 @@ static inline void da8xx_fb_config_clk_divider(unsigned div)
if (lcd_revision = LCD_VERSION_2)
lcdc_write(LCD_V2_DMA_CLK_EN | LCD_V2_LIDD_CLK_EN |
LCD_V2_CORE_CLK_EN, LCD_CLK_ENABLE_REG);
+
+ return 0;
+}
+
+static unsigned int da8xx_fb_calc_clk_divider(struct da8xx_fb_par *par,
+ unsigned pixclock,
+ unsigned *rate)
+{
+ unsigned div;
+
+ pixclock = PICOS2KHZ(pixclock) * 1000;
+
+ *rate = par->lcd_fck_rate;
+
+ if (pixclock < (*rate / CLK_MAX_DIV)) {
+ *rate = clk_round_rate(par->lcdc_clk, pixclock * CLK_MAX_DIV);
+ div = CLK_MAX_DIV;
+ } else if (pixclock > (*rate / CLK_MIN_DIV)) {
+ *rate = clk_round_rate(par->lcdc_clk, pixclock * CLK_MIN_DIV);
+ div = CLK_MIN_DIV;
+ } else {
+ div = *rate / pixclock;
+ }
+
+ return div;
}
-static inline void da8xx_fb_calc_config_clk_divider(struct da8xx_fb_par *par,
+static inline int da8xx_fb_calc_config_clk_divider(struct da8xx_fb_par *par,
struct fb_videomode *mode)
{
- unsigned div = da8xx_fb_calc_clk_divider(par, mode->pixclock);
+ unsigned rate;
+ unsigned div = da8xx_fb_calc_clk_divider(par, mode->pixclock, &rate);
- da8xx_fb_config_clk_divider(div);
+ return da8xx_fb_config_clk_divider(par, div, rate);
+}
+
+static inline unsigned da8xx_fb_round_clk(struct da8xx_fb_par *par,
+ unsigned pixclock)
+{
+ unsigned div, rate;
+
+ div = da8xx_fb_calc_clk_divider(par, pixclock, &rate);
+ return KHZ2PICOS(rate / (1000 * div));
}
static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,
@@ -723,7 +759,11 @@ static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,
u32 bpp;
int ret = 0;
- da8xx_fb_calc_config_clk_divider(par, panel);
+ ret = da8xx_fb_calc_config_clk_divider(par, panel);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(par->dev, "unable to configure clock\n");
+ return ret;
+ }
if (panel->sync & FB_SYNC_CLK_INVERT)
lcdc_write((lcdc_read(LCD_RASTER_TIMING_2_REG) |
--
1.7.9.5
^ permalink raw reply related
* RE: [PATCH 08/10] video: da8xx-fb: obtain fb_videomode info from dt
From: Mohammed, Afzal @ 2013-01-15 13:59 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Florian Tobias Schandinat,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Nori, Sekhar,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Valkeinen, Tomi,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA7FC7A-Er742YJ7I/eIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
SGkgU3RlZmZlbiwNCg0KT24gTW9uLCBKYW4gMDcsIDIwMTMgYXQgMTQ6NTE6MTUsIE1vaGFtbWVk
LCBBZnphbCB3cm90ZToNCj4gT24gTW9uLCBKYW4gMDcsIDIwMTMgYXQgMTQ6NDE6MzEsIFN0ZWZm
ZW4gVHJ1bXRyYXIgd3JvdGU6DQo+ID4gT24gTW9uLCBKYW4gMDcsIDIwMTMgYXQgMTA6NDE6MzBB
TSArMDUzMCwgQWZ6YWwgTW9oYW1tZWQgd3JvdGU6DQoNCj4gPiA+ICstIGRpc3BsYXktdGltaW5n
czogbGlzdCBvZiBkaWZmZXJlbnQgdmlkZW9tb2RlcyBzdXBwb3J0ZWQgYnkgdGhlIGxjZA0KPiA+
ID4gKyAgcGFuZWwsIHJlcHJlc2VudGVkIGFzIGNoaWxkcywgY2FuIGhhdmUgbXVsdGlwbGUgbW9k
ZXMgc3VwcG9ydGVkLCBpZg0KPiA+ID4gKyAgb25seSBvbmUsIHRoZW4gaXQgaXMgY29uc2lkZXJl
ZCBuYXRpdmUgbW9kZSwgaWYgbXVsdGlwbGUgbW9kZXMgYXJlDQo+ID4gPiArICBwcm92aWRlZCwg
bmF0aXZlIG1vZGUgY2FuIGJlIHNldCBleHBsaWNpdGx5LCBtb3JlIGRldGFpbHMgYXZhaWxhYmxl
DQo+ID4gPiArICBARG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3ZpZGVvL2Rpc3Bs
YXktdGltaW5nLnR4dA0KPiANCj4gPiBLZWVwIGluIG1pbmQgdGhhdCB0aGUgdGV4dCBjb21iaW5l
ZCB3aXRoLi4uDQo+IA0KPiA+ID4gKwkJaWYgKG9mX2dldF9mYl92aWRlb21vZGUobnAsIGxjZGNf
aW5mbywgMCkpIHsNCj4gPiA+ICsJCQlkZXZfZXJyKCZkZXYtPmRldiwgInRpbWluZ3Mgbm90IGF2
YWlsYWJsZSBpbiBEVFxuIik7DQo+ID4gPiArCQkJcmV0dXJuIE5VTEw7DQo+ID4gPiArCQl9DQo+
ID4gPiArCQlyZXR1cm4gbGNkY19pbmZvOw0KPiA+ID4gKwl9DQo+ID4gDQo+ID4gLi4uIHRoaXMg
aXMgbm90IGNvcnJlY3QuIFlvdSBhcmUganVzdCBzdXBwb3J0aW5nIHRoZSBmaXJzdCBkaXNwbGF5
LXRpbWluZ3MNCj4gPiBzdWJub2RlIChvZl9nZXRfZmJfdmlkZW9tb2RlKC4uLiwgMCkpLg0KPiAN
Cj4gDQo+IFllcyByaWdodCwgSSB3aWxsIG1vZGlmeSB0aGUgdGV4dCB0byByZWZsZWN0IHdoYXQg
dGhlIGRyaXZlciBkb2VzLg0KDQpUaGlua2luZyBhYm91dCBpdCBmdXJ0aGVyLCBpdCBzZWVtcyB0
aGUgcmlnaHQgdGhpbmcgdG8gZG8NCmluIHRoaXMgY2FzZSB3b3VsZCBiZSB0byBpbnZva2UgYXMs
DQoNCiJvZl9nZXRfZmJfdmlkZW9tb2RlKG5wLCBsY2RfaW5mbywgT0ZfVVNFX05BVElWRV9NT0RF
KSIuDQoNClVwZGF0ZWQgdmVyc2lvbiBoYXMgYmVlbiBwb3N0ZWQgdG8gdGhlIGxpc3RzIChmb3Jn
b3QgdG8gY2MgeW91KQ0KDQpSZWdhcmRzDQpBZnphbA0KDQo
^ permalink raw reply
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
From: Takashi Iwai @ 2013-01-15 14:25 UTC (permalink / raw)
To: sedat.dilek; +Cc: Jiri Kosina, linux-fbdev, LKML, alan, Andrew Morton
In-Reply-To: <CA+icZUUxgRsGkYAmZ=JxTwPvdhTzpGLcxm6+VSq9jnfYPVXj4Q@mail.gmail.com>
At Sat, 5 Jan 2013 13:13:27 +0100,
Sedat Dilek wrote:
>
> Hi Jiri,
>
> ...known issue (see thread in [1]), please feel free to test patches
> from Alan and Andrew (see [1], [2] and [3]) and report.
>
> Regards,
> - Sedat -
>
> [1] http://marc.info/?t\x135309396400003&r=1&w=2
> [2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
> [3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
> [4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch
I've hit this bug and tried the patch [2] ([3] and [4] are gone).
Unfortunately the deadlock is still reported, as seen below.
A similar fix for fbcon_unbind(), splitting an unlocked version of
unbind_con_driver() and call it?
(BTW, the patch [2] contains strange characters in the comments, and
has a few coding issues easily detected by checkpatch.pl.)
thanks,
Takashi
=
[ 3.228454] [drm] Initialized drm 1.1.0 20060810
[ 3.317144] [drm] radeon defaulting to kernel modesetting.
[ 3.330546] [drm] radeon kernel modesetting enabled.
[ 3.343942] checking generic (c0000000 1000000) vs hw (c0000000 10000000)
[ 3.343946] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
[ 3.357376]
[ 3.357377] ===========================
[ 3.357378] [ INFO: possible circular locking dependency detected ]
[ 3.357380] 3.8.0-rc3-test+ #82 Not tainted
[ 3.357381] -------------------------------------------------------
[ 3.357383] udevd/137 is trying to acquire lock:
[ 3.357394] (console_lock){+.+.+.}, at: [<ffffffff8140385f>] unbind_con_driver+0x3f/0x200
[ 3.357395]
[ 3.357395] but task is already holding lock:
[ 3.357402] ((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff810799b1>] __blocking_notifier_call_chain+0x51/0xc0
[ 3.357403]
[ 3.357403] which lock already depends on the new lock.
[ 3.357403]
[ 3.357404]
[ 3.357404] the existing dependency chain (in reverse order) is:
[ 3.357407]
[ 3.357407] -> #1 ((fb_notifier_list).rwsem){.+.+.+}:
[ 3.357411] [<ffffffff810b605a>] lock_acquire+0xaa/0x210
[ 3.357417] [<ffffffff81643dc2>] down_read+0x42/0x57
[ 3.357419] [<ffffffff810799b1>] __blocking_notifier_call_chain+0x51/0xc0
[ 3.357422] [<ffffffff81079a31>] blocking_notifier_call_chain+0x11/0x20
[ 3.357426] [<ffffffff8138cbe6>] fb_notifier_call_chain+0x16/0x20
[ 3.357428] [<ffffffff8138e302>] register_framebuffer+0x1c2/0x2f0
[ 3.357433] [<ffffffff81d1748e>] vesafb_probe+0x6e0/0x760
[ 3.357437] [<ffffffff8142afbe>] platform_drv_probe+0x3e/0x70
[ 3.357440] [<ffffffff81428d26>] driver_probe_device+0x86/0x390
[ 3.357442] [<ffffffff814290d3>] __driver_attach+0xa3/0xb0
[ 3.357445] [<ffffffff81426dbd>] bus_for_each_dev+0x4d/0x90
[ 3.357447] [<ffffffff814286a9>] driver_attach+0x19/0x20
[ 3.357450] [<ffffffff81428308>] bus_add_driver+0x1a8/0x290
[ 3.357452] [<ffffffff81429792>] driver_register+0x72/0x170
[ 3.357455] [<ffffffff8142a7e1>] platform_driver_register+0x41/0x50
[ 3.357458] [<ffffffff8142a806>] platform_driver_probe+0x16/0xa0
[ 3.357460] [<ffffffff81d16d6b>] vesafb_init+0x215/0x258
[ 3.357464] [<ffffffff810002e2>] do_one_initcall+0x122/0x180
[ 3.357468] [<ffffffff816258ec>] kernel_init+0x1fc/0x370
[ 3.357471] [<ffffffff8164e1fc>] ret_from_fork+0x7c/0xb0
[ 3.357474]
[ 3.357474] -> #0 (console_lock){+.+.+.}:
[ 3.357476] [<ffffffff810b5055>] __lock_acquire+0x1385/0x1cc0
[ 3.357478] [<ffffffff810b605a>] lock_acquire+0xaa/0x210
[ 3.357482] [<ffffffff81048fbf>] console_lock+0x6f/0x80
[ 3.357485] [<ffffffff8140385f>] unbind_con_driver+0x3f/0x200
[ 3.357489] [<ffffffff8139aeb7>] fbcon_event_notify+0x447/0x8b0
[ 3.357492] [<ffffffff8164a225>] notifier_call_chain+0x55/0x110
[ 3.357495] [<ffffffff810799c7>] __blocking_notifier_call_chain+0x67/0xc0
[ 3.357497] [<ffffffff81079a31>] blocking_notifier_call_chain+0x11/0x20
[ 3.357500] [<ffffffff8138cbe6>] fb_notifier_call_chain+0x16/0x20
[ 3.357502] [<ffffffff8138debb>] do_unregister_framebuffer+0x5b/0x110
[ 3.357505] [<ffffffff8138e108>] do_remove_conflicting_framebuffers+0x158/0x190
[ 3.357507] [<ffffffff8138e46a>] remove_conflicting_framebuffers+0x3a/0x60
[ 3.357532] [<ffffffffa00df16b>] radeon_pci_probe+0x8b/0xd0 [radeon]
[ 3.357536] [<ffffffff8136d5a6>] local_pci_probe+0x46/0x80
[ 3.357539] [<ffffffff8136d7f1>] pci_device_probe+0x101/0x110
[ 3.357542] [<ffffffff81428d26>] driver_probe_device+0x86/0x390
[ 3.357544] [<ffffffff814290d3>] __driver_attach+0xa3/0xb0
[ 3.357547] [<ffffffff81426dbd>] bus_for_each_dev+0x4d/0x90
[ 3.357549] [<ffffffff814286a9>] driver_attach+0x19/0x20
[ 3.357552] [<ffffffff81428308>] bus_add_driver+0x1a8/0x290
[ 3.357554] [<ffffffff81429792>] driver_register+0x72/0x170
[ 3.357557] [<ffffffff8136c60f>] __pci_register_driver+0x5f/0x70
[ 3.357577] [<ffffffffa006ec3a>] drm_pci_init+0x11a/0x130 [drm]
[ 3.357594] [<ffffffffa01c20ec>] radeon_init+0xec/0x1000 [radeon]
[ 3.357597] [<ffffffff810002e2>] do_one_initcall+0x122/0x180
[ 3.357600] [<ffffffff810c4b53>] load_module+0x1043/0x1510
[ 3.357603] [<ffffffff810c50f7>] sys_init_module+0xd7/0x120
[ 3.357605] [<ffffffff8164e2ad>] system_call_fastpath+0x1a/0x1f
[ 3.357606]
[ 3.357606] other info that might help us debug this:
[ 3.357606]
[ 3.357607] Possible unsafe locking scenario:
[ 3.357607]
[ 3.357608] CPU0 CPU1
[ 3.357609] ---- ----
[ 3.357611] lock((fb_notifier_list).rwsem);
[ 3.357613] lock(console_lock);
[ 3.357615] lock((fb_notifier_list).rwsem);
[ 3.357616] lock(console_lock);
[ 3.357617]
[ 3.357617] *** DEADLOCK ***
[ 3.357617]
[ 3.357619] 5 locks held by udevd/137:
[ 3.357624] #0: (&__lockdep_no_validate__){......}, at: [<ffffffff81429083>] __driver_attach+0x53/0xb0
[ 3.357628] #1: (&__lockdep_no_validate__){......}, at: [<ffffffff81429091>] __driver_attach+0x61/0xb0
[ 3.357633] #2: (registration_lock){+.+.+.}, at: [<ffffffff8138e45b>] remove_conflicting_framebuffers+0x2b/0x60
[ 3.357637] #3: (&fb_info->lock){+.+.+.}, at: [<ffffffff8138d0c1>] lock_fb_info+0x21/0x60
[ 3.357642] #4: ((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff810799b1>] __blocking_notifier_call_chain+0x51/0xc0
[ 3.357643]
[ 3.357643] stack backtrace:
[ 3.357645] Pid: 137, comm: udevd Not tainted 3.8.0-rc3-test+ #82
[ 3.357646] Call Trace:
[ 3.357652] [<ffffffff8163b136>] print_circular_bug+0x1fb/0x20c
[ 3.357655] [<ffffffff810b5055>] __lock_acquire+0x1385/0x1cc0
[ 3.357658] [<ffffffff810b605a>] lock_acquire+0xaa/0x210
[ 3.357661] [<ffffffff8140385f>] ? unbind_con_driver+0x3f/0x200
[ 3.357664] [<ffffffff810b2b0d>] ? trace_hardirqs_on+0xd/0x10
[ 3.357667] [<ffffffff81048fbf>] console_lock+0x6f/0x80
[ 3.357670] [<ffffffff8140385f>] ? unbind_con_driver+0x3f/0x200
[ 3.357673] [<ffffffff8140385f>] unbind_con_driver+0x3f/0x200
[ 3.357676] [<ffffffff8134c01e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 3.357680] [<ffffffff8139aeb7>] fbcon_event_notify+0x447/0x8b0
[ 3.357683] [<ffffffff8164a225>] notifier_call_chain+0x55/0x110
[ 3.357685] [<ffffffff810799c7>] __blocking_notifier_call_chain+0x67/0xc0
[ 3.357688] [<ffffffff81079a31>] blocking_notifier_call_chain+0x11/0x20
[ 3.357690] [<ffffffff8138cbe6>] fb_notifier_call_chain+0x16/0x20
[ 3.357693] [<ffffffff8138debb>] do_unregister_framebuffer+0x5b/0x110
[ 3.357696] [<ffffffff8138e108>] do_remove_conflicting_framebuffers+0x158/0x190
[ 3.357698] [<ffffffff8138e46a>] remove_conflicting_framebuffers+0x3a/0x60
[ 3.357717] [<ffffffffa00df16b>] radeon_pci_probe+0x8b/0xd0 [radeon]
[ 3.357721] [<ffffffff8136d5a6>] local_pci_probe+0x46/0x80
[ 3.357724] [<ffffffff8136d7f1>] pci_device_probe+0x101/0x110
[ 3.357727] [<ffffffff81428d26>] driver_probe_device+0x86/0x390
[ 3.357729] [<ffffffff814290d3>] __driver_attach+0xa3/0xb0
[ 3.357732] [<ffffffff81429030>] ? driver_probe_device+0x390/0x390
[ 3.357734] [<ffffffff81426dbd>] bus_for_each_dev+0x4d/0x90
[ 3.357737] [<ffffffff814286a9>] driver_attach+0x19/0x20
[ 3.357740] [<ffffffff81428308>] bus_add_driver+0x1a8/0x290
[ 3.357744] [<ffffffffa01c2000>] ? 0xffffffffa01c1fff
[ 3.357747] [<ffffffff81429792>] driver_register+0x72/0x170
[ 3.357749] [<ffffffffa01c2000>] ? 0xffffffffa01c1fff
[ 3.357752] [<ffffffff8136c60f>] __pci_register_driver+0x5f/0x70
[ 3.357762] [<ffffffffa006ec3a>] drm_pci_init+0x11a/0x130 [drm]
[ 3.357764] [<ffffffffa01c2000>] ? 0xffffffffa01c1fff
[ 3.357767] [<ffffffffa01c2000>] ? 0xffffffffa01c1fff
[ 3.357784] [<ffffffffa01c20ec>] radeon_init+0xec/0x1000 [radeon]
[ 3.357786] [<ffffffff810002e2>] do_one_initcall+0x122/0x180
[ 3.357789] [<ffffffff810c4b53>] load_module+0x1043/0x1510
[ 3.357792] [<ffffffff8135d260>] ? ddebug_proc_open+0xb0/0xb0
[ 3.357796] [<ffffffff810c50f7>] sys_init_module+0xd7/0x120
[ 3.357798] [<ffffffff8164e2ad>] system_call_fastpath+0x1a/0x1f
^ permalink raw reply
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
From: Takashi Iwai @ 2013-01-15 14:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: sedat.dilek, Jiri Kosina, linux-fbdev, LKML, alan
In-Reply-To: <s5hpq16zfox.wl%tiwai@suse.de>
At Tue, 15 Jan 2013 15:25:18 +0100,
Takashi Iwai wrote:
>
> At Sat, 5 Jan 2013 13:13:27 +0100,
> Sedat Dilek wrote:
> >
> > Hi Jiri,
> >
> > ...known issue (see thread in [1]), please feel free to test patches
> > from Alan and Andrew (see [1], [2] and [3]) and report.
> >
> > Regards,
> > - Sedat -
> >
> > [1] http://marc.info/?t\x135309396400003&r=1&w=2
> > [2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
> > [3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
> > [4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch
>
> I've hit this bug and tried the patch [2] ([3] and [4] are gone).
> Unfortunately the deadlock is still reported, as seen below.
>
> A similar fix for fbcon_unbind(), splitting an unlocked version of
> unbind_con_driver() and call it?
>
> (BTW, the patch [2] contains strange characters in the comments, and
> has a few coding issues easily detected by checkpatch.pl.)
The fix patch for coding issue is below.
Feel free to fold into the original patch.
Takashi
=
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] fb: Fix coding style and remove stray non-ascii chars
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
drivers/tty/vt/vt.c | 4 ++--
drivers/video/console/fbcon.c | 3 +--
drivers/video/fbmem.c | 4 ++--
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index f307196..1db1c8d 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3653,7 +3653,7 @@ int do_take_over_console(const struct consw *csw, int first, int last, int deflt
/*
* If we get an busy error we still want to bind the console driver
* and return success, as we may have unbound the console driver
- * but not unregistered it.
+ * but not unregistered it.
*/
if (err = -EBUSY)
err = 0;
@@ -3679,7 +3679,7 @@ int take_over_console(const struct consw *csw, int first, int last, int deflt)
/*
* If we get an busy error we still want to bind the console driver
* and return success, as we may have unbound the console driver
- * but not unregistered it.
+ * but not unregistered it.
*/
if (err = -EBUSY)
err = 0;
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index c75f8ce..4bd7820 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -546,9 +546,8 @@ static int do_fbcon_takeover(int show_logo)
fbcon_is_default);
if (err) {
- for (i = first_fb_vc; i <= last_fb_vc; i++) {
+ for (i = first_fb_vc; i <= last_fb_vc; i++)
con2fb_map[i] = -1;
- }
info_idx = -1;
} else {
fbcon_has_console_bind = 1;
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 564ebe9..d8d9831 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1650,9 +1650,9 @@ static int do_register_framebuffer(struct fb_info *fb_info)
event.info = fb_info;
if (!lock_fb_info(fb_info))
return -ENODEV;
- console_lock();
+ console_lock();
fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, &event);
- console_unlock();
+ console_unlock();
unlock_fb_info(fb_info);
return 0;
}
--
1.8.1
^ permalink raw reply related
* Re: [PATCH v2 12/12] video: da8xx-fb: set upstream clock rate (if reqd)
From: Mike Turquette @ 2013-01-15 15:32 UTC (permalink / raw)
To: Afzal Mohammed, Florian Tobias Schandinat, Tomi Valkeinen,
Grant Likely, Rob Herring, Rob Landley, Sekhar Nori, linux-omap,
linux-fbdev, devicetree-discuss, linux-doc, linux-kernel
In-Reply-To: <26e787b021cda89a080f80657c2094b9ff2decaf.1358251448.git.afzal@ti.com>
Quoting Afzal Mohammed (2013-01-15 05:44:36)
> LCDC IP has a clock divider to adjust pixel clock, this limits pixel
> clock range to fck/255 - fck/2(fck - rate of input clock to LCDC IP).
> In the case of AM335x, where this IP is present, default fck is not
> sufficient to provide normal pixel clock rates, hence rendering this
> driver unusable on AM335x.
>
> If input clock too is configurable, allowable range of pixel clock
> would increase. Here initially it is checked whether with present fck,
> divider in IP could be configured to obtain required rate, if not,
> fck is adjusted. This makes it usable on AM335x.
>
> Note:
> A better (if allowable) solution may be to represent clock divider in
> LCDC IP as a basic divider clock - the one defined in common clock
> framework. But for this to happen, all the platform's using this driver
> should be using common clock framework (DaVinci is yet to be converted
> to use common clock framework). And it has to be determined whether
> common clock framework allows this kind of a clock modelling inside a
> driver and for this to be part of clock tree. Advantage of doing so
> would be better resolution for pixel clock, even though without this
> existing use cases are working properly. Or another extreme alternative
> would be to replicate clk-divider of common clock framework inside the
> driver, but that probably is not preferred and not worth as it would be
> duplication and without much advantage to existing users.
>
Afzal,
Modeling the divider inside your IP block as a clock is supported in the
common clock framework. Linking up these sorts of clocks to the clock
tree was one of the original design goals of CCF.
Regarding DaVinci: converting that platform over to use CCF would be the
best approach. An alternative would be that you could break
single-image boot for AM335x and DaVinci, by having AM335x use CCF and
DaVinci use the legacy clock framework. From the LCDC driver's
perspective this should not matter and is indeed the purpose of the
clk.h api and clkdev interfaces, however looking at this driver I can
see there would still be a lot ifdef-ery going on... better to just
convert everything over to CCF.
Regards,
Mike
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> ---
>
> v2: new patch
>
> drivers/video/da8xx-fb.c | 76 +++++++++++++++++++++++++++++++++++-----------
> 1 file changed, 58 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
> index 5455682..09dfa12 100644
> --- a/drivers/video/da8xx-fb.c
> +++ b/drivers/video/da8xx-fb.c
> @@ -133,6 +133,9 @@
> #define WSI_TIMEOUT 50
> #define PALETTE_SIZE 256
>
> +#define CLK_MIN_DIV 2
> +#define CLK_MAX_DIV 255
> +
> static void __iomem *da8xx_fb_reg_base;
> static struct resource *lcdc_regs;
> static unsigned int lcd_revision;
> @@ -683,23 +686,21 @@ static void da8xx_fb_lcd_reset(void)
> }
> }
>
> -static inline unsigned da8xx_fb_calc_clk_divider(struct da8xx_fb_par *par,
> - unsigned pixclock)
> -{
> - return par->lcd_fck_rate / (PICOS2KHZ(pixclock) * 1000);
> -}
> -
> -static inline unsigned da8xx_fb_round_clk(struct da8xx_fb_par *par,
> - unsigned pixclock)
> +static int da8xx_fb_config_clk_divider(struct da8xx_fb_par *par,
> + unsigned div, unsigned rate)
> {
> - unsigned div;
> + int ret;
>
> - div = da8xx_fb_calc_clk_divider(par, pixclock);
> - return KHZ2PICOS(par->lcd_fck_rate / (1000 * div));
> -}
> + if (par->lcd_fck_rate != rate) {
> + ret = clk_set_rate(par->lcdc_clk, rate);
> + if (IS_ERR_VALUE(ret)) {
> + dev_err(par->dev,
> + "unable to set clock rate at %u\n", rate);
> + return ret;
> + }
> + par->lcd_fck_rate = clk_get_rate(par->lcdc_clk);
> + }
>
> -static inline void da8xx_fb_config_clk_divider(unsigned div)
> -{
> /* Configure the LCD clock divisor. */
> lcdc_write(LCD_CLK_DIVISOR(div) |
> (LCD_RASTER_MODE & 0x1), LCD_CTRL_REG);
> @@ -707,14 +708,49 @@ static inline void da8xx_fb_config_clk_divider(unsigned div)
> if (lcd_revision = LCD_VERSION_2)
> lcdc_write(LCD_V2_DMA_CLK_EN | LCD_V2_LIDD_CLK_EN |
> LCD_V2_CORE_CLK_EN, LCD_CLK_ENABLE_REG);
> +
> + return 0;
> +}
> +
> +static unsigned int da8xx_fb_calc_clk_divider(struct da8xx_fb_par *par,
> + unsigned pixclock,
> + unsigned *rate)
> +{
> + unsigned div;
> +
> + pixclock = PICOS2KHZ(pixclock) * 1000;
> +
> + *rate = par->lcd_fck_rate;
> +
> + if (pixclock < (*rate / CLK_MAX_DIV)) {
> + *rate = clk_round_rate(par->lcdc_clk, pixclock * CLK_MAX_DIV);
> + div = CLK_MAX_DIV;
> + } else if (pixclock > (*rate / CLK_MIN_DIV)) {
> + *rate = clk_round_rate(par->lcdc_clk, pixclock * CLK_MIN_DIV);
> + div = CLK_MIN_DIV;
> + } else {
> + div = *rate / pixclock;
> + }
> +
> + return div;
> }
>
> -static inline void da8xx_fb_calc_config_clk_divider(struct da8xx_fb_par *par,
> +static inline int da8xx_fb_calc_config_clk_divider(struct da8xx_fb_par *par,
> struct fb_videomode *mode)
> {
> - unsigned div = da8xx_fb_calc_clk_divider(par, mode->pixclock);
> + unsigned rate;
> + unsigned div = da8xx_fb_calc_clk_divider(par, mode->pixclock, &rate);
>
> - da8xx_fb_config_clk_divider(div);
> + return da8xx_fb_config_clk_divider(par, div, rate);
> +}
> +
> +static inline unsigned da8xx_fb_round_clk(struct da8xx_fb_par *par,
> + unsigned pixclock)
> +{
> + unsigned div, rate;
> +
> + div = da8xx_fb_calc_clk_divider(par, pixclock, &rate);
> + return KHZ2PICOS(rate / (1000 * div));
> }
>
> static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,
> @@ -723,7 +759,11 @@ static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config *cfg,
> u32 bpp;
> int ret = 0;
>
> - da8xx_fb_calc_config_clk_divider(par, panel);
> + ret = da8xx_fb_calc_config_clk_divider(par, panel);
> + if (IS_ERR_VALUE(ret)) {
> + dev_err(par->dev, "unable to configure clock\n");
> + return ret;
> + }
>
> if (panel->sync & FB_SYNC_CLK_INVERT)
> lcdc_write((lcdc_read(LCD_RASTER_TIMING_2_REG) |
> --
> 1.7.9.5
^ permalink raw reply
* Re: [PATCH] ARM: AM33XX: clock: SET_RATE_PARENT in lcd path
From: Mike Turquette @ 2013-01-15 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358256897-26275-1-git-send-email-afzal@ti.com>
Quoting Afzal Mohammed (2013-01-15 05:34:57)
> LCDC clock node is a one that does not have set rate capability. It
> just passes on the rate that is sent downstream by it's parent. While
> lcdc clock parent and it's grand parent - dpll_disp_m2_ck and
> dpll_disp_ck has the capability to configure rate.
>
> And the default rates provided by LCDC clock's ancestors are not
> sufficient to obtain pixel clock for current LCDC use cases, hence
> currently display would not work on AM335x SoC's (with driver
> modifications in platfrom independent way).
>
> Hence inform clock framework to propogate set rate for LCDC clock as
> well as it's parent - dpll_disp_m2_ck. With this change, set rate on
> LCDC clock would get propogated till dpll_disp_ck via dpll_disp_m2_ck,
> hence allowing the driver (same driver is used in DaVinci too) to set
> rates using LCDC clock without worrying about platform dependent clock
> details.
>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> ---
>
> Based on v3.8-rc3
>
> arch/arm/mach-omap2/cclock33xx_data.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cclock33xx_data.c b/arch/arm/mach-omap2/cclock33xx_data.c
> index ea64ad6..b731216 100644
> --- a/arch/arm/mach-omap2/cclock33xx_data.c
> +++ b/arch/arm/mach-omap2/cclock33xx_data.c
> @@ -284,9 +284,10 @@ DEFINE_STRUCT_CLK(dpll_disp_ck, dpll_core_ck_parents, dpll_ddr_ck_ops);
> * TODO: Add clksel here (sys_clkin, CORE_CLKOUTM6, PER_CLKOUTM2
> * and ALT_CLK1/2)
> */
> -DEFINE_CLK_DIVIDER(dpll_disp_m2_ck, "dpll_disp_ck", &dpll_disp_ck, 0x0,
> - AM33XX_CM_DIV_M2_DPLL_DISP, AM33XX_DPLL_CLKOUT_DIV_SHIFT,
> - AM33XX_DPLL_CLKOUT_DIV_WIDTH, CLK_DIVIDER_ONE_BASED, NULL);
> +DEFINE_CLK_DIVIDER(dpll_disp_m2_ck, "dpll_disp_ck", &dpll_disp_ck,
> + CLK_SET_RATE_PARENT, AM33XX_CM_DIV_M2_DPLL_DISP,
> + AM33XX_DPLL_CLKOUT_DIV_SHIFT, AM33XX_DPLL_CLKOUT_DIV_WIDTH,
> + CLK_DIVIDER_ONE_BASED, NULL);
>
> /* DPLL_PER */
> static struct dpll_data dpll_per_dd = {
> @@ -932,6 +933,8 @@ int __init am33xx_clk_init(void)
> cpu_clkflg = CK_AM33XX;
> }
>
> + lcd_gclk.flags |= CLK_SET_RATE_PARENT;
> +
Afzal,
This is a bit hacky. Someone looking at the definition of struct
lcd_gclk above cannot easily tell that CLK_SET_RATE_PARENT is set below.
Also if other clocks need flags set at a later date then this will
become a big ugly block of flag setting.
I hope to move away from these macros some day, but in the mean time it
might be good to have a DEFINE_STRUCT_CLK_FLAGS macro which adds in an
argument struct clk->flags.
Paul, any thoughts on yet another macro?
Thanks,
Mike
> for (c = am33xx_clks; c < am33xx_clks + ARRAY_SIZE(am33xx_clks); c++) {
> if (c->cpu & cpu_clkflg) {
> clkdev_add(&c->lk);
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
From: Takashi Iwai @ 2013-01-15 16:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: sedat.dilek, Jiri Kosina, linux-fbdev, LKML, alan
In-Reply-To: <s5hip6yzeo9.wl%tiwai@suse.de>
At Tue, 15 Jan 2013 15:47:18 +0100,
Takashi Iwai wrote:
>
> At Tue, 15 Jan 2013 15:25:18 +0100,
> Takashi Iwai wrote:
> >
> > At Sat, 5 Jan 2013 13:13:27 +0100,
> > Sedat Dilek wrote:
> > >
> > > Hi Jiri,
> > >
> > > ...known issue (see thread in [1]), please feel free to test patches
> > > from Alan and Andrew (see [1], [2] and [3]) and report.
> > >
> > > Regards,
> > > - Sedat -
> > >
> > > [1] http://marc.info/?t\x135309396400003&r=1&w=2
> > > [2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
> > > [3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
> > > [4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch
> >
> > I've hit this bug and tried the patch [2] ([3] and [4] are gone).
> > Unfortunately the deadlock is still reported, as seen below.
> >
> > A similar fix for fbcon_unbind(), splitting an unlocked version of
> > unbind_con_driver() and call it?
> >
> > (BTW, the patch [2] contains strange characters in the comments, and
> > has a few coding issues easily detected by checkpatch.pl.)
>
> The fix patch for coding issue is below.
> Feel free to fold into the original patch.
... and the additional patch below fixed the lockdep warning on my
machine.
Takashi
=
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] fb: Yet another band-aid for fixing lockdep mess
I've still got lockdep warnings even after Alan's patch, and it seems
that yet more band aids are required to paper over similar paths for
unbind_con_driver() and unregister_con_driver(). After this hack,
lockdep warnings are finally gone.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
drivers/tty/vt/vt.c | 43 ++++++++++++++++++++++++++++---------------
drivers/video/console/fbcon.c | 4 ++--
drivers/video/fbmem.c | 4 ++++
include/linux/console.h | 1 +
include/linux/vt_kern.h | 2 ++
5 files changed, 37 insertions(+), 17 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 1db1c8d..3947e8d 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3135,6 +3135,18 @@ static int con_is_graphics(const struct consw *csw, int first, int last)
*/
int unbind_con_driver(const struct consw *csw, int first, int last, int deflt)
{
+ int retval;
+
+ console_lock();
+ retval = do_unbind_con_driver(csw, first, last, deflt);
+ console_unlock();
+ return retval;
+}
+EXPORT_SYMBOL(unbind_con_driver);
+
+/* unlocked version of unbind_con_driver() */
+int do_unbind_con_driver(const struct consw *csw, int first, int last, int deflt)
+{
struct module *owner = csw->owner;
const struct consw *defcsw = NULL;
struct con_driver *con_driver = NULL, *con_back = NULL;
@@ -3143,7 +3155,7 @@ int unbind_con_driver(const struct consw *csw, int first, int last, int deflt)
if (!try_module_get(owner))
return -ENODEV;
- console_lock();
+ WARN_CONSOLE_UNLOCKED();
/* check if driver is registered and if it is unbindable */
for (i = 0; i < MAX_NR_CON_DRIVER; i++) {
@@ -3156,10 +3168,8 @@ int unbind_con_driver(const struct consw *csw, int first, int last, int deflt)
}
}
- if (retval) {
- console_unlock();
+ if (retval)
goto err;
- }
retval = -ENODEV;
@@ -3175,15 +3185,11 @@ int unbind_con_driver(const struct consw *csw, int first, int last, int deflt)
}
}
- if (retval) {
- console_unlock();
+ if (retval)
goto err;
- }
- if (!con_is_bound(csw)) {
- console_unlock();
+ if (!con_is_bound(csw))
goto err;
- }
first = max(first, con_driver->first);
last = min(last, con_driver->last);
@@ -3212,13 +3218,12 @@ int unbind_con_driver(const struct consw *csw, int first, int last, int deflt)
/* ignore return value, binding should not fail */
do_bind_con_driver(defcsw, first, last, deflt);
- console_unlock();
err:
module_put(owner);
return retval;
}
-EXPORT_SYMBOL(unbind_con_driver);
+EXPORT_SYMBOL_GPL(do_unbind_con_driver);
static int vt_bind(struct con_driver *con)
{
@@ -3605,9 +3610,18 @@ EXPORT_SYMBOL(register_con_driver);
*/
int unregister_con_driver(const struct consw *csw)
{
- int i, retval = -ENODEV;
+ int retval;
console_lock();
+ retval = do_unregister_con_driver(csw);
+ console_unlock();
+ return retval;
+}
+EXPORT_SYMBOL(unregister_con_driver);
+
+int do_unregister_con_driver(const struct consw *csw)
+{
+ int i, retval = -ENODEV;
/* cannot unregister a bound driver */
if (con_is_bound(csw))
@@ -3633,10 +3647,9 @@ int unregister_con_driver(const struct consw *csw)
}
}
err:
- console_unlock();
return retval;
}
-EXPORT_SYMBOL(unregister_con_driver);
+EXPORT_SYMBOL_GPL(do_unregister_con_driver);
/*
* If we support more console drivers, this function is used
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 4bd7820..2aef9ca 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -3004,7 +3004,7 @@ static int fbcon_unbind(void)
{
int ret;
- ret = unbind_con_driver(&fb_con, first_fb_vc, last_fb_vc,
+ ret = do_unbind_con_driver(&fb_con, first_fb_vc, last_fb_vc,
fbcon_is_default);
if (!ret)
@@ -3077,7 +3077,7 @@ static int fbcon_fb_unregistered(struct fb_info *info)
primary_device = -1;
if (!num_registered_fb)
- unregister_con_driver(&fb_con);
+ do_unregister_con_driver(&fb_con);
return 0;
}
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index d8d9831..070b9a1 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1668,8 +1668,10 @@ static int do_unregister_framebuffer(struct fb_info *fb_info)
if (!lock_fb_info(fb_info))
return -ENODEV;
+ console_lock();
event.info = fb_info;
ret = fb_notifier_call_chain(FB_EVENT_FB_UNBIND, &event);
+ console_unlock();
unlock_fb_info(fb_info);
if (ret)
@@ -1684,7 +1686,9 @@ static int do_unregister_framebuffer(struct fb_info *fb_info)
num_registered_fb--;
fb_cleanup_device(fb_info);
event.info = fb_info;
+ console_lock();
fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, &event);
+ console_unlock();
/* this may free fb info */
put_fb_info(fb_info);
diff --git a/include/linux/console.h b/include/linux/console.h
index 4ef4307..47b858c 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -77,6 +77,7 @@ extern const struct consw prom_con; /* SPARC PROM console */
int con_is_bound(const struct consw *csw);
int register_con_driver(const struct consw *csw, int first, int last);
int unregister_con_driver(const struct consw *csw);
+int do_unregister_con_driver(const struct consw *csw);
int take_over_console(const struct consw *sw, int first, int last, int deflt);
int do_take_over_console(const struct consw *sw, int first, int last, int deflt);
void give_up_console(const struct consw *sw);
diff --git a/include/linux/vt_kern.h b/include/linux/vt_kern.h
index 50ae7d0..dbbc6bf 100644
--- a/include/linux/vt_kern.h
+++ b/include/linux/vt_kern.h
@@ -130,6 +130,8 @@ void vt_event_post(unsigned int event, unsigned int old, unsigned int new);
int vt_waitactive(int n);
void change_console(struct vc_data *new_vc);
void reset_vc(struct vc_data *vc);
+extern int do_unbind_con_driver(const struct consw *csw, int first, int last,
+ int deflt);
extern int unbind_con_driver(const struct consw *csw, int first, int last,
int deflt);
int vty_init(const struct file_operations *console_fops);
--
1.8.1
^ permalink raw reply related
* Re: fb: Rework locking to fix lock ordering on takeover
From: Alan Cox @ 2013-01-15 18:41 UTC (permalink / raw)
To: sedat.dilek
Cc: Andrew Morton, Linus Torvalds, linux-fbdev, LKML,
Rafael J. Wysocki
In-Reply-To: <CA+icZUVJ5hbPJvV4LMFGgD3Sto5=EV=MO9nutYdJwkiRrmpNJQ@mail.gmail.com>
> A disappeared/busy/not-answering maintainer is not an excuse for
> handling serious regressions (even here in this case there are fixes
> around),
It's *not* a regression - that's the horrible bit. If it was a regression
we'd just back the changes out, wait for (or switch) maintainer and be
happy a release later.
Its a piece of terrible design that is years old and a bug that is at
least two years old which caused random hangs on Fedora boxes during boot
up and so on for several releases. What has happened is Daniel's changes
made the bug *visible* as it's now lockdep splatted and can thus be
analyzed and worked upon.
We are pretty good at regression squashing because you can just rewind a
bit, and try again later. In this case rewinding the lockdep splat
simply turns it back into random silent hangs.
> Personally, I am still missing a mei-driver fix [2] and a libata-dev fix [3].
> Both issues are not new to the maintainers.
> Not sure if shouting louder is the best strategy here.
Really its a kernel summit question. IMHO we ought to have a policy
that anything of any relevance has *two* maintainers or more. That way
there is always someone to help pick a new maintainer if one drops out
and we are mostly not at the mercy of real world happenings. We also need
to be much more active in giving maintainers the boot if they vanish (and
having two maintainers will balance the effect nicely).
In practice I think most maintainers can offhand name the person they'd
pick to replace them, so they can pretty easily switch to two maintainers.
> It would be great to have a place like a "board of arbitration" where
> someone can send blames.
There is a ton of stuff in bugzilla including fixes for some years old
stuff (eg bluetooth on some dongle types that broke in 2.6.3x). It's not
a case of inventing bodies to handle stuff, it's a case of two things
- people getting off their backsides to fix it
- enabling those people to get the job done
Finger pointing statistics and shame lists such as Rafael did are just
tools to help. At the end of the day its about people doing stuff.
Alan
^ permalink raw reply
* [PATCH] drivers/video: fsl-diu-fb: add hardware cursor support
From: Timur Tabi @ 2013-01-15 20:17 UTC (permalink / raw)
To: linux-fbdev
From: Timur Tabi <timur@freescale.com>
The Freescale DIU supports a 32x32 color hardware cursor. Framebuffer
cursors are monochrome, so the driver converts the image data to the
format that the DIU expects and then programs to hardware accordingly.
The support cursor enabling/disabling, we provide two cursor image buffers.
One is always blank (all zeroes), and the other contains the real cursor
image data. To disable the cursor (used typically for cursor blinking),
we just tell the hardware to use the blank cursor data.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
drivers/video/fsl-diu-fb.c | 157 +++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 155 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index 19cfd7a..acdde17 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -375,7 +375,10 @@ struct fsl_diu_data {
struct diu_ad dummy_ad __aligned(8);
struct diu_ad ad[NUM_AOIS] __aligned(8);
u8 gamma[256 * 3] __aligned(32);
- u8 cursor[MAX_CURS * MAX_CURS * 2] __aligned(32);
+ /* It's easier to parse the cursor data as little-endian */
+ __le16 cursor[MAX_CURS * MAX_CURS] __aligned(32);
+ /* Blank cursor data -- used to hide the cursor */
+ __le16 blank_cursor[MAX_CURS * MAX_CURS] __aligned(32);
uint8_t edid_data[EDID_LENGTH];
bool has_edid;
} __aligned(32);
@@ -824,7 +827,6 @@ static void update_lcdc(struct fb_info *info)
/* Program DIU registers */
out_be32(&hw->gamma, DMA_ADDR(data, gamma));
- out_be32(&hw->cursor, DMA_ADDR(data, cursor));
out_be32(&hw->bgnd, 0x007F7F7F); /* Set background to grey */
out_be32(&hw->disp_size, (var->yres << 16) | var->xres);
@@ -968,6 +970,156 @@ static u32 fsl_diu_get_pixel_format(unsigned int bits_per_pixel)
}
/*
+ * Copies a cursor image from user space to the proper place in driver
+ * memory so that the hardware can display the cursor image.
+ *
+ * Cursor data is represented as a sequence of 'width' bits packed into bytes.
+ * That is, the first 8 bits are in the first byte, the second 8 bits in the
+ * second byte, and so on. Therefore, the each row of the cursor is (width +
+ * 7) / 8 bytes of 'data'
+ *
+ * The DIU only supports cursors up to 32x32 (MAX_CURS). We reject cursors
+ * larger than this, so we already know that 'width' <= 32. Therefore, we can
+ * simplify our code by using a 32-bit big-endian integer ("line") to read in
+ * a single line of pixels, and only look at the top 'width' bits of that
+ * integer.
+ *
+ * This could result in an unaligned 32-bit read. For example, if the cursor
+ * is 24x24, then the first three bytes of 'image' contain the pixel data for
+ * the top line of the cursor. We do a 32-bit read of 'image', but we look
+ * only at the top 24 bits. Then we increment 'image' by 3 bytes. The next
+ * read is unaligned. The only problem is that we might read past the end of
+ * 'image' by 1-3 bytes, but that should not cause any problems.
+ */
+static void fsl_diu_load_cursor_image(struct fb_info *info,
+ const void *image, uint16_t bg, uint16_t fg,
+ unsigned int width, unsigned int height)
+{
+ struct mfb_info *mfbi = info->par;
+ struct fsl_diu_data *data = mfbi->parent;
+ __le16 *cursor = data->cursor;
+ __le16 _fg = cpu_to_le16(fg);
+ __le16 _bg = cpu_to_le16(bg);
+ unsigned int h, w;
+
+ for (h = 0; h < height; h++) {
+ uint32_t mask = 1 << 31;
+ uint32_t line = be32_to_cpup(image);
+
+ for (w = 0; w < width; w++) {
+ cursor[w] = (line & mask) ? _fg : _bg;
+ mask >>= 1;
+ }
+
+ cursor += MAX_CURS;
+ image += DIV_ROUND_UP(width, 8);
+ }
+}
+
+/*
+ * Set a hardware cursor. The image data for the cursor is passed via the
+ * fb_cursor object.
+ */
+static int fsl_diu_cursor(struct fb_info *info, struct fb_cursor *cursor)
+{
+ struct mfb_info *mfbi = info->par;
+ struct fsl_diu_data *data = mfbi->parent;
+ struct diu __iomem *hw = data->diu_reg;
+
+ if (cursor->image.width > MAX_CURS || cursor->image.height > MAX_CURS)
+ return -EINVAL;
+
+ /* The cursor size has changed */
+ if (cursor->set & FB_CUR_SETSIZE) {
+ /*
+ * The DIU cursor is a fixed size, so when we get this
+ * message, instead of resizing the cursor, we just clear
+ * all the image data, in expectation of new data. However,
+ * in tests this control does not appear to be normally
+ * called.
+ */
+ memset(data->cursor, 0, sizeof(data->cursor));
+ }
+
+ /* The cursor position has changed (cursor->image.dx|dy) */
+ if (cursor->set & FB_CUR_SETPOS) {
+ uint32_t xx, yy;
+
+ yy = (cursor->image.dy - info->var.yoffset) & 0x7ff;
+ xx = (cursor->image.dx - info->var.xoffset) & 0x7ff;
+
+ out_be32(&hw->curs_pos, yy << 16 | xx);
+ }
+
+ /*
+ * FB_CUR_SETIMAGE - the cursor image has changed
+ * FB_CUR_SETCMAP - the cursor colors has changed
+ * FB_CUR_SETSHAPE - the cursor bitmask has changed
+ */
+ if (cursor->set & (FB_CUR_SETSHAPE | FB_CUR_SETCMAP | FB_CUR_SETIMAGE)) {
+ unsigned int image_size + DIV_ROUND_UP(cursor->image.width, 8) * cursor->image.height;
+ unsigned int image_words + DIV_ROUND_UP(image_size, sizeof(uint32_t));
+ unsigned int bg_idx = cursor->image.bg_color;
+ unsigned int fg_idx = cursor->image.fg_color;
+ uint8_t buffer[image_size];
+ uint32_t *image, *source, *mask;
+ uint16_t fg, bg;
+ unsigned int i;
+
+ if (info->state != FBINFO_STATE_RUNNING)
+ return 0;
+
+ /*
+ * Determine the size of the cursor image data. Normally,
+ * it's 8x16.
+ */
+ image_size = DIV_ROUND_UP(cursor->image.width, 8) *
+ cursor->image.height;
+
+ bg = ((info->cmap.red[bg_idx] & 0xf8) << 7) |
+ ((info->cmap.green[bg_idx] & 0xf8) << 2) |
+ ((info->cmap.blue[bg_idx] & 0xf8) >> 3) |
+ 1 << 15;
+
+ fg = ((info->cmap.red[fg_idx] & 0xf8) << 7) |
+ ((info->cmap.green[fg_idx] & 0xf8) << 2) |
+ ((info->cmap.blue[fg_idx] & 0xf8) >> 3) |
+ 1 << 15;
+
+ /* Use 32-bit operations on the data to improve performance */
+ image = (uint32_t *)buffer;
+ source = (uint32_t *)cursor->image.data;
+ mask = (uint32_t *)cursor->mask;
+
+ if (cursor->rop = ROP_XOR)
+ for (i = 0; i < image_words; i++)
+ image[i] = source[i] ^ mask[i];
+ else
+ for (i = 0; i < image_words; i++)
+ image[i] = source[i] & mask[i];
+
+ fsl_diu_load_cursor_image(info, image, bg, fg,
+ cursor->image.width, cursor->image.height);
+ };
+
+ /*
+ * Show or hide the cursor. The cursor data is always stored in the
+ * 'cursor' memory block, and the actual cursor position is always in
+ * the DIU's CURS_POS register. To hide the cursor, we redirect the
+ * CURSOR register to a blank cursor. The show the cursor, we
+ * redirect the CURSOR register to the real cursor data.
+ */
+ if (cursor->enable)
+ out_be32(&hw->cursor, DMA_ADDR(data, cursor));
+ else
+ out_be32(&hw->cursor, DMA_ADDR(data, blank_cursor));
+
+ return 0;
+}
+
+/*
* Using the fb_var_screeninfo in fb_info we set the resolution of this
* particular framebuffer. This function alters the fb_fix_screeninfo stored
* in fb_info. It does not alter var in fb_info since we are using that
@@ -1305,6 +1457,7 @@ static struct fb_ops fsl_diu_ops = {
.fb_ioctl = fsl_diu_ioctl,
.fb_open = fsl_diu_open,
.fb_release = fsl_diu_release,
+ .fb_cursor = fsl_diu_cursor,
};
static int install_fb(struct fb_info *info)
--
1.7.3.4
^ permalink raw reply related
* Re: fb: Rework locking to fix lock ordering on takeover
From: Rafael J. Wysocki @ 2013-01-15 22:15 UTC (permalink / raw)
To: sedat.dilek
Cc: Andrew Morton, Linus Torvalds, linux-fbdev, LKML,
Greg Kroah-Hartman
In-Reply-To: <CA+icZUVJ5hbPJvV4LMFGgD3Sto5=EV=MO9nutYdJwkiRrmpNJQ@mail.gmail.com>
On Sunday, January 13, 2013 04:14:38 PM Sedat Dilek wrote:
> Hi Andrew,
>
> your patch from [1] - as far as I followed - misses a lot of
> Reported-by#s and Tested-by#s (Boris, Jiri, etc.).
> Just one new R-b I have seen yesterday.
>
> I have the original patch from Alan plus the two follow-ups from you
> in my patch-series against v3.8-{rc2,rc3} for quite a while.
> So, please feel free to add a Tested-by.
>
> Unfortunately, your patch has introduced some (unwanted) extra chars
> like "_*" (comments only).
> I appreciate one single (new) patch like this, but please in a proper way.
Why don't you prepare such a patch? I suppose you know everything you need?
> A disappeared/busy/not-answering maintainer is not an excuse for
> handling serious regressions (even here in this case there are fixes
> around),
> Personally, I am still missing a mei-driver fix [2] and a libata-dev fix [3].
> Both issues are not new to the maintainers.
> Not sure if shouting louder is the best strategy here.
[2] seems to be in the Greg's tree, so I suppose it's on its way to Linus and
please note that we're after a several days vacation period and people need to
process their backlogs.
Perhaps just ping the relevant maintainers when 3.8-rc4 is out (and do the same
after -rc5 and so on).
> It would be great to have a place like a "board of arbitration" where
> someone can send blames.
> And I remember vaguely Rafael had a nice list of issues (w/ reference
> to patches!).
> This was a real cool helpful innoivation!
> I can't remember why Rafael stopped his nice service to the
> Linux-kernel community.
Because I don't have the time to do that any more. Yes, it was useful, but it
also was quite a bit of work. Would you volunteer to do that?
Rafael
> [1] https://patchwork.kernel.org/patch/1969391/
> [2] http://git.kernel.org/?p=linux/kernel/git/gregkh/char-misc.git;a=commitdiff;hæ028db0146cf5a68dbd1508225ea49840997880
> [3] http://patchwork.ozlabs.org/patch/206897/
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH v2 12/12] video: da8xx-fb: set upstream clock rate (if reqd)
From: Sekhar Nori @ 2013-01-16 5:14 UTC (permalink / raw)
To: Mike Turquette
Cc: Afzal Mohammed, Florian Tobias Schandinat, Tomi Valkeinen,
Grant Likely, Rob Herring, Rob Landley, linux-omap, linux-fbdev,
devicetree-discuss, linux-doc, linux-kernel
In-Reply-To: <20130115153222.23734.7924@quantum>
On 1/15/2013 9:02 PM, Mike Turquette wrote:
> Quoting Afzal Mohammed (2013-01-15 05:44:36)
>> LCDC IP has a clock divider to adjust pixel clock, this limits pixel
>> clock range to fck/255 - fck/2(fck - rate of input clock to LCDC IP).
>> In the case of AM335x, where this IP is present, default fck is not
>> sufficient to provide normal pixel clock rates, hence rendering this
>> driver unusable on AM335x.
>>
>> If input clock too is configurable, allowable range of pixel clock
>> would increase. Here initially it is checked whether with present fck,
>> divider in IP could be configured to obtain required rate, if not,
>> fck is adjusted. This makes it usable on AM335x.
>>
>> Note:
>> A better (if allowable) solution may be to represent clock divider in
>> LCDC IP as a basic divider clock - the one defined in common clock
>> framework. But for this to happen, all the platform's using this driver
>> should be using common clock framework (DaVinci is yet to be converted
>> to use common clock framework). And it has to be determined whether
>> common clock framework allows this kind of a clock modelling inside a
>> driver and for this to be part of clock tree. Advantage of doing so
>> would be better resolution for pixel clock, even though without this
>> existing use cases are working properly. Or another extreme alternative
>> would be to replicate clk-divider of common clock framework inside the
>> driver, but that probably is not preferred and not worth as it would be
>> duplication and without much advantage to existing users.
>>
>
> Afzal,
>
> Modeling the divider inside your IP block as a clock is supported in the
> common clock framework. Linking up these sorts of clocks to the clock
> tree was one of the original design goals of CCF.
>
> Regarding DaVinci: converting that platform over to use CCF would be the
> best approach.
This is work in progress. There are patches that have been posted. Work
has been slow on this though due to lack of bandwidth.
> An alternative would be that you could break
> single-image boot for AM335x and DaVinci, by having AM335x use CCF and
> DaVinci use the legacy clock framework. From the LCDC driver's
Single image for DaVinci and AM335x is not possible anyway since ARMv5
and ARMv6+ cannot be supported in a single image.
> perspective this should not matter and is indeed the purpose of the
> clk.h api and clkdev interfaces, however looking at this driver I can
> see there would still be a lot ifdef-ery going on... better to just
> convert everything over to CCF.
Waiting for DaVinci CCF to complete will be too long a wait. Probably
convert to CCF just for AM335x ATM. There would be some ifdef'ry but
hopefully that need not be inside function bodies. Would have to see the
implementation, I guess.
Thanks,
Sekhar
^ permalink raw reply
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
From: Sedat Dilek @ 2013-01-16 9:21 UTC (permalink / raw)
To: Takashi Iwai
Cc: Jiri Kosina, linux-fbdev, LKML, alan, Andrew Morton,
Rafael J. Wysocki
In-Reply-To: <s5hpq16zfox.wl%tiwai@suse.de>
On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai <tiwai@suse.de> wrote:
> At Sat, 5 Jan 2013 13:13:27 +0100,
> Sedat Dilek wrote:
>>
>> Hi Jiri,
>>
>> ...known issue (see thread in [1]), please feel free to test patches
>> from Alan and Andrew (see [1], [2] and [3]) and report.
>>
>> Regards,
>> - Sedat -
>>
>> [1] http://marc.info/?t\x135309396400003&r=1&w=2
>> [2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
>> [3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
>> [4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch
>
> I've hit this bug and tried the patch [2] ([3] and [4] are gone).
> Unfortunately the deadlock is still reported, as seen below.
>
> A similar fix for fbcon_unbind(), splitting an unlocked version of
> unbind_con_driver() and call it?
>
> (BTW, the patch [2] contains strange characters in the comments, and
> has a few coding issues easily detected by checkpatch.pl.)
>
[ CCing Rafael as he asked in another thread if I had sent a patch ]
I noticed also some these "strange" chars in the patch from Andrew and
a patch of mine was sent as
"fb-Rework-locking-to-fix-lock-ordering-on-takeover-fix-comments.patch"
to the lists.
It is strange to me that Andrew or other maintainers himself did not
check with "checkpatch.pl".
This should be a common testcase!
Hey, noone is perfect :-).
( /me has also not checked with that script - I just saw it. )
Just as a note to the issue in general:
Andrew took over the patch from Alan which is very honest - he is not
the active TTY maintainer!
Didn't Greg takeover maintenance from Alan (after a dispute and blaming Alan)?
If this is true, why the hell is Greg not CCed?
Thanks for the real patch in the followup of this thread!
Who will take care of it :-)?
- Sedat
>
> thanks,
>
> Takashi
>
> =>
> [ 3.228454] [drm] Initialized drm 1.1.0 20060810
> [ 3.317144] [drm] radeon defaulting to kernel modesetting.
> [ 3.330546] [drm] radeon kernel modesetting enabled.
> [ 3.343942] checking generic (c0000000 1000000) vs hw (c0000000 10000000)
> [ 3.343946] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
> [ 3.357376]
> [ 3.357377] ===========================
> [ 3.357378] [ INFO: possible circular locking dependency detected ]
> [ 3.357380] 3.8.0-rc3-test+ #82 Not tainted
> [ 3.357381] -------------------------------------------------------
> [ 3.357383] udevd/137 is trying to acquire lock:
> [ 3.357394] (console_lock){+.+.+.}, at: [<ffffffff8140385f>] unbind_con_driver+0x3f/0x200
> [ 3.357395]
> [ 3.357395] but task is already holding lock:
> [ 3.357402] ((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff810799b1>] __blocking_notifier_call_chain+0x51/0xc0
> [ 3.357403]
> [ 3.357403] which lock already depends on the new lock.
> [ 3.357403]
> [ 3.357404]
> [ 3.357404] the existing dependency chain (in reverse order) is:
> [ 3.357407]
> [ 3.357407] -> #1 ((fb_notifier_list).rwsem){.+.+.+}:
> [ 3.357411] [<ffffffff810b605a>] lock_acquire+0xaa/0x210
> [ 3.357417] [<ffffffff81643dc2>] down_read+0x42/0x57
> [ 3.357419] [<ffffffff810799b1>] __blocking_notifier_call_chain+0x51/0xc0
> [ 3.357422] [<ffffffff81079a31>] blocking_notifier_call_chain+0x11/0x20
> [ 3.357426] [<ffffffff8138cbe6>] fb_notifier_call_chain+0x16/0x20
> [ 3.357428] [<ffffffff8138e302>] register_framebuffer+0x1c2/0x2f0
> [ 3.357433] [<ffffffff81d1748e>] vesafb_probe+0x6e0/0x760
> [ 3.357437] [<ffffffff8142afbe>] platform_drv_probe+0x3e/0x70
> [ 3.357440] [<ffffffff81428d26>] driver_probe_device+0x86/0x390
> [ 3.357442] [<ffffffff814290d3>] __driver_attach+0xa3/0xb0
> [ 3.357445] [<ffffffff81426dbd>] bus_for_each_dev+0x4d/0x90
> [ 3.357447] [<ffffffff814286a9>] driver_attach+0x19/0x20
> [ 3.357450] [<ffffffff81428308>] bus_add_driver+0x1a8/0x290
> [ 3.357452] [<ffffffff81429792>] driver_register+0x72/0x170
> [ 3.357455] [<ffffffff8142a7e1>] platform_driver_register+0x41/0x50
> [ 3.357458] [<ffffffff8142a806>] platform_driver_probe+0x16/0xa0
> [ 3.357460] [<ffffffff81d16d6b>] vesafb_init+0x215/0x258
> [ 3.357464] [<ffffffff810002e2>] do_one_initcall+0x122/0x180
> [ 3.357468] [<ffffffff816258ec>] kernel_init+0x1fc/0x370
> [ 3.357471] [<ffffffff8164e1fc>] ret_from_fork+0x7c/0xb0
> [ 3.357474]
> [ 3.357474] -> #0 (console_lock){+.+.+.}:
> [ 3.357476] [<ffffffff810b5055>] __lock_acquire+0x1385/0x1cc0
> [ 3.357478] [<ffffffff810b605a>] lock_acquire+0xaa/0x210
> [ 3.357482] [<ffffffff81048fbf>] console_lock+0x6f/0x80
> [ 3.357485] [<ffffffff8140385f>] unbind_con_driver+0x3f/0x200
> [ 3.357489] [<ffffffff8139aeb7>] fbcon_event_notify+0x447/0x8b0
> [ 3.357492] [<ffffffff8164a225>] notifier_call_chain+0x55/0x110
> [ 3.357495] [<ffffffff810799c7>] __blocking_notifier_call_chain+0x67/0xc0
> [ 3.357497] [<ffffffff81079a31>] blocking_notifier_call_chain+0x11/0x20
> [ 3.357500] [<ffffffff8138cbe6>] fb_notifier_call_chain+0x16/0x20
> [ 3.357502] [<ffffffff8138debb>] do_unregister_framebuffer+0x5b/0x110
> [ 3.357505] [<ffffffff8138e108>] do_remove_conflicting_framebuffers+0x158/0x190
> [ 3.357507] [<ffffffff8138e46a>] remove_conflicting_framebuffers+0x3a/0x60
> [ 3.357532] [<ffffffffa00df16b>] radeon_pci_probe+0x8b/0xd0 [radeon]
> [ 3.357536] [<ffffffff8136d5a6>] local_pci_probe+0x46/0x80
> [ 3.357539] [<ffffffff8136d7f1>] pci_device_probe+0x101/0x110
> [ 3.357542] [<ffffffff81428d26>] driver_probe_device+0x86/0x390
> [ 3.357544] [<ffffffff814290d3>] __driver_attach+0xa3/0xb0
> [ 3.357547] [<ffffffff81426dbd>] bus_for_each_dev+0x4d/0x90
> [ 3.357549] [<ffffffff814286a9>] driver_attach+0x19/0x20
> [ 3.357552] [<ffffffff81428308>] bus_add_driver+0x1a8/0x290
> [ 3.357554] [<ffffffff81429792>] driver_register+0x72/0x170
> [ 3.357557] [<ffffffff8136c60f>] __pci_register_driver+0x5f/0x70
> [ 3.357577] [<ffffffffa006ec3a>] drm_pci_init+0x11a/0x130 [drm]
> [ 3.357594] [<ffffffffa01c20ec>] radeon_init+0xec/0x1000 [radeon]
> [ 3.357597] [<ffffffff810002e2>] do_one_initcall+0x122/0x180
> [ 3.357600] [<ffffffff810c4b53>] load_module+0x1043/0x1510
> [ 3.357603] [<ffffffff810c50f7>] sys_init_module+0xd7/0x120
> [ 3.357605] [<ffffffff8164e2ad>] system_call_fastpath+0x1a/0x1f
> [ 3.357606]
> [ 3.357606] other info that might help us debug this:
> [ 3.357606]
> [ 3.357607] Possible unsafe locking scenario:
> [ 3.357607]
> [ 3.357608] CPU0 CPU1
> [ 3.357609] ---- ----
> [ 3.357611] lock((fb_notifier_list).rwsem);
> [ 3.357613] lock(console_lock);
> [ 3.357615] lock((fb_notifier_list).rwsem);
> [ 3.357616] lock(console_lock);
> [ 3.357617]
> [ 3.357617] *** DEADLOCK ***
> [ 3.357617]
> [ 3.357619] 5 locks held by udevd/137:
> [ 3.357624] #0: (&__lockdep_no_validate__){......}, at: [<ffffffff81429083>] __driver_attach+0x53/0xb0
> [ 3.357628] #1: (&__lockdep_no_validate__){......}, at: [<ffffffff81429091>] __driver_attach+0x61/0xb0
> [ 3.357633] #2: (registration_lock){+.+.+.}, at: [<ffffffff8138e45b>] remove_conflicting_framebuffers+0x2b/0x60
> [ 3.357637] #3: (&fb_info->lock){+.+.+.}, at: [<ffffffff8138d0c1>] lock_fb_info+0x21/0x60
> [ 3.357642] #4: ((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff810799b1>] __blocking_notifier_call_chain+0x51/0xc0
> [ 3.357643]
> [ 3.357643] stack backtrace:
> [ 3.357645] Pid: 137, comm: udevd Not tainted 3.8.0-rc3-test+ #82
> [ 3.357646] Call Trace:
> [ 3.357652] [<ffffffff8163b136>] print_circular_bug+0x1fb/0x20c
> [ 3.357655] [<ffffffff810b5055>] __lock_acquire+0x1385/0x1cc0
> [ 3.357658] [<ffffffff810b605a>] lock_acquire+0xaa/0x210
> [ 3.357661] [<ffffffff8140385f>] ? unbind_con_driver+0x3f/0x200
> [ 3.357664] [<ffffffff810b2b0d>] ? trace_hardirqs_on+0xd/0x10
> [ 3.357667] [<ffffffff81048fbf>] console_lock+0x6f/0x80
> [ 3.357670] [<ffffffff8140385f>] ? unbind_con_driver+0x3f/0x200
> [ 3.357673] [<ffffffff8140385f>] unbind_con_driver+0x3f/0x200
> [ 3.357676] [<ffffffff8134c01e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [ 3.357680] [<ffffffff8139aeb7>] fbcon_event_notify+0x447/0x8b0
> [ 3.357683] [<ffffffff8164a225>] notifier_call_chain+0x55/0x110
> [ 3.357685] [<ffffffff810799c7>] __blocking_notifier_call_chain+0x67/0xc0
> [ 3.357688] [<ffffffff81079a31>] blocking_notifier_call_chain+0x11/0x20
> [ 3.357690] [<ffffffff8138cbe6>] fb_notifier_call_chain+0x16/0x20
> [ 3.357693] [<ffffffff8138debb>] do_unregister_framebuffer+0x5b/0x110
> [ 3.357696] [<ffffffff8138e108>] do_remove_conflicting_framebuffers+0x158/0x190
> [ 3.357698] [<ffffffff8138e46a>] remove_conflicting_framebuffers+0x3a/0x60
> [ 3.357717] [<ffffffffa00df16b>] radeon_pci_probe+0x8b/0xd0 [radeon]
> [ 3.357721] [<ffffffff8136d5a6>] local_pci_probe+0x46/0x80
> [ 3.357724] [<ffffffff8136d7f1>] pci_device_probe+0x101/0x110
> [ 3.357727] [<ffffffff81428d26>] driver_probe_device+0x86/0x390
> [ 3.357729] [<ffffffff814290d3>] __driver_attach+0xa3/0xb0
> [ 3.357732] [<ffffffff81429030>] ? driver_probe_device+0x390/0x390
> [ 3.357734] [<ffffffff81426dbd>] bus_for_each_dev+0x4d/0x90
> [ 3.357737] [<ffffffff814286a9>] driver_attach+0x19/0x20
> [ 3.357740] [<ffffffff81428308>] bus_add_driver+0x1a8/0x290
> [ 3.357744] [<ffffffffa01c2000>] ? 0xffffffffa01c1fff
> [ 3.357747] [<ffffffff81429792>] driver_register+0x72/0x170
> [ 3.357749] [<ffffffffa01c2000>] ? 0xffffffffa01c1fff
> [ 3.357752] [<ffffffff8136c60f>] __pci_register_driver+0x5f/0x70
> [ 3.357762] [<ffffffffa006ec3a>] drm_pci_init+0x11a/0x130 [drm]
> [ 3.357764] [<ffffffffa01c2000>] ? 0xffffffffa01c1fff
> [ 3.357767] [<ffffffffa01c2000>] ? 0xffffffffa01c1fff
> [ 3.357784] [<ffffffffa01c20ec>] radeon_init+0xec/0x1000 [radeon]
> [ 3.357786] [<ffffffff810002e2>] do_one_initcall+0x122/0x180
> [ 3.357789] [<ffffffff810c4b53>] load_module+0x1043/0x1510
> [ 3.357792] [<ffffffff8135d260>] ? ddebug_proc_open+0xb0/0xb0
> [ 3.357796] [<ffffffff810c50f7>] sys_init_module+0xd7/0x120
> [ 3.357798] [<ffffffff8164e2ad>] system_call_fastpath+0x1a/0x1f
^ permalink raw reply
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
From: Takashi Iwai @ 2013-01-16 9:35 UTC (permalink / raw)
To: sedat.dilek
Cc: Jiri Kosina, linux-fbdev, LKML, alan, Andrew Morton,
Rafael J. Wysocki, Greg Kroah-Hartman, Jiri Slaby
In-Reply-To: <CA+icZUWFKzccbHrU0pxK-T2TdwyDsTTNxP_22zmGTPbcAmhMaQ@mail.gmail.com>
At Wed, 16 Jan 2013 10:21:46 +0100,
Sedat Dilek wrote:
>
> On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai <tiwai@suse.de> wrote:
> > At Sat, 5 Jan 2013 13:13:27 +0100,
> > Sedat Dilek wrote:
> >>
> >> Hi Jiri,
> >>
> >> ...known issue (see thread in [1]), please feel free to test patches
> >> from Alan and Andrew (see [1], [2] and [3]) and report.
> >>
> >> Regards,
> >> - Sedat -
> >>
> >> [1] http://marc.info/?t\x135309396400003&r=1&w=2
> >> [2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
> >> [3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
> >> [4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch
> >
> > I've hit this bug and tried the patch [2] ([3] and [4] are gone).
> > Unfortunately the deadlock is still reported, as seen below.
> >
> > A similar fix for fbcon_unbind(), splitting an unlocked version of
> > unbind_con_driver() and call it?
> >
> > (BTW, the patch [2] contains strange characters in the comments, and
> > has a few coding issues easily detected by checkpatch.pl.)
> >
>
> [ CCing Rafael as he asked in another thread if I had sent a patch ]
>
> I noticed also some these "strange" chars in the patch from Andrew and
> a patch of mine was sent as
> "fb-Rework-locking-to-fix-lock-ordering-on-takeover-fix-comments.patch"
> to the lists.
>
> It is strange to me that Andrew or other maintainers himself did not
> check with "checkpatch.pl".
> This should be a common testcase!
> Hey, noone is perfect :-).
> ( /me has also not checked with that script - I just saw it. )
>
> Just as a note to the issue in general:
> Andrew took over the patch from Alan which is very honest - he is not
> the active TTY maintainer!
> Didn't Greg takeover maintenance from Alan (after a dispute and blaming Alan)?
> If this is true, why the hell is Greg not CCed?
Let's do it :)
Greg, Jiri, this bug hits already quite a few people.
I can reproduce the bug easily on a machine with a radeon graphics.
It appears always at boot when lockdep is enabled.
> Thanks for the real patch in the followup of this thread!
> Who will take care of it :-)?
Either tty maintainer, or fb maintainer, or Andrew?
FWIW, Andrew took my patch in mm:
http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch
thanks,
Takashi
^ permalink raw reply
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
From: Sedat Dilek @ 2013-01-16 9:52 UTC (permalink / raw)
To: Takashi Iwai
Cc: Jiri Kosina, linux-fbdev, LKML, alan, Andrew Morton,
Rafael J. Wysocki, Greg Kroah-Hartman, Jiri Slaby, linux-next
In-Reply-To: <s5hpq1531yn.wl%tiwai@suse.de>
On Wed, Jan 16, 2013 at 10:35 AM, Takashi Iwai <tiwai@suse.de> wrote:
> At Wed, 16 Jan 2013 10:21:46 +0100,
> Sedat Dilek wrote:
>>
>> On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai <tiwai@suse.de> wrote:
>> > At Sat, 5 Jan 2013 13:13:27 +0100,
>> > Sedat Dilek wrote:
>> >>
>> >> Hi Jiri,
>> >>
>> >> ...known issue (see thread in [1]), please feel free to test patches
>> >> from Alan and Andrew (see [1], [2] and [3]) and report.
>> >>
>> >> Regards,
>> >> - Sedat -
>> >>
>> >> [1] http://marc.info/?t\x135309396400003&r=1&w=2
>> >> [2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
>> >> [3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
>> >> [4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch
>> >
>> > I've hit this bug and tried the patch [2] ([3] and [4] are gone).
>> > Unfortunately the deadlock is still reported, as seen below.
>> >
>> > A similar fix for fbcon_unbind(), splitting an unlocked version of
>> > unbind_con_driver() and call it?
>> >
>> > (BTW, the patch [2] contains strange characters in the comments, and
>> > has a few coding issues easily detected by checkpatch.pl.)
>> >
>>
>> [ CCing Rafael as he asked in another thread if I had sent a patch ]
>>
>> I noticed also some these "strange" chars in the patch from Andrew and
>> a patch of mine was sent as
>> "fb-Rework-locking-to-fix-lock-ordering-on-takeover-fix-comments.patch"
>> to the lists.
>>
>> It is strange to me that Andrew or other maintainers himself did not
>> check with "checkpatch.pl".
>> This should be a common testcase!
>> Hey, noone is perfect :-).
>> ( /me has also not checked with that script - I just saw it. )
>>
>> Just as a note to the issue in general:
>> Andrew took over the patch from Alan which is very honest - he is not
>> the active TTY maintainer!
>> Didn't Greg takeover maintenance from Alan (after a dispute and blaming Alan)?
>> If this is true, why the hell is Greg not CCed?
>
> Let's do it :)
>
> Greg, Jiri, this bug hits already quite a few people.
>
> I can reproduce the bug easily on a machine with a radeon graphics.
> It appears always at boot when lockdep is enabled.
>
>
>> Thanks for the real patch in the followup of this thread!
>> Who will take care of it :-)?
>
> Either tty maintainer, or fb maintainer, or Andrew?
>
> FWIW, Andrew took my patch in mm:
> http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
> http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch
>
[ CCing linux-next ML ]
Thanks for all your efforts to get this fb-issue nailed down for mainline!
Just as a note being a Linux-Next customer:
"fb-yet-another-band-aid-for-fixing-lockdep-mess.patch" did not hit
next-20130116!
Thanks for the link!
Normally Andrew sents out a mmotm release marking patches from his
tree destinated for Linux-Next with a "*".
To quote from the latest mmotm release-notes:
"This mmotm tree contains the following patches against 3.8-rc3:
(patches marked "*" will be included in linux-next)"
But anyway this stuff is Linux-3.8 material as well.
- Sedat -
>
> thanks,
>
> Takashi
^ permalink raw reply
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
From: Sedat Dilek @ 2013-01-16 9:59 UTC (permalink / raw)
To: Takashi Iwai
Cc: Jiri Kosina, linux-fbdev, LKML, alan, Andrew Morton,
Rafael J. Wysocki, Greg Kroah-Hartman, Jiri Slaby, linux-next
In-Reply-To: <CA+icZUXjmjgFii4bpr6fvfUY9jfu932bCxa088g-wZjOfpYbng@mail.gmail.com>
On Wed, Jan 16, 2013 at 10:52 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> On Wed, Jan 16, 2013 at 10:35 AM, Takashi Iwai <tiwai@suse.de> wrote:
>> At Wed, 16 Jan 2013 10:21:46 +0100,
>> Sedat Dilek wrote:
>>>
>>> On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai <tiwai@suse.de> wrote:
>>> > At Sat, 5 Jan 2013 13:13:27 +0100,
>>> > Sedat Dilek wrote:
>>> >>
>>> >> Hi Jiri,
>>> >>
>>> >> ...known issue (see thread in [1]), please feel free to test patches
>>> >> from Alan and Andrew (see [1], [2] and [3]) and report.
>>> >>
>>> >> Regards,
>>> >> - Sedat -
>>> >>
>>> >> [1] http://marc.info/?t\x135309396400003&r=1&w=2
>>> >> [2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
>>> >> [3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
>>> >> [4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch
>>> >
>>> > I've hit this bug and tried the patch [2] ([3] and [4] are gone).
>>> > Unfortunately the deadlock is still reported, as seen below.
>>> >
>>> > A similar fix for fbcon_unbind(), splitting an unlocked version of
>>> > unbind_con_driver() and call it?
>>> >
>>> > (BTW, the patch [2] contains strange characters in the comments, and
>>> > has a few coding issues easily detected by checkpatch.pl.)
>>> >
>>>
>>> [ CCing Rafael as he asked in another thread if I had sent a patch ]
>>>
>>> I noticed also some these "strange" chars in the patch from Andrew and
>>> a patch of mine was sent as
>>> "fb-Rework-locking-to-fix-lock-ordering-on-takeover-fix-comments.patch"
>>> to the lists.
>>>
>>> It is strange to me that Andrew or other maintainers himself did not
>>> check with "checkpatch.pl".
>>> This should be a common testcase!
>>> Hey, noone is perfect :-).
>>> ( /me has also not checked with that script - I just saw it. )
>>>
>>> Just as a note to the issue in general:
>>> Andrew took over the patch from Alan which is very honest - he is not
>>> the active TTY maintainer!
>>> Didn't Greg takeover maintenance from Alan (after a dispute and blaming Alan)?
>>> If this is true, why the hell is Greg not CCed?
>>
>> Let's do it :)
>>
>> Greg, Jiri, this bug hits already quite a few people.
>>
>> I can reproduce the bug easily on a machine with a radeon graphics.
>> It appears always at boot when lockdep is enabled.
>>
>>
>>> Thanks for the real patch in the followup of this thread!
>>> Who will take care of it :-)?
>>
>> Either tty maintainer, or fb maintainer, or Andrew?
>>
>> FWIW, Andrew took my patch in mm:
>> http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
>> http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch
>>
>
> [ CCing linux-next ML ]
>
> Thanks for all your efforts to get this fb-issue nailed down for mainline!
>
> Just as a note being a Linux-Next customer:
>
> "fb-yet-another-band-aid-for-fixing-lockdep-mess.patch" did not hit
> next-20130116!
> Thanks for the link!
>
> Normally Andrew sents out a mmotm release marking patches from his
> tree destinated for Linux-Next with a "*".
>
> To quote from the latest mmotm release-notes:
>
> "This mmotm tree contains the following patches against 3.8-rc3:
> (patches marked "*" will be included in linux-next)"
>
> But anyway this stuff is Linux-3.8 material as well.
>
JYI: [1] now does NOT have anymore those "strange" chars, Thanks Takashi san.
I will test next-20130116 with both fb-fixes as -2 kernel.
( Running LTP-lite on my "naked" -1 kernel only with my kbuild/deb-pkg-fixes. )
Thanks to everyone involved.
- Sedat -
[1] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
[2] http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch
> - Sedat -
>
>>
>> thanks,
>>
>> Takashi
^ permalink raw reply
* [PATCH 0/3] OMAPDSS: Panel NEC: backlight handling changes
From: Peter Ujfalusi @ 2013-01-16 12:45 UTC (permalink / raw)
To: Tomi Valkeinen, Florian Tobias Schandinat
Cc: Archit Taneja, linux-omap, linux-fbdev, linux-kernel,
Andrew Morton
Hi Tomi,
While working with Zoom2 which is using the NEC panel I noticed few issues with
the panel driver.
The first patch fixes one irritating warning print every time I boot the board.
With the third patch we can cleanly move to bl-pwm driver to handle the
backlight on Zoom2. In this case we should not register another backlight device
in the NEC panel driver.
Regards,
Peter
---
Peter Ujfalusi (3):
OMAPDSS: Panel NEC: Set backlight type to remove boot time warning
OMAPDSS: Panel NEC: Get rid of nec_80848_data structure
OMAPDSS: Panel NEC: Only register backlight when we have valid
callback
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 81 ++++++++++------------
1 file changed, 35 insertions(+), 46 deletions(-)
--
1.8.1
^ permalink raw reply
* [PATCH 1/3] OMAPDSS: Panel NEC: Set backlight type to remove boot time warning
From: Peter Ujfalusi @ 2013-01-16 12:45 UTC (permalink / raw)
To: Tomi Valkeinen, Florian Tobias Schandinat
Cc: Archit Taneja, linux-omap, linux-fbdev, linux-kernel,
Andrew Morton
In-Reply-To: <1358340309-8774-1-git-send-email-peter.ujfalusi@ti.com>
Fixes the following boot time warning:
[ 2.230865] WARNING: at drivers/video/backlight/backlight.c:315 backlight_device_register+0x184/0x1f4()
[ 2.240386] nec-8048: invalid backlight type
We need to pass valid backlight type when the device is registered.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
index c4e9c2b..f43a343 100644
--- a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
+++ b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
@@ -132,6 +132,7 @@ static int nec_8048_panel_probe(struct omap_dss_device *dssdev)
memset(&props, 0, sizeof(struct backlight_properties));
props.max_brightness = 255;
+ props.type = BACKLIGHT_RAW;
bl = backlight_device_register("nec-8048", &dssdev->dev, dssdev,
&nec_8048_bl_ops, &props);
--
1.8.1
^ permalink raw reply related
* [PATCH 2/3] OMAPDSS: Panel NEC: Get rid of nec_80848_data structure
From: Peter Ujfalusi @ 2013-01-16 12:45 UTC (permalink / raw)
To: Tomi Valkeinen, Florian Tobias Schandinat
Cc: Archit Taneja, linux-omap, linux-fbdev, linux-kernel,
Andrew Morton
In-Reply-To: <1358340309-8774-1-git-send-email-peter.ujfalusi@ti.com>
It has only a pointer to the backlight_device in it. We can just add the
pointer to the backlight_device as driver data.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 32 +++++-----------------
1 file changed, 7 insertions(+), 25 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
index f43a343..e6589fe 100644
--- a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
+++ b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
@@ -32,10 +32,6 @@
*/
#define LCD_PIXEL_CLOCK 23800
-struct nec_8048_data {
- struct backlight_device *bl;
-};
-
static const struct {
unsigned char addr;
unsigned char dat;
@@ -118,30 +114,21 @@ static const struct backlight_ops nec_8048_bl_ops = {
static int nec_8048_panel_probe(struct omap_dss_device *dssdev)
{
struct backlight_device *bl;
- struct nec_8048_data *necd;
struct backlight_properties props;
int r;
dssdev->panel.timings = nec_8048_panel_timings;
- necd = kzalloc(sizeof(*necd), GFP_KERNEL);
- if (!necd)
- return -ENOMEM;
-
- dev_set_drvdata(&dssdev->dev, necd);
-
memset(&props, 0, sizeof(struct backlight_properties));
props.max_brightness = 255;
props.type = BACKLIGHT_RAW;
bl = backlight_device_register("nec-8048", &dssdev->dev, dssdev,
&nec_8048_bl_ops, &props);
- if (IS_ERR(bl)) {
- r = PTR_ERR(bl);
- kfree(necd);
- return r;
- }
- necd->bl = bl;
+ if (IS_ERR(bl))
+ return PTR_ERR(bl);
+
+ dev_set_drvdata(&dssdev->dev, bl);
bl->props.fb_blank = FB_BLANK_UNBLANK;
bl->props.power = FB_BLANK_UNBLANK;
@@ -157,21 +144,17 @@ static int nec_8048_panel_probe(struct omap_dss_device *dssdev)
static void nec_8048_panel_remove(struct omap_dss_device *dssdev)
{
- struct nec_8048_data *necd = dev_get_drvdata(&dssdev->dev);
- struct backlight_device *bl = necd->bl;
+ struct backlight_device *bl = dev_get_drvdata(&dssdev->dev);
bl->props.power = FB_BLANK_POWERDOWN;
nec_8048_bl_update_status(bl);
backlight_device_unregister(bl);
-
- kfree(necd);
}
static int nec_8048_panel_power_on(struct omap_dss_device *dssdev)
{
+ struct backlight_device *bl = dev_get_drvdata(&dssdev->dev);
int r;
- struct nec_8048_data *necd = dev_get_drvdata(&dssdev->dev);
- struct backlight_device *bl = necd->bl;
if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE)
return 0;
@@ -202,8 +185,7 @@ err0:
static void nec_8048_panel_power_off(struct omap_dss_device *dssdev)
{
- struct nec_8048_data *necd = dev_get_drvdata(&dssdev->dev);
- struct backlight_device *bl = necd->bl;
+ struct backlight_device *bl = dev_get_drvdata(&dssdev->dev);
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
return;
--
1.8.1
^ permalink raw reply related
* [PATCH 3/3] OMAPDSS: Panel NEC: Only register backlight when we have valid callback
From: Peter Ujfalusi @ 2013-01-16 12:45 UTC (permalink / raw)
To: Tomi Valkeinen, Florian Tobias Schandinat
Cc: Archit Taneja, linux-omap, linux-fbdev, linux-kernel,
Andrew Morton
In-Reply-To: <1358340309-8774-1-git-send-email-peter.ujfalusi@ti.com>
Do not register a backlight device when the dssdev->set_backlight callback
is not set by the board.
In this case either we do not have means to control the backlight or the
board is using other means to control it, like bl-pwm.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 60 ++++++++++++----------
1 file changed, 33 insertions(+), 27 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
index e6589fe..11302b2 100644
--- a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
+++ b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
@@ -85,9 +85,6 @@ static int nec_8048_bl_update_status(struct backlight_device *bl)
struct omap_dss_device *dssdev = dev_get_drvdata(&bl->dev);
int level;
- if (!dssdev->set_backlight)
- return -EINVAL;
-
if (bl->props.fb_blank = FB_BLANK_UNBLANK &&
bl->props.power = FB_BLANK_UNBLANK)
level = bl->props.brightness;
@@ -114,30 +111,33 @@ static const struct backlight_ops nec_8048_bl_ops = {
static int nec_8048_panel_probe(struct omap_dss_device *dssdev)
{
struct backlight_device *bl;
- struct backlight_properties props;
int r;
dssdev->panel.timings = nec_8048_panel_timings;
- memset(&props, 0, sizeof(struct backlight_properties));
- props.max_brightness = 255;
- props.type = BACKLIGHT_RAW;
+ if (dssdev->set_backlight) {
+ struct backlight_properties props;
+
+ memset(&props, 0, sizeof(struct backlight_properties));
+ props.max_brightness = 255;
+ props.type = BACKLIGHT_RAW;
- bl = backlight_device_register("nec-8048", &dssdev->dev, dssdev,
- &nec_8048_bl_ops, &props);
- if (IS_ERR(bl))
- return PTR_ERR(bl);
+ bl = backlight_device_register("nec-8048", &dssdev->dev, dssdev,
+ &nec_8048_bl_ops, &props);
+ if (IS_ERR(bl))
+ return PTR_ERR(bl);
- dev_set_drvdata(&dssdev->dev, bl);
+ dev_set_drvdata(&dssdev->dev, bl);
- bl->props.fb_blank = FB_BLANK_UNBLANK;
- bl->props.power = FB_BLANK_UNBLANK;
- bl->props.max_brightness = dssdev->max_backlight_level;
- bl->props.brightness = dssdev->max_backlight_level;
+ bl->props.fb_blank = FB_BLANK_UNBLANK;
+ bl->props.power = FB_BLANK_UNBLANK;
+ bl->props.max_brightness = dssdev->max_backlight_level;
+ bl->props.brightness = dssdev->max_backlight_level;
- r = nec_8048_bl_update_status(bl);
- if (r < 0)
- dev_err(&dssdev->dev, "failed to set lcd brightness\n");
+ r = nec_8048_bl_update_status(bl);
+ if (r < 0)
+ dev_err(&dssdev->dev, "failed to set lcd brightness\n");
+ }
return 0;
}
@@ -146,9 +146,11 @@ static void nec_8048_panel_remove(struct omap_dss_device *dssdev)
{
struct backlight_device *bl = dev_get_drvdata(&dssdev->dev);
- bl->props.power = FB_BLANK_POWERDOWN;
- nec_8048_bl_update_status(bl);
- backlight_device_unregister(bl);
+ if (bl) {
+ bl->props.power = FB_BLANK_POWERDOWN;
+ nec_8048_bl_update_status(bl);
+ backlight_device_unregister(bl);
+ }
}
static int nec_8048_panel_power_on(struct omap_dss_device *dssdev)
@@ -172,9 +174,11 @@ static int nec_8048_panel_power_on(struct omap_dss_device *dssdev)
goto err1;
}
- r = nec_8048_bl_update_status(bl);
- if (r < 0)
- dev_err(&dssdev->dev, "failed to set lcd brightness\n");
+ if (bl) {
+ r = nec_8048_bl_update_status(bl);
+ if (r < 0)
+ dev_err(&dssdev->dev, "failed to set lcd brightness\n");
+ }
return 0;
err1:
@@ -190,8 +194,10 @@ static void nec_8048_panel_power_off(struct omap_dss_device *dssdev)
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
return;
- bl->props.brightness = 0;
- nec_8048_bl_update_status(bl);
+ if (bl) {
+ bl->props.brightness = 0;
+ nec_8048_bl_update_status(bl);
+ }
if (dssdev->platform_disable)
dssdev->platform_disable(dssdev);
--
1.8.1
^ permalink raw reply related
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
From: Sedat Dilek @ 2013-01-16 12:51 UTC (permalink / raw)
To: Takashi Iwai
Cc: Jiri Kosina, linux-fbdev, LKML, alan, Andrew Morton,
Rafael J. Wysocki, Greg Kroah-Hartman, Jiri Slaby, linux-next
In-Reply-To: <CA+icZUVviNP_BHBNQXo35W1Ge121_89argJ2NN1+rLOWgoYBtQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5008 bytes --]
On Wed, Jan 16, 2013 at 12:07 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> On Wed, Jan 16, 2013 at 10:59 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>> On Wed, Jan 16, 2013 at 10:52 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>>> On Wed, Jan 16, 2013 at 10:35 AM, Takashi Iwai <tiwai@suse.de> wrote:
>>>> At Wed, 16 Jan 2013 10:21:46 +0100,
>>>> Sedat Dilek wrote:
>>>>>
>>>>> On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai <tiwai@suse.de> wrote:
>>>>> > At Sat, 5 Jan 2013 13:13:27 +0100,
>>>>> > Sedat Dilek wrote:
>>>>> >>
>>>>> >> Hi Jiri,
>>>>> >>
>>>>> >> ...known issue (see thread in [1]), please feel free to test patches
>>>>> >> from Alan and Andrew (see [1], [2] and [3]) and report.
>>>>> >>
>>>>> >> Regards,
>>>>> >> - Sedat -
>>>>> >>
>>>>> >> [1] http://marc.info/?t=135309396400003&r=1&w=2
>>>>> >> [2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
>>>>> >> [3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
>>>>> >> [4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch
>>>>> >
>>>>> > I've hit this bug and tried the patch [2] ([3] and [4] are gone).
>>>>> > Unfortunately the deadlock is still reported, as seen below.
>>>>> >
>>>>> > A similar fix for fbcon_unbind(), splitting an unlocked version of
>>>>> > unbind_con_driver() and call it?
>>>>> >
>>>>> > (BTW, the patch [2] contains strange characters in the comments, and
>>>>> > has a few coding issues easily detected by checkpatch.pl.)
>>>>> >
>>>>>
>>>>> [ CCing Rafael as he asked in another thread if I had sent a patch ]
>>>>>
>>>>> I noticed also some these "strange" chars in the patch from Andrew and
>>>>> a patch of mine was sent as
>>>>> "fb-Rework-locking-to-fix-lock-ordering-on-takeover-fix-comments.patch"
>>>>> to the lists.
>>>>>
>>>>> It is strange to me that Andrew or other maintainers himself did not
>>>>> check with "checkpatch.pl".
>>>>> This should be a common testcase!
>>>>> Hey, noone is perfect :-).
>>>>> ( /me has also not checked with that script - I just saw it. )
>>>>>
>>>>> Just as a note to the issue in general:
>>>>> Andrew took over the patch from Alan which is very honest - he is not
>>>>> the active TTY maintainer!
>>>>> Didn't Greg takeover maintenance from Alan (after a dispute and blaming Alan)?
>>>>> If this is true, why the hell is Greg not CCed?
>>>>
>>>> Let's do it :)
>>>>
>>>> Greg, Jiri, this bug hits already quite a few people.
>>>>
>>>> I can reproduce the bug easily on a machine with a radeon graphics.
>>>> It appears always at boot when lockdep is enabled.
>>>>
>>>>
>>>>> Thanks for the real patch in the followup of this thread!
>>>>> Who will take care of it :-)?
>>>>
>>>> Either tty maintainer, or fb maintainer, or Andrew?
>>>>
>>>> FWIW, Andrew took my patch in mm:
>>>> http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
>>>> http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch
>>>>
>>>
>>> [ CCing linux-next ML ]
>>>
>>> Thanks for all your efforts to get this fb-issue nailed down for mainline!
>>>
>>> Just as a note being a Linux-Next customer:
>>>
>>> "fb-yet-another-band-aid-for-fixing-lockdep-mess.patch" did not hit
>>> next-20130116!
>>> Thanks for the link!
>>>
>>> Normally Andrew sents out a mmotm release marking patches from his
>>> tree destinated for Linux-Next with a "*".
>>>
>>> To quote from the latest mmotm release-notes:
>>>
>>> "This mmotm tree contains the following patches against 3.8-rc3:
>>> (patches marked "*" will be included in linux-next)"
>>>
>>> But anyway this stuff is Linux-3.8 material as well.
>>>
>>
>> JYI: [1] now does NOT have anymore those "strange" chars, Thanks Takashi san.
>>
>> I will test next-20130116 with both fb-fixes as -2 kernel.
>> ( Running LTP-lite on my "naked" -1 kernel only with my kbuild/deb-pkg-fixes. )
>>
>> Thanks to everyone involved.
>>
>
> I have reverted the three fb-fixes from akpm-tree in next-20130116...
> ...and applied the two fb-fixes from mmotm-tree (see attached patches file).
>
> FYI: The 1st patch from mmotm-tree is a (proper) replacement for the 3
> patches in Linux-Next.
>
> Furthermore, I made some quick testing:
> Booting into the system is fine.
> Suspend + resume looks good (see dmesg.diff).
>
> See also attached files!
>
En plus, I have run successfully LTP-lite.
$ egrep -i 'error|fail'
runltplite-results_3.8.0-rc3-next20130116-2-iniza-generic.txt | egrep
-v -i 'expected' | wc -l
208
I do not want to flood the MLs, so people wanting full LTP-lite report
(~600KiB) can contact me.
- Sedat -
> - Sedat -
>
>> - Sedat -
>>
>> [1] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
>> [2] http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch
>>> - Sedat -
>>>
>>>>
>>>> thanks,
>>>>
>>>> Takashi
[-- Attachment #2: ltplite_expected-failures_3.8.0-rc3-next20130116-2-iniza-generic.txt --]
[-- Type: text/plain, Size: 15254 bytes --]
PASS: error count is 0
bind02 1 TPASS : correct error
chmod01 2 TPASS : chmod(2) error when accessing non-existent object through symbolic link is caught
chown04 1 TPASS : chown failed: TEST_ERRNO=EPERM(1): Operation not permitted
chown04 2 TPASS : chown failed: TEST_ERRNO=EACCES(13): Permission denied
chown04 3 TPASS : chown failed: TEST_ERRNO=EFAULT(14): Bad address
chown04 4 TPASS : chown failed: TEST_ERRNO=EFAULT(14): Bad address
chown04 5 TPASS : chown failed: TEST_ERRNO=ENAMETOOLONG(36): File name too long
chown04 6 TPASS : chown failed: TEST_ERRNO=ENOENT(2): No such file or directory
chown04 7 TPASS : chown failed: TEST_ERRNO=ENOTDIR(20): Not a directory
flock01 1 TPASS : flock() succeded with Shared Lock, returned error number=0
flock01 2 TPASS : flock() succeded with Unlock, returned error number=0
flock01 3 TPASS : flock() succeded with Exclusive Lock, returned error number=0
fork06 0 TINFO : failures 0
getpriority02 1 TPASS : getpriority(2) fails, Invalid 'which' value specified, errno:22
getpriority02 2 TPASS : getpriority(2) fails, Invalid 'who' value specified, errno:3
getpriority02 3 TPASS : getpriority(2) fails, Invalid 'who' value specified, errno:3
getpriority02 4 TPASS : getpriority(2) fails, Invalid 'who' value specified, errno:3
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty0
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty1
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty10
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty11
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty12
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty13
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty14
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty15
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty16
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty17
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty18
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty19
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty2
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty20
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty21
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty22
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty23
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty24
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty25
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty26
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty27
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty28
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty29
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty3
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty30
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty31
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty32
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty33
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty34
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty35
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty36
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty37
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty38
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty39
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty4
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty40
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty41
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty42
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty43
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty44
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty45
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty46
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty47
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty48
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty49
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty5
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty50
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty51
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty52
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty53
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty54
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty55
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty56
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty57
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty58
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty59
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty6
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty60
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty61
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty62
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty63
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty7
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty8
ioctl01_02 1 TFAIL : ioctl01 Failed with /dev/tty9
kill failed with EPERM
lchown02 1 TPASS : lchown(2) fails, Process is not owner/root, errno:1
lchown02 2 TPASS : lchown(2) fails, Search permission denied, errno:13
lchown02 3 TPASS : lchown(2) fails, Address beyond address space, errno:14
lchown02 4 TPASS : lchown(2) fails, Unaccessible address space, errno:14
lchown02 5 TPASS : lchown(2) fails, Pathname too long, errno:36
lchown02 6 TPASS : lchown(2) fails, Path contains regular file, errno:20
lchown02 7 TPASS : lchown(2) fails, Pathname is empty, errno:2
link04 1 TPASS : link(<non-existent file>, <nefile>) Failed, errno=2
link04 2 TPASS : link(<path is empty string>, <nefile>) Failed, errno=2
link04 3 TPASS : link(<path contains a non-existent file>, <nefile>) Failed, errno=2
link04 4 TPASS : link(<path contains a regular file>, <nefile>) Failed, errno=20
link04 5 TPASS : link(<pathname too long>, <nefile>) Failed, errno=36
link04 6 TPASS : link(<address beyond address space>, <nefile>) Failed, errno=14
link04 7 TPASS : link(<negative address>, <nefile>) Failed, errno=14
link04 8 TPASS : link(<regfile>, <empty string>) Failed, errno=2
link04 9 TPASS : link(<regfile>, <path contains a non-existent file>) Failed, errno=2
link04 10 TPASS : link(<regfile>, <path contains a regular file>) Failed, errno=2
link04 11 TPASS : link(<regfile>, <pathname too long>) Failed, errno=36
link04 12 TPASS : link(<regfile>, <address beyond address space>) Failed, errno=14
link04 13 TPASS : link(<regfile>, <negative address>) Failed, errno=14
link04 14 TPASS : link(<regfile>, <regfile2>) Failed, errno=17
llseek02 1 TPASS : llseek() fails, 'whence' argument is not valid, errno:22
llseek02 2 TPASS : llseek() fails, 'fd' is not an open file descriptor, errno:9
lseek02 1 TPASS : lseek(-1, 1, SEEK_SET) Failed, errno=9 : Bad file descriptor
lseek03 1 TPASS : lseek(tfile_5520, 1, 5) Failed, errno=22 : Invalid argument
lseek03 2 TPASS : lseek(tfile_5520, 1, -1) Failed, errno=22 : Invalid argument
lseek03 3 TPASS : lseek(tfile_5520, 1, 7) Failed, errno=22 : Invalid argument
lseek04 1 TPASS : lseek(fifofd, 1, SEEK_SET) Failed, errno=29 : Illegal seek
lseek05 1 TPASS : lseek(pipefd, 1, SEEK_SET) Failed, errno=29 : Illegal seek
lseek10 1 TPASS : lseek() fails, 'fd' associated with a pipe/fifo, errno:29
lseek10 2 TPASS : lseek() fails, 'whence' argument is not valid, errno:22
lseek10 3 TPASS : lseek() fails, 'fd' is not an open file descriptor, errno:9
lstat02 1 TPASS : lstat() fails, No Search permissions to process, errno:13
lstat02 2 TPASS : lstat() fails, Negative address, errno:14
lstat02 3 TPASS : lstat() fails, Address beyond address space, errno:14
lstat02 4 TPASS : lstat() fails, Pathname too long, errno:36
lstat02 5 TPASS : lstat() fails, Pathname is empty, errno:2
lstat02 6 TPASS : lstat() fails, Path contains regular file, errno:20
mknod06 1 TPASS : mknod() fails, Specified node already exists, errno:17
mknod06 2 TPASS : mknod() fails, Negative address, errno:14
mknod06 3 TPASS : mknod() fails, Address beyond address space, errno:14
mknod06 4 TPASS : mknod() fails, Non-existent file, errno:2
mknod06 5 TPASS : mknod() fails, Pathname is empty, errno:2
mknod06 6 TPASS : mknod() fails, Pathname too long, errno:36
mknod06 7 TPASS : mknod() fails, Path contains regular file, errno:20
mmap06 1 TPASS : mmap failed with EACCES
mmap07 1 TPASS : mmap failed with EACCES
mmap08 1 TPASS : mmap failed with EBADF
mremap02 1 TPASS : mremap() Failed, 'invalid argument specified' - errno 22
mremap03 1 TPASS : mremap() Fails, 'old region not mapped', errno 14
mremap04 1 TPASS : mremap() failed, 'MREMAP_MAYMOVE flag unset', errno 12
open01 3 TPASS : open(2) with (O_CREAT | O_EXCL) error is caught when creating object file through symbolic link file
open01 4 TPASS : open(2) error with O_RDWR is caught when processing symbolic link file which points at no object file
pipe06 1 TPASS : failed with EMFILE
pread02 1 TPASS : pread() fails, file descriptor is a PIPE or FIFO, errno:29
pread02 2 TPASS : pread() fails, specified offset is -ve or invalid, errno:22
readlink01 3 TPASS : Reading a symbolic link which exceeds maximum pathname error is caught
readlink01 4 TPASS : Reading a nonsymbolic link file error condition is caught. EINVAL is returned
rmdir05 1 TPASS : rmdir(".") failed to remove the current working directory. Returned 22 : Invalid argument
sched_getscheduler02 1 TPASS : call failed with ESRCH
setgroups03 1 TPASS : setgroups(65537) fails, Size is > sysconf(_SC_NGROUPS_MAX), errno=22
setgroups03 2 TPASS : setgroups(65536) fails, Permission denied, not super-user, errno=1
setregid02 0 TINFO : ERROR: After setregid(-1, root), real gid = 65534; effective gid = 65534
setregid02 0 TINFO : ERROR: After setregid(-1, bin) real gid = 65534; effective gid = 65534
setregid02 0 TINFO : ERROR: After setregid(root,-1), real gid = 65534; effective gid = 65534
setregid02 0 TINFO : ERROR: After setregid(bin, -1), real gid = 65534; effective gid = 65534
setregid02 0 TINFO : ERROR: After setregid(root, bin) real gid = 65534; effective gid = 65534
setregid02 0 TINFO : ERROR: After setregid(bin, root), real gid = 65534; effective gid = 65534
setregid02 0 TINFO : ERROR: After setregid(invalid group, -1), real gid = 65534; effective gid = 65534
setregid02 0 TINFO : ERROR: After setregid(-1, invalid group), real gid = 65534; effective gid = 65534
shmctl02 6 TCONF : shmctl() did not fail for non-root user.This may be okay for your distribution.
shmctl02 7 TCONF : shmctl() did not fail for non-root user.This may be okay for your distribution.
sigaltstack02 1 TPASS : stgaltstack() fails, Invalid Flag value, errno:22
sigaltstack02 2 TPASS : stgaltstack() fails, alternate stack is < MINSIGSTKSZ, errno:12
sighold02 1 TPASS : Sighold called without error for 57 of 64 signals
stat03 1 TPASS : stat() fails, No Search permissions to process, errno:13
stat03 2 TPASS : stat() fails, Address beyond address space, errno:14
stat03 3 TPASS : stat() fails, Negative address, errno:14
stat03 4 TPASS : stat() fails, Pathname too long, errno:36
stat03 5 TPASS : stat() fails, Pathname is empty, errno:2
stat03 6 TPASS : stat() fails, Path contains regular file, errno:20
stat04 2 TPASS : Stat(2) error when accessing non-existent object through symbolic link is caught
stat06 1 TPASS : stat(<non-existent file>, &stbuf) Failed, errno=2
stat06 2 TPASS : stat(<path is empty string>, &stbuf) Failed, errno=2
stat06 3 TPASS : stat(<path contains a non-existent file>, &stbuf) Failed, errno=2
stat06 4 TPASS : stat(<path contains a regular file>, &stbuf) Failed, errno=20
stat06 5 TPASS : stat(<pathname too long>, &stbuf) Failed, errno=36
stat06 6 TPASS : stat(<address beyond address space>, &stbuf) Failed, errno=14
stat06 7 TPASS : stat(<negative address>, &stbuf) Failed, errno=14
symlink01 4 TPASS : Creating an existing symbolic link file error is caught
symlink01 5 TPASS : Creating a symbolic link which exceeds maximum pathname error is caught
symlink03 1 TPASS : symlink() Fails, No Search permissions to process, errno=13
symlink03 2 TPASS : symlink() Fails, Specified symlink already exists, errno=17
symlink03 3 TPASS : symlink() Fails, Address beyond address space, errno=14
symlink03 4 TPASS : symlink() Fails, Negative address, errno=14
symlink03 5 TPASS : symlink() Fails, Symlink path too long, errno=36
symlink03 6 TPASS : symlink() Fails, Symlink Pathname is empty, errno=2
symlink03 7 TPASS : symlink() Fails, Symlink Path contains regular file, errno=20
sysinfo02 1 TPASS : Test to check the error code 14 PASSED
truncate03 1 TPASS : truncate() fails, No Search permissions to process, errno=13
truncate03 2 TPASS : truncate() fails, Path contains regular file, errno=20
truncate03 3 TPASS : truncate() fails, Address beyond address space, errno=14
truncate03 4 TPASS : truncate() fails, Negative address, errno=14
truncate03 5 TPASS : truncate() fails, Pathname too long, errno=36
truncate03 6 TPASS : truncate() fails, Pathname is empty, errno=2
truncate04 1 TPASS : truncate() fails, File is a directory, errno=21
unlink07 1 TPASS : unlink(<non-existent file>) Failed, errno=2
unlink07 2 TPASS : unlink(<path is empty string>) Failed, errno=2
unlink07 3 TPASS : unlink(<path contains a non-existent file>) Failed, errno=2
unlink07 4 TPASS : unlink(<address beyond address space>) Failed, errno=14
unlink07 5 TPASS : unlink(<path contains a regular file>) Failed, errno=20
unlink07 6 TPASS : unlink(<address beyond address space>) Failed, errno=14
unlink07 7 TPASS : unlink(<pathname too long>) Failed, errno=36
unlink07 8 TPASS : unlink(<negative address>) Failed, errno=14
unlink08 3 TPASS : unlink(<directory>) Failed, errno=21
utime01 2 TPASS : utime(2) error when accessing non-existent object through symbolic link is caught
utime06 1 TPASS : utime() fails, Permission denied to modify file time, errno:13
utime06 2 TPASS : utime() fails, Specified file doesn't exist, errno:2
write03 0 TINFO : Enter Block 1: test to check if write corrupts the file when write fails
write03 1 TPASS : failure of write(2) didnot corrupt the file
mtest01 1 TFAIL : More memory than the maximum amount you specified is already being used
mtest01 1 TFAIL : More memory than the maximum amount you specified is already being used
gf17 1 TFAIL : Test failed
gf18 1 TFAIL : Test failed
INFO: ltp-pan reported some tests FAIL
^ permalink raw reply
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
From: Greg Kroah-Hartman @ 2013-01-17 2:42 UTC (permalink / raw)
To: Takashi Iwai
Cc: sedat.dilek, Jiri Kosina, linux-fbdev, LKML, alan, Andrew Morton,
Rafael J. Wysocki, Jiri Slaby
In-Reply-To: <s5hpq1531yn.wl%tiwai@suse.de>
On Wed, Jan 16, 2013 at 10:35:12AM +0100, Takashi Iwai wrote:
> At Wed, 16 Jan 2013 10:21:46 +0100,
> Sedat Dilek wrote:
> >
> > On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai <tiwai@suse.de> wrote:
> > > At Sat, 5 Jan 2013 13:13:27 +0100,
> > > Sedat Dilek wrote:
> > >>
> > >> Hi Jiri,
> > >>
> > >> ...known issue (see thread in [1]), please feel free to test patches
> > >> from Alan and Andrew (see [1], [2] and [3]) and report.
> > >>
> > >> Regards,
> > >> - Sedat -
> > >>
> > >> [1] http://marc.info/?t\x135309396400003&r=1&w=2
> > >> [2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
> > >> [3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
> > >> [4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch
> > >
> > > I've hit this bug and tried the patch [2] ([3] and [4] are gone).
> > > Unfortunately the deadlock is still reported, as seen below.
> > >
> > > A similar fix for fbcon_unbind(), splitting an unlocked version of
> > > unbind_con_driver() and call it?
> > >
> > > (BTW, the patch [2] contains strange characters in the comments, and
> > > has a few coding issues easily detected by checkpatch.pl.)
> > >
> >
> > [ CCing Rafael as he asked in another thread if I had sent a patch ]
> >
> > I noticed also some these "strange" chars in the patch from Andrew and
> > a patch of mine was sent as
> > "fb-Rework-locking-to-fix-lock-ordering-on-takeover-fix-comments.patch"
> > to the lists.
> >
> > It is strange to me that Andrew or other maintainers himself did not
> > check with "checkpatch.pl".
> > This should be a common testcase!
> > Hey, noone is perfect :-).
> > ( /me has also not checked with that script - I just saw it. )
> >
> > Just as a note to the issue in general:
> > Andrew took over the patch from Alan which is very honest - he is not
> > the active TTY maintainer!
> > Didn't Greg takeover maintenance from Alan (after a dispute and blaming Alan)?
> > If this is true, why the hell is Greg not CCed?
>
> Let's do it :)
>
> Greg, Jiri, this bug hits already quite a few people.
>
> I can reproduce the bug easily on a machine with a radeon graphics.
> It appears always at boot when lockdep is enabled.
>
>
> > Thanks for the real patch in the followup of this thread!
> > Who will take care of it :-)?
>
> Either tty maintainer, or fb maintainer, or Andrew?
>
> FWIW, Andrew took my patch in mm:
> http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
> http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch
Ok, so, which one should I take for 3.8? And ideally the fb maintainer
should do this, not I, right?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/1] video: exynos: Use devm_* APIs in s6e8ax0.c
From: Sachin Kamat @ 2013-01-17 3:15 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1355289083-28269-1-git-send-email-sachin.kamat@linaro.org>
Hi Florian,
On 17 December 2012 06:06, Donghwa Lee <dh09.lee@samsung.com> wrote:
> On Wed, Dec 12, 2012 at 14:11, Sachin Kamat wrote:
>>
>> devm_* APIs are device managed and make error handling
>> and code cleanup simpler.
>>
>> Cc: Donghwa Lee <dh09.lee@samsung.com>
>> Cc: Inki Dae <inki.dae@samsung.com>
>> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
>> ---
>> Compile tested against linux-next.
>> ---
>> drivers/video/exynos/s6e8ax0.c | 14 ++++----------
>> 1 files changed, 4 insertions(+), 10 deletions(-)
>>
>
> It looks good to me.
> Acked-by: Donghwa Lee <dh09.lee@samsung.com>
Can you please add this patch to to your tree if it looks OK?
--
With warm regards,
Sachin
^ permalink raw reply
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
From: Andrew Morton @ 2013-01-17 3:54 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Takashi Iwai, sedat.dilek, Jiri Kosina, linux-fbdev, LKML, alan,
Rafael J. Wysocki, Jiri Slaby
In-Reply-To: <20130117024246.GF20928@kroah.com>
On Wed, 16 Jan 2013 18:42:46 -0800 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > FWIW, Andrew took my patch in mm:
> > http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
> > http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch
>
>
> Ok, so, which one should I take for 3.8? And ideally the fb maintainer
> should do this, not I, right?
Please see http://www.spinics.net/lists/linux-fbdev/msg08954.html
Tomi might be able to review the above for us. I think we need both.
If nothing else happens I intend to send both Linuswards for 3.8 in a
week or two.
^ permalink raw reply
* Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
From: Greg Kroah-Hartman @ 2013-01-17 4:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Takashi Iwai, sedat.dilek, Jiri Kosina, linux-fbdev, LKML, alan,
Rafael J. Wysocki, Jiri Slaby
In-Reply-To: <20130116195416.c2d9a107.akpm@linux-foundation.org>
On Wed, Jan 16, 2013 at 07:54:16PM -0800, Andrew Morton wrote:
> On Wed, 16 Jan 2013 18:42:46 -0800 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> > > FWIW, Andrew took my patch in mm:
> > > http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
> > > http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch
> >
> >
> > Ok, so, which one should I take for 3.8? And ideally the fb maintainer
> > should do this, not I, right?
>
> Please see http://www.spinics.net/lists/linux-fbdev/msg08954.html
>
> Tomi might be able to review the above for us. I think we need both.
> If nothing else happens I intend to send both Linuswards for 3.8 in a
> week or two.
Ok, that sounds fine with me, thanks for doing that.
greg k-h
^ permalink raw reply
* [PATCH v5 0/8] video: mmp display subsystem
From: Zhou Zhu @ 2013-01-17 8:20 UTC (permalink / raw)
To: linux-fbdev
Hi,
This series added support for display controller in
Marvell "mmp" series processors.
It also contains patches to enable display panel on
TTC_DKB board.
v5: rebased to 3.8RC3 and support common clock tree.
v4: added patches to enable display panel on TTC_DKB
board.
v3: registered lcd spi control as a spi master and
panel driver operations moved to standard spi bus
interface.
v2: removed change-id and blank lines.
Thanks,
-Zhou
Guoqing Li (1):
video: mmp display controller support
Lisa Du (1):
video: mmp: add tpo hvga panel supported
Zhou Zhu (6):
video: mmp display subsystem
video: mmp fb support
video: mmpdisp: add spi port in display controller
ARM: mmp: added device for display controller
ARM: mmp: enable display in ttc_dkb
ARM: mmp: add display and fb support in pxa910 defconfig
arch/arm/configs/pxa910_defconfig | 8 +
arch/arm/mach-mmp/include/mach/pxa910.h | 5 +-
arch/arm/mach-mmp/pxa910.c | 3 +
arch/arm/mach-mmp/ttc_dkb.c | 92 ++
drivers/video/Kconfig | 1 +
drivers/video/Makefile | 1 +
drivers/video/mmp/Kconfig | 11 +
drivers/video/mmp/Makefile | 1 +
drivers/video/mmp/core.c | 217 ++++
drivers/video/mmp/fb/Kconfig | 13 +
drivers/video/mmp/fb/Makefile | 1 +
drivers/video/mmp/fb/mmpfb.c | 710 +++++++++++
drivers/video/mmp/fb/mmpfb.h | 54 +
drivers/video/mmp/hw/Kconfig | 20 +
drivers/video/mmp/hw/Makefile | 2 +
drivers/video/mmp/hw/mmp_ctrl.c | 591 +++++++++
drivers/video/mmp/hw/mmp_ctrl.h | 1958 +++++++++++++++++++++++++++++
drivers/video/mmp/hw/mmp_spi.c | 180 +++
drivers/video/mmp/panel/Kconfig | 6 +
drivers/video/mmp/panel/Makefile | 1 +
drivers/video/mmp/panel/tpo_tj032md01bw.c | 188 +++
include/video/mmp_disp.h | 351 ++++++
22 files changed, 4413 insertions(+), 1 deletion(-)
create mode 100644 drivers/video/mmp/Kconfig
create mode 100644 drivers/video/mmp/Makefile
create mode 100644 drivers/video/mmp/core.c
create mode 100644 drivers/video/mmp/fb/Kconfig
create mode 100644 drivers/video/mmp/fb/Makefile
create mode 100644 drivers/video/mmp/fb/mmpfb.c
create mode 100644 drivers/video/mmp/fb/mmpfb.h
create mode 100644 drivers/video/mmp/hw/Kconfig
create mode 100644 drivers/video/mmp/hw/Makefile
create mode 100644 drivers/video/mmp/hw/mmp_ctrl.c
create mode 100644 drivers/video/mmp/hw/mmp_ctrl.h
create mode 100644 drivers/video/mmp/hw/mmp_spi.c
create mode 100644 drivers/video/mmp/panel/Kconfig
create mode 100644 drivers/video/mmp/panel/Makefile
create mode 100644 drivers/video/mmp/panel/tpo_tj032md01bw.c
create mode 100644 include/video/mmp_disp.h
--
1.7.9.5
^ 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