* Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
From: Stephen Warren @ 2013-01-31 17:25 UTC (permalink / raw)
To: Mark Zhang
Cc: Alexandre Courbot, Laurent Pinchart, Thierry Reding, Mark Zhang,
Linux Kernel Mailing List,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org
In-Reply-To: <510A1DAC.1070106-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 01/31/2013 12:30 AM, Mark Zhang wrote:
> On 01/31/2013 02:36 PM, Alexandre Courbot wrote:
>> On Thu, Jan 31, 2013 at 1:54 PM, Mark Zhang <nvmarkzhang@gmail.com> wrote:
>>> Display controller don't know whether the panel has EDID EEPROM but the
>>> panel driver knows. So why we need to make display controller queries
>>> EDID blindly? Since panel driver knows about all "video modes/panel
>>> size" stuffs, why not we let it handle all these things?
>>
>> The DC actually does know whether the connected panel supports EDID -
>> in this case, the output node will have a property for the DDC bus,
>> e.g.
>>
>> nvidia,ddc-i2c-bus = <&lcd_ddc>;
>>
>> If no DDC bus is specified or if transfer fails, the DC driver can
>> still query the panel driver for hardcoded modes.
>
> Strictly speaking, according to my understanding, "nvidia,ddc-i2c-bus"
> means tegra has a hardware ddc channel, this doesn't mean we can get the
> EDID from this DDC surely.
Having a DDC bus by definition means that the EDID can be queried
through it. If you can't query the EDID, there is no DDC bus, and hence
that property is not present in the DT.
^ permalink raw reply
* Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
From: Stephen Warren @ 2013-01-31 17:23 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Laurent Pinchart, Thierry Reding, Mark Zhang,
Linux Kernel Mailing List,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Alexandre Courbot
In-Reply-To: <CAAVeFuJkJ4cftWvSvt1YJa6c48JyJPVTu=i18yMHptZMi3DAzg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 01/30/2013 09:14 PM, Alexandre Courbot wrote:
> On Thu, Jan 31, 2013 at 5:27 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> So this looks like a reasonable binding to me. The one issue is that
>> it's very generic, and if we go this route, we'll probably end up with
>> tens or hundreds of identical or extremely similar simple bindings, and
>> associated drivers.
>>
>> We can avoid this instead by defining something like a "simple-lcd"
>> binding, and associated driver, that will work for perhaps 90%, 95%,
>> 99%, even 100%(?) of panels.
>
> That seems totally doable indeed. Actually the right way to do this
> might be by extending the simple DPI panel driver Laurent included in
> his patchset.
>
>> Just like the above, but with:
>>
>> compatible="simple-panel", "chunghwa,claa101wa01a"
>>
>> instead, and the driver binding to "simple-panel" rather than
>> "chunghwa,claa101wa01a".
>
> Just out of curiosity, why don't we rather define
>
> compatible="chunghwa,claa101wa01a", "simple-panel"
>
> in that order? I thought DT compatible strings should go from more to
> less specific. The device would still bind to "simple-panel" if no
> more specific driver exists.
Yes, that's correct; I "typo"d the example I gave.
>> The driver can assume that a specific set of supplies (and perhaps
>> GPIOs) is always present, and that the /sequence/ of manipulating those
>> is fixed. This will avoid the need for anything like the power sequences
>> code. If a particular panel doesn't fit those assumptions, including the
>> exact sequence of manipulations for each state transition (which should
>> be documented in the binding) then it can get a custom driver, this also
>> avoiding having to define custom sequences in DT.
>>
>> Things that might be parameterized/optional:
>>
>> * Perhaps some GPIOs aren't always present.
>> * If some regulators aren't SW-controllable, DT should still provide a
>> fixed/dummy regulator so the driver doesn't care.
>
> How about making all regulators and GPIO optional in the driver?
The general feedback I've received is that regulators should always be
present, and simply implemented by fixed/dummy regulators if missing in
a particular board design, rather than having the driver code handle
them being optional. This certainly does simplify the driver, since it
can always unconditionally program the regulator irrespective of whether
it's fixed/dummy or not.
^ permalink raw reply
* Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
From: Stephen Warren @ 2013-01-31 17:20 UTC (permalink / raw)
To: Mark Zhang
Cc: Alexandre Courbot, Laurent Pinchart, Thierry Reding, Mark Zhang,
linux-kernel, linux-fbdev, linux-tegra, gnurou
In-Reply-To: <5109EA2A.8020204@gmail.com>
On 01/30/2013 08:51 PM, Mark Zhang wrote:
> On 01/31/2013 04:19 AM, Stephen Warren wrote:
>> On 01/30/2013 12:20 AM, Mark Zhang wrote:
>>> On 01/30/2013 11:02 AM, Alexandre Courbot wrote:
>>>> Add support for the Chunghwa CLAA101WA01A display panel.
>>
>>>> +static int panel_claa101_get_modes(struct display_entity *entity,
>>>> + const struct videomode **modes)
>>>> +{
>>>> + /* TODO get modes from EDID? */
>>>
>>> Why not move the "nvidia,ddc" from encoder's DT to panel's DT? In that
>>> case, you can get EDID here. I know drm has some helpers to fetch EDID
>>> but I recall there are some other functions which has no drm
>>> dependencies which may be suitable for you.
>>
>> DDC access is a property of the display controller, not the panel
>> itself. The panel might be hooked up to a display controller's DDC/I2C
>> channel as the target, but it isn't the host/controller of the DDC/I2C
>> channel. As such, placing the nvidia,ddc property into the display
>> controller node makes sense.
>
> Yes, DC triggers the DDC access and is the host of the DDC/I2C channel.
> So I think it's reasonable to put nvidia,ddc property into the display
> controller node. But the video mode info in EDID which be fetched via
> DDC is the property of the panel, so this info should be provided by
> panel driver.
No, that makes absolutely no sense at all in the EDID case.
By the same argument, we'd need a panel driver for every external
monitor which implemented EDID, just to transfer the EDID results from
the display controller's DDC channel into the panel driver and back into
the display controller code, which wants the mode list.
Again, if the mode list is coming from DDC, the display controller
should retrieve it in exactly the same way it retrieves it for any
external monitor - by direct control of the DDC channel to read the
EDID. The only time it makes sense for the panel driver to get involved
in supplying the mode list is when there's no EDID, so the list must be
hard-coded into the driver.
^ permalink raw reply
* Re: BUG: circular locking dependency detected
From: Russell King @ 2013-01-31 13:07 UTC (permalink / raw)
To: Dave Airlie
Cc: Greg Kroah-Hartman, Daniel Vetter, Linus Torvalds, Andrew Morton,
Florian Tobias Schandinat, linux-fbdev@vger.kernel.org,
Linux Kernel Mailing List, dri-devel
In-Reply-To: <CAPM=9tzZLPZ0EqEvEuZbimomSQv+xMnLpTq28z7=bKBF1w26TQ@mail.gmail.com>
On Thu, Jan 31, 2013 at 10:51:27PM +1100, Dave Airlie wrote:
> I'll ship them via my tree at this point I think, since I now need to
> queue a revert of the revert on top.
>
> I have a few vgacon/fbcon fixes that I need to go in this cycle.
Great, thanks.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: BUG: circular locking dependency detected
From: Greg Kroah-Hartman @ 2013-01-31 13:02 UTC (permalink / raw)
To: Dave Airlie
Cc: Daniel Vetter, Linus Torvalds, Russell King, Andrew Morton,
Florian Tobias Schandinat, linux-fbdev@vger.kernel.org,
Linux Kernel Mailing List, dri-devel
In-Reply-To: <CAPM=9tzZLPZ0EqEvEuZbimomSQv+xMnLpTq28z7=bKBF1w26TQ@mail.gmail.com>
On Thu, Jan 31, 2013 at 10:51:27PM +1100, Dave Airlie wrote:
> On Thu, Jan 31, 2013 at 8:21 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Thu, Jan 31, 2013 at 09:21:16AM +0100, Daniel Vetter wrote:
> >> On Thu, Jan 31, 2013 at 6:40 AM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> > On Thu, Jan 31, 2013 at 11:26:53AM +1100, Linus Torvalds wrote:
> >> >> On Thu, Jan 31, 2013 at 11:13 AM, Russell King <rmk@arm.linux.org.uk> wrote:
> >> >> >
> >> >> > Which may or may not be a good thing depending how you look at it; it
> >> >> > means that once your kernel blanks, you get a lockdep dump. At that
> >> >> > point you lose lockdep checking for everything else because lockdep
> >> >> > disables itself after the first dump.
> >> >>
> >> >> Fair enough, we may want to revert the lockdep checking for
> >> >> console_lock, and make re-enabling it part of the patch-series that
> >> >> fixes the locking.
> >> >>
> >> >> Daniel/Dave? Does that sound reasonable?
> >>
> >> Yeah, sounds good.
> >>
> >> > Reverting the patch is fine with me. Just let me know so I can queue it
> >> > up again for 3.9.
> >>
> >> Can you please also pick up the (currently) three locking fixups
> >> around fbcon? Just so that we don't repeat the same fun where people
> >> complain about lockdep splats, but the fixes are stuck somewhere. And
> >> I guess Dave would be happy to not end up as fbcon maintainer ;-) He
> >> has a git branch with them at
> >> http://cgit.freedesktop.org/~airlied/linux/log/?hûcon-locking-fixes
> >> though I have a small bikeshed on his last patch pending.
> >
> > Care to just send me the patches through email when you all get done
> > bikesheding? And for some reason I thought Andrew was going to handle
> > these fbcon patches, but if not, I'll be glad to take them.
>
> I'll ship them via my tree at this point I think, since I now need to
> queue a revert of the revert on top.
>
> I have a few vgacon/fbcon fixes that I need to go in this cycle.
Ok, I'll gladly let you handle this :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 2/4] pwm_backlight: Validate dft_brightness in main probe function
From: Thierry Reding @ 2013-01-31 12:58 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: Richard Purdie, Grant Likely, Rob Landley,
Florian Tobias Schandinat, Andrew Morton, devicetree-discuss,
linux-doc, linux-kernel, linux-fbdev
In-Reply-To: <510A65BA.6090208@ti.com>
[-- Attachment #1: Type: text/plain, Size: 735 bytes --]
On Thu, Jan 31, 2013 at 01:38:18PM +0100, Peter Ujfalusi wrote:
> Hi Thierry,
>
> On 01/22/2013 02:39 PM, Peter Ujfalusi wrote:
> > Move the dft_brightness validity check from the DT parsing function to the
> > main probe. In this way we can validate it in case we are booting with or
> > without DT.
>
> Based on the discussion the rest of the series is going to be dropped, but
> what about this single patch?
> I think it is still addresses a valid issue, which is that in non DT boot we
> do not check if the dft_brightness is within valid range.
>
> I can resend this patch alone since it is not going to apply on mainline as it is.
No that's okay. I've gone ahead and applied in manually.
Thanks,
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] pwm_backlight: Validate dft_brightness in main probe function
From: Peter Ujfalusi @ 2013-01-31 12:38 UTC (permalink / raw)
To: Richard Purdie
Cc: Grant Likely, Rob Landley, Thierry Reding,
Florian Tobias Schandinat, Andrew Morton, devicetree-discuss,
linux-doc, linux-kernel, linux-fbdev
In-Reply-To: <1358861996-27194-3-git-send-email-peter.ujfalusi@ti.com>
Hi Thierry,
On 01/22/2013 02:39 PM, Peter Ujfalusi wrote:
> Move the dft_brightness validity check from the DT parsing function to the
> main probe. In this way we can validate it in case we are booting with or
> without DT.
Based on the discussion the rest of the series is going to be dropped, but
what about this single patch?
I think it is still addresses a valid issue, which is that in non DT boot we
do not check if the dft_brightness is within valid range.
I can resend this patch alone since it is not going to apply on mainline as it is.
--
Péter
>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
> drivers/video/backlight/pwm_bl.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index f0d6854..2a81c24 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -135,12 +135,6 @@ static int pwm_backlight_parse_dt(struct device *dev,
> if (ret < 0)
> return ret;
>
> - if (value >= data->max_brightness) {
> - dev_warn(dev, "invalid default brightness level: %u, using %u\n",
> - value, data->max_brightness - 1);
> - value = data->max_brightness - 1;
> - }
> -
> data->dft_brightness = value;
> }
>
> @@ -249,6 +243,12 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> goto err_alloc;
> }
>
> + if (data->dft_brightness > data->max_brightness) {
> + dev_warn(&pdev->dev,
> + "invalid default brightness level: %u, using %u\n",
> + data->dft_brightness, data->max_brightness);
> + data->dft_brightness = data->max_brightness;
> + }
> bl->props.brightness = data->dft_brightness;
> backlight_update_status(bl);
>
>
^ permalink raw reply
* Re: BUG: circular locking dependency detected
From: Dave Airlie @ 2013-01-31 11:51 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Daniel Vetter, Linus Torvalds, Russell King, Andrew Morton,
Florian Tobias Schandinat, linux-fbdev@vger.kernel.org,
Linux Kernel Mailing List, dri-devel
In-Reply-To: <20130131092146.GB3361@kroah.com>
On Thu, Jan 31, 2013 at 8:21 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Thu, Jan 31, 2013 at 09:21:16AM +0100, Daniel Vetter wrote:
>> On Thu, Jan 31, 2013 at 6:40 AM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> > On Thu, Jan 31, 2013 at 11:26:53AM +1100, Linus Torvalds wrote:
>> >> On Thu, Jan 31, 2013 at 11:13 AM, Russell King <rmk@arm.linux.org.uk> wrote:
>> >> >
>> >> > Which may or may not be a good thing depending how you look at it; it
>> >> > means that once your kernel blanks, you get a lockdep dump. At that
>> >> > point you lose lockdep checking for everything else because lockdep
>> >> > disables itself after the first dump.
>> >>
>> >> Fair enough, we may want to revert the lockdep checking for
>> >> console_lock, and make re-enabling it part of the patch-series that
>> >> fixes the locking.
>> >>
>> >> Daniel/Dave? Does that sound reasonable?
>>
>> Yeah, sounds good.
>>
>> > Reverting the patch is fine with me. Just let me know so I can queue it
>> > up again for 3.9.
>>
>> Can you please also pick up the (currently) three locking fixups
>> around fbcon? Just so that we don't repeat the same fun where people
>> complain about lockdep splats, but the fixes are stuck somewhere. And
>> I guess Dave would be happy to not end up as fbcon maintainer ;-) He
>> has a git branch with them at
>> http://cgit.freedesktop.org/~airlied/linux/log/?hûcon-locking-fixes
>> though I have a small bikeshed on his last patch pending.
>
> Care to just send me the patches through email when you all get done
> bikesheding? And for some reason I thought Andrew was going to handle
> these fbcon patches, but if not, I'll be glad to take them.
I'll ship them via my tree at this point I think, since I now need to
queue a revert of the revert on top.
I have a few vgacon/fbcon fixes that I need to go in this cycle.
Dave.
^ permalink raw reply
* Re: [PATCH 1/3] video: exynos_mipi_dsi: Convert to devm_ioremap_resource()
From: Sachin Kamat @ 2013-01-31 11:32 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-kernel, gregkh, Donghwa Lee, Florian Tobias Schandinat,
linux-fbdev
In-Reply-To: <20130131104241.GA8676@avionic-0098.mockup.avionic-design.de>
On 31 January 2013 16:12, Thierry Reding
<thierry.reding@avionic-design.de> wrote:
> On Thu, Jan 31, 2013 at 03:55:37PM +0530, Sachin Kamat wrote:
>> Use the newly introduced devm_ioremap_resource() instead of
>> devm_request_and_ioremap() which provides more consistent error handling.
>>
>> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
>> Cc: Donghwa Lee <dh09.lee@samsung.com>
>> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
>> Cc: linux-fbdev@vger.kernel.org
>> ---
>> drivers/video/exynos/exynos_mipi_dsi.c | 7 ++++---
>> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> All of these can drop the additional error message because equivalent
> error message are output by devm_ioremap_resource() itself.
Ah right.. I will remove them and re-send the patches.
--
With warm regards,
Sachin
^ permalink raw reply
* Re: [PATCH 1/3] video: exynos_mipi_dsi: Convert to devm_ioremap_resource()
From: Thierry Reding @ 2013-01-31 10:42 UTC (permalink / raw)
To: Sachin Kamat
Cc: linux-kernel, gregkh, Donghwa Lee, Florian Tobias Schandinat,
linux-fbdev
In-Reply-To: <1359627939-2685-1-git-send-email-sachin.kamat@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 664 bytes --]
On Thu, Jan 31, 2013 at 03:55:37PM +0530, Sachin Kamat wrote:
> Use the newly introduced devm_ioremap_resource() instead of
> devm_request_and_ioremap() which provides more consistent error handling.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> Cc: Donghwa Lee <dh09.lee@samsung.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: linux-fbdev@vger.kernel.org
> ---
> drivers/video/exynos/exynos_mipi_dsi.c | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
All of these can drop the additional error message because equivalent
error message are output by devm_ioremap_resource() itself.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 1/3] video: exynos_mipi_dsi: Convert to devm_ioremap_resource()
From: Sachin Kamat @ 2013-01-31 10:37 UTC (permalink / raw)
To: linux-kernel
Cc: thierry.reding, gregkh, sachin.kamat, Donghwa Lee,
Florian Tobias Schandinat, linux-fbdev
Use the newly introduced devm_ioremap_resource() instead of
devm_request_and_ioremap() which provides more consistent error handling.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Donghwa Lee <dh09.lee@samsung.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org
---
drivers/video/exynos/exynos_mipi_dsi.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
index fac7df6..a29715f 100644
--- a/drivers/video/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/exynos/exynos_mipi_dsi.c
@@ -32,6 +32,7 @@
#include <linux/notifier.h>
#include <linux/regulator/consumer.h>
#include <linux/pm_runtime.h>
+#include <linux/err.h>
#include <video/exynos_mipi_dsim.h>
@@ -384,10 +385,10 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- dsim->reg_base = devm_request_and_ioremap(&pdev->dev, res);
- if (!dsim->reg_base) {
+ dsim->reg_base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(dsim->reg_base)) {
dev_err(&pdev->dev, "failed to remap io region\n");
- ret = -ENOMEM;
+ ret = PTR_ERR(dsim->reg_base);
goto error;
}
--
1.7.4.1
^ permalink raw reply related
* Re: BUG: circular locking dependency detected
From: Sedat Dilek @ 2013-01-31 10:20 UTC (permalink / raw)
To: Daniel Vetter
Cc: Dave Airlie, Linus Torvalds, DRI, linux-fbdev, linux-next,
Stephen Rothwell, Andrew Morton, linux-mm, Takashi Iwai, gregkh,
Borislav Petkov
In-Reply-To: <CA+icZUVHrGcGnRcBQF1HLsR4HKOjLsOi6MppPnZCuh8K=wMHmA@mail.gmail.com>
On Thu, Jan 31, 2013 at 11:12 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> [ CCing Linux-Next and MMOTM folks ]
>
> Original posting from Daniel see [0]
>
> [ QUOTE ]
> On Thu, Jan 31, 2013 at 6:40 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>> On Thu, Jan 31, 2013 at 11:26:53AM +1100, Linus Torvalds wrote:
>>> On Thu, Jan 31, 2013 at 11:13 AM, Russell King <rmk@arm.linux.org.uk> wrote:
>>> >
>>> > Which may or may not be a good thing depending how you look at it; it
>>> > means that once your kernel blanks, you get a lockdep dump. At that
>>> > point you lose lockdep checking for everything else because lockdep
>>> > disables itself after the first dump.
>>>
>>> Fair enough, we may want to revert the lockdep checking for
>>> console_lock, and make re-enabling it part of the patch-series that
>>> fixes the locking.
>>>
>>> Daniel/Dave? Does that sound reasonable?
>
> Yeah, sounds good.
>
>> Reverting the patch is fine with me. Just let me know so I can queue it
>> up again for 3.9.
>
> Can you please also pick up the (currently) three locking fixups
> around fbcon? Just so that we don't repeat the same fun where people
> complain about lockdep splats, but the fixes are stuck somewhere. And
> I guess Dave would be happy to not end up as fbcon maintainer ;-) He
> has a git branch with them at
> http://cgit.freedesktop.org/~airlied/linux/log/?hûcon-locking-fixes
> though I have a small bikeshed on his last patch pending.
> -Daniel
> [ /QUOTE ]
>
> Did the 3rd patch go also to mmotm tree and got marked for Linux-Next inclusion?
> Best would be to have it in mainline, finally.
> Please, fix that for-3.8!
>
> Thanks to all volunteers (Alan, Andrew, Takashi Iwai (Sorry, dunno
> which is 1st and last name), Daniel and finally Dave) trying to get
> this incredible pain-in-the-a** upstream :-).
>
> - Sedat -
>
> [0] http://marc.info/?l=dri-devel&m\x135962051326601&w=2
> [1] http://cgit.freedesktop.org/~airlied/linux/log/?hûcon-locking-fixes
> [2] http://cgit.freedesktop.org/~airlied/linux/commit/?hûcon-locking-fixes&id˜dfe36b5532576dedf41408d5bbd45fa31ec62d
[ Adjusting outdated email-adresses, CC Borislav ]
What's with the patch from [3] in mmotm? For-3.8, no more needed?
- Sedat -
[3] http://ozlabs.org/~akpm/mmots/broken-out/drm-fb-helper-dont-sleep-for-screen-unblank-when-an-oopps-is-in-progress.patch
^ permalink raw reply
* Re: BUG: circular locking dependency detected
From: Sedat Dilek @ 2013-01-31 10:12 UTC (permalink / raw)
To: Daniel Vetter
Cc: Dave Airlie, Linus Torvalds, Greg KH, DRI, linux-fbdev,
linux-next, Stephen Rothwell, Andrew Morton, linux-mm,
Takashi Iwai
In-Reply-To: <20130130200400.GB31748@flint.arm.linux.org.uk>
[ CCing Linux-Next and MMOTM folks ]
Original posting from Daniel see [0]
[ QUOTE ]
On Thu, Jan 31, 2013 at 6:40 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Thu, Jan 31, 2013 at 11:26:53AM +1100, Linus Torvalds wrote:
>> On Thu, Jan 31, 2013 at 11:13 AM, Russell King <rmk@arm.linux.org.uk> wrote:
>> >
>> > Which may or may not be a good thing depending how you look at it; it
>> > means that once your kernel blanks, you get a lockdep dump. At that
>> > point you lose lockdep checking for everything else because lockdep
>> > disables itself after the first dump.
>>
>> Fair enough, we may want to revert the lockdep checking for
>> console_lock, and make re-enabling it part of the patch-series that
>> fixes the locking.
>>
>> Daniel/Dave? Does that sound reasonable?
Yeah, sounds good.
> Reverting the patch is fine with me. Just let me know so I can queue it
> up again for 3.9.
Can you please also pick up the (currently) three locking fixups
around fbcon? Just so that we don't repeat the same fun where people
complain about lockdep splats, but the fixes are stuck somewhere. And
I guess Dave would be happy to not end up as fbcon maintainer ;-) He
has a git branch with them at
http://cgit.freedesktop.org/~airlied/linux/log/?hûcon-locking-fixes
though I have a small bikeshed on his last patch pending.
-Daniel
[ /QUOTE ]
Did the 3rd patch go also to mmotm tree and got marked for Linux-Next inclusion?
Best would be to have it in mainline, finally.
Please, fix that for-3.8!
Thanks to all volunteers (Alan, Andrew, Takashi Iwai (Sorry, dunno
which is 1st and last name), Daniel and finally Dave) trying to get
this incredible pain-in-the-a** upstream :-).
- Sedat -
[0] http://marc.info/?l=dri-devel&m\x135962051326601&w=2
[1] http://cgit.freedesktop.org/~airlied/linux/log/?hûcon-locking-fixes
[2] http://cgit.freedesktop.org/~airlied/linux/commit/?hûcon-locking-fixes&id˜dfe36b5532576dedf41408d5bbd45fa31ec62d
^ permalink raw reply
* Re: BUG: circular locking dependency detected
From: Daniel Vetter @ 2013-01-31 9:38 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Linus Torvalds, Russell King, Dave Airlie, Andrew Morton,
Florian Tobias Schandinat, linux-fbdev@vger.kernel.org,
Linux Kernel Mailing List, dri-devel
In-Reply-To: <20130131092146.GB3361@kroah.com>
On Thu, Jan 31, 2013 at 10:21 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>> Can you please also pick up the (currently) three locking fixups
>> around fbcon? Just so that we don't repeat the same fun where people
>> complain about lockdep splats, but the fixes are stuck somewhere. And
>> I guess Dave would be happy to not end up as fbcon maintainer ;-) He
>> has a git branch with them at
>> http://cgit.freedesktop.org/~airlied/linux/log/?hûcon-locking-fixes
>> though I have a small bikeshed on his last patch pending.
>
> Care to just send me the patches through email when you all get done
> bikesheding? And for some reason I thought Andrew was going to handle
> these fbcon patches, but if not, I'll be glad to take them.
Yeah, I'll annoy people again with patches until they're merged ;-)
Iirc Andrew picked them due to lack of an fbcon maintainer, and
everyone else likes to pass the bucket. Having looked through the code
a bit, imo understandable ...
btw, I've started to look into how we could fix the locking madness
around fbcon for good instead of with duct-tape [1]. I'll try to
discuss this with a few fbdev guys at fosdem (some at least should be
there). Certainly a long-term thing, but comments from whomever gets
volunteered to shepherd fbcon would be great.
Cheers, Daniel
1: http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg33535.html
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: BUG: circular locking dependency detected
From: Greg Kroah-Hartman @ 2013-01-31 9:21 UTC (permalink / raw)
To: Daniel Vetter
Cc: Linus Torvalds, Russell King, Dave Airlie, Andrew Morton,
Florian Tobias Schandinat, linux-fbdev@vger.kernel.org,
Linux Kernel Mailing List, dri-devel
In-Reply-To: <CAKMK7uGUrvh2dXza_b288kVdztiLjSCNpH304oBQgg_ZonEnzw@mail.gmail.com>
On Thu, Jan 31, 2013 at 09:21:16AM +0100, Daniel Vetter wrote:
> On Thu, Jan 31, 2013 at 6:40 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Thu, Jan 31, 2013 at 11:26:53AM +1100, Linus Torvalds wrote:
> >> On Thu, Jan 31, 2013 at 11:13 AM, Russell King <rmk@arm.linux.org.uk> wrote:
> >> >
> >> > Which may or may not be a good thing depending how you look at it; it
> >> > means that once your kernel blanks, you get a lockdep dump. At that
> >> > point you lose lockdep checking for everything else because lockdep
> >> > disables itself after the first dump.
> >>
> >> Fair enough, we may want to revert the lockdep checking for
> >> console_lock, and make re-enabling it part of the patch-series that
> >> fixes the locking.
> >>
> >> Daniel/Dave? Does that sound reasonable?
>
> Yeah, sounds good.
>
> > Reverting the patch is fine with me. Just let me know so I can queue it
> > up again for 3.9.
>
> Can you please also pick up the (currently) three locking fixups
> around fbcon? Just so that we don't repeat the same fun where people
> complain about lockdep splats, but the fixes are stuck somewhere. And
> I guess Dave would be happy to not end up as fbcon maintainer ;-) He
> has a git branch with them at
> http://cgit.freedesktop.org/~airlied/linux/log/?hûcon-locking-fixes
> though I have a small bikeshed on his last patch pending.
Care to just send me the patches through email when you all get done
bikesheding? And for some reason I thought Andrew was going to handle
these fbcon patches, but if not, I'll be glad to take them.
thanks,
greg k-h
^ permalink raw reply
* Re: BUG: circular locking dependency detected
From: Daniel Vetter @ 2013-01-31 8:21 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Linus Torvalds, Russell King, Dave Airlie, Andrew Morton,
Florian Tobias Schandinat, linux-fbdev@vger.kernel.org,
Linux Kernel Mailing List, dri-devel
In-Reply-To: <20130131054002.GA3697@kroah.com>
On Thu, Jan 31, 2013 at 6:40 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Thu, Jan 31, 2013 at 11:26:53AM +1100, Linus Torvalds wrote:
>> On Thu, Jan 31, 2013 at 11:13 AM, Russell King <rmk@arm.linux.org.uk> wrote:
>> >
>> > Which may or may not be a good thing depending how you look at it; it
>> > means that once your kernel blanks, you get a lockdep dump. At that
>> > point you lose lockdep checking for everything else because lockdep
>> > disables itself after the first dump.
>>
>> Fair enough, we may want to revert the lockdep checking for
>> console_lock, and make re-enabling it part of the patch-series that
>> fixes the locking.
>>
>> Daniel/Dave? Does that sound reasonable?
Yeah, sounds good.
> Reverting the patch is fine with me. Just let me know so I can queue it
> up again for 3.9.
Can you please also pick up the (currently) three locking fixups
around fbcon? Just so that we don't repeat the same fun where people
complain about lockdep splats, but the fixes are stuck somewhere. And
I guess Dave would be happy to not end up as fbcon maintainer ;-) He
has a git branch with them at
http://cgit.freedesktop.org/~airlied/linux/log/?hûcon-locking-fixes
though I have a small bikeshed on his last patch pending.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
From: Mark Zhang @ 2013-01-31 7:30 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Stephen Warren, Laurent Pinchart, Thierry Reding, Mark Zhang,
Linux Kernel Mailing List,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org
In-Reply-To: <CAAVeFuL_a1aAEDCFdhjMzZG40QuK3dcZqsWqfVpwmQbZsfiHRg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 01/31/2013 02:36 PM, Alexandre Courbot wrote:
> On Thu, Jan 31, 2013 at 1:54 PM, Mark Zhang <nvmarkzhang@gmail.com> wrote:
>> Display controller don't know whether the panel has EDID EEPROM but the
>> panel driver knows. So why we need to make display controller queries
>> EDID blindly? Since panel driver knows about all "video modes/panel
>> size" stuffs, why not we let it handle all these things?
>
> The DC actually does know whether the connected panel supports EDID -
> in this case, the output node will have a property for the DDC bus,
> e.g.
>
> nvidia,ddc-i2c-bus = <&lcd_ddc>;
>
> If no DDC bus is specified or if transfer fails, the DC driver can
> still query the panel driver for hardcoded modes.
>
Strictly speaking, according to my understanding, "nvidia,ddc-i2c-bus"
means tegra has a hardware ddc channel, this doesn't mean we can get the
EDID from this DDC surely.
> Also passing a function pointer to get_modes() does not relief the DC
> driver from probing for the DDC bus. You will still have to handle
> both conditions (DDC bus present or not), the check will just be moved
> into your callback function.
>
Yes. But panel driver decides whether the DDC probing is needed. If the
panel has an EEPROM, it can call the function which display controller
provides to do a DDC probing, it not, panel driver just ignores this
function pointer and return the hardcoded modes directly.
> Alex.
>
^ permalink raw reply
* Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
From: Alexandre Courbot @ 2013-01-31 6:36 UTC (permalink / raw)
To: Mark Zhang
Cc: Stephen Warren, Laurent Pinchart, Thierry Reding, Mark Zhang,
Linux Kernel Mailing List, linux-fbdev@vger.kernel.org,
linux-tegra@vger.kernel.org, acourbot@nvidia.com
In-Reply-To: <5109F916.8080404@gmail.com>
On Thu, Jan 31, 2013 at 1:54 PM, Mark Zhang <nvmarkzhang@gmail.com> wrote:
> Display controller don't know whether the panel has EDID EEPROM but the
> panel driver knows. So why we need to make display controller queries
> EDID blindly? Since panel driver knows about all "video modes/panel
> size" stuffs, why not we let it handle all these things?
The DC actually does know whether the connected panel supports EDID -
in this case, the output node will have a property for the DDC bus,
e.g.
nvidia,ddc-i2c-bus = <&lcd_ddc>;
If no DDC bus is specified or if transfer fails, the DC driver can
still query the panel driver for hardcoded modes.
Also passing a function pointer to get_modes() does not relief the DC
driver from probing for the DDC bus. You will still have to handle
both conditions (DDC bus present or not), the check will just be moved
into your callback function.
Alex.
^ permalink raw reply
* Re: BUG: circular locking dependency detected
From: Greg Kroah-Hartman @ 2013-01-31 5:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: Russell King, Dave Airlie, Daniel Vetter, Andrew Morton,
Florian Tobias Schandinat, linux-fbdev@vger.kernel.org,
Linux Kernel Mailing List, dri-devel
In-Reply-To: <CA+55aFxfeXWAiXV18qGgOk9+2HHiD7LUuyk55brHFXd+_c6eZQ@mail.gmail.com>
On Thu, Jan 31, 2013 at 11:26:53AM +1100, Linus Torvalds wrote:
> On Thu, Jan 31, 2013 at 11:13 AM, Russell King <rmk@arm.linux.org.uk> wrote:
> >
> > Which may or may not be a good thing depending how you look at it; it
> > means that once your kernel blanks, you get a lockdep dump. At that
> > point you lose lockdep checking for everything else because lockdep
> > disables itself after the first dump.
>
> Fair enough, we may want to revert the lockdep checking for
> console_lock, and make re-enabling it part of the patch-series that
> fixes the locking.
>
> Daniel/Dave? Does that sound reasonable?
Reverting the patch is fine with me. Just let me know so I can queue it
up again for 3.9.
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
From: Mark Zhang @ 2013-01-31 4:54 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Stephen Warren, Laurent Pinchart, Thierry Reding, Mark Zhang,
Linux Kernel Mailing List, linux-fbdev@vger.kernel.org,
linux-tegra@vger.kernel.org
In-Reply-To: <CAAVeFuJf9Ww7g8Q9RAG9Na1SZq2-n2MMxcAEBek52ZVG7RpL7g@mail.gmail.com>
On 01/31/2013 12:24 PM, Alexandre Courbot wrote:
> On Thu, Jan 31, 2013 at 12:51 PM, Mark Zhang <nvmarkzhang@gmail.com> wrote:
>>> DDC access is a property of the display controller, not the panel
>>> itself. The panel might be hooked up to a display controller's DDC/I2C
>>> channel as the target, but it isn't the host/controller of the DDC/I2C
>>> channel. As such, placing the nvidia,ddc property into the display
>>> controller node makes sense.
>>>
>>
>> Yes, DC triggers the DDC access and is the host of the DDC/I2C channel.
>> So I think it's reasonable to put nvidia,ddc property into the display
>> controller node. But the video mode info in EDID which be fetched via
>> DDC is the property of the panel, so this info should be provided by
>> panel driver. Actually display controller cares about the video modes,
>> not the way to get these info. So I think it's better to do the whole
>> work like this:
>>
>> 1) display controller relied on CDF to call "display_entity_get_modes"
>> 2) panel driver calls the function which is hooked to display controller
>> to get the video modes via DDC.
>> 3) if the video modes can't be fetched via DDC, panel driver provides
>> the info(either by hard-coded or defined in DT) anyway
>
> This would require a callback dedicated to this in display_entity and
> would break its simple design.
We just need to add a function pointer param which can be used by panel
driver in "display_entity_get_modes", don't we?
>
>> Just like I said above, display controller should not query DDC
>> directly. Since CDF already defines these for us, display controller
>> should call CDF's functions, like: display_entity_get_modes,
>> display_entity_get_size... I think this is the key difference I wanna
>> talk about. And also in this way, display controller doesn't need to
>> care about this 2 steps logics, just call "display_entity_get_modes" is OK.
>
> Well the fact is that it *is* the display controller that queries DDC
> directly. The panel is just a bus here, and the EDID EEPROM could
> perfectly work without it. If you model what you described with DT
> nodes, I'm afraid you will end up with something both complex (with DC
> node referencing panel node and back again for the EDID bus) and that
> does not picture reality accurately.
Display controller don't know whether the panel has EDID EEPROM but the
panel driver knows. So why we need to make display controller queries
EDID blindly? Since panel driver knows about all "video modes/panel
size" stuffs, why not we let it handle all these things?
>
> Alex.
>
^ permalink raw reply
* Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
From: Alexandre Courbot @ 2013-01-31 4:24 UTC (permalink / raw)
To: Mark Zhang
Cc: Stephen Warren, Laurent Pinchart, Thierry Reding, Mark Zhang,
Linux Kernel Mailing List,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Alexandre Courbot
In-Reply-To: <5109EA2A.8020204-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Jan 31, 2013 at 12:51 PM, Mark Zhang <nvmarkzhang@gmail.com> wrote:
>> DDC access is a property of the display controller, not the panel
>> itself. The panel might be hooked up to a display controller's DDC/I2C
>> channel as the target, but it isn't the host/controller of the DDC/I2C
>> channel. As such, placing the nvidia,ddc property into the display
>> controller node makes sense.
>>
>
> Yes, DC triggers the DDC access and is the host of the DDC/I2C channel.
> So I think it's reasonable to put nvidia,ddc property into the display
> controller node. But the video mode info in EDID which be fetched via
> DDC is the property of the panel, so this info should be provided by
> panel driver. Actually display controller cares about the video modes,
> not the way to get these info. So I think it's better to do the whole
> work like this:
>
> 1) display controller relied on CDF to call "display_entity_get_modes"
> 2) panel driver calls the function which is hooked to display controller
> to get the video modes via DDC.
> 3) if the video modes can't be fetched via DDC, panel driver provides
> the info(either by hard-coded or defined in DT) anyway
This would require a callback dedicated to this in display_entity and
would break its simple design.
> Just like I said above, display controller should not query DDC
> directly. Since CDF already defines these for us, display controller
> should call CDF's functions, like: display_entity_get_modes,
> display_entity_get_size... I think this is the key difference I wanna
> talk about. And also in this way, display controller doesn't need to
> care about this 2 steps logics, just call "display_entity_get_modes" is OK.
Well the fact is that it *is* the display controller that queries DDC
directly. The panel is just a bus here, and the EDID EEPROM could
perfectly work without it. If you model what you described with DT
nodes, I'm afraid you will end up with something both complex (with DC
node referencing panel node and back again for the EDID bus) and that
does not picture reality accurately.
Alex.
^ permalink raw reply
* Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
From: Alexandre Courbot @ 2013-01-31 4:14 UTC (permalink / raw)
To: Stephen Warren
Cc: Laurent Pinchart, Thierry Reding, Mark Zhang,
Linux Kernel Mailing List,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Alexandre Courbot
In-Reply-To: <51098229.7080508-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
On Thu, Jan 31, 2013 at 5:27 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> So this looks like a reasonable binding to me. The one issue is that
> it's very generic, and if we go this route, we'll probably end up with
> tens or hundreds of identical or extremely similar simple bindings, and
> associated drivers.
>
> We can avoid this instead by defining something like a "simple-lcd"
> binding, and associated driver, that will work for perhaps 90%, 95%,
> 99%, even 100%(?) of panels.
That seems totally doable indeed. Actually the right way to do this
might be by extending the simple DPI panel driver Laurent included in
his patchset.
> Just like the above, but with:
>
> compatible="simple-panel", "chunghwa,claa101wa01a"
>
> instead, and the driver binding to "simple-panel" rather than
> "chunghwa,claa101wa01a".
Just out of curiosity, why don't we rather define
compatible="chunghwa,claa101wa01a", "simple-panel"
in that order? I thought DT compatible strings should go from more to
less specific. The device would still bind to "simple-panel" if no
more specific driver exists.
> The driver can assume that a specific set of supplies (and perhaps
> GPIOs) is always present, and that the /sequence/ of manipulating those
> is fixed. This will avoid the need for anything like the power sequences
> code. If a particular panel doesn't fit those assumptions, including the
> exact sequence of manipulations for each state transition (which should
> be documented in the binding) then it can get a custom driver, this also
> avoiding having to define custom sequences in DT.
>
> Things that might be parameterized/optional:
>
> * Perhaps some GPIOs aren't always present.
> * If some regulators aren't SW-controllable, DT should still provide a
> fixed/dummy regulator so the driver doesn't care.
How about making all regulators and GPIO optional in the driver?
> * Wait times between regulator/GPIO/... manipulation could be specified
> in DT.
> * For panels without EDID, CDF DT bindings can provide the list of
> supported modes, otherwise we assume that the display controller that
> drives the panel has been told how to access the EDID, just like it
> would for an "external" display.
Excellent. Thanks for the feedback.
Alex.
^ permalink raw reply
* Re: [RFC 1/4] video: panel: add CLAA101WA01A panel support
From: Mark Zhang @ 2013-01-31 3:51 UTC (permalink / raw)
To: Stephen Warren
Cc: Alexandre Courbot, Laurent Pinchart, Thierry Reding, Mark Zhang,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, gnurou-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <51098064.7030902-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
On 01/31/2013 04:19 AM, Stephen Warren wrote:
> On 01/30/2013 12:20 AM, Mark Zhang wrote:
>> On 01/30/2013 11:02 AM, Alexandre Courbot wrote:
>>> Add support for the Chunghwa CLAA101WA01A display panel.
>
>>> +static int panel_claa101_get_modes(struct display_entity *entity,
>>> + const struct videomode **modes)
>>> +{
>>> + /* TODO get modes from EDID? */
>>
>> Why not move the "nvidia,ddc" from encoder's DT to panel's DT? In that
>> case, you can get EDID here. I know drm has some helpers to fetch EDID
>> but I recall there are some other functions which has no drm
>> dependencies which may be suitable for you.
>
> DDC access is a property of the display controller, not the panel
> itself. The panel might be hooked up to a display controller's DDC/I2C
> channel as the target, but it isn't the host/controller of the DDC/I2C
> channel. As such, placing the nvidia,ddc property into the display
> controller node makes sense.
>
Yes, DC triggers the DDC access and is the host of the DDC/I2C channel.
So I think it's reasonable to put nvidia,ddc property into the display
controller node. But the video mode info in EDID which be fetched via
DDC is the property of the panel, so this info should be provided by
panel driver. Actually display controller cares about the video modes,
not the way to get these info. So I think it's better to do the whole
work like this:
1) display controller relied on CDF to call "display_entity_get_modes"
2) panel driver calls the function which is hooked to display controller
to get the video modes via DDC.
3) if the video modes can't be fetched via DDC, panel driver provides
the info(either by hard-coded or defined in DT) anyway
> Re: the other discussion in this thread: Probably the simplest is if
> tegradrm/other-CDF-users do something like:
>
> 1) If DDC I2C channel available for this display channel, query DDC.
Just like I said above, display controller should not query DDC
directly. Since CDF already defines these for us, display controller
should call CDF's functions, like: display_entity_get_modes,
display_entity_get_size... I think this is the key difference I wanna
talk about. And also in this way, display controller doesn't need to
care about this 2 steps logics, just call "display_entity_get_modes" is OK.
Mark
> 2) If not, or perhaps also if that fails, query the panel driver for the
> mode list.
>
> That would cover all bases very simply.
>
^ permalink raw reply
* Re: BUG: circular locking dependency detected
From: Linus Torvalds @ 2013-01-31 0:26 UTC (permalink / raw)
To: Russell King
Cc: Dave Airlie, Daniel Vetter, Andrew Morton,
Florian Tobias Schandinat, linux-fbdev@vger.kernel.org,
Linux Kernel Mailing List, Greg Kroah-Hartman, dri-devel
In-Reply-To: <20130131001339.GC14801@flint.arm.linux.org.uk>
On Thu, Jan 31, 2013 at 11:13 AM, Russell King <rmk@arm.linux.org.uk> wrote:
>
> Which may or may not be a good thing depending how you look at it; it
> means that once your kernel blanks, you get a lockdep dump. At that
> point you lose lockdep checking for everything else because lockdep
> disables itself after the first dump.
Fair enough, we may want to revert the lockdep checking for
console_lock, and make re-enabling it part of the patch-series that
fixes the locking.
Daniel/Dave? Does that sound reasonable?
Linus
^ permalink raw reply
* Re: BUG: circular locking dependency detected
From: Russell King @ 2013-01-31 0:13 UTC (permalink / raw)
To: Dave Airlie
Cc: Linus Torvalds, Daniel Vetter, Andrew Morton,
Florian Tobias Schandinat, linux-fbdev@vger.kernel.org,
Linux Kernel Mailing List, Greg Kroah-Hartman, dri-devel
In-Reply-To: <CAPM=9tz6YBh2o3T8Ogt4K=wxSrC3Jc4PCJMzfpbyY=B132fA5g@mail.gmail.com>
On Thu, Jan 31, 2013 at 10:04:05AM +1000, Dave Airlie wrote:
> On Thu, Jan 31, 2013 at 9:52 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Thu, Jan 31, 2013 at 9:19 AM, Russell King <rmk@arm.linux.org.uk> wrote:
> >>
> >> So... what you seem to be telling me is that 3.9 is going to be a
> >> release which issues lockdep complaints when the console blanks, and
> >> you think that's acceptable?
> >>
> >> Adding Linus and Andrew so they're aware of this issue...
> >
> > Oh, we're extremely aware of it. And it's not a new issue, the locking
> > problem have apparently been around forever, although I'm not sure why
> > the lockdep splat itself started happening only recently.
> >
> > They'll make it into 3.9, it's 3.8 that won't have them. The patches
> > initially caused way *worse* behavior than just a lockdep splat - they
> > caused actual hard lockups (and that was *after* the initial series of
> > fixes). That got fixed (hopefully for the last case!) fairly recently,
> > and I'm not willing to take the scary patch-series that has had
> > several problem cases.
>
> Well we didn't have any lock validation support before Daniel added it
> a couple of kernels back,
> so instead of hidden locking problems we've had from time began, we now have
> lockdep detectable locking problems.
Which may or may not be a good thing depending how you look at it; it
means that once your kernel blanks, you get a lockdep dump. At that
point you lose lockdep checking for everything else because lockdep
disables itself after the first dump.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ 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