[PATCH v7 11/17] Documentation: phy: add document for rockchip dp phy
Am Samstag, 24. Oktober 2015, 11:06:37 schrieb Yakir Yang: > Add dt binding documentation for rockchip display port PHY. > > Tested-by: Javier Martinez Canillas > Signed-off-by: Yakir Yang > --- phy binding looks nice and easy Reviewed-by: Heiko Stuebner
[PATCH v7 10/17] phy: Add driver for rockchip Display Port PHY
Am Samstag, 24. Oktober 2015, 11:06:04 schrieb Yakir Yang: > Add phy driver for the Rockchip DisplayPort PHY module. This > is required to get DisplayPort working in Rockchip SoCs. > > Tested-by: Javier Martinez Canillas > Signed-off-by: Yakir Yang > --- > diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c > new file mode 100644 > index 000..4af19af > --- /dev/null > +++ b/drivers/phy/phy-rockchip-dp.c > @@ -0,0 +1,153 @@ > +/* > + * Rockchip DP PHY driver > + * > + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd. > + * Author: Yakir Yang > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define GRF_SOC_CON12 0x0274 > +#define GRF_EDP_REF_CLK_SEL_INTERBIT(4) > +#define GRF_EDP_PHY_SIDDQ_WRITE_EN BIT(21) > +#define GRF_EDP_PHY_SIDDQ_ON0 > +#define GRF_EDP_PHY_SIDDQ_OFF BIT(5) mixed spacers (tabs and spaces), please use either tabs if you want to align stuff or a single space. Also you're mixing the handling here, for SIDDQ you're defining both the actual bit as well as the write-enable bit, but for CLK_SEL_INTR you're hard-coding the 16-bit shift down in the code. You could also just use/copy the HIWORD_MASK macro we use for example in the clock controller. > + > +struct rockchip_dp_phy { > + struct device *dev; > + struct regmap *grf; > + struct clk *phy_24m; > +}; > + > +static int rockchip_set_phy_state(struct phy *phy, bool enable) > +{ > + struct rockchip_dp_phy *dp = phy_get_drvdata(phy); > + int ret; > + > + if (enable) { > + ret = regmap_write(dp->grf, GRF_SOC_CON12, > +GRF_EDP_PHY_SIDDQ_WRITE_EN | > +GRF_EDP_PHY_SIDDQ_ON); > + if (ret < 0) { > + dev_err(dp->dev, "Can't enable PHY power %d\n", ret); > + return ret; > + } > + > + ret = clk_prepare_enable(dp->phy_24m); > + unnecessary empty line after clk_prepare_enable with these things fixed, Reviewed-by: Heiko Stuebner Cheers, Heiko
[PATCH v7 09/17] Documentation: drm/bridge: add document for analogix_dp
Patch subject should probably be something like: dt-bindings: add document for rockchip variant of analogix_dp or similar, but definitly should mention that it's the Rockchip variant. Am Samstag, 24. Oktober 2015, 11:06:03 schrieb Yakir Yang: > Rockchip DP driver is a helper driver of analogix_dp coder driver, > so most of the DT property should be descriped in analogix_dp document. > > Tested-by: Javier Martinez Canillas > Signed-off-by: Yakir Yang everything else looks nice, so with a better subject Reviewed-by: Heiko Stuebner
[PATCH v7 06/17] Documentation: drm/bridge: add document for analogix_dp
Hi Yakir, Am Samstag, 24. Oktober 2015, 11:06:00 schrieb Yakir Yang: > Analogix dp driver is split from exynos dp driver, so we just > make an copy of exynos_dp.txt, and then simplify exynos_dp.txt > > Beside update some exynos dtsi file with the latest change > according to the devicetree binding documents. > > Tested-by: Javier Martinez Canillas > Signed-off-by: Yakir Yang > --- > diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt > b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt > index 7a3a9cd..9e47357 100644 > --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt > +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt > @@ -31,45 +31,31 @@ Required properties for dp-controller: > from general PHY binding: the phandle for the PHY device. > -phy-names: > from general PHY binding: Should be "dp". > - -samsung,color-space: > - input video data format. > - COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2 > - -samsung,dynamic-range: > - dynamic range for input video data. > - VESA = 0, CEA = 1 > - -samsung,ycbcr-coeff: > - YCbCr co-efficients for input video. > - COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1 > - -samsung,color-depth: > - number of bits per colour component. > - COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3 > - -samsung,link-rate: > - link rate supported by the panel. > - LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A > - -samsung,lane-count: > - number of lanes supported by the panel. > - LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4 > + > +Optional properties for dp-controller: > - display-timings: timings for the connected panel as described by > Documentation/devicetree/bindings/video/display-timing.txt ^^ bindings/display/display-timing.txt ... that actually made the patch not apply cleanly [...] > -[1]: Documentation/devicetree/bindings/media/video-interfaces.txt > +Deprecated properties for DisplayPort: > +-interlaced:deprecated prop that can parsed frm drm_display_mode. > +-vsync-active-high: deprecated prop that can parsed frm drm_display_mode. > +-hsync-active-high: deprecated prop that can parsed frm drm_display_mode. > +-samsung,ycbcr-coeff: deprecated prop that can parsed frm drm_display_mode. > +-samsung,dynamic-range: deprecated prop that can parsed frm drm_display_mode. the "frm" above need some more "o"s to be "from"s :-) > +-samsung,color-space: deprecated prop that can parsed from > drm_display_info. > +-samsung,color-depth: deprecated prop that can parsed from > drm_display_info. > +-samsung,link-rate: deprecated prop that can reading from monitor by > dpcd method. > +-samsung,lane-count:deprecated prop that can reading from monitor by > dpcd method. > +-samsung,hpd-gpio: deprecated name for hpd-gpios. > + > +--- Cheers, Heiko
No backlight since linux-4.2.4 - drivers/gpu/drm/radeon/atombios_encoders.c
On 27.10.2015 17:44, Michael Burian wrote: > On 10/27/15 03:36, Michel Dänzer wrote: >>> >>> [0] contains dmesg output with your patch applied (which fixes the >>> backlight issue) >> >> This is very surprising: The patch just adds some debugging output, it's >> not supposed to have any functional effect. Also, I don't see any of the >> debugging output added by the patch in >> dmesg-4.3.0-rc7-3-g85051e2-dirty-2015-10-26-11-00-41-radeon-bl-debug. >> > >> Are you sure that my patch was actually applied to the radeon driver >> when generating that file? Did you update the initrd with the patched >> radeon.ko? >> > > the build was done using "make -j4 deb-pkg" on a better equipped machine, > .deb packages were copied over and installed - maybe something interesting > happened > > AFAICT the patch should have been applied, at least it was shown with > git diff and the -dirty suffix was added by the build system, not me. > All graphics related drivers are compiled in (=y) rather than as > modules (=m) in .config. > > Another thing I tried yesterday was to add the old way right below the new one > (this fixes the backlight issue) enclosed by some debug statements that > indicate > start / stop of the old / new method. (see atomdebug.diff - should be applied > against > mainline) I'm not familiar with the ATOM bytecode, but since the number of bytecode instructions executed seems the same in both cases, I suspect that dig->backlight_level == 0 => ATOM_LCD_BLOFF is executed. (The debugging output in my patch would have provided all of this information and more, but there wasn't any of it in the dmesg you provided) I guess the question then becomes how dig->backlight_level is (supposed to be) initialized. What values do the following files contain in the broken and working cases? /sys/class/backlight/radeon_bl0/bl_power /sys/class/backlight/radeon_bl0/brightness /sys/class/backlight/radeon_bl0/actual_brightness /sys/class/backlight/radeon_bl0/max_brightness -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
No backlight since linux-4.2.4 - drivers/gpu/drm/radeon/atombios_encoders.c
On 10/27/15 17:43, Alex Deucher wrote: > > I see the problem. We don't enable native backlight control on older > asics like yours by default. Does the attached patch help? > Yes, backlight is on again. (tested against mainline: 858e904bd71dd0057a548d6785d94ce5ec4aeabd) thanks
No backlight since linux-4.2.4 - drivers/gpu/drm/radeon/atombios_encoders.c
On 10/27/15 16:10, Alex Deucher wrote: > > It would appear that your system does not use the gpu backlight > controller. Either it's lying or messing with the GPU backlight > controller causes some bad interaction with whatever does control it. > Does the attached radeon patch help? I'm also attaching an amdgpu > patch for reference in case the same problem appears on amdgpu. > no, still no backlight when applied against current current mainline 858e904bd71dd0057a548d6785d94ce5ec4aeabd (Merge tag 'iommu-fixes-v4.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu)
[Bug 91917] linux-firmware.git should carry most recent firmware for SI, CI et al.
https://bugs.freedesktop.org/show_bug.cgi?id=91917 Kai changed: What|Removed |Added CC||deathsimple at vodafone.de --- Comment #1 from Kai --- Ping. There has been a further round of firmware updates on 2015-10-16. -- 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/20151027/572dc1b2/attachment.html>
[PATCH 2/2] drm/amdgpu: switch to common fence_wait_any_timeout v2
From: Christian König No need to duplicate the functionality any more. v2: fix handling if no fence is available. Signed-off-by: Christian König Reviewed-by: Alex Deucher (v1) --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4 -- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 98 --- drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c| 20 --- 3 files changed, 13 insertions(+), 109 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h index a9c0def..dd7d2ce 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h @@ -447,10 +447,6 @@ int amdgpu_fence_wait_next(struct amdgpu_ring *ring); int amdgpu_fence_wait_empty(struct amdgpu_ring *ring); unsigned amdgpu_fence_count_emitted(struct amdgpu_ring *ring); -signed long amdgpu_fence_wait_any(struct fence **array, - uint32_t count, - bool intr, - signed long t); struct amdgpu_fence *amdgpu_fence_ref(struct amdgpu_fence *fence); void amdgpu_fence_unref(struct amdgpu_fence **fence); diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c index 663caa9..c4bb282 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c @@ -822,104 +822,6 @@ static const char *amdgpu_fence_get_timeline_name(struct fence *f) return (const char *)fence->ring->name; } -static bool amdgpu_test_signaled_any(struct fence **fences, uint32_t count) -{ - int idx; - struct fence *fence; - - for (idx = 0; idx < count; ++idx) { - fence = fences[idx]; - if (fence) { - if (test_bit(FENCE_FLAG_SIGNALED_BIT, &fence->flags)) - return true; - } - } - return false; -} - -struct amdgpu_wait_cb { - struct fence_cb base; - struct task_struct *task; -}; - -static void amdgpu_fence_wait_cb(struct fence *fence, struct fence_cb *cb) -{ - struct amdgpu_wait_cb *wait = - container_of(cb, struct amdgpu_wait_cb, base); - wake_up_process(wait->task); -} - -/** - * Wait the fence array with timeout - * - * @array:the fence array with amdgpu fence pointer - * @count:the number of the fence array - * @intr: when sleep, set the current task interruptable or not - * @t:timeout to wait - * - * It will return when any fence is signaled or timeout. - */ -signed long amdgpu_fence_wait_any(struct fence **array, uint32_t count, - bool intr, signed long t) -{ - struct amdgpu_wait_cb *cb; - struct fence *fence; - unsigned idx; - - BUG_ON(!array); - - cb = kcalloc(count, sizeof(struct amdgpu_wait_cb), GFP_KERNEL); - if (cb == NULL) { - t = -ENOMEM; - goto err_free_cb; - } - - for (idx = 0; idx < count; ++idx) { - fence = array[idx]; - if (fence) { - cb[idx].task = current; - if (fence_add_callback(fence, - &cb[idx].base, amdgpu_fence_wait_cb)) { - /* The fence is already signaled */ - goto fence_rm_cb; - } - } - } - - while (t > 0) { - if (intr) - set_current_state(TASK_INTERRUPTIBLE); - else - set_current_state(TASK_UNINTERRUPTIBLE); - - /* -* amdgpu_test_signaled_any must be called after -* set_current_state to prevent a race with wake_up_process -*/ - if (amdgpu_test_signaled_any(array, count)) - break; - - t = schedule_timeout(t); - - if (t > 0 && intr && signal_pending(current)) - t = -ERESTARTSYS; - } - - __set_current_state(TASK_RUNNING); - -fence_rm_cb: - for (idx = 0; idx < count; ++idx) { - fence = array[idx]; - if (fence && cb[idx].base.func) - fence_remove_callback(fence, &cb[idx].base); - } - -err_free_cb: - kfree(cb); - - return t; -} - const struct fence_ops amdgpu_fence_ops = { .get_driver_name = amdgpu_fence_get_driver_name, .get_timeline_name = amdgpu_fence_get_timeline_name, diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c index 5cb27d5..3f48759 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c @@ -337,6 +337,7 @@ int amdgpu_sa_bo_new(struct amdgpu_device *adev, { struct fence *fences[AMDGPU_MAX_RINGS]; unsigned tries[AMDGPU_MAX_RINGS]; + unsigned count; int i, r;
[PATCH 1/2] dma-buf/fence: add fence_wait_any_timeout function v2
From: Christian König Waiting for the first fence in an array of fences to signal. This is useful for device driver specific resource managers and also Vulkan needs something similar. v2: more parameter checks, handling for timeout==0, remove NULL entry support, better callback removal. Signed-off-by: Christian König Reviewed-by: Alex Deucher --- drivers/dma-buf/fence.c | 98 + include/linux/fence.h | 3 +- 2 files changed, 100 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c index 50ef8bd..7b05dbe 100644 --- a/drivers/dma-buf/fence.c +++ b/drivers/dma-buf/fence.c @@ -397,6 +397,104 @@ out: } EXPORT_SYMBOL(fence_default_wait); +static bool +fence_test_signaled_any(struct fence **fences, uint32_t count) +{ + int i; + + for (i = 0; i < count; ++i) { + struct fence *fence = fences[i]; + if (test_bit(FENCE_FLAG_SIGNALED_BIT, &fence->flags)) + return true; + } + return false; +} + +/** + * fence_wait_any_timeout - sleep until any fence gets signaled + * or until timeout elapses + * @fences:[in]array of fences to wait on + * @count: [in]number of fences to wait on + * @intr: [in]if true, do an interruptible wait + * @timeout: [in]timeout value in jiffies, or MAX_SCHEDULE_TIMEOUT + * + * Returns -EINVAL on custom fence wait implementation, -ERESTARTSYS if + * interrupted, 0 if the wait timed out, or the remaining timeout in jiffies + * on success. + * + * Synchronous waits for the first fence in the array to be signaled. The + * caller needs to hold a reference to all fences in the array, otherwise a + * fence might be freed before return, resulting in undefined behavior. + */ +signed long +fence_wait_any_timeout(struct fence **fences, uint32_t count, + bool intr, signed long timeout) +{ + struct default_wait_cb *cb; + signed long ret = timeout; + unsigned i; + + if (WARN_ON(!fences || !count || timeout < 0)) + return -EINVAL; + + if (timeout == 0) { + for (i = 0; i < count; ++i) + if (fence_is_signaled(fences[i])) + return 1; + + return 0; + } + + cb = kcalloc(count, sizeof(struct default_wait_cb), GFP_KERNEL); + if (cb == NULL) { + ret = -ENOMEM; + goto err_free_cb; + } + + for (i = 0; i < count; ++i) { + struct fence *fence = fences[i]; + + if (fence->ops->wait != fence_default_wait) { + ret = -EINVAL; + goto fence_rm_cb; + } + + cb[i].task = current; + if (fence_add_callback(fence, &cb[i].base, + fence_default_wait_cb)) { + /* This fence is already signaled */ + goto fence_rm_cb; + } + } + + while (ret > 0) { + if (intr) + set_current_state(TASK_INTERRUPTIBLE); + else + set_current_state(TASK_UNINTERRUPTIBLE); + + if (fence_test_signaled_any(fences, count)) + break; + + ret = schedule_timeout(ret); + + if (ret > 0 && intr && signal_pending(current)) + ret = -ERESTARTSYS; + } + + __set_current_state(TASK_RUNNING); + +fence_rm_cb: + while (i-- > 0) + fence_remove_callback(fences[i], &cb[i].base); + +err_free_cb: + kfree(cb); + + return ret; +} +EXPORT_SYMBOL(fence_wait_any_timeout); + /** * fence_init - Initialize a custom fence. * @fence: [in]the fence to initialize diff --git a/include/linux/fence.h b/include/linux/fence.h index ddc0f26..bb52201 100644 --- a/include/linux/fence.h +++ b/include/linux/fence.h @@ -321,7 +321,8 @@ static inline struct fence *fence_later(struct fence *f1, struct fence *f2) } signed long fence_wait_timeout(struct fence *, bool intr, signed long timeout); - +signed long fence_wait_any_timeout(struct fence **fences, uint32_t count, + bool intr, signed long timeout); /** * fence_wait - sleep until the fence gets signaled -- 1.9.1
Missing amdgpu firmware files
Well that's strange. Essentially those are just duplicates to the existing files and the driver should fallback to them. IIRC the radeon/*_sdma1.bin files are only requested when you try to use CIK support with amdgpu which isn't a good idea in a production environment. What's the link for the bug reports? It's most likely just people trying to use the driver with hardware which it isn't supposed to be used with. We probably should either remove CIK support totally from the amdgpu or add all the files to the firmware repository. Regards, Christian. On 27.10.2015 16:42, Seth Forshee wrote: > I've received reports from Ubuntu users about missing amdgpu firmware > files with 4.2 kernels. The driver calls out a number of > radeon/*_sdma1.bin files that are not present in the linux-firmware git > repo. Are these files available anywhere (under a license that allows > redistribution), and will they be pushed up to linux-firmware anytime > soon? > > Thanks, > Seth >
Missing amdgpu firmware files
> -Original Message- > From: Seth Forshee [mailto:seth.forshee at canonical.com] > Sent: Tuesday, October 27, 2015 12:06 PM > To: Koenig, Christian > Cc: Deucher, Alexander; Oded Gabbay; dri-devel at lists.freedesktop.org > Subject: Re: Missing amdgpu firmware files > > On Tue, Oct 27, 2015 at 04:47:53PM +0100, Christian König wrote: > > Well that's strange. Essentially those are just duplicates to the > > existing files and the driver should fallback to them. > > > > IIRC the radeon/*_sdma1.bin files are only requested when you try to > > use CIK support with amdgpu which isn't a good idea in a production > > environment. > > > > What's the link for the bug reports? It's most likely just people > > trying to use the driver with hardware which it isn't supposed to be > > used with. > > There have been a few reports that the firmware is missing, but only one > I see where the user actually reports any display problems. > > http://bugs.launchpad.net/bugs/1510405 > > Of course it's possible that he is jumping to conclusions about the > missing firmware files causing his display issues. The driver refuses to load if the firmware is missing. However, as Christian mentioned, you will only get those messages if you've enabled CIK support amdgpu which we don't recommend (controlled by CONFIG_DRM_AMDGPU_CIK). Radeon does not require the additional firmware. Alex
[Bug 106291] amdgpu fails GPU reset when resuming from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=106291 --- Comment #8 from universaledge97 at gmail.com --- It turned out that the amdgpu kernel module was not included in compilation. I normally use the linux-mainline package from the AUR (I run Arch Linux) to install rc kernels, where, for some reason, the amdgpu module was not enabled to compile by default. I now have amdgpu built into 4.3rc7, and will report back if the issue is still present. -- You are receiving this mail because: You are watching the assignee of the bug.
Missing amdgpu firmware files
> -Original Message- > From: Koenig, Christian > Sent: Tuesday, October 27, 2015 11:48 AM > To: Seth Forshee; Deucher, Alexander; Oded Gabbay > Cc: dri-devel at lists.freedesktop.org > Subject: Re: Missing amdgpu firmware files > > Well that's strange. Essentially those are just duplicates to the > existing files and the driver should fallback to them. > > IIRC the radeon/*_sdma1.bin files are only requested when you try to use > CIK support with amdgpu which isn't a good idea in a production > environment. > > What's the link for the bug reports? It's most likely just people trying > to use the driver with hardware which it isn't supposed to be used with. > > We probably should either remove CIK support totally from the amdgpu or > add all the files to the firmware repository. Exactly. They are only used if you forcibly enable CIK support in amdgpu which is just for testing. CIK is already supported in radeon and that should be used for CIK parts. Sdma1 is identical to regular sdma file so you can just symlink them or copy them. I guess I can update the firmware tree. Alex > > Regards, > Christian. > > On 27.10.2015 16:42, Seth Forshee wrote: > > I've received reports from Ubuntu users about missing amdgpu firmware > > files with 4.2 kernels. The driver calls out a number of > > radeon/*_sdma1.bin files that are not present in the linux-firmware git > > repo. Are these files available anywhere (under a license that allows > > redistribution), and will they be pushed up to linux-firmware anytime > > soon? > > > > Thanks, > > Seth > >
[Bug 106271] Switch between AMD hybrid graphics (HD 8650G / HD 8970M) makes hardware reset.
https://bugzilla.kernel.org/show_bug.cgi?id=106271 --- Comment #6 from Alex Deucher --- (In reply to Aneroid from comment #5) > Yes, I try to do that. > > xrandr --listproviders > Providers: number : 2 > Provider 0: id: 0x7e cap: 0xf, Source Output, Sink Output, Source Offload, > Sink Offload crtcs: 4 outputs: 4 associated providers: 0 name:radeon > Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, > Sink Offload crtcs: 6 outputs: 1 associated providers: 0 name:radeon > > xrandr --setprovideroffloadsink 0x7e 0x46 You've got the arguments reversed; the first is the offload device, the second is the display device. Try: xrandr --setprovideroffloadsink 0x46 0x7e > > And it ruined my xorg completely. X fall out in to the shell without any > errors. Can you attach your dmesg output and xorg log when you do that? Does adding amdgpu.runpm=0 to the kernel command line in grub help? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v11 2/4] PM / Domains: add setter for dev.pm_domain
Adds a function that sets the pointer to dev_pm_domain in struct device and that warns if the device has already finished probing. The reason why we want to enforce that is because in the general case that can cause problems and also that we can simplify code quite a bit if we can always assume that. This patch also changes all current code that directly sets the dev.pm_domain pointer. Signed-off-by: Tomeu Vizoso Reviewed-by: Ulf Hansson --- Changes in v11: - Move calls to dev_pm_domain_set() out from &dev->power.lock as that isn't needed for dev->pm_domain. Changes in v9: - Add docs noting the need for the device lock to be held before calling dev_pm_domain_set() Changes in v8: - Add dev_pm_domain_set() and update code to use it arch/arm/mach-omap2/omap_device.c | 7 --- drivers/acpi/acpi_lpss.c | 5 +++-- drivers/acpi/device_pm.c | 5 +++-- drivers/base/power/clock_ops.c| 5 +++-- drivers/base/power/common.c | 21 + drivers/base/power/domain.c | 6 -- drivers/gpu/vga/vga_switcheroo.c | 10 +- drivers/misc/mei/pci-me.c | 5 +++-- drivers/misc/mei/pci-txe.c| 5 +++-- include/linux/pm_domain.h | 3 +++ 10 files changed, 52 insertions(+), 20 deletions(-) diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c index 4cb8fd9f741f..204101d11632 100644 --- a/arch/arm/mach-omap2/omap_device.c +++ b/arch/arm/mach-omap2/omap_device.c @@ -32,6 +32,7 @@ #include #include #include +#include #include #include #include @@ -168,7 +169,7 @@ static int omap_device_build_from_dt(struct platform_device *pdev) r->name = dev_name(&pdev->dev); } - pdev->dev.pm_domain = &omap_device_pm_domain; + dev_pm_domain_set(&pdev->dev, &omap_device_pm_domain); if (device_active) { omap_device_enable(pdev); @@ -180,7 +181,7 @@ odbfd_exit1: odbfd_exit: /* if data/we are at fault.. load up a fail handler */ if (ret) - pdev->dev.pm_domain = &omap_device_fail_pm_domain; + dev_pm_domain_set(&pdev->dev, &omap_device_fail_pm_domain); return ret; } @@ -701,7 +702,7 @@ int omap_device_register(struct platform_device *pdev) { pr_debug("omap_device: %s: registering\n", pdev->name); - pdev->dev.pm_domain = &omap_device_pm_domain; + dev_pm_domain_set(&pdev->dev, &omap_device_pm_domain); return platform_device_add(pdev); } diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c index f51bd0d0bc17..cc6e1abc69b3 100644 --- a/drivers/acpi/acpi_lpss.c +++ b/drivers/acpi/acpi_lpss.c @@ -17,6 +17,7 @@ #include #include #include +#include #include #include @@ -706,7 +707,7 @@ static int acpi_lpss_platform_notify(struct notifier_block *nb, switch (action) { case BUS_NOTIFY_ADD_DEVICE: - pdev->dev.pm_domain = &acpi_lpss_pm_domain; + dev_pm_domain_set(&pdev->dev, &acpi_lpss_pm_domain); if (pdata->dev_desc->flags & LPSS_LTR) return sysfs_create_group(&pdev->dev.kobj, &lpss_attr_group); @@ -714,7 +715,7 @@ static int acpi_lpss_platform_notify(struct notifier_block *nb, case BUS_NOTIFY_DEL_DEVICE: if (pdata->dev_desc->flags & LPSS_LTR) sysfs_remove_group(&pdev->dev.kobj, &lpss_attr_group); - pdev->dev.pm_domain = NULL; + dev_pm_domain_set(&pdev->dev, NULL); break; default: break; diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c index 4806b7f856c4..8c5955bf9bbf 100644 --- a/drivers/acpi/device_pm.c +++ b/drivers/acpi/device_pm.c @@ -22,6 +22,7 @@ #include #include #include +#include #include #include "internal.h" @@ -1076,7 +1077,7 @@ static void acpi_dev_pm_detach(struct device *dev, bool power_off) struct acpi_device *adev = ACPI_COMPANION(dev); if (adev && dev->pm_domain == &acpi_general_pm_domain) { - dev->pm_domain = NULL; + dev_pm_domain_set(dev, NULL); acpi_remove_pm_notifier(adev); if (power_off) { /* @@ -1128,7 +1129,7 @@ int acpi_dev_pm_attach(struct device *dev, bool power_on) return -EBUSY; acpi_add_pm_notifier(adev, dev, acpi_pm_notify_work_func); - dev->pm_domain = &acpi_general_pm_domain; + dev_pm_domain_set(dev, &acpi_general_pm_domain); if (power_on) { acpi_dev_pm_full_power(adev); acpi_device_wakeup(adev, ACPI_STATE_S0, false); diff --git a/drivers/base/power/clock_ops.c b/drivers/base/power/clock_ops.c index 652b5a367c1f..e80fda6c03a9 100644 --- a/drivers/base/power/clock_ops.c +++ b/drivers/base/power/clock_ops.c @@ -15,6 +15,7 @@ #include #include #include +#in
[PATCH v11 0/4] Allow USB devices to remain runtime-suspended when sleeping
Hi, this is v11 of an attempt to make it easier for devices to remain in runtime PM when the system goes to sleep, mainly to reduce the time spent resuming devices. For this, we interpret the absence of all PM callback implementations as it being safe to do direct_complete, so their ancestors aren't prevented from remaining runtime-suspended. Additionally, the prepare() callback of USB devices will return 1 if runtime PM is enabled and the current wakeup settings are correct. With these changes, a uvcvideo device (for example) stays in runtime suspend when the system goes to sleep and is left in that state when the system resumes, not delaying it unnecessarily. Thanks, Tomeu Changes in v11: - Move calls to dev_pm_domain_set() out from &dev->power.lock as that isn't needed for dev->pm_domain. Changes in v10: - Remove superfluous call to pm_runtime_enabled() as suggested by Alan Changes in v9: - Add docs noting the need for the device lock to be held before calling device_is_bound() - Add docs noting the need for the device lock to be held before calling dev_pm_domain_set() - Move to CONFIG_PM_SLEEP as suggested by Rafael and Ulf. - Rename from device_check_pm_callbacks to device_pm_check_callbacks to follow with the naming convention of existing API. - Re-add calling to device_pm_check_callbacks from device registration and when updating the PM domain of a device. Changes in v8: - Add device_is_bound() - Add dev_pm_domain_set() and update code to use it - Move no_pm_callbacks field into CONFIG_PM_SLEEP - Call device_check_pm_callbacks only after a device is bound or unbound Changes in v7: - Reduce indentation by adding a label in device_prepare() Changes in v6: - Add stub for !CONFIG_PM. - Move implementation of device_check_pm_callbacks to power/main.c as it doesn't belong to CONFIG_PM_SLEEP. - Take dev->power.lock before modifying flag. Changes in v5: - Check for all dev_pm_ops instances associated to a device, updating a no_pm_callbacks flag at the times when that could change. Tomeu Vizoso (4): device core: add device_is_bound() PM / Domains: add setter for dev.pm_domain PM / sleep: Go direct_complete if driver has no callbacks USB / PM: Allow USB devices to remain runtime-suspended when sleeping arch/arm/mach-omap2/omap_device.c | 7 --- drivers/acpi/acpi_lpss.c | 5 +++-- drivers/acpi/device_pm.c | 5 +++-- drivers/base/dd.c | 21 +++-- drivers/base/power/clock_ops.c| 5 +++-- drivers/base/power/common.c | 24 drivers/base/power/domain.c | 8 ++-- drivers/base/power/main.c | 35 +++ drivers/base/power/power.h| 3 +++ drivers/gpu/vga/vga_switcheroo.c | 10 +- drivers/misc/mei/pci-me.c | 5 +++-- drivers/misc/mei/pci-txe.c| 5 +++-- drivers/usb/core/port.c | 6 ++ drivers/usb/core/usb.c| 8 +++- include/linux/device.h| 2 ++ include/linux/pm.h| 1 + include/linux/pm_domain.h | 3 +++ 17 files changed, 130 insertions(+), 23 deletions(-) -- 2.5.0
[Bug 106271] Switch between AMD hybrid graphics (HD 8650G / HD 8970M) makes hardware reset.
https://bugzilla.kernel.org/show_bug.cgi?id=106271 --- Comment #5 from Aneroid --- Yes, I try to do that. xrandr --listproviders Providers: number : 2 Provider 0: id: 0x7e cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 4 associated providers: 0 name:radeon Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 6 outputs: 1 associated providers: 0 name:radeon xrandr --setprovideroffloadsink 0x7e 0x46 And it ruined my xorg completely. X fall out in to the shell without any errors. I could switch between graphics card on flgrx driver with "aticonfig --px-dgpu" and "aticonfig --px-igpu". It worked well. But now, it seems that I stuck in low power graphics mode and I can't switch to my power card. ' glxinfo always show me AMD ARUBA chip: glxinfo | grep "OpenGL renderer" OpenGL renderer string: Gallium 0.4 on AMD ARUBA (DRM 2.43.0, LLVM 3.7.0) DRI_PRIME=1 glxinfo | grep "OpenGL renderer" OpenGL renderer string: Gallium 0.4 on AMD ARUBA (DRM 2.43.0, LLVM 3.7.0) DRI_PRIME=0 glxinfo | grep "OpenGL renderer" OpenGL renderer string: Gallium 0.4 on AMD ARUBA (DRM 2.43.0, LLVM 3.7.0) -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v3 3/3] drm/tegra: Remove local fbdev emulation Kconfig option
DRM_TEGRA_FBDEV config is currently used to enable/disable legacy fbdev emulation for the tegra kms driver. Remove this local config option and use the top level DRM_FBDEV_EMULATION config option instead. Signed-off-by: Archit Taneja --- drivers/gpu/drm/tegra/Kconfig | 12 drivers/gpu/drm/tegra/drm.c | 4 ++-- drivers/gpu/drm/tegra/drm.h | 6 +++--- drivers/gpu/drm/tegra/fb.c| 12 ++-- 4 files changed, 11 insertions(+), 23 deletions(-) diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig index 74d9d62..63ebb15 100644 --- a/drivers/gpu/drm/tegra/Kconfig +++ b/drivers/gpu/drm/tegra/Kconfig @@ -16,18 +16,6 @@ config DRM_TEGRA if DRM_TEGRA -config DRM_TEGRA_FBDEV - bool "Enable legacy fbdev support" - select DRM_KMS_FB_HELPER - select FB_SYS_FILLRECT - select FB_SYS_COPYAREA - select FB_SYS_IMAGEBLIT - default y - help - Choose this option if you have a need for the legacy fbdev support. - Note that this support also provides the Linux console on top of - the Tegra modesetting driver. - config DRM_TEGRA_DEBUG bool "NVIDIA Tegra DRM debug support" help diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c index 159ef51..e0f8277 100644 --- a/drivers/gpu/drm/tegra/drm.c +++ b/drivers/gpu/drm/tegra/drm.c @@ -106,7 +106,7 @@ static int tegra_atomic_commit(struct drm_device *drm, static const struct drm_mode_config_funcs tegra_drm_mode_funcs = { .fb_create = tegra_fb_create, -#ifdef CONFIG_DRM_TEGRA_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION .output_poll_changed = tegra_fb_output_poll_changed, #endif .atomic_check = drm_atomic_helper_check, @@ -260,7 +260,7 @@ static void tegra_drm_context_free(struct tegra_drm_context *context) static void tegra_drm_lastclose(struct drm_device *drm) { -#ifdef CONFIG_DRM_TEGRA_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION struct tegra_drm *tegra = drm->dev_private; tegra_fbdev_restore_mode(tegra->fbdev); diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h index ec49275..942cad9 100644 --- a/drivers/gpu/drm/tegra/drm.h +++ b/drivers/gpu/drm/tegra/drm.h @@ -30,7 +30,7 @@ struct tegra_fb { unsigned int num_planes; }; -#ifdef CONFIG_DRM_TEGRA_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION struct tegra_fbdev { struct drm_fb_helper base; struct tegra_fb *fb; @@ -46,7 +46,7 @@ struct tegra_drm { struct mutex clients_lock; struct list_head clients; -#ifdef CONFIG_DRM_TEGRA_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION struct tegra_fbdev *fbdev; #endif @@ -273,7 +273,7 @@ int tegra_drm_fb_prepare(struct drm_device *drm); void tegra_drm_fb_free(struct drm_device *drm); int tegra_drm_fb_init(struct drm_device *drm); void tegra_drm_fb_exit(struct drm_device *drm); -#ifdef CONFIG_DRM_TEGRA_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION void tegra_fbdev_restore_mode(struct tegra_fbdev *fbdev); void tegra_fb_output_poll_changed(struct drm_device *drm); #endif diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c index 07c844b..9b8aa96 100644 --- a/drivers/gpu/drm/tegra/fb.c +++ b/drivers/gpu/drm/tegra/fb.c @@ -18,7 +18,7 @@ static inline struct tegra_fb *to_tegra_fb(struct drm_framebuffer *fb) return container_of(fb, struct tegra_fb, base); } -#ifdef CONFIG_DRM_TEGRA_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION static inline struct tegra_fbdev *to_tegra_fbdev(struct drm_fb_helper *helper) { return container_of(helper, struct tegra_fbdev, base); @@ -181,7 +181,7 @@ unreference: return ERR_PTR(err); } -#ifdef CONFIG_DRM_TEGRA_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION static struct fb_ops tegra_fb_ops = { .owner = THIS_MODULE, .fb_fillrect = drm_fb_helper_sys_fillrect, @@ -371,7 +371,7 @@ void tegra_fb_output_poll_changed(struct drm_device *drm) int tegra_drm_fb_prepare(struct drm_device *drm) { -#ifdef CONFIG_DRM_TEGRA_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION struct tegra_drm *tegra = drm->dev_private; tegra->fbdev = tegra_fbdev_create(drm); @@ -384,7 +384,7 @@ int tegra_drm_fb_prepare(struct drm_device *drm) void tegra_drm_fb_free(struct drm_device *drm) { -#ifdef CONFIG_DRM_TEGRA_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION struct tegra_drm *tegra = drm->dev_private; tegra_fbdev_free(tegra->fbdev); @@ -393,7 +393,7 @@ void tegra_drm_fb_free(struct drm_device *drm) int tegra_drm_fb_init(struct drm_device *drm) { -#ifdef CONFIG_DRM_TEGRA_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION struct tegra_drm *tegra = drm->dev_private; int err; @@ -408,7 +408,7 @@ int tegra_drm_fb_init(struct drm_device *drm) void tegra_drm_fb_exit(struct drm_device *drm) { -#ifdef CONFIG_DRM_TEGRA_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION struct tegra_drm *tegra = drm->dev_private; tegra_fbdev_exit(tegra->fbdev); -- The Qualcomm Innovation
[PATCH v3 2/3] drm/sti: Remove local fbdev emulation Kconfig option
DRM_STI_FBDEV config is currently used to enable/disable fbdev emulation for the sti kms driver. Remove this local config option and use the top level DRM_FBDEV_EMULATION config option instead where applicable. We replace the #ifdef in sti_drm_load with CONFIG_DRM_FBDEV_EMULATION. It's probably okay to get remove the #ifdef itself, but just left it here for now to be safe. It can be removed after some testing. Signed-off-by: Archit Taneja --- drivers/gpu/drm/sti/Kconfig | 6 -- drivers/gpu/drm/sti/sti_drv.c | 2 +- 2 files changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig index fbccc10..e3aa5af 100644 --- a/drivers/gpu/drm/sti/Kconfig +++ b/drivers/gpu/drm/sti/Kconfig @@ -9,9 +9,3 @@ config DRM_STI select FW_LOADER_USER_HELPER_FALLBACK help Choose this option to enable DRM on STM stiH41x chipset - -config DRM_STI_FBDEV - bool "DRM frame buffer device for STMicroelectronics SoC stiH41x Serie" - depends on DRM_STI - help - Choose this option to enable FBDEV on top of DRM for STM stiH41x chipset diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c index f846996..1b2db6c 100644 --- a/drivers/gpu/drm/sti/sti_drv.c +++ b/drivers/gpu/drm/sti/sti_drv.c @@ -160,7 +160,7 @@ static int sti_load(struct drm_device *dev, unsigned long flags) drm_mode_config_reset(dev); -#ifdef CONFIG_DRM_STI_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION drm_fbdev_cma_init(dev, 32, dev->mode_config.num_crtc, dev->mode_config.num_connector); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH v3 1/3] drm/imx: Remove local fbdev emulation Kconfig option
DRM_IMX_FB_HELPER config is currently used to enable/disable fbdev emulation for the imx kms driver. Remove this local config option and use the top level DRM_FBDEV_EMULATION config option where applicable. Using this config lets us also prevent wrapping around drm_fb_helper_* calls with #ifdefs in certain places. Tested-by: Philipp Zabel Signed-off-by: Archit Taneja --- drivers/gpu/drm/imx/Kconfig| 9 - drivers/gpu/drm/imx/imx-drm-core.c | 12 +++- 2 files changed, 3 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig index 2b81a41..35ca4f0 100644 --- a/drivers/gpu/drm/imx/Kconfig +++ b/drivers/gpu/drm/imx/Kconfig @@ -10,15 +10,6 @@ config DRM_IMX help enable i.MX graphics support -config DRM_IMX_FB_HELPER - tristate "provide legacy framebuffer /dev/fb0" - select DRM_KMS_CMA_HELPER - depends on DRM_IMX - help - The DRM framework can provide a legacy /dev/fb0 framebuffer - for your device. This is necessary to get a framebuffer console - and also for applications using the legacy framebuffer API - config DRM_IMX_PARALLEL_DISPLAY tristate "Support for parallel displays" select DRM_PANEL diff --git a/drivers/gpu/drm/imx/imx-drm-core.c b/drivers/gpu/drm/imx/imx-drm-core.c index de00a6c..cacf2dd 100644 --- a/drivers/gpu/drm/imx/imx-drm-core.c +++ b/drivers/gpu/drm/imx/imx-drm-core.c @@ -49,8 +49,10 @@ struct imx_drm_crtc { struct imx_drm_crtc_helper_funcsimx_drm_helper_funcs; }; +#if IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION) static int legacyfb_depth = 16; module_param(legacyfb_depth, int, 0444); +#endif int imx_drm_crtc_id(struct imx_drm_crtc *crtc) { @@ -60,26 +62,20 @@ EXPORT_SYMBOL_GPL(imx_drm_crtc_id); static void imx_drm_driver_lastclose(struct drm_device *drm) { -#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER) struct imx_drm_device *imxdrm = drm->dev_private; if (imxdrm->fbhelper) drm_fbdev_cma_restore_mode(imxdrm->fbhelper); -#endif } static int imx_drm_driver_unload(struct drm_device *drm) { -#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER) struct imx_drm_device *imxdrm = drm->dev_private; -#endif drm_kms_helper_poll_fini(drm); -#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER) if (imxdrm->fbhelper) drm_fbdev_cma_fini(imxdrm->fbhelper); -#endif component_unbind_all(drm->dev, drm); @@ -215,11 +211,9 @@ EXPORT_SYMBOL_GPL(imx_drm_encoder_destroy); static void imx_drm_output_poll_changed(struct drm_device *drm) { -#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER) struct imx_drm_device *imxdrm = drm->dev_private; drm_fbdev_cma_hotplug_event(imxdrm->fbhelper); -#endif } static struct drm_mode_config_funcs imx_drm_mode_config_funcs = { @@ -308,7 +302,7 @@ static int imx_drm_driver_load(struct drm_device *drm, unsigned long flags) * The fb helper takes copies of key hardware information, so the * crtcs/connectors/encoders must not change after this point. */ -#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER) +#if IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION) if (legacyfb_depth != 16 && legacyfb_depth != 32) { dev_warn(drm->dev, "Invalid legacyfb_depth. Defaulting to 16bpp\n"); legacyfb_depth = 16; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH v3 0/3] drm: fb emulation: Remove remaining driver level fb emulation configs
Instead of using a custom legacy fbdev emulation config option, use the top level DRM_FBDEV_EMULATION config option. There are 3 drivers which use custom config options: imx, sti and tegra. Since the last revision, i915 and msm drivers have removed their custom configs. Remove the remaining config options in order to have a single config option. Archit Taneja (3): drm/imx: Remove local fbdev emulation Kconfig option drm/sti: Remove local fbdev emulation Kconfig option drm/tegra: Remove local fbdev emulation Kconfig option drivers/gpu/drm/imx/Kconfig| 9 - drivers/gpu/drm/imx/imx-drm-core.c | 12 +++- drivers/gpu/drm/sti/Kconfig| 6 -- drivers/gpu/drm/sti/sti_drv.c | 2 +- drivers/gpu/drm/tegra/Kconfig | 12 drivers/gpu/drm/tegra/drm.c| 4 ++-- drivers/gpu/drm/tegra/drm.h| 6 +++--- drivers/gpu/drm/tegra/fb.c | 12 ++-- 8 files changed, 15 insertions(+), 48 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
No backlight since linux-4.2.4 - drivers/gpu/drm/radeon/atombios_encoders.c
On Tue, Oct 27, 2015 at 12:23 PM, Michael Burian wrote: > On 10/27/15 16:10, Alex Deucher wrote: > >> >> It would appear that your system does not use the gpu backlight >> controller. Either it's lying or messing with the GPU backlight >> controller causes some bad interaction with whatever does control it. >> Does the attached radeon patch help? I'm also attaching an amdgpu >> patch for reference in case the same problem appears on amdgpu. >> > > no, still no backlight when applied against current current mainline > > 858e904bd71dd0057a548d6785d94ce5ec4aeabd (Merge tag 'iommu-fixes-v4.3-rc7' of > git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu) > I see the problem. We don't enable native backlight control on older asics like yours by default. Does the attached patch help? Alex -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-radeon-fix-dpms-when-driver-backlight-control-is.patch Type: text/x-patch Size: 2351 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151027/7192775b/attachment-0001.bin>
[PATCH 46/48] staging: etnaviv: rewrite submit interface to use copy from user
Am Montag, den 26.10.2015, 20:48 + schrieb Russell King - ARM Linux: > On Fri, Sep 25, 2015 at 01:57:58PM +0200, Lucas Stach wrote: > > +void etnaviv_gpu_cmdbuf_free(struct etnaviv_cmdbuf *cmdbuf) > > +{ > > + dma_free_writecombine(cmdbuf->gpu->dev, cmdbuf->size, > > + cmdbuf->vaddr, cmdbuf->paddr); > > + kfree(cmdbuf); > > +} > ... > > @@ -885,6 +914,14 @@ static void retire_worker(struct work_struct *work) > > + list_for_each_entry_safe(cmdbuf, tmp, &gpu->active_cmd_list, > > +gpu_active_list) { > > + if (fence_after_eq(fence, cmdbuf->fence)) { > > + etnaviv_gpu_cmdbuf_free(cmdbuf); > > + list_del(&cmdbuf->gpu_active_list); > > I mentioned that I'd left one of my machines on a soak test - with vlc > running with a video clip, but in pause mode. vlc continues writing > frames to the etnaviv Xv GPU backend, thereby exercising these code > paths. After about 39 hours, the above provoked the oops below, which > is a use-after-free bug. Fix on its way to my git branch once builds > and reboots are complete. > Urgh, thanks for fixing that. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ |
No backlight since linux-4.2.4 - drivers/gpu/drm/radeon/atombios_encoders.c
Michael, please keep the Cc: list intact. On 26.10.2015 19:46, Michael Burian wrote: > On 10/26/15 10:32, Michel Dänzer wrote: >> On 25.10.2015 04:25, Michael Burian wrote: >>> >>> # first bad commit: [5a633828b4b2bef343826afcb0a70770c4911c55] drm/radeon: >>> Restore LCD backlight level on resume (>= R5xx) >>> >>> Workaround 2: >>> >>> reverting this single commit 5a633828b4b2bef343826afcb0a70770c4911c55 fixes >>> the problem in linux-stable[0] >>> as well as mainline[1] 4.3.0-rc6-00277-g01815536 >> >> Please provide the dmesg output from running with the attached debugging >> patch. >> > > [0] contains dmesg output with your patch applied (which fixes the backlight > issue) This is very surprising: The patch just adds some debugging output, it's not supposed to have any functional effect. Also, I don't see any of the debugging output added by the patch in dmesg-4.3.0-rc7-3-g85051e2-dirty-2015-10-26-11-00-41-radeon-bl-debug. Are you sure that my patch was actually applied to the radeon driver when generating that file? Did you update the initrd with the patched radeon.ko? > [1] contains dmesg output without your patch for comparison (resulting in a > permanent black screen as before in rc6) > > > [0] > dmesg-4.3.0-rc7-3-g85051e2-dirty-2015-10-26-11-00-41-radeon-bl-debug > > [1] > dmesg-4.3.0-rc7-3-g85051e2-2015-10-26-11-22-09 > > -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Missing amdgpu firmware files
On Tue, Oct 27, 2015 at 04:10:33PM +, Deucher, Alexander wrote: > > -Original Message- > > From: Seth Forshee [mailto:seth.forshee at canonical.com] > > Sent: Tuesday, October 27, 2015 12:06 PM > > To: Koenig, Christian > > Cc: Deucher, Alexander; Oded Gabbay; dri-devel at lists.freedesktop.org > > Subject: Re: Missing amdgpu firmware files > > > > On Tue, Oct 27, 2015 at 04:47:53PM +0100, Christian König wrote: > > > Well that's strange. Essentially those are just duplicates to the > > > existing files and the driver should fallback to them. > > > > > > IIRC the radeon/*_sdma1.bin files are only requested when you try to > > > use CIK support with amdgpu which isn't a good idea in a production > > > environment. > > > > > > What's the link for the bug reports? It's most likely just people > > > trying to use the driver with hardware which it isn't supposed to be > > > used with. > > > > There have been a few reports that the firmware is missing, but only one > > I see where the user actually reports any display problems. > > > > http://bugs.launchpad.net/bugs/1510405 > > > > Of course it's possible that he is jumping to conclusions about the > > missing firmware files causing his display issues. > > The driver refuses to load if the firmware is missing. However, as Christian > mentioned, you will only get those messages if you've enabled CIK support > amdgpu which we don't recommend (controlled by CONFIG_DRM_AMDGPU_CIK). > Radeon does not require the additional firmware. Got it, thanks. I'll disable it. Seth
No backlight since linux-4.2.4 - drivers/gpu/drm/radeon/atombios_encoders.c
On Tue, Oct 27, 2015 at 6:06 AM, Michael Burian wrote: > On 10/27/15 10:17, Michel Dänzer wrote: >> >> I'm not familiar with the ATOM bytecode, but since the number of >> bytecode instructions executed seems the same in both cases, I suspect >> that dig->backlight_level == 0 => ATOM_LCD_BLOFF is executed. (The >> debugging output in my patch would have provided all of this information >> and more, but there wasn't any of it in the dmesg you provided) >> >> I guess the question then becomes how dig->backlight_level is (supposed >> to be) initialized. >> >> What values do the following files contain in the broken and working cases? >> >> /sys/class/backlight/radeon_bl0/bl_power >> /sys/class/backlight/radeon_bl0/brightness >> /sys/class/backlight/radeon_bl0/actual_brightness >> /sys/class/backlight/radeon_bl0/max_brightness >> >> > > These files do not exist on my system, > I can offer /sys/class/backlight/acpi_video0/ > > content is identical in both cases > > bl_power0 > brightness 10 > actual_brightness 10 > max_brightness 10 > > It would appear that your system does not use the gpu backlight controller. Either it's lying or messing with the GPU backlight controller causes some bad interaction with whatever does control it. Does the attached radeon patch help? I'm also attaching an amdgpu patch for reference in case the same problem appears on amdgpu. Alex -- next part -- A non-text attachment was scrubbed... Name: 0002-drm-amdgpu-fix-backlight-handling-when-not-controlle.patch Type: text/x-patch Size: 2441 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151027/252b8352/attachment.bin> -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-radeon-fix-backlight-handling-when-not-controlle.patch Type: text/x-patch Size: 2601 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151027/252b8352/attachment-0001.bin>
No backlight since linux-4.2.4 - drivers/gpu/drm/radeon/atombios_encoders.c
On 10/27/15 10:17, Michel Dänzer wrote: > > I'm not familiar with the ATOM bytecode, but since the number of > bytecode instructions executed seems the same in both cases, I suspect > that dig->backlight_level == 0 => ATOM_LCD_BLOFF is executed. (The > debugging output in my patch would have provided all of this information > and more, but there wasn't any of it in the dmesg you provided) > > I guess the question then becomes how dig->backlight_level is (supposed > to be) initialized. > > What values do the following files contain in the broken and working cases? > > /sys/class/backlight/radeon_bl0/bl_power > /sys/class/backlight/radeon_bl0/brightness > /sys/class/backlight/radeon_bl0/actual_brightness > /sys/class/backlight/radeon_bl0/max_brightness > > These files do not exist on my system, I can offer /sys/class/backlight/acpi_video0/ content is identical in both cases bl_power0 brightness 10 actual_brightness 10 max_brightness 10
Missing amdgpu firmware files
On Tue, Oct 27, 2015 at 04:47:53PM +0100, Christian König wrote: > Well that's strange. Essentially those are just duplicates to the > existing files and the driver should fallback to them. > > IIRC the radeon/*_sdma1.bin files are only requested when you try to > use CIK support with amdgpu which isn't a good idea in a production > environment. > > What's the link for the bug reports? It's most likely just people > trying to use the driver with hardware which it isn't supposed to be > used with. There have been a few reports that the firmware is missing, but only one I see where the user actually reports any display problems. http://bugs.launchpad.net/bugs/1510405 Of course it's possible that he is jumping to conclusions about the missing firmware files causing his display issues. Thanks, Seth
[PATCH] drm/msm/mdp5: high precision vblank timestamp support
On 10/27/2015 05:33 AM, Rob Clark wrote: > On Mon, Oct 26, 2015 at 5:54 AM, Archit Taneja > wrote: >> MDP5 has line count and frame count registers for each interface. Enable >> these counters and use them to implement the get_vblank_timestamp drm >> driver op. >> >> The line counter starts with the value 1 at the beginning of the VSYNC >> pulse and ends with value VTOTAL at the end of VFP. This value is used >> to determine whether we're in blanking period or not, and an adjusted >> value of this counter is used to get vpos as expected by >> get_scanout_position. Since there is no way to calculate hpos, we always >> set it to 0. > > What are the odds that mdp(n!=5) could support the same? If/when that > ever happens I could see making some of this helpers to duplicate a > bit less in mdpN backend.. but I guess also fine to cross that bridge > when we come to it. Other than that, lgtm, thanks The MDP4 line counter only loops within the active region, making it sort of ineffective. That's the main reason why I didn't attempt to implement it for mdp4. There seems to be a 12 bit frame counter available to implement a vblank counter, but without the line counter, I'm not sure if that'll be any better than using the software vblank counter. Archit > > BR, > -R > >> Signed-off-by: Archit Taneja >> --- >> drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 18 >> drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 129 >> >> drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 2 + >> 3 files changed, 149 insertions(+) >> >> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c >> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c >> index c9e32b0..a019656 100644 >> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c >> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c >> @@ -293,6 +293,24 @@ static const struct drm_encoder_helper_funcs >> mdp5_encoder_helper_funcs = { >> .enable = mdp5_encoder_enable, >> }; >> >> +int mdp5_encoder_get_linecount(struct drm_encoder *encoder) >> +{ >> + struct mdp5_encoder *mdp5_encoder = to_mdp5_encoder(encoder); >> + struct mdp5_kms *mdp5_kms = get_kms(encoder); >> + int intf = mdp5_encoder->intf.num; >> + >> + return mdp5_read(mdp5_kms, REG_MDP5_INTF_LINE_COUNT(intf)); >> +} >> + >> +u32 mdp5_encoder_get_framecount(struct drm_encoder *encoder) >> +{ >> + struct mdp5_encoder *mdp5_encoder = to_mdp5_encoder(encoder); >> + struct mdp5_kms *mdp5_kms = get_kms(encoder); >> + int intf = mdp5_encoder->intf.num; >> + >> + return mdp5_read(mdp5_kms, REG_MDP5_INTF_FRAME_COUNT(intf)); >> +} >> + >> int mdp5_encoder_set_split_display(struct drm_encoder *encoder, >> struct drm_encoder *slave_encoder) >> { >> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c >> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c >> index b532faa..e115318 100644 >> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c >> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c >> @@ -468,6 +468,127 @@ static int get_clk(struct platform_device *pdev, >> struct clk **clkp, >> return 0; >> } >> >> +static struct drm_encoder *get_encoder_from_crtc(struct drm_crtc *crtc) >> +{ >> + struct drm_device *dev = crtc->dev; >> + struct drm_encoder *encoder; >> + >> + drm_for_each_encoder(encoder, dev) >> + if (encoder->crtc == crtc) >> + return encoder; >> + >> + return NULL; >> +} >> + >> +static int mdp5_get_scanoutpos(struct drm_device *dev, unsigned int pipe, >> + unsigned int flags, int *vpos, int *hpos, >> + ktime_t *stime, ktime_t *etime, >> + const struct drm_display_mode *mode) >> +{ >> + struct msm_drm_private *priv = dev->dev_private; >> + struct drm_crtc *crtc; >> + struct drm_encoder *encoder; >> + int line, vsw, vbp, vactive_start, vactive_end, vfp_end; >> + int ret = 0; >> + >> + crtc = priv->crtcs[pipe]; >> + if (!crtc) { >> + DRM_ERROR("Invalid crtc %d\n", pipe); >> + return 0; >> + } >> + >> + encoder = get_encoder_from_crtc(crtc); >> + if (!encoder) { >> + DRM_ERROR("no encoder found for crtc %d\n", pipe); >> + return 0; >> + } >> + >> + ret |= DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_ACCURATE; >> + >> + vsw = mode->crtc_vsync_end - mode->crtc_vsync_start; >> + vbp = mode->crtc_vtotal - mode->crtc_vsync_end; >> + >> + /* >> +* the line counter is 1 at the start of the VSYNC pulse and VTOTAL >> at >> +* the end of VFP. Translate the porch values relative to the line >> +* counter positions. >> +*/ >> + >> + vactive_start = vsw + vbp + 1; >> + >> + vactive_end = vactive_start + mode->crtc_vdisplay; >> + >> + /* last scan line before VSYNC */ >> +
Missing amdgpu firmware files
I've received reports from Ubuntu users about missing amdgpu firmware files with 4.2 kernels. The driver calls out a number of radeon/*_sdma1.bin files that are not present in the linux-firmware git repo. Are these files available anywhere (under a license that allows redistribution), and will they be pushed up to linux-firmware anytime soon? Thanks, Seth
[Linux v4.3-rc6] i915: issues with Skylake integrated graphics
On Tue, 27 Oct 2015, Eric Biggers wrote: > On Mon, Oct 26, 2015 at 03:28:37PM +0200, Jani Nikula wrote: >> Please file two separate bugs at [1], one for the above, and another for >> the below. Please add drm.debug=14 module parameter, and attach dmesg >> all the way from boot to the problem. > > I have filed https://bugs.freedesktop.org/show_bug.cgi?id=92685 for the second > part. I did not, however, re-experience the first warning (the > "WARN_ON(p->pixel_rate == 0)") after upgrading to Linux v4.3-rc7 and rebooting > several times. Thanks for the report. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
No backlight since linux-4.2.4 - drivers/gpu/drm/radeon/atombios_encoders.c
On 10/27/15 03:36, Michel Dänzer wrote: >> >> [0] contains dmesg output with your patch applied (which fixes the backlight >> issue) > > This is very surprising: The patch just adds some debugging output, it's > not supposed to have any functional effect. Also, I don't see any of the > debugging output added by the patch in > dmesg-4.3.0-rc7-3-g85051e2-dirty-2015-10-26-11-00-41-radeon-bl-debug. > > Are you sure that my patch was actually applied to the radeon driver > when generating that file? Did you update the initrd with the patched > radeon.ko? > the build was done using "make -j4 deb-pkg" on a better equipped machine, .deb packages were copied over and installed - maybe something interesting happened AFAICT the patch should have been applied, at least it was shown with git diff and the -dirty suffix was added by the build system, not me. All graphics related drivers are compiled in (=y) rather than as modules (=m) in .config. Another thing I tried yesterday was to add the old way right below the new one (this fixes the backlight issue) enclosed by some debug statements that indicate start / stop of the old / new method. (see atomdebug.diff - should be applied against mainline) -- next part -- radeon_start_backlight_new_way >> execute D2AA (len 348, WS 4, PS 4) SET_ATI_PORT @ 0xD2B0 port: 0 (MM) COMPARE_PS @ 0xD2B3 src1: PS[0x00,0x8802] .[7:0] -> 0x02 src2: IMM 0x04 result: NE LE JUMP_EQUAL @ 0xD2B7 taken: no target: 0x0128 COMPARE_PS @ 0xD2BA src1: PS[0x00,0x8802] .[7:0] -> 0x02 src2: IMM 0x05 result: NE LE JUMP_EQUAL @ 0xD2BE taken: no target: 0x0113 COMPARE_PS @ 0xD2C1 src1: PS[0x00,0x8802] .[7:0] -> 0x02 src2: IMM 0x00 result: NE GT JUMP_EQUAL @ 0xD2C5 taken: no target: 0x00D8 COMPARE_PS @ 0xD2C8 src1: PS[0x00,0x8802] .[7:0] -> 0x02 src2: IMM 0x01 result: NE GT JUMP_NOT_EQUAL @ 0xD2CC taken: yes target: 0x013D COMPARE_PS @ 0xD3E7 src1: PS[0x00,0x8802] .[7:0] -> 0x02 src2: IMM 0x03 result: NE LE JUMP_NOT_EQUAL @ 0xD3EB taken: yes target: 0x0151 OR_REG @ 0xD3FB dst: REG[0x1EBC] .[31:24] -> 0x00 src: IMM 0x02 dst: REG[0x1EBC] .[31:24] <- 0x02 AND_REG @ 0xD400 dst: REG[0x1EBC] .[31:24] -> 0x02 src: IMM 0xFE dst: REG[0x1EBC] .[31:24] <- 0x02 EOT @ 0xD405 << radeon_stop_backlight_new_wayradeon_start_backlight_old_way -- next part -- radeon_stop_backlight_new_wayradeon_start_backlight_old_way >> execute D2AA (len 348, WS 4, PS 4) SET_ATI_PORT @ 0xD2B0 port: 0 (MM) COMPARE_PS @ 0xD2B3 src1: PS[0x00,0x0003] .[7:0] -> 0x03 src2: IMM 0x04 result: NE LE JUMP_EQUAL @ 0xD2B7 taken: no target: 0x0128 COMPARE_PS @ 0xD2BA src1: PS[0x00,0x0003] .[7:0] -> 0x03 src2: IMM 0x05 result: NE LE JUMP_EQUAL @ 0xD2BE taken: no target: 0x0113 COMPARE_PS @ 0xD2C1 src1: PS[0x00,0x0003] .[7:0] -> 0x03 src2: IMM 0x00 result: NE GT JUMP_EQUAL @ 0xD2C5 taken: no target: 0x00D8 COMPARE_PS @ 0xD2C8 src1: PS[0x00,0x0003] .[7:0] -> 0x03 src2: IMM 0x01 result: NE GT JUMP_NOT_EQUAL @ 0xD2CC taken: yes target: 0x013D COMPARE_PS @ 0xD3E7 src1: PS[0x00,0x0003] .[7:0] -> 0x03 src2: IMM 0x03 result: EQ LE JUMP_NOT_EQUAL @ 0xD3EB taken: no target: 0x0151 OR_REG @ 0xD3EE dst: REG[0x1EBC] .[31:24] -> 0x02 src: IMM 0x02 dst: REG[0x1EBC] .[31:24] <- 0x02 OR_REG @ 0xD3F3 dst: REG[0x1EBC] .[31:24] -> 0x02 src: IMM 0x01 dst: REG[0x1EBC] .[31:24] <- 0x03 JUMP @ 0xD3F8 target: 0x015B EOT @ 0xD405 << radeon_stop_backlight_old_way -- next part -- A non-text attachment was scrubbed... Name: atomdebug.diff Type: text/x-patch Size: 1430 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151027/a392214c/attachment-0001.bin>
[Bug 92309] Box drawn around cursor in multiple 3D games
https://bugs.freedesktop.org/show_bug.cgi?id=92309 --- Comment #11 from Kamil Páral --- Thanks, Michel, that sounds plausible. In that case it seems we can close this bug and the only thing to do here is to ask the developers to fix their games. -- 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/20151027/d9c69f3c/attachment.html>
[Bug 92309] Box drawn around cursor in multiple 3D games
https://bugs.freedesktop.org/show_bug.cgi?id=92309 --- Comment #10 from Michel Dänzer --- Presumably the cursor isn't captured by apitrace because it's not rendered using OpenGL but uses the Xcursor* APIs. The artifacts are most likely due to the cursor image not using proper pre-mulitplied alpha data as expected by those APIs, which apparently happens to "work" to some degree with other drivers / hardware. -- 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/20151027/aa282ace/attachment.html>
[GIT PULL] On-demand device probing
On Tuesday, October 20, 2015 12:04:05 PM Alan Stern wrote: > On Tue, 20 Oct 2015, Mark Brown wrote: > > > On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: > > > > > Furthermore, that applies only to devices that use synchronous suspend. > > > Async suspend is becoming common, and there the only restrictions are > > > parent-child relations plus whatever explicit requirements that drivers > > > impose by calling device_pm_wait_for_dev(). > > > > Hrm, this is the first I'd noticed that feature though I see the initial > > commit dates from January. > > Async suspend and device_pm_wait_for_dev() were added in January 2010, > not 2015! > > > It looks like most of the users are PCs at > > the minute but we should be using it more widely for embedded things, > > there's definitely some cases I'm aware of where it will allow us to > > remove some open coding. > > > > It does seem like we want to be feeding dependency information we > > discover for probing way into the suspend dependencies... > > Rafael has been thinking about a way to do this systematically. > Nothing concrete has emerged yet. Well, good point. :-) I've been kind of struggling with finding time to work on the patches lately and some aspects of the design are still not finalized. It seems, though, that it can be beneficial to discuss the approach in general, so let me start a new thread for that. Thanks, Rafael
[Bug 106291] amdgpu fails GPU reset when resuming from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=106291 --- Comment #7 from Michel Dänzer --- The log from 4.3-rc6 doesn't show any trace of the amdgpu driver. Did you accidentally disable it when compiling that kernel? -- You are receiving this mail because: You are watching the assignee of the bug.
[GIT PULL] On-demand device probing
On Mon, Oct 26, 2015 at 11:51 AM, Michael Turquette wrote: > Quoting Rafael J. Wysocki (2015-10-25 06:54:39) >> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown wrote: >> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: >> > >> >> Well, I'm not quite sure why exactly everyone is so focused on probing >> >> here. >> > >> > Probe deferral is really noisy even if it's working fine on a given >> > system so it's constantly being highlighted to people in a way that >> > other issues aren't if you're not directly having problems. >> > >> > There's also the understanding people had that the order things get >> > bound changes the ordering for some of the other cases (perhaps it's a >> > good idea to do that, it seems likely to be sensible?). >> >> But it really doesn't do that. Also making it do so doesn't help much >> in the cases where things can happen asynchronously (system >> suspend/resume, runtime PM). >> >> If, instead, there was a way to specify a functional dependency at the >> device registration time, it might be used to change the order of >> everything relevant, including probe. That should help to reduce the >> noise you're referring to. > > Taking it a step further, if functional dependencies were understood at > link-time then we could optimize link order as well. There are probably > lots of optimizations if we only made the effort to understand these > dependencies earlier. Do you mean the kernel link time or something else? At least in some cases the dependency information won't be known at that time, so we need a way to record a dependency at the time it becomes visible to us anyway. > Constructing the device/resource dependency graph before the device ever > boots sounds interesting to me. That's only practical if you build the kernel for a specific device. If you want a generic binary that can work with multiple different devices, that graph may very well be different for each of them. Thanks, Rafael