Re: [git pull] drm tree for 3.12-rc1
On Fri, Sep 6, 2013 at 2:56 AM, Linus Torvalds wrote: > On Thu, Sep 5, 2013 at 4:19 PM, Linus Torvalds > wrote: >> >> So I've decided I'm going to try to bisect this after all. I've done >> enough pulls for today anyway, I guess. Let's see if I can bisect it >> by just trying to boot many times each try. > > Ok, it's not the recent drm pull at all. I can't find a good kernel in > the bunch - they all fail eventually. > > It may have been going in for as long as I've had this Haswell > machine, and I was just lucky (and not rebooting a lot until in the > merge window - and 4/5 boots work fine). > > It may also be user-space and have come in with the mesa update I got > through yum yesterday. So there might be multiple reasons why I saw it > today after the drm pull for the first time. > > The black screen - when it happens - happens after the fedora logo has > flashed, and gdm is supposed to start up. I tried reproducing it by > logging out and back in again (to restart X), but that doesn't do it. > Maybe timing-related with boot or just demand-loading of binaries the > first time, whatever.. Or mayby it's something special that gdm does > at startup? > Hi Linus, this _may_ be related to: https://bugzilla.redhat.com/show_bug.cgi?id=989763 I also have a 3rd gen Intel core GPU (so not HSW) which shut off the backlight while launching GDM (but for me, it happens at each boot). Using the brightness increase keyboard shortcut is enough for me to light up the backlight and see the session login. Not sure it will solve the problem, but it worth trying :) Cheers, Benjamin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Tue, 2013-09-10 at 16:53 +0300, Jani Nikula wrote: > I think the parameter "Does the ACPI backlight interface work or not" > belongs to the ACPI video driver. That depends on how Windows 8 works. If Windows 8 policy is handled by the GPU drivers then it belongs in i915. If it's handled by the ACPI code then it belongs in the ACPI code. But I have no way of determining that, whereas you work for a company that produces a Windows 8 video driver… -- Matthew Garrett ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
> On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_dma.c
>> b/drivers/gpu/drm/i915/i915_dma.c
>> index f466980..75fba17 100644
>> --- a/drivers/gpu/drm/i915/i915_dma.c
>> +++ b/drivers/gpu/drm/i915/i915_dma.c
>> @@ -1650,7 +1650,7 @@ int i915_driver_load(struct drm_device *dev, unsigned
>> long flags)
>> if (INTEL_INFO(dev)->num_pipes) {
>> /* Must be done after probing outputs */
>> intel_opregion_init(dev);
>> -acpi_video_register();
>> +__acpi_video_register(i915_take_over_backlight);
>> }
>>
>> if (IS_GEN5(dev))
>
> I can't compile:
>
>
> DEBUG: drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load':
> DEBUG: drivers/gpu/drm/i915/i915_dma.c:1661:3: error: implicit
> declaration of function
> '__acpi_video_register' [-Werror=implicit-function-declaration]
> DEBUG:__acpi_video_register(i915_take_over_backlight);
> DEBUG:^
> DEBUG: cc1: some warnings being treated as errors
> DEBUG: make[4]: *** [drivers/gpu/drm/i915/i915_dma.o] Error 1
> DEBUG: make[3]: *** [drivers/gpu/drm/i915] Error 2
> DEBUG: make[2]: *** [drivers/gpu/drm] Error 2
> DEBUG: make[1]: *** [drivers/gpu] Error 2
> DEBUG: make: *** [drivers] Error 2
>
The two patches are based on top of Rafael's linux-next tree. I just
tried it again, no compile problem for me. I also tried on today Linus'
master tree, as there are some updates from i915, two conflicts exist.
I've just resolved them and will update it in next revision.
If you want to try it now, please use:
https://github.com/aaronlu/linux acpi_video_rework
Thanks,
Aaron
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Tue, 2013-09-10 at 11:27 +0800, Aaron Lu wrote:
> On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
> > On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
> >> diff --git a/drivers/gpu/drm/i915/i915_dma.c
> >> b/drivers/gpu/drm/i915/i915_dma.c
> >> index f466980..75fba17 100644
> >> --- a/drivers/gpu/drm/i915/i915_dma.c
> >> +++ b/drivers/gpu/drm/i915/i915_dma.c
> >> @@ -1650,7 +1650,7 @@ int i915_driver_load(struct drm_device *dev,
> >> unsigned long flags)
> >>if (INTEL_INFO(dev)->num_pipes) {
> >>/* Must be done after probing outputs */
> >>intel_opregion_init(dev);
> >> - acpi_video_register();
> >> + __acpi_video_register(i915_take_over_backlight);
> >>}
> >>
> >>if (IS_GEN5(dev))
> >
> > I can't compile:
> >
> >
> > DEBUG: drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load':
> > DEBUG: drivers/gpu/drm/i915/i915_dma.c:1661:3: error: implicit
> > declaration of function
> > '__acpi_video_register' [-Werror=implicit-function-declaration]
> > DEBUG:__acpi_video_register(i915_take_over_backlight);
> > DEBUG:^
> > DEBUG: cc1: some warnings being treated as errors
> > DEBUG: make[4]: *** [drivers/gpu/drm/i915/i915_dma.o] Error 1
> > DEBUG: make[3]: *** [drivers/gpu/drm/i915] Error 2
> > DEBUG: make[2]: *** [drivers/gpu/drm] Error 2
> > DEBUG: make[1]: *** [drivers/gpu] Error 2
> > DEBUG: make: *** [drivers] Error 2
> >
>
> The two patches are based on top of Rafael's linux-next tree. I just
> tried it again, no compile problem for me. I also tried on today Linus'
> master tree, as there are some updates from i915, two conflicts exist.
> I've just resolved them and will update it in next revision.
> If you want to try it now, please use:
> https://github.com/aaronlu/linux acpi_video_rework
>
> Thanks,
> Aaron
Thanks. this patch fixes my problems w/ compilation. I've tested this
two patches and after apply I have:
$ tree /sys/class/backlight/
/sys/class/backlight/
|-- acpi_video0
-> ../../devices/pci:00/:00:02.0/backlight/acpi_video0
`-- intel_backlight
-> ../../devices/pci:00/:00:02.0/drm/card0/card0-LVDS-1/intel_backlight
2 directories, 0 files
I think it's didn't unregistered.. I may forget. I need to apply one of
patch from Matthew ?
Some strings from logs:
DMI: LENOVO 23205NG/23205NG, BIOS G2ET92WW (2.52 ) 02/22/2013
thinkpad_acpi: Standard ACPI backlight interface available, not loading
native one
--
Igor Gnatenko
Fedora release 20 (Heisenbug)
Linux 3.11.0-1.fc20.x86_64
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On 09/10/2013 01:13 PM, Igor Gnatenko wrote:
> On Tue, 2013-09-10 at 11:27 +0800, Aaron Lu wrote:
>> On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
>>> On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c
index f466980..75fba17 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1650,7 +1650,7 @@ int i915_driver_load(struct drm_device *dev,
unsigned long flags)
if (INTEL_INFO(dev)->num_pipes) {
/* Must be done after probing outputs */
intel_opregion_init(dev);
- acpi_video_register();
+ __acpi_video_register(i915_take_over_backlight);
}
if (IS_GEN5(dev))
>>>
>>> I can't compile:
>>>
>>>
>>> DEBUG: drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load':
>>> DEBUG: drivers/gpu/drm/i915/i915_dma.c:1661:3: error: implicit
>>> declaration of function
>>> '__acpi_video_register' [-Werror=implicit-function-declaration]
>>> DEBUG:__acpi_video_register(i915_take_over_backlight);
>>> DEBUG:^
>>> DEBUG: cc1: some warnings being treated as errors
>>> DEBUG: make[4]: *** [drivers/gpu/drm/i915/i915_dma.o] Error 1
>>> DEBUG: make[3]: *** [drivers/gpu/drm/i915] Error 2
>>> DEBUG: make[2]: *** [drivers/gpu/drm] Error 2
>>> DEBUG: make[1]: *** [drivers/gpu] Error 2
>>> DEBUG: make: *** [drivers] Error 2
>>>
>>
>> The two patches are based on top of Rafael's linux-next tree. I just
>> tried it again, no compile problem for me. I also tried on today Linus'
>> master tree, as there are some updates from i915, two conflicts exist.
>> I've just resolved them and will update it in next revision.
>> If you want to try it now, please use:
>> https://github.com/aaronlu/linux acpi_video_rework
>>
>> Thanks,
>> Aaron
>
> Thanks. this patch fixes my problems w/ compilation. I've tested this
> two patches and after apply I have:
> $ tree /sys/class/backlight/
> /sys/class/backlight/
> |-- acpi_video0
> -> ../../devices/pci:00/:00:02.0/backlight/acpi_video0
> `-- intel_backlight
> ->
> ../../devices/pci:00/:00:02.0/drm/card0/card0-LVDS-1/intel_backlight
>
> 2 directories, 0 files
>
> I think it's didn't unregistered.. I may forget. I need to apply one of
> patch from Matthew ?
You need to specify i915.take_over_backlight=1 in kernel cmdline, that
module option is set to false by default for now.
Thanks for the test.
-Aaron
>
> Some strings from logs:
> DMI: LENOVO 23205NG/23205NG, BIOS G2ET92WW (2.52 ) 02/22/2013
> thinkpad_acpi: Standard ACPI backlight interface available, not loading
> native one
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Tue, 2013-09-10 at 13:16 +0800, Aaron Lu wrote:
> On 09/10/2013 01:13 PM, Igor Gnatenko wrote:
> > On Tue, 2013-09-10 at 11:27 +0800, Aaron Lu wrote:
> >> On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
> >>> On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
> diff --git a/drivers/gpu/drm/i915/i915_dma.c
> b/drivers/gpu/drm/i915/i915_dma.c
> index f466980..75fba17 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1650,7 +1650,7 @@ int i915_driver_load(struct drm_device *dev,
> unsigned long flags)
> if (INTEL_INFO(dev)->num_pipes) {
> /* Must be done after probing outputs */
> intel_opregion_init(dev);
> -acpi_video_register();
> +__acpi_video_register(i915_take_over_backlight);
> }
>
> if (IS_GEN5(dev))
> >>>
> >>> I can't compile:
> >>>
> >>>
> >>> DEBUG: drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load':
> >>> DEBUG: drivers/gpu/drm/i915/i915_dma.c:1661:3: error: implicit
> >>> declaration of function
> >>> '__acpi_video_register' [-Werror=implicit-function-declaration]
> >>> DEBUG:__acpi_video_register(i915_take_over_backlight);
> >>> DEBUG:^
> >>> DEBUG: cc1: some warnings being treated as errors
> >>> DEBUG: make[4]: *** [drivers/gpu/drm/i915/i915_dma.o] Error 1
> >>> DEBUG: make[3]: *** [drivers/gpu/drm/i915] Error 2
> >>> DEBUG: make[2]: *** [drivers/gpu/drm] Error 2
> >>> DEBUG: make[1]: *** [drivers/gpu] Error 2
> >>> DEBUG: make: *** [drivers] Error 2
> >>>
> >>
> >> The two patches are based on top of Rafael's linux-next tree. I just
> >> tried it again, no compile problem for me. I also tried on today Linus'
> >> master tree, as there are some updates from i915, two conflicts exist.
> >> I've just resolved them and will update it in next revision.
> >> If you want to try it now, please use:
> >> https://github.com/aaronlu/linux acpi_video_rework
> >>
> >> Thanks,
> >> Aaron
> >
> > Thanks. this patch fixes my problems w/ compilation. I've tested this
> > two patches and after apply I have:
> > $ tree /sys/class/backlight/
> > /sys/class/backlight/
> > |-- acpi_video0
> > -> ../../devices/pci:00/:00:02.0/backlight/acpi_video0
> > `-- intel_backlight
> > ->
> > ../../devices/pci:00/:00:02.0/drm/card0/card0-LVDS-1/intel_backlight
> >
> > 2 directories, 0 files
> >
> > I think it's didn't unregistered.. I may forget. I need to apply one of
> > patch from Matthew ?
>
> You need to specify i915.take_over_backlight=1 in kernel cmdline, that
> module option is set to false by default for now.
>
> Thanks for the test.
>
> -Aaron
>
> >
> > Some strings from logs:
> > DMI: LENOVO 23205NG/23205NG, BIOS G2ET92WW (2.52 ) 02/22/2013
> > thinkpad_acpi: Standard ACPI backlight interface available, not loading
> > native one
> >
>
Thanks for quick answer. Yes. This option do unregister. Thanks. but for
this patch-set I also need "[PATCH 2/3] ACPI / video: Always call
acpi_video_init_brightness() on init" from Matthew (for notifications in
DE).
--
Igor Gnatenko
Fedora release 20 (Heisenbug)
Linux 3.11.0-1.fc20.x86_64
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] ACPI / video: seperate backlight control and event interface
On Mon, 2013-09-09 at 16:40 +0800, Aaron Lu wrote: > The backlight control and event delivery functionality provided by ACPI > video module is mixed together and registered all during video device > enumeration time. As a result, the two functionality are also removed > together on module unload time or by the acpi_video_unregister function. > The two functionalities are actually independent and one may be useful > while the other one may be broken, so it is desirable to seperate the > two functionalities such that it is clear and easy to disable one > functionality without affecting the other one. This patch does the > seperation and as a result, a new video_bus_head list is introduced to > store all registered video bus structure and a new function > acpi_video_unregister_backlight is introduced to unregister backlight > interfaces for all video devices belonging to stored video buses. > > Currently, there is no need to unregister ACPI video's event delivery > functionality alone so the function acpi_video_remove_notify_handler is > not introduced, it can be easily added when needed. > > Signed-off-by: Aaron Lu Tested-by: Igor Gnatenko > --- > drivers/acpi/video.c | 451 > ++- > include/acpi/video.h | 2 + > 2 files changed, 264 insertions(+), 189 deletions(-) -- Igor Gnatenko Fedora release 20 (Heisenbug) Linux 3.11.0-3.fc20.x86_64 -- Igor Gnatenko Fedora release 20 (Heisenbug) Linux 3.11.0-1.fc20.x86_64 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote: > According to Matthew Garrett, "Windows 8 leaves backlight control up > to individual graphics drivers rather than making ACPI calls itself. > There's plenty of evidence to suggest that the Intel driver for > Windows [8] doesn't use the ACPI interface, including the fact that > it's broken on a bunch of machines when the OS claims to support > Windows 8. The simplest thing to do appears to be to disable the > ACPI backlight interface on these systems". > > There's a problem with that approach, however, because simply > avoiding to register the ACPI backlight interface if the firmware > calls _OSI for Windows 8 may not work in the following situations: > (1) The ACPI backlight interface actually works on the given system > and the i915 driver is not loaded (e.g. another graphics driver > is used). > (2) The ACPI backlight interface doesn't work on the given system, > but there is a vendor platform driver that will register its > own, equally broken, backlight interface if not prevented from > doing so by the ACPI subsystem. > Therefore we need to allow the ACPI backlight interface to be > registered until the i915 driver is loaded which then will unregister > it if the firmware has called _OSI for Windows 8 (or will register > the ACPI video driver without backlight support if not already > present). > > For this reason, introduce an alternative function for registering > ACPI video, __acpi_video_register(bool), that if ture is passed, > will check whether or not the ACPI video driver has already been > registered and whether or not the backlight Windows 8 quirk has to > be applied. If the quirk has to be applied, it will block the ACPI > backlight support and either unregister the backlight interface if > the ACPI video driver has already been registered, or register the > ACPI video driver without the backlight interface otherwise. Make > the i915 driver use __acpi_video_register() instead of > acpi_video_register() in i915_driver_load(), and the param passed > there is controlled by the i915 module level parameter > i915_take_over_backlight, which is set to false by default. > > This change is evolved from earlier patches of Matthew Garrett, > Chun-Yi Lee and Seth Forshee and is heavily based on two patches > from Rafael: > https://lkml.org/lkml/2013/7/17/720 > https://lkml.org/lkml/2013/7/24/806 > > Signed-off-by: Aaron Lu Tested-by: Igor Gnatenko > --- > drivers/acpi/internal.h | 2 ++ > drivers/acpi/video.c| 24 > drivers/acpi/video_detect.c | 15 ++- > drivers/gpu/drm/i915/i915_dma.c | 2 +- > drivers/gpu/drm/i915/i915_drv.c | 5 + > drivers/gpu/drm/i915/i915_drv.h | 1 + > include/acpi/video.h| 9 +++-- > include/linux/acpi.h| 1 + > 8 files changed, 47 insertions(+), 12 deletions(-) -- Igor Gnatenko Fedora release 20 (Heisenbug) Linux 3.11.0-3.fc20.x86_64 -- Igor Gnatenko Fedora release 20 (Heisenbug) Linux 3.11.0-1.fc20.x86_64 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On 09/10/2013 01:22 PM, Igor Gnatenko wrote:
> On Tue, 2013-09-10 at 13:16 +0800, Aaron Lu wrote:
>> On 09/10/2013 01:13 PM, Igor Gnatenko wrote:
>>> On Tue, 2013-09-10 at 11:27 +0800, Aaron Lu wrote:
On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
> On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_dma.c
>> b/drivers/gpu/drm/i915/i915_dma.c
>> index f466980..75fba17 100644
>> --- a/drivers/gpu/drm/i915/i915_dma.c
>> +++ b/drivers/gpu/drm/i915/i915_dma.c
>> @@ -1650,7 +1650,7 @@ int i915_driver_load(struct drm_device *dev,
>> unsigned long flags)
>> if (INTEL_INFO(dev)->num_pipes) {
>> /* Must be done after probing outputs */
>> intel_opregion_init(dev);
>> -acpi_video_register();
>> +__acpi_video_register(i915_take_over_backlight);
>> }
>>
>> if (IS_GEN5(dev))
>
> I can't compile:
>
>
> DEBUG: drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load':
> DEBUG: drivers/gpu/drm/i915/i915_dma.c:1661:3: error: implicit
> declaration of function
> '__acpi_video_register' [-Werror=implicit-function-declaration]
> DEBUG:__acpi_video_register(i915_take_over_backlight);
> DEBUG:^
> DEBUG: cc1: some warnings being treated as errors
> DEBUG: make[4]: *** [drivers/gpu/drm/i915/i915_dma.o] Error 1
> DEBUG: make[3]: *** [drivers/gpu/drm/i915] Error 2
> DEBUG: make[2]: *** [drivers/gpu/drm] Error 2
> DEBUG: make[1]: *** [drivers/gpu] Error 2
> DEBUG: make: *** [drivers] Error 2
>
The two patches are based on top of Rafael's linux-next tree. I just
tried it again, no compile problem for me. I also tried on today Linus'
master tree, as there are some updates from i915, two conflicts exist.
I've just resolved them and will update it in next revision.
If you want to try it now, please use:
https://github.com/aaronlu/linux acpi_video_rework
Thanks,
Aaron
>>>
>>> Thanks. this patch fixes my problems w/ compilation. I've tested this
>>> two patches and after apply I have:
>>> $ tree /sys/class/backlight/
>>> /sys/class/backlight/
>>> |-- acpi_video0
>>> -> ../../devices/pci:00/:00:02.0/backlight/acpi_video0
>>> `-- intel_backlight
>>> ->
>>> ../../devices/pci:00/:00:02.0/drm/card0/card0-LVDS-1/intel_backlight
>>>
>>> 2 directories, 0 files
>>>
>>> I think it's didn't unregistered.. I may forget. I need to apply one of
>>> patch from Matthew ?
>>
>> You need to specify i915.take_over_backlight=1 in kernel cmdline, that
>> module option is set to false by default for now.
>>
>> Thanks for the test.
>>
>> -Aaron
>>
>>>
>>> Some strings from logs:
>>> DMI: LENOVO 23205NG/23205NG, BIOS G2ET92WW (2.52 ) 02/22/2013
>>> thinkpad_acpi: Standard ACPI backlight interface available, not loading
>>> native one
>>>
>>
>
> Thanks for quick answer. Yes. This option do unregister. Thanks. but for
> this patch-set I also need "[PATCH 2/3] ACPI / video: Always call
> acpi_video_init_brightness() on init" from Matthew (for notifications in
> DE).
That patch is reverted as it cause problem for other system:
https://bugs.freedesktop.org/show_bug.cgi?id=68355
OTOH, the thinkpad-acpi module already has a call to _BCL except that
the tpacpi_acpi_handle_locate failed to locate video controller's handle:
https://bugzilla.kernel.org/show_bug.cgi?id=51231#c121
I'll see if I can figure out why.
Thanks,
Aaron
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm intel fixes and one nouveau regression
Hi Linus, Daniel had some fixes queued up, that were delayed, the stolen memory ones and vga arbiter ones are quite useful, along with his usual bunch of stuff, nothing for HSW outputs yet, the one nouveau fix is for a regression I caused with the poweroff stuff. Dave. The following changes since commit 86a7e1224a68511d3a1ae0b7e11581b9d37723ae: Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next (2013-09-05 17:48:04 +1000) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 01172772c7c973debf5b4881fcb9463891ea97ec: drm/nouveau: fix oops on runtime suspend/resume (2013-09-10 12:38:53 +1000) Alex Williamson (3): vgaarb: Don't disable resources that are not owned vgaarb: Fix VGA decodes changes i915: Update VGA arbiter support for newer devices Chris Wilson (9): drm/i915: Adjust available RPS information through sysfs for vlv drm/i915: Apply the force-detect VGA w/a to Valleyview drm/i915: Report requested frequency alongside current frequency in debugfs drm/i915: Embed the ring->private within the struct intel_ring_buffer drm/i915: Use RCS flips on Ivybridge+ drm/i915: Pin pages whilst mapping the dma-buf drm/i915: Hold an object reference whilst we shrink it drm/i915: Skip stolen region initialisation if none is reserved drm/i915: Confine page flips to BCS on Valleyview Damien Lespiau (1): drm/i915: Don't call sg_free_table() if sg_alloc_table() fails Daniel Vetter (6): drm/i915: tune down hangcheck noise drm/i915: fix up the relocate_entry refactoring drm/i915: fix hpd work vs. flush_work in the pageflip code deadlock drm/i915: handle sdvo input pixel multiplier correctly again drm/i915: fix i9xx_crtc_clock_get for multiplied pixels drm/i915: fix gpu hang vs. flip stall deadlocks Dave Airlie (2): Merge tag 'drm-intel-fixes-2013-09-06' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes drm/nouveau: fix oops on runtime suspend/resume Imre Deak (1): drm/i915: fix lvds/dp panel fitter setting Jani Nikula (1): drm/i915: try not to lose backlight CBLV precision Jesse Barnes (2): drm/i915: split PCI IDs out into i915_drm.h v4 x86: add early quirk for reserving Intel graphics stolen memory v5 Joe Perches (1): i915_gem: Convert kmem_cache_alloc(...GFP_ZERO) to kmem_cache_zalloc Mika Kuoppala (2): drm/i915: Don't mask EI UP interrupt on IVB|SNB drm/i915: sanitize forcewake registers on reset Paulo Zanoni (1): drm/i915: enable trickle feed on Haswell Ville Syrjälä (2): drm/i915: Fix pipe config warnings when dealing with LVDS fixed mode drm/i915: Delay disabling of VGA memory until vgacon->fbcon handoff is done arch/x86/kernel/early-quirks.c | 154 + drivers/gpu/drm/i915/i915_debugfs.c| 11 +- drivers/gpu/drm/i915/i915_dma.c| 15 +- drivers/gpu/drm/i915/i915_drv.c| 164 +- drivers/gpu/drm/i915/i915_drv.h| 7 + drivers/gpu/drm/i915/i915_gem.c| 48 +-- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 41 +++--- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 + drivers/gpu/drm/i915/i915_gem_stolen.c | 3 + drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- drivers/gpu/drm/i915/i915_irq.c| 23 +++- drivers/gpu/drm/i915/i915_reg.h| 34 +++-- drivers/gpu/drm/i915/i915_sysfs.c | 36 - drivers/gpu/drm/i915/intel_crt.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 83 ++-- drivers/gpu/drm/i915/intel_drv.h | 3 +- drivers/gpu/drm/i915/intel_lvds.c | 8 +- drivers/gpu/drm/i915/intel_opregion.c | 2 +- drivers/gpu/drm/i915/intel_panel.c | 14 +- drivers/gpu/drm/i915/intel_pm.c| 14 +- drivers/gpu/drm/i915/intel_ringbuffer.c| 99 -- drivers/gpu/drm/i915/intel_ringbuffer.h| 6 +- drivers/gpu/drm/i915/intel_sdvo.c | 17 +-- drivers/gpu/drm/i915/intel_sprite.c| 7 +- drivers/gpu/drm/i915/intel_uncore.c| 9 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 9 +- drivers/gpu/vga/vgaarb.c | 51 +++ include/drm/i915_drm.h | 34 + include/drm/i915_pciids.h | 211 + include/linux/vgaarb.h | 7 + 30 files changed, 780 insertions(+), 337 deletions(-) create mode 100644 include/drm/i915_pciids.h___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Mon, Sep 09, 2013 at 11:32:10AM +0200, Daniel Vetter wrote:
> Hi Aaaron,
>
> Have we grown any clue meanwhile about which Intel boxes need this and for
> which we still need to keep the acpi backlight around? I've grown _very_
Sorry, no general rule has been found. As Rafael has said, it appears
to be random... And in addition to the "shipped with Win7 with a Win8
upgrade option" case, I also find a Sony laptop that has Win8
pre-installed and a broken ACPI video backlight interface. Its ACPI
video backlight control method is simply a stub, so even the
acpi_osi="!Windows 2012" will not provide a working backlight for this
system.
-Aaron
> reluctant to just adding tons of quirks to our driver for the backlight.
> Almost all the quirks we have added recently (or that have been proposed
> to be added) are for the backlight. Imo that indicates we get something
> fundamentally wrong ...
>
> Cheers, Daniel
>
> On Mon, Sep 09, 2013 at 04:42:20PM +0800, Aaron Lu wrote:
> > According to Matthew Garrett, "Windows 8 leaves backlight control up
> > to individual graphics drivers rather than making ACPI calls itself.
> > There's plenty of evidence to suggest that the Intel driver for
> > Windows [8] doesn't use the ACPI interface, including the fact that
> > it's broken on a bunch of machines when the OS claims to support
> > Windows 8. The simplest thing to do appears to be to disable the
> > ACPI backlight interface on these systems".
> >
> > There's a problem with that approach, however, because simply
> > avoiding to register the ACPI backlight interface if the firmware
> > calls _OSI for Windows 8 may not work in the following situations:
> > (1) The ACPI backlight interface actually works on the given system
> > and the i915 driver is not loaded (e.g. another graphics driver
> > is used).
> > (2) The ACPI backlight interface doesn't work on the given system,
> > but there is a vendor platform driver that will register its
> > own, equally broken, backlight interface if not prevented from
> > doing so by the ACPI subsystem.
> > Therefore we need to allow the ACPI backlight interface to be
> > registered until the i915 driver is loaded which then will unregister
> > it if the firmware has called _OSI for Windows 8 (or will register
> > the ACPI video driver without backlight support if not already
> > present).
> >
> > For this reason, introduce an alternative function for registering
> > ACPI video, __acpi_video_register(bool), that if ture is passed,
> > will check whether or not the ACPI video driver has already been
> > registered and whether or not the backlight Windows 8 quirk has to
> > be applied. If the quirk has to be applied, it will block the ACPI
> > backlight support and either unregister the backlight interface if
> > the ACPI video driver has already been registered, or register the
> > ACPI video driver without the backlight interface otherwise. Make
> > the i915 driver use __acpi_video_register() instead of
> > acpi_video_register() in i915_driver_load(), and the param passed
> > there is controlled by the i915 module level parameter
> > i915_take_over_backlight, which is set to false by default.
> >
> > This change is evolved from earlier patches of Matthew Garrett,
> > Chun-Yi Lee and Seth Forshee and is heavily based on two patches
> > from Rafael:
> > https://lkml.org/lkml/2013/7/17/720
> > https://lkml.org/lkml/2013/7/24/806
> >
> > Signed-off-by: Aaron Lu
> > ---
> > drivers/acpi/internal.h | 2 ++
> > drivers/acpi/video.c| 24
> > drivers/acpi/video_detect.c | 15 ++-
> > drivers/gpu/drm/i915/i915_dma.c | 2 +-
> > drivers/gpu/drm/i915/i915_drv.c | 5 +
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > include/acpi/video.h| 9 +++--
> > include/linux/acpi.h| 1 +
> > 8 files changed, 47 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> > index 20f4233..a53832e 100644
> > --- a/drivers/acpi/internal.h
> > +++ b/drivers/acpi/internal.h
> > @@ -170,8 +170,10 @@ int acpi_create_platform_device(struct acpi_device
> > *adev,
> >
> > --
> > */
> > #if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE)
> > bool acpi_video_backlight_quirks(void);
> > +bool acpi_video_verify_backlight_support(void);
> > #else
> > static inline bool acpi_video_backlight_quirks(void) { return false; }
> > +static inline bool acpi_video_verify_backlight_support(void) { return
> > false; }
> > #endif
> >
> > #endif /* _ACPI_INTERNAL_H_ */
> > diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
> > index 5ad5a71..cc709a7 100644
> > --- a/drivers/acpi/video.c
> > +++ b/drivers/acpi/video.c
> > @@ -1256,8 +1256,8 @@ acpi_video_switch_brightness(struct acpi_video_device
> > *device, int event)
> > unsigned long long level_curr
[PATCH 1/2] drm/radeon: simplify driver data retrieval
You can get the driver data from struct device directly, there's no
need to get the PCI device first.
Signed-off-by: Jean Delvare
Cc: David Airlie
Cc: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_pm.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
--- linux-3.11-rc7.orig/drivers/gpu/drm/radeon/radeon_pm.c 2013-09-02
22:06:28.569606289 +0200
+++ linux-3.11-rc7/drivers/gpu/drm/radeon/radeon_pm.c 2013-09-03
09:20:41.850518596 +0200
@@ -333,7 +333,7 @@ static ssize_t radeon_get_pm_profile(str
struct device_attribute *attr,
char *buf)
{
- struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
+ struct drm_device *ddev = dev_get_drvdata(dev);
struct radeon_device *rdev = ddev->dev_private;
int cp = rdev->pm.profile;
@@ -349,7 +349,7 @@ static ssize_t radeon_set_pm_profile(str
const char *buf,
size_t count)
{
- struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
+ struct drm_device *ddev = dev_get_drvdata(dev);
struct radeon_device *rdev = ddev->dev_private;
mutex_lock(&rdev->pm.mutex);
@@ -383,7 +383,7 @@ static ssize_t radeon_get_pm_method(stru
struct device_attribute *attr,
char *buf)
{
- struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
+ struct drm_device *ddev = dev_get_drvdata(dev);
struct radeon_device *rdev = ddev->dev_private;
int pm = rdev->pm.pm_method;
@@ -397,7 +397,7 @@ static ssize_t radeon_set_pm_method(stru
const char *buf,
size_t count)
{
- struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
+ struct drm_device *ddev = dev_get_drvdata(dev);
struct radeon_device *rdev = ddev->dev_private;
/* we don't support the legacy modes with dpm */
@@ -433,7 +433,7 @@ static ssize_t radeon_get_dpm_state(stru
struct device_attribute *attr,
char *buf)
{
- struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
+ struct drm_device *ddev = dev_get_drvdata(dev);
struct radeon_device *rdev = ddev->dev_private;
enum radeon_pm_state_type pm = rdev->pm.dpm.user_state;
@@ -447,7 +447,7 @@ static ssize_t radeon_set_dpm_state(stru
const char *buf,
size_t count)
{
- struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
+ struct drm_device *ddev = dev_get_drvdata(dev);
struct radeon_device *rdev = ddev->dev_private;
mutex_lock(&rdev->pm.mutex);
@@ -472,7 +472,7 @@ static ssize_t radeon_get_dpm_forced_per
struct device_attribute
*attr,
char *buf)
{
- struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
+ struct drm_device *ddev = dev_get_drvdata(dev);
struct radeon_device *rdev = ddev->dev_private;
enum radeon_dpm_forced_level level = rdev->pm.dpm.forced_level;
@@ -486,7 +486,7 @@ static ssize_t radeon_set_dpm_forced_per
const char *buf,
size_t count)
{
- struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
+ struct drm_device *ddev = dev_get_drvdata(dev);
struct radeon_device *rdev = ddev->dev_private;
enum radeon_dpm_forced_level level;
int ret = 0;
@@ -524,7 +524,7 @@ static ssize_t radeon_hwmon_show_temp(st
struct device_attribute *attr,
char *buf)
{
- struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
+ struct drm_device *ddev = dev_get_drvdata(dev);
struct radeon_device *rdev = ddev->dev_private;
int temp;
--
Jean Delvare
Suse L3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/radeon: expose DPM thermal thresholds through sysfs
The hwmon sysfs interface allows exposing temperature limits. The "max"
and "min" thresholds will be exposed as a critical high limit and its
hysteresis value, respectively. This gives the user a better idea of how
well cooling is doing and whether it is sufficient.
Signed-off-by: Jean Delvare
Cc: David Airlie
Cc: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_pm.c | 38 +
1 file changed, 38 insertions(+)
--- linux-3.11-rc7.orig/drivers/gpu/drm/radeon/radeon_pm.c 2013-09-03
09:20:41.850518596 +0200
+++ linux-3.11-rc7/drivers/gpu/drm/radeon/radeon_pm.c 2013-09-03
09:26:03.630852919 +0200
@@ -536,6 +536,23 @@ static ssize_t radeon_hwmon_show_temp(st
return snprintf(buf, PAGE_SIZE, "%d\n", temp);
}
+static ssize_t radeon_hwmon_show_temp_thresh(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+ struct drm_device *ddev = dev_get_drvdata(dev);
+ struct radeon_device *rdev = ddev->dev_private;
+ int hyst = to_sensor_dev_attr(attr)->index;
+ int temp;
+
+ if (hyst)
+ temp = rdev->pm.dpm.thermal.min_temp;
+ else
+ temp = rdev->pm.dpm.thermal.max_temp;
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", temp);
+}
+
static ssize_t radeon_hwmon_show_name(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -544,16 +561,37 @@ static ssize_t radeon_hwmon_show_name(st
}
static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, radeon_hwmon_show_temp, NULL,
0);
+static SENSOR_DEVICE_ATTR(temp1_crit, S_IRUGO, radeon_hwmon_show_temp_thresh,
NULL, 0);
+static SENSOR_DEVICE_ATTR(temp1_crit_hyst, S_IRUGO,
radeon_hwmon_show_temp_thresh, NULL, 1);
static SENSOR_DEVICE_ATTR(name, S_IRUGO, radeon_hwmon_show_name, NULL, 0);
static struct attribute *hwmon_attributes[] = {
&sensor_dev_attr_temp1_input.dev_attr.attr,
+ &sensor_dev_attr_temp1_crit.dev_attr.attr,
+ &sensor_dev_attr_temp1_crit_hyst.dev_attr.attr,
&sensor_dev_attr_name.dev_attr.attr,
NULL
};
+static umode_t hwmon_attributes_visible(struct kobject *kobj,
+ struct attribute *attr, int index)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct drm_device *ddev = dev_get_drvdata(dev);
+ struct radeon_device *rdev = ddev->dev_private;
+
+ /* Skip limit attributes if DPM is not enabled */
+ if (rdev->pm.pm_method != PM_METHOD_DPM &&
+ (attr == &sensor_dev_attr_temp1_crit.dev_attr.attr ||
+attr == &sensor_dev_attr_temp1_crit_hyst.dev_attr.attr))
+ return 0;
+
+ return attr->mode;
+}
+
static const struct attribute_group hwmon_attrgroup = {
.attrs = hwmon_attributes,
+ .is_visible = hwmon_attributes_visible,
};
static int radeon_hwmon_init(struct radeon_device *rdev)
--
Jean Delvare
Suse L3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Tue, 2013-09-10 at 17:21 +0300, Jani Nikula wrote: > On Tue, 10 Sep 2013, Matthew Garrett wrote: > > On Tue, 2013-09-10 at 16:53 +0300, Jani Nikula wrote: > > > >> I think the parameter "Does the ACPI backlight interface work or not" > >> belongs to the ACPI video driver. > > > > That depends on how Windows 8 works. If Windows 8 policy is handled by > > the GPU drivers then it belongs in i915. If it's handled by the ACPI > > code then it belongs in the ACPI code. > > I fail to see the logic. Windows 8 policy dictates whether we can use > the AML code or not. IMHO, ACPI code is in the best position to figure > this out and quirk as necessary. It's the part that knows about Windows > 8, not i915. So if nvidia hardware uses the ACPI interface and Intel doesn't, we should still quirk it in the ACPI driver? -- Matthew Garrett ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/radeon kexec fixes
Alex Deucher writes: > On Mon, Sep 9, 2013 at 5:21 AM, Markus Trippelsdorf > wrote: > >> IIRC Alex said the sanity checks are expensive and boot-time could be >> improved by dropping them. Maybe he can chime in? > > They shouldn't be necessary with a proper shutdown, but in this > particular case, they are not very expensive. What is expensive is > having a separate sanity check functions for all the various hw blocks > to teardown everything on startup prior to starting it up in case > kexec, etc. left the system in a bad state. It ends up amounting to a > full tear down sequence followed by a full start up sequence every > time you load the driver. > > I can't really comment on the first patch, but the rest seem fine. Let me reask the question just a little bit. Is it the sanity checks that are expensive? Or is it the reinitialization that is triggered by the sanity checks that is expensive? >From what Christian said in the other reply it sounds like this is a game we will never completely win, but it would be nice to have half a chance in the kexec on panic case to have video. So I am curious to know if the checks are expensive when we are coming at hardware in a clean state. Eric ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: fix return value check in ERR_PTR()
From: Wei Yongjun
In case of error, the function drm_prime_pages_to_sg() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/msm/msm_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 6b5a6c8..3462def 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -40,9 +40,9 @@ static struct page **get_pages(struct drm_gem_object *obj)
}
msm_obj->sgt = drm_prime_pages_to_sg(p, npages);
- if (!msm_obj->sgt) {
+ if (IS_ERR(msm_obj->sgt)) {
dev_err(dev->dev, "failed to allocate sgt\n");
- return ERR_PTR(-ENOMEM);
+ return ERR_CAST(msm_obj->sgt);
}
msm_obj->pages = p;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: fix return value check in lowlevel_buffer_allocate()
From: Wei Yongjun
In case of error, the function drm_prime_pages_to_sg() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/exynos/exynos_drm_buf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 3445a0f..e3ee833 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -90,9 +90,9 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
}
buf->sgt = drm_prime_pages_to_sg(buf->pages, nr_pages);
- if (!buf->sgt) {
+ if (IS_ERR(buf->sgt)) {
DRM_ERROR("failed to get sg table.\n");
- ret = -ENOMEM;
+ ret = PTR_ERR(buf->sgt);
goto err_free_attrs;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Tue, Sep 10, 2013 at 09:23:04PM +0200, Rafael J. Wysocki wrote: > On Tuesday, September 10, 2013 04:53:40 PM Jani Nikula wrote: > > On Mon, 09 Sep 2013, "Rafael J. Wysocki" wrote: > > > On Monday, September 09, 2013 05:21:18 PM Daniel Vetter wrote: > > >> On Mon, Sep 09, 2013 at 02:16:12PM +0200, Rafael J. Wysocki wrote: > > >> > Hi, > > >> > > > >> > On Monday, September 09, 2013 11:32:10 AM Daniel Vetter wrote: > > >> > > Hi Aaaron, > > >> > > > > >> > > Have we grown any clue meanwhile about which Intel boxes need this > > >> > > and for > > >> > > which we still need to keep the acpi backlight around? > > >> > > > >> > First of all, there is a bunch of boxes where ACPI backlight works > > >> > incorrectly > > >> > because of the Win8 compatibility issue. [In short, if we say we are > > >> > compatible > > >> > with Win8, the backlight AML goes into a special code path that is > > >> > broken on > > >> > those machines. Presumably Win8 uses native backlight control on them > > >> > and that > > >> > AML code path is never executed there.] The collection of machines > > >> > with this > > >> > problem appears to be kind of random (various models from various > > >> > vendors), but > > >> > I *think* they are machines that originally shipped with Win7 with a > > >> > Win8 > > >> > "upgrade" option (which in practice requires the BIOS to be updated > > >> > anyway). > > >> > > > >> > Because of that, last time we tried to switch all of the systems using > > >> > i915 > > >> > and telling the BIOS that they are compatible with Win8 over to native > > >> > backlight > > >> > control, but that didn't work for two reasons. The first reason is > > >> > that some > > >> > user space doesn't know how to use intel_backlight and needs to be > > >> > taught about > > >> > that (so some systems are just not ready for that switch). The second > > >> > and more > > >> > fundamental reason is that the native backlight control simply doesn't > > >> > work on > > >> > some machines and we don't seem to have any idea why and how to debug > > >> > this > > >> > particular problem (mostly because we don't have enough information > > >> > and we > > >> > don't know what to ask for). > > >> > > > >> > > I've grown _very_ reluctant to just adding tons of quirks to our > > >> > > driver for > > >> > > the backlight. > > >> > > > > >> > > Almost all the quirks we have added recently (or that have been > > >> > > proposed > > >> > > to be added) are for the backlight. Imo that indicates we get > > >> > > something > > >> > > fundamentally wrong ... > > >> > > > >> > This thing isn't really a quirk. It rather is an option for the users > > >> > of > > >> > the systems where ACPI backlight doesn't work to switch over to the > > >> > native > > >> > backlight control using a command line switch. This way they can at > > >> > least > > >> > *see* if the native backlight control works for them and (hopefully) > > >> > report > > >> > problems if that's not the case. This gives us a chance to get more > > >> > information about what the problem is and possibly to make some > > >> > progress > > >> > without making changes for everyone, reverting those changes when they > > >> > don't > > >> > work etc. > > >> > > > >> > An alternative for them is to pass acpi_osi="!Windows 2012" which will > > >> > probably > > >> > make the ACPI backlight work for them again, but this rather is a step > > >> > back, > > >> > because we can't possibly learn anything new from that. > > >> > > >> If Win8 is as broken as we are I'm ok with the module option. It just > > >> sounded to me like right now we don't know of a way to make all machines > > >> somewhat happy, combined with the other pile of random backlight issues > > >> the assumption that we do something (maybe something a bit racy) that > > >> windows doesn't do isn't too far-fetched. So I'm not wary of the machines > > >> where the aml is busted for acpi_os=win8, but for the others where this > > >> broke stuff. > > >> > > >> Or do I miss something here? > > > > > > The ACPI video driver doesn't do anything new now. It only does things > > > that > > > did work before we started to tell BIOSes we're compatible with Win8. The > > > reason why they don't work on some machines now is not related to whether > > > or > > > not Win8 is broken, but to what is there in the ACPI tables on those > > > machines. > > > That *is* pure garbage, but Win8 users don't see that (presumably, because > > > Win8 does't execute the AML in question). We don't see that either with > > > acpi_osi="!Windows 2012" (because then we don't execute that AML either). > > > > > > Whether or not Win8 is broken doesn't matter here. What matters is that > > > we > > > have to deal with broken AML somehow. > > > > > > One way may be to tell everyone affected by this to pass > > > acpi_osi="!Windows 2012" in the kernel command line or possibly create a > > > blacklist of those
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Wed, 11 Sep 2013, Aaron Lu wrote: > It is possible the i915 driver decides not to register a backlight > interface for the graphics card for some reason(memory allocation failed > or it knows the native control does not work on this card or whatever), > so I would prefer let i915 tell ACPI video that it has registered a > native backlight control interface as Jani has said. > > Then together with the video.use_native_backlight, we can register or > not register ACPI video backlight interface accordingly. Or rather, we > can simply not register ACPI video backlight interface for Win8 systems > as long as i915 indicates that it has native backlight control(if the > native control is broken, i915 should fix it or blacklist it so that > i915 will not indicate it has native backlight control and ACPI video > will continue to register its own). > > How does this sound? Sounds good to me. Before plunging forward, have you observed any difference between the boot modes? We have reports [1] that the backlight behaviour is different with UEFI vs. UEFI+CSM or legacy boot. So I'm wondering if the acpi_gbl_osi_data >= ACPI_OSI_WIN_8 check in patch 2/2 is the whole story. Further, if we tell the BIOS we're Windows 8 to use the tested BIOS code paths, what guarantees do we have of UEFI+CSM or legacy boots working? BR, Jani. [1] https://bugzilla.kernel.org/show_bug.cgi?id=47941#c96 -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/radeon kexec fixes
On 2013.09.10 at 16:40 -0400, Alex Deucher wrote: > On Tue, Sep 10, 2013 at 2:27 PM, Eric W. Biederman > wrote: > > Alex Deucher writes: > > > >> On Mon, Sep 9, 2013 at 5:21 AM, Markus Trippelsdorf > >> wrote: > >> > >>> IIRC Alex said the sanity checks are expensive and boot-time could be > >>> improved by dropping them. Maybe he can chime in? > >> > >> They shouldn't be necessary with a proper shutdown, but in this > >> particular case, they are not very expensive. What is expensive is > >> having a separate sanity check functions for all the various hw blocks > >> to teardown everything on startup prior to starting it up in case > >> kexec, etc. left the system in a bad state. It ends up amounting to a > >> full tear down sequence followed by a full start up sequence every > >> time you load the driver. > >> > >> I can't really comment on the first patch, but the rest seem fine. > > > > Let me reask the question just a little bit. > > > > Is it the sanity checks that are expensive? Or is it the > > reinitialization that is triggered by the sanity checks that is > > expensive? > > > > From what Christian said in the other reply it sounds like this is a > > game we will never completely win, but it would be nice to have half a > > chance in the kexec on panic case to have video. So I am curious to > > know if the checks are expensive when we are coming at hardware in a > > clean state. > > The particular sanity checks from this patch set are not expensive, > but we had previously discussed more extensive sanity checks for other > aspects of the chips in prior conversations. Prior to this patch set, > the hw is not torn down properly (might have been in the middle of DMA > for example) when kexec happens. That's why the sanity checks were > added in the first place. With this patch set, the sanity checks > shouldn't be necessary. I think you're talking past each other. What Eric worries about is the »kexec on panic« case, where the shutdown method *isn't* called. In this case the sanity checks, that are only superfluous when the hardware was shutdown normally during kexec (the default case), may actually help. And because the checks aren't expensive, it wouldn't hurt to just leave them in place. -- Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/radeon kexec fixes
On 2013.09.09 at 11:38 +0200, Christian König wrote:
> Am 09.09.2013 11:21, schrieb Markus Trippelsdorf:
> > On 2013.09.08 at 17:32 -0700, Eric W. Biederman wrote:
> >> Markus Trippelsdorf writes:
> >>
> >>> Here are a couple of patches that get kexec working with radeon devices.
> >>> I've tested this on my RS780.
> >>> Comments or flames are welcome.
> >>> Thanks.
> >> A couple of high level comments.
> >>
> >> This looks promising for the usual case.
> >>
> >> Removing the printk at the end of the kexec path seems a little dubious,
> >> what of other cpus, interrupt handlers, etc. Basically estabilishing a
> >> new rule on when printk is allowed seems a little dubious at this point,
> >> even if it is a useful debugging trick.
> > OK. I will drop this patch. It doesn't seem to be necessary, because I
> > cannot reproduce the printk related hang anymore.
> >
> >> Having a clean shutdown of the radeon definitely seems worth doing,
> >> because the cases where we care abouty video are when a person is in
> >> front of the system.
> > Yes. But please note that even with radeon_pci_shutdown implemented, I
> > still get ring test failures on roughly every eighth kexec boot:
> >
> > [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
> > radeon :01:05.0: disabling GPU acceleration
> >
> > That's definitely better than the current state of affairs, with ring
> > test failures on every second boot. But I haven't figured out the reason
> > for these failures yet. It's curious that once a ring test failure
> > occurs, it will reliably fail after each kexec invocation, no matter how
> > often repeated. Only a reboot brings the machine back to normal.
>
> The main problem here is that the AMD gfx hardware doesn't really
> support being reinitialized once booted (for various reasons). It's a
> (intended) limitation of the hardware design that you can only
> initialize certain blocks once every power cycle, so the whole approach
> actually will never work 100% reliable.
>
> All you can hope for is that stopping the hardware while shutting down
> the old kernel and starting it again results in exactly the same
> hardware parameters (offsets, clock etc...) otherwise starting the
> blocks will just fail and you end up with disabled acceleration like above.
>
> Sorry, but there isn't much we can do about this,
I've tested this further and it turned out that if I revert commit
f5d9b7f0f9 on top of my "drm/radeon: Implement radeon_pci_shutdown"
patch, the initialization failures seem to go away completely.
Any idea what's going on?
Here's the patch:
diff --git a/drivers/gpu/drm/radeon/r600_dpm.c
b/drivers/gpu/drm/radeon/r600_dpm.c
index fa0de46..4e8c1988 100644
--- a/drivers/gpu/drm/radeon/r600_dpm.c
+++ b/drivers/gpu/drm/radeon/r600_dpm.c
@@ -296,9 +296,9 @@ bool r600_dynamicpm_enabled(struct radeon_device *rdev)
void r600_enable_sclk_control(struct radeon_device *rdev, bool enable)
{
if (enable)
- WREG32_P(SCLK_PWRMGT_CNTL, 0, ~SCLK_PWRMGT_OFF);
+ WREG32_P(GENERAL_PWRMGT, 0, ~SCLK_PWRMGT_OFF);
else
- WREG32_P(SCLK_PWRMGT_CNTL, SCLK_PWRMGT_OFF, ~SCLK_PWRMGT_OFF);
+ WREG32_P(GENERAL_PWRMGT, SCLK_PWRMGT_OFF, ~SCLK_PWRMGT_OFF);
}
void r600_enable_mclk_control(struct radeon_device *rdev, bool enable)
--
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/radeon kexec fixes
Am 11.09.2013 11:01, schrieb Markus Trippelsdorf:
On 2013.09.09 at 11:38 +0200, Christian König wrote:
Am 09.09.2013 11:21, schrieb Markus Trippelsdorf:
On 2013.09.08 at 17:32 -0700, Eric W. Biederman wrote:
Markus Trippelsdorf writes:
Here are a couple of patches that get kexec working with radeon devices.
I've tested this on my RS780.
Comments or flames are welcome.
Thanks.
A couple of high level comments.
This looks promising for the usual case.
Removing the printk at the end of the kexec path seems a little dubious,
what of other cpus, interrupt handlers, etc. Basically estabilishing a
new rule on when printk is allowed seems a little dubious at this point,
even if it is a useful debugging trick.
OK. I will drop this patch. It doesn't seem to be necessary, because I
cannot reproduce the printk related hang anymore.
Having a clean shutdown of the radeon definitely seems worth doing,
because the cases where we care abouty video are when a person is in
front of the system.
Yes. But please note that even with radeon_pci_shutdown implemented, I
still get ring test failures on roughly every eighth kexec boot:
[drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
radeon :01:05.0: disabling GPU acceleration
That's definitely better than the current state of affairs, with ring
test failures on every second boot. But I haven't figured out the reason
for these failures yet. It's curious that once a ring test failure
occurs, it will reliably fail after each kexec invocation, no matter how
often repeated. Only a reboot brings the machine back to normal.
The main problem here is that the AMD gfx hardware doesn't really
support being reinitialized once booted (for various reasons). It's a
(intended) limitation of the hardware design that you can only
initialize certain blocks once every power cycle, so the whole approach
actually will never work 100% reliable.
All you can hope for is that stopping the hardware while shutting down
the old kernel and starting it again results in exactly the same
hardware parameters (offsets, clock etc...) otherwise starting the
blocks will just fail and you end up with disabled acceleration like above.
Sorry, but there isn't much we can do about this,
I've tested this further and it turned out that if I revert commit
f5d9b7f0f9 on top of my "drm/radeon: Implement radeon_pci_shutdown"
patch, the initialization failures seem to go away completely.
Any idea what's going on?
Well DPM is mostly Alex domain, but if I have to guess I would say that
the SCLK is gated by the hardware when the driver is unloaded and since
DPM initialized only later not ungated when the driver loads again.
Here's the patch:
diff --git a/drivers/gpu/drm/radeon/r600_dpm.c
b/drivers/gpu/drm/radeon/r600_dpm.c
index fa0de46..4e8c1988 100644
--- a/drivers/gpu/drm/radeon/r600_dpm.c
+++ b/drivers/gpu/drm/radeon/r600_dpm.c
@@ -296,9 +296,9 @@ bool r600_dynamicpm_enabled(struct radeon_device *rdev)
void r600_enable_sclk_control(struct radeon_device *rdev, bool enable)
{
if (enable)
- WREG32_P(SCLK_PWRMGT_CNTL, 0, ~SCLK_PWRMGT_OFF);
+ WREG32_P(GENERAL_PWRMGT, 0, ~SCLK_PWRMGT_OFF);
else
- WREG32_P(SCLK_PWRMGT_CNTL, SCLK_PWRMGT_OFF, ~SCLK_PWRMGT_OFF);
+ WREG32_P(GENERAL_PWRMGT, SCLK_PWRMGT_OFF, ~SCLK_PWRMGT_OFF);
}
void r600_enable_mclk_control(struct radeon_device *rdev, bool enable)
The patch just breaks SCLK gating on R6xx again, so no gain here.
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/radeon kexec fixes
Am 11.09.2013 10:53, schrieb Markus Trippelsdorf: On 2013.09.10 at 16:40 -0400, Alex Deucher wrote: On Tue, Sep 10, 2013 at 2:27 PM, Eric W. Biederman wrote: Alex Deucher writes: On Mon, Sep 9, 2013 at 5:21 AM, Markus Trippelsdorf wrote: IIRC Alex said the sanity checks are expensive and boot-time could be improved by dropping them. Maybe he can chime in? They shouldn't be necessary with a proper shutdown, but in this particular case, they are not very expensive. What is expensive is having a separate sanity check functions for all the various hw blocks to teardown everything on startup prior to starting it up in case kexec, etc. left the system in a bad state. It ends up amounting to a full tear down sequence followed by a full start up sequence every time you load the driver. I can't really comment on the first patch, but the rest seem fine. Let me reask the question just a little bit. Is it the sanity checks that are expensive? Or is it the reinitialization that is triggered by the sanity checks that is expensive? From what Christian said in the other reply it sounds like this is a game we will never completely win, but it would be nice to have half a chance in the kexec on panic case to have video. So I am curious to know if the checks are expensive when we are coming at hardware in a clean state. The particular sanity checks from this patch set are not expensive, but we had previously discussed more extensive sanity checks for other aspects of the chips in prior conversations. Prior to this patch set, the hw is not torn down properly (might have been in the middle of DMA for example) when kexec happens. That's why the sanity checks were added in the first place. With this patch set, the sanity checks shouldn't be necessary. I think you're talking past each other. What Eric worries about is the »kexec on panic« case, where the shutdown method *isn't* called. In this case the sanity checks, that are only superfluous when the hardware was shutdown normally during kexec (the default case), may actually help. And because the checks aren't expensive, it wouldn't hurt to just leave them in place. When we don't know the state the hardware is in it is really hard to get into a working configuration again, even with the sanity checks in place. For example you can't just cut power or reset the UVD block without knowing it's state, cause then you have a good chance that you hit into the middle of a register or memory access of the VCPU. This usually results in the next few registers accesses only return either 0x0 or 0x and after that the system completely locks up. Isn't it possible to know that we are in a "kexec after panic" case and only try to initialize the display hardware and not all the other blocks? That would at least allow us to get an error message of what happened on the screen and otherwise advise the user to do a clean reset. Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL
https://bugzilla.kernel.org/show_bug.cgi?id=54381 --- Comment #14 from Andrew Stubbs --- More observations: About 1 time in 3 boots the driver will fail to allocate PPLLs at all, and Ubuntu 13.10 will not start lightdm login screen. Having failed, I tend to get a run of failures, but two or three reboots is usually sufficient to get a working setup once more. There just seems to be a random factor in there somewhere. Please note: in these instances I have one monitor configured to run in a reduced resolution, so clock matching should not be a problem. I suppose it might be less problematic were I running all three screens at their preferred, default resolution. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 01/10] drm: ADV7511 i2c HDMI encoder driver
Hi Lars-Peter,
On Wednesday 04 September 2013 13:34:30 Lars-Peter Clausen wrote:
> [...]
>
> >> +
> >> +/**
> >> + * enum adv7511_input_color_depth - Selects the input format color depth
> >> + * @ADV7511_INPUT_COLOR_DEPTH_8BIT: Input format color depth is 8 bits
> >> per channel
> >> + * @ADV7511_INPUT_COLOR_DEPTH_10BIT: Input format color dpeth is 10 bits
> >> per channel
> >> + * @ADV7511_INPUT_COLOR_DEPTH_12BIT: Input format color depth is 12 bits
> >> per channel
> >> + **/
> >> +enum adv7511_input_color_depth {
> >> + ADV7511_INPUT_COLOR_DEPTH_8BIT = 3,
> >> + ADV7511_INPUT_COLOR_DEPTH_10BIT = 1,
> >> + ADV7511_INPUT_COLOR_DEPTH_12BIT = 2,
> >> +};
> >
> > Those enums describe the video format at the chip input. This can be
> > configured statically from platform data or DT, but some platforms might
> > need to setup formats dynamically at runtime. For instance the ADV7511
> > could be driven by a mux with two inputs using different formats.
> >
> > For these reasons I would combine all those enums in a single one that
> > lists all possible input formats. The formats should be standardized and
> > moved to a separate header file. Get and set format operations will be
> > needed (this is something CDF will address :-)).
>
> Since most these settings are orthogonal to each other putting them in one
> enum gives you 3 * 3 * 6 * 3 = 162 entries. These enums configure to which
> pins of the ADV7511 what signal is connected. Standardizing this would
> require that other chips use the same layouts for connecting the pins.
The problem is, this information needs to be shared between devices. Formats
on the bus could very well be dynamic, the ADV7511 video source could be able
to generate multiple formats that would be runtime configurable. To support
this, platform data and DT bindings should describe how signals are connected
(which would thus filter the list of supported formats), and a runtime API
will be needed to get and set formats. The formats thus need to be
standardized
We had a similar issue in V4L2 and have introduced a media bus format
enumeration to solve it (see include/uapi/linux/v4l2-mediabus.h). I believe
something similar is needed here.
Of course this won't solve the issue of how to select a format on the bus when
both endpoints support multiple formats. This should probably be selected by
userspace somehow, but we're missing an API to do so at the moment. A default
value would thus need to be computed somehow, and possibly given by platform
data and DT bindings (although it doesn't describe the hardware as such, and
should thus not be part of the DT bindings).
> >> +/**
> >> + * enum adv7511_up_conversion - Selects the upscaling conversion method
> >> + * @ADV7511_UP_CONVERSION_ZERO_ORDER: Use zero order up conversion
> >> + * @ADV7511_UP_CONVERSION_FIRST_ORDER: Use first order up conversion
> >> + *
> >> + * This used when converting from a 4:2:2 format to a 4:4:4 format.
> >> + **/
> >> +enum adv7511_up_conversion {
> >> +ADV7511_UP_CONVERSION_ZERO_ORDER = 0,
> >> +ADV7511_UP_CONVERSION_FIRST_ORDER = 1,
> >> +};
> >
> > How is the upscaling conversion method supposed to be selected ? What does
> > it depend on ?
>
> It's probably up to the system designer to say which method yields better
> results for their system.
And what would a system designer base his/her decision on ? :-)
> >> +/**
> >> + * struct adv7511_video_config - Describes adv7511 hardware
> >> configuration
> >> + * @csc_enable: Whether to enable color space conversion
> >> + * @csc_scaling_factor: Color space conversion scaling factor
> >> + * @csc_coefficents: Color space conversion coefficents
> >> + * @hdmi_mode:Whether to use HDMI or DVI output mode
> >> + * @avi_infoframe:HDMI infoframe
> >> + **/
> >> +struct adv7511_video_config {
> >> + bool csc_enable;
> >
> > Shouldn't this be automatically computed based on the input and output
> > formats ?
>
> If the driver knew the input and output colorspaces and had coefficient
> tables for all possible combinations built in that could be done. This is
> maybe something that could be done in the framework.
>
> >> + enum adv7511_csc_scaling csc_scaling_factor;
> >> + const uint16_t *csc_coefficents;
> >
> > Do the coefficients need to be configured freely, or could presets do ?
> >
> >> + bool hdmi_mode;
> >> + struct hdmi_avi_infoframe avi_infoframe;
> >> +};
>
> [...]
>
> >> +static void adv7511_set_config(struct drm_encoder *encoder, void *c)
> >
> > Now we're getting to the controversial point.
> >
> > What bothers me about the DRM encoder slave API is that the display
> > controller driver needs to be aware of the details of the slave encoder,
> > as it needs to pass an encoder-specific configuration structure to the
> > .set_config() operation. The question would thus be, what about using the
> > Common Display Framework ?
>
> Well, as I s
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Wed, 11 Sep 2013, Matthew Garrett wrote: > On Wed, 2013-09-11 at 11:45 +0300, Jani Nikula wrote: > >> Before plunging forward, have you observed any difference between the >> boot modes? We have reports [1] that the backlight behaviour is >> different with UEFI vs. UEFI+CSM or legacy boot. So I'm wondering if the >> acpi_gbl_osi_data >= ACPI_OSI_WIN_8 check in patch 2/2 is the whole >> story. >> >> Further, if we tell the BIOS we're Windows 8 to use the tested BIOS code >> paths, what guarantees do we have of UEFI+CSM or legacy boots working? > > We have no evidence of Windows behaving differently based on the exposed > firmware type. By "behaving differently", do you mean internally adapting to the boot mode, or exhibiting different behaviour to the user? We have evidence of the firmware behaving differently (VBT, backlight) based on the boot mode, all else being equal. We don't adapt to that, and we fail. I don't know if we should adapt, or do things differently altogether. I don't even know if Windows 8 works on all boot modes on the machines in question. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: fix error return code in omap_dmm_probe()
On Wed, Sep 11, 2013 at 7:16 AM, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fix to return -ENOMEM in the refill memory alloc error handling
> case instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun
Thanks
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> index 9b794c9..ab546c9 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> @@ -675,6 +675,7 @@ static int omap_dmm_probe(struct platform_device *dev)
> &omap_dmm->refill_pa, GFP_KERNEL);
> if (!omap_dmm->refill_va) {
> dev_err(&dev->dev, "could not allocate refill memory\n");
> + ret = -ENOMEM;
> goto fail;
> }
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 06/19] video: display: OF support
Hi Philipp,
On Wednesday 04 September 2013 16:21:38 Philipp Zabel wrote:
> Am Samstag, den 10.08.2013, 01:03 +0200 schrieb Laurent Pinchart:
> > Extend the notifier with DT node matching support, and add helper
> > functions to build the notifier and link entities based on a graph
> > representation in DT.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > drivers/video/display/display-core.c | 334 ++
> > drivers/video/display/display-notifier.c | 187 +
> > include/video/display.h | 45 +
> > 3 files changed, 566 insertions(+)
> >
> > diff --git a/drivers/video/display/display-core.c
> > b/drivers/video/display/display-core.c index c3b47d3..328ead7 100644
> > --- a/drivers/video/display/display-core.c
> > +++ b/drivers/video/display/display-core.c
>
> [...]
>
> > @@ -420,6 +599,161 @@ int display_entity_link_graph(struct device *dev,
> > struct list_head *entities)>
> > }
> > EXPORT_SYMBOL_GPL(display_entity_link_graph);
> >
> > +#ifdef CONFIG_OF
> > +
> > +static int display_of_entity_link_entity(struct device *dev,
> > +struct display_entity *entity,
> > +struct list_head *entities,
> > +struct display_entity *root)
> > +{
> > + u32 link_flags = MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED;
> > + const struct device_node *node = entity->dev->of_node;
>
> the current device tree matching implementation only allows one display
> entity per linux device. How about adding an of_node pointer to struct
> display_entity directly and allow multiple display entity nodes below in a
> single device node in the device tree?
That's a very good point. We had a similar issues in V4L2, with sensors that
would create several entities. However, in those cases, the sensors would be
connected to the rest of the pipeline through a single entity :
Sensor Entity 1 -> ... -> Sensor Entity N -> V4L2 pipeline ...
The core code thus had to care about a single sensor entity when building the
pipeline. We could solve the problem in a similar way for panels, but encoders
need a more elaborate solution.
I see (at least) two possibilities here, either explicitly describing all
entities that make the device in DT (as you have proposed below), or creating
a hierarchy of entities, with parent entities that can contain several child
entities. I've CC'ed Guennadi, Hans, Sylwester and Sakari to get their opinion
on the matter.
> lvds-encoder {
> channel@0 {
If I understand this correctly, your LVDS encoder has two independent
channels. In the general case a device made of multiple entities might have
those entities chained, so "channel" might not be the best term. "entity"
might be a better choice.
> port@0 {
> lvds0_input: endpoint {
> };
> };
> port@1 {
> lvds0_output: endpoint {
> };
> };
> };
> channel@1 {
> port@0 {
> lvds1_input: endpoint {
> };
> };
> lvds1: port@1 {
> lvds1_output: endpoint {
> };
> };
> };
> };
>
> > + struct media_entity *local = &entity->entity;
> > + struct device_node *ep = NULL;
> > + int ret = 0;
> > +
> > + dev_dbg(dev, "creating links for entity %s\n", local->name);
> > +
> > + while (1) {
> > + struct media_entity *remote = NULL;
> > + struct media_pad *remote_pad;
> > + struct media_pad *local_pad;
> > + struct display_of_link link;
> > + struct display_entity *ent;
> > + struct device_node *next;
> > +
> > + /* Get the next endpoint and parse its link. */
> > + next = display_of_get_next_endpoint(node, ep);
> > + if (next == NULL)
> > + break;
> > +
> > + of_node_put(ep);
> > + ep = next;
> > +
> > + dev_dbg(dev, "processing endpoint %s\n", ep->full_name);
> > +
> > + ret = display_of_parse_link(ep, &link);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to parse link for %s\n",
> > + ep->full_name);
> > + continue;
> > + }
> > +
> > + /* Skip source pads, they will be processed from the other end
> > of
> > +* the link.
> > +*/
> > + if (link.local_port >= local->num_pads) {
> > + dev_err(dev, "invalid port number %u on %s\n",
> > + link.local_port, link.local_node->full_name);
> > + display_of_put_link(&link);
> > + ret = -EINVAL;
> > + break;
> > + }
> > +
> > + local_pad = &local->p
[GIT PULL]: dma-buf updates for 3.12
Hi Linus, Here's the 3.12 pull request for dma-buf framework updates. Its yet another small one - dma-buf framework now supports size discovery of the buffer via llseek. Could you please pull? Thanks and best regards, ~Sumit. The following changes since commit 26b0332e30c7f93e780aaa054bd84e3437f84354: Merge tag 'dmaengine-3.12' of git:// git.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine (2013-09-09 18:07:15 -0700) are available in the git repository at: git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git tags/for-3.12 for you to fetch changes up to 19e8697ba45e7bcdb04f2adf6110fbf4882863e5: dma-buf: Expose buffer size to userspace (v2) (2013-09-10 11:36:45 +0530) dma-buf updates for 3.12 Christopher James Halse Rogers (1): dma-buf: Expose buffer size to userspace (v2) Tuomas Tynkkynen (1): dma-buf: Check return value of anon_inode_getfile Documentation/dma-buf-sharing.txt | 12 drivers/base/dma-buf.c| 32 2 files changed, 44 insertions(+) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL]: dma-buf updates for 3.12
Hi Linus. Sincere apologies for the html post; this request is now in plain-text. (it has been convenient using the gmail interface, but I promise this is the last time you'll see a non-plain-text email from me. Apologies again! Best regards, ~Sumit. On 11 September 2013 17:07, Sumit Semwal wrote: > Hi Linus, > > Here's the 3.12 pull request for dma-buf framework updates. Its yet another > small one - dma-buf framework now supports size discovery of the buffer via > llseek. > > Could you please pull? > > Thanks and best regards, > ~Sumit. > > > The following changes since commit 26b0332e30c7f93e780aaa054bd84e3437f84354: > > Merge tag 'dmaengine-3.12' of > git://git.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine (2013-09-09 > 18:07:15 -0700) > > are available in the git repository at: > > > git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git tags/for-3.12 > > for you to fetch changes up to 19e8697ba45e7bcdb04f2adf6110fbf4882863e5: > > dma-buf: Expose buffer size to userspace (v2) (2013-09-10 11:36:45 +0530) > > > dma-buf updates for 3.12 > > > Christopher James Halse Rogers (1): > dma-buf: Expose buffer size to userspace (v2) > > Tuomas Tynkkynen (1): > dma-buf: Check return value of anon_inode_getfile > > Documentation/dma-buf-sharing.txt | 12 > drivers/base/dma-buf.c| 32 > 2 files changed, 44 insertions(+) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 06/19] video: display: OF support
Am Mittwoch, den 11.09.2013, 13:33 +0200 schrieb Laurent Pinchart:
> Hi Philipp,
>
> On Wednesday 04 September 2013 16:21:38 Philipp Zabel wrote:
> > Am Samstag, den 10.08.2013, 01:03 +0200 schrieb Laurent Pinchart:
> > > Extend the notifier with DT node matching support, and add helper
> > > functions to build the notifier and link entities based on a graph
> > > representation in DT.
> > >
> > > Signed-off-by: Laurent Pinchart
> > >
> > > ---
> > >
> > > drivers/video/display/display-core.c | 334 ++
> > > drivers/video/display/display-notifier.c | 187 +
> > > include/video/display.h | 45 +
> > > 3 files changed, 566 insertions(+)
> > >
> > > diff --git a/drivers/video/display/display-core.c
> > > b/drivers/video/display/display-core.c index c3b47d3..328ead7 100644
> > > --- a/drivers/video/display/display-core.c
> > > +++ b/drivers/video/display/display-core.c
> >
> > [...]
> >
> > > @@ -420,6 +599,161 @@ int display_entity_link_graph(struct device *dev,
> > > struct list_head *entities)>
> > > }
> > > EXPORT_SYMBOL_GPL(display_entity_link_graph);
> > >
> > > +#ifdef CONFIG_OF
> > > +
> > > +static int display_of_entity_link_entity(struct device *dev,
> > > + struct display_entity *entity,
> > > + struct list_head *entities,
> > > + struct display_entity *root)
> > > +{
> > > + u32 link_flags = MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED;
> > > + const struct device_node *node = entity->dev->of_node;
> >
> > the current device tree matching implementation only allows one display
> > entity per linux device. How about adding an of_node pointer to struct
> > display_entity directly and allow multiple display entity nodes below in a
> > single device node in the device tree?
>
> That's a very good point. We had a similar issues in V4L2, with sensors that
> would create several entities. However, in those cases, the sensors would be
> connected to the rest of the pipeline through a single entity :
>
> Sensor Entity 1 -> ... -> Sensor Entity N -> V4L2 pipeline ...
>
> The core code thus had to care about a single sensor entity when building the
> pipeline. We could solve the problem in a similar way for panels, but
> encoders
> need a more elaborate solution.
>
> I see (at least) two possibilities here, either explicitly describing all
> entities that make the device in DT (as you have proposed below), or creating
> a hierarchy of entities, with parent entities that can contain several child
> entities. I've CC'ed Guennadi, Hans, Sylwester and Sakari to get their
> opinion
> on the matter.
When you say hierarchy of entities, I imagine something like GStreamer
bins? I suspect hierarchically encapsulated entities would complicate
the pipeline/graph traversal code quite a bit, although it would
probably help to organise the graph and reduce the amount of boilerplate
needed in the device tree.
> > lvds-encoder {
> > channel@0 {
>
> If I understand this correctly, your LVDS encoder has two independent
> channels.
In this example, yes. In reality the i.MX LDB has a mux in each path, so
both inputs can be routed to both outputs. With an entity hierarchy this
could be described as a single entity with two inputs and two outputs,
containing two multiplexer entites and two encoder entities.
LDB entity with two input pads, four internal entities, and two output
pads:
,.
|-. LDB ,--. ,--. ,-|
--| pad || mux0 |--| enc0 |--| pad |--
| 0 |--. ,--| | | | | 2 |
|-´ \/ `--´ `--´ `-|
|-. /\ ,--. ,--. .-|
--| pad |--´ `--| mux1 | | enc1 |--| pad |--
| 1 || |--| | | 3 |
|-´`--´ `--´ `-|
`´
(In guess the mux and enc entities could each be combined into one)
> In the general case a device made of multiple entities might have
> those entities chained, so "channel" might not be the best term.
> "entity" might be a better choice.
On the other hand, when describing subdevice entities in the device
tree, maybe the generic type of entity (sensor, scaler, encoder, mux,
etc.) would be useful information?
Another module where I'd like to describe the (outward facing) contained
entities in the device tree is the i.MX Image Processing Unit, which has
two capture interfaces and two display interfaces (all parallel). Those
can't be combined into a single entity because there are other internal
entities connected to them, and because the capture interfaces are v4l2
subdevices, whereas the display interfaces will be display entites.
Alternatively, this could also be described as a single entity
containing an internal structure.
IPU entity with two input pads, two internal capture entities (csi), two
displa
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #20 from Alex Deucher --- (In reply to comment #13) > your possible fix from Comment 10 solve it halfway or maybe fully even on > my slow Duron 1800, RV730 AGP (4650), if we separate the mosaic into a new > bug entry. That's a separate issue. Please open a different bug for that. (In reply to comment #18) > Candidate for stable? Yes, the patch will go to stable. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 Alex Deucher changed: What|Removed |Added Product|Mesa|DRI Version|9.2 |DRI CVS Component|Drivers/Gallium/r600|DRM/Radeon -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/radeon kexec fixes
On Wed, Sep 11, 2013 at 5:01 AM, Markus Trippelsdorf
wrote:
> On 2013.09.09 at 11:38 +0200, Christian König wrote:
>> Am 09.09.2013 11:21, schrieb Markus Trippelsdorf:
>> > On 2013.09.08 at 17:32 -0700, Eric W. Biederman wrote:
>> >> Markus Trippelsdorf writes:
>> >>
>> >>> Here are a couple of patches that get kexec working with radeon devices.
>> >>> I've tested this on my RS780.
>> >>> Comments or flames are welcome.
>> >>> Thanks.
>> >> A couple of high level comments.
>> >>
>> >> This looks promising for the usual case.
>> >>
>> >> Removing the printk at the end of the kexec path seems a little dubious,
>> >> what of other cpus, interrupt handlers, etc. Basically estabilishing a
>> >> new rule on when printk is allowed seems a little dubious at this point,
>> >> even if it is a useful debugging trick.
>> > OK. I will drop this patch. It doesn't seem to be necessary, because I
>> > cannot reproduce the printk related hang anymore.
>> >
>> >> Having a clean shutdown of the radeon definitely seems worth doing,
>> >> because the cases where we care abouty video are when a person is in
>> >> front of the system.
>> > Yes. But please note that even with radeon_pci_shutdown implemented, I
>> > still get ring test failures on roughly every eighth kexec boot:
>> >
>> > [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD)
>> > radeon :01:05.0: disabling GPU acceleration
>> >
>> > That's definitely better than the current state of affairs, with ring
>> > test failures on every second boot. But I haven't figured out the reason
>> > for these failures yet. It's curious that once a ring test failure
>> > occurs, it will reliably fail after each kexec invocation, no matter how
>> > often repeated. Only a reboot brings the machine back to normal.
>>
>> The main problem here is that the AMD gfx hardware doesn't really
>> support being reinitialized once booted (for various reasons). It's a
>> (intended) limitation of the hardware design that you can only
>> initialize certain blocks once every power cycle, so the whole approach
>> actually will never work 100% reliable.
>>
>> All you can hope for is that stopping the hardware while shutting down
>> the old kernel and starting it again results in exactly the same
>> hardware parameters (offsets, clock etc...) otherwise starting the
>> blocks will just fail and you end up with disabled acceleration like above.
>>
>> Sorry, but there isn't much we can do about this,
>
> I've tested this further and it turned out that if I revert commit
> f5d9b7f0f9 on top of my "drm/radeon: Implement radeon_pci_shutdown"
> patch, the initialization failures seem to go away completely.
>
> Any idea what's going on?
>
You are disabling dynamic power management with that patch reverted.
The patch fixed a copy paste typo in the register. Bit 0
(SCLK_PWRMGT_OFF) of register SCLK_PWRMGT_CNTL controls whether
dynamic engine clock control is enabled. Bit 0 (GLOBAL_PWRMGT_EN) of
register GENERAL_PWRMGT controls whether dynamic power management
(dynamic engine/memory/voltage, controls etc.) is enabled at all.
Alex
> Here's the patch:
>
> diff --git a/drivers/gpu/drm/radeon/r600_dpm.c
> b/drivers/gpu/drm/radeon/r600_dpm.c
> index fa0de46..4e8c1988 100644
> --- a/drivers/gpu/drm/radeon/r600_dpm.c
> +++ b/drivers/gpu/drm/radeon/r600_dpm.c
> @@ -296,9 +296,9 @@ bool r600_dynamicpm_enabled(struct radeon_device *rdev)
> void r600_enable_sclk_control(struct radeon_device *rdev, bool enable)
> {
> if (enable)
> - WREG32_P(SCLK_PWRMGT_CNTL, 0, ~SCLK_PWRMGT_OFF);
> + WREG32_P(GENERAL_PWRMGT, 0, ~SCLK_PWRMGT_OFF);
> else
> - WREG32_P(SCLK_PWRMGT_CNTL, SCLK_PWRMGT_OFF, ~SCLK_PWRMGT_OFF);
> + WREG32_P(GENERAL_PWRMGT, SCLK_PWRMGT_OFF, ~SCLK_PWRMGT_OFF);
> }
>
> void r600_enable_mclk_control(struct radeon_device *rdev, bool enable)
>
>
> --
> Markus
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/radeon kexec fixes
On Wed, Sep 11, 2013 at 4:53 AM, Markus Trippelsdorf wrote: > On 2013.09.10 at 16:40 -0400, Alex Deucher wrote: >> On Tue, Sep 10, 2013 at 2:27 PM, Eric W. Biederman >> wrote: >> > Alex Deucher writes: >> > >> >> On Mon, Sep 9, 2013 at 5:21 AM, Markus Trippelsdorf >> >> wrote: >> >> >> >>> IIRC Alex said the sanity checks are expensive and boot-time could be >> >>> improved by dropping them. Maybe he can chime in? >> >> >> >> They shouldn't be necessary with a proper shutdown, but in this >> >> particular case, they are not very expensive. What is expensive is >> >> having a separate sanity check functions for all the various hw blocks >> >> to teardown everything on startup prior to starting it up in case >> >> kexec, etc. left the system in a bad state. It ends up amounting to a >> >> full tear down sequence followed by a full start up sequence every >> >> time you load the driver. >> >> >> >> I can't really comment on the first patch, but the rest seem fine. >> > >> > Let me reask the question just a little bit. >> > >> > Is it the sanity checks that are expensive? Or is it the >> > reinitialization that is triggered by the sanity checks that is >> > expensive? >> > >> > From what Christian said in the other reply it sounds like this is a >> > game we will never completely win, but it would be nice to have half a >> > chance in the kexec on panic case to have video. So I am curious to >> > know if the checks are expensive when we are coming at hardware in a >> > clean state. >> >> The particular sanity checks from this patch set are not expensive, >> but we had previously discussed more extensive sanity checks for other >> aspects of the chips in prior conversations. Prior to this patch set, >> the hw is not torn down properly (might have been in the middle of DMA >> for example) when kexec happens. That's why the sanity checks were >> added in the first place. With this patch set, the sanity checks >> shouldn't be necessary. > > I think you're talking past each other. > What Eric worries about is the »kexec on panic« case, where the shutdown > method *isn't* called. In this case the sanity checks, that are only > superfluous when the hardware was shutdown normally during kexec (the > default case), may actually help. And because the checks aren't > expensive, it wouldn't hurt to just leave them in place. For the particular sanity check in this patch set, that's fine. Even with that in place, it only covers a small subset of GPUs and it doesn't cover all possible problematic areas. In general kexec on panic seems like a recipe for trouble. You may end up in the middle of several dma transactions across multiple engines on the GPU. We could add code to tear down every block on the chip on start up in case such an event happened, but like Christian said, some blocks can't really be recovered depending on how things were ended, and then we've doubled the start up time for the driver. Additionally, most of the tear down is dependent on various driver state which we wouldn't have at start up, so most of code would need to re-architected so that it could be called independently of the relevant driver state. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 06/19] video: display: OF support
On 09/11/2013 01:33 PM, Laurent Pinchart wrote:
> Hi Philipp,
>
> On Wednesday 04 September 2013 16:21:38 Philipp Zabel wrote:
>> Am Samstag, den 10.08.2013, 01:03 +0200 schrieb Laurent Pinchart:
>>> Extend the notifier with DT node matching support, and add helper
>>> functions to build the notifier and link entities based on a graph
>>> representation in DT.
>>>
>>> Signed-off-by: Laurent Pinchart
>>>
>>> ---
>>>
>>> drivers/video/display/display-core.c | 334 ++
>>> drivers/video/display/display-notifier.c | 187 +
>>> include/video/display.h | 45 +
>>> 3 files changed, 566 insertions(+)
>>>
>>> diff --git a/drivers/video/display/display-core.c
>>> b/drivers/video/display/display-core.c index c3b47d3..328ead7 100644
>>> --- a/drivers/video/display/display-core.c
>>> +++ b/drivers/video/display/display-core.c
>>
>> [...]
>>
>>> @@ -420,6 +599,161 @@ int display_entity_link_graph(struct device *dev,
>>> struct list_head *entities)>
>>> }
>>> EXPORT_SYMBOL_GPL(display_entity_link_graph);
>>>
>>> +#ifdef CONFIG_OF
>>> +
>>> +static int display_of_entity_link_entity(struct device *dev,
>>> +struct display_entity *entity,
>>> +struct list_head *entities,
>>> +struct display_entity *root)
>>> +{
>>> + u32 link_flags = MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED;
>>> + const struct device_node *node = entity->dev->of_node;
>>
>> the current device tree matching implementation only allows one display
>> entity per linux device. How about adding an of_node pointer to struct
>> display_entity directly and allow multiple display entity nodes below in a
>> single device node in the device tree?
>
> That's a very good point. We had a similar issues in V4L2, with sensors that
> would create several entities. However, in those cases, the sensors would be
> connected to the rest of the pipeline through a single entity :
>
> Sensor Entity 1 -> ... -> Sensor Entity N -> V4L2 pipeline ...
>
> The core code thus had to care about a single sensor entity when building the
> pipeline. We could solve the problem in a similar way for panels, but
> encoders
> need a more elaborate solution.
Why? Sorry, I don't see why an encoder is different in this respect than a
panel.
I'm sure I'm missing something here.
>
> I see (at least) two possibilities here, either explicitly describing all
> entities that make the device in DT (as you have proposed below), or creating
> a hierarchy of entities, with parent entities that can contain several child
> entities. I've CC'ed Guennadi, Hans, Sylwester and Sakari to get their
> opinion
> on the matter.
I think the way this is done today in complex devices is that the driver just
exposes itself as a single sub-device, but internally it has its own pipeline of
sub-devices. The only one that I know of (platform/s5p-tv/hdmi_drv) doesn't
expose
them to a media controller, they are completely hidden inside the hdmi driver.
The ability to support hierarchies of entities would be very nice. However, I
don't know how much work that would be to implement and if it is worth the
effort.
Regards,
Hans
>
>> lvds-encoder {
>> channel@0 {
>
> If I understand this correctly, your LVDS encoder has two independent
> channels. In the general case a device made of multiple entities might have
> those entities chained, so "channel" might not be the best term. "entity"
> might be a better choice.
>
>> port@0 {
>> lvds0_input: endpoint {
>> };
>> };
>> port@1 {
>> lvds0_output: endpoint {
>> };
>> };
>> };
>> channel@1 {
>> port@0 {
>> lvds1_input: endpoint {
>> };
>> };
>> lvds1: port@1 {
>> lvds1_output: endpoint {
>> };
>> };
>> };
>> };
>>
>>> + struct media_entity *local = &entity->entity;
>>> + struct device_node *ep = NULL;
>>> + int ret = 0;
>>> +
>>> + dev_dbg(dev, "creating links for entity %s\n", local->name);
>>> +
>>> + while (1) {
>>> + struct media_entity *remote = NULL;
>>> + struct media_pad *remote_pad;
>>> + struct media_pad *local_pad;
>>> + struct display_of_link link;
>>> + struct display_entity *ent;
>>> + struct device_node *next;
>>> +
>>> + /* Get the next endpoint and parse its link. */
>>> + next = display_of_get_next_endpoint(node, ep);
>>> + if (next == NULL)
>>> + break;
>>> +
>>> + of_node_put(ep);
>>> + ep = next;
>>> +
>>> + dev_dbg(dev, "processing endpoint %s\n", ep->full_name);
>>> +
>>> + ret = display_of_parse_link(e
[Bug 59649] [r600][RV635] GPU lockup CP stall / GPU resets over and over - Kernel 3.7 to 3.11 inclusive
https://bugs.freedesktop.org/show_bug.cgi?id=59649 --- Comment #8 from Shawn Starr --- This is pending close, waiting til end of week, but so far, the fixes work, those patches listed in the bug are obsolete as the work is being shifted around but the logic however seems to fix the reset issues. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon: simplify driver data retrieval
On Tue, Sep 10, 2013 at 4:30 AM, Jean Delvare wrote:
> You can get the driver data from struct device directly, there's no
> need to get the PCI device first.
>
> Signed-off-by: Jean Delvare
> Cc: David Airlie
> Cc: Alex Deucher
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/radeon/radeon_pm.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> --- linux-3.11-rc7.orig/drivers/gpu/drm/radeon/radeon_pm.c 2013-09-02
> 22:06:28.569606289 +0200
> +++ linux-3.11-rc7/drivers/gpu/drm/radeon/radeon_pm.c 2013-09-03
> 09:20:41.850518596 +0200
> @@ -333,7 +333,7 @@ static ssize_t radeon_get_pm_profile(str
> struct device_attribute *attr,
> char *buf)
> {
> - struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
> + struct drm_device *ddev = dev_get_drvdata(dev);
> struct radeon_device *rdev = ddev->dev_private;
> int cp = rdev->pm.profile;
>
> @@ -349,7 +349,7 @@ static ssize_t radeon_set_pm_profile(str
> const char *buf,
> size_t count)
> {
> - struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
> + struct drm_device *ddev = dev_get_drvdata(dev);
> struct radeon_device *rdev = ddev->dev_private;
>
> mutex_lock(&rdev->pm.mutex);
> @@ -383,7 +383,7 @@ static ssize_t radeon_get_pm_method(stru
> struct device_attribute *attr,
> char *buf)
> {
> - struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
> + struct drm_device *ddev = dev_get_drvdata(dev);
> struct radeon_device *rdev = ddev->dev_private;
> int pm = rdev->pm.pm_method;
>
> @@ -397,7 +397,7 @@ static ssize_t radeon_set_pm_method(stru
> const char *buf,
> size_t count)
> {
> - struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
> + struct drm_device *ddev = dev_get_drvdata(dev);
> struct radeon_device *rdev = ddev->dev_private;
>
> /* we don't support the legacy modes with dpm */
> @@ -433,7 +433,7 @@ static ssize_t radeon_get_dpm_state(stru
> struct device_attribute *attr,
> char *buf)
> {
> - struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
> + struct drm_device *ddev = dev_get_drvdata(dev);
> struct radeon_device *rdev = ddev->dev_private;
> enum radeon_pm_state_type pm = rdev->pm.dpm.user_state;
>
> @@ -447,7 +447,7 @@ static ssize_t radeon_set_dpm_state(stru
> const char *buf,
> size_t count)
> {
> - struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
> + struct drm_device *ddev = dev_get_drvdata(dev);
> struct radeon_device *rdev = ddev->dev_private;
>
> mutex_lock(&rdev->pm.mutex);
> @@ -472,7 +472,7 @@ static ssize_t radeon_get_dpm_forced_per
>struct
> device_attribute *attr,
>char *buf)
> {
> - struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
> + struct drm_device *ddev = dev_get_drvdata(dev);
> struct radeon_device *rdev = ddev->dev_private;
> enum radeon_dpm_forced_level level = rdev->pm.dpm.forced_level;
>
> @@ -486,7 +486,7 @@ static ssize_t radeon_set_dpm_forced_per
>const char *buf,
>size_t count)
> {
> - struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
> + struct drm_device *ddev = dev_get_drvdata(dev);
> struct radeon_device *rdev = ddev->dev_private;
> enum radeon_dpm_forced_level level;
> int ret = 0;
> @@ -524,7 +524,7 @@ static ssize_t radeon_hwmon_show_temp(st
> struct device_attribute *attr,
> char *buf)
> {
> - struct drm_device *ddev = pci_get_drvdata(to_pci_dev(dev));
> + struct drm_device *ddev = dev_get_drvdata(dev);
> struct radeon_device *rdev = ddev->dev_private;
> int temp;
>
>
> --
> Jean Delvare
> Suse L3
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #127 from Sergey --- Thanks, I'll try to check these patches. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #126 from Alex Deucher --- (In reply to comment #124) > I've noticed, that while watching youtube videos, sometimes (actually rather > often) everything freezes. Looks like Xorg crash. It tries to recover but > screen freezes, though mouse is working and sound (probably everything else > is alive). > > Dmesg is flooded with messages: > [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! > radeon :01:00.0: couldn't schedule ib That's a GPU lock up which may not be related to dpm. I recently fixed an alignment issue with command buffers that may fix these hangs for you. you'll need this patch for libdrm: http://cgit.freedesktop.org/mesa/drm/commit/?id=58d008883165ba35c83041fa9ed84937163d5f76 and this patch for mesa: http://cgit.freedesktop.org/mesa/mesa/commit/?id=a81beee37e0dd7b75422448420e8e8b0b4b76c1e -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #124 from Sergey --- I've noticed, that while watching youtube videos, sometimes (actually rather often) everything freezes. Looks like Xorg crash. It tries to recover but screen freezes, though mouse is working and sound (probably everything else is alive). Dmesg is flooded with messages: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! radeon :01:00.0: couldn't schedule ib -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: BUG: sleeping function called from invalid context on 3.10.10-rt7
[+cc dri-devel] On 09/11/2013 11:38 AM, Steven Rostedt wrote: On Wed, 11 Sep 2013 11:16:43 -0400 Peter Hurley wrote: The funny part is, there's a comment there that shows that this was done even for "PREEMPT_RT". Unfortunately, the call to "get_scanout_position()" can call functions that use the rt-mutex "sleeping spin locks" and it breaks there. I guess we need to ask the authors of the mainline patch exactly why that preempt_disable() is needed? The drm core associates a timestamp with each vertical blank frame #. Drm drivers can optionally support a 'high resolution' hw timestamp. The vblank frame #/timestamp tuple is user-space visible. The i915 drm driver supports a hw timestamp via this drm helper function which computes the timestamp from the crtc scan position (based on the pixel clock). For mainline, the preempt_disable/_enable() isn't actually necessary because every call tree that leads here already has preemption disabled. For -RT, the maybe i915 register spinlock (uncore.lock) should be raw? No, it should not. Note, any other lock that can be held when it is held would also need to be raw. By that, you mean "any other lock" that might be claimed "would also need to be raw"? Hopefully not "any other lock" already held? And by taking a quick audit of the code, I see this: spin_lock_irqsave(&dev_priv->uncore.lock, irqflags); /* Reset the chip */ /* GEN6_GDRST is not in the gt power well, no need to check * for fifo space for the write or forcewake the chip for * the read */ __raw_i915_write32(dev_priv, GEN6_GDRST, GEN6_GRDOM_FULL); /* Spin waiting for the device to ack the reset request */ ret = wait_for((__raw_i915_read32(dev_priv, GEN6_GDRST) & GEN6_GRDOM_FULL) == 0, 500); That spin is unacceptable in RT with preemption and interrupts disabled. Yep. That would be bad. AFAICT the registers read in i915_get_crtc_scanoutpos() aren't included in the force-wake set, so raw reads of the registers would probably be acceptable (thus obviating the need for claiming the uncore.lock). Except that _ALL_ register access is disabled with the uncore.lock during a gpu reset. Not sure if that's meant to include crtc registers or not, or what other synchronization/serialization issues are being handled/hidden by forcing all register accesses to wait during a gpu reset. Hopefully an i915 expert can weigh in here? What's the real issue here? That the vblank timestamp needs to be an accurate measurement of a realtime event. Sleeping/servicing interrupts while reading the registers necessary to compute the timestamp would be bad too. (edit: which hopefully Mario Kleiner clarified in his reply) My point earlier was three-fold: 1. Don't need the preempt_disable() for mainline: all callers are already holding interrupt-disabling spinlocks. 2. -RT still needs to prevent scheduling there. 3. the problem is i915-specific. [update: the radeon driver should also BUG like the i915 driver but probably should have mmio_idx_lock spinlock as raw] Does it have something to do with this dump? Not sure [but I didn't realize the query was regarding 3.0]. [3.932060] [ cut here ] [3.936809] WARNING: at /home/rostedt/work/git/linux-rt.git/drivers/gpu/drm/i915/i915_drv.c:322 gen6_gt_force_wake_get+0x4d/0x50 [i915]() [3.949229] Hardware name: HP Compaq Pro 6300 SFF [3.953988] Modules linked in: i915(+) video i2c_algo_bit drm_kms_helper drm i2c_core [3.961943] Pid: 220, comm: udevd Not tainted 3.0.89-test-rt117 #117 [3.968343] Call Trace: [3.970851] [] warn_slowpath_common+0x7f/0xc0 [3.970852] [] warn_slowpath_null+0x1a/0x20 [3.970857] [] gen6_gt_force_wake_get+0x4d/0x50 [i915] [3.970865] [] ivybridge_init_clock_gating+0xcb/0x2f0 [i915] [3.970870] [] ? intel_crtc_disable+0x29/0x60 [i915] [3.970877] [] intel_modeset_init+0x751/0x10e0 [i915] [3.970882] [] i915_driver_load+0xfc8/0x17f0 [i915] [3.970885] [] ? device_register+0x1e/0x30 [3.970892] [] ? drm_sysfs_device_add+0x86/0xb0 [drm] [3.970896] [] ? drm_get_minor+0x233/0x300 [drm] [3.970900] [] drm_get_pci_dev+0x189/0x2a0 [drm] [3.970902] [] ? migrate_enable+0x8b/0x1c0 [3.970910] [] i915_pci_probe+0x1b/0x1d [i915] [3.970913] [] local_pci_probe+0x5c/0xd0 [3.970915] [] pci_device_probe+0x109/0x130 [3.970917] [] driver_probe_device+0x9c/0x2b0 [3.970918] [] __driver_attach+0xab/0xb0 [3.970919] [] ? driver_probe_device+0x2b0/0x2b0 [3.970920] [] ? driver_probe_device+0x2b0/0x2b0 [3.970921] [] bus_for_each_dev+0x64/0xa0 [3.970923] [] driver_attach+0x1e/0x20 [3.970924] [] bus_add_driver+0x1b0/0x290 [3.970925] [] driver_register+0x76/0x140 [3.970927] [] __pci_register_driver+0x82/0x100 [3.970930] [] ? notifier_call_chain+0x4d/0x70 [3.970934] [] drm_pci_init+0x11a/0x130 [drm] [3.970935] [] ? 0xff
[Bug 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182 --- Comment #28 from Weber K. --- Sorry fellows... I my proposal was only a workaround... Maybe if you have 2 cards, and only the second is radeon, then the callback will never be scheduled... :( The solution needs to be adjusted a little more... Ill think about it... Ill report if I find something new... Thanks! -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: fix potential NULL pointer dereference
On Wed, Sep 11, 2013 at 10:09 AM, Wei Yongjun wrote:
> From: Wei Yongjun
>
> The dereference to 'pdata' should be moved below the NULL test.
>
> Signed-off-by: Wei Yongjun
Acked-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index e1e1ec9..6b50e6b 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -29,13 +29,14 @@
> static void bs_init(struct msm_gpu *gpu, struct platform_device *pdev)
> {
> struct drm_device *dev = gpu->dev;
> - struct kgsl_device_platform_data *pdata = pdev->dev.platform_data;
> + struct kgsl_device_platform_data *pdata;
>
> if (!pdev) {
> dev_err(dev->dev, "could not find dtv pdata\n");
> return;
> }
>
> + pdata = pdev->dev.platform_data;
> if (pdata->bus_scale_table) {
> gpu->bsc =
> msm_bus_scale_register_client(pdata->bus_scale_table);
> DBG("bus scale client: %08x", gpu->bsc);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #125 from Sergey --- Created attachment 85644 --> https://bugs.freedesktop.org/attachment.cgi?id=85644&action=edit Xorg log Here is Xorg log, but according to timestamps it is only for Xorg, that tried to restart. Initial error is not seen. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60857] Unstable display with Radeon 760G (ASUS M4A78L-M LE)
https://bugzilla.kernel.org/show_bug.cgi?id=60857 Alex Deucher changed: What|Removed |Added Attachment #107430|0 |1 is obsolete|| --- Comment #7 from Alex Deucher --- Created attachment 108131 --> https://bugzilla.kernel.org/attachment.cgi?id=108131&action=edit debugging output Can you attach your dmesg output with this patch applied? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] radeon drm-fixes-3.12
Hi Dave, Radeon drm fixes for 3.12. All over the place (display, dpm, uvd, etc.). Also adds a couple more berlin pci ids. The following changes since commit 01172772c7c973debf5b4881fcb9463891ea97ec: drm/nouveau: fix oops on runtime suspend/resume (2013-09-10 12:38:53 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.12 for you to fetch changes up to b7a5ae97502e104371c7eb3b7b17ae959e50d6f5: drm/radeon/dpm: add bapm callback for kb/kv (2013-09-11 11:44:40 -0400) Alex Deucher (18): drm/radeon/cik: properly handle internal cp ints drm/radeon/si: properly handle internal cp ints drm/radeon/dce6/audio: make sure pin is valid before accessing it drm/radeon: add a connector property for audio drm/radeon: dpm updates for KV drm/radeon: protect concurrent smc register access with a spinlock drm/radeon: add spinlocks for indirect register accesss drm/radeon/cik: update gpu_init for an additional berlin gpu drm/radeon: add some additional berlin pci ids drm/radeon: fix typo in PG flags drm/radeon/r6xx: add a stubbed out set_uvd_clocks callback drm/radeon/dpm: fix fallback for empty UVD clocks drm/radeon/atom: workaround vbios bug in transmitter table on rs880 (v2) drm/radeon/dpm: handle bapm on trinity drm/radeon/dpm: handle bapm on kb/kv drm/radeon/dpm: add infrastructure to properly handle bapm drm/radeon/dpm: add bapm callback for trinity drm/radeon/dpm: add bapm callback for kb/kv Anthoine Bourgeois (1): drm/radeon/dpm: implement force performance levels for rs780 (v2) Christian König (2): drm/radeon: remove stale radeon_fence_retire tracepoint drm/radeon: add command submission tracepoint Dan Carpenter (2): drm/radeon: clean up r600_free_extended_power_table() drm/radeon: signedness bug in kv_dpm.c Jean Delvare (2): drm/radeon: simplify driver data retrieval drm/radeon: expose DPM thermal thresholds through sysfs drivers/gpu/drm/radeon/atombios_encoders.c | 23 ++-- drivers/gpu/drm/radeon/ci_smc.c| 39 --- drivers/gpu/drm/radeon/cik.c | 36 +-- drivers/gpu/drm/radeon/dce6_afmt.c | 12 ++- drivers/gpu/drm/radeon/kv_dpm.c| 163 +++-- drivers/gpu/drm/radeon/kv_dpm.h| 1 + drivers/gpu/drm/radeon/kv_smc.c| 8 ++ drivers/gpu/drm/radeon/ppsmc.h | 2 + drivers/gpu/drm/radeon/r100.c | 7 ++ drivers/gpu/drm/radeon/r420.c | 7 ++ drivers/gpu/drm/radeon/r600.c | 19 drivers/gpu/drm/radeon/r600_dpm.c | 38 +++ drivers/gpu/drm/radeon/radeon.h| 82 ++- drivers/gpu/drm/radeon/radeon_asic.c | 11 +- drivers/gpu/drm/radeon/radeon_asic.h | 5 + drivers/gpu/drm/radeon/radeon_connectors.c | 33 ++ drivers/gpu/drm/radeon/radeon_cs.c | 3 + drivers/gpu/drm/radeon/radeon_device.c | 11 ++ drivers/gpu/drm/radeon/radeon_display.c| 12 +++ drivers/gpu/drm/radeon/radeon_drv.c| 2 +- drivers/gpu/drm/radeon/radeon_mode.h | 9 ++ drivers/gpu/drm/radeon/radeon_pm.c | 67 ++-- drivers/gpu/drm/radeon/radeon_trace.h | 27 +++-- drivers/gpu/drm/radeon/rs400.c | 7 ++ drivers/gpu/drm/radeon/rs600.c | 12 ++- drivers/gpu/drm/radeon/rs690.c | 7 ++ drivers/gpu/drm/radeon/rs780_dpm.c | 99 ++ drivers/gpu/drm/radeon/rv515.c | 8 ++ drivers/gpu/drm/radeon/rv770_dpm.c | 10 +- drivers/gpu/drm/radeon/rv770_smc.c | 44 +--- drivers/gpu/drm/radeon/rv770_smc.h | 2 - drivers/gpu/drm/radeon/si.c| 21 +++- drivers/gpu/drm/radeon/si_smc.c| 43 +--- drivers/gpu/drm/radeon/trinity_dpm.c | 16 +++ drivers/gpu/drm/radeon/trinity_dpm.h | 2 + drivers/gpu/drm/radeon/trinity_smc.c | 8 ++ include/drm/drm_pciids.h | 3 + 37 files changed, 729 insertions(+), 170 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: return -EBUSY if bo still active
When we CPU_PREP a bo with NOSYNC flag (for example, to implement
PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE), an -EBUSY return indicates to
userspace that the bo is still busy. Previously it was incorrectly
returning 0 in this case.
And while we're in there throw in an bit of extra sanity checking in
case userspace tries to wait for a bogus fence.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 50 ---
drivers/gpu/drm/msm/msm_drv.h | 6 ++
drivers/gpu/drm/msm/msm_gem.c | 6 +-
3 files changed, 44 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 864c977..008d772 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -499,25 +499,41 @@ int msm_wait_fence_interruptable(struct drm_device *dev,
uint32_t fence,
struct timespec *timeout)
{
struct msm_drm_private *priv = dev->dev_private;
- unsigned long timeout_jiffies = timespec_to_jiffies(timeout);
- unsigned long start_jiffies = jiffies;
- unsigned long remaining_jiffies;
int ret;
- if (time_after(start_jiffies, timeout_jiffies))
- remaining_jiffies = 0;
- else
- remaining_jiffies = timeout_jiffies - start_jiffies;
-
- ret = wait_event_interruptible_timeout(priv->fence_event,
- priv->completed_fence >= fence,
- remaining_jiffies);
- if (ret == 0) {
- DBG("timeout waiting for fence: %u (completed: %u)",
- fence, priv->completed_fence);
- ret = -ETIMEDOUT;
- } else if (ret != -ERESTARTSYS) {
- ret = 0;
+ if (!priv->gpu)
+ return 0;
+
+ if (fence > priv->gpu->submitted_fence) {
+ DRM_ERROR("waiting on invalid fence: %u (of %u)\n",
+ fence, priv->gpu->submitted_fence);
+ return -EINVAL;
+ }
+
+ if (!timeout) {
+ /* no-wait: */
+ ret = fence_completed(dev, fence) ? 0 : -EBUSY;
+ } else {
+ unsigned long timeout_jiffies = timespec_to_jiffies(timeout);
+ unsigned long start_jiffies = jiffies;
+ unsigned long remaining_jiffies;
+
+ if (time_after(start_jiffies, timeout_jiffies))
+ remaining_jiffies = 0;
+ else
+ remaining_jiffies = timeout_jiffies - start_jiffies;
+
+ ret = wait_event_interruptible_timeout(priv->fence_event,
+ fence_completed(dev, fence),
+ remaining_jiffies);
+
+ if (ret == 0) {
+ DBG("timeout waiting for fence: %u (completed: %u)",
+ fence, priv->completed_fence);
+ ret = -ETIMEDOUT;
+ } else if (ret != -ERESTARTSYS) {
+ ret = 0;
+ }
}
return ret;
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 1ea9d46..df8f1d0 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -191,6 +191,12 @@ u32 msm_readl(const void __iomem *addr);
#define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
#define VERB(fmt, ...) if (0) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
+static inline bool fence_completed(struct drm_device *dev, uint32_t fence)
+{
+ struct msm_drm_private *priv = dev->dev_private;
+ return priv->completed_fence >= fence;
+}
+
static inline int align_pitch(int width, int bpp)
{
int bytespp = (bpp + 7) / 8;
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 5999b67..583286f 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -437,12 +437,16 @@ int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t
op,
struct msm_gem_object *msm_obj = to_msm_bo(obj);
int ret = 0;
- if (is_active(msm_obj) && !(op & MSM_PREP_NOSYNC)) {
+ if (is_active(msm_obj)) {
uint32_t fence = 0;
+
if (op & MSM_PREP_READ)
fence = msm_obj->write_fence;
if (op & MSM_PREP_WRITE)
fence = max(fence, msm_obj->read_fence);
+ if (op & MSM_PREP_NOSYNC)
+ timeout = NULL;
+
ret = msm_wait_fence_interruptable(dev, fence, timeout);
}
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: workaround for missing irq
Occasionally we seem to miss an IRQ from the ME (microengine). I'm not
entirely sure the root cause, but for now we can unwedge things by
retiring from the hangcheck timer.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 10cc443..7ddcfbe 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -230,6 +230,8 @@ static void hangcheck_timer_reset(struct msm_gpu *gpu)
static void hangcheck_handler(unsigned long data)
{
struct msm_gpu *gpu = (struct msm_gpu *)data;
+ struct drm_device *dev = gpu->dev;
+ struct msm_drm_private *priv = dev->dev_private;
uint32_t fence = gpu->funcs->last_fence(gpu);
if (fence != gpu->hangcheck_fence) {
@@ -237,8 +239,6 @@ static void hangcheck_handler(unsigned long data)
gpu->hangcheck_fence = fence;
} else if (fence < gpu->submitted_fence) {
/* no progress and not done.. hung! */
- struct drm_device *dev = gpu->dev;
- struct msm_drm_private *priv = dev->dev_private;
gpu->hangcheck_fence = fence;
dev_err(dev->dev, "%s: hangcheck detected gpu lockup!\n",
gpu->name);
@@ -252,6 +252,9 @@ static void hangcheck_handler(unsigned long data)
/* if still more pending work, reset the hangcheck timer: */
if (gpu->submitted_fence > gpu->hangcheck_fence)
hangcheck_timer_reset(gpu);
+
+ /* workaround for missing irq: */
+ queue_work(priv->wq, &gpu->retire_work);
}
/*
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58121] Radeon SUMO: LVDS panel blanks when enabling external monitor
https://bugzilla.kernel.org/show_bug.cgi?id=58121 黄家垚 changed: What|Removed |Added CC||huangjiayao_1...@163.com --- Comment #4 from 黄家垚 --- This also appeared on my laptop(A6 3400M and A8 3500M) with Linux 3.5.0 to 3.11. For using external monitor, i can only use Linux 3.4.x. I an looking forward to use newer Linux kernel on my laptop. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #20 from Alexandre Demers --- Ok, if I apply the whole suggested patch but the following, it hangs: @@ -4152,14 +4152,14 @@ int ni_dpm_init(struct radeon_device *rdev) } ni_pi->mclk_rtt_mode_threshold = eg_pi->mclk_edc_wr_enable_threshold; -pi->voltage_control = -radeon_atom_is_voltage_gpio(rdev, SET_VOLTAGE_TYPE_ASIC_VDDC, 0); +pi->voltage_control = false; +//radeon_atom_is_voltage_gpio(rdev, SET_VOLTAGE_TYPE_ASIC_VDDC, 0); -pi->mvdd_control = -radeon_atom_is_voltage_gpio(rdev, SET_VOLTAGE_TYPE_ASIC_MVDDC, 0); +pi->mvdd_control = false; +//radeon_atom_is_voltage_gpio(rdev, SET_VOLTAGE_TYPE_ASIC_MVDDC, 0); -eg_pi->vddci_control = -radeon_atom_is_voltage_gpio(rdev, SET_VOLTAGE_TYPE_ASIC_VDDCI, 0); +eg_pi->vddci_control = false; +//radeon_atom_is_voltage_gpio(rdev, SET_VOLTAGE_TYPE_ASIC_VDDCI, 0); rv770_get_engine_memory_ss(rdev); I'll try to play with that a bit and I'll come back. I also still have to give you the module_index. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: host1x: use %pa to print dma_addr_t
This removes two warnings where dma_addr_t variables were printed using %x when built with CONFIG_ARM_LPAE=y, thus having 64-bit dma_addr_t: drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' drivers/gpu/host1x/hw/debug_hw.c:175:10: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t' Signed-off-by: Olof Johansson --- drivers/gpu/host1x/hw/cdma_hw.c |4 ++-- drivers/gpu/host1x/hw/debug_hw.c |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/host1x/hw/cdma_hw.c b/drivers/gpu/host1x/hw/cdma_hw.c index 2ee4ad5..3db3011 100644 --- a/drivers/gpu/host1x/hw/cdma_hw.c +++ b/drivers/gpu/host1x/hw/cdma_hw.c @@ -54,8 +54,8 @@ static void cdma_timeout_cpu_incr(struct host1x_cdma *cdma, u32 getptr, u32 *p = (u32 *)((u32)pb->mapped + getptr); *(p++) = HOST1X_OPCODE_NOP; *(p++) = HOST1X_OPCODE_NOP; - dev_dbg(host1x->dev, "%s: NOP at 0x%x\n", __func__, - pb->phys + getptr); + dev_dbg(host1x->dev, "%s: NOP at %pa+0x%x\n", __func__, + &pb->phys, getptr); getptr = (getptr + 8) & (pb->size_bytes - 1); } wmb(); diff --git a/drivers/gpu/host1x/hw/debug_hw.c b/drivers/gpu/host1x/hw/debug_hw.c index 334c038..346a54b 100644 --- a/drivers/gpu/host1x/hw/debug_hw.c +++ b/drivers/gpu/host1x/hw/debug_hw.c @@ -171,8 +171,8 @@ static void show_channel_gathers(struct output *o, struct host1x_cdma *cdma) continue; } - host1x_debug_output(o, "GATHER at %08x+%04x, %d words\n", - g->base, g->offset, g->words); + host1x_debug_output(o, "GATHER at %pa+%04x, %d words\n", + &g->base, g->offset, g->words); show_gather(o, g->base + g->offset, g->words, cdma, g->base, mapped); -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #21 from Alexandre Demers --- Adding printk(KERN_DEBUG "DEBUG: about to pass the following value of module_index to radeon_atom_init_mc_reg_table(): %d", module_index); just before calling radeon_atom_init_mc_reg_table() returns 2. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ast: fix the ast open key function
From: Dave Airlie
When porting from UMS I mistyped this from the wrong place, AST noticed
and pointed it out, so we should fix it to be like the X.org driver.
Reported-by: Y.C. Chen
Cc: sta...@vger.kernel.org
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ast/ast_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 796dbb2..8492b68 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -177,7 +177,7 @@ uint8_t ast_get_index_reg_mask(struct ast_private *ast,
static inline void ast_open_key(struct ast_private *ast)
{
- ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xA1, 0xFF, 0x04);
+ ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0x80, 0xA8);
}
#define AST_VIDMEM_SIZE_8M0x0080
--
1.8.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #33 from Jose P. --- Created attachment 85691 --> https://bugs.freedesktop.org/attachment.cgi?id=85691&action=edit dmesg+Xorg.0.log Same bug here... HP laptop (dv6-6174la), dual GPU: 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] BeaverCreek [Radeon HD 6520G] [1002:9647] (prog-if 00 [VGA controller]) 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Whistler [Radeon HD 6630M/6650M/6750M/7670M/7690M] [1002:6741] (prog-if 00 [VGA controller]) Linux hostname 3.11.0-7-generic #13-Ubuntu SMP Tue Sep 10 20:55:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux workaround: use an external monitor (HDMI and VGA worked, with some problems though, but that is unrelated [you can see some warning and backtraces] and didn't happen before) attached: whole dmesg, Xorg.0.log files after two consecutive suspend/resume cycles plus some testing with external monitors, and .diff files (from other session) showing messages logged only after suspend to RAM. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
