[Bug 85021] radeon: Allow one to set "mid" to power_dpm_force_performance_level

https://bugzilla.kernel.org/show_bug.cgi?id=85021 --- Comment #7 from higuita --- Ok, so if "mid" would work for old cards and is not easy to implement, probably is not worth the trouble as most people don't manually set the power level. i will try to solve my problem another way or maybe

[PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

sertions(+), 177 deletions(-) > > > > OK, I guess this is as good as it gets. > > > > What tree would you like it go through? > > Do we really need this new helper ? I mean, the very moment when we > decide to implement ->runtime_idle() we will need to get rid of this > change. I wonder if it's really valid... I'm not sure I'm following? This seems to simply implement what drivers have been doing already as one function. Why would it be invalid to reduce code duplication? -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/8b65c651/attachment-0001.sig>

[PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

On Wednesday, September 24, 2014 09:44:50 PM Vinod Koul wrote: > This patch series adds a simple macro pm_runtime_last_busy_and_autosuspend() > which invokes pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend() > sequentially. Then we do a tree wide update of current patterns which are >

[git pull] drm fixes

Hi Linus, Some final radeon and i915 fixes, black screens mostly Dave. The following changes since commit 0f33be009b89d2268e94194dc4fd01a7851b6d51: Linux 3.17-rc6 (2014-09-21 15:43:02 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes

[PATCH] drm: Drop grab fpriv->fbs_lock in drm_fb_release

Paulo Zanoni reported a lockdep splat with a locking inversion between fpriv->fbs_lock and the modeset locks. This issue was introduced in commit f2b50c1161590c3bcdbf3455fe4c575f1c1bd293 Author: Daniel Vetter Date: Fri Sep 12 17:07:32 2014 +0200 drm: Fixup locking for universal cursor

[PATCH 07/27] vga_switcheroo: use pm_runtime_last_busy_and_autosuspend helper

Use the new pm_runtime_last_busy_and_autosuspend helper instead of open coding the same code Signed-off-by: Vinod Koul --- drivers/gpu/vga/vga_switcheroo.c |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/vga/vga_switcheroo.c

[PATCH 06/27] drm/radeon: use pm_runtime_last_busy_and_autosuspend helper

Use the new pm_runtime_last_busy_and_autosuspend helper instead of open coding the same code Signed-off-by: Vinod Koul --- drivers/gpu/drm/radeon/radeon_connectors.c | 15 +-- drivers/gpu/drm/radeon/radeon_drv.c|5 ++--- drivers/gpu/drm/radeon/radeon_kms.c|

[PATCH 05/27] drm/nouveau: use pm_runtime_last_busy_and_autosuspend helper

Use the new pm_runtime_last_busy_and_autosuspend helper instead of open coding the same code Signed-off-by: Vinod Koul --- drivers/gpu/drm/nouveau/nouveau_connector.c |3 +-- drivers/gpu/drm/nouveau/nouveau_drm.c |9 +++-- 2 files changed, 4 insertions(+), 8 deletions(-) diff

[PATCH 04/27] drm/i915: use pm_runtime_last_busy_and_autosuspend helper

Use the new pm_runtime_last_busy_and_autosuspend helper instead of open coding the same code Signed-off-by: Vinod Koul --- drivers/gpu/drm/i915/intel_pm.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c

[PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

This patch series adds a simple macro pm_runtime_last_busy_and_autosuspend() which invokes pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend() sequentially. Then we do a tree wide update of current patterns which are present. As evident from log below this pattern is frequent in the

[PULL] topic/core-stuff

On Wed, Sep 24, 2014 at 12:24:53PM +0200, Daniel Vetter wrote: > Hi Dave, > > Just noticed that you've picked up the header rework stuff already, so > I've rebased that out again. Otherwise just two stragglers from the vblank > rework and the universal cursor planes locking fix. Plus sprinkling >

[Bug 79980] Random radeonsi crashes

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/0e99e357/attachment-0001.html>

[PATCH 04/27] drm/i915: use pm_runtime_last_busy_and_autosuspend helper

On Wed, Sep 24, 2014 at 09:44:54PM +0530, Vinod Koul wrote: > Use the new pm_runtime_last_busy_and_autosuspend helper instead of open > coding the same code > > Signed-off-by: Vinod Koul Ack to merge through whatever tree is appropriate for this. Or tell me when I should pick this up for

[Bug 82441] [gma500] Dell Inspiron Mini 1010 black screen after boot

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/128a49d7/attachment.html>

[Bug 78562] [gma500] wrong pixel clock on LVDS (half the correct frequency)

org/archives/dri-devel/attachments/20140924/17ab2827/attachment.html>

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

is created (depends on use_native_backlight > >>>>>> param). And userspace will pick dell-laptop (or acpi > >>>>>> video) to use (which cannot change brightness). > >>>>>> > >>>>>>> Why would you want to use dell-laptop despite the i915 > >>>>>>> driver working fine ? > >>>>>> > >>>>>> i915 working only if I compile kernel without acpi > >>>>>> video dell- laptop support (distributions compile > >>>>>> kernel with these drivers) and i915 is not good for > >>>>>> usage. First it provides more then thousand brightness > >>>>>> levels and lot of (with low numbers) completely turn > >>>>>> display off. And if userspace map these thousand > >>>>>> levels into 5-10 levels (as nobody want to press > >>>>>> brightness key up/down 1000x) two lowest levels cause > >>>>>> display off. > >>>>> > >>>>> More and more laptops will only have working backlight > >>>>> control at all when using i915, so userspace will need > >>>>> to learn to better deal with backlight controls with > >>>>> these ranges. And low pwm levels turning the backlight > >>>>> of is normal for raw interfaces, if userspace does not > >>>>> want this, then they should not go so low. > >>>> > >>>> So then kernel should report which low levels turn > >>>> backlight off so userspace will know which levels should > >>>> avoid. But this is not implemented yet. > >>>> > >>>>> I suggest that you file a bug against your desktop > >>>>> environment that it is not using the backlight controls > >>>>> in an optimal manner, from the kernel pov everything is > >>>>> working fine. > >>>> > >>>> Once I will know which levels should not DE use I can > >>>> report bug. > >>>> > >>>>>> With acpi > >>>>>> video and dell-laptop driver levels are mapped into > >>>>>> small level space in perfect way. So this is reason I > >>>>>> want to use dell-laptop for controlling brightness. > >>>>> > >>>>> If you want to use dell-laptop, specify > >>>>> acpi_backlight=vendor on the kernel commandline, that > >>>>> will give you dell_laptop + intel_backlight as > >>>>> backlight interfaces, and userspace should prefer > >>>>> dell_laptop. > >>>> > >>>> With acpi_backlight=vendor dell-laptop is not working, > >>>> see my previous mail. In this case intel i915 drm driver > >>>> ignore bios events for changing brightness. And > >>>> userspace prefer to use dell_laptop which do nothing! > >>> > >>> Ok, that problematic commit is: > >>> > >>> ACPI / i915: ignore firmware requests for backlight change > >>> 0b9f7d93ca6109048a4eb06332b666b6e29df4fe > >>> > >>> When I reverted it acpi_backlight=vendor started working > >>> again (via dell_laptop). Without reverting that commit > >>> dell_laptop simply do nothing. > >>> > >>> Tested and on my laptop Dell Latitude E6440 driver > >>> dell_laptop does not work with above commit. > >> > >> Hmm, interesting, so when dell-laptop registers and makes a > >> few calls using the dell-laptop acpi interface, > > > > No, dell-laptop is *not* acpi driver. See my first mail. It > > uses dell dcdbas driver which makes SMI calls for SMBIOS. > > But it (on my machine! no idea about other older once) just > > forward brightness change to intel driver. And it has > > useful brightness levels (no lot of levels which turning > > display off). > > > > And making SMI calls can be done also from userspace. There > > is tool dellLcdBrightness in libsmbios package which for > > brightness. And commit > > 0b9f7d93ca6109048a4eb06332b666b6e29df4fe broke > > functionality of that tool. > > > >> then you either stop getting key press events through the > >> acpi-video-bus, or dell-laptop is just a shim around the > >> i915 interface with the firmware calling into itself on > >> these models. Given that dell-laptop is ancient, the shim > >> story is not that far fetched. > > > > Brightness Fn keys are reported by WMI (dell-wmi driver), so > > they working without dell-laptop and acpi video drivers > > perfectly. > > > >> Do you still get an on screen display showing the > >> brightness when using a kernel without this patch + > >> acpi_backlight=vendor ? > > > > Brightness Fn keys are reported to userspace (from WMI input > > device) with any combination of video.use_native_backlight > > and acpi_backlight kernel params. > > 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. -- 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: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/13639ce2/attachment-0001.sig>

[PULL] drm-intel-fixes

Hi Dave, a couple of small fixes for 3.17 still. BR, Jani. The following changes since commit 0f33be009b89d2268e94194dc4fd01a7851b6d51: Linux 3.17-rc6 (2014-09-21 15:43:02 -0700) are available in the git repository at: git://anongit.freedesktop.org/drm-intel

[PULL] topic/core-stuff

On Wed, Sep 24, 2014 at 6:24 PM, Ilia Mirkin wrote: > On Wed, Sep 24, 2014 at 6:24 AM, Daniel Vetter > wrote: >> Hi Dave, >> >> Just noticed that you've picked up the header rework stuff already, so >> I've rebased that out again. Otherwise just two stragglers from the vblank >> rework and the

[Bug 84292] [r600] crashes in Tropico 5 with Radeon HD 5xxx

are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/cba9b1b4/attachment.html>

[Bug 84292] [r600] crashes in Tropico 5 with Radeon HD 5xxx

|5 with Radeon HD 5xxx |with Radeon HD 5xxx -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/e8238

[PATCH v4 5/5] drm/rockchip: Add support for Rockchip Soc EDP

On 2014/9/24 7:35, Rob Clark wrote: > On Tue, Sep 23, 2014 at 9:56 AM, Rob Clark wrote: >> On Tue, Sep 23, 2014 at 4:47 AM, cym wrote: >>> On Tuesday, September 23, 2014 03:20 AM, Rob Clark wrote: On Mon, Sep 22, 2014 at 7:02 AM, Mark yao wrote: > This adds support for Rockchip

[Bug 84292] Radeonsi crashes in Tropico 5 with Radeon HD 5xxx

vel/attachments/20140924/7e26bb88/attachment.html>

drm/radeon: fix AGP userptr handling

Hello Christian K?nig, This is a semi-automatic email about new static checker warnings. The patch 3840a656f61f: "drm/radeon: fix AGP userptr handling" from Sep 17, 2014, leads to the following Smatch complaint: drivers/gpu/drm/radeon/radeon_ttm.c:708 radeon_ttm_tt_populate() error:

[Bug 84292] Radeonsi crashes in Tropico 5 with Radeon HD 5xxx

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/a83e92c0/attachment.html>

[Bug 84292] New: Radeonsi crashes in Tropico 5 with Radeon HD 5xxx

eedesktop.org/archives/dri-devel/attachments/20140924/5ff5a664/attachment.html>

[pull] radeon drm-next-3.18

Hi Dave, Just some fixes for 3.18. These are all pretty non-invasive. - Re-enable some dpm features that were previously disabled due to a bug that was fixed in 3.16 - Make some arrays static - re-arrange some audio code to properly reflect connected status in the audio driver The following

[PATCH v4 1/5] drm/rockchip: Add basic drm driver

On 2014?09?24? 16:20, Daniel Vetter wrote: > On Mon, Sep 22, 2014 at 06:48:54PM +0800, Mark yao wrote: >> This patch adds the basic structure of a DRM Driver for Rockchip Socs. >> >> Signed-off-by: Mark yao >> --- >> Changes in v2: >> - use the component framework to defer main drm driver probe

[PATCH] drm: Drop grab fpriv->fbs_lock in drm_fb_release

2014-09-24 16:55 GMT-03:00 Daniel Vetter : > Paulo Zanoni reported a lockdep splat with a locking inversion between > fpriv->fbs_lock and the modeset locks. This issue was introduced in > > commit f2b50c1161590c3bcdbf3455fe4c575f1c1bd293 > Author: Daniel Vetter > Date: Fri Sep 12 17:07:32 2014

[Bug 75276] Implement VGPR Register Spilling

ves/dri-devel/attachments/20140924/ceee0f03/attachment.html>

[PATCH 10/10] drm/omap: fix TILER on OMAP5

On OMAP5 it is not possible to use TILER buffer with CPU when caching or write-combining is used. Doing so leads to errors from the memory manager. However, on OMAP4, write-combining works fine. This patch adds platform specific data for the TILER, and a function tiler_get_cpu_cache_flags()

[pull] radeon drm-fixes-3.17

Hi Dave, Some radeon fixes for 3.17: - fix a backlight regression resulting in dark screen - add a PX quirk to avoid a hang with runtime pm - fix an init issue on the CIK compute rings - fix IH ring buffer overflows gracefully The following changes since commit

[PATCH 06/27] drm/radeon: use pm_runtime_last_busy_and_autosuspend helper

On Wed, Sep 24, 2014 at 12:14 PM, Vinod Koul wrote: > Use the new pm_runtime_last_busy_and_autosuspend helper instead of open > coding the same code > > Signed-off-by: Vinod Koul Acked-by: Alex Deucher I don't care which tree this goes through. > --- >

[PATCH 07/27] vga_switcheroo: use pm_runtime_last_busy_and_autosuspend helper

On Wed, Sep 24, 2014 at 12:14 PM, Vinod Koul wrote: > Use the new pm_runtime_last_busy_and_autosuspend helper instead of open > coding the same code > > Signed-off-by: Vinod Koul Acked-by: Alex Deucher > --- > drivers/gpu/vga/vga_switcheroo.c |7 +++ > 1 files changed, 3

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: >

[PATCH 9/9] drm/omap: handle mismatching color format and buffer width

omapdrm doesn't check if the width of the framebuffer and the color format's bits-per-pixel match. For example, using a display with a width of 1280, and a buffer allocated with using 32 bits per pixel (i.e. 1280*4 = 5120 bytes), with a 24 bits per pixel color format, leads to the following

[PATCH 8/9] drm/omap: fix error handling in omap_framebuffer_create()

When an error happens in omap_framebuffer_create(), omap_framebuffer_create() calls omap_framebuffer_destroy() if the fb struct has been allocated. However, that crashes, as omap_framebuffer_destroy(), which calls drm_framebuffer_cleanup(), should only be called after drm_framebuffer_init() Fix

[PATCH 7/9] drm/omap: fix operation without fbdev

omapdrm should work fine even if fbdev is missing. The current driver crashes in that case, though, as it is missing checks for the fbdev. Add the checks so that we don't free fbdev or restore fbdev mode when there's no fbdev. Signed-off-by: Tomi Valkeinen ---

[PATCH 6/9] drm/omap: add a comment why locking is missing

unpin_worker() calls omap_framebuffer_unpin() without any locks, which looks very suspicious. However, both pin and unpin are always called via the driver's private workqueue, so the access is synchronized that way. Add a comment to make this clear. Signed-off-by: Tomi Valkeinen ---

[PATCH 5/9] drm/omap: add pin refcounting to omap_framebuffer

omap_framebuffer_pin() and omap_framebuffer_unpin() are currently broken, as they cannot be called multiple times (i.e. pin, pin, unpin, unpin), which is what happens in certain cases. This issue causes the driver to possibly use 0 as an address for a displayed buffer, leading to OCP error from

[PATCH 4/9] drm/omap: clear omap_obj->paddr in omap_gem_put_paddr()

Clear omap_obj's paddr when unmapping the memory, so that it's easier to catch bad use of the paddr. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_gem.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c b/drivers/gpu/drm/omapdrm/omap_gem.c

[PATCH 3/9] drm/omap: fix race issue with vsync irq and apply

omap_crtc's apply_worker does: omap_irq_register(dev, _crtc->apply_irq); dispc_mgr_go(channel); This is supposed to enable the vsync irq, and set the GO bit. The vsync handler will later check if the HW has cleared the GO bit and queue apply work. However, what may happen is

[PATCH 2/9] drm/omap: page_flip: return -EBUSY if flip pending

The DRM documentation says: "If a page flip is already pending, the page_flip operation must return -EBUSY." Currently omapdrm returns -EINVAL instead. Fix omapdrm by returning -EBUSY. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_crtc.c | 2 +- 1 file changed, 1

[PATCH 1/9] drm/omap: fix encoder-crtc mapping

OMAP DSS hardware supports changing the output port to which an overlay manager's video stream goes. For example, DPI video stream can come from any of the four overlay managers on OMAP5. However, as it's difficult to manage the change in the driver, the omapdss driver does not support that at

[PATCH 0/9] drm/omap: misc fixes

Hi, This is a modified version of the series I sent earlier (http://comments.gmane.org/gmane.comp.video.dri.devel/113812). I haven't had time to work on the locking issues, so I've dropped the patches related to that so that the rest could get merged. I have also added three new small patches

[PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

tions(+), 177 deletions(-) > > > > > > OK, I guess this is as good as it gets. > > > > > > What tree would you like it go through? > > > > Do we really need this new helper ? I mean, the very moment when we > > decide to implement ->runtime_idle() we will need to get rid of this > > change. I wonder if it's really valid... > > I'm not sure I'm following? This seems to simply implement what drivers > have been doing already as one function. Why would it be invalid to reduce > code duplication? For two reasons: 1) the helper has no inteligence whatsoever. It just calls the same functions. 2) the duplication will vanish whenever someone implements ->runtime_idle() and have that call pm_runtime_autosuspend() (like PCI and USB buses are doing today). This will just be yet another line that needs to change. Frankly though, no strong feelings, I just think it's a commit that doesn't bring that any benefits other than looking like one line was removed. -- balbi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/b24c7ffc/attachment-0001.sig>

[Bug 83708] [vdpau,uvd] kernel oops, Unable to handle kernel paging request at virtual address

e same as 1. Must do cpu_to_le32 transfer By the way, u said writel() and readl() already convert to/from little endian. is based on the X86 arch implement? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/ca81f200/attachment.html>

[PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

+--- > > include/linux/pm_runtime.h |6 +++ > > 31 files changed, 97 insertions(+), 177 deletions(-) > > OK, I guess this is as good as it gets. > > What tree would you like it go through? Do we really need this new helper ? I mean, the very moment when we decide to implement ->runtime_idle() we will need to get rid of this change. I wonder if it's really valid... -- balbi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/c68f5603/attachment-0001.sig>

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

> >>>> these drivers) and i915 is not good for usage. First it > >>>> provides more then thousand brightness levels and lot of > >>>> (with low numbers) completely turn display off. And if > >>>> userspace map these thousand levels into 5-10 levels (as > >>>> nobody want to press brightness key up/down 1000x) two > >>>> lowest levels cause display off. > >>> > >>> More and more laptops will only have working backlight > >>> control at all when using i915, so userspace will need to > >>> learn to better deal with backlight controls with these > >>> ranges. And low pwm levels turning the backlight of is > >>> normal for raw interfaces, if userspace does not want > >>> this, then they should not go so low. > >> > >> So then kernel should report which low levels turn > >> backlight off so userspace will know which levels should > >> avoid. But this is not implemented yet. > >> > >>> I suggest that you file a bug against your desktop > >>> environment that it is not using the backlight controls in > >>> an optimal manner, from the kernel pov everything is > >>> working fine. > >> > >> Once I will know which levels should not DE use I can > >> report bug. > >> > >>>> With acpi > >>>> video and dell-laptop driver levels are mapped into small > >>>> level space in perfect way. So this is reason I want to > >>>> use dell-laptop for controlling brightness. > >>> > >>> If you want to use dell-laptop, specify > >>> acpi_backlight=vendor on the kernel commandline, that will > >>> give you dell_laptop + intel_backlight as backlight > >>> interfaces, and userspace should prefer dell_laptop. > >> > >> With acpi_backlight=vendor dell-laptop is not working, see > >> my previous mail. In this case intel i915 drm driver > >> ignore bios events for changing brightness. And userspace > >> prefer to use dell_laptop which do nothing! > > > > Ok, that problematic commit is: > > > > ACPI / i915: ignore firmware requests for backlight change > > 0b9f7d93ca6109048a4eb06332b666b6e29df4fe > > > > When I reverted it acpi_backlight=vendor started working > > again (via dell_laptop). Without reverting that commit > > dell_laptop simply do nothing. > > > > Tested and on my laptop Dell Latitude E6440 driver > > dell_laptop does not work with above commit. > > Hmm, interesting, so when dell-laptop registers and makes a > few calls using the dell-laptop acpi interface, No, dell-laptop is *not* acpi driver. See my first mail. It uses dell dcdbas driver which makes SMI calls for SMBIOS. But it (on my machine! no idea about other older once) just forward brightness change to intel driver. And it has useful brightness levels (no lot of levels which turning display off). And making SMI calls can be done also from userspace. There is tool dellLcdBrightness in libsmbios package which for brightness. And commit 0b9f7d93ca6109048a4eb06332b666b6e29df4fe broke functionality of that tool. > then you either stop getting key press events through the > acpi-video-bus, or dell-laptop is just a shim around the i915 > interface with the firmware calling into itself on these > models. Given that dell-laptop is ancient, the shim story is > not that far fetched. > Brightness Fn keys are reported by WMI (dell-wmi driver), so they working without dell-laptop and acpi video drivers perfectly. > Do you still get an on screen display showing the brightness > when using a kernel without this patch + > acpi_backlight=vendor ? > Brightness Fn keys are reported to userspace (from WMI input device) with any combination of video.use_native_backlight and acpi_backlight kernel params. > Regards, > > Hans -- 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: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/a1cc358f/attachment-0001.sig>

[PATCH v3 11/11] drm/i915: remove intel_pipe_set_base()

From: Gustavo Padovan After some refactor intel_primary_plane_setplane() does the same as intel_pipe_set_base() so we can get rid of it and replace the calls with intel_primary_plane_setplane(). v2: take Ville's comments: - get the right arguments for

[PATCH v3 10/11] drm/i915: use intel_fb_obj() macros to assign gem objects

From: Gustavo Padovan Use the macros makes the code cleaner and it also checks for a NULL fb. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/i915/intel_sprite.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git

[PATCH v3 09/11] drm/i915: create a prepare phase for sprite plane updates

From: Gustavo Padovan take out pin_fb code so the commit phase can't fail anymore. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/i915/intel_sprite.c | 63 +++-- 1 file changed, 40 insertions(+), 23 deletions(-) diff --git

[PATCH v3 08/11] drm/i915: create a prepare step for primary planes updates

From: Gustavo Padovan Take out the pin_fb code so commit phase can't fail anymore. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/i915/intel_display.c | 35 ++- 1 file changed, 26 insertions(+), 9 deletions(-) diff --git

[PATCH v3 07/11] drm: add helper to get crtc timings

From: Gustavo Padovan We need to get hdisplay and vdisplay in a few places so create a helper to make our job easier. Suggested-by: Ville Syrj?l? Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/drm_crtc.c | 20 +---

[PATCH v3 06/11] drm/i915: split intel_crtc_page_flip() into check() and commit()

From: Daniel Stone Start the work of splitting the intel_crtc_page_flip() for later use by the atomic modesetting API. Signed-off-by: Daniel Stone Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/i915/intel_display.c | 51 ++-- 1 file

[PATCH v3 05/11] drm/i915: remove intel_crtc_cursor_set_obj()

From: Gustavo Padovan Merge it into the plane update_plane() callback and make other users use the update_plane() functions instead. The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj() so we fold intel_crtc_cursor_set_obj() inside

[PATCH v3 04/11] drm/i915: move check of intel_crtc_cursor_set_obj() out

From: Gustavo Padovan Move check inside intel_crtc_cursor_set_obj() to intel_check_cursor_plane(), we only use it there so move them out to make the merge of intel_crtc_cursor_set_obj() into intel_check_cursor_plane() easier. This is another step toward the

[PATCH v3 03/11] drm/i915: Fix not checking cursor and object sizes

From: Gustavo Padovan Even if the fb is the same we should still check if the sizes are valid to be set. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/i915/intel_display.c | 61 1 file changed, 41 insertions(+), 20

[PATCH v3 02/11] drm/i915: remove leftover from pre-universal planes days

From: Gustavo Padovan Now that universal planes are in place we don't need this plane unref on failures. Suggested-by: Ville Syrj?l? Signed-off-by: Gustavo Padovan Reviewed-by: Ville Syrj?l? --- drivers/gpu/drm/i915/intel_display.c | 12 +--- 1 file

[PATCH v3 01/11] drm/i915: Merge of visible and !visible paths for primary planes

From: Gustavo Padovan Fold intel_pipe_set_base() in the update primary plane path merging pieces of code that are common to both paths. Basically the the pin/unpin procedures are the same for both paths and some checks can also be shared (some of the were moved

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, >

[patch] drm/gma500: some return code fixes

In psb_mmu_insert_pfn_sequence() we set the error code but don't use it and the caller doesn't check for error either. I have changed it to return an error and to check. In psb_driver_load() there are a couple paths where we don't set an error code on allocation failure. I've made those return

[PATCH] drm: move legacy device members into a substruct.

From: Dave Airlie This is step one towards allocating these on demand for legacy devices. First group all the legacy struct members into their own structure and include it into the main drm driver structure directly. Signed-off-by: Dave Airlie ---

[PATCH v4 1/5] drm/rockchip: Add basic drm driver

On Wed, Sep 24, 2014 at 11:31 AM, Mark yao wrote: > On 2014?09?24? 16:20, Daniel Vetter wrote: >> >> On Mon, Sep 22, 2014 at 06:48:54PM +0800, Mark yao wrote: >>> >>> This patch adds the basic structure of a DRM Driver for Rockchip Socs. >>> >>> Signed-off-by: Mark yao >>> --- >>> Changes in v2:

[Bug 83861] radeon power management cause audio skips and glitch

https://bugzilla.kernel.org/show_bug.cgi?id=83861 --- Comment #5 from Francesco --- please,. we need an answer if is possible, a solution!5 months with this bug , the bug is present on kernel 3.16 and on 3.17, we neeed a solutioN :'( -- You are receiving this mail because: You are watching the

[Bug 83861] radeon power management cause audio skips and glitch

https://bugzilla.kernel.org/show_bug.cgi?id=83861 --- Comment #4 from Yomi --- Created attachment 151761 --> https://bugzilla.kernel.org/attachment.cgi?id=151761=edit Xorg.log -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 83861] radeon power management cause audio skips and glitch

https://bugzilla.kernel.org/show_bug.cgi?id=83861 --- Comment #3 from Yomi --- Created attachment 151751 --> https://bugzilla.kernel.org/attachment.cgi?id=151751=edit dmesg dmesg -- You are receiving this mail because: You are watching the assignee of the bug.

[PULL] topic/core-stuff

Hi Dave, Just noticed that you've picked up the header rework stuff already, so I've rebased that out again. Otherwise just two stragglers from the vblank rework and the universal cursor planes locking fix. Plus sprinkling container_of all over fbdev emulation from Fabian. Aside: I only have

[PULL] topic/core-stuff

On Wed, Sep 24, 2014 at 6:24 AM, Daniel Vetter wrote: > Hi Dave, > > Just noticed that you've picked up the header rework stuff already, so > I've rebased that out again. Otherwise just two stragglers from the vblank > rework and the universal cursor planes locking fix. Plus sprinkling >

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

ication/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/a9f85d9c/attachment-0001.sig>

[PATCH] drm/exynos: fimd: fix screen shaking issue on i80 mode

This patch resolves a issue that screen is shaked after resumed. The issue could be incurred when overlay registers are updated to new buffer while fimd is still transmitting video data. So this patch make sure to wait for the completion of the transmission if fimd is transmitting video data

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

ion. I have to say the endpoint system feels cleaner than the above, but perhaps it's possible to improve the method above somehow. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/3ae43015/attachment.sig>

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

cklight or not. I don't know if we need a different representation for bridges and panels. Thinking about backlight, the driver can just register the backlight device if it needs one. There's no need to differentiate bridges and panels for that. But maybe there are other reasons that warrant different representations. However, my current feeling is that there's no need for different representations. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/0c858afa/attachment-0001.sig>

[PATCH] drm/i915: reduce memory footprint for debugging

On Tue, 23 Sep 2014, Stefan Br?ns wrote: > see df8fbc231b7e4a78dae2b02e116fe73e4ea63cb0 Andy beat you to it with commit a8e98153627dfbb10ff4dd65729676115a932b2e Author: Andy Shevchenko Date: Mon Sep 1 14:12:01 2014 +0300 drm: i915: reduce memory footprint when debugging on its way

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

ousand levels into 5-10 levels (as > > > nobody want to press brightness key up/down 1000x) two > > > lowest levels cause display off. > > > > More and more laptops will only have working backlight > > control at all when using i915, so userspace will need to > > learn to better deal with backlight controls with these > > ranges. And low pwm levels turning the backlight of is > > normal for raw interfaces, if userspace does not want this, > > then they should not go so low. > > So then kernel should report which low levels turn backlight > off so userspace will know which levels should avoid. But > this is not implemented yet. > > > I suggest that you file a bug against your desktop > > environment that it is not using the backlight controls in > > an optimal manner, from the kernel pov everything is > > working fine. > > Once I will know which levels should not DE use I can report > bug. > > > > With acpi > > > video and dell-laptop driver levels are mapped into small > > > level space in perfect way. So this is reason I want to > > > use dell-laptop for controlling brightness. > > > > If you want to use dell-laptop, specify > > acpi_backlight=vendor on the kernel commandline, that will > > give you dell_laptop + intel_backlight as backlight > > interfaces, and userspace should prefer dell_laptop. > > With acpi_backlight=vendor dell-laptop is not working, see my > previous mail. In this case intel i915 drm driver ignore bios > events for changing brightness. And userspace prefer to use > dell_laptop which do nothing! > Ok, that problematic commit is: ACPI / i915: ignore firmware requests for backlight change 0b9f7d93ca6109048a4eb06332b666b6e29df4fe When I reverted it acpi_backlight=vendor started working again (via dell_laptop). Without reverting that commit dell_laptop simply do nothing. Tested and on my laptop Dell Latitude E6440 driver dell_laptop does not work with above commit. > > But IMHO it would be better to file a bug > > with your desktop environment, and get that fixed to work > > properly with intel_backlight (or with raw backlight > > interfaces in general). > > > > Regards, > > > > Hans > > > > >> Regards, > > >> > > >> Hans -- 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: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/dd8208f7/attachment-0001.sig>

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

ress brightness key up/down 1000x) two > > lowest levels cause display off. > > More and more laptops will only have working backlight control > at all when using i915, so userspace will need to learn to > better deal with backlight controls with these ranges. And > low pwm levels turning the backlight of is normal for raw > interfaces, if userspace does not want this, then they should > not go so low. > So then kernel should report which low levels turn backlight off so userspace will know which levels should avoid. But this is not implemented yet. > I suggest that you file a bug against your desktop environment > that it is not using the backlight controls in an optimal > manner, from the kernel pov everything is working fine. > Once I will know which levels should not DE use I can report bug. > > With acpi > > video and dell-laptop driver levels are mapped into small > > level space in perfect way. So this is reason I want to use > > dell-laptop for controlling brightness. > > If you want to use dell-laptop, specify acpi_backlight=vendor > on the kernel commandline, that will give you dell_laptop + > intel_backlight as backlight interfaces, and userspace should > prefer dell_laptop. With acpi_backlight=vendor dell-laptop is not working, see my previous mail. In this case intel i915 drm driver ignore bios events for changing brightness. And userspace prefer to use dell_laptop which do nothing! > But IMHO it would be better to file a bug > with your desktop environment, and get that fixed to work > properly with intel_backlight (or with raw backlight > interfaces in general). > > Regards, > > Hans > > >> Regards, > >> > >> Hans -- 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: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/3f3e68c1/attachment-0001.sig>

[PATCH] drm/i915: reduce memory footprint for debugging

On Tue, Sep 23, 2014 at 08:04:07PM +0200, Stefan Br?ns wrote: > see df8fbc231b7e4a78dae2b02e116fe73e4ea63cb0 > > Signed-off-by: Stefan Br?ns I already have such a patch: commit a8e98153627dfbb10ff4dd65729676115a932b2e Author: Andy Shevchenko Date: Mon Sep 1 14:12:01 2014 +0300 drm:

[PATCH v6 0/2] ASoC: tda998x: add a codec to the HDMI transmitter

The NXP TDA998x HDMI transmitter may transmit audio to the HDMI link from 2 different sources, I2S and S/PDIF. This patch set adds an interface between the HDMI transmitter and the HDMI CODEC. The interface is used by the TDA998x driver to update the audio constraints from the display

[PATCH v4 1/5] drm/rockchip: Add basic drm driver

On Mon, Sep 22, 2014 at 06:48:54PM +0800, Mark yao wrote: > This patch adds the basic structure of a DRM Driver for Rockchip Socs. > > Signed-off-by: Mark yao > --- > Changes in v2: > - use the component framework to defer main drm driver probe > until all VOP devices have been probed. > - use

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 >>>

[PATCH v5 3/3] dt-bindings: video: Add documentation for rockchip vop

This adds binding documentation for Rockchip SoC VOP driver. Signed-off-by: Mark Yao --- Changes in v2: - rename "lcdc" to "vop" - add vop reset - add iommu node - add port for display-subsystem Changes in v3: None Changes in v4: None Changes in v5: None

[PATCH v5 2/3] dt-bindings: video: Add for rockchip display subsytem

This add a display subsystem comprise the all display interface nodes. Signed-off-by: Mark Yao --- Changes in v2: - add DRM master device node to list all display nodes that comprise the graphics subsystem. Changes in v3: None Changes in v4: None Changes in v5: None

[PATCH v5 1/3] drm/rockchip: Add basic drm driver

This patch adds the basic structure of a DRM Driver for Rockchip Socs. Signed-off-by: Mark yao --- Changes in v2: - use the component framework to defer main drm driver probe until all VOP devices have been probed. - use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by master

[PATCH v6 2/2] drm/i2c:tda998x: Use the HDMI audio CODEC

This patch interfaces the HDMI transmitter with the audio system. Signed-off-by: Jean-Francois Moine --- .../devicetree/bindings/drm/i2c/tda998x.txt| 18 ++ drivers/gpu/drm/i2c/Kconfig| 1 + drivers/gpu/drm/i2c/tda998x_drv.c | 299

[PATCH v5 0/3] Add drm driver for Rockchip Socs

This a series of patches is a DRM Driver for Rockchip Socs, add support for vop devices. Future patches will add additional encoders/connectors, such as eDP, HDMI. The basic "crtc" for rockchip is a "VOP" - Video Output Processor. the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two

[PATCH v6 1/2] ASoC:codecs: Add a transmitter interface to the HDMI CODEC CODEC

The audio constraints of the HDMI interface are defined by the EDID which is sent by the connected device. The HDMI transmitters may have one or many audio sources. This patch adds two functions to the HDMI CODEC: - it updates the audio constraints from the EDID, - it gives the audio source type

[PATCH 1/8] drm/: Don't call drm_mmap

On Tue, Sep 23, 2014 at 11:46 PM, Daniel Vetter wrote: > Really, the legacy buffer api should be dead, especially for all these > newfangled drivers. I suspect this is copypasta from the transitioning > days, which probably originated in radeon. > > Cc: David Airlie > Cc: Alex Deucher > Cc:

[Bug 84176] [glamor] X goes out of memory while running x11perf

are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/a77d4694/attachment-0001.html>

[Bug 83708] [vdpau,uvd] kernel oops, Unable to handle kernel paging request at virtual address

ug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/4e186695/attachment.html>

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

On 09/23/2014 04:41 PM, Thierry Reding wrote: > On Tue, Sep 23, 2014 at 12:34:54PM +0200, Andrzej Hajda wrote: >> On 09/23/2014 12:10 PM, Thierry Reding wrote: >>> On Tue, Sep 23, 2014 at 11:43:47AM +0200, Andrzej Hajda wrote: On 09/23/2014 10:35 AM, Thierry Reding wrote: >>> [...] > But

[Bug 81045] [r600] Unreal Engine 4 demo crashed kernel

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/ab8bb18d/attachment.html>

[PATCH 0/3] drm: Fix possible ZERO_SIZE_PTR pointer dereferencing error.

Ping :) Thanks, BRs Xiubo > -Original Message- > From: Xiubo Li [mailto:Li.Xiubo at freescale.com] > Sent: Tuesday, August 12, 2014 11:30 AM > To: airlied at linux.ie; dri-devel at lists.freedesktop.org > Cc: Xiubo Li-B47053 > Subject: [PATCH 0/3] drm: Fix possible ZERO_SIZE_PTR

Stupid NVIDIA 3D vgaarb.c patch

On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote: > Adding proper people and mailing lists.. > > The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by > BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is > appropriate, but hopefully somebody does. The fact that it makes

[Bug 85021] radeon: Allow one to set "mid" to power_dpm_force_performance_level

https://bugzilla.kernel.org/show_bug.cgi?id=85021 --- Comment #6 from Alex Deucher --- (In reply to higuita from comment #2) > Auto will jump from level 0 to level 2, i never see level 1 being used in > any place/app other than a maximized glxgears. > > tvtime or chrome+youtube+thml5 will jump

[Bug 84178] Big glamor regression in Xorg server 1.6.99.1 GIT: x11perf 1.5 Test: PutImage XY 500x500 Square

are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/2ad82f11/attachment.html>

[Bug 84178] Big glamor regression in Xorg server 1.6.99.1 GIT: x11perf 1.5 Test: PutImage XY 500x500 Square

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/a40411d1/attachment.html>

[Bug 85021] radeon: Allow one to set "mid" to power_dpm_force_performance_level

https://bugzilla.kernel.org/show_bug.cgi?id=85021 --- Comment #5 from higuita --- The gpu is one old ATI HD2600XP AGP: 01:00.0 VGA compatible controller: AMD/ATI [Advanced Micro Devices, Inc.] RV630 XT [Radeon HD 2600 XT AGP] I usually use this command to see what level the gpu is: cat

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

eceiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140924/90c4218a/attachment.html>

[Bug 85021] radeon: Allow one to set "mid" to power_dpm_force_performance_level

https://bugzilla.kernel.org/show_bug.cgi?id=85021 --- Comment #4 from Alexandre Demers --- Created attachment 151651 --> https://bugzilla.kernel.org/attachment.cgi?id=151651=edit Script showing some information on the gpu you will have to run this script using "sudo" or somthing similar. It

[Bug 85021] radeon: Allow one to set "mid" to power_dpm_force_performance_level

https://bugzilla.kernel.org/show_bug.cgi?id=85021 Alexandre Demers changed: What|Removed |Added CC||alexandre.f.demers at gmail.co

[Bug 83861] radeon power management cause audio skips and glitch

https://bugzilla.kernel.org/show_bug.cgi?id=83861 Yomi changed: What|Removed |Added CC||abyomi0 at gmail.com --- Comment #2 from Yomi

  1   2   >