* 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: 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: 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: 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: [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: 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: 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 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: 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: 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
* [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: [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
* 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: 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 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: [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: 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: 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: [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: [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: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: Mark Zhang @ 2013-02-01 4:19 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: <510AA7F8.7070000-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
On 02/01/2013 01:20 AM, Stephen Warren wrote:
> 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.
>
Ah, yes, this is right. We can't write driver for every external monitor
which implements EDID. Although I think it's more reasonable that panel
decides whether the DDC probe is necessary.
> 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: [PATCH v16 RESEND 0/7] of: add display helper
From: Jingoo Han @ 2013-02-01 7:40 UTC (permalink / raw)
To: Steffen Trumtrar
Cc: Rob Clark, linux-fbdev@vger.kernel.org, Mohammed, Afzal,
Stephen Warren, devicetree-discuss@lists.ozlabs.org,
Florian Tobias Schandinat, dri-devel@lists.freedesktop.org,
Tomi Valkeinen, Rob Herring, Laurent Pinchart,
kernel@pengutronix.de, Guennady Liakhovetski,
linux-media@vger.kernel.org, Jingoo Han
In-Reply-To: <1358766482-6275-1-git-send-email-s.trumtrar@pengutronix.de>
SGkgU3RlZmZlbiwNCg0KWW91IGNhbiBhZGQgbXkgdGVzdGVkLWJ5IGZvciB0aGlzIHNlcmllcy4N
CkkgaGF2ZSB0ZXN0ZWQgdGhlbSBmb3IgRXh5bm9zOiBzbWRrNDIxMCBib2FyZC4NCg0KQmVhdCBy
ZWdhcmRzLA0KSmluZ29vIEhhbg0KDQpPbiBXZWRuZXNkYXksIEphbnVhcnkgMjMsIDIwMTMgNjox
MiBQTSwgU3RlZmZlbiBUcnVtdHJhciB3cm90ZQ0KPiBPbiBUdWUsIEphbiAyMiwgMjAxMyBhdCAw
Mzo1MDo0OFBNIC0wNjAwLCBSb2IgQ2xhcmsgd3JvdGU6DQo+ID4gT24gTW9uLCBKYW4gMjEsIDIw
MTMgYXQgNTowNyBBTSwgU3RlZmZlbiBUcnVtdHJhcg0KPiA+IDxzLnRydW10cmFyQHBlbmd1dHJv
bml4LmRlPiB3cm90ZToNCj4gPiA+IEhpIQ0KPiA+ID4NCj4gPiA+IFRoZXJlIHdhcyBzdGlsbCBu
byBtYWludGFpbmVyLCB0aGF0IGNvbW1lbnRlZCwgYWNrJ2QsIG5hY2snZCwgYXBwbHknZCB0aGUN
Cj4gPiA+IHNlcmllcy4gU28sIHRoaXMgaXMganVzdCBhIHJlc2VuZC4NCj4gPiA+IFRoZSBwYXRj
aGVzIHdlcmUgdGVzdGVkIHdpdGg6DQo+ID4gPg0KPiA+ID4gICAgICAgICAtIHYxNSBvbiBUZWdy
YSBieSBUaGllcnJ5DQo+ID4gPiAgICAgICAgIC0gc2gtbW9iaWxlLWxjZGNmYiBieSBMYXVyZW50
DQo+ID4gPiAgICAgICAgIC0gTVg1M1FTQiBieSBNYXJlaw0KPiA+ID4gICAgICAgICAtIEV4eW5v
czogc21kazUyNTAgYnkgTGVlbGENCj4gPiA+ICAgICAgICAgLSBBTTMzNVggRVZNICYgQU0zMzVY
IEVWTS1TSyBieSBBZnphbA0KPiA+ID4gICAgICAgICAtIGlteDZxOiBzYWJyZWxpdGUsIHNhYnJl
c2QgYnkgUGhpbGlwcCBhbmQgbWUNCj4gPiA+ICAgICAgICAgLSBpbXg1MzogdHFtYTUzL21iYTUz
IGJ5IG1lDQo+ID4NCj4gPg0KPiA+IGJ0dywgeW91IGNhbiBhZGQgbXkgdGVzdGVkLWJ5IGZvciB0
aGlzIHNlcmllcy4uICBJJ3ZlIGJlZW4gdXNpbmcgdGhlbQ0KPiA+IGZvciB0aGUgdGlsY2RjIGxj
ZC1wYW5lbCBvdXRwdXQgZHJpdmVyIHN1cHBvcnQuDQo+ID4NCj4gDQo+IFRoYW5rcy4gVGhlIG1v
cmUgZHJpdmVycyB0aGUgbWVycmllciA7LSkNCj4gDQo+IFN0ZWZmZW4NCj4gDQo+ID4gPg0KPiA+
ID4NCj4gPiA+IENoYW5nZXMgc2luY2UgdjE1Og0KPiA+ID4gICAgICAgICAtIG1vdmUgaW5jbHVk
ZS9saW51eC97dmlkZW9tb2RlLGRpc3BsYXlfdGltaW5nfS5oIHRvIGluY2x1ZGUvdmlkZW8NCj4g
PiA+ICAgICAgICAgLSBtb3ZlIGluY2x1ZGUvbGludXgvb2Zfe3ZpZGVvbW9kZSxkaXNwbGF5X3Rp
bWluZ30uaCB0byBpbmNsdWRlL3ZpZGVvDQo+ID4gPiAgICAgICAgIC0gcmVpbXBsZW1lbnQgZmxh
Z3M6IGFkZCBWRVNBIGZsYWdzIGFuZCBkYXRhIGZsYWdzDQo+ID4gPiAgICAgICAgIC0gbGV0IHBp
eGVsY2xvY2sgaW4gc3RydWN0IHZpZGVvbW9kZSBiZSB1bnNpZ25lZCBsb25nDQo+ID4gPiAgICAg
ICAgIC0gcmVuYW1lIG9mX2Rpc3BsYXlfdGltaW5nc19leGlzdHMgdG8gb2ZfZGlzcGxheV90aW1p
bmdzX2V4aXN0DQo+ID4gPiAgICAgICAgIC0gcmV2aXNlIGxvZ2dpbmcvZXJyb3IgbWVzc2FnZXM6
IHJlcGxhY2UgX19mdW5jX18gd2l0aCBucC0+ZnVsbF9uYW1lDQo+ID4gPiAgICAgICAgIC0gcmVu
YW1lIHBpeGVsY2xrLWludmVydGVkIHRvIHBpeGVsY2xrLWFjdGl2ZQ0KPiA+ID4gICAgICAgICAt
IHJldmlzZSBjb21tZW50cyBpbiBjb2RlDQo+ID4gPg0KPiA+ID4gQ2hhbmdlcyBzaW5jZSB2MTQ6
DQo+ID4gPiAgICAgICAgIC0gZml4ICJjb25zdCBzdHJ1Y3QgKiIgd2FybmluZw0KPiA+ID4gICAg
ICAgICAgICAgICAgIChyZXBvcnRlZCBieTogTGVlbGEgS3Jpc2huYSBBbXVkYWxhIDxsLmtyaXNo
bmFAc2Ftc3VuZy5jb20+KQ0KPiA+ID4gICAgICAgICAtIHJldHVybiAtRUlOVkFMIHdoZW4gaHRv
dGFsIG9yIHZ0b3RhbCBhcmUgemVybw0KPiA+ID4gICAgICAgICAtIHJlbW92ZSB1bnJlYWNoYWJs
ZSBjb2RlIGluIG9mX2dldF9kaXNwbGF5X3RpbWluZ3MNCj4gPiA+ICAgICAgICAgLSBpbmNsdWRl
IGhlYWRlcnMgaW4gLmMgZmlsZXMgYW5kIG5vdCBpbXBsaWNpdCBpbiAuaA0KPiA+ID4gICAgICAg
ICAtIHNvcnQgaW5jbHVkZXMgYWxwaGFiZXRpY2FsbHkNCj4gPiA+ICAgICAgICAgLSBmaXggbG93
ZXIvdXBwZXJjYXNlIGluIGJpbmRpbmcgZG9jdW1lbnRhdGlvbg0KPiA+ID4gICAgICAgICAtIHJl
YmFzZSBvbnRvIHYzLjctcmM3DQo+ID4gPg0KPiA+ID4gQ2hhbmdlcyBzaW5jZSB2MTM6DQo+ID4g
PiAgICAgICAgIC0gZml4ICJjb25zdCBzdHJ1Y3QgKiIgd2FybmluZw0KPiA+ID4gICAgICAgICAg
ICAgICAgIChyZXBvcnRlZCBieTogTGF1cmVudCBQaW5jaGFydCA8bGF1cmVudC5waW5jaGFydEBp
ZGVhc29uYm9hcmQuY29tPikNCj4gPiA+ICAgICAgICAgLSBwcmV2ZW50IGRpdmlzaW9uIGJ5IHpl
cm8gaW4gZmJfdmlkZW9tb2RlX2Zyb21fdmlkZW9tb2RlDQo+ID4gPg0KPiA+ID4gQ2hhbmdlcyBz
aW5jZSB2MTI6DQo+ID4gPiAgICAgICAgIC0gcmVuYW1lIHN0cnVjdCBkaXNwbGF5X3RpbWluZyB0
byB2aWFfZGlzcGxheV90aW1pbmcgaW4gdmlhIHN1YnN5c3RlbQ0KPiA+ID4gICAgICAgICAtIGZp
eCByZWZyZXNocmF0ZSBjYWxjdWxhdGlvbg0KPiA+ID4gICAgICAgICAtIGZpeCAiY29uc3Qgc3Ry
dWN0ICoiIHdhcm5pbmdzDQo+ID4gPiAgICAgICAgICAgICAgICAgKHJlcG9ydGVkIGJ5OiBNYW5q
dW5hdGhhcHBhLCBQcmFrYXNoIDxwcmFrYXNoLnBtQHRpLmNvbT4pDQo+ID4gPiAgICAgICAgIC0g
c29tZSBDb2RpbmdTdHlsZSBmaXhlcw0KPiA+ID4gICAgICAgICAtIHJld3JpdGUgcGFydHMgb2Yg
Y29tbWl0IG1lc3NhZ2VzIGFuZCBkaXNwbGF5LXRpbWluZ3MudHh0DQo+ID4gPiAgICAgICAgIC0g
bGV0IGRpc3BsYXlfdGltaW5nX2dldF92YWx1ZSBnZXQgYWxsIHZhbHVlcyBpbnN0ZWFkIG9mIGp1
c3QgdHlwaWNhbA0KPiA+ID4NCj4gPiA+IENoYW5nZXMgc2luY2UgdjExOg0KPiA+ID4gICAgICAg
ICAtIG1ha2UgcG9pbnRlcnMgY29uc3Qgd2hlcmUgYXBwbGljYWJsZQ0KPiA+ID4gICAgICAgICAt
IGFkZCByZXZpZXdlZC1ieSBMYXVyZW50IFBpbmNoYXJ0DQo+ID4gPg0KPiA+ID4gQ2hhbmdlcyBz
aW5jZSB2MTA6DQo+ID4gPiAgICAgICAgIC0gZml4IGZ1bmN0aW9uIG5hbWUgKGRybV8pZGlzcGxh
eV9tb2RlX2Zyb21fdmlkZW9tb2RlDQo+ID4gPiAgICAgICAgIC0gYWRkIGFja2VkLWJ5LCByZXZp
ZXdlZC1ieSwgdGVzdGVkLWJ5DQo+ID4gPg0KPiA+ID4gQ2hhbmdlcyBzaW5jZSB2OToNCj4gPiA+
ICAgICAgICAgLSBkb24ndCBsZWFrIG1lbW9yeSB3aGVuIHByZXZpb3VzIHRpbWluZ3Mgd2VyZSBj
b3JyZWN0DQo+ID4gPiAgICAgICAgIC0gQ29kaW5nU3R5bGUgZml4ZXMNCj4gPiA+ICAgICAgICAg
LSBtb3ZlIGJsYW5rIGxpbmVzIGFyb3VuZA0KPiA+ID4NCj4gPiA+IENoYW5nZXMgc2luY2Ugdjg6
DQo+ID4gPiAgICAgICAgIC0gZml4IG1lbW9yeSBsZWFrcw0KPiA+ID4gICAgICAgICAtIGNoYW5n
ZSBBUEkgdG8gYmUgbW9yZSBjb25zaXN0ZW50IChmb29fZnJvbV9iYXIoc3RydWN0IGJhciwgc3Ry
dWN0IGZvbykpDQo+ID4gPiAgICAgICAgIC0gaW5jbHVkZSBoZWFkZXJzIHdlcmUgbmVjZXNzYXJ5
DQo+ID4gPiAgICAgICAgIC0gbWlzYyBtaW5vciBidWdmaXhlcw0KPiA+ID4NCj4gPiA+IENoYW5n
ZXMgc2luY2Ugdjc6DQo+ID4gPiAgICAgICAgIC0gbW92ZSBvZl94eHggdG8gZHJpdmVycy92aWRl
bw0KPiA+ID4gICAgICAgICAtIHJlbW92ZSBub24tYmluZGluZyBkb2N1bWVudGF0aW9uIGZyb20g
ZGlzcGxheS10aW1pbmdzLnR4dA0KPiA+ID4gICAgICAgICAtIHNxdWFzaCBkaXNwbGF5X3RpbWlu
Z3MgYW5kIHZpZGVvbW9kZSBpbiBvbmUgcGF0Y2gNCj4gPiA+ICAgICAgICAgLSBtaXNjIG1pbm9y
IGZpeGVzDQo+ID4gPg0KPiA+ID4gQ2hhbmdlcyBzaW5jZSB2NjoNCj4gPiA+ICAgICAgICAgLSBn
ZXQgcmlkIG9mIHNvbWUgZW1wdHkgbGluZXMgZXRjLg0KPiA+ID4gICAgICAgICAtIG1vdmUgZnVu
Y3Rpb25zIHRvIHRoZWlyIHN1YnN5c3RlbXMNCj4gPiA+ICAgICAgICAgLSBzcGxpdCBvZl8gZnJv
bSBub24tb2ZfIGZ1bmN0aW9ucw0KPiA+ID4gICAgICAgICAtIGFkZCBhdCBsZWFzdCBzb21lIGtl
cm5lbGRvYyB0byBzb21lIGZ1bmN0aW9ucw0KPiA+ID4NCj4gPiA+IENoYW5nZXMgc2luY2UgdjU6
DQo+ID4gPiAgICAgICAgIC0gcmVtb3ZlZCBhbGwgZGlzcGxheSBzdHVmZiBhbmQganVzdCBkZXNj
cmliZSB0aW1pbmdzDQo+ID4gPg0KPiA+ID4gQ2hhbmdlcyBzaW5jZSB2NDoNCj4gPiA+ICAgICAg
ICAgLSByZWZhY3RvcmVkIGZ1bmN0aW9ucw0KPiA+ID4NCj4gPiA+IENoYW5nZXMgc2luY2UgdjM6
DQo+ID4gPiAgICAgICAgIC0gcHJpbnQgZXJyb3IgbWVzc2FnZXMNCj4gPiA+ICAgICAgICAgLSBm
cmVlIGFsbG9jZWQgbWVtb3J5DQo+ID4gPiAgICAgICAgIC0gZ2VuZXJhbCBjbGVhbnVwDQo+ID4g
Pg0KPiA+ID4gQ2hhbmdlcyBzaW5jZSB2MjoNCj4gPiA+ICAgICAgICAgLSB1c2UgaGFyZHdhcmUt
bmVhciBwcm9wZXJ0eS1uYW1lcw0KPiA+ID4gICAgICAgICAtIHByb3ZpZGUgYSB2aWRlb21vZGUg
c3RydWN0dXJlDQo+ID4gPiAgICAgICAgIC0gYWxsb3cgcmFuZ2VzIGZvciBhbGwgcHJvcGVydGll
cyAoPG1pbix0eXAsbWF4PikNCj4gPiA+ICAgICAgICAgLSBmdW5jdGlvbnMgdG8gZ2V0IGRpc3Bs
YXlfbW9kZSBvciBmYl92aWRlb21vZGUNCj4gPiA+DQo+ID4gPg0KPiA+ID4gUmVnYXJkcywNCj4g
PiA+IFN0ZWZmZW4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gU3RlZmZlbiBUcnVtdHJhciAoNyk6DQo+
ID4gPiAgIHZpYWZiOiByZW5hbWUgZGlzcGxheV90aW1pbmcgdG8gdmlhX2Rpc3BsYXlfdGltaW5n
DQo+ID4gPiAgIHZpZGVvOiBhZGQgZGlzcGxheV90aW1pbmcgYW5kIHZpZGVvbW9kZQ0KPiA+ID4g
ICB2aWRlbzogYWRkIG9mIGhlbHBlciBmb3IgZGlzcGxheSB0aW1pbmdzL3ZpZGVvbW9kZQ0KPiA+
ID4gICBmYm1vbjogYWRkIHZpZGVvbW9kZSBoZWxwZXJzDQo+ID4gPiAgIGZibW9uOiBhZGQgb2Zf
dmlkZW9tb2RlIGhlbHBlcnMNCj4gPiA+ICAgZHJtX21vZGVzOiBhZGQgdmlkZW9tb2RlIGhlbHBl
cnMNCj4gPiA+ICAgZHJtX21vZGVzOiBhZGQgb2ZfdmlkZW9tb2RlIGhlbHBlcnMNCj4gPiA+DQo+
ID4gPiAgLi4uL2RldmljZXRyZWUvYmluZGluZ3MvdmlkZW8vZGlzcGxheS10aW1pbmcudHh0ICAg
fCAgMTA5ICsrKysrKysrKw0KPiA+ID4gIGRyaXZlcnMvZ3B1L2RybS9kcm1fbW9kZXMuYyAgICAg
ICAgICAgICAgICAgICAgICAgIHwgICA3MCArKysrKysNCj4gPiA+ICBkcml2ZXJzL3ZpZGVvL0tj
b25maWcgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMjEgKysNCj4gPiA+ICBkcml2
ZXJzL3ZpZGVvL01ha2VmaWxlICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIDQgKw0K
PiA+ID4gIGRyaXZlcnMvdmlkZW8vZGlzcGxheV90aW1pbmcuYyAgICAgICAgICAgICAgICAgICAg
IHwgICAyNCArKw0KPiA+ID4gIGRyaXZlcnMvdmlkZW8vZmJtb24uYyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwgICA5NCArKysrKysrKw0KPiA+ID4gIGRyaXZlcnMvdmlkZW8vb2ZfZGlz
cGxheV90aW1pbmcuYyAgICAgICAgICAgICAgICAgIHwgIDIzOSArKysrKysrKysrKysrKysrKysr
Kw0KPiA+ID4gIGRyaXZlcnMvdmlkZW8vb2ZfdmlkZW9tb2RlLmMgICAgICAgICAgICAgICAgICAg
ICAgIHwgICA1NCArKysrKw0KPiA+ID4gIGRyaXZlcnMvdmlkZW8vdmlhL2h3LmMgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHwgICAgNiArLQ0KPiA+ID4gIGRyaXZlcnMvdmlkZW8vdmlhL2h3
LmggICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgMiArLQ0KPiA+ID4gIGRyaXZlcnMv
dmlkZW8vdmlhL2xjZC5jICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgMiArLQ0KPiA+
ID4gIGRyaXZlcnMvdmlkZW8vdmlhL3NoYXJlLmggICAgICAgICAgICAgICAgICAgICAgICAgIHwg
ICAgMiArLQ0KPiA+ID4gIGRyaXZlcnMvdmlkZW8vdmlhL3ZpYV9tb2Rlc2V0dGluZy5jICAgICAg
ICAgICAgICAgIHwgICAgOCArLQ0KPiA+ID4gIGRyaXZlcnMvdmlkZW8vdmlhL3ZpYV9tb2Rlc2V0
dGluZy5oICAgICAgICAgICAgICAgIHwgICAgNiArLQ0KPiA+ID4gIGRyaXZlcnMvdmlkZW8vdmlk
ZW9tb2RlLmMgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAzOSArKysrDQo+ID4gPiAgaW5j
bHVkZS9kcm0vZHJtUC5oICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICA5ICsN
Cj4gPiA+ICBpbmNsdWRlL2xpbnV4L2ZiLmggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB8ICAgIDggKw0KPiA+ID4gIGluY2x1ZGUvdmlkZW8vZGlzcGxheV90aW1pbmcuaCAgICAgICAg
ICAgICAgICAgICAgIHwgIDEyNCArKysrKysrKysrDQo+ID4gPiAgaW5jbHVkZS92aWRlby9vZl9k
aXNwbGF5X3RpbWluZy5oICAgICAgICAgICAgICAgICAgfCAgIDIwICsrDQo+ID4gPiAgaW5jbHVk
ZS92aWRlby9vZl92aWRlb21vZGUuaCAgICAgICAgICAgICAgICAgICAgICAgfCAgIDE4ICsrDQo+
ID4gPiAgaW5jbHVkZS92aWRlby92aWRlb21vZGUuaCAgICAgICAgICAgICAgICAgICAgICAgICAg
fCAgIDQ4ICsrKysNCj4gPiA+ICAyMSBmaWxlcyBjaGFuZ2VkLCA4OTQgaW5zZXJ0aW9ucygrKSwg
MTMgZGVsZXRpb25zKC0pDQo+ID4gPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IERvY3VtZW50YXRpb24v
ZGV2aWNldHJlZS9iaW5kaW5ncy92aWRlby9kaXNwbGF5LXRpbWluZy50eHQNCj4gPiA+ICBjcmVh
dGUgbW9kZSAxMDA2NDQgZHJpdmVycy92aWRlby9kaXNwbGF5X3RpbWluZy5jDQo+ID4gPiAgY3Jl
YXRlIG1vZGUgMTAwNjQ0IGRyaXZlcnMvdmlkZW8vb2ZfZGlzcGxheV90aW1pbmcuYw0KPiA+ID4g
IGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2ZXJzL3ZpZGVvL29mX3ZpZGVvbW9kZS5jDQo+ID4gPiAg
Y3JlYXRlIG1vZGUgMTAwNjQ0IGRyaXZlcnMvdmlkZW8vdmlkZW9tb2RlLmMNCj4gPiA+ICBjcmVh
dGUgbW9kZSAxMDA2NDQgaW5jbHVkZS92aWRlby9kaXNwbGF5X3RpbWluZy5oDQo+ID4gPiAgY3Jl
YXRlIG1vZGUgMTAwNjQ0IGluY2x1ZGUvdmlkZW8vb2ZfZGlzcGxheV90aW1pbmcuaA0KPiA+ID4g
IGNyZWF0ZSBtb2RlIDEwMDY0NCBpbmNsdWRlL3ZpZGVvL29mX3ZpZGVvbW9kZS5oDQo+ID4gPiAg
Y3JlYXRlIG1vZGUgMTAwNjQ0IGluY2x1ZGUvdmlkZW8vdmlkZW9tb2RlLmgNCj4gPiA+DQo+ID4g
PiAtLQ0KPiA+ID4gMS43LjEwLjQNCj4gPiA+DQo+ID4NCj4gDQo
^ permalink raw reply
* Re: Revert "console: implement lockdep support for console_lock"
From: Sedat Dilek @ 2013-02-01 8:21 UTC (permalink / raw)
To: Dave Airlie; +Cc: Daniel Vetter, Linus Torvalds, linux-fbdev, LKML, linux-next
Hi Dave,
people having the fbcon-locking-fixes [1] in their local GIT tree can
revert this change?
commit ff0d05bf73620eb7dc8aee7423e992ef87870bdf
Refs: v3.8-rc5-194-gff0d05b
Author: Dave Airlie <airlied@gmail.com>
AuthorDate: Thu Jan 31 14:27:03 2013 +1100
Commit: Dave Airlie <airlied@gmail.com>
CommitDate: Thu Jan 31 15:46:56 2013 +1100
Revert "console: implement lockdep support for console_lock"
This reverts commit daee779718a319ff9f83e1ba3339334ac650bb22.
I'll requeue this after the console locking fixes, so lockdep
is useful again for people until fbcon is fixed.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Thanks!
Regards,
- Sedat
[1] http://cgit.freedesktop.org/~airlied/linux/log/?hûcon-locking-fixes
^ permalink raw reply
* Re: Revert "console: implement lockdep support for console_lock"
From: Daniel Vetter @ 2013-02-01 8:42 UTC (permalink / raw)
To: sedat.dilek; +Cc: Dave Airlie, Linus Torvalds, linux-fbdev, LKML, linux-next
In-Reply-To: <CA+icZUW5tBotrZT9QtNPao-3rEccohBW8a4diS2nJ+ONgTWLaQ@mail.gmail.com>
On Fri, Feb 1, 2013 at 9:21 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> people having the fbcon-locking-fixes [1] in their local GIT tree can
> revert this change?
Yeah, if you have all the fixes reverting this is fine and appreciated
to increase testing. Dave will probably push the revert himself to
drm-next soon.
-Daniel
>
> commit ff0d05bf73620eb7dc8aee7423e992ef87870bdf
> Refs: v3.8-rc5-194-gff0d05b
> Author: Dave Airlie <airlied@gmail.com>
> AuthorDate: Thu Jan 31 14:27:03 2013 +1100
> Commit: Dave Airlie <airlied@gmail.com>
> CommitDate: Thu Jan 31 15:46:56 2013 +1100
>
> Revert "console: implement lockdep support for console_lock"
>
> This reverts commit daee779718a319ff9f83e1ba3339334ac650bb22.
>
> I'll requeue this after the console locking fixes, so lockdep
> is useful again for people until fbcon is fixed.
>
> Signed-off-by: Dave Airlie <airlied@redhat.com>
>
> Thanks!
>
> Regards,
> - Sedat
>
> [1] http://cgit.freedesktop.org/~airlied/linux/log/?hûcon-locking-fixes
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ 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