Re: [PATCH v2 09/10] udf: Replace license notice with SPDX identifier

[Pali Rohár]

On Friday 12 May 2023 17:06:20 Bagas Sanjaya wrote:
> diff --git a/fs/udf/udftime.c b/fs/udf/udftime.c
> index fce4ad976c8c29..d0fce5348fd3f3 100644
> --- a/fs/udf/udftime.c
> +++ b/fs/udf/udftime.c
> @@ -1,21 +1,4 @@
> -/* Copyright (C) 1993, 1994, 1995, 1996, 1997 Free Software Foundation, Inc.
> -   This file is part of the GNU C Library.
> -   Contributed by Paul Eggert (egg...@twinsun.com).
> -
> -   The GNU C Library is free software; you can redistribute it and/or
> -   modify it under the terms of the GNU Library General Public License as
> -   published by the Free Software Foundation; either version 2 of the
> -   License, or (at your option) any later version.
> -
> -   The GNU C Library is distributed in the hope that it will be useful,
> -   but WITHOUT ANY WARRANTY; without even the implied warranty of
> -   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> -   Library General Public License for more details.
> -
> -   You should have received a copy of the GNU Library General Public
> -   License along with the GNU C Library; see the file COPYING.LIB.  If not,
> -   write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
> -   Boston, MA 02111-1307, USA.  */
> +// SPDX-License-Identifier: GPL-2.0-only
>  
>  /*
>   * dgb 10/02/98: ripped this from glibc source to help convert timestamps

Please, dot not do this. It is really rude to people who worked on it in
past (even if they do not care about this particular file anymore) as
technically they still have ownership of this code / file. And such
change never remove their ownership or copyright in most countries.

Re: [PATCH 00/22] Fallback to native backlight

[Pali Rohár]

On Monday 24 October 2022 21:58:57 Akihiko Odaki wrote:
> Regarding the second limitation, I don't even understand the difference
> between vendor and native. My guess is that a vendor backlight device uses
> vendor-specific ACPI interface, and a native one directly uses hardware
> registers. If my guess is correct, the difference between vendor and native
> does not imply that both of them are likely to exist at the same time. As
> the conclusion, there is no more motivation to try to de-duplicate the
> vendor/native combination than to try to de-duplicate combination of devices
> with a single type.

Hello! I just want to point one thing. On some Dell laptops there are
3 different ways (= 3 different APIs) how to control display backlight.
There is ACPI driver (uses ACPI), GPU/DRM driver (i915.ko; uses directly
HW) and platform vendor driver (dell-laptop.ko; uses vendor BIOS or
firmware API). Just every driver has different pre-calculated scaling
values. So sometimes user wants to choose different driver just because
it allows to set backlight level with "better" granularity. Registering
all 3 device drivers is bad as user does not want to see 3 display
panels and forcing registration of specific one without runtime option
is also bad (some of those drivers do not have to be suitable or has
worse granularity as other).

Re: [PATCH v1 06/11] PCI: aardvark: switch to using devm_gpiod_get_optional()

[Pali Rohár]

On Monday 05 September 2022 15:54:53 Dmitry Torokhov wrote:
> On Mon, Sep 05, 2022 at 09:00:46AM +0200, Pali Rohár wrote:
> > On Sunday 04 September 2022 23:30:58 Dmitry Torokhov wrote:
> > > I would like to stop exporting OF-specific devm_gpiod_get_from_of_node()
> > > so that gpiolib can be cleaned a bit, so let's switch to the generic
> > > device property API.
> > > 
> > > I believe that the only reason the driver, instead of the standard
> > > devm_gpiod_get_optional(), used devm_gpiod_get_from_of_node() is
> > > because it wanted to set up a pretty consumer name for the GPIO,
> > 
> > IIRC consumer name is not used at all.
> > 
> > The reason was to specify full name of DTS property, for easier
> > identification of the code. DTS property is "reset-gpios" but API
> > specify only "reset".
> 
> I see. Do you want me to reset the patch with updated desctiption as to
> the reason devm_gpiod_get_from_of_node() was used?

I think it is fine. So add my:

Acked-by: Pali Rohár 

Anyway as another improvement for future I would suggest some API
function with _optional_ logic, so it could be used for more PCIe
controller drivers (e.g. also tegra) without need to reimplement
-ENOENT handling. It is really strange if for acquiring same PERST#
line via GPIO ("reset-gpios" DT property) are used more API functions
in different PCIe drivers.

> > 
> > > and we now have a special API for that.
> > > 
> > > Signed-off-by: Dmitry Torokhov 
> > > 
> > > diff --git a/drivers/pci/controller/pci-aardvark.c 
> > > b/drivers/pci/controller/pci-aardvark.c
> > > index 4834198cc86b..4a8a4a8522cb 100644
> > > --- a/drivers/pci/controller/pci-aardvark.c
> > > +++ b/drivers/pci/controller/pci-aardvark.c
> > > @@ -1856,20 +1856,19 @@ static int advk_pcie_probe(struct platform_device 
> > > *pdev)
> > >   return ret;
> > >   }
> > >  
> > > - pcie->reset_gpio = devm_gpiod_get_from_of_node(dev, dev->of_node,
> > > -"reset-gpios", 0,
> > > -GPIOD_OUT_LOW,
> > > -"pcie1-reset");
> > > + pcie->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
> > >   ret = PTR_ERR_OR_ZERO(pcie->reset_gpio);
> > >   if (ret) {
> > > - if (ret == -ENOENT) {
> > > - pcie->reset_gpio = NULL;
> > > - } else {
> > > - if (ret != -EPROBE_DEFER)
> > > - dev_err(dev, "Failed to get reset-gpio: %i\n",
> > > - ret);
> > > - return ret;
> > > - }
> > > + if (ret != -EPROBE_DEFER)
> > > + dev_err(dev, "Failed to get reset-gpio: %i\n",
> > > + ret);
> > > + return ret;
> > > + }
> > > +
> > > + ret = gpiod_set_consumer_name(pcie->reset_gpio, "pcie1-reset");
> > > + if (ret) {
> > > + dev_err(dev, "Failed to set reset gpio name: %d\n", ret);
> > > + return ret;
> > >   }
> > >  
> > >   ret = of_pci_get_max_link_speed(dev->of_node);
> > > 
> > > -- 
> > > b4 0.10.0-dev-fc921
> 
> Thanks.
> 
> -- 
> Dmitry

Re: [PATCH v1 01/11] PCI: tegra: switch to using devm_fwnode_gpiod_get

[Pali Rohár]

On Monday 05 September 2022 13:49:21 Andy Shevchenko wrote:
> On Mon, Sep 5, 2022 at 10:23 AM Pali Rohár  wrote:
> > On Sunday 04 September 2022 23:30:53 Dmitry Torokhov wrote:
> 
> ...
> 
> > > - rp->reset_gpio = devm_gpiod_get_from_of_node(dev, port,
> > > -  "reset-gpios", 
> > > 0,
> > > -  GPIOD_OUT_LOW,
> > > -  label);
> > > + rp->reset_gpio = devm_fwnode_gpiod_get(dev,
> > > +
> > > of_fwnode_handle(port),
> > > +"reset",
> > > +GPIOD_OUT_LOW,
> > > +label);
> >
> > Why in pci-aardvark.c for PERST# reset-gpio you have used
> > devm_gpiod_get_optional() and here in pci-tegra.c you have used
> > devm_fwnode_gpiod_get()? I think that PERST# logic is same in both
> > drivers.
> 
> It's not the same dev and its node in this case. There is one reset
> for _all_ ports, here is the reset on _per port_ basis.

aardvark is single port controller. So it is basically same.

Re: [PATCH v1 01/11] PCI: tegra: switch to using devm_fwnode_gpiod_get

[Pali Rohár]

On Sunday 04 September 2022 23:30:53 Dmitry Torokhov wrote:
> I would like to limit (or maybe even remove) use of
> [devm_]gpiod_get_from_of_node in drivers so that gpiolib can be cleaned
> a bit, so let's switch to the generic device property API. It may even
> help with handling secondary fwnodes when gpiolib is taught to handle
> gpios described by swnodes.
> 
> Signed-off-by: Dmitry Torokhov 
> 
> diff --git a/drivers/pci/controller/pci-tegra.c 
> b/drivers/pci/controller/pci-tegra.c
> index 8e323e93be91..929f9363e94b 100644
> --- a/drivers/pci/controller/pci-tegra.c
> +++ b/drivers/pci/controller/pci-tegra.c
> @@ -2202,10 +2202,11 @@ static int tegra_pcie_parse_dt(struct tegra_pcie 
> *pcie)
>* and in this case fall back to using AFI per port register
>* to toggle PERST# SFIO line.
>*/
> - rp->reset_gpio = devm_gpiod_get_from_of_node(dev, port,
> -  "reset-gpios", 0,
> -  GPIOD_OUT_LOW,
> -  label);
> + rp->reset_gpio = devm_fwnode_gpiod_get(dev,
> +of_fwnode_handle(port),
> +"reset",
> +GPIOD_OUT_LOW,
> +label);

Why in pci-aardvark.c for PERST# reset-gpio you have used
devm_gpiod_get_optional() and here in pci-tegra.c you have used
devm_fwnode_gpiod_get()? I think that PERST# logic is same in both
drivers.

>   if (IS_ERR(rp->reset_gpio)) {
>   if (PTR_ERR(rp->reset_gpio) == -ENOENT) {
>   rp->reset_gpio = NULL;
> 
> -- 
> b4 0.10.0-dev-fc921

Re: [PATCH v1 06/11] PCI: aardvark: switch to using devm_gpiod_get_optional()

[Pali Rohár]

On Sunday 04 September 2022 23:30:58 Dmitry Torokhov wrote:
> I would like to stop exporting OF-specific devm_gpiod_get_from_of_node()
> so that gpiolib can be cleaned a bit, so let's switch to the generic
> device property API.
> 
> I believe that the only reason the driver, instead of the standard
> devm_gpiod_get_optional(), used devm_gpiod_get_from_of_node() is
> because it wanted to set up a pretty consumer name for the GPIO,

IIRC consumer name is not used at all.

The reason was to specify full name of DTS property, for easier
identification of the code. DTS property is "reset-gpios" but API
specify only "reset".

> and we now have a special API for that.
> 
> Signed-off-by: Dmitry Torokhov 
> 
> diff --git a/drivers/pci/controller/pci-aardvark.c 
> b/drivers/pci/controller/pci-aardvark.c
> index 4834198cc86b..4a8a4a8522cb 100644
> --- a/drivers/pci/controller/pci-aardvark.c
> +++ b/drivers/pci/controller/pci-aardvark.c
> @@ -1856,20 +1856,19 @@ static int advk_pcie_probe(struct platform_device 
> *pdev)
>   return ret;
>   }
>  
> - pcie->reset_gpio = devm_gpiod_get_from_of_node(dev, dev->of_node,
> -"reset-gpios", 0,
> -GPIOD_OUT_LOW,
> -"pcie1-reset");
> + pcie->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
>   ret = PTR_ERR_OR_ZERO(pcie->reset_gpio);
>   if (ret) {
> - if (ret == -ENOENT) {
> - pcie->reset_gpio = NULL;
> - } else {
> - if (ret != -EPROBE_DEFER)
> - dev_err(dev, "Failed to get reset-gpio: %i\n",
> - ret);
> - return ret;
> - }
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to get reset-gpio: %i\n",
> + ret);
> + return ret;
> + }
> +
> + ret = gpiod_set_consumer_name(pcie->reset_gpio, "pcie1-reset");
> + if (ret) {
> + dev_err(dev, "Failed to set reset gpio name: %d\n", ret);
> + return ret;
>   }
>  
>   ret = of_pci_get_max_link_speed(dev->of_node);
> 
> -- 
> b4 0.10.0-dev-fc921

Re: Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size

[Pali Rohár]

On Wednesday 21 February 2018 15:28:53 Ville Syrjälä wrote:
> On Mon, Feb 19, 2018 at 10:36:50AM +0100, Pali Rohár wrote:
> > On Tuesday 13 February 2018 19:45:56 Ville Syrjälä wrote:
> > > On Tue, Feb 13, 2018 at 06:43:41PM +0100, Pali Rohár wrote:
> > > > On Tuesday 13 February 2018 18:12:21 Ville Syrjälä wrote:
> > > > > On Tue, Feb 13, 2018 at 05:04:37PM +0100, Pali Rohár wrote:
> > > > > > So it can be done only once after reboot? Or only prior to booting 
> > > > > > kernel?
> > > > > 
> > > > > Never.
> > > > 
> > > > Never? Now I'm lost. Why then dmesg message instruct user to try set up
> > > > it in BIOS if you say it is never possible?
> > > 
> > > You can change it in the BIOS. No way to change it from the operating 
> > > system.
> > 
> > Hi! Can you explain it a bit more?
> > 
> > What does it mean "in BIOS"? Prior switching from 16bit real mode to
> > protected or long? Or before exiting EFI boot services? Or before
> > booting kernel (when initialize memory mapping)?
> 
> The BIOS is a black box, no one really knows what it's doing. The stolen
> memory is carved out pretty early I think (alongside other carved out
> chunks for SMM and whatnot). And once that's done the BIOS usually locks
> down stuff like this (the hw has magic write once lock bits for various
> registers) so there's just no way to change things afterwards.

Thank you for explanation. So real problem with changing size of stolen
memory is that BIOS "may" lock future changes.

Is there any documentation for this Intel GPU stolen memory? I hope that
I should be able at least to read status of that lock registers -- to
prove that size of stolen memory is locked and cannot be changed.

> > 
> > I still do not see reason nor understand why this cannot be possible
> > either in bootloader (e.g. grub2) or prior to loading bootloader which
> > runs in protected or long mode.
> > 
> > It is because BIOS uses some undocumented call/procedure which sets that
> > amount of memory and it is unknown how to do it?
> > 
> > -- 
> > Pali Rohár
> > pali.ro...@gmail.com
> 

-- 
Pali Rohár
pali.ro...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size

[Pali Rohár]

On Tuesday 13 February 2018 19:45:56 Ville Syrjälä wrote:
> On Tue, Feb 13, 2018 at 06:43:41PM +0100, Pali Rohár wrote:
> > On Tuesday 13 February 2018 18:12:21 Ville Syrjälä wrote:
> > > On Tue, Feb 13, 2018 at 05:04:37PM +0100, Pali Rohár wrote:
> > > > So it can be done only once after reboot? Or only prior to booting 
> > > > kernel?
> > > 
> > > Never.
> > 
> > Never? Now I'm lost. Why then dmesg message instruct user to try set up
> > it in BIOS if you say it is never possible?
> 
> You can change it in the BIOS. No way to change it from the operating system.

Hi! Can you explain it a bit more?

What does it mean "in BIOS"? Prior switching from 16bit real mode to
protected or long? Or before exiting EFI boot services? Or before
booting kernel (when initialize memory mapping)?

I still do not see reason nor understand why this cannot be possible
either in bootloader (e.g. grub2) or prior to loading bootloader which
runs in protected or long mode.

It is because BIOS uses some undocumented call/procedure which sets that
amount of memory and it is unknown how to do it?

-- 
Pali Rohár
pali.ro...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size

[Pali Rohár]

On Tuesday 13 February 2018 18:12:21 Ville Syrjälä wrote:
> On Tue, Feb 13, 2018 at 05:04:37PM +0100, Pali Rohár wrote:
> > $ cat /sys/kernel/debug/dri/0/i915_gem_stolen
> > Stolen:
> >8b55bf17e080:g16KiB 40 40 [ 0 0 0 0 ] 0  LLC dirty 
> > (pinned x 1) (ggtt offset: 00083000, size: 4000, type: 0) (stolen: 
> > 1000)
> >8b55c2693040:g16KiB 40 40 [ 0 0 0 0 ] 0  LLC dirty 
> > (pinned x 1) (ggtt offset: 02b9f000, size: 4000, type: 0) (stolen: 
> > 5000)
> >8b55bf9a7300:g16KiB 40 40 [ 0 0 0 0 ] 0  LLC dirty 
> > (pinned x 0) (ggtt offset: 0f6b4000, size: 4000, type: 0) (stolen: 
> > 9000)
> >8b55a6161040:g16KiB 40 40 [ 0 0 0 0 ] 0  LLC dirty 
> > (pinned x 0) (ggtt offset: 0937f000, size: 4000, type: 0) (stolen: 
> > d000)
> >8b5563e0dac0:g16KiB 40 40 [ 0 0 0 0 ] 0  LLC dirty 
> > (pinned x 0) (ggtt offset: 0f714000, size: 4000, type: 0) (stolen: 
> > 00019000)
> >8b55bf17e800:g 4KiB 41 00 [ 0 0 0 0 ] 0  LLC (pinned x 
> > 1) (ggtt offset: e000, size: 1000, type: 0) (stolen: 0012c000)
> >8b55bf02d540:g16KiB 40 40 [ 0 0 0 0 ] 0  LLC dirty 
> > (pinned x 1) (ggtt offset: 00141000, size: 4000, type: 0) (stolen: 
> > 0012d000)
> >8b55c2989340:g16KiB 40 40 [ 0 0 0 0 ] 0  LLC dirty 
> > (pinned x 1) (ggtt offset: 00148000, size: 4000, type: 0) (stolen: 
> > 00131000)
> >8b55c29890c0:g16KiB 40 40 [ 0 0 0 0 ] 0  LLC dirty 
> > (pinned x 1) (ggtt offset: 0014f000, size: 4000, type: 0) (stolen: 
> > 00135000)
> >8b55c2989840:g16KiB 40 40 [ 0 0 0 0 ] 0  LLC dirty 
> > (pinned x 1) (ggtt offset: 00156000, size: 4000, type: 0) (stolen: 
> > 00139000)
> >8b55bf02da40:  p g 14400KiB 77 00 [ 0 0 0 0 ] 0  uncached dirty 
> > (name: 1) (pinned x 1) (display) (ggtt offset: 0015a000, size: 00e1, 
> > type: 0) (stolen: 0013d000) (p mappable)
> >8b556dfba780:g16KiB 40 40 [ 0 0 0 0 ] 0  LLC dirty 
> > (pinned x 0) (ggtt offset: 0ad2a000, size: 4000, type: 0) (stolen: 
> > 01655000)
> > 
> > > likely you'll have the fbdev framebuffer taking up a sizeable chunk.
> > 
> > Seems 14MB.
> > 
> > > You could get some back by reducing fbdev depth to 16bpp, or even 8bpp,
> > > but I'm not convinced the fbdev gamma LUT stuff really works currently
> > > so you might end up with bogus colors in your vts with that.
> > 
> > Ok, I could try it. Via fbset tool?
> 
> Kernel command line. We don't allow resizing the fbdev fb once it's
> created.

Ok, will try.

> > 
> > > > 
> > > > [0.00] Memory: 7972840K/8282704K available (6196K kernel code, 
> > > > 1159K rwdata, 2848K rodata, 1408K init, 688K bss, 309864K reserved, 0K 
> > > > cma-reserved)
> > > > 
> > > > > The BIOS may or may not provide a knob to change the size
> > > > > of the stolen memory.
> > > > 
> > > > In BIOS Setup screen I have option to choose GPU memory and I set it to
> > > > max 512MB. So this is not the right option...
> > > > 
> > > > And why cannot kernel use some continuous check of RAM itself?
> > > 
> > > Because the hardware won't allow it.
> > 
> > So it can be done only once after reboot? Or only prior to booting kernel?
> 
> Never.

Never? Now I'm lost. Why then dmesg message instruct user to try set up
it in BIOS if you say it is never possible?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size

[Pali Rohár]

On Tuesday 13 February 2018 17:36:54 Ville Syrjälä wrote:
> On Tue, Feb 13, 2018 at 02:38:42PM +0100, Pali Rohár wrote:
> > On Tuesday 13 February 2018 15:27:26 Ville Syrjälä wrote:
> > > On Tue, Feb 13, 2018 at 09:50:30AM +0100, Pali Rohár wrote:
> > > > On Tuesday 06 February 2018 16:21:43 Pali Rohár wrote:
> > > > > Hi! I'm periodically getting following message in dmesg on Lenovo
> > > > > Thinkpad X1 Carbon 3rd generation:
> > > > > 
> > > > > [drm] Reducing the compressed framebuffer size. This may lead to less 
> > > > > power savings than a non-reduced-size. Try to increase stolen memory 
> > > > > size if available in BIOS.
> > > > > 
> > > > > In BIOS I already set GPU size to 512M, but this did not help. Also
> > > > > update to last BIOS version did not help.
> > > > > 
> > > > > So why this message is periodically print in dmesg? And what can I do
> > > > > with this problem?
> > > > > 
> > > > > And why cannot Linux kernel allocate itself more memory for GPU (if 
> > > > > BIOS
> > > > > can/could do that)? Is not 512MB for GPU enough?
> > > > 
> > > > And here is output from lspci, which clearly says that 512MB is already
> > > > set for GPU:
> > > 
> > > The PCI BAR size has nothing to do with the size of the stolen memory.
> > > The BAR just provides a window into the global GTT address space of the
> > > GPU. Stolen memory is a contiguous chunk of physical memory carved out
> > > by the BIOS.
> > 
> > Ok, how could I detect how much memory was stolen?
> > 
> > In dmesg I see following lines:
> > 
> > [0.00] e820: BIOS-provided physical RAM map:
> > [0.00] BIOS-e820: [mem 0x-0x00057fff] usable
> > [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] 
> > reserved
> > [0.00] BIOS-e820: [mem 0x00059000-0x0008bfff] usable
> > [0.00] BIOS-e820: [mem 0x0008c000-0x0009] 
> > reserved
> > [0.00] BIOS-e820: [mem 0x000e-0x000f] 
> > reserved
> > [0.00] BIOS-e820: [mem 0x0010-0xab908fff] usable
> > [0.00] BIOS-e820: [mem 0xab909000-0xabb08fff] type 
> > 20
> > [0.00] BIOS-e820: [mem 0xabb09000-0xacbfefff] 
> > reserved
> > [0.00] BIOS-e820: [mem 0xacbff000-0xacd7efff] ACPI 
> > NVS
> > [0.00] BIOS-e820: [mem 0xacd7f000-0xacdfefff] ACPI 
> > data
> > [0.00] BIOS-e820: [mem 0xacdff000-0xacdf] usable
> > [0.00] BIOS-e820: [mem 0xf80f8000-0xf80f8fff] 
> > reserved
> > [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] 
> > reserved
> > [0.00] BIOS-e820: [mem 0x0001-0x00024dff] usable
> > 
> > [0.00] Reserving Intel graphics memory at 
> > 0xae00-0xafff
> 
> That's the one. Since you have a BDW the amount FBC can actually use
> will be 8MiB less than what's reported here. So looks like you should
> have 24MiB total, minus whatever else we end up allocating from stolen.
> 
> Check /sys/kernel/debug/dri/0/i915_gem_stolen to see what's there. Most

$ cat /sys/kernel/debug/dri/0/i915_gem_stolen
Stolen:
   8b55bf17e080:g16KiB 40 40 [ 0 0 0 0 ] 0  LLC dirty (pinned x 
1) (ggtt offset: 00083000, size: 4000, type: 0) (stolen: 1000)
   8b55c2693040:g16KiB 40 40 [ 0 0 0 0 ] 0  LLC dirty (pinned x 
1) (ggtt offset: 02b9f000, size: 4000, type: 0) (stolen: 5000)
   8b55bf9a7300:g16KiB 40 40 [ 0 0 0 0 ] 0  LLC dirty (pinned x 
0) (ggtt offset: 0f6b4000, size: 4000, type: 0) (stolen: 9000)
   8b55a6161040:g16KiB 40 40 [ 0 0 0 0 ] 0  LLC dirty (pinned x 
0) (ggtt offset: 0937f000, size: 4000, type: 0) (stolen: d000)
   8b5563e0dac0:g16KiB 40 40 [ 0 0 0 0 ] 0  LLC dirty (pinned x 
0) (ggtt offset: 0f714000, size: 4000, type: 0) (stolen: 00019000)
   8b55bf17e800:g 4KiB 41 00 [ 0 0 0 0 ] 0  LLC (pinned x 1) 
(ggtt offset: e000, size: 1000, type: 0) (stolen: 0012c000)
   8b55bf02d540:g16KiB 40 40 [ 0 0 0 0 ] 0  LLC dirty (pinned x 
1) (ggtt offset: 00141000, size: 4000, type: 0) (stolen: 0012d000)
   8b55c2989340:g16KiB 40 40 [ 0 0 0 0 ] 0  LLC dirty (pinned x 
1) (ggtt offset: 00148000, size: 4000, type: 

Re: Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size

[Pali Rohár]

On Tuesday 13 February 2018 15:27:26 Ville Syrjälä wrote:
> On Tue, Feb 13, 2018 at 09:50:30AM +0100, Pali Rohár wrote:
> > On Tuesday 06 February 2018 16:21:43 Pali Rohár wrote:
> > > Hi! I'm periodically getting following message in dmesg on Lenovo
> > > Thinkpad X1 Carbon 3rd generation:
> > > 
> > > [drm] Reducing the compressed framebuffer size. This may lead to less 
> > > power savings than a non-reduced-size. Try to increase stolen memory size 
> > > if available in BIOS.
> > > 
> > > In BIOS I already set GPU size to 512M, but this did not help. Also
> > > update to last BIOS version did not help.
> > > 
> > > So why this message is periodically print in dmesg? And what can I do
> > > with this problem?
> > > 
> > > And why cannot Linux kernel allocate itself more memory for GPU (if BIOS
> > > can/could do that)? Is not 512MB for GPU enough?
> > 
> > And here is output from lspci, which clearly says that 512MB is already
> > set for GPU:
> 
> The PCI BAR size has nothing to do with the size of the stolen memory.
> The BAR just provides a window into the global GTT address space of the
> GPU. Stolen memory is a contiguous chunk of physical memory carved out
> by the BIOS.

Ok, how could I detect how much memory was stolen?

In dmesg I see following lines:

[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x00057fff] usable
[0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved
[0.00] BIOS-e820: [mem 0x00059000-0x0008bfff] usable
[0.00] BIOS-e820: [mem 0x0008c000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xab908fff] usable
[0.00] BIOS-e820: [mem 0xab909000-0xabb08fff] type 20
[0.00] BIOS-e820: [mem 0xabb09000-0xacbfefff] reserved
[0.00] BIOS-e820: [mem 0xacbff000-0xacd7efff] ACPI NVS
[0.00] BIOS-e820: [mem 0xacd7f000-0xacdfefff] ACPI data
[0.00] BIOS-e820: [mem 0xacdff000-0xacdf] usable
[0.00] BIOS-e820: [mem 0xf80f8000-0xf80f8fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00024dff] usable

[0.00] Reserving Intel graphics memory at 
0xae00-0xafff

[0.00] Memory: 7972840K/8282704K available (6196K kernel code, 1159K 
rwdata, 2848K rodata, 1408K init, 688K bss, 309864K reserved, 0K cma-reserved)

> The BIOS may or may not provide a knob to change the size
> of the stolen memory.

In BIOS Setup screen I have option to choose GPU memory and I set it to
max 512MB. So this is not the right option...

And why cannot kernel use some continuous check of RAM itself?

> > 
> > $ lspci -v -s 00:02.0
> > 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 
> > 09) (prog-if 00 [VGA controller])
> > Subsystem: Lenovo HD Graphics 5500
> > Flags: bus master, fast devsel, latency 0, IRQ 46
> > Memory at e000 (64-bit, non-prefetchable) [size=16M]
> > Memory at c000 (64-bit, prefetchable) [size=512M]
> > I/O ports at 3000 [size=64]
> > [virtual] Expansion ROM at 000c [disabled] [size=128K]
> > Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
> > Capabilities: [d0] Power Management version 2
> > Capabilities: [a4] PCI Advanced Features
> > Kernel driver in use: i915
> > Kernel modules: i915
> > 
> > -- 
> > Pali Rohár
> > pali.ro...@gmail.com
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Pali Rohár
pali.ro...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size

[Pali Rohár]

On Tuesday 06 February 2018 16:21:43 Pali Rohár wrote:
> Hi! I'm periodically getting following message in dmesg on Lenovo
> Thinkpad X1 Carbon 3rd generation:
> 
> [drm] Reducing the compressed framebuffer size. This may lead to less power 
> savings than a non-reduced-size. Try to increase stolen memory size if 
> available in BIOS.
> 
> In BIOS I already set GPU size to 512M, but this did not help. Also
> update to last BIOS version did not help.
> 
> So why this message is periodically print in dmesg? And what can I do
> with this problem?
> 
> And why cannot Linux kernel allocate itself more memory for GPU (if BIOS
> can/could do that)? Is not 512MB for GPU enough?

And here is output from lspci, which clearly says that 512MB is already
set for GPU:

$ lspci -v -s 00:02.0
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09) 
(prog-if 00 [VGA controller])
Subsystem: Lenovo HD Graphics 5500
Flags: bus master, fast devsel, latency 0, IRQ 46
Memory at e000 (64-bit, non-prefetchable) [size=16M]
Memory at c000 (64-bit, prefetchable) [size=512M]
I/O ports at 3000 [size=64]
[virtual] Expansion ROM at 000c [disabled] [size=128K]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915
Kernel modules: i915

-- 
Pali Rohár
pali.ro...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size

[Pali Rohár]

Hi! I'm periodically getting following message in dmesg on Lenovo
Thinkpad X1 Carbon 3rd generation:

[drm] Reducing the compressed framebuffer size. This may lead to less power 
savings than a non-reduced-size. Try to increase stolen memory size if 
available in BIOS.

In BIOS I already set GPU size to 512M, but this did not help. Also
update to last BIOS version did not help.

So why this message is periodically print in dmesg? And what can I do
with this problem?

And why cannot Linux kernel allocate itself more memory for GPU (if BIOS
can/could do that)? Is not 512MB for GPU enough?

-- 
Pali Rohár
pali.ro...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Failed to compile xserver-xorg-video-ati from git

[Pali Rohár]

Hi! Compilation of xserver-xorg-video-ati from git show these problems:

../../src/radeon_kms.c: In function 'radeon_sync_scanout_pixmaps':
../../src/radeon_kms.c:481:2: warning: implicit declaration of function 
'RegionDuplicate' [-Wimplicit-
function-declaration]
../../src/radeon_kms.c:481:14: warning: assignment makes pointer from integer 
without a cast [enabled by 
default]
Function `RegionDuplicate' implicitly converted to pointer at 
../../src/radeon_kms.c:481
../../src/radeon_kms.c: At top level:
../../src/radeon_kms.c:406:1: warning: 'transform_region' defined but not used 
[-Wunused-function]

Due to error 'Function `RegionDuplicate' implicitly converted to pointer' gcc 
refuse to accept it...

-- 
Pali Rohár
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[PATCH 19/32] dell-laptop: Port to new backlight interface selection API

[Pali Rohár]

On Thursday 11 June 2015 14:29:24 Hans de Goede wrote:
> Hi,
> 
> On 11-06-15 13:47, Pali Rohár wrote:
> >On Wednesday 10 June 2015 15:01:19 Hans de Goede wrote:
> >>Port the backlight selection logic to the new backlight interface
> >>selection API.
> >>
> >>Signed-off-by: Hans de Goede 
> >>---
> >>  drivers/platform/x86/dell-laptop.c | 6 ++
> >>  1 file changed, 2 insertions(+), 4 deletions(-)
> >>
> >>diff --git a/drivers/platform/x86/dell-laptop.c 
> >>b/drivers/platform/x86/dell-laptop.c
> >>index d688d80..db2e031 100644
> >>--- a/drivers/platform/x86/dell-laptop.c
> >>+++ b/drivers/platform/x86/dell-laptop.c
> >>@@ -31,6 +31,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >>+#include 
> >>  #include "../../firmware/dcdbas.h"
> >>
> >>  #define BRIGHTNESS_TOKEN 0x7d
> >>@@ -1921,10 +1922,7 @@ static int __init dell_init(void)
> >>_debugfs_fops);
> >>
> >>  #ifdef CONFIG_ACPI
> >>-   /* In the event of an ACPI backlight being available, don't
> >>-* register the platform controller.
> >>-*/
> >>-   if (acpi_video_backlight_support())
> >>+   if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
> >>return 0;
> >>  #endif
> >>
> >
> >Now I'm thinking... Is this correct condition? And do we need it? This
> >Dell backlight interface works even if ACPI or intel i915 driver
> >controls backlight. Why we should prevent dell-laptop.ko to register
> >Dell backlight interface if ACPI video already register one? And why not
> >prevent when intel i915 driver register another?
> 
> 3 things:
> 
> 1) This is mostly a cleanup series, it does not make any behavioral
> changes (other then renaming the kernelcmdline option and we've
> already discussed fixing that).
> 
> 2) All 3 drivers ultimately bit-bang the same hardware, we really should
> have only one driver banging the hardware, so
>   if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
>   return 0;
> 
> Definitely is the right thing todo here.
> 
> 3) You're right that the intel_backlight still registering even if
> acpi_video_get_backlight_type() != acpi_backlight_native is weird, but
> that is how it was before this series, and userspace prefers firmware
> type backlight sysfs entries over platform /raw ones so it will
> automatically pick the right one.  We should consider not registering
> the backlight sysfs class interface from the intel code when
> acpi_video_get_backlight_type() != acpi_backlight_native but that is
> something for later...
> 
> Regards,
> 
> Hans

Ok. This patch series is just refactor/cleanup which does not change
functional behavior. I'm ok with this dell-laptop change, so you can add
my Acked-By.

Once you will create new patches for backlight (maybe for intel i915),
please CC me, so I can discuss about them too.

-- 
Pali Rohár
pali.rohar at gmail.com

[PATCH 20/32] dell-wmi: Port to new backlight interface selection API

[Pali Rohár]

On Thursday 11 June 2015 14:19:11 Hans de Goede wrote:
> Hi,
> 
> On 11-06-15 13:43, Pali Rohár wrote:
> >On Wednesday 10 June 2015 15:01:20 Hans de Goede wrote:
> >>Port the backlight selection logic to the new backlight interface
> >>selection API.
> >>
> >>Signed-off-by: Hans de Goede 
> >>---
> >>  drivers/platform/x86/dell-wmi.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/drivers/platform/x86/dell-wmi.c 
> >>b/drivers/platform/x86/dell-wmi.c
> >>index 6512a06..f2d77fe 100644
> >>--- a/drivers/platform/x86/dell-wmi.c
> >>+++ b/drivers/platform/x86/dell-wmi.c
> >>@@ -35,6 +35,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >>+#include 
> >>
> >>  MODULE_AUTHOR("Matthew Garrett ");
> >>  MODULE_DESCRIPTION("Dell laptop WMI hotkeys driver");
> >>@@ -397,7 +398,7 @@ static int __init dell_wmi_init(void)
> >>}
> >>
> >>dmi_walk(find_hk_type, NULL);
> >>-   acpi_video = acpi_video_backlight_support();
> >>+   acpi_video = acpi_video_get_backlight_type() != acpi_backlight_vendor;
> >>
> >>err = dell_wmi_input_setup();
> >>if (err)
> >
> >Hello,
> >
> >to make sure that nothing will be broken I will try to explain current
> >code. Variable acpi_video is global boolean (for this module) and when
> >is set to true it is expected that ACPI generate brightness up/down key
> >events via ACPI input device. When is acpi_video boolean variable is set
> >to false then ACPI input device should not send brightness up/down keys
> >to userspace. And dell-wmi.ko driver send those two keys via dell-wmi
> >input device.
> 
> I know.
> 
> >So please check that your change does not change above behaviour.
> 
> I've already checked this.
> 

Ok, then this patch is fine for me. Add my Acked-by or Reviewed-by.

> > Maybe it would make sense to rename "acpi_video" variable to something 
> > better.
> 
> There is another driver which has a similar construction. I believe that it
> would be good to add an acpi_video_handles_key_presses() helper to the
> acpi-video code which can be used for this instead of abusing
> acpi_video_get_backlight_type() for this. I've put this on my todo list
> to do as a further cleanup once the initial series is merged.
> 
> Regards,
> 
> Hans

Ok, thanks! acpi_video_handles_key_presses() has really better name.

-- 
Pali Rohár
pali.rohar at gmail.com

[PATCH 07/32] acpi-video-detect: Rewrite backlight interface selection logic

[Pali Rohár]

On Thursday 11 June 2015 11:29:24 Hans de Goede wrote:
> Hi,
> 
> On 11-06-15 11:19, Pali Rohár wrote:
> >On Wednesday 10 June 2015 15:01:07 Hans de Goede wrote:
> >>Currently we have 2 kernel commandline options + dmi-quirks in 3 places all
> >>interacting (in interesting ways) to select which which backlight interface
> >>to use. On the commandline we've acpi_backlight=[video|vendor] and
> >>video.use_native_backlight=[0|1]. DMI quirks we have in
> >>acpi/video-detect.c, acpi/video.c and drivers/platform/x86/*.c .
> >>
> >>This commit is the first step to cleaning this up, replacing the 2 cmdline
> >>options with just acpi_video.backlight=[video|vendor|native|none], and
> >>adding a new API to video_detect.c to reflect this.
> >>
> >>Follow up commits will also move other related code, like unregistering the
> >>acpi_video backlight interface if it was registered before other drivers
> >>which take priority over it are loaded, to video_detect.c where this
> >>logic really belongs.
> >>
> >>Signed-off-by: Hans de Goede 
> >
> >Hello,
> >
> >lot of people are using acpi_backlight parameter in kernel cmdline to
> >fix some of problems. I would like to see this parameter still working
> >and to not break existing configuration. E.g acpi_backlight=vendor to
> >use dell-laptop.ko or thinkpad_acpi.ko backlight.
> 
> I would have like to keep acpi_backlight= for that exact same reason,
> but that is not possible while keeping acpi_video as a module.
> 
> Thinking more about this, this is not strictly true, we could make
> some other (core) part of the acpi code use __setup to get the
> acpi_backlight= value and have that part export the value for use
> in the acpi_video module. This is not really pretty, but I think it
> may be the best way to solve this.
> 

This solution should work. It is not nice, but current mess of backlight
drivers, acpi, etc, is not nice too. It will help users who already know
(or read on internet/forums/discussions) acpi_backlight= parameter...

> >It is still nightmare to get laptop panel backlight working on different
> >(broken) laptops
> 
> Well one reason it is a nightmare is because there are too many
> backlight drivers fighting for control and there is not an easy
> way to tell the kernel only register this one, this is exactly
> what this patch-set is trying to address :)  People may still
> need to use a cmdline option but now there is only one option to
> play with.
> 

It is not only that. Sometimes there are three possible ways how to
control backlight (vendor driver, acpi driver, gpu driver). And all
those driver can work, but some of them works "better".

E.g in my case on Dell Latitude E6440 all three drivers can register
backlight interface and export it to userspace via sysfs.

But the best option for *me* is to use one from dell-laptop.ko because
it has good granularity of levels for controlling backlight. Intel one
has too many levels and does not fit some linear distribution (which I
would like to see). ACPI video.ko sometimes does not work correctly with
KDE4 setting -- sometimes I need to press brightness key more times to
take effect. I do not know if this is problem of KDE or ACPI or
whatever. For me for my current desktop & kernel setup is the best
solution to use dell-laptop.ko with acpi_backlight=vendor param. I do
not have to debug or change anything, just add one param to cmdline.

And I think other users (without programming knowledge) who need
immediately working laptop will use same option as me.

> > and people learnt to try to use acpi_backlight
> > parameter for quit/hot fixing these problems.
> 
> People who need to pass a kernel commandline option really should
> report a bug once they have figured out what option to use.
> 

This is good assumption, but do not forget that there are people who:

1) do not have time to trying find out where to report bug and how
2) do not know how to report bug
3) even do not know that they can do something (like for MS systems)

> Fedora users are getting pretty good at this as the Fedora kernel
> maintainers punt all such bug reports to me and I properly deal
> with them verifying the users solution is sane and then submitting
> a patch with a dmi based quirk for the users laptop upstream.
> 
> > Upgrading kernel (if you
> >remove acpi_backlight parameter) just break it again.
> 
> I think that is actually (partially) a good thing, as said people
> who rely on cmdline workarounds should file bugs, so that we can
> add a quirk. Had the users done so, the quirk would be long in
> place and the changing of the cmdline option name would not be
> an issue for them.
> 
> I realize that this knife cuts both ways, and that this will
> cause unhappy users, as said if it had been possible to not change
> the cmdline option name in a clean way I would have done so.
> 
> If everyone agrees with the solution I've outlined above, we
> can actually make it so as to not break things for users
> who's setup relies on 

[PATCH 19/32] dell-laptop: Port to new backlight interface selection API

[Pali Rohár]

On Wednesday 10 June 2015 15:01:19 Hans de Goede wrote:
> Port the backlight selection logic to the new backlight interface
> selection API.
> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/platform/x86/dell-laptop.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/platform/x86/dell-laptop.c 
> b/drivers/platform/x86/dell-laptop.c
> index d688d80..db2e031 100644
> --- a/drivers/platform/x86/dell-laptop.c
> +++ b/drivers/platform/x86/dell-laptop.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "../../firmware/dcdbas.h"
>  
>  #define BRIGHTNESS_TOKEN 0x7d
> @@ -1921,10 +1922,7 @@ static int __init dell_init(void)
>   _debugfs_fops);
>  
>  #ifdef CONFIG_ACPI
> - /* In the event of an ACPI backlight being available, don't
> -  * register the platform controller.
> -  */
> - if (acpi_video_backlight_support())
> + if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
>   return 0;
>  #endif
>  

Now I'm thinking... Is this correct condition? And do we need it? This
Dell backlight interface works even if ACPI or intel i915 driver
controls backlight. Why we should prevent dell-laptop.ko to register
Dell backlight interface if ACPI video already register one? And why not
prevent when intel i915 driver register another?

-- 
Pali Rohár
pali.rohar at gmail.com

[PATCH 20/32] dell-wmi: Port to new backlight interface selection API

[Pali Rohár]

On Wednesday 10 June 2015 15:01:20 Hans de Goede wrote:
> Port the backlight selection logic to the new backlight interface
> selection API.
> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/platform/x86/dell-wmi.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
> index 6512a06..f2d77fe 100644
> --- a/drivers/platform/x86/dell-wmi.c
> +++ b/drivers/platform/x86/dell-wmi.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  MODULE_AUTHOR("Matthew Garrett ");
>  MODULE_DESCRIPTION("Dell laptop WMI hotkeys driver");
> @@ -397,7 +398,7 @@ static int __init dell_wmi_init(void)
>   }
>  
>   dmi_walk(find_hk_type, NULL);
> - acpi_video = acpi_video_backlight_support();
> + acpi_video = acpi_video_get_backlight_type() != acpi_backlight_vendor;
>  
>   err = dell_wmi_input_setup();
>   if (err)

Hello,

to make sure that nothing will be broken I will try to explain current
code. Variable acpi_video is global boolean (for this module) and when
is set to true it is expected that ACPI generate brightness up/down key
events via ACPI input device. When is acpi_video boolean variable is set
to false then ACPI input device should not send brightness up/down keys
to userspace. And dell-wmi.ko driver send those two keys via dell-wmi
input device.

So please check that your change does not change above behaviour. Maybe
it would make sense to rename "acpi_video" variable to something better.

-- 
Pali Rohár
pali.rohar at gmail.com

[PATCH 07/32] acpi-video-detect: Rewrite backlight interface selection logic

[Pali Rohár]

On Wednesday 10 June 2015 15:01:07 Hans de Goede wrote:
> Currently we have 2 kernel commandline options + dmi-quirks in 3 places all
> interacting (in interesting ways) to select which which backlight interface
> to use. On the commandline we've acpi_backlight=[video|vendor] and
> video.use_native_backlight=[0|1]. DMI quirks we have in
> acpi/video-detect.c, acpi/video.c and drivers/platform/x86/*.c .
> 
> This commit is the first step to cleaning this up, replacing the 2 cmdline
> options with just acpi_video.backlight=[video|vendor|native|none], and
> adding a new API to video_detect.c to reflect this.
> 
> Follow up commits will also move other related code, like unregistering the
> acpi_video backlight interface if it was registered before other drivers
> which take priority over it are loaded, to video_detect.c where this
> logic really belongs.
> 
> Signed-off-by: Hans de Goede 

Hello,

lot of people are using acpi_backlight parameter in kernel cmdline to
fix some of problems. I would like to see this parameter still working
and to not break existing configuration. E.g acpi_backlight=vendor to
use dell-laptop.ko or thinkpad_acpi.ko backlight.

It is still nightmare to get laptop panel backlight working on different
(broken) laptops and people learnt to try to use acpi_backlight
parameter for quit/hot fixing these problems. Upgrading kernel (if you
remove acpi_backlight parameter) just break it again.

-- 
Pali Rohár
pali.rohar at gmail.com

[Intel-gfx] 3.19-rc1 errors when opening LID

[Pali Rohár]

Hello,

in attachment is output of ls -l /sys/bus/acpi/devices from both 
3.13 and 3.19 kernels.

Anyway Gabriele Mazzotta wrote me that new acpi devices could be 
created after commit faae404ebdc6bba (ACPICA: Add "Windows 2013" 
string to _OSI support).

Maybe this another output could help you:

$ cat /sys/bus/acpi/devices/INT33C5\:00/status
0
$ cat /sys/bus/acpi/devices/INT33C5\:00/power_state
(unknown)

Device INT33C5 is in that dmesg log:
acpi INT33C5:00: Cannot transition to non-D0 state from D3

And status 0 in sysnode could indicate that acpi device is not 
present right?

On Thursday 25 December 2014 17:59:36 nick wrote:
> Pali,
> This was probably to either add better power management or
> enable some new features related to acpi. Can you send me the
> files they created in kernel 3.19 r1 as I can probably trace
> it back to the bad commit. Regards Nick
> 
> On 2014-12-25 03:48 AM, Pali Rohár wrote:
> > I know how to use git... first I wanted to report errors
> > because maybe it could be known problem or somebody else
> > can come with quick patch even without bisetcing (like for
> > other problems which I reported).
> > 
> > Anyway those acpi devices which are mentioned in log do not
> > exist in 3.13 kernel (I do not see them in /sys/devices)
> > 
> > Any idea why 3.19 kernel create new acpi devices which 3.13
> > kernel did not?
> > 
> > On Thursday 25 December 2014 05:28:27 nick wrote:
> >> Pali,
> >> Do you known how to run git bisect as this is probably the
> >> best way to continue. Otherwise, I can teach you how it's
> >> not hard if your willing to learn :). Cheers Nick
> >> 
> >> On 2014-12-24 01:51 PM, Pali Rohár wrote:
> >>> Hello!
> >>> 
> >>> With new 3.19-rc1 kernel every time when I open LID on my
> >>> laptop, kernel prints these error lines to dmesg:
> >>> 
> >>> [25566.368133] [drm:hsw_unclaimed_reg_detect.isra.6
> >>> [i915]] *ERROR* Unclaimed register detected. Please use
> >>> the i915.mmio_debug=1 to debug this problem.
> >>> [25566.368134] [drm:intel_uncore_check_errors [i915]]
> >>> *ERROR* Unclaimed register before interrupt
> >>> [25566.368192]
> >>> [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR*
> >>> Unclaimed register detected. Please use the
> >>> i915.mmio_debug=1 to debug this problem. [25566.368232]
> >>> [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR*
> >>> Unclaimed register detected. Please use the
> >>> i915.mmio_debug=1 to debug this problem.<4>[25568.446011]
> >>> i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has
> >>> bogus alignment
> >>> [25568.447018] pci_bus :02: Allocating resources
> >>> [25568.447055] pci_bus :03: Allocating resources
> >>> [25568.447135] pci_bus :04: Allocating resources
> >>> [25568.447168] pci_bus :05: Allocating resources
> >>> [25568.447195] pci_bus :06: Allocating resources
> >>> [25568.447228] pci_bus :0e: Allocating resources
> >>> [25568.447323] i915 :00:02.0: BAR 6: [??? 0x
> >>> flags 0x2] has bogus alignment [25568.447557] i915
> >>> :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus
> >>> alignment [25568.447735] i915 :00:02.0: BAR 6: [???
> >>> 0x flags 0x2] has bogus alignment [25568.447847]
> >>> i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has
> >>> bogus alignment [25568.448399] i915 :00:02.0: BAR 6:
> >>> [??? 0x flags 0x2] has bogus alignment
> >>> [25568.448438] i915 :00:02.0: BAR 6: [??? 0x
> >>> flags 0x2] has bogus alignment [25568.448566] acpi
> >>> MSFT:00: Cannot transition to power state D3cold for
> >>> parent in (unknown) [25568.448572] acpi INT33C2:00: Cannot
> >>> transition to non-D0 state from D3 [25568.448577] acpi
> >>> MSFT0002:00: Cannot transition to power state D3cold for
> >>> parent in (unknown) [25568.448581] acpi ELAN1010:00:
> >>> Cannot transition to power state D3cold for parent in
> >>> (unknown) [25568.448587] acpi INT33C3:00: Cannot
> >>> transition to non-D0 state from D3 [25568.448590] acpi
> >>> INT33C0:00: Cannot transition to non-D0 state from D3
> >>> [25568.448594] acpi INT33C1:00: Cannot transition to
> >>> non-D0 state from D3 [25568.448598] acpi INT33C4:00:
> >>> Cannot transition to non-D0 state from D3 [25568.448602]
> >>> acpi INT33C5:00: Cannot transition to non-D0 state from
> >>> D3 [25568.448623] acpi device:41: Cannot transition to
> >>> power state D3cold for parent in (unknown) [25568.448627]
> >>> acpi INT33C6:00: Cannot transition to non-D0 state from
> >>> D3 [25568.448890] pci_bus :01: Allocating resources
> >>> [25568.448905] i915 :00:02.0: BAR 6: [??? 0x
> >>> flags 0x2] has bogus alignment [25568.449064] i915
> >>> :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus
> >>> alignment [25568.449472] i915 :00:02.0: BAR 6: [???
> >>> 0x flags 0x2] has bogus alignment
> >>> 
> >>> With older kernel (3.13) I do not see these errors, so it
> >>> is regression. Can you look at it? If it is needed, I can
> >>> provide 

3.19-rc1 errors when opening LID

[Pali Rohár]

On Friday 26 December 2014 16:12:49 Rafael J. Wysocki wrote:
> On Wednesday, December 24, 2014 07:51:48 PM Pali Rohár wrote:
> > --nextPart5943893.pKyMBm5Emp
> > Content-Type: Text/Plain;
> > 
> >   charset="utf-8"
> > 
> > Content-Transfer-Encoding: quoted-printable
> > 
> > Hello!
> > 
> > With new 3.19-rc1 kernel every time when I open LID on my
> > laptop, kernel pr=
> 
> > ints these error lines to dmesg:
> Does your syste suspend when the lid is closed and resume when
> it is open?
> 

No, I disabled all autosuspend and autohibernate settings. When I 
close LID system is running.

> 
> > [25568.448566] acpi MSFT:00: Cannot transition to power
> > state D3cold fo= r parent in (unknown)
> > [25568.448572] acpi INT33C2:00: Cannot transition to non-D0
> > state from D3 [25568.448577] acpi MSFT0002:00: Cannot
> > transition to power state D3cold fo= r parent in (unknown)
> > [25568.448581] acpi ELAN1010:00: Cannot transition to power
> > state D3cold fo= r parent in (unknown)
> > [25568.448587] acpi INT33C3:00: Cannot transition to non-D0
> > state from D3 [25568.448590] acpi INT33C0:00: Cannot
> > transition to non-D0 state from D3 [25568.448594] acpi
> > INT33C1:00: Cannot transition to non-D0 state from D3
> > [25568.448598] acpi INT33C4:00: Cannot transition to non-D0
> > state from D3 [25568.448602] acpi INT33C5:00: Cannot
> > transition to non-D0 state from D3 [25568.448623] acpi
> > device:41: Cannot transition to power state D3cold for =
> > parent in (unknown)
> > [25568.448627] acpi INT33C6:00: Cannot transition to non-D0
> > state from D3
> 
> All of the above mean that power transitions were not carried
> out for some devices, because they were in unexpected power
> states to start with.
> 
> They are devices on the Intel LPSS as far as I can say (CCing
> Mika and Andy).
> 

Just to note: all above acpi devices do not exist in 3.13 kernel, 
at least I do not see them in /sys/bus/acpi/.

> > [25568.448890] pci_bus :01: Allocating resources
> > [25568.448905] i915 :00:02.0: BAR 6: [??? 0x
> > flags 0x2] has bog= us alignment
> > [25568.449064] i915 :00:02.0: BAR 6: [??? 0x
> > flags 0x2] has bog= us alignment
> > [25568.449472] i915 :00:02.0: BAR 6: [??? 0x
> > flags 0x2] has bog= us alignment
> > 
> > With older kernel (3.13) I do not see these errors, so it is
> > regression.
> 
> It only is a regression if it leads to functional problems. 
> Do you see any?
> 

Ok. I do not see functional problems, but I see above messages in 
dmesg log every time when I open LID.

> > Ca=n you look at it? If it is needed, I can provide other
> > logs, ACPI/DSTD dump= s, etc.
> 
> It looks like 3.13 didn't try to use some devices that are now
> used in 3.19-rc1 and something doesn't work entirely as
> expected.

-- 
Pali Rohár
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[Intel-gfx] 3.19-rc1 errors when opening LID

[Pali Rohár]

I know how to use git... first I wanted to report errors because 
maybe it could be known problem or somebody else can come with 
quick patch even without bisetcing (like for other problems which 
I reported).

Anyway those acpi devices which are mentioned in log do not exist 
in 3.13 kernel (I do not see them in /sys/devices)

Any idea why 3.19 kernel create new acpi devices which 3.13 
kernel did not?

On Thursday 25 December 2014 05:28:27 nick wrote:
> Pali,
> Do you known how to run git bisect as this is probably the
> best way to continue. Otherwise, I can teach you how it's not
> hard if your willing to learn :). Cheers Nick
> 
> On 2014-12-24 01:51 PM, Pali Rohár wrote:
> > Hello!
> > 
> > With new 3.19-rc1 kernel every time when I open LID on my
> > laptop, kernel prints these error lines to dmesg:
> > 
> > [25566.368133] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]]
> > *ERROR* Unclaimed register detected. Please use the
> > i915.mmio_debug=1 to debug this problem. [25566.368134]
> > [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed
> > register before interrupt [25566.368192]
> > [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR*
> > Unclaimed register detected. Please use the
> > i915.mmio_debug=1 to debug this problem. [25566.368232]
> > [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR*
> > Unclaimed register detected. Please use the
> > i915.mmio_debug=1 to debug this problem.<4>[25568.446011]
> > i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has
> > bogus alignment
> > [25568.447018] pci_bus :02: Allocating resources
> > [25568.447055] pci_bus :03: Allocating resources
> > [25568.447135] pci_bus :04: Allocating resources
> > [25568.447168] pci_bus :05: Allocating resources
> > [25568.447195] pci_bus :06: Allocating resources
> > [25568.447228] pci_bus :0e: Allocating resources
> > [25568.447323] i915 :00:02.0: BAR 6: [??? 0x
> > flags 0x2] has bogus alignment [25568.447557] i915
> > :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus
> > alignment [25568.447735] i915 :00:02.0: BAR 6: [???
> > 0x flags 0x2] has bogus alignment [25568.447847]
> > i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has
> > bogus alignment [25568.448399] i915 :00:02.0: BAR 6:
> > [??? 0x flags 0x2] has bogus alignment
> > [25568.448438] i915 :00:02.0: BAR 6: [??? 0x
> > flags 0x2] has bogus alignment [25568.448566] acpi
> > MSFT:00: Cannot transition to power state D3cold for
> > parent in (unknown) [25568.448572] acpi INT33C2:00: Cannot
> > transition to non-D0 state from D3 [25568.448577] acpi
> > MSFT0002:00: Cannot transition to power state D3cold for
> > parent in (unknown) [25568.448581] acpi ELAN1010:00: Cannot
> > transition to power state D3cold for parent in (unknown)
> > [25568.448587] acpi INT33C3:00: Cannot transition to non-D0
> > state from D3 [25568.448590] acpi INT33C0:00: Cannot
> > transition to non-D0 state from D3 [25568.448594] acpi
> > INT33C1:00: Cannot transition to non-D0 state from D3
> > [25568.448598] acpi INT33C4:00: Cannot transition to non-D0
> > state from D3 [25568.448602] acpi INT33C5:00: Cannot
> > transition to non-D0 state from D3 [25568.448623] acpi
> > device:41: Cannot transition to power state D3cold for
> > parent in (unknown) [25568.448627] acpi INT33C6:00: Cannot
> > transition to non-D0 state from D3 [25568.448890] pci_bus
> > :01: Allocating resources [25568.448905] i915
> > :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus
> > alignment [25568.449064] i915 :00:02.0: BAR 6: [???
> > 0x flags 0x2] has bogus alignment [25568.449472]
> > i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has
> > bogus alignment
> > 
> > With older kernel (3.13) I do not see these errors, so it is
> > regression. Can you look at it? If it is needed, I can
> > provide other logs, ACPI/DSTD dumps, etc.
> > 
> > 
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Pali Rohár
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

3.19-rc1 errors when opening LID

[Pali Rohár]

Hello!

With new 3.19-rc1 kernel every time when I open LID on my laptop, kernel prints 
these error lines to dmesg:

[25566.368133] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed 
register detected. Please use the i915.mmio_debug=1 to debug this problem.
[25566.368134] [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed 
register before interrupt
[25566.368192] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed 
register detected. Please use the i915.mmio_debug=1 to debug this problem.
[25566.368232] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed 
register detected. Please use the i915.mmio_debug=1 to debug this 
problem.<4>[25568.446011] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] 
has bogus alignment
[25568.447018] pci_bus :02: Allocating resources
[25568.447055] pci_bus :03: Allocating resources
[25568.447135] pci_bus :04: Allocating resources
[25568.447168] pci_bus :05: Allocating resources
[25568.447195] pci_bus :06: Allocating resources
[25568.447228] pci_bus :0e: Allocating resources
[25568.447323] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus 
alignment
[25568.447557] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus 
alignment
[25568.447735] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus 
alignment
[25568.447847] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus 
alignment
[25568.448399] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus 
alignment
[25568.448438] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus 
alignment
[25568.448566] acpi MSFT:00: Cannot transition to power state D3cold for 
parent in (unknown)
[25568.448572] acpi INT33C2:00: Cannot transition to non-D0 state from D3
[25568.448577] acpi MSFT0002:00: Cannot transition to power state D3cold for 
parent in (unknown)
[25568.448581] acpi ELAN1010:00: Cannot transition to power state D3cold for 
parent in (unknown)
[25568.448587] acpi INT33C3:00: Cannot transition to non-D0 state from D3
[25568.448590] acpi INT33C0:00: Cannot transition to non-D0 state from D3
[25568.448594] acpi INT33C1:00: Cannot transition to non-D0 state from D3
[25568.448598] acpi INT33C4:00: Cannot transition to non-D0 state from D3
[25568.448602] acpi INT33C5:00: Cannot transition to non-D0 state from D3
[25568.448623] acpi device:41: Cannot transition to power state D3cold for 
parent in (unknown)
[25568.448627] acpi INT33C6:00: Cannot transition to non-D0 state from D3
[25568.448890] pci_bus :01: Allocating resources
[25568.448905] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus 
alignment
[25568.449064] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus 
alignment
[25568.449472] i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bogus 
alignment

With older kernel (3.13) I do not see these errors, so it is regression. Can 
you look at it? If it is needed, I can provide other logs, ACPI/DSTD dumps, etc.

-- 
Pali Rohár
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Linux 3.19-rc1: i915.ko error messages at boot

[Pali Rohár]

lspci output:
00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core 
Processor Integrated Graphics 
Controller [8086:0416] (rev 06)

dmesg output:
[2.379847] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed 
register detected. Please use the 
i915.mmio_debug=1 to debug this problem.
[2.379847] [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed 
register before interrupt
[2.379868] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed 
register detected. Please use the 
i915.mmio_debug=1 to debug this problem.
[2.379869] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed 
register detected. Please use the 
i915.mmio_debug=1 to debug this problem.
[2.430637] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed 
register detected. Please use the 
i915.mmio_debug=1 to debug this problem.<3>[2.430649] 
[drm:intel_uncore_check_errors [i915]] *ERROR* 
Unclaimed register before interrupt
[2.430756] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed 
register detected. Please use the 
i915.mmio_debug=1 to debug this problem.
[2.430817] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed 
register detected. Please use the 
i915.mmio_debug=1 to debug this problem.[drm:hsw_unclaimed_reg_detect.isra.6 
[i915]] *ERROR* Unclaimed register 
detected. Please use the i915.mmio_debug=1 to debug this problem.
[2.430948] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed 
register detected. Please use the 
i915.mmio_debug=1 to debug this problem.[drm:hsw_unclaimed_reg_detect.isra.6 
[i915]] *ERROR* Unclaimed register 
detected. Please use the i915.mmio_debug=1 to debug this problem.
[2.619114] [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed 
register before interrupt
[2.619213] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed 
register detected. Please use the 
i915.mmio_debug=1 to debug this problem.
[2.619275] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed 
register detected. Please use the 
i915.mmio_debug=1 to debug this problem.[drm:hsw_unclaimed_reg_detect.isra.6 
[i915]] *ERROR* Unclaimed register 
detected. Please use the i915.mmio_debug=1 to debug this problem.
[2.626522] [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed 
register before interrupt
[2.626616] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed 
register detected. Please use the 
i915.mmio_debug=1 to debug this problem.
[2.626678] [drm:hsw_unclaimed_reg_detect.isra.6 [i915]] *ERROR* Unclaimed 
register detected. Please use the 
i915.mmio_debug=1 to debug this problem.<6>[2.633412] AVX2 version of 
gcm_enc/dec engaged.

-- 
Pali Rohár
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

ACPI/i915: Cannot configure display brightness on Dell Latitude E6440

[Pali Rohár]

On Thursday 25 September 2014 05:15:35 Aaron Lu wrote:
> Hi Hans,
> 
> Thanks for following up and explaining the situation to Pali.
> 
> On 09/25/2014 02:21 AM, Pali Roh?r wrote:
> > On Wednesday 24 September 2014 16:34:21 Hans de Goede wrote:
> >> Ok, so the dell-laptop interface is just an obsolete
> >> wrapper around the i915 opregion code, which shows that
> >> the right interface to use is the i915 one, which we do if
> >> you don't specify any kernel commandline parameters, case
> >> closed.
> >> 
> >> Regards,
> >> 
> >> Hans
> > 
> > Nope, its not closed.
> > 
> > Still i915 interface has problem with setting backlight. It
> > exports lot of levels which turning display off. Which
> > breaking exiting applications for configuring display
> > brightness. This is still big regression as black screen is
> > not want people want to see.
> > 
> > Driver dell-laptop has exported only few - not thousands
> > level (which is insane) and only usefull levels (not lot of
> > levels which turn display off).
> > 
> > So for this reason using i915 backlight interface is not
> > possible and also Dell (for E6440) set kernel param
> > acpi_backlight=vendor to use dell_laptop module for
> > controlling brightness.
> > 
> > On my laptop E6440 is better for using dell-laptop and not
> > acpi or i915.
> 
> Hi Pali,
> 
> Please test this patch:
> 

Hi! this patch fixing this problem. With acpi_backlight=vendor 
dell-laptop will register backlight interface which is working 
again. Also userspace application dellLcdBrightness is working 
now without problem.

Can you going to send this patch also to stable 3.16 branch? As 
it fixing commit 0b9f7d93ca6109048a4eb06332b666b6e29df4fe.

> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_opregion.c index
> ca52ad2ae7d1..15534345bd57 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -396,6 +396,24 @@ int intel_opregion_notify_adapter(struct
> drm_device *dev, pci_power_t state) return -EINVAL;
>  }
> 
> +/*
> + * Some of the Thinkpads' firmware will issue a backlight
> change operation + * region request unconditionally on AC
> plug/unplug, this is undesirable and + * should be ignored.
> Then there is a Dell laptop whose vendor backlight + *
> interface also makes use of operation region request to
> change backlight + * level and we have to keep it work. The
> rule used here is: if the vendor + * backlight interface is
> not in use and the ACPI backlight interface is + * broken, we
> ignore the requests; oterwise, we keep processing them. + */
> +static bool should_ignore_backlight_request(void)
> +{
> + if (acpi_video_backlight_support() &&
> + !acpi_video_verify_backlight_support())
> + return true;
> +
> + return false;
> +}
> +
>  static u32 asle_set_backlight(struct drm_device *dev, u32
> bclp) {
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -404,11 +422,7 @@ static u32 asle_set_backlight(struct
> drm_device *dev, u32 bclp)
> 
>   DRM_DEBUG_DRIVER("bclp = 0x%08x\n", bclp);
> 
> - /*
> -  * If the acpi_video interface is not supposed to be used,
> don't -* bother processing backlight level change requests
> from firmware. -   */
> - if (!acpi_video_verify_backlight_support()) {
> + if (should_ignore_backlight_request()) {
>   DRM_DEBUG_KMS("opregion backlight request ignored\n");
>   return 0;
>   }

-- 
Pali Roh?r
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

ACPI/i915: Cannot configure display brightness on Dell Latitude E6440

[Pali Rohár]

On Wednesday 24 September 2014 16:34:21 Hans de Goede wrote:
> Hi,
> 
> On 09/24/2014 02:53 PM, Pali Roh?r wrote:
> > On Wednesday 24 September 2014 14:04:36 Hans de Goede wrote:
> >> Hi,
> >> 
> >> On 09/24/2014 11:14 AM, Pali Roh?r wrote:
> >>> On Wednesday 24 September 2014 10:59:41 Pali Roh?r wrote:
>  On Wednesday 24 September 2014 10:19:38 Hans de Goede 
wrote:
> > Hi,
> > 
> > On 09/23/2014 10:44 PM, Pali Roh?r wrote:
> >> On Tuesday 23 September 2014 22:31:31 you wrote:
> >>> Hi,
> >>> 
> >>> On 09/23/2014 10:06 PM, Pali Roh?r wrote:
>  Hello,
>  
>  after big changes in acpi video/i915 code I cannot
>  change display brightness on my Dell Latitude E6440
>  with kernel 3.17-rc6. With kernel 3.13 everything
>  worked fine.
>  
>  More information about this problem:
>  
>  For configuring brightness on Dell laptops there are
>  4 ways: 1) via acpi video driver
>  2) via dell-laptop driver
>  3) via i915 drm driver
>  4) from userspace with special dell SMI call
>  
>  (e.g with program dellLcdBrightness from
>  libsmbios package)
>  
>  Methods 2) and 4) are same, both making special SMI
>  call and Bios handing this request (just 2 is from
>  kernel and 4 from userspace)
>  
>  Method 1) via acpi video driver working, but is not
>  perfect. Driver can be used to change brightness (but
>  only some levels, probably this depends on acpi/DSDT
>  tables), but cannot be used to retrieve current
>  brightness (when BIOS/SMI change brightness acpi
>  driver report old incorrect value). So I prefer
>  dell-laptop driver instead acpi video.
>  
>  Method 3) working even with 3.17-rc6 kernel but
>  because that backlight device exported by i915 is
>  marked as raw, desktop programs prefer to use other
>  devices.
>  
>  Moreover it looks like that methods 1) 2) and 4) just
>  forward request to method 3). So in any cased
>  brightness is changed by i915 drm driver.
>  
>  I'm not sure (correct me if I'm wrong!) but I think
>  that intel i915 drm driver accept changes (file
>  intel_opregion.c) only if acpi function
>  acpi_video_verify_backlight_support() returns true.
>  
>  Function acpi_video_verify_backlight_support()
>  returns true iff: function
>  acpi_video_backlight_support() returns true AND at
>  least one of these functions returns false:
>  acpi_osi_is_win8()
>  acpi_video_use_native_backlight()
>  backlight_device_registered(BACKLIGHT_RAW)
>  
>  On my notebook acpi_osi_is_win8() returns true (as is
>  win8 compliant),
>  backlight_device_registered(BACKLIGHT_RAW) returns
>  true as I'm using intel i915 drm driver with raw
>  backlight device and
>  acpi_video_use_native_backlight() returns true/false
>  depending on
>  "video.use_native_backlight" kernel param. Default is
>  true.
>  
>  So if I want to have working acpi video driver with
>  display brightness support I need to boot kernel with
>  param: "video.use_native_backlight=0". I tested it
>  with kernel 3.17-rc6 and this param really enabled
>  display brightness support via acpi video driver --
>  which is good.
>  
>  Driver dell-laptop creating backligh device for
>  brightness control only if
>  acpi_video_backlight_support() returns false. There
>  is complicated condition for it and when kernel is
>  booted with "video.use_native_backlight=0" that
>  function returns true.
>  
>  So conclusion is: With current code in kernel
>  3.17-rc6 it is not possible to control brightness of
>  display with native driver dell-laptop on Dell
>  Latitude E6440 (and probably on others too)!!!
>  
>  And Because laptop is win8 compliant and you create
>  decision to use native driver (instead acpi one) it
>  is not possible to control display brightness
>  without tweeks in kernel cmdline.
>  
>  As I wrote I would rather to use native dell-laptop
>  driver for controlling brightness, but it is not
>  possible.
>  
>  So how to solve this problem?
>  
>  Quick solution would be to set use_native_backlight
>  false for some Dell laptops which means, that acpi
>  video will be used and in this case intel i915 driver
>  will *not* drop backlight change request.
>  
>  Another solution could be to disable check in
>  dell_laptop 

ACPI/i915: Cannot configure display brightness on Dell Latitude E6440

[Pali Rohár]

On Wednesday 24 September 2014 14:04:36 Hans de Goede wrote:
> Hi,
> 
> On 09/24/2014 11:14 AM, Pali Roh?r wrote:
> > On Wednesday 24 September 2014 10:59:41 Pali Roh?r wrote:
> >> On Wednesday 24 September 2014 10:19:38 Hans de Goede wrote:
> >>> Hi,
> >>> 
> >>> On 09/23/2014 10:44 PM, Pali Roh?r wrote:
>  On Tuesday 23 September 2014 22:31:31 you wrote:
> > Hi,
> > 
> > On 09/23/2014 10:06 PM, Pali Roh?r wrote:
> >> Hello,
> >> 
> >> after big changes in acpi video/i915 code I cannot
> >> change display brightness on my Dell Latitude E6440
> >> with kernel 3.17-rc6. With kernel 3.13 everything
> >> worked fine.
> >> 
> >> More information about this problem:
> >> 
> >> For configuring brightness on Dell laptops there are 4
> >> ways: 1) via acpi video driver
> >> 2) via dell-laptop driver
> >> 3) via i915 drm driver
> >> 4) from userspace with special dell SMI call
> >> 
> >> (e.g with program dellLcdBrightness from libsmbios
> >> package)
> >> 
> >> Methods 2) and 4) are same, both making special SMI
> >> call and Bios handing this request (just 2 is from
> >> kernel and 4 from userspace)
> >> 
> >> Method 1) via acpi video driver working, but is not
> >> perfect. Driver can be used to change brightness (but
> >> only some levels, probably this depends on acpi/DSDT
> >> tables), but cannot be used to retrieve current
> >> brightness (when BIOS/SMI change brightness acpi driver
> >> report old incorrect value). So I prefer dell-laptop
> >> driver instead acpi video.
> >> 
> >> Method 3) working even with 3.17-rc6 kernel but because
> >> that backlight device exported by i915 is marked as
> >> raw, desktop programs prefer to use other devices.
> >> 
> >> Moreover it looks like that methods 1) 2) and 4) just
> >> forward request to method 3). So in any cased
> >> brightness is changed by i915 drm driver.
> >> 
> >> I'm not sure (correct me if I'm wrong!) but I think
> >> that intel i915 drm driver accept changes (file
> >> intel_opregion.c) only if acpi function
> >> acpi_video_verify_backlight_support() returns true.
> >> 
> >> Function acpi_video_verify_backlight_support() returns
> >> true iff: function acpi_video_backlight_support()
> >> returns true AND at least one of these functions
> >> returns false: acpi_osi_is_win8()
> >> acpi_video_use_native_backlight()
> >> backlight_device_registered(BACKLIGHT_RAW)
> >> 
> >> On my notebook acpi_osi_is_win8() returns true (as is
> >> win8 compliant),
> >> backlight_device_registered(BACKLIGHT_RAW) returns true
> >> as I'm using intel i915 drm driver with raw backlight
> >> device and acpi_video_use_native_backlight() returns
> >> true/false depending on
> >> "video.use_native_backlight" kernel param. Default is
> >> true.
> >> 
> >> So if I want to have working acpi video driver with
> >> display brightness support I need to boot kernel with
> >> param: "video.use_native_backlight=0". I tested it with
> >> kernel 3.17-rc6 and this param really enabled display
> >> brightness support via acpi video driver -- which is
> >> good.
> >> 
> >> Driver dell-laptop creating backligh device for
> >> brightness control only if
> >> acpi_video_backlight_support() returns false. There is
> >> complicated condition for it and when kernel is booted
> >> with "video.use_native_backlight=0" that function
> >> returns true.
> >> 
> >> So conclusion is: With current code in kernel 3.17-rc6
> >> it is not possible to control brightness of display
> >> with native driver dell-laptop on Dell Latitude E6440
> >> (and probably on others too)!!!
> >> 
> >> And Because laptop is win8 compliant and you create
> >> decision to use native driver (instead acpi one) it is
> >> not possible to control display brightness without
> >> tweeks in kernel cmdline.
> >> 
> >> As I wrote I would rather to use native dell-laptop
> >> driver for controlling brightness, but it is not
> >> possible.
> >> 
> >> So how to solve this problem?
> >> 
> >> Quick solution would be to set use_native_backlight
> >> false for some Dell laptops which means, that acpi
> >> video will be used and in this case intel i915 driver
> >> will *not* drop backlight change request.
> >> 
> >> Another solution could be to disable check in
> >> dell_laptop driver and add use_native_backlight=0 to
> >> hooks. But this create two backlight interfaces (which
> >> is not good), but only way (for now) how to make
> >> dell_laptop working again.
> >> 
> >> Better and maybe only one proper solution would be to
> >> teach intel drm i915 driver to not drop backlight
> >> change request for Dell laptops 

ACPI/i915: Cannot configure display brightness on Dell Latitude E6440

[Pali Rohár]

On Wednesday 24 September 2014 10:59:41 Pali Roh?r wrote:
> On Wednesday 24 September 2014 10:19:38 Hans de Goede wrote:
> > Hi,
> > 
> > On 09/23/2014 10:44 PM, Pali Roh?r wrote:
> > > On Tuesday 23 September 2014 22:31:31 you wrote:
> > >> Hi,
> > >> 
> > >> On 09/23/2014 10:06 PM, Pali Roh?r wrote:
> > >>> Hello,
> > >>> 
> > >>> after big changes in acpi video/i915 code I cannot
> > >>> change display brightness on my Dell Latitude E6440
> > >>> with kernel 3.17-rc6. With kernel 3.13 everything
> > >>> worked fine.
> > >>> 
> > >>> More information about this problem:
> > >>> 
> > >>> For configuring brightness on Dell laptops there are 4
> > >>> ways: 1) via acpi video driver
> > >>> 2) via dell-laptop driver
> > >>> 3) via i915 drm driver
> > >>> 4) from userspace with special dell SMI call
> > >>> 
> > >>> (e.g with program dellLcdBrightness from libsmbios
> > >>> package)
> > >>> 
> > >>> Methods 2) and 4) are same, both making special SMI call
> > >>> and Bios handing this request (just 2 is from kernel and
> > >>> 4 from userspace)
> > >>> 
> > >>> Method 1) via acpi video driver working, but is not
> > >>> perfect. Driver can be used to change brightness (but
> > >>> only some levels, probably this depends on acpi/DSDT
> > >>> tables), but cannot be used to retrieve current
> > >>> brightness (when BIOS/SMI change brightness acpi driver
> > >>> report old incorrect value). So I prefer dell-laptop
> > >>> driver instead acpi video.
> > >>> 
> > >>> Method 3) working even with 3.17-rc6 kernel but because
> > >>> that backlight device exported by i915 is marked as raw,
> > >>> desktop programs prefer to use other devices.
> > >>> 
> > >>> Moreover it looks like that methods 1) 2) and 4) just
> > >>> forward request to method 3). So in any cased brightness
> > >>> is changed by i915 drm driver.
> > >>> 
> > >>> I'm not sure (correct me if I'm wrong!) but I think that
> > >>> intel i915 drm driver accept changes (file
> > >>> intel_opregion.c) only if acpi function
> > >>> acpi_video_verify_backlight_support() returns true.
> > >>> 
> > >>> Function acpi_video_verify_backlight_support() returns
> > >>> true iff: function acpi_video_backlight_support()
> > >>> returns true AND at least one of these functions
> > >>> returns false: acpi_osi_is_win8()
> > >>> acpi_video_use_native_backlight()
> > >>> backlight_device_registered(BACKLIGHT_RAW)
> > >>> 
> > >>> On my notebook acpi_osi_is_win8() returns true (as is
> > >>> win8 compliant),
> > >>> backlight_device_registered(BACKLIGHT_RAW) returns true
> > >>> as I'm using intel i915 drm driver with raw backlight
> > >>> device and acpi_video_use_native_backlight() returns
> > >>> true/false depending on
> > >>> "video.use_native_backlight" kernel param. Default is
> > >>> true.
> > >>> 
> > >>> So if I want to have working acpi video driver with
> > >>> display brightness support I need to boot kernel with
> > >>> param: "video.use_native_backlight=0". I tested it with
> > >>> kernel 3.17-rc6 and this param really enabled display
> > >>> brightness support via acpi video driver -- which is
> > >>> good.
> > >>> 
> > >>> Driver dell-laptop creating backligh device for
> > >>> brightness control only if
> > >>> acpi_video_backlight_support() returns false. There is
> > >>> complicated condition for it and when kernel is booted
> > >>> with "video.use_native_backlight=0" that function
> > >>> returns true.
> > >>> 
> > >>> So conclusion is: With current code in kernel 3.17-rc6
> > >>> it is not possible to control brightness of display
> > >>> with native driver dell-laptop on Dell Latitude E6440
> > >>> (and probably on others too)!!!
> > >>> 
> > >>> And Because laptop is win8 compliant and you create
> > >>> decision to use native driver (instead acpi one) it is
> > >>> not possible to control display brightness without
> > >>> tweeks in kernel cmdline.
> > >>> 
> > >>> As I wrote I would rather to use native dell-laptop
> > >>> driver for controlling brightness, but it is not
> > >>> possible.
> > >>> 
> > >>> So how to solve this problem?
> > >>> 
> > >>> Quick solution would be to set use_native_backlight
> > >>> false for some Dell laptops which means, that acpi
> > >>> video will be used and in this case intel i915 driver
> > >>> will *not* drop backlight change request.
> > >>> 
> > >>> Another solution could be to disable check in
> > >>> dell_laptop driver and add use_native_backlight=0 to
> > >>> hooks. But this create two backlight interfaces (which
> > >>> is not good), but only way (for now) how to make
> > >>> dell_laptop working again.
> > >>> 
> > >>> Better and maybe only one proper solution would be to
> > >>> teach intel drm i915 driver to not drop backlight change
> > >>> request for Dell laptops (or all??). (This allows to
> > >>> work both acpi video and dell_laptop drivers without
> > >>> any change and with *any* value in param
> > >>> use_native_backlight). I think that problematic code is
> > >>> in function 

ACPI/i915: Cannot configure display brightness on Dell Latitude E6440

[Pali Rohár]

On Wednesday 24 September 2014 10:19:38 Hans de Goede wrote:
> Hi,
> 
> On 09/23/2014 10:44 PM, Pali Roh?r wrote:
> > On Tuesday 23 September 2014 22:31:31 you wrote:
> >> Hi,
> >> 
> >> On 09/23/2014 10:06 PM, Pali Roh?r wrote:
> >>> Hello,
> >>> 
> >>> after big changes in acpi video/i915 code I cannot change
> >>> display brightness on my Dell Latitude E6440 with kernel
> >>> 3.17-rc6. With kernel 3.13 everything worked fine.
> >>> 
> >>> More information about this problem:
> >>> 
> >>> For configuring brightness on Dell laptops there are 4
> >>> ways: 1) via acpi video driver
> >>> 2) via dell-laptop driver
> >>> 3) via i915 drm driver
> >>> 4) from userspace with special dell SMI call
> >>> 
> >>> (e.g with program dellLcdBrightness from libsmbios
> >>> package)
> >>> 
> >>> Methods 2) and 4) are same, both making special SMI call
> >>> and Bios handing this request (just 2 is from kernel and
> >>> 4 from userspace)
> >>> 
> >>> Method 1) via acpi video driver working, but is not
> >>> perfect. Driver can be used to change brightness (but
> >>> only some levels, probably this depends on acpi/DSDT
> >>> tables), but cannot be used to retrieve current
> >>> brightness (when BIOS/SMI change brightness acpi driver
> >>> report old incorrect value). So I prefer dell-laptop
> >>> driver instead acpi video.
> >>> 
> >>> Method 3) working even with 3.17-rc6 kernel but because
> >>> that backlight device exported by i915 is marked as raw,
> >>> desktop programs prefer to use other devices.
> >>> 
> >>> Moreover it looks like that methods 1) 2) and 4) just
> >>> forward request to method 3). So in any cased brightness
> >>> is changed by i915 drm driver.
> >>> 
> >>> I'm not sure (correct me if I'm wrong!) but I think that
> >>> intel i915 drm driver accept changes (file
> >>> intel_opregion.c) only if acpi function
> >>> acpi_video_verify_backlight_support() returns true.
> >>> 
> >>> Function acpi_video_verify_backlight_support() returns
> >>> true iff: function acpi_video_backlight_support() returns
> >>> true AND at least one of these functions returns false:
> >>> acpi_osi_is_win8()
> >>> acpi_video_use_native_backlight()
> >>> backlight_device_registered(BACKLIGHT_RAW)
> >>> 
> >>> On my notebook acpi_osi_is_win8() returns true (as is win8
> >>> compliant), backlight_device_registered(BACKLIGHT_RAW)
> >>> returns true as I'm using intel i915 drm driver with raw
> >>> backlight device and acpi_video_use_native_backlight()
> >>> returns true/false depending on
> >>> "video.use_native_backlight" kernel param. Default is
> >>> true.
> >>> 
> >>> So if I want to have working acpi video driver with
> >>> display brightness support I need to boot kernel with
> >>> param: "video.use_native_backlight=0". I tested it with
> >>> kernel 3.17-rc6 and this param really enabled display
> >>> brightness support via acpi video driver -- which is
> >>> good.
> >>> 
> >>> Driver dell-laptop creating backligh device for brightness
> >>> control only if acpi_video_backlight_support() returns
> >>> false. There is complicated condition for it and when
> >>> kernel is booted with "video.use_native_backlight=0" that
> >>> function returns true.
> >>> 
> >>> So conclusion is: With current code in kernel 3.17-rc6 it
> >>> is not possible to control brightness of display with
> >>> native driver dell-laptop on Dell Latitude E6440 (and
> >>> probably on others too)!!!
> >>> 
> >>> And Because laptop is win8 compliant and you create
> >>> decision to use native driver (instead acpi one) it is
> >>> not possible to control display brightness without tweeks
> >>> in kernel cmdline.
> >>> 
> >>> As I wrote I would rather to use native dell-laptop driver
> >>> for controlling brightness, but it is not possible.
> >>> 
> >>> So how to solve this problem?
> >>> 
> >>> Quick solution would be to set use_native_backlight false
> >>> for some Dell laptops which means, that acpi video will be
> >>> used and in this case intel i915 driver will *not* drop
> >>> backlight change request.
> >>> 
> >>> Another solution could be to disable check in dell_laptop
> >>> driver and add use_native_backlight=0 to hooks. But this
> >>> create two backlight interfaces (which is not good), but
> >>> only way (for now) how to make dell_laptop working again.
> >>> 
> >>> Better and maybe only one proper solution would be to
> >>> teach intel drm i915 driver to not drop backlight change
> >>> request for Dell laptops (or all??). (This allows to work
> >>> both acpi video and dell_laptop drivers without any
> >>> change and with *any* value in param
> >>> use_native_backlight). I think that problematic code is
> >>> in function asle_set_backlight() in file intel_opregion.c
> >>> (but I'm not sure). My idea is that "drop" event function
> >>> it is caused by this commit
> >>> 0b9f7d93ca6109048a4eb06332b666b6e29df4fe (but I'm not
> >>> sure).
> >>> 
> >>> At least something must be done as I think that I'm not
> >>> only one who has Dell laptop and 

ACPI/i915: Cannot configure display brightness on Dell Latitude E6440

[Pali Rohár]

On Tuesday 23 September 2014 22:31:31 you wrote:
> Hi,
> 
> On 09/23/2014 10:06 PM, Pali Roh?r wrote:
> > Hello,
> > 
> > after big changes in acpi video/i915 code I cannot change
> > display brightness on my Dell Latitude E6440 with kernel
> > 3.17-rc6. With kernel 3.13 everything worked fine.
> > 
> > More information about this problem:
> > 
> > For configuring brightness on Dell laptops there are 4 ways:
> > 1) via acpi video driver
> > 2) via dell-laptop driver
> > 3) via i915 drm driver
> > 4) from userspace with special dell SMI call
> > 
> > (e.g with program dellLcdBrightness from libsmbios
> > package)
> > 
> > Methods 2) and 4) are same, both making special SMI call and
> > Bios handing this request (just 2 is from kernel and 4 from
> > userspace)
> > 
> > Method 1) via acpi video driver working, but is not perfect.
> > Driver can be used to change brightness (but only some
> > levels, probably this depends on acpi/DSDT tables), but
> > cannot be used to retrieve current brightness (when
> > BIOS/SMI change brightness acpi driver report old incorrect
> > value). So I prefer dell-laptop driver instead acpi video.
> > 
> > Method 3) working even with 3.17-rc6 kernel but because that
> > backlight device exported by i915 is marked as raw, desktop
> > programs prefer to use other devices.
> > 
> > Moreover it looks like that methods 1) 2) and 4) just
> > forward request to method 3). So in any cased brightness is
> > changed by i915 drm driver.
> > 
> > I'm not sure (correct me if I'm wrong!) but I think that
> > intel i915 drm driver accept changes (file
> > intel_opregion.c) only if acpi function
> > acpi_video_verify_backlight_support() returns true.
> > 
> > Function acpi_video_verify_backlight_support() returns true
> > iff: function acpi_video_backlight_support() returns true
> > AND at least one of these functions returns false:
> > acpi_osi_is_win8()
> > acpi_video_use_native_backlight()
> > backlight_device_registered(BACKLIGHT_RAW)
> > 
> > On my notebook acpi_osi_is_win8() returns true (as is win8
> > compliant), backlight_device_registered(BACKLIGHT_RAW)
> > returns true as I'm using intel i915 drm driver with raw
> > backlight device and acpi_video_use_native_backlight()
> > returns true/false depending on
> > "video.use_native_backlight" kernel param. Default is true.
> > 
> > So if I want to have working acpi video driver with display
> > brightness support I need to boot kernel with param:
> > "video.use_native_backlight=0". I tested it with kernel
> > 3.17-rc6 and this param really enabled display brightness
> > support via acpi video driver -- which is good.
> > 
> > Driver dell-laptop creating backligh device for brightness
> > control only if acpi_video_backlight_support() returns
> > false. There is complicated condition for it and when
> > kernel is booted with "video.use_native_backlight=0" that
> > function returns true.
> > 
> > So conclusion is: With current code in kernel 3.17-rc6 it is
> > not possible to control brightness of display with native
> > driver dell-laptop on Dell Latitude E6440 (and probably on
> > others too)!!!
> > 
> > And Because laptop is win8 compliant and you create decision
> > to use native driver (instead acpi one) it is not possible
> > to control display brightness without tweeks in kernel
> > cmdline.
> > 
> > As I wrote I would rather to use native dell-laptop driver
> > for controlling brightness, but it is not possible.
> > 
> > So how to solve this problem?
> > 
> > Quick solution would be to set use_native_backlight false
> > for some Dell laptops which means, that acpi video will be
> > used and in this case intel i915 driver will *not* drop
> > backlight change request.
> > 
> > Another solution could be to disable check in dell_laptop
> > driver and add use_native_backlight=0 to hooks. But this
> > create two backlight interfaces (which is not good), but
> > only way (for now) how to make dell_laptop working again.
> > 
> > Better and maybe only one proper solution would be to teach
> > intel drm i915 driver to not drop backlight change request
> > for Dell laptops (or all??). (This allows to work both acpi
> > video and dell_laptop drivers without any change and with
> > *any* value in param use_native_backlight). I think that
> > problematic code is in function asle_set_backlight() in
> > file intel_opregion.c (but I'm not sure). My idea is that
> > "drop" event function it is caused by this commit
> > 0b9f7d93ca6109048a4eb06332b666b6e29df4fe (but I'm not
> > sure).
> > 
> > At least something must be done as I think that I'm not only
> > one who has Dell laptop and brightness configuration is
> > really important...
> 
> I don't understand your problem, the kernel is selecting the
> i915 backlight driver, making that the only one available to
> userspace, so the one problem you state with the i915 driver,
> that it is "raw" is not an issue, as userspace will pick it
> when it is the only one.
> 

It is not only one. Also 

ACPI/i915: Cannot configure display brightness on Dell Latitude E6440

[Pali Rohár]

Hello,

after big changes in acpi video/i915 code I cannot change display 
brightness on my Dell Latitude E6440 with kernel 3.17-rc6. With 
kernel 3.13 everything worked fine.

More information about this problem:

For configuring brightness on Dell laptops there are 4 ways:
1) via acpi video driver
2) via dell-laptop driver
3) via i915 drm driver
4) from userspace with special dell SMI call
   (e.g with program dellLcdBrightness from libsmbios package)

Methods 2) and 4) are same, both making special SMI call and Bios 
handing this request (just 2 is from kernel and 4 from userspace)

Method 1) via acpi video driver working, but is not perfect. 
Driver can be used to change brightness (but only some levels, 
probably this depends on acpi/DSDT tables), but cannot be used to 
retrieve current brightness (when BIOS/SMI change brightness acpi 
driver report old incorrect value). So I prefer dell-laptop 
driver instead acpi video.

Method 3) working even with 3.17-rc6 kernel but because that 
backlight device exported by i915 is marked as raw, desktop 
programs prefer to use other devices.

Moreover it looks like that methods 1) 2) and 4) just forward 
request to method 3). So in any cased brightness is changed by 
i915 drm driver.

I'm not sure (correct me if I'm wrong!) but I think that intel 
i915 drm driver accept changes (file intel_opregion.c) only if 
acpi function acpi_video_verify_backlight_support() returns true.

Function acpi_video_verify_backlight_support() returns true iff:
function acpi_video_backlight_support() returns true AND at least 
one of these functions returns false:
acpi_osi_is_win8()
acpi_video_use_native_backlight() 
backlight_device_registered(BACKLIGHT_RAW)

On my notebook acpi_osi_is_win8() returns true (as is win8 
compliant), backlight_device_registered(BACKLIGHT_RAW) returns 
true as I'm using intel i915 drm driver with raw backlight device 
and acpi_video_use_native_backlight() returns true/false 
depending on "video.use_native_backlight" kernel param. Default 
is true.

So if I want to have working acpi video driver with display 
brightness support I need to boot kernel with param: 
"video.use_native_backlight=0". I tested it with kernel 3.17-rc6 
and this param really enabled display brightness support via acpi 
video driver -- which is good.

Driver dell-laptop creating backligh device for brightness 
control only if acpi_video_backlight_support() returns false. 
There is complicated condition for it and when kernel is booted 
with "video.use_native_backlight=0" that function returns true.

So conclusion is: With current code in kernel 3.17-rc6 it is not 
possible to control brightness of display with native driver 
dell-laptop on Dell Latitude E6440 (and probably on others 
too)!!!

And Because laptop is win8 compliant and you create decision to 
use native driver (instead acpi one) it is not possible to 
control display brightness without tweeks in kernel cmdline.

As I wrote I would rather to use native dell-laptop driver for 
controlling brightness, but it is not possible.

So how to solve this problem?

Quick solution would be to set use_native_backlight false for 
some Dell laptops which means, that acpi video will be used and 
in this case intel i915 driver will *not* drop backlight change 
request.

Another solution could be to disable check in dell_laptop driver 
and add use_native_backlight=0 to hooks. But this create two 
backlight interfaces (which is not good), but only way (for now) 
how to make dell_laptop working again.

Better and maybe only one proper solution would be to teach intel 
drm i915 driver to not drop backlight change request for Dell 
laptops (or all??). (This allows to work both acpi video and 
dell_laptop drivers without any change and with *any* value in 
param use_native_backlight). I think that problematic code is in 
function asle_set_backlight() in file intel_opregion.c (but I'm 
not sure). My idea is that "drop" event function it is caused by 
this commit 0b9f7d93ca6109048a4eb06332b666b6e29df4fe (but I'm not 
sure).

At least something must be done as I think that I'm not only one 
who has Dell laptop and brightness configuration is really 
important...

Thanks.

-- 
Pali Roh?r
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Question about radeon runpm dmesg logs

[Pali Rohár]

Hello,

I have laptop with hybrid graphics solution (intel+radeon).
Radeon runpm option working (when using DRI_PRIME), however every
time when radeon card is powering on kernel write lot of lines to
dmesg:

[ 1075.055132] ACPI: \_SB_.PCI0.PEG0: ACPI_NOTIFY_BUS_CHECK event
[ 1075.055164] ACPI: \_SB_.PCI0.PEG0: Bus check in hotplug_event()
[ 1075.064446] switching from power state:
[ 1075.064449]  ui class: none
[ 1075.064450]  internal class: boot 
[ 1075.064451]  caps: 
[ 1075.064452]  uvdvclk: 0 dclk: 0
[ 1075.064453]  power level 0sclk: 3 mclk: 14900 vddc: 900 
vddci: 0 pcie gen: 3
[ 1075.064454]  status: c b 
[ 1075.064455] switching to power state:
[ 1075.064455]  ui class: performance
[ 1075.064456]  internal class: none
[ 1075.064457]  caps: 
[ 1075.064457]  uvdvclk: 0 dclk: 0
[ 1075.064458]  power level 0sclk: 3 mclk: 15000 vddc: 800 
vddci: 0 pcie gen: 3
[ 1075.064459]  power level 1sclk: 4 mclk: 10 vddc: 875 
vddci: 0 pcie gen: 3
[ 1075.064460]  power level 2sclk: 75000 mclk: 10 vddc: 1025 
vddci: 0 pcie gen: 3
[ 1075.064461]  power level 3sclk: 9 mclk: 10 vddc: 1025 
vddci: 0 pcie gen: 3
[ 1075.064461]  power level 4sclk: 97500 mclk: 10 vddc: 1075 
vddci: 0 pcie gen: 3
[ 1075.064462]  status: r 
[ 1075.065584] [drm] probing gen 2 caps for device 8086:c01 = 261ad03/e
[ 1075.065586] [drm] PCIE gen 3 link speeds already enabled
[ 1075.067609] [drm] PCIE GART of 1024M enabled (table at 0x0004).
[ 1075.067722] radeon :01:00.0: WB enabled
[ 1075.067724] radeon :01:00.0: fence driver on ring 0 use gpu addr 
0x8c00 and cpu addr 
0x880036d8cc00
[ 1075.067725] radeon :01:00.0: fence driver on ring 1 use gpu addr 
0x8c04 and cpu addr 
0x880036d8cc04
[ 1075.067726] radeon :01:00.0: fence driver on ring 2 use gpu addr 
0x8c08 and cpu addr 
0x880036d8cc08
[ 1075.067727] radeon :01:00.0: fence driver on ring 3 use gpu addr 
0x8c0c and cpu addr 
0x880036d8cc0c
[ 1075.067728] radeon :01:00.0: fence driver on ring 4 use gpu addr 
0x8c10 and cpu addr 
0x880036d8cc10
[ 1075.209399] [drm] ring test on 0 succeeded in 2 usecs
[ 1075.209403] [drm] ring test on 1 succeeded in 1 usecs
[ 1075.209406] [drm] ring test on 2 succeeded in 1 usecs
[ 1075.209464] [drm] ring test on 3 succeeded in 2 usecs
[ 1075.209470] [drm] ring test on 4 succeeded in 1 usecs
[ 1075.209528] [drm] ib test on ring 0 succeeded in 0 usecs
[ 1075.209577] [drm] ib test on ring 1 succeeded in 0 usecs
[ 1075.209621] [drm] ib test on ring 2 succeeded in 0 usecs
[ 1075.209646] [drm] ib test on ring 3 succeeded in 0 usecs
[ 1075.209663] [drm] ib test on ring 4 succeeded in 0 usecs


And when radeon card is automatically powered off by runpm in
dmesg I see these lines:

[ 1081.923248] ACPI: \_SB_.PCI0.PEG0: ACPI_NOTIFY_BUS_CHECK event
[ 1081.923267] ACPI: \_SB_.PCI0.PEG0: Bus check in hotplug_event()

Is it OK? Are there any errors? For me lines marked with drm and
radeon strings look like test/verbose/debug info. But I really do
not know what that ACPI lines are and what it means. It is something important?

I just want to be sure if there are some errors or not - as
seeing couple of lines every time when card is turned on does not
look like pretty.

-- 
Pali Roh?r
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [PATCH] nouveau: fix reclocking on nv40

[Pali Rohár]

On Wednesday 21 August 2013 02:24:01 Ben Skeggs wrote:
 On Mon, Aug 19, 2013 at 4:59 PM, Pali Rohár 
pali.ro...@gmail.com wrote:
  On Friday 16 August 2013 14:57:07 Pali Rohár wrote:
  In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
  introduced error which cause that reclocking on nv40 not
  working anymore. There is missing assigment of return value
  from pll_calc to ret.
  
  Signed-off-by: Pali Rohár pali.ro...@gmail.com
  Signed-off-by: Martin Peres martin.pe...@labri.fr
  ---
  
   drivers/gpu/drm/nouveau/nv40_pm.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c
  b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d
  100644
  --- a/drivers/gpu/drm/nouveau/nv40_pm.c
  +++ b/drivers/gpu/drm/nouveau/nv40_pm.c
  @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev,
  u32 reg, struct nvbios_pll *pll, if (clk 
  pll-vco1.max_freq)
  
pll-vco2.max_freq = 0;
  
  - pclk-pll_calc(pclk, pll, clk, coef);
  + ret = pclk-pll_calc(pclk, pll, clk, coef);
  
if (ret == 0)

return -ERANGE;
  
  Hello, it is possible to include this patch in 3.11?
  Or it is too late now and need to wait for 3.12?
 
 I've picked up the patch and will submit it in my next
 3.11-fixes pull request.
 
 Thanks,
 Ben.
 

Hello, now I see that patch is in 3.11, thanks! Ben, what do you 
think, can be this patch backported to older kernels?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] nouveau: fix reclocking on nv40

[Pali Rohár]

On Friday 16 August 2013 14:57:07 Pali Rohár wrote:
 In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
 introduced error which cause that reclocking on nv40 not
 working anymore. There is missing assigment of return value
 from pll_calc to ret.
 
 Signed-off-by: Pali Rohár pali.ro...@gmail.com
 Signed-off-by: Martin Peres martin.pe...@labri.fr
 ---
  drivers/gpu/drm/nouveau/nv40_pm.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c
 b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d
 100644
 --- a/drivers/gpu/drm/nouveau/nv40_pm.c
 +++ b/drivers/gpu/drm/nouveau/nv40_pm.c
 @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32
 reg, struct nvbios_pll *pll, if (clk  pll-vco1.max_freq)
   pll-vco2.max_freq = 0;
 
 - pclk-pll_calc(pclk, pll, clk, coef);
 + ret = pclk-pll_calc(pclk, pll, clk, coef);
   if (ret == 0)
   return -ERANGE;

Hello, it is possible to include this patch in 3.11?
Or it is too late now and need to wait for 3.12?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] nouveau: fix reclocking on nv40

[Pali Rohár]

On Friday 16 August 2013 14:57:07 Pali Roh?r wrote:
> In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
> introduced error which cause that reclocking on nv40 not
> working anymore. There is missing assigment of return value
> from pll_calc to ret.
> 
> Signed-off-by: Pali Roh?r 
> Signed-off-by: Martin Peres 
> ---
>  drivers/gpu/drm/nouveau/nv40_pm.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c
> b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d
> 100644
> --- a/drivers/gpu/drm/nouveau/nv40_pm.c
> +++ b/drivers/gpu/drm/nouveau/nv40_pm.c
> @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32
> reg, struct nvbios_pll *pll, if (clk < pll->vco1.max_freq)
>   pll->vco2.max_freq = 0;
> 
> - pclk->pll_calc(pclk, pll, clk, );
> + ret = pclk->pll_calc(pclk, pll, clk, );
>   if (ret == 0)
>   return -ERANGE;

Hello, it is possible to include this patch in 3.11?
Or it is too late now and need to wait for 3.12?

-- 
Pali Roh?r
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Re: nouveau: temperature on nv40 is unavailable since ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954

[Pali Rohár]

On Thursday 15 August 2013 18:21:51 Martin Peres wrote:
 On 15/08/2013 03:24, Pali Rohár wrote:
  On Thursday 15 August 2013 04:07:24 Martin Peres wrote:
  On 14/08/2013 05:02, Pali Rohár wrote:
  On Tuesday 13 August 2013 15:55:28 Martin Peres wrote:
  On 13/08/2013 09:53, Pali Rohár wrote:
  On utorok, 13. augusta 2013 15:32:45 CEST, Martin Peres
  
  wrote:
  On 13/08/2013 09:23, Pali Rohár wrote:
  On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
 ...
  
  You can check the temperature by running nvidia-settings.
  If you can't see the temperature in it, then nvidia
  doesn't support it on your card and
  I'm not sure we should :s
  
  Thanks for the vbios you sent me in private. For the
  others, the reason why he doesn't have temperature
  anymore is because his vbios lacks sensor calibration
  values.
  
  In nvidia-settings tab GPU 0 - (GeForce 6600 GT) --
  Thermal Settings is:
  
  Thermal Sensor Information:
  ID: 0
  Target: GPU
  Provider: GPU Internal
  Temperature: 70 C (now)
  
  I looked in Windows program SpeedFan. It found Nvidia PCI
  card and reported GPU Temp about 68-70 C. So it looks
  like both nvidia driver and windows SpeedFan program
  reading same values.
  
  Great, I'll cook you a patch in a bit and you'll see what
  the temperature is like. It won't be perfectly accurate
  but there is some kind of default for nvidia cards of this
  generation.
  
  Ok, send me patch and I can try it if it will work and
  report similar values as windows or nvidia driver.
  
  Sorry for the late answer.
  
  Please test this patch. Be aware that temperature with nouveau
  will be higher than with the blob.
  I only want to see if nouveau reports a temperature.
  
  The only way to be sure if the values are good-enough would be
  to use the blob and run:
  nvapeek 0x15b0
  Please send me the result along with the temperature reported
  by nvidia at the time of the peek.
  
  Martin
  
  PS: This patch has only be compile-tested, I don't have access
  to an nv4x right now.
  
  Hello,
  
  now after patch nouveau report temperature:
  
  $ sensors
  ...
  nouveau-pci-0500
  Adapter: PCI adapter
  temp1:+63.0°C  (high = +95.0°C, hyst =  +3.0°C)
  
  (crit = +145.0°C, hyst =  +2.0°C)
  (emerg = +135.0°C, hyst =  +5.0°C)
 
 Ok, that was expected ;)
 
  ...
  
  I found that nvidia binary driver has command line utility
  nvidia-smi which report same temperature as X utility nvidia-
  settings. So I will use nvidia-smi (if it is OK).
  
  And after reboot nvidia report another temperature value:
  
  $ nvidia-smi -q -d TEMPERATURE
  ...
  GPU :05:00.0
  
   Temperature
   
   Gpu : 70 C
  
  Immediately I called nvapeek command:
  
  $ nvapeek 0x15b0
  15b0: 108e
  
  So value reported by nouveau is lower than value reported by
  nvidia binary driver.
 
 As you didn't run nvapeek 15b0 when running nouveau it is hard to tell
 if it is due to
 calibration values or because the temperature was lower.
 

I run it and it always reported value 00ff (also when temperature changed).

 Could you please read the temperature + peek 15b0 when running nouveau?
 
 Anyway, it is weird because I cannot find 70°C with 0x8e as an input
 temperature and with
 the current default values :o
 

My idea is that register does not contains temperature. Both nouveau and 
nvidia driver when show different temperature it does not show different output 
from nvapeek 0x15b0.

Now I started computer with nouveau driver. Temperature is incresing, but 
nvapeek 0x15b0 is still same.

So do you really needs other tests with nvapeek 0x15b0? Is that register 
correct?

  I wait some some and started nvidia-smi and nvapeek again, here
  are results:
  
  $ nvidia-smi -q -d TEMPERATURE
  ...
  GPU :05:00.0
  
   Temperature
   
   Gpu : 67 C
  
  $ nvapeek 0x15b0
  15b0: 108e
  
  So it looks like that nvapeek returning always same value and
  does not depends on temperature... It is OK?
 
 Well, it looks like the temperature reading is very noisy!
 Could you please get the temperature + peek when the card is as hot as
 possible?
 
 There is a very effective solution to get a GPU hot, use a hair drier.
 If you could get your
 GPU to at 110°C (or less, if you feel like it is too much), that could
 help me check the formula
 and default values.
 
 PS: I attached a new version of the patch that should improve the
 temperature accuracy for
 nv43s. Could you test it and send me your kernel log?

-- 
Pali Rohár
pali.ro...@gmail.com



signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] nouveau reclocking on nv40 not working since 77145f1cbdf8d28b46ff8070ca749bad821e0774

[Pali Rohár]

On Thursday 15 August 2013 18:23:06 Martin Peres wrote:
 On 15/08/2013 13:46, Pali Rohár wrote:
  On Tuesday 13 August 2013 11:28:01 Pali Rohár wrote:
  Hello,
  
  in commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
  introduced error which cause that on my Nvidia 6600GT card
  reclocking not working anymore. There is missing assigment of
  return value from pll_calc to ret.
  
  After this patch reclocking on my card working fine again.
  Above broken commit was introduced in kernel 3.7, so consider
  backporting this patch to older kernels too.
  
  Signed-off-by: Pali Rohár pali.ro...@gmail.com
  
  diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c
  b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d
  100644
  --- a/drivers/gpu/drm/nouveau/nv40_pm.c
  +++ b/drivers/gpu/drm/nouveau/nv40_pm.c
  @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32
  reg, struct nvbios_pll *pll, if (clk  pll-vco1.max_freq)
  
 pll-vco2.max_freq = 0;
  
  -  pclk-pll_calc(pclk, pll, clk, coef);
  +  ret = pclk-pll_calc(pclk, pll, clk, coef);
  
 if (ret == 0)
 
 return -ERANGE;
  
  Martin, can you look at another problem with my graphics card?
 
 As I told you before, I'm away from my computers, so I cannot test the
 patch. However,
 this one seems quite obvious and should be pushed. Thanks.

Yes, look at that diff of that problematic commit and you will see that ret 
here is missing. It is possible to push this patch to 3.11?

-- 
Pali Rohár
pali.ro...@gmail.com



signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] nouveau: fix reclocking on nv40

[Pali Rohár]

In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was introduced
error which cause that reclocking on nv40 not working anymore.
There is missing assigment of return value from pll_calc to ret.

Signed-off-by: Pali Rohár pali.ro...@gmail.com
Signed-off-by: Martin Peres martin.pe...@labri.fr
---
 drivers/gpu/drm/nouveau/nv40_pm.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c 
b/drivers/gpu/drm/nouveau/nv40_pm.c
index 3af5bcd..625f80d 100644
--- a/drivers/gpu/drm/nouveau/nv40_pm.c
+++ b/drivers/gpu/drm/nouveau/nv40_pm.c
@@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32 reg, struct 
nvbios_pll *pll,
if (clk  pll-vco1.max_freq)
pll-vco2.max_freq = 0;
 
-   pclk-pll_calc(pclk, pll, clk, coef);
+   ret = pclk-pll_calc(pclk, pll, clk, coef);
if (ret == 0)
return -ERANGE;
 
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] nouveau: fix reclocking on nv40

[Pali Rohár]

In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was introduced
error which cause that reclocking on nv40 not working anymore.
There is missing assigment of return value from pll_calc to ret.

Signed-off-by: Pali Roh?r 
Signed-off-by: Martin Peres 
---
 drivers/gpu/drm/nouveau/nv40_pm.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c 
b/drivers/gpu/drm/nouveau/nv40_pm.c
index 3af5bcd..625f80d 100644
--- a/drivers/gpu/drm/nouveau/nv40_pm.c
+++ b/drivers/gpu/drm/nouveau/nv40_pm.c
@@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32 reg, struct 
nvbios_pll *pll,
if (clk < pll->vco1.max_freq)
pll->vco2.max_freq = 0;

-   pclk->pll_calc(pclk, pll, clk, );
+   ret = pclk->pll_calc(pclk, pll, clk, );
if (ret == 0)
return -ERANGE;

-- 
1.7.10.4

[PATCH] nouveau reclocking on nv40 not working since 77145f1cbdf8d28b46ff8070ca749bad821e0774

[Pali Rohár]

On Thursday 15 August 2013 18:23:06 Martin Peres wrote:
> On 15/08/2013 13:46, Pali Roh?r wrote:
> > On Tuesday 13 August 2013 11:28:01 Pali Roh?r wrote:
> >> Hello,
> >> 
> >> in commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
> >> introduced error which cause that on my Nvidia 6600GT card
> >> reclocking not working anymore. There is missing assigment of
> >> return value from pll_calc to ret.
> >> 
> >> After this patch reclocking on my card working fine again.
> >> Above broken commit was introduced in kernel 3.7, so consider
> >> backporting this patch to older kernels too.
> >> 
> >> Signed-off-by: Pali Roh?r 
> >> 
> >> diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c
> >> b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d
> >> 100644
> >> --- a/drivers/gpu/drm/nouveau/nv40_pm.c
> >> +++ b/drivers/gpu/drm/nouveau/nv40_pm.c
> >> @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32
> >> reg, struct nvbios_pll *pll, if (clk < pll->vco1.max_freq)
> >> 
> >>pll->vco2.max_freq = 0;
> >> 
> >> -  pclk->pll_calc(pclk, pll, clk, );
> >> +  ret = pclk->pll_calc(pclk, pll, clk, );
> >> 
> >>if (ret == 0)
> >>
> >>return -ERANGE;
> > 
> > Martin, can you look at another problem with my graphics card?
> 
> As I told you before, I'm away from my computers, so I cannot test the
> patch. However,
> this one seems quite obvious and should be pushed. Thanks.

Yes, look at that diff of that problematic commit and you will see that ret 
here is missing. It is possible to push this patch to 3.11?

-- 
Pali Roh?r
pali.rohar at gmail.com

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

nouveau: temperature on nv40 is unavailable since ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954

[Pali Rohár]

On Thursday 15 August 2013 18:21:51 Martin Peres wrote:
> On 15/08/2013 03:24, Pali Roh?r wrote:
> > On Thursday 15 August 2013 04:07:24 Martin Peres wrote:
> >> On 14/08/2013 05:02, Pali Roh?r wrote:
> >>> On Tuesday 13 August 2013 15:55:28 Martin Peres wrote:
>  On 13/08/2013 09:53, Pali Roh?r wrote:
> > On utorok, 13. augusta 2013 15:32:45 CEST, Martin Peres
> >>> 
> >>> wrote:
> >> On 13/08/2013 09:23, Pali Roh?r wrote:
> >>> On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
> >>...
> >> 
> >> You can check the temperature by running nvidia-settings.
> >> If you can't see the temperature in it, then nvidia
> >> doesn't support it on your card and
> >> I'm not sure we should :s
> >> 
> >> Thanks for the vbios you sent me in private. For the
> >> others, the reason why he doesn't have temperature
> >> anymore is because his vbios lacks sensor calibration
> >> values.
> > 
> > In nvidia-settings tab "GPU 0 - (GeForce 6600 GT)" -->
> > "Thermal Settings" is:
> > 
> > Thermal Sensor Information:
> > ID: 0
> > Target: GPU
> > Provider: GPU Internal
> > Temperature: 70 C (now)
> > 
> > I looked in Windows program SpeedFan. It found Nvidia PCI
> > card and reported "GPU Temp" about 68-70 C. So it looks
> > like both nvidia driver and windows SpeedFan program
> > reading same values.
>  
>  Great, I'll cook you a patch in a bit and you'll see what
>  the temperature is like. It won't be perfectly accurate
>  but there is some kind of default for nvidia cards of this
>  generation.
> >>> 
> >>> Ok, send me patch and I can try it if it will work and
> >>> report similar values as windows or nvidia driver.
> >> 
> >> Sorry for the late answer.
> >> 
> >> Please test this patch. Be aware that temperature with nouveau
> >> will be higher than with the blob.
> >> I only want to see if nouveau reports a temperature.
> >> 
> >> The only way to be sure if the values are good-enough would be
> >> to use the blob and run:
> >> nvapeek 0x15b0
> >> Please send me the result along with the temperature reported
> >> by nvidia at the time of the peek.
> >> 
> >> Martin
> >> 
> >> PS: This patch has only be compile-tested, I don't have access
> >> to an nv4x right now.
> > 
> > Hello,
> > 
> > now after patch nouveau report temperature:
> > 
> > $ sensors
> > ...
> > nouveau-pci-0500
> > Adapter: PCI adapter
> > temp1:+63.0?C  (high = +95.0?C, hyst =  +3.0?C)
> > 
> > (crit = +145.0?C, hyst =  +2.0?C)
> > (emerg = +135.0?C, hyst =  +5.0?C)
> 
> Ok, that was expected ;)
> 
> > ...
> > 
> > I found that nvidia binary driver has command line utility
> > nvidia-smi which report same temperature as X utility nvidia-
> > settings. So I will use nvidia-smi (if it is OK).
> > 
> > And after reboot nvidia report another temperature value:
> > 
> > $ nvidia-smi -q -d TEMPERATURE
> > ...
> > GPU :05:00.0
> > 
> >  Temperature
> >  
> >  Gpu : 70 C
> > 
> > Immediately I called nvapeek command:
> > 
> > $ nvapeek 0x15b0
> > 15b0: 108e
> > 
> > So value reported by nouveau is lower than value reported by
> > nvidia binary driver.
> 
> As you didn't run nvapeek 15b0 when running nouveau it is hard to tell
> if it is due to
> calibration values or because the temperature was lower.
> 

I run it and it always reported value 00ff (also when temperature changed).

> Could you please read the temperature + peek 15b0 when running nouveau?
> 
> Anyway, it is weird because I cannot find 70?C with 0x8e as an input
> temperature and with
> the current default values :o
> 

My idea is that register does not contains temperature. Both nouveau and 
nvidia driver when show different temperature it does not show different output 
from "nvapeek 0x15b0".

Now I started computer with nouveau driver. Temperature is incresing, but 
nvapeek 0x15b0 is still same.

So do you really needs other tests with nvapeek 0x15b0? Is that register 
correct?

> > I wait some some and started nvidia-smi and nvapeek again, here
> > are results:
> > 
> > $ nvidia-smi -q -d TEMPERATURE
> > ...
> > GPU :05:00.0
> > 
> >  Temperature
> >  
> >  Gpu : 67 C
> > 
> > $ nvapeek 0x15b0
> > 15b0: 108e
> > 
> > So it looks like that nvapeek returning always same value and
> > does not depends on temperature... It is OK?
> 
> Well, it looks like the temperature reading is very noisy!
> Could you please get the temperature + peek when the card is as hot as
> possible?
> 
> There is a very effective solution to get a GPU hot, use a hair drier.
> If you could get your
> GPU to at 110?C (or less, if you feel like it is too much), that could
> help me check the formula
> and default values.
> 
> PS: I attached a new version of the patch that should improve the
> temperature accuracy for
> nv43s. 

[PATCH] nouveau reclocking on nv40 not working since 77145f1cbdf8d28b46ff8070ca749bad821e0774

[Pali Rohár]

On Tuesday 13 August 2013 11:28:01 Pali Roh?r wrote:
> Hello,
> 
> in commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
> introduced error which cause that on my Nvidia 6600GT card
> reclocking not working anymore. There is missing assigment of
> return value from pll_calc to ret.
> 
> After this patch reclocking on my card working fine again.
> Above broken commit was introduced in kernel 3.7, so consider
> backporting this patch to older kernels too.
> 
> Signed-off-by: Pali Roh?r 
> 
> diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c
> b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d
> 100644
> --- a/drivers/gpu/drm/nouveau/nv40_pm.c
> +++ b/drivers/gpu/drm/nouveau/nv40_pm.c
> @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32
> reg, struct nvbios_pll *pll, if (clk < pll->vco1.max_freq)
>   pll->vco2.max_freq = 0;
> 
> - pclk->pll_calc(pclk, pll, clk, );
> + ret = pclk->pll_calc(pclk, pll, clk, );
>   if (ret == 0)
>   return -ERANGE;

Martin, can you look at another problem with my graphics card?

-- 
Pali Roh?r
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

nouveau: temperature on nv40 is unavailable since ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954

[Pali Rohár]

On Thursday 15 August 2013 04:07:24 Martin Peres wrote:
> On 14/08/2013 05:02, Pali Roh?r wrote:
> > On Tuesday 13 August 2013 15:55:28 Martin Peres wrote:
> >> On 13/08/2013 09:53, Pali Roh?r wrote:
> >>> On utorok, 13. augusta 2013 15:32:45 CEST, Martin Peres
> > 
> > wrote:
>  On 13/08/2013 09:23, Pali Roh?r wrote:
> > On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
>    ...
>  
>  You can check the temperature by running nvidia-settings.
>  If you can't see the temperature in it, then nvidia
>  doesn't support it on your card and
>  I'm not sure we should :s
>  
>  Thanks for the vbios you sent me in private. For the
>  others, the reason why he doesn't have temperature
>  anymore is because his vbios lacks sensor calibration
>  values.
> >>> 
> >>> In nvidia-settings tab "GPU 0 - (GeForce 6600 GT)" -->
> >>> "Thermal Settings" is:
> >>> 
> >>> Thermal Sensor Information:
> >>> ID: 0
> >>> Target: GPU
> >>> Provider: GPU Internal
> >>> Temperature: 70 C (now)
> >>> 
> >>> I looked in Windows program SpeedFan. It found Nvidia PCI
> >>> card and reported "GPU Temp" about 68-70 C. So it looks
> >>> like both nvidia driver and windows SpeedFan program
> >>> reading same values.
> >> 
> >> Great, I'll cook you a patch in a bit and you'll see what
> >> the temperature is like. It won't be perfectly accurate
> >> but there is some kind of default for nvidia cards of this
> >> generation.
> > 
> > Ok, send me patch and I can try it if it will work and
> > report similar values as windows or nvidia driver.
> 
> Sorry for the late answer.
> 
> Please test this patch. Be aware that temperature with nouveau
> will be higher than with the blob.
> I only want to see if nouveau reports a temperature.
> 
> The only way to be sure if the values are good-enough would be
> to use the blob and run:
> nvapeek 0x15b0
> Please send me the result along with the temperature reported
> by nvidia at the time of the peek.
> 
> Martin
> 
> PS: This patch has only be compile-tested, I don't have access
> to an nv4x right now.

Hello,

now after patch nouveau report temperature:

$ sensors
...
nouveau-pci-0500
Adapter: PCI adapter
temp1:+63.0?C  (high = +95.0?C, hyst =  +3.0?C)
   (crit = +145.0?C, hyst =  +2.0?C)
   (emerg = +135.0?C, hyst =  +5.0?C)
...

I found that nvidia binary driver has command line utility 
nvidia-smi which report same temperature as X utility nvidia-
settings. So I will use nvidia-smi (if it is OK).

And after reboot nvidia report another temperature value:

$ nvidia-smi -q -d TEMPERATURE
...
GPU :05:00.0
Temperature
Gpu : 70 C

Immediately I called nvapeek command:

$ nvapeek 0x15b0
15b0: 108e

So value reported by nouveau is lower than value reported by 
nvidia binary driver.

I wait some some and started nvidia-smi and nvapeek again, here 
are results:

$ nvidia-smi -q -d TEMPERATURE
...
GPU :05:00.0
Temperature
Gpu : 67 C

$ nvapeek 0x15b0
15b0: 108e

So it looks like that nvapeek returning always same value and 
does not depends on temperature... It is OK?

-- 
Pali Roh?r
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Re: nouveau: temperature on nv40 is unavailable since ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954

[Pali Rohár]

On Thursday 15 August 2013 04:07:24 Martin Peres wrote:
 On 14/08/2013 05:02, Pali Rohár wrote:
  On Tuesday 13 August 2013 15:55:28 Martin Peres wrote:
  On 13/08/2013 09:53, Pali Rohár wrote:
  On utorok, 13. augusta 2013 15:32:45 CEST, Martin Peres
  
  wrote:
  On 13/08/2013 09:23, Pali Rohár wrote:
  On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
...
  
  You can check the temperature by running nvidia-settings.
  If you can't see the temperature in it, then nvidia
  doesn't support it on your card and
  I'm not sure we should :s
  
  Thanks for the vbios you sent me in private. For the
  others, the reason why he doesn't have temperature
  anymore is because his vbios lacks sensor calibration
  values.
  
  In nvidia-settings tab GPU 0 - (GeForce 6600 GT) --
  Thermal Settings is:
  
  Thermal Sensor Information:
  ID: 0
  Target: GPU
  Provider: GPU Internal
  Temperature: 70 C (now)
  
  I looked in Windows program SpeedFan. It found Nvidia PCI
  card and reported GPU Temp about 68-70 C. So it looks
  like both nvidia driver and windows SpeedFan program
  reading same values.
  
  Great, I'll cook you a patch in a bit and you'll see what
  the temperature is like. It won't be perfectly accurate
  but there is some kind of default for nvidia cards of this
  generation.
  
  Ok, send me patch and I can try it if it will work and
  report similar values as windows or nvidia driver.
 
 Sorry for the late answer.
 
 Please test this patch. Be aware that temperature with nouveau
 will be higher than with the blob.
 I only want to see if nouveau reports a temperature.
 
 The only way to be sure if the values are good-enough would be
 to use the blob and run:
 nvapeek 0x15b0
 Please send me the result along with the temperature reported
 by nvidia at the time of the peek.
 
 Martin
 
 PS: This patch has only be compile-tested, I don't have access
 to an nv4x right now.

Hello,

now after patch nouveau report temperature:

$ sensors
...
nouveau-pci-0500
Adapter: PCI adapter
temp1:+63.0°C  (high = +95.0°C, hyst =  +3.0°C)
   (crit = +145.0°C, hyst =  +2.0°C)
   (emerg = +135.0°C, hyst =  +5.0°C)
...

I found that nvidia binary driver has command line utility 
nvidia-smi which report same temperature as X utility nvidia-
settings. So I will use nvidia-smi (if it is OK).

And after reboot nvidia report another temperature value:

$ nvidia-smi -q -d TEMPERATURE
...
GPU :05:00.0
Temperature
Gpu : 70 C

Immediately I called nvapeek command:

$ nvapeek 0x15b0
15b0: 108e

So value reported by nouveau is lower than value reported by 
nvidia binary driver.

I wait some some and started nvidia-smi and nvapeek again, here 
are results:

$ nvidia-smi -q -d TEMPERATURE
...
GPU :05:00.0
Temperature
Gpu : 67 C

$ nvapeek 0x15b0
15b0: 108e

So it looks like that nvapeek returning always same value and 
does not depends on temperature... It is OK?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] nouveau reclocking on nv40 not working since 77145f1cbdf8d28b46ff8070ca749bad821e0774

[Pali Rohár]

On Tuesday 13 August 2013 11:28:01 Pali Rohár wrote:
 Hello,
 
 in commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
 introduced error which cause that on my Nvidia 6600GT card
 reclocking not working anymore. There is missing assigment of
 return value from pll_calc to ret.
 
 After this patch reclocking on my card working fine again.
 Above broken commit was introduced in kernel 3.7, so consider
 backporting this patch to older kernels too.
 
 Signed-off-by: Pali Rohár pali.ro...@gmail.com
 
 diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c
 b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d
 100644
 --- a/drivers/gpu/drm/nouveau/nv40_pm.c
 +++ b/drivers/gpu/drm/nouveau/nv40_pm.c
 @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32
 reg, struct nvbios_pll *pll, if (clk  pll-vco1.max_freq)
   pll-vco2.max_freq = 0;
 
 - pclk-pll_calc(pclk, pll, clk, coef);
 + ret = pclk-pll_calc(pclk, pll, clk, coef);
   if (ret == 0)
   return -ERANGE;

Martin, can you look at another problem with my graphics card?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

nouveau: temperature on nv40 is unavailable since ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954

[Pali Rohár]

On Tuesday 13 August 2013 15:55:28 Martin Peres wrote:
> On 13/08/2013 09:53, Pali Roh?r wrote:
> > On utorok, 13. augusta 2013 15:32:45 CEST, Martin Peres 
wrote:
> >> On 13/08/2013 09:23, Pali Roh?r wrote:
> >>> On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
> >>  ...
> >> 
> >> You can check the temperature by running nvidia-settings.
> >> If you can't see the temperature in it, then nvidia
> >> doesn't support it on your card and
> >> I'm not sure we should :s
> >> 
> >> Thanks for the vbios you sent me in private. For the
> >> others, the reason why he doesn't have temperature anymore
> >> is because his vbios lacks sensor calibration values.
> > 
> > In nvidia-settings tab "GPU 0 - (GeForce 6600 GT)" -->
> > "Thermal Settings" is:
> > 
> > Thermal Sensor Information:
> > ID: 0
> > Target: GPU
> > Provider: GPU Internal
> > Temperature: 70 C (now)
> > 
> > I looked in Windows program SpeedFan. It found Nvidia PCI
> > card and reported "GPU Temp" about 68-70 C. So it looks
> > like both nvidia driver and windows SpeedFan program
> > reading same values.
> 
> Great, I'll cook you a patch in a bit and you'll see what the
> temperature is like. It won't be perfectly accurate but there
> is some kind of default for nvidia cards of this generation.

Ok, send me patch and I can try it if it will work and report 
similar values as windows or nvidia driver.

-- 
Pali Roh?r
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Radeon: DPM suspend/hibernete error

[Pali Rohár]

Hello,

I'm testing linux-3.11-rc5 with my radeon graphics card HD 6470M. 
Finally hibernate and suspend mode started working without hangs. 
But now I see this error message in dmesg before notebook it 
hibernated or suspended:

[drm:rv770_stop_dpm] *ERROR* Could not force DPM to low.

Is this ERROR message big problem? Can you look at it?
Note that suspend/resume and hibernation working fine.

Thank you very much for DPM  UVD support!

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: nouveau: temperature on nv40 is unavailable since ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954

[Pali Rohár]

On Tuesday 13 August 2013 15:55:28 Martin Peres wrote:
 On 13/08/2013 09:53, Pali Rohár wrote:
  On utorok, 13. augusta 2013 15:32:45 CEST, Martin Peres 
wrote:
  On 13/08/2013 09:23, Pali Rohár wrote:
  On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
   ...
  
  You can check the temperature by running nvidia-settings.
  If you can't see the temperature in it, then nvidia
  doesn't support it on your card and
  I'm not sure we should :s
  
  Thanks for the vbios you sent me in private. For the
  others, the reason why he doesn't have temperature anymore
  is because his vbios lacks sensor calibration values.
  
  In nvidia-settings tab GPU 0 - (GeForce 6600 GT) --
  Thermal Settings is:
  
  Thermal Sensor Information:
  ID: 0
  Target: GPU
  Provider: GPU Internal
  Temperature: 70 C (now)
  
  I looked in Windows program SpeedFan. It found Nvidia PCI
  card and reported GPU Temp about 68-70 C. So it looks
  like both nvidia driver and windows SpeedFan program
  reading same values.
 
 Great, I'll cook you a patch in a bit and you'll see what the
 temperature is like. It won't be perfectly accurate but there
 is some kind of default for nvidia cards of this generation.

Ok, send me patch and I can try it if it will work and report 
similar values as windows or nvidia driver.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Radeon: DPM suspend/hibernete error

[Pali Rohár]

Hello,

I'm testing linux-3.11-rc5 with my radeon graphics card HD 6470M. 
Finally hibernate and suspend mode started working without hangs. 
But now I see this error message in dmesg before notebook it 
hibernated or suspended:

[drm:rv770_stop_dpm] *ERROR* Could not force DPM to low.

Is this ERROR message big problem? Can you look at it?
Note that suspend/resume and hibernation working fine.

Thank you very much for DPM & UVD support!

-- 
Pali Roh?r
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

nouveau: temperature on nv40 is unavailable since ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954

[Pali Rohár]

On utorok, 13. augusta 2013 15:32:45 CEST, Martin Peres wrote:
> On 13/08/2013 09:23, Pali Roh?r wrote:
>> On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
>  ...
> You can check the temperature by running nvidia-settings. If you can't
> see the temperature in it, then nvidia doesn't support it on your card and
> I'm not sure we should :s
>
> Thanks for the vbios you sent me in private. For the others, the reason
> why he doesn't have temperature anymore is because his vbios lacks
> sensor calibration values.
>
>

In nvidia-settings tab "GPU 0 - (GeForce 6600 GT)" --> "Thermal Settings" is:

Thermal Sensor Information:
ID: 0
Target: GPU
Provider: GPU Internal
Temperature: 70 C (now)

I looked in Windows program SpeedFan. It found Nvidia PCI card and reported 
"GPU Temp" about 68-70 C. So it looks like both nvidia driver and windows 
SpeedFan program reading same values.

-- 
Pali Roh?r
pali.rohar at gmail.com

nouveau: temperature on nv40 is unavailable since ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954

[Pali Rohár]

On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
> On 13/08/2013 05:56, Pali Roh?r wrote:
> > Hello,
> > 
> > after commit ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954 temperature
> > information from lm sensors is not available on my Nvidia 6600GT graphics
> > card. There is no nouveau hwmon entry in sysfs anymore. Why it was
> > removed? Can I help with debugging? I'd like to see temperature sensor
> > working again.
> 
> Hi,
> 
> Thanks for bisecting the issue. Can you send me your vbios and tell
> me if the nvidia driver shows your temperature probe (and what is
> its source).
> 
> To fetch your vbios, you can extract it using nvagetbios from the
> envytools repo: https://github.com/envytools/envytools
> 
> Cheers,
> Martin

How can I check source and temperature probe in nvidia binary driver?

-- 
Pali Roh?r
pali.rohar at gmail.com

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

nouveau: temperature on nv40 is unavailable since ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954

[Pali Rohár]

Hello,

after commit ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954 temperature information 
from lm sensors is not available on my Nvidia 6600GT graphics card. There is 
no nouveau hwmon entry in sysfs anymore. Why it was removed? Can I help with 
debugging? I'd like to see temperature sensor working again.

-- 
Pali Roh?r
pali.rohar at gmail.com

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[PATCH] nouveau reclocking on nv40 not working since 77145f1cbdf8d28b46ff8070ca749bad821e0774

[Pali Rohár]

Hello,

in commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was introduced
error which cause that on my Nvidia 6600GT card reclocking not working
anymore. There is missing assigment of return value from pll_calc to ret.

After this patch reclocking on my card working fine again. Above broken
commit was introduced in kernel 3.7, so consider backporting this patch
to older kernels too.

Signed-off-by: Pali Roh?r 

diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c 
b/drivers/gpu/drm/nouveau/nv40_pm.c
index 3af5bcd..625f80d 100644
--- a/drivers/gpu/drm/nouveau/nv40_pm.c
+++ b/drivers/gpu/drm/nouveau/nv40_pm.c
@@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32 reg, struct 
nvbios_pll *pll,
if (clk < pll->vco1.max_freq)
pll->vco2.max_freq = 0;

-   pclk->pll_calc(pclk, pll, clk, );
+   ret = pclk->pll_calc(pclk, pll, clk, );
if (ret == 0)
return -ERANGE;


-- 
Pali Roh?r
pali.rohar at gmail.com

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[PATCH] nouveau reclocking on nv40 not working since 77145f1cbdf8d28b46ff8070ca749bad821e0774

[Pali Rohár]

Hello,

in commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was introduced
error which cause that on my Nvidia 6600GT card reclocking not working
anymore. There is missing assigment of return value from pll_calc to ret.

After this patch reclocking on my card working fine again. Above broken
commit was introduced in kernel 3.7, so consider backporting this patch
to older kernels too.

Signed-off-by: Pali Rohár pali.ro...@gmail.com

diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c 
b/drivers/gpu/drm/nouveau/nv40_pm.c
index 3af5bcd..625f80d 100644
--- a/drivers/gpu/drm/nouveau/nv40_pm.c
+++ b/drivers/gpu/drm/nouveau/nv40_pm.c
@@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32 reg, struct 
nvbios_pll *pll,
if (clk  pll-vco1.max_freq)
pll-vco2.max_freq = 0;
 
-   pclk-pll_calc(pclk, pll, clk, coef);
+   ret = pclk-pll_calc(pclk, pll, clk, coef);
if (ret == 0)
return -ERANGE;
 

-- 
Pali Rohár
pali.ro...@gmail.com



signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

nouveau: temperature on nv40 is unavailable since ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954

[Pali Rohár]

Hello,

after commit ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954 temperature information 
from lm sensors is not available on my Nvidia 6600GT graphics card. There is 
no nouveau hwmon entry in sysfs anymore. Why it was removed? Can I help with 
debugging? I'd like to see temperature sensor working again.

-- 
Pali Rohár
pali.ro...@gmail.com



signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: nouveau: temperature on nv40 is unavailable since ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954

[Pali Rohár]

On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
 On 13/08/2013 05:56, Pali Rohár wrote:
  Hello,
  
  after commit ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954 temperature
  information from lm sensors is not available on my Nvidia 6600GT graphics
  card. There is no nouveau hwmon entry in sysfs anymore. Why it was
  removed? Can I help with debugging? I'd like to see temperature sensor
  working again.
 
 Hi,
 
 Thanks for bisecting the issue. Can you send me your vbios and tell
 me if the nvidia driver shows your temperature probe (and what is
 its source).
 
 To fetch your vbios, you can extract it using nvagetbios from the
 envytools repo: https://github.com/envytools/envytools
 
 Cheers,
 Martin

How can I check source and temperature probe in nvidia binary driver?

-- 
Pali Rohár
pali.ro...@gmail.com



signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: nouveau: temperature on nv40 is unavailable since ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954

[Pali Rohár]

On utorok, 13. augusta 2013 15:32:45 CEST, Martin Peres wrote:

On 13/08/2013 09:23, Pali Rohár wrote:

On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:

 ...
You can check the temperature by running nvidia-settings. If you can't
see the temperature in it, then nvidia doesn't support it on your card and
I'm not sure we should :s

Thanks for the vbios you sent me in private. For the others, the reason
why he doesn't have temperature anymore is because his vbios lacks
sensor calibration values.




In nvidia-settings tab GPU 0 - (GeForce 6600 GT) -- Thermal Settings is:

Thermal Sensor Information:
ID: 0
Target: GPU
Provider: GPU Internal
Temperature: 70 C (now)

I looked in Windows program SpeedFan. It found Nvidia PCI card and reported GPU 
Temp about 68-70 C. So it looks like both nvidia driver and windows SpeedFan 
program reading same values.

--
Pali Rohár
pali.ro...@gmail.com

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Fwd: Brightness on HP EliteBook 8460p

[Pali Rohár]

On Tuesday 31 July 2012 12:17:05 Alex Deucher wrote:
> On Tue, Jul 31, 2012 at 12:03 PM, Pali Roh?r 
 wrote:
> > On Tuesday 31 July 2012 17:49:32 Luca Tettamanti wrote:
> >> I'm putting back the CC and adding Alex.
> >> 
> >> On Tue, Jul 31, 2012 at 5:07 PM, Pali Roh?r
> > 
> >  wrote:
> >> > Thanks, now working. When I write to acpi video brightness
> >> > file it change brightness and in dmesg is:
> >> > 
> >> > [   47.200998] [drm:radeon_atif_handler], event,
> >> > device_class
> >> > = video, type = 0xd0
> >> > [   47.201102] [drm:radeon_atif_get_sbios_requests], SBIOS
> >> > pending requests: 0x80
> >> > [   47.201104] [drm:radeon_atif_handler], ATIF: 1 pending
> >> > SBIOS requests
> >> > [   47.201105] [drm:radeon_atif_handler], Changing
> >> > brightness
> >> > to 11
> >> 
> >> Great! I'll send an updated patch to Alex soon.
> >> 
> >> > I think that acpi only sent event about brightness key
> >> > pressed, because nothing happened when I pressed it.
> >> > 
> >> > Also for windows is needed special HP application (hp
> >> > hotkey)
> >> > for brightness keys. Without it brightness keys not
> >> > working
> >> > too...
> >> 
> >> I've looked at hp-wmi: the hotkey is indeed dispatched via
> >> WMI
> >> (hp-wmi) so you need something in userspace (KDE, Gnome,
> >> etc)
> >> to respond to that key press.
> > 
> > No, when I rmmod hp-wmi brightness keys still generate
> > events.
> > And when I disable acpi then brightness keys do not generate
> > events but adjust brightness automatically (by BIOS).
> > 
> > I think that hp-wmi on my notebook only handle bluetooth &
> > wifi rfkills and ALS switch. All button working without
> > hp-wmi too.> 
> >> > And there is one problem with
> >> > /sys/class/backlight/radeon_bl.
> >> > When I enable Ambient Light Sensor which auto adjust
> >> > brightness based on sensor data, writing value 0 (min) or
> >> > 255 (max) to /sys/class/backlight/radeon_bl/brightness
> >> > turn
> >> > off display.
> >> 
> >> Ok, that's weird. 0 turns off the panel by design, 255
> >> should
> >> not...
> > 
> > But when ALS is disabled 0 did not turn display off.
> 
> 0 only turns off the backlight, not the panel itself.  Is the
> backlight still partially on or is it just the actual panel
> (timing and image)?
> 
> Alex

I looked at display again and 0 only turn backlight off (or 
adjust minimum value). If I look at display correctly (in dark 
room) I can recognize that display is still on and I can see 
window manager decorations (but text is not readable).

Value 255 when ALS is on has same effect as 0 - adjust minimum 
value (instead maximum).

-- 
Pali Roh?r
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Re: Fwd: Brightness on HP EliteBook 8460p

[Pali Rohár]

On Tuesday 31 July 2012 17:49:32 Luca Tettamanti wrote:
 I'm putting back the CC and adding Alex.

 On Tue, Jul 31, 2012 at 5:07 PM, Pali Rohár
pali.ro...@gmail.com wrote:
  Thanks, now working. When I write to acpi video brightness
  file it change brightness and in dmesg is:
 
  [   47.200998] [drm:radeon_atif_handler], event, device_class
  = video, type = 0xd0
  [   47.201102] [drm:radeon_atif_get_sbios_requests], SBIOS
  pending requests: 0x80
  [   47.201104] [drm:radeon_atif_handler], ATIF: 1 pending
  SBIOS requests
  [   47.201105] [drm:radeon_atif_handler], Changing brightness
  to 11

 Great! I'll send an updated patch to Alex soon.

  I think that acpi only sent event about brightness key
  pressed, because nothing happened when I pressed it.
 
  Also for windows is needed special HP application (hp hotkey)
  for brightness keys. Without it brightness keys not working
  too...
 I've looked at hp-wmi: the hotkey is indeed dispatched via WMI
 (hp-wmi) so you need something in userspace (KDE, Gnome, etc)
 to respond to that key press.


No, when I rmmod hp-wmi brightness keys still generate events.
And when I disable acpi then brightness keys do not generate
events but adjust brightness automatically (by BIOS).

I think that hp-wmi on my notebook only handle bluetooth  wifi
rfkills and ALS switch. All button working without hp-wmi too.

  And there is one problem with /sys/class/backlight/radeon_bl.
  When I enable Ambient Light Sensor which auto adjust
  brightness based on sensor data, writing value 0 (min) or
  255 (max) to /sys/class/backlight/radeon_bl/brightness turn
  off display.
 Ok, that's weird. 0 turns off the panel by design, 255 should
 not...

But when ALS is disabled 0 did not turn display off.

  All
  other values (1-254) are OK (adjust brightness level). When I
  turn off Ambient Light Sensor (via hp-wmi kernel module) then
  values 0 and 255 also set brightness level (min and max). My
  suggestion is to convert value 0 to 1 and 255 to 254 to
  prevent this problem.

 No idea what's going on here... might be some weird vendor
 magic. The WMI code is rather obscure...

 Luca

ACPI/WMI cannot change brightness, see this what doing that ALS
function: http://lists.freedesktop.org/archives/dri-devel/2012-
March/020416.html

--
Pali Rohár
pali.ro...@gmail.com

signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Fwd: Brightness on HP EliteBook 8460p

[Pali Rohár]

On Tuesday 31 July 2012 12:17:05 Alex Deucher wrote:
 On Tue, Jul 31, 2012 at 12:03 PM, Pali Rohár
pali.ro...@gmail.com wrote:
  On Tuesday 31 July 2012 17:49:32 Luca Tettamanti wrote:
  I'm putting back the CC and adding Alex.
 
  On Tue, Jul 31, 2012 at 5:07 PM, Pali Rohár
 
  pali.ro...@gmail.com wrote:
   Thanks, now working. When I write to acpi video brightness
   file it change brightness and in dmesg is:
  
   [   47.200998] [drm:radeon_atif_handler], event,
   device_class
   = video, type = 0xd0
   [   47.201102] [drm:radeon_atif_get_sbios_requests], SBIOS
   pending requests: 0x80
   [   47.201104] [drm:radeon_atif_handler], ATIF: 1 pending
   SBIOS requests
   [   47.201105] [drm:radeon_atif_handler], Changing
   brightness
   to 11
 
  Great! I'll send an updated patch to Alex soon.
 
   I think that acpi only sent event about brightness key
   pressed, because nothing happened when I pressed it.
  
   Also for windows is needed special HP application (hp
   hotkey)
   for brightness keys. Without it brightness keys not
   working
   too...
 
  I've looked at hp-wmi: the hotkey is indeed dispatched via
  WMI
  (hp-wmi) so you need something in userspace (KDE, Gnome,
  etc)
  to respond to that key press.
 
  No, when I rmmod hp-wmi brightness keys still generate
  events.
  And when I disable acpi then brightness keys do not generate
  events but adjust brightness automatically (by BIOS).
 
  I think that hp-wmi on my notebook only handle bluetooth 
  wifi rfkills and ALS switch. All button working without
  hp-wmi too.
   And there is one problem with
   /sys/class/backlight/radeon_bl.
   When I enable Ambient Light Sensor which auto adjust
   brightness based on sensor data, writing value 0 (min) or
   255 (max) to /sys/class/backlight/radeon_bl/brightness
   turn
   off display.
 
  Ok, that's weird. 0 turns off the panel by design, 255
  should
  not...
 
  But when ALS is disabled 0 did not turn display off.

 0 only turns off the backlight, not the panel itself.  Is the
 backlight still partially on or is it just the actual panel
 (timing and image)?

 Alex

I looked at display again and 0 only turn backlight off (or
adjust minimum value). If I look at display correctly (in dark
room) I can recognize that display is still on and I can see
window manager decorations (but text is not readable).

Value 255 when ALS is on has same effect as 0 - adjust minimum
value (instead maximum).

--
Pali Rohár
pali.ro...@gmail.com

signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Fwd: Brightness on HP EliteBook 8460p

[Pali Rohár]

On Tuesday 31 July 2012 17:49:32 Luca Tettamanti wrote:
> I'm putting back the CC and adding Alex.
> 
> On Tue, Jul 31, 2012 at 5:07 PM, Pali Roh?r 
 wrote:
> > Thanks, now working. When I write to acpi video brightness
> > file it change brightness and in dmesg is:
> > 
> > [   47.200998] [drm:radeon_atif_handler], event, device_class
> > = video, type = 0xd0
> > [   47.201102] [drm:radeon_atif_get_sbios_requests], SBIOS
> > pending requests: 0x80
> > [   47.201104] [drm:radeon_atif_handler], ATIF: 1 pending
> > SBIOS requests
> > [   47.201105] [drm:radeon_atif_handler], Changing brightness
> > to 11
> 
> Great! I'll send an updated patch to Alex soon.
> 
> > I think that acpi only sent event about brightness key
> > pressed, because nothing happened when I pressed it.
> > 
> > Also for windows is needed special HP application (hp hotkey)
> > for brightness keys. Without it brightness keys not working
> > too...
> I've looked at hp-wmi: the hotkey is indeed dispatched via WMI
> (hp-wmi) so you need something in userspace (KDE, Gnome, etc)
> to respond to that key press.
> 

No, when I rmmod hp-wmi brightness keys still generate events. 
And when I disable acpi then brightness keys do not generate 
events but adjust brightness automatically (by BIOS).

I think that hp-wmi on my notebook only handle bluetooth & wifi 
rfkills and ALS switch. All button working without hp-wmi too.

> > And there is one problem with /sys/class/backlight/radeon_bl.
> > When I enable Ambient Light Sensor which auto adjust
> > brightness based on sensor data, writing value 0 (min) or
> > 255 (max) to /sys/class/backlight/radeon_bl/brightness turn
> > off display.
> Ok, that's weird. 0 turns off the panel by design, 255 should
> not...

But when ALS is disabled 0 did not turn display off.

> > All
> > other values (1-254) are OK (adjust brightness level). When I
> > turn off Ambient Light Sensor (via hp-wmi kernel module) then
> > values 0 and 255 also set brightness level (min and max). My
> > suggestion is to convert value 0 to 1 and 255 to 254 to
> > prevent this problem.
> 
> No idea what's going on here... might be some weird vendor
> magic. The WMI code is rather obscure...
> 
> Luca

ACPI/WMI cannot change brightness, see this what doing that ALS 
function: http://lists.freedesktop.org/archives/dri-devel/2012-
March/020416.html

-- 
Pali Roh?r
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Re: Fwd: Brightness on HP EliteBook 8460p

[Pali Rohár]

Hello, I have some good news. Radeon patches from this post
http://lists.freedesktop.org/archives/dri-devel/2012-July/025535.html
export brightness file /sys/class/backlight/radeon_bl/brightness
And finally with these patches I'm able to change brightness on my EliteBook.

--
Pali Rohár
pali.ro...@gmail.com

signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Fwd: Brightness on HP EliteBook 8460p

[Pali Rohár]

Hello, I have some good news. Radeon patches from this post
http://lists.freedesktop.org/archives/dri-devel/2012-July/025535.html
export brightness file /sys/class/backlight/radeon_bl/brightness
And finally with these patches I'm able to change brightness on my EliteBook.

-- 
Pali Roh?r
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Fwd: Brightness on HP EliteBook 8460p

[Pali Rohár]

On Saturday 04 February 2012 20:19:16 Joey Lee wrote:
> Add Cc. to dri mail
> 
> Hi Pali,
> 
> ? ??2012-02-03 ? 16:24 +0100?Pali Roh?r ???
> 
> > On Friday 20 January 2012 17:55:57 Pali Roh?r wrote:
> > > On Friday 20 January 2012 11:28:59 joeyli wrote:
> > > > ? ??2012-01-20 ? 11:12 +0800?joeyli ???
> > > > 
> > > > > Hi Pali,
> > > > > 
> > > > > Sorry for I am late reply you.
> > > > > 
> > > > > ? ??2012-01-17 ? 19:10 +0100?Pali Roh?r ???
> > > > > 
> > > > > > On Wednesday 21 December 2011 12:45:07 Pali Roh?r wrote:
> > > > > > > Hello,
> > > > > > > 
> > > > > > > I tried to boot with all 3 strings in acpi_os_name, but
> > > > > > > nothing was
> > > > > > > changed. I'm attaching dmesg outputs, one from BIOS
> > > > > > > mode, one from
> > > > > > > UEFI mode. Both are with "Microsoft Windows NT".
> > > > > > 
> > > > > > Did you looked at my logs?
> > > > > 
> > > > > I checked your dmesg log, found the acpi_os_name kernel
> > > > > parameter is :
> > > > > 
> > > > > [0.00] Command line:
> > > > > BOOT_IMAGE=/vmlinuz-3.2.0-4-generic
> > > > > root=UUID=4ec6272a-8551-40f3-a1b1-3e10984f3e69 ro
> > > > > pcie_aspm=force
> > > > > acpi.debug_level=0x2 acpi.debug_layer=0x
> > > > > "acpi_os_name=Microsoft Windows NT" splash vt.handoff=7
> > > > > 
> > > > > We still need by-pass the os name check in DSDT when test
> > > > > function key,> > > > 
> > > > > please help to feed:
> > > > >   acpi_os_name="Windows 2009"
> > > > > 
> > > > > And,
> > > > > looks like the acpi debug level not enough, please kindly
> > > > > change acpi> > > > 
> > > > > debug parameter to:
> > > > >   acpi.debug_level=0xF acpi.debug_layer=0x
> > > > >   log_buf_len=5M
> > > > > 
> > > > > summary:
> > > > >   acpi.debug_level=0xF acpi.debug_layer=0x
> > > > >   log_buf_len=5M
> > > > >   acpi_os_name="Windows 2009"
> > > > 
> > > > Forgot remind,
> > > > please remember press brightness function key a couple of
> > > > times before you dump the dmesg and messages log.
> > > > 
> > > > 
> > > > Thanks a lot!
> > > > Joey Lee
> > > 
> > > Hello,
> > > 
> > > there was no acpi log, so I recompiled ubuntu kernel with
> > > CONFIG_ACPI_DEBUG=y and CONFIG_ACPI_DEBUG_FUNC_TRACE. Then I
> > > started kernel with your params.
> > > 
> > > Now I'm attaching very long debug output. I belive it will be
> > > now usefull.
> > > 
> > > Pressing brightness keys did not show anything in log.
> > > 
> > > After writing 0 to /sys/class/backlight/acpi_video0/brightness
> > > in log appear: [   57.675070] [ACPI Debug]  Integer
> > > 0x000B ...
> > > 
> > > And after writing 10:
> > > [   99.865208] [ACPI Debug]  Integer 0x0048
> > > [   99.865295]   evmisc-0120 [4294967289]
> > > ev_queue_notify_reques:
> > > Dispatching Notify on [DGFX] Node 880136246c80 Value 0xD0
> > > (**Device Specific**) [   99.865350]video-1474 [4294967289]
> > > video_bus_notify> > 
> > > : Unsupported event [0xd0]
> > 
> > Do you need more logs? Or is this enought?
> 
> Yes, as you point out, this is a doubt for video bus received 0xD0
> event but nobody take care it.
> 
> Traced dsdt of EliteBook 8460p from you, the _BCM like this:
> 
> Method (_BCM, 1, Serialized)/* ATI _BCM, per
> log, run this _BCM */ {
> Store (\_SB.BCM (Arg0), Local0) /* set next level,
> normally return 0x1 if XP sp2 or later */ If (Local0)  
>   /* if XP sp2 or later */ {
> Store (BRID, Local1)
> If (LEqual (SBRV (), 0x00)) /* normally SBRV
> return 1, will not emit SMI */ {
> \_SB.SSMI (0xEA74, 0x04, Local1, 0x00, 0x00)
> }
> 
> Signal (\_SB.BEVT)  /* emit BEVT event, HKFR
> (HotkeyFunctionResponse) waiting it, but why? */ }
> }
> 
> _BCM call SBRV to setup brightness value to variable ABRI:
> 
> Method (SBRV, 0, Serialized)/* call by ATI _BCM */
> {
> Store (\_SB.SBRC (), ABRI)  /* SBRC() return the
> brightness value, why store to ABRI? only used in PEGP.DGFX.AFN2 */
> Or (PSBR, 0x80, PSBR)
> Notify (^, 0xD0)/* notify method's parent:
> PEGP.DGFX by 0xD0 */ Return (0x01)   /*
> normally return 1 */ }The PEGP.DGFX acpi device was binding to
> acpi/video driver, the above ASL code emit a 0xD0 bus event to
> video.c but cann't process it. Even we add a new bus event in
> video.c and generate a acpi event, there still need another acpi
> driver should take care it.
> 
> I thought this acpi event might need take care by radeon drm, but I
> am not good for radeon, need more help.
> 
> Per your acpi debug log, the brightness value was changed normally
> when you access _BCM:
> 
> 83133 Jan 20 17:17:51 Pali-EliteBook kernel: [   57.674669] ACPI:
> Execute Method [\_SB_.PCI0.PEGP.DGFX.LCD_._BCM] (Node 8 
> 801362472a8)  # start test _BCM manually 83134 Jan 20 17:17:51
> Pali-EliteBook 

Re: Fwd: Brightness on HP EliteBook 8460p

[Pali Rohár]

On Saturday 04 February 2012 20:19:16 Joey Lee wrote:
 Add Cc. to dri mail

 Hi Pali,

 於 五，2012-02-03 於 16:24 +0100，Pali Rohár 提到：

  On Friday 20 January 2012 17:55:57 Pali Rohár wrote:
   On Friday 20 January 2012 11:28:59 joeyli wrote:
於 五，2012-01-20 於 11:12 +0800，joeyli 提到：
   
 Hi Pali,

 Sorry for I am late reply you.

 於 二，2012-01-17 於 19:10 +0100，Pali Rohár 提到：

  On Wednesday 21 December 2011 12:45:07 Pali Rohár wrote:
   Hello,
  
   I tried to boot with all 3 strings in acpi_os_name, but
   nothing was
   changed. I'm attaching dmesg outputs, one from BIOS
   mode, one from
   UEFI mode. Both are with Microsoft Windows NT.
 
  Did you looked at my logs?

 I checked your dmesg log, found the acpi_os_name kernel
 parameter is :

 [0.00] Command line:
 BOOT_IMAGE=/vmlinuz-3.2.0-4-generic
 root=UUIDNc6272a-8551-40f3-a1b1-3e10984f3e69 ro
 pcie_aspm=force
 acpi.debug_level=0x2 acpi.debug_layer=0x
 acpi_os_name=Microsoft Windows NT splash vt.handoff=7

 We still need by-pass the os name check in DSDT when test
 function key,   
 please help to feed:
   acpi_os_name=Windows 2009

 And,
 looks like the acpi debug level not enough, please kindly
 change acpi   
 debug parameter to:
   acpi.debug_level=0xF acpi.debug_layer=0x
   log_buf_len=5M

 summary:
   acpi.debug_level=0xF acpi.debug_layer=0x
   log_buf_len=5M
   acpi_os_name=Windows 2009
   
Forgot remind,
please remember press brightness function key a couple of
times before you dump the dmesg and messages log.
   
   
Thanks a lot!
Joey Lee
  
   Hello,
  
   there was no acpi log, so I recompiled ubuntu kernel with
   CONFIG_ACPI_DEBUG=y and CONFIG_ACPI_DEBUG_FUNC_TRACE. Then I
   started kernel with your params.
  
   Now I'm attaching very long debug output. I belive it will be
   now usefull.
  
   Pressing brightness keys did not show anything in log.
  
   After writing 0 to /sys/class/backlight/acpi_video0/brightness
   in log appear: [   57.675070] [ACPI Debug]  Integer
   0x000B ...
  
   And after writing 10:
   [   99.865208] [ACPI Debug]  Integer 0x0048
   [   99.865295]   evmisc-0120 [4294967289]
   ev_queue_notify_reques:
   Dispatching Notify on [DGFX] Node 880136246c80 Value 0xD0
   (**Device Specific**) [   99.865350]video-1474 [4294967289]
   video_bus_notify 
   : Unsupported event [0xd0]
 
  Do you need more logs? Or is this enought?

 Yes, as you point out, this is a doubt for video bus received 0xD0
 event but nobody take care it.

 Traced dsdt of EliteBook 8460p from you, the _BCM like this:

 Method (_BCM, 1, Serialized)/* ATI _BCM, per
 log, run this _BCM */ {
 Store (\_SB.BCM (Arg0), Local0) /* set next level,
 normally return 0x1 if XP sp2 or later */ If (Local0)
   /* if XP sp2 or later */ {
 Store (BRID, Local1)
 If (LEqual (SBRV (), 0x00)) /* normally SBRV
 return 1, will not emit SMI */ {
 \_SB.SSMI (0xEA74, 0x04, Local1, 0x00, 0x00)
 }

 Signal (\_SB.BEVT)  /* emit BEVT event, HKFR
 (HotkeyFunctionResponse) waiting it, but why? */ }
 }

 _BCM call SBRV to setup brightness value to variable ABRI:

 Method (SBRV, 0, Serialized)/* call by ATI _BCM */
 {
 Store (\_SB.SBRC (), ABRI)  /* SBRC() return the
 brightness value, why store to ABRI? only used in PEGP.DGFX.AFN2 */
 Or (PSBR, 0x80, PSBR)
 Notify (^, 0xD0)/* notify method's parent:
 PEGP.DGFX by 0xD0 */ Return (0x01)   /*
 normally return 1 */ }The PEGP.DGFX acpi device was binding to
 acpi/video driver, the above ASL code emit a 0xD0 bus event to
 video.c but cann't process it. Even we add a new bus event in
 video.c and generate a acpi event, there still need another acpi
 driver should take care it.

 I thought this acpi event might need take care by radeon drm, but I
 am not good for radeon, need more help.

 Per your acpi debug log, the brightness value was changed normally
 when you access _BCM:

 83133 Jan 20 17:17:51 Pali-EliteBook kernel: [   57.674669] ACPI:
 Execute Method [\_SB_.PCI0.PEGP.DGFX.LCD_._BCM] (Node 8
 801362472a8)  # start test _BCM manually 83134 Jan 20 17:17:51
 Pali-EliteBook kernel: [   57.674736] exregion-0199 [01]
 ex_system_memory_space: System-Memory (width 8  ) R/W 0
 Address00BF7ACE1C 83135 Jan 20 17:17:51 Pali-EliteBook
 kernel: [   57.674748] exregion-0199 [02] ex_system_memory_space:
 System-Memory (width 8  ) R/W 1 Address00BF7ACE1C ...
 83179 Jan 20 17:17:51 Pali-EliteBook kernel: [   57.675070] [ACPI
 Debug]  Integer 0x000B# brightness value is 11 83180
 Jan 20 17:17:51 Pali-EliteBook kernel

Display brightness on Radeon 6470

[Pali Rohár]

Hi,

can you look at problem with setting display brightness on radeon 6470 card?

http://www.mail-archive.com/platform-driver-x86 at vger.kernel.org/msg02862.html
https://bugzilla.kernel.org/show_bug.cgi?id=40862

-- 
Pali Roh?r
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Display brightness on Radeon 6470

[Pali Rohár]

Hi,

can you look at problem with setting display brightness on radeon 6470 card?

http://www.mail-archive.com/platform-driver-x86@vger.kernel.org/msg02862.html
https://bugzilla.kernel.org/show_bug.cgi?id@862

--
Pali Rohár
pali.ro...@gmail.com

signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel