Re: [Intel-gfx] startx on Fedora died today

crashing when systemd-logind integration is used. https://bugzilla.redhat.com/show_bug.cgi?id=1118540 Signed-off-by: Hans de Goede hdego...@redhat.com --- include/hotplug.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/hotplug.h b/include/hotplug.h index c4268a0..b2c0d78

[Intel-gfx] [REGRESSION BISECTED] backlight control stops workin with 3.14 and later

Hi Jani et al, A friend of mine Bertrik Sikken (in the Cc) his backlight control stopped working for him on his Samsung N150Plus netbook. I took a quick look, and the raw intel_backlight backlight interface works under 3.14, but the firmware samsung_laptop backlight interface, which is what most

Re: [Intel-gfx] [REGRESSION BISECTED] backlight control stops workin with 3.14 and later

Hi, On 07/22/2014 08:52 AM, Daniel Vetter wrote: On Tue, Jul 22, 2014 at 8:42 AM, Hans de Goede hdego...@redhat.com wrote: Hi Jani et al, A friend of mine Bertrik Sikken (in the Cc) his backlight control stopped working for him on his Samsung N150Plus netbook. I took a quick look

Re: [Intel-gfx] PROBLEM: Native backlight regressed from logarithmic to linear scale

Hi, On 07/22/2014 06:32 AM, Anders Kaseorg wrote: [1.] One line summary of the problem: Native backlight regressed from logarithmic to linear scale [2.] Full description of the problem/report: With the new default of video.use_native_backlight=0 (commit v3.16-rc1~30^2~2^3), my

Re: [Intel-gfx] [REGRESSION BISECTED] backlight control stops workin with 3.14 and later

Hi, On 08/22/2014 08:48 AM, Jani Nikula wrote: On Fri, 22 Aug 2014, Bertrik Sikken bert...@sikken.nl wrote: On 19-8-2014 3:29, Jani Nikula wrote: On Tue, 19 Aug 2014, Bertrik Sikken bert...@sikken.nl wrote: On Sun, 17 Aug 2014, Bertrik Sikken bert...@sikken.nl wrote: On 15-8-2014 3:43, Jani

[Intel-gfx] [PATCH] backlight: Don't read back backlight setting from kernel on DPMS off

to backlight_active_level which now is 0. This commit fixes this by not reading back the backlight setting from the kernel on DPMS off. Signed-off-by: Hans de Goede hdego...@redhat.com --- src/sna/sna_display.c | 3 --- src/uxa/intel_display.c | 3 --- 2 files changed, 6 deletions(-) diff --git a/src/sna

Re: [Intel-gfx] [PATCH] backlight: Don't read back backlight setting from kernel on DPMS off

Hi, On 06/05/2014 04:29 PM, Chris Wilson wrote: On Thu, Jun 05, 2014 at 05:01:23PM +0300, Jani Nikula wrote: On Thu, 05 Jun 2014, Hans de Goede hdego...@redhat.com wrote: We've several reports from users where the backlight comes up turned off on starting X, when using

Re: [Intel-gfx] [PATCH] backlight: Don't read back backlight setting from kernel on DPMS off

Hi, On 06/05/2014 10:24 PM, Chris Wilson wrote: On Thu, Jun 05, 2014 at 09:08:33PM +0200, Hans de Goede wrote: Note that it is read after the framebuffer has been resized and a new mode has been set on pipe 0 using LVDS1, could this perhaps cause the 0 to be read when using actual_brightness

Re: [Intel-gfx] [PATCH] backlight: Don't read back backlight setting from kernel on DPMS off

Hi, On 06/05/2014 10:24 PM, Chris Wilson wrote: On Thu, Jun 05, 2014 at 09:08:33PM +0200, Hans de Goede wrote: Note that it is read after the framebuffer has been resized and a new mode has been set on pipe 0 using LVDS1, could this perhaps cause the 0 to be read when using actual_brightness

Re: [Intel-gfx] [PATCH] backlight: Don't read back backlight setting from kernel on DPMS off

Hi, On 06/06/2014 04:51 PM, Chris Wilson wrote: On Fri, Jun 06, 2014 at 04:37:36PM +0200, Hans de Goede wrote: Hi, On 06/05/2014 10:24 PM, Chris Wilson wrote: On Thu, Jun 05, 2014 at 09:08:33PM +0200, Hans de Goede wrote: Note that it is read after the framebuffer has been resized and a new

[Intel-gfx] xf86-video-intel-2.99.912 with dri3 enabled breaks gnome-shell

Hi All, While preparing 1.15.99.903 server + 2.99.912 intel drv packages for Fedora 21, I noticed that both gdm and gnome-shell (tested with startx) hang, they show the initial background screen and then just sit there. Building the server with --disable-dri3, or building the intel drv with a

Re: [Intel-gfx] video: X sets brightness to zero after resume

Hi, On 06/13/2014 03:28 AM, Aaron Lu wrote: On 06/12/2014 08:42 PM, Kalle Valo wrote: Hi Aaron, after your commit 0e9f81d3b7c (ACPI / video: Add systems that should favour native backlight interface) I have had an regression that every time after resume the display brightness has been set

Re: [Intel-gfx] [PATCH] backlight: Don't read back backlight setting from kernel on DPMS off

Hi, On 06/07/2014 01:12 PM, Chris Wilson wrote: On Sat, Jun 07, 2014 at 12:18:35PM +0200, Hans de Goede wrote: Hi, On 06/06/2014 04:51 PM, Chris Wilson wrote: commit c6cd10f536e099277cdc46643725a5a50ea8b525 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu Jun 5 22:43:37 2014 +0100

[Intel-gfx] xf86-video-intel hits an assert when using dri and xorg is not suid root

Hi, When trying to run the latest xorg + intel drv, with dri3, with Xorg not running as root, the followin assert in src/intel_device.c: authorise() : assert(is_i915_gem(fd)); Triggers, this is caused by the DRM_IOCTL_I915_GETPARAM ioctl in is_i915_gem() failing with -EACCESS in this case. I

Re: [Intel-gfx] xf86-video-intel hits an assert when using dri and xorg is not suid root

Hi, On 06/13/2014 02:36 PM, Chris Wilson wrote: On Fri, Jun 13, 2014 at 02:08:06PM +0200, Hans de Goede wrote: Hi, When trying to run the latest xorg + intel drv, with dri3, with Xorg not running as root, the followin assert in src/intel_device.c: authorise() : assert(is_i915_gem(fd

Re: [Intel-gfx] xf86-video-intel hits an assert when using dri and xorg is not suid root

Hi, On 06/13/2014 02:53 PM, Chris Wilson wrote: On Fri, Jun 13, 2014 at 02:44:44PM +0200, Hans de Goede wrote: Hi, On 06/13/2014 02:36 PM, Chris Wilson wrote: On Fri, Jun 13, 2014 at 02:08:06PM +0200, Hans de Goede wrote: Hi, When trying to run the latest xorg + intel drv, with dri3

[Intel-gfx] [PATCH 2/2] uxa: Mark the output as off before making pipe changes

This is a partial backport of commit c6cd10f536, which makes the same change for sna, to avoid users still using uxa ending up with a blackscreen after plugging in an external monitor. Signed-off-by: Hans de Goede hdego...@redhat.com --- src/uxa/intel_display.c | 8 1 file changed, 8

[Intel-gfx] [PATCH 1/2] uxa: When the output is off, report the cached backlight value

This is a backport of commit b545e10c50cb to uxa, so that users who are still using uxa, don't end up with a black screen after suspend / resume. Signed-off-by: Hans de Goede hdego...@redhat.com --- src/uxa/intel_display.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff

Re: [Intel-gfx] [PATCH] backlight: Fix compile error

Hi, On 06/18/2014 02:51 PM, Chris Wilson wrote: On Wed, Jun 18, 2014 at 02:41:56PM +0200, Hans de Goede wrote: /usr/include/xorg/os.h around line 579 reads: extern _X_EXPORT char * strndup(const char *str, size_t n); However strndup is already defined by glibc, and this redefine causes

Re: [Intel-gfx] [PATCH 2/2] uxa: Mark the output as off before making pipe changes

Hi, On 06/18/2014 03:14 PM, Chris Wilson wrote: On Wed, Jun 18, 2014 at 03:01:37PM +0200, Hans de Goede wrote: This is a partial backport of commit c6cd10f536, which makes the same change for sna, to avoid users still using uxa ending up with a blackscreen after plugging in an external

Re: [Intel-gfx] What to do with xf86-video-intel backlight control when running Xorg as non root

Hi, On 02/13/2014 05:40 PM, Chris Wilson wrote: On Thu, Feb 13, 2014 at 04:52:59PM +0100, Hans de Goede wrote: Hi All, Currently xf86-video-intel is unique in that it is the only video driver which does backlight control inside the driver rather then letting something else (ie the desktop

[Intel-gfx] [PATCH 2/3] xf86-video-intel: export fd_set_cloexec / fd_set_nonblock

Allow fd_set_cloexec / fd_set_nonblock to be used outside of intel_device.c. Signed-off-by: Hans de Goede hdego...@redhat.com --- src/intel_device.c | 8 src/intel_driver.h | 2 ++ 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/src/intel_device.c b/src/intel_device.c

[Intel-gfx] [PATCH 3/3] xf86-video-intel: Add a helper for setting backlight without root rights

the backlight directly on ati and nouveau cards. This commit adds src/backlight.h and src/backlight.c as a place to share common backlight code, in the future most of the duplicate backlight code inside src/sna/sna_display.c and src/uxa/intel_display.c should be moved there. Signed-off-by: Hans de Goede

[Intel-gfx] [PATCH 1/3] xf86-video-intel: Fix fd_set_nonblock

O_NONBLOCK is a status flag not a descriptor flag, so F_GETFL / F_SETFL should be used to modify it. Signed-off-by: Hans de Goede hdego...@redhat.com --- src/intel_device.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/intel_device.c b/src/intel_device.c index

Re: [Intel-gfx] [PATCH 3/3] xf86-video-intel: Add a helper for setting backlight without root rights

Hi, On 02/15/2014 12:54 AM, Chris Wilson wrote: On Sat, Feb 15, 2014 at 12:02:37AM +0100, Hans de Goede wrote: Once the xserver stops running as root on kms capabable systems, we will need some other way to access the backlight. The approach taken in this patch leaves most of the heavy

Re: [Intel-gfx] [PATCH 3/3] xf86-video-intel: Add a helper for setting backlight without root rights

Hi, On 02/15/2014 12:52 PM, Chris Wilson wrote: On Sat, Feb 15, 2014 at 09:48:14AM +0100, Hans de Goede wrote: Hi, On 02/15/2014 12:54 AM, Chris Wilson wrote: On Sat, Feb 15, 2014 at 12:02:37AM +0100, Hans de Goede wrote: Once the xserver stops running as root on kms capabable systems, we

[Intel-gfx] [PATCH 2/4] backlight: Use System instead of system when checking for pkexec

Event though we've failed to open the backlight normally, we may still be running under a suid-root xserver, so use the servers build in System instead of system so as to properly drop root rights. Signed-off-by: Hans de Goede hdego...@redhat.com --- src/backlight.c | 3 ++- 1 file changed, 2

[Intel-gfx] [PATCH 0/4] backlight-helper: fixes and improvements

Hi All, I've tried the backlight code as merged with X running as a regular user + pkexec, and they work as advertised. When reviewing the changes I noticed some minor and not so minor (security!) issues, which this patch series address. Thanks Regards, Hans

[Intel-gfx] [PATCH 4/4] backlight-helper: Simplify reading the level from stdin

with a much simpler loop using fgets, improving readability of the code. Signed-off-by: Hans de Goede hdego...@redhat.com --- tools/backlight_helper.c | 29 +++-- 1 file changed, 7 insertions(+), 22 deletions(-) diff --git a/tools/backlight_helper.c b/tools

[Intel-gfx] [PATCH 3/4] backlight: Drop rights before executing pkexec

Event though we've failed to open the backlight normally, we may still be running under a suid-root xserver, so drop any elevated rights before executing what we hope will be pkxec. Signed-off-by: Hans de Goede hdego...@redhat.com --- src/backlight.c | 4 1 file changed, 4 insertions

[Intel-gfx] [RFC 0/1] Add support for server managed fds

Hi All, Here is a patch to add support for server managed fds to xf86-video-intel this is RFC only atm since not all related server patches have landed yet. With the server patches + this patch it is possible to run Xorg without root-rights on systemd-logind using systems. Regards, Hans

[Intel-gfx] [PATCH] intel: Add support for server managed fds

Signed-off-by: Hans de Goede hdego...@redhat.com --- src/intel_device.c | 19 ++- src/intel_module.c | 4 2 files changed, 10 insertions(+), 13 deletions(-) diff --git a/src/intel_device.c b/src/intel_device.c index d0c8092..b19884c 100644 --- a/src/intel_device.c +++ b/src

Re: [Intel-gfx] [PATCH] intel: Add support for server managed fds

Hi, On 03/07/2014 02:18 PM, Chris Wilson wrote: On Fri, Mar 07, 2014 at 02:13:38PM +0100, Hans de Goede wrote: Signed-off-by: Hans de Goede hdego...@redhat.com --- src/intel_device.c | 19 ++- src/intel_module.c | 4 2 files changed, 10 insertions(+), 13 deletions

[Intel-gfx] [PATCH 2/2] uxa: Add support for server managed fds

and as an added bonus adds server managed fd support. Signed-off-by: Hans de Goede hdego...@redhat.com --- src/intel_device.c | 14 -- src/intel_driver.h | 2 -- src/uxa/intel_driver.c | 44 +++- 3 files changed, 3 insertions(+), 57 deletions

[Intel-gfx] [PATCH 1/2] intel_device: Don't close the fd on probe failure if it is server managed

EBADFD errors. Signed-off-by: Hans de Goede hdego...@redhat.com --- src/intel_device.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/intel_device.c b/src/intel_device.c index c0e1582..2d31ec8 100644 --- a/src/intel_device.c +++ b/src/intel_device.c @@ -339,7 +339,8

Re: [Intel-gfx] ACPI/i915: Cannot configure display brightness on Dell Latitude E6440

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

Re: [Intel-gfx] ACPI/i915: Cannot configure display brightness on Dell Latitude E6440

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

Re: [Intel-gfx] ACPI/i915: Cannot configure display brightness on Dell Latitude E6440

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

Re: [Intel-gfx] ACPI/i915: Cannot configure display brightness on Dell Latitude E6440

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

Re: [Intel-gfx] [PATCH] drm/i915: intel_backlight scale() math WA v2

Hi, On 09/24/2014 05:54 PM, Joe Konno wrote: From: Joe Konno joe.ko...@intel.com Improper truncated integer division in the scale() function causes actual_brightness != brightness. This (partial) work-around should be sufficient for a majority of use-cases, but it is by no means a complete

Re: [Intel-gfx] [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type

lockdep splat. On a hunch I reverted commit 93a291dfaf9c328ca5a9cea1733af1a128efe890 Author: Hans de Goede hdego...@redhat.com Date: Tue Jun 16 16:27:52 2015 +0200 ACPI / video: Move backlight notifier to video_detect.c and the problem seems to be gone. Hans, any thoughts? Looking

[Intel-gfx] [PATCH] ACPI / video: Fix circular lock dependency issue in the video-detect code

or one times during normal system use. Signed-off-by: Hans de Goede hdego...@redhat.com --- drivers/acpi/video_detect.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 815f75e..2922f1f 100644

Re: [Intel-gfx] [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type

Hi, On 13-08-15 16:33, Hans de Goede wrote: Hi, On 12-08-15 21:26, Ville Syrjälä wrote: On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote: On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek sedat.di...@gmail.com

[Intel-gfx] Fixing i915/opregion issues with firmware which lists more then 8 output devices

Hi, As discussed in the past, the i915 opregion code does not do the right thing wrt the CADL field when there are more then 8 outputs, this is causing issues on many different types of Asus laptops. This thread has details and a number of attempts to fix this:

Re: [Intel-gfx] Fixing i915/opregion issues with firmware which lists more then 8 output devices

Hi, On 06-11-15 11:19, Jani Nikula wrote: On Thu, 05 Nov 2015, Hans de Goede <hdego...@redhat.com> wrote: Hi, As discussed in the past, the i915 opregion code does not do the right thing wrt the CADL field when there are more then 8 outputs, this is causing issues on many different

[Intel-gfx] [RFC/PATCH xf86-video-intel] sna: Let modestting + glamor handle gen9+

, just like how nouveau handles falling back to modesetting for newer cards. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1305369 Signed-off-by: Hans de Goede <hdego...@redhat.com> --- src/intel_module.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/intel_module.c

Re: [Intel-gfx] [RFC/PATCH xf86-video-intel] sna: Let modestting + glamor handle gen9+

Hi, On 13-03-16 20:36, Rob Clark wrote: On Fri, Mar 11, 2016 at 5:07 AM, Timo Aaltonen <tjaal...@ubuntu.com> wrote: 29.02.2016, 16:47, Hans de Goede kirjoitti: sna has no meaningfull accel for gen9+, this causes problems with i.e. apps using XVideo since the sprite XVideo suppor

Re: [Intel-gfx] [RFC/PATCH xf86-video-intel] sna: Let modestting + glamor handle gen9+

Hi, On 11-03-16 11:07, Timo Aaltonen wrote: 29.02.2016, 16:47, Hans de Goede kirjoitti: sna has no meaningfull accel for gen9+, this causes problems with i.e. apps using XVideo since the sprite XVideo support does not work well for many apps. Therefor it is better to just let the xserver fall

Re: [Intel-gfx] Fixing i915/opregion issues with firmware which lists more then 8 output devices

Hi Jani, On 23-03-16 12:48, Jani Nikula wrote: On Fri, 06 Nov 2015, Hans de Goede <hdego...@redhat.com> wrote: On 06-11-15 11:19, Jani Nikula wrote: On Thu, 05 Nov 2015, Hans de Goede <hdego...@redhat.com> wrote: Hi, As discussed in the past, the i915 opregion code does not

[Intel-gfx] [PATCH xf86-video-intel] Fix fd (and mem) leak when intel_scrn_create fails

the fallback to the modesetting driver. This commit fixes this by adding a intel_close_device() cleanup function and calling that when intel_scrn_create() fails. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- src/intel_device.c | 17 + src/intel_driver.h | 1

Re: [Intel-gfx] [RFC/PATCH xf86-video-intel] sna: Let modestting + glamor handle gen9+

Hi, On 22-04-16 15:17, Timo Aaltonen wrote: 08.04.2016, 16:21, Hans de Goede kirjoitti: Hi, Hi, sorry for the delay.. On 11-03-16 11:07, Timo Aaltonen wrote: I've been trying to make this work, but there are cases where it fails bad: # a config file with a Device section that loads

[Intel-gfx] [PATCH xf86-video-intel] Fix fd (and mem) leak when intel_scrn_create fails

the fallback to the modesetting driver. This commit fixes this by adding a intel_close_device() cleanup function and calling that when intel_scrn_create() fails. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- src/intel_device.c | 17 + src/intel_driver.h | 1

[Intel-gfx] [PATCH resend xf86-video-intel] Fix fd (and mem) leak when intel_scrn_create fails

the fallback to the modesetting driver. This commit fixes this by adding a intel_close_device() cleanup function and calling that when intel_scrn_create() fails. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- src/intel_device.c | 17 + src/intel_driver.h | 1

Re: [Intel-gfx] [v4, 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Hi, On 26-07-16 19:34, cp...@redhat.com wrote: Since the watermark calculations for Skylake are still broken, we're apt to hitting underruns very easily under multi-monitor configurations. While it would be lovely if this was fixed, it's not. Another problem that's been coming from this

Re: [Intel-gfx] [PATCH] drm/i915: Acquire audio powerwell for HD-Audio registers

Hi, On 04-08-16 23:03, Takashi Iwai wrote: [dropped stable ML and add a few other relevant people to Cc] On Thu, 04 Aug 2016 20:05:27 +0200, Takashi Iwai wrote: On Thu, 04 Aug 2016 18:44:11 +0200, Daniel Vetter wrote: On Wed, Aug 03, 2016 at 05:09:00PM +0100, Chris Wilson wrote: On

Re: [Intel-gfx] [v5, 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Hi, On 08/02/2016 08:52 PM, cp...@redhat.com wrote: Since the watermark calculations for Skylake are still broken, we're apt to hitting underruns very easily under multi-monitor configurations. While it would be lovely if this was fixed, it's not. Another problem that's been coming from this

Re: [Intel-gfx] [PATCH] drm/i915: Fix not finding the VBT when it overlaps with OPREGION_ASLE_EXT

Hi Jani, So any further update on this ? I've just got a report from an user that my fix also fixes the LCD panel on his (different model, ACER SW5_017) machine not lighting up: https://bugzilla.kernel.org/show_bug.cgi?id=155241#c56 Although my fix my be in contradiction with the VBT spec, I

[Intel-gfx] [PATCH v2 0/3] acpi_lpss/pwm: Fix i915 pwm_get issues

Hi All, Here is another attempt at fixing i915 not finding the lpss_pwm device (fixed by calling pwm_table_add from apci_lpss.c) as well as i915 not being capable of pwm_get returning -EPROBE_DEFER. I must sat I rather like this version (vs forcing pwm-lpss* to be builtin), so I hope we can move

[Intel-gfx] [PATCH v2 3/3] acpi: lpss: call pwm_add_table() for bsw PWM device

_add_table() calls directly in PWM drivers (this leads to probe ordering issues), so lets do it here since the acpi-lpss code is always builtin. Signed-off-by: Hans de Goede <hdego...@redhat.com> Acked-by: Thierry Reding <thierry.red...@gmail.com> --- Changes in v2: -Set new pwm_lo

[Intel-gfx] [PATCH v2 1/3] pwm/core: Don't hold pwm_lookup_lock longer then necessary

There is no need to hold pwm_lookup_lock after we're done with looping over pwm_lookup_list, so release it earlier. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/pwm/core.c | 18 -- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/drivers/pwm/

[Intel-gfx] [PATCH v2 2/3] pwm/core: Try to get the module from pwm_get

Add a module_name string to the pwm_lookup struct and if specified and pwmchip_find_by_name() does not find the pwmchip try calling request_module with the specified name. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/pwm/core.c | 4 include/linux/pwm.

Re: [Intel-gfx] [PATCH v2] pwm: lpss: Make builtin so that i915 can find the pwm_backlight

Hi, On 20-01-17 11:42, Thierry Reding wrote: On Fri, Jan 20, 2017 at 11:18:29AM +0100, Hans de Goede wrote: Hi, On 20-01-17 10:55, Andy Shevchenko wrote: On Fri, 2017-01-20 at 10:48 +0100, Hans de Goede wrote: I'm fine with doing a v3 with a comment, how about putting that comment right

Re: [Intel-gfx] [PATCH] drm/i915: Fix not finding the VBT when it overlaps with OPREGION_ASLE_EXT

Hi, On 23-01-17 11:36, Jani Nikula wrote: On Fri, 20 Jan 2017, Hans de Goede <hdego...@redhat.com> wrote: Hi, On 31-12-16 17:00, Hans de Goede wrote: Hi, On 27-12-16 11:58, Jani Nikula wrote: On Sun, 25 Dec 2016, Hans de Goede <hdego...@redhat.com> wrote: If there is no OPREG

Re: [Intel-gfx] [PATCH v2 06/13] i2c: designware-baytrail: Disallow the CPU to enter C6 or C7 while holding the punit semaphore

Hi, On 01/24/2017 10:51 AM, Andy Shevchenko wrote: On Mon, 2017-01-23 at 22:09 +0100, Hans de Goede wrote: On my cherrytrail tablet with axp288 pmic, just doing a bunch of repeated reads from the pmic, e.g. "i2cdump -y 14 0x34" would lookup the tablet in 1 - 3 runs guaranteed.

[Intel-gfx] [PATCH v2 03/13] i2c: designware: Rename accessor_flags to flags

Rename accessor_flags to flags, so that we can use the field for other flags too. This is a preparation patch for adding cherrytrail support to the punit semaphore code. Signed-off-by: Hans de Goede <hdego...@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevche...@linux.intel.c

[Intel-gfx] [PATCH v2 13/13] drm/i915: Acquire P-Unit access when modifying P-Unit settings

Make sure the P-Unit or the PMIC i2c bus is not in use when we send a request to the P-Unit by calling iosf_mbi_punit_acquire() / _release() around P-Unit write accesses. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241 Signed-off-by: Hans de Goede <hdego...@redhat.com>

[Intel-gfx] [PATCH v2 12/13] drm/i915: Listen for PMIC bus access notifications

accessing the PMIC bus to limit their bus accesses to a bare minimum (e.g. cache registers, do not update battery level more often then 4 times a minute), to limit the amount of wakeups. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241 Signed-off-by: Hans de Goede <hdego...@redhat.

[Intel-gfx] [PATCH v2 11/13] drm/i915: Add intel_uncore_suspend / resume functions

intel_uncore_forcewake_reset private. This is a preparation patch for adding PMIC bus access notifier support. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241 Signed-off-by: Hans de Goede <hdego...@redhat.com> Tested-by: tagorereddy <tagore.chan...@gmail.com> --- Changes in v2: -Spelling:

[Intel-gfx] [PATCH v2 07/13] i2c: designware-baytrail: Fix race when resetting the semaphore

Use iosf_mbi_modify instead of iosf_mbi_read + iosf_mbi_write so that we keep the iosf_mbi_lock locked during the read-modify-write done to reset the semaphore. Signed-off-by: Hans de Goede <hdego...@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevche...@linux.intel.com> Acke

[Intel-gfx] [PATCH v2 00/13] coordinate cht i2c-pmic and i915-punit accesses

Hi All, Here is v2 of my cht i2c-pmic and i915-punit access coordination patchset. New in this version are some minor spelling / style fixes and more importantly the inclusion of 6 extra i2c-designware patches. These 6 patches are ready for merging, they have Wolfram's (the i2c maintainer's)

[Intel-gfx] [PATCH v2 06/13] i2c: designware-baytrail: Disallow the CPU to enter C6 or C7 while holding the punit semaphore

everything just hangs. Avoid this by disallowing the CPU to enter C6 or C7 before acquiring the punit bus semaphore. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109051 Signed-off-by: Hans de Goede <hdego...@redhat.com> Tested-by: Takashi Iwai <ti...@suse.de> Review

[Intel-gfx] [PATCH v2 01/13] x86/platform/intel/iosf_mbi: Add a mutex for P-Unit access

it, but this does not appear to be sufficient, we still need to avoid making certain P-Unit requests during the access window to avoid problems. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241 Signed-off-by: Hans de Goede <hdego...@redhat.com> Tested-by: tagorereddy <ta

[Intel-gfx] [PATCH v2 05/13] i2c: designware-baytrail: Only check iosf_mbi_available() for shared hosts

iosf_mbi_available() returns true. Signed-off-by: Hans de Goede <hdego...@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevche...@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nik...@linux.intel.com> Tested-by: Takashi Iwai <ti...@suse.de> Acked-by: Wolfram Sang <w...@the-d

[Intel-gfx] [PATCH v2 04/13] i2c: designware-baytrail: Pass dw_i2c_dev into helper functions

Pass dw_i2c_dev into the helper functions, this is a preparation patch for the punit semaphore fixes done in the other patches in this set. Signed-off-by: Hans de Goede <hdego...@redhat.com> Reviewed-by: Takashi Iwai <ti...@suse.de> Tested-by: Takashi Iwai <ti...@suse.de>

[Intel-gfx] [PATCH v2 02/13] x86/platform/intel/iosf_mbi: Add a PMIC bus access notifier

can acquire any resources, which it may need during the window the other driver is accessing the PMIC, before hand. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241 Signed-off-by: Hans de Goede <hdego...@redhat.com> Tested-by: tagorereddy <tagore.chan...@gmail.com> Revie

[Intel-gfx] [PATCH v2 09/13] i2c: designware-baytrail: Acquire P-Unit access on bus acquire

semaphore. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241 Signed-off-by: Hans de Goede <hdego...@redhat.com> Tested-by: tagorereddy <tagore.chan...@gmail.com> Acked-by: Wolfram Sang <w...@the-dreams.de> --- Changes in v2: -Spelling: P-Unit, PMIC -Adjust for iosf_mbi_

[Intel-gfx] [PATCH v2 10/13] i2c: designware-baytrail: Call pmic_bus_access_notifier_chain

Call the iosf_mbi pmic_bus_access_notifier_chain on bus acquire / release. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241 Signed-off-by: Hans de Goede <hdego...@redhat.com> Tested-by: tagorereddy <tagore.chan...@gmail.com> Reviewed-by: Andy Shevchenko <

[Intel-gfx] [PATCH v2 08/13] i2c: designware-baytrail: Add support for cherrytrail

The cherrytrail punit has the pmic i2c bus access semaphore at a different register address. Signed-off-by: Hans de Goede <hdego...@redhat.com> Reviewed-by: Takashi Iwai <ti...@suse.de> Tested-by: Takashi Iwai <ti...@suse.de> Reviewed-by: Andy Shevchenko <andriy.shevche...@l

Re: [Intel-gfx] [PATCH v2 2/3] pwm/core: Try to get the module from pwm_get

Hi, On 30-01-17 09:17, Thierry Reding wrote: On Sun, Jan 22, 2017 at 05:14:08PM +0100, Hans de Goede wrote: Add a module_name string to the pwm_lookup struct and if specified and pwmchip_find_by_name() does not find the pwmchip try calling request_module with the specified name. Signed-off

Re: [Intel-gfx] [PATCH v2 13/13] drm/i915: Acquire P-Unit access when modifying P-Unit settings

Hi, On 30-01-17 14:10, Ville Syrjälä wrote: On Sat, Jan 28, 2017 at 06:18:45PM +0100, Hans de Goede wrote: Hi, On 01/28/2017 05:25 PM, Hans de Goede wrote: Hi, On 01/27/2017 02:51 PM, Ville Syrjälä wrote: On Mon, Jan 23, 2017 at 10:09:58PM +0100, Hans de Goede wrote: Make sure the P-Unit

Re: [Intel-gfx] [PATCH v2 13/13] drm/i915: Acquire P-Unit access when modifying P-Unit settings

Hi, On 30-01-17 16:38, Ville Syrjälä wrote: On Mon, Jan 30, 2017 at 04:27:58PM +0100, Hans de Goede wrote: Hi, On 30-01-17 16:11, Ville Syrjälä wrote: On Mon, Jan 30, 2017 at 04:02:19PM +0100, Hans de Goede wrote: Hi, On 30-01-17 14:10, Ville Syrjälä wrote: On Sat, Jan 28, 2017 at 06:18

Re: [Intel-gfx] [PATCH v2 13/13] drm/i915: Acquire P-Unit access when modifying P-Unit settings

Hi, On 30-01-17 16:11, Ville Syrjälä wrote: On Mon, Jan 30, 2017 at 04:02:19PM +0100, Hans de Goede wrote: Hi, On 30-01-17 14:10, Ville Syrjälä wrote: On Sat, Jan 28, 2017 at 06:18:45PM +0100, Hans de Goede wrote: Hi, On 01/28/2017 05:25 PM, Hans de Goede wrote: Hi, On 01/27/2017 02:51

Re: [Intel-gfx] [PATCH v2 13/13] drm/i915: Acquire P-Unit access when modifying P-Unit settings

Hi, On 01/27/2017 02:51 PM, Ville Syrjälä wrote: On Mon, Jan 23, 2017 at 10:09:58PM +0100, Hans de Goede wrote: Make sure the P-Unit or the PMIC i2c bus is not in use when we send a request to the P-Unit by calling iosf_mbi_punit_acquire() / _release() around P-Unit write accesses. Can't we

Re: [Intel-gfx] [PATCH v2 11/13] drm/i915: Add intel_uncore_suspend / resume functions

Hi, On 01/27/2017 02:45 PM, Ville Syrjälä wrote: On Mon, Jan 23, 2017 at 10:09:56PM +0100, Hans de Goede wrote: Rename intel_uncore_early_sanitize to intel_uncore_resume, dropping the (always true) restore_forcewake argument and add a new intel_uncore_resume function to replace

Re: [Intel-gfx] [PATCH v2 12/13] drm/i915: Listen for PMIC bus access notifications

Hi, On 01/27/2017 02:52 PM, Ville Syrjälä wrote: On Mon, Jan 23, 2017 at 10:09:57PM +0100, Hans de Goede wrote: Listen for PMIC bus access notifications and get FORCEWAKE_ALL while the bus is accessed to avoid needing to do any forcewakes, which need PMIC bus access, while the PMIC bus is busy

Re: [Intel-gfx] [PATCH v2 13/13] drm/i915: Acquire P-Unit access when modifying P-Unit settings

Hi, On 01/28/2017 05:25 PM, Hans de Goede wrote: Hi, On 01/27/2017 02:51 PM, Ville Syrjälä wrote: On Mon, Jan 23, 2017 at 10:09:58PM +0100, Hans de Goede wrote: Make sure the P-Unit or the PMIC i2c bus is not in use when we send a request to the P-Unit by calling iosf_mbi_punit_acquire

Re: [Intel-gfx] [PATCH 8/9] drm/i915/bxt: Enable BXT DSI dual link

Hi, On 20-02-17 12:00, Jani Nikula wrote: On Mon, 20 Feb 2017, "Srinivas, Vidya" wrote: Thanks Jani. I will rebase and re-submit and also to remove drm_panel interface dependency, I am planning to create panel sequence callbacks in intel_dsi structure itself. Is

[Intel-gfx] [PATCH resend 09/15] drm/i915/dsi: Group DPOunit clock gate workaround with PLL enable

sequence / compare it to the spec 2) It is grouped with the pll disable call in intel_dsi_post_disable, so for consistency it should be grouped with the pll enable in intel_dsi_pre_enable Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/gpu/drm/i915/intel_dsi.

[Intel-gfx] [PATCH resend 08/15] drm/i915/dsi: Move MIPI_SEQ_POWER_ON/OFF calls together with pmic gpio calls

Now that we are no longer bound to the drm_panel_ callbacks, call MIPI_SEQ_POWER_ON/OFF at the proper place. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/gpu/drm/i915/intel_dsi.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/dr

[Intel-gfx] [PATCH resend 12/15] drm/i915/dsi: Document always using v3 SHUTDOWN / MIPI_SEQ_DISPLAY_OFF order

According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF before sending SHUTDOWN, where as for v3 VBTs we should send SHUTDOWN first. Since the v2 order has known issues, we use the v3 order everywhere, add a comment documenting this. Signed-off-by: Hans de Goede <hd

[Intel-gfx] [PATCH resend 14/15] drm/i915/dsi: Call MIPI_SEQ_TEAR_ON and DISPLAY_ON for cmd-mode (untested)

According to the spec we should call MIPI_SEQ_TEAR_ON and DISPLAY_ON on enable for cmd-mode, just like we already call their counterparts on disable. Note: untested, my panel is a vid-mode panel. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/gpu/drm/i915/intel_dsi.c | 2

[Intel-gfx] [PATCH resend 07/15] drm/i915/dsi: Drop bogus MIPI_SEQ_ASSERT_RESET before POWER_ON

MIPI_SEQ_ASSERT_RESET before POWER_ON is not necessary for 2 reasons: 1) The reset should already be asserted before intel_dsi_pre_enable() gets called 2) Most (some?) VBTs will ensure reset was asserted in their MIPI_SEQ_DEASSERT_RESET themselves Signed-off-by: Hans de Goede <hd

[Intel-gfx] [PATCH resend 13/15] drm/i915/dsi: Execute MIPI_SEQ_TEAR_OFF from intel_dsi_post_disable

For v3 VBTs we should call MIPI_SEQ_TEAR_OFF before MIPI_SEQ_DISPLAY_OFF, for non v3 VBTs this is a nop. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/gpu/drm/i915/intel_dsi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/g

[Intel-gfx] [PATCH resend 06/15] drm/i915/dsi: Make intel_dsi_enable/disable directly exec VBT sequences

intel_dsi_exec_vbt_sequence() from intel_dsi_panel_vbt.c and call that from intel_dsi_enable/disable(). No functional changes. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/gpu/drm/i915/intel_dsi.c | 14 +++--- drivers/gpu/drm/i915/intel_dsi.h | 3 +++ drive

[Intel-gfx] [PATCH resend 15/15] drm/i915/dsi: Skip delays for v3 VBTs in vid-mode

For v3 VBTs in vid-mode the delays are part of the VBT sequences, so we should not also delay ourselves otherwise we get double delays. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/gpu/drm/i915/intel_dsi.c | 19 +++ 1 file changed, 15 insertions(+), 4 del

[Intel-gfx] [PATCH resend 10/15] drm/i915/dsi: Execute MIPI_SEQ_DEASSERT_RESET before calling device_ready()

Execute MIPI_SEQ_DEASSERT_RESET before putting the device in ready state (LP-11), this is the sequence in which things should be done according to the spec. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/gpu/drm/i915/intel_dsi.c | 9 +++-- 1 file changed, 7 insertions

[Intel-gfx] [PATCH resend 11/15] drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with panel_[en|dis]able_backlight

Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as we call intel_panel_enable_backlight() / intel_panel_disable_backlight(). Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/gpu/drm/i915/intel_dsi.c | 6 -- 1 file changed, 4 insertions(+), 2 del

Re: [Intel-gfx] i915: Dealing with 90° rotated display ?

Hi, On 16-02-17 17:58, Ville Syrjälä wrote: On Thu, Feb 16, 2017 at 11:01:29AM +0100, Hans de Goede wrote: Hi, On 15-02-17 15:59, Ville Syrjälä wrote: On Wed, Feb 15, 2017 at 03:54:17PM +0100, Hans de Goede wrote: Hi Jani, As discussed here: https://bugs.freedesktop.org/show_bug.cgi?id

[Intel-gfx] [PATCH resend 04/15] drm/i915/dsi: Move intel_dsi_clear_device_ready()

not make any changes what-so-ever. Signed-off-by: Hans de Goede <hdego...@redhat.com> Acked-by: Jani Nikula <jani.nik...@intel.com> --- drivers/gpu/drm/i915/intel_dsi.c | 86 1 file changed, 43 insertions(+), 43 deletions(-) diff --git a/drivers/

[Intel-gfx] [PATCH resend 05/15] drm/i915/dsi: Document the panel enable / disable sequences from the spec

Document the DSI panel enable / disable sequences from the spec, for easy comparison between the code and the spec. Signed-off-by: Hans de Goede <hdego...@redhat.com> Acked-by: Jani Nikula <jani.nik...@intel.com> --- drivers/gpu/drm/i915/inte

  1   2   3   4   5   6   7   8   9   10   >