Re: i915 backlight
On Wed, Jul 31, 2013 at 11:16:52PM +0200, Rafael J. Wysocki wrote: > Does reverting efaa14c help? Nope. But see my other reply to Aaron. Thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915 backlight
On Thu, Aug 01, 2013 at 09:13:35AM +0800, Aaron Lu wrote: > Can you please run acpi_listen and then press the Fn-Fx key, see if the > events are correctly sent out? Like this? # acpi_listen video/brightnessdown BRTDN 0087 video/brightnessup BRTUP 0086 video/brightnessdown BRTDN 0087 video/brightnessup BRTUP 0086 video/brightnessdown BRTDN 0087 video/brightnessup BRTUP 0086 video/brightnessdown BRTDN 0087 video/brightnessup BRTUP 0086 video/brightnessdown BRTDN 0087 ^C > From the bug page: > https://bugzilla.kernel.org/show_bug.cgi?id=51231#c80 > I got the impression that both the acpi_video interface and the vendor > interface thinkpad_screen are broken. So adding this cmdline here works > suggests that either thinkpad_screen works or thinkpad vendor driver > doesn't get loaded or doesn't create that interface for some reason. > > Alternatively, if the intel_backlight interface works(highly possible), > you can use xorg.conf to specify the that backlight interface for X. > > Section "Device" > Option "Backlight""intel_backlight" > Identifier "Card0" > Driver "intel" > BusID "PCI:0:2:0" > EndSection Yeah, that didn't work *but* manually writing to both: /sys/class/backlight/acpi_video0/brightness and /sys/class/backlight/intel_backlight/brightness works. The ranges are different, though: intel_backlight/actual_brightness:1000 intel_backlight/bl_power:0 intel_backlight/brightness:1000 intel_backlight/max_brightness:4437 intel_backlight/type:raw acpi_video0/actual_brightness:41 acpi_video0/bl_power:0 acpi_video0/brightness:41 acpi_video0/max_brightness:100 acpi_video0/type:firmware I guess I need to write me a dirty script for now ... :-) Thanks guys. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #42 from Scias --- Comment 40 patch works here. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60674] New: linux 3.10.x RV740 (Radeon HD 4770) display problem
https://bugzilla.kernel.org/show_bug.cgi?id=60674 Bug ID: 60674 Summary: linux 3.10.x RV740 (Radeon HD 4770) display problem Product: Drivers Version: 2.5 Kernel Version: 3.10 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: yg...@sfr.fr Regression: No Created attachment 107073 --> https://bugzilla.kernel.org/attachment.cgi?id=107073&action=edit Screenshot with kernel 3.10 (display BUG) Description: Hard to describe… It seems that fonts don’t get displayed. Seeing the screenshots, I’m not sure it is the only problem, though… (see icons for example) Linux console is OK. E17 is OK. Additional info: * OS: up-to-date Arch Linux * current (working kernel): 3.9.9 * tested non-working kernels: 3.10.2 and 3.10.3 Steps to reproduce: * upgrade kernel, * get this: [attached screenshot] As you can see, Enlightenment17 has no problem for some reason. However, all other applications I tried were displayed like the screenshot: Firefox, Thunderbird, Geany… and SLIM (the display manager)! On the login screen for example, I can enter my login name, but no text is shown on screen; it lets me login though. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60674] linux 3.10.x RV740 (Radeon HD 4770) display problem
https://bugzilla.kernel.org/show_bug.cgi?id=60674 --- Comment #1 from Yves G. (theYinYeti) --- Created attachment 107074 --> https://bugzilla.kernel.org/attachment.cgi?id=107074&action=edit For comparison, same screenshot with kernel 3.9. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/27] drivers/gpu/host1x/drm: don't check resource with devm_ioremap_resource
On 23.07.2013 21:01, Wolfram Sang wrote: > diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c > index 01097da..9ffece6 100644 > --- a/drivers/gpu/host1x/drm/hdmi.c > +++ b/drivers/gpu/host1x/drm/hdmi.c > @@ -1248,9 +1248,6 @@ static int tegra_hdmi_probe(struct platform_device > *pdev) > return err; > > regs = platform_get_resource(pdev, IORESOURCE_MEM, 0); > - if (!regs) > - return -ENXIO; > - > hdmi->regs = devm_ioremap_resource(&pdev->dev, regs); > if (IS_ERR(hdmi->regs)) > return PTR_ERR(hdmi->regs); > Looks good to me. Reviewed-By: Terje Bergstrom Terje ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 13/20] drm/gem: create drm_gem_dumb_destroy
On Tue, Jul 16, 2013 at 9:12 AM, Daniel Vetter wrote:
> All the gem based kms drivers really want the same function to
> destroy a dumb framebuffer backing storage object.
>
> So give it to them and roll it out in all drivers.
>
> This still leaves the option open for kms drivers which don't use GEM
> for backing storage, but it does decently simplify matters for gem
> drivers.
>
> Cc: Inki Dae
> Cc: Laurent Pinchart
> Cc: Intel Graphics Development
> Cc: Ben Skeggs
> Cc: Rob Clark
> Cc: Alex Deucher
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/ast/ast_drv.c | 2 +-
> drivers/gpu/drm/ast/ast_drv.h | 3 ---
> drivers/gpu/drm/ast/ast_main.c| 7 ---
> drivers/gpu/drm/cirrus/cirrus_drv.c | 2 +-
> drivers/gpu/drm/cirrus/cirrus_drv.h | 3 ---
> drivers/gpu/drm/cirrus/cirrus_main.c | 7 ---
> drivers/gpu/drm/drm_gem.c | 14 ++
> drivers/gpu/drm/drm_gem_cma_helper.c | 10 --
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 20
> drivers/gpu/drm/exynos/exynos_drm_gem.h | 9 -
> drivers/gpu/drm/gma500/gem.c | 17 -
> drivers/gpu/drm/gma500/psb_drv.c | 2 +-
> drivers/gpu/drm/gma500/psb_drv.h | 2 --
> drivers/gpu/drm/i915/i915_drv.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 2 --
> drivers/gpu/drm/i915/i915_gem.c | 7 ---
> drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +-
> drivers/gpu/drm/mgag200/mgag200_drv.h | 3 ---
> drivers/gpu/drm/mgag200/mgag200_main.c| 7 ---
> drivers/gpu/drm/nouveau/nouveau_display.c | 7 ---
> drivers/gpu/drm/nouveau/nouveau_display.h | 2 --
> drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_drv.c| 2 +-
> drivers/gpu/drm/omapdrm/omap_drv.h| 2 --
> drivers/gpu/drm/omapdrm/omap_gem.c| 15 ---
> drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
> drivers/gpu/drm/qxl/qxl_drv.h | 3 ---
> drivers/gpu/drm/qxl/qxl_dumb.c| 7 ---
> drivers/gpu/drm/radeon/radeon.h | 3 ---
> drivers/gpu/drm/radeon/radeon_drv.c | 5 +
> drivers/gpu/drm/radeon/radeon_gem.c | 7 ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +-
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
> drivers/gpu/drm/udl/udl_drv.c | 2 +-
> drivers/gpu/drm/udl/udl_drv.h | 2 --
> drivers/gpu/drm/udl/udl_gem.c | 6 --
> drivers/gpu/host1x/drm/drm.c | 2 +-
> drivers/gpu/host1x/drm/gem.c | 6 --
> drivers/gpu/host1x/drm/gem.h | 2 --
> drivers/staging/imx-drm/imx-drm-core.c| 2 +-
> include/drm/drmP.h| 3 +++
> include/drm/drm_gem_cma_helper.h | 8
> 44 files changed, 33 insertions(+), 186 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
> index df0d0a0..a144fb0 100644
> --- a/drivers/gpu/drm/ast/ast_drv.c
> +++ b/drivers/gpu/drm/ast/ast_drv.c
> @@ -216,7 +216,7 @@ static struct drm_driver driver = {
> .gem_free_object = ast_gem_free_object,
> .dumb_create = ast_dumb_create,
> .dumb_map_offset = ast_dumb_mmap_offset,
> - .dumb_destroy = ast_dumb_destroy,
> + .dumb_destroy = drm_gem_dumb_destroy,
>
> };
>
> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> index 622d4ae..796dbb2 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -322,9 +322,6 @@ ast_bo(struct ttm_buffer_object *bo)
> extern int ast_dumb_create(struct drm_file *file,
>struct drm_device *dev,
>struct drm_mode_create_dumb *args);
> -extern int ast_dumb_destroy(struct drm_file *file,
> - struct drm_device *dev,
> - uint32_t handle);
>
> extern int ast_gem_init_object(struct drm_gem_object *obj);
> extern void ast_gem_free_object(struct drm_gem_object *obj);
> diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
> index f60fd7b..0ef4228 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -449,13 +449,6 @@ int ast_dumb_create(struct drm_file *file,
> return 0;
> }
>
> -int ast_dumb_destroy(struct drm_file *file,
> -struct drm_device *dev,
> -uint32_t handle)
> -{
> - return drm_gem_handle_delete(file, handle);
> -}
> -
> int ast_gem_init_object(struct drm_gem_object *obj)
> {
> BUG();
> diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
> b/drivers/gpu/drm/cirrus/cirrus_drv.c
> index 8ecb601..d35d99c 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_drv.c
> +++ b/dr
[Bug 60674] linux 3.10.x RV740 (Radeon HD 4770) display problem
https://bugzilla.kernel.org/show_bug.cgi?id=60674 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher --- Just to be sure, is the only component you changed the kernel (i.e., you didn't change the mesa version as well)? If so, can you bisect the kernel? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #43 from Alex Deucher --- Can you guys attach a copy of your vbios? (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/ echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #44 from Sergey --- Created attachment 83431 --> https://bugs.freedesktop.org/attachment.cgi?id=83431&action=edit vbios used for ATI RV620/M82 [Mobility Radeon HD 3450/3470] -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: use loop for initializing AFMT blocks
On Thu, Aug 1, 2013 at 1:54 AM, Rafał Miłecki wrote: > 2013/7/31 Alex Deucher : >> On Wed, Jul 31, 2013 at 11:50 AM, Rafał Miłecki wrote: >>> >>> Signed-off-by: Rafał Miłecki >>> --- >>> Dave/Alex: please decide who picks this patch :) >> >> I think it might be easier to just assume 6 afmt blocks on all DCE4+ >> hardware (DCE6 too). It's makes the logic simpler in the driver. The >> afmt block is tied to the dig encoder so the correct one will always >> get selected even if a particular asic has more allocated than it has >> physically. > > I'm not sure about idea of allocating memory for parts of hardware > that don't exist (read: wasting some memory). It could be a nice > solution to allocate AFMT blocks depending on the amount of DIG > encoders. Unfortunately, I'm afraid we don't have anything like > "num_dig", do we? We assign "dig->dig_encoder" value using > radeon_atom_pick_dig_encoder, but it just check for encoder/link/crtc. > > Any other idea? Or should we just waste some memory? Is this worth it It seems simpler to me, but it's not that big a deal either way. > to avoid this simple > if (ASIC_IS_DCE64(rdev)) > num_afmt = 2; Need to double check which PHYs oland actually has. I think it's just the first two. > else if (ASIC_IS_DCE61(rdev)) > num_afmt = 4; Trinity supports 6 dig encoders. > else if (ASIC_IS_DCE6(rdev)) > num_afmt = 6; > else if (ASIC_IS_DCE5(rdev)) > num_afmt = 6; > else if (ASIC_IS_DCE41(rdev)) > num_afmt = 2; > else /* DCE4 */ > num_afmt = 6; > ? > > > -- > Rafał ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fix 64 bit divide in SI spm code
From: Alex Deucher Forgot to use the appropriate math64 function. Signed-off-by: Alex Deucher --- This is already in my -fixes queue, but for those that are running into issues, here's the fix. drivers/gpu/drm/radeon/si_dpm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c index 7ad22e8..4182557 100644 --- a/drivers/gpu/drm/radeon/si_dpm.c +++ b/drivers/gpu/drm/radeon/si_dpm.c @@ -1767,7 +1767,7 @@ static void si_calculate_leakage_for_v_and_t_formula(const struct ni_leakage_coe s64 temperature, t_slope, t_intercept, av, bv, t_ref; s64 tmp; - i_leakage = drm_int2fixp(ileakage) / 100; + i_leakage = div64_s64(drm_int2fixp(ileakage), 100); vddc = div64_s64(drm_int2fixp(v), 1000); temperature = div64_s64(drm_int2fixp(t), 1000); -- 1.7.7.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #45 from Scias --- Created attachment 83432 --> https://bugs.freedesktop.org/attachment.cgi?id=83432&action=edit vbios for RV635/M86 [Mobility Radeon HD 3650] vbios for RV635/M86 [Mobility Radeon HD 3650] -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #46 from Francisco Pina Martins --- I am trying to do some testing too, but I cannot seem to apply the patch from comment 40 to the mainline kernel. Should I be getting the changes from a specific branch in git://people.freedesktop.org/~agd5f/linux ? Thanks and sorry about the noise. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #47 from Alex Deucher --- I've pushed my latest -fixes branch: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.11 it already includes the fix from comment 40. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #48 from Alex Deucher --- Sergey, On a kernel that has the patch in comment 40, does booting with radeon.aspm=0 help? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/radeon/dpm: implement force performance levels for rs780
> -Original Message-
> From: Anthoine Bourgeois [mailto:anthoine.bourge...@gmail.com]
> Sent: Wednesday, July 31, 2013 6:34 PM
> To: Deucher, Alexander; Koenig, Christian; Jerome Glisse; Anthoine
> Bourgeois
> Cc: dri-devel@lists.freedesktop.org
> Subject: [PATCH] drm/radeon/dpm: implement force performance levels for
> rs780
>
> Allows you to limit the selected power levels via sysfs.
>
> Force the feedback divider to select a power level.
Nice work. A few comments below.
Alex
>
> Signed-off-by: Anthoine Bourgeois
> ---
> drivers/gpu/drm/radeon/radeon_asic.c | 1 +
> drivers/gpu/drm/radeon/radeon_asic.h | 2 ++
> drivers/gpu/drm/radeon/rs780_dpm.c | 67
> ++--
> 3 files changed, 59 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
> b/drivers/gpu/drm/radeon/radeon_asic.c
> index f8f8b31..437d357 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.c
> +++ b/drivers/gpu/drm/radeon/radeon_asic.c
> @@ -1272,6 +1272,7 @@ static struct radeon_asic rs780_asic = {
> .get_mclk = &rs780_dpm_get_mclk,
> .print_power_state = &rs780_dpm_print_power_state,
> .debugfs_print_current_performance_level =
> &rs780_dpm_debugfs_print_current_performance_level,
> + .force_performance_level =
> &rs780_dpm_force_performance_level,
> },
> .pflip = {
> .pre_page_flip = &rs600_pre_page_flip,
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
> b/drivers/gpu/drm/radeon/radeon_asic.h
> index 902479f..09841fc 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.h
> +++ b/drivers/gpu/drm/radeon/radeon_asic.h
> @@ -437,6 +437,8 @@ void rs780_dpm_print_power_state(struct
> radeon_device *rdev,
>struct radeon_ps *ps);
> void rs780_dpm_debugfs_print_current_performance_level(struct
> radeon_device *rdev,
> struct seq_file *m);
> +int rs780_dpm_force_performance_level(struct radeon_device *rdev,
> + enum radeon_dpm_forced_level level);
>
> /* uvd */
> int r600_uvd_init(struct radeon_device *rdev);
> diff --git a/drivers/gpu/drm/radeon/rs780_dpm.c
> b/drivers/gpu/drm/radeon/rs780_dpm.c
> index d1a1ce7..df58e34 100644
> --- a/drivers/gpu/drm/radeon/rs780_dpm.c
> +++ b/drivers/gpu/drm/radeon/rs780_dpm.c
> @@ -404,6 +404,27 @@ static void rs780_force_voltage_to_high(struct
> radeon_device *rdev)
> WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
> }
>
> +static void rs780_force_fbdiv(struct radeon_device *rdev, u32 fb_div)
> +{
> + struct igp_ps *current_state = rs780_get_ps(rdev-
> >pm.dpm.current_ps);
> +
> + if ((current_state->sclk_low == fb_div) &&
> + (current_state->sclk_high == fb_div))
> + return;
I'm not quite sure what you are checking here.
> +
> + WREG32_P(GFX_MACRO_BYPASS_CNTL, SPLL_BYPASS_CNTL,
> ~SPLL_BYPASS_CNTL);
> +
> + WREG32_P(FVTHROT_FBDIV_REG2,
> FORCED_FEEDBACK_DIV(fb_div),
> + ~FORCED_FEEDBACK_DIV_MASK);
> + WREG32_P(FVTHROT_FBDIV_REG1,
> STARTING_FEEDBACK_DIV(fb_div),
> + ~STARTING_FEEDBACK_DIV_MASK);
> + WREG32_P(FVTHROT_FBDIV_REG1, FORCE_FEEDBACK_DIV,
> ~FORCE_FEEDBACK_DIV);
> +
> + udelay(100);
> +
> + WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
> +}
> +
> static int rs780_set_engine_clock_scaling(struct radeon_device *rdev,
> struct radeon_ps *new_ps,
> struct radeon_ps *old_ps)
> @@ -432,17 +453,7 @@ static int rs780_set_engine_clock_scaling(struct
> radeon_device *rdev,
> if (ret)
> return ret;
>
> - WREG32_P(GFX_MACRO_BYPASS_CNTL, SPLL_BYPASS_CNTL,
> ~SPLL_BYPASS_CNTL);
> -
> - WREG32_P(FVTHROT_FBDIV_REG2,
> FORCED_FEEDBACK_DIV(max_dividers.fb_div),
> - ~FORCED_FEEDBACK_DIV_MASK);
> - WREG32_P(FVTHROT_FBDIV_REG1,
> STARTING_FEEDBACK_DIV(max_dividers.fb_div),
> - ~STARTING_FEEDBACK_DIV_MASK);
> - WREG32_P(FVTHROT_FBDIV_REG1, FORCE_FEEDBACK_DIV,
> ~FORCE_FEEDBACK_DIV);
> -
> - udelay(100);
> -
> - WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
> + rs780_force_fbdiv(rdev, max_dividers.fb_div);
>
> if (max_dividers.fb_div > min_dividers.fb_div) {
> WREG32_P(FVTHROT_FBDIV_REG0,
> @@ -986,3 +997,37 @@ void
> rs780_dpm_debugfs_print_current_performance_level(struct
> radeon_device *rde
> seq_printf(m, "power level 1sclk: %u vddc_index: %d\n",
> ps->sclk_high, ps->max_voltage);
> }
> +
> +int rs780_dpm_force_performance_level(struct radeon_device *rdev,
> + enum radeon_dpm_forced_level level)
> +{
> + struct radeon_ps *rps = rdev->pm.dpm.current_ps;
> + struct igp_ps *ps = rs780_get_ps(rps);
> + struct atom_clock_dividers min_dividers, max_dividers;
You can drop t
Re: [PATCH 0/2] drm/tilcdc drm/i2c/tda998x workaround for sync issues on TI SoC
Sebastian Hesselbarth wrote on Wed [2013-Jul-31 22:21:20 +0200]: > Darren, > > I now fully understand the issues of AM335x's LCD controller and your > fix for it. I suggest to clarify the comments you added to tilcdc to > allow others to understand it more quickly. > Sebastian, Thanks for looking at my proposed changes, you understand this sync stuff very well so I appreciate your input that this is actually an acceptable workaround. > Actually, the LCD controller always aligns vsync to the second edge > of hsync, which will never give VESA-compliant sync. The (elegant) > workaround you are proposing is to align both rising edges, so at > least TDA998x can sync on those with some hskew added. Lucky you that > it ignores hsync length but only looks for rising HS/VS edges ;) Yes we definitely got lucky with this one, good thing the NXP supported that reference pixel position, as I was out of options from the lcd controller side of things to adjust the horizontal position. > > Should we prepare a new patch set comprising the following patches? > > Russell King: > drm/i2c: nxp-tda998x: fix EDID reading on TDA19988 devices > drm/i2c: nxp-tda998x: ensure VIP output mux is properly set > drm/i2c: nxp-tda998x: fix npix/nline programming > drm/i2c: nxp-tda998x: prepare for video input configuration > drm/i2c: nxp-tda998x: add video and audio input configuration > > Sebastian Hesselbarth: > drm/i2c: tda998x: fix sync generation and calculation > > Darren Etheridge: > drm/i2c/tda998x prepare for tilcdc sync workaround > drm/tilcdc fixup mode to workaound sync for tda998x > > Or do we keep them separated and possibly resend them if David cannot > find them anymore? I vote we submit a complete series that we can all test, there were quite a lot of versions of things in flight at the same time so I am sure David would appreciate a consolidated version. The only thing I have not tested is audio support, but as the original driver did not have that anyway I don't consider it blocking if it is working for CuBox. Darren ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #49 from Francisco Pina Martins --- Created attachment 83443 --> https://bugs.freedesktop.org/attachment.cgi?id=83443&action=edit [AMD/ATI] RV635/M86 [Mobility Radeon HD 3650] vbios Booting with kernel compiled from http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.11 setting radeon.dpm=1 results in the mentioned "frosting", with the machine becoming totally irresponsive. This happens during modesetting. Tried to boot 3 times, all of them the same problem. Trying with radeon.dpm=1 and radeon.aspm=0 gives the exact same result. 3 out of 3 times I get the crash. I am attaching my vbios too. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #50 from Hrvoje Senjan --- Created attachment 83444 --> https://bugs.freedesktop.org/attachment.cgi?id=83444&action=edit Advanced Micro Devices [AMD] nee ATI RV635 [Mobility Radeon HD 3650] Pretty same results as Francisco. The screen remained black after kms tried to kick in. Also, no difference with aspm off. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] drm/tilcdc drm/i2c/tda998x workaround for sync issues on TI SoC
On Thu, Aug 1, 2013 at 10:29 AM, Darren Etheridge wrote: > Sebastian Hesselbarth wrote on Wed > [2013-Jul-31 22:21:20 +0200]: >> Darren, >> >> I now fully understand the issues of AM335x's LCD controller and your >> fix for it. I suggest to clarify the comments you added to tilcdc to >> allow others to understand it more quickly. >> > Sebastian, > Thanks for looking at my proposed changes, you understand this sync > stuff very well so I appreciate your input that this is actually an > acceptable workaround. > >> Actually, the LCD controller always aligns vsync to the second edge >> of hsync, which will never give VESA-compliant sync. The (elegant) >> workaround you are proposing is to align both rising edges, so at >> least TDA998x can sync on those with some hskew added. Lucky you that >> it ignores hsync length but only looks for rising HS/VS edges ;) > Yes we definitely got lucky with this one, good thing the NXP > supported that reference pixel position, as I was out of options from > the lcd controller side of things to adjust the horizontal position. > >> >> Should we prepare a new patch set comprising the following patches? >> >> Russell King: >> drm/i2c: nxp-tda998x: fix EDID reading on TDA19988 devices >> drm/i2c: nxp-tda998x: ensure VIP output mux is properly set >> drm/i2c: nxp-tda998x: fix npix/nline programming >> drm/i2c: nxp-tda998x: prepare for video input configuration >> drm/i2c: nxp-tda998x: add video and audio input configuration >> >> Sebastian Hesselbarth: >> drm/i2c: tda998x: fix sync generation and calculation >> >> Darren Etheridge: >> drm/i2c/tda998x prepare for tilcdc sync workaround >> drm/tilcdc fixup mode to workaound sync for tda998x >> >> Or do we keep them separated and possibly resend them if David cannot >> find them anymore? > I vote we submit a complete series that we can all test, there were quite > a lot of versions of things in flight at the same time so I am sure > David would appreciate a consolidated version. I'm sure Dave would appreciate it if someone set up a tree w/ all the patches consolidated and sent a pull req. I can help with that if needed, but it probably makes more sense for someone who is using a beagle-bone and/or CuBox on a more regular basis to do this BR, -R > The only thing I have not tested is audio support, but as the original > driver did not have that anyway I don't consider it blocking if it is > working for CuBox. > > Darren ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/radeon: use loop for initializing AFMT blocks
Signed-off-by: Rafał Miłecki
---
drivers/gpu/drm/radeon/radeon_display.c | 53 ++-
1 file changed, 23 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index c2b67b4..31d9fbe 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1257,38 +1257,31 @@ static void radeon_afmt_init(struct radeon_device *rdev)
if (ASIC_IS_DCE6(rdev)) {
/* todo */
} else if (ASIC_IS_DCE4(rdev)) {
+ static uint32_t eg_offsets[] = {
+ EVERGREEN_CRTC0_REGISTER_OFFSET,
+ EVERGREEN_CRTC1_REGISTER_OFFSET,
+ EVERGREEN_CRTC2_REGISTER_OFFSET,
+ EVERGREEN_CRTC3_REGISTER_OFFSET,
+ EVERGREEN_CRTC4_REGISTER_OFFSET,
+ EVERGREEN_CRTC5_REGISTER_OFFSET,
+ };
+ int num_afmt;
+
/* DCE4/5 has 6 audio blocks tied to DIG encoders */
/* DCE4.1 has 2 audio blocks tied to DIG encoders */
- rdev->mode_info.afmt[0] = kzalloc(sizeof(struct radeon_afmt),
GFP_KERNEL);
- if (rdev->mode_info.afmt[0]) {
- rdev->mode_info.afmt[0]->offset =
EVERGREEN_CRTC0_REGISTER_OFFSET;
- rdev->mode_info.afmt[0]->id = 0;
- }
- rdev->mode_info.afmt[1] = kzalloc(sizeof(struct radeon_afmt),
GFP_KERNEL);
- if (rdev->mode_info.afmt[1]) {
- rdev->mode_info.afmt[1]->offset =
EVERGREEN_CRTC1_REGISTER_OFFSET;
- rdev->mode_info.afmt[1]->id = 1;
- }
- if (!ASIC_IS_DCE41(rdev)) {
- rdev->mode_info.afmt[2] = kzalloc(sizeof(struct
radeon_afmt), GFP_KERNEL);
- if (rdev->mode_info.afmt[2]) {
- rdev->mode_info.afmt[2]->offset =
EVERGREEN_CRTC2_REGISTER_OFFSET;
- rdev->mode_info.afmt[2]->id = 2;
- }
- rdev->mode_info.afmt[3] = kzalloc(sizeof(struct
radeon_afmt), GFP_KERNEL);
- if (rdev->mode_info.afmt[3]) {
- rdev->mode_info.afmt[3]->offset =
EVERGREEN_CRTC3_REGISTER_OFFSET;
- rdev->mode_info.afmt[3]->id = 3;
- }
- rdev->mode_info.afmt[4] = kzalloc(sizeof(struct
radeon_afmt), GFP_KERNEL);
- if (rdev->mode_info.afmt[4]) {
- rdev->mode_info.afmt[4]->offset =
EVERGREEN_CRTC4_REGISTER_OFFSET;
- rdev->mode_info.afmt[4]->id = 4;
- }
- rdev->mode_info.afmt[5] = kzalloc(sizeof(struct
radeon_afmt), GFP_KERNEL);
- if (rdev->mode_info.afmt[5]) {
- rdev->mode_info.afmt[5]->offset =
EVERGREEN_CRTC5_REGISTER_OFFSET;
- rdev->mode_info.afmt[5]->id = 5;
+ if (ASIC_IS_DCE5(rdev))
+ num_afmt = 6;
+ else if (ASIC_IS_DCE41(rdev))
+ num_afmt = 2;
+ else /* DCE4 */
+ num_afmt = 6;
+
+ BUG_ON(num_afmt > ARRAY_SIZE(eg_offsets));
+ for (i = 0; i < num_afmt; i++) {
+ rdev->mode_info.afmt[i] = kzalloc(sizeof(struct
radeon_afmt), GFP_KERNEL);
+ if (rdev->mode_info.afmt[i]) {
+ rdev->mode_info.afmt[i]->offset = eg_offsets[i];
+ rdev->mode_info.afmt[i]->id = i;
}
}
} else if (ASIC_IS_DCE3(rdev)) {
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 2/2] drm/radeon: initialize AFMT blocks on DCE6
It was succesfully tested on HD7750 (DCE6). Signed-off-by: Rafał Miłecki --- V2: Update comments, change DCE61 AFMTs amount to 6 --- drivers/gpu/drm/radeon/radeon_display.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index 31d9fbe..8da4fc6 100644 --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -1267,9 +1267,18 @@ static void radeon_afmt_init(struct radeon_device *rdev) }; int num_afmt; - /* DCE4/5 has 6 audio blocks tied to DIG encoders */ - /* DCE4.1 has 2 audio blocks tied to DIG encoders */ - if (ASIC_IS_DCE5(rdev)) + /* +* DCE64 most probably has just 2 AFMTs +* DCE61 supports 6 DIG encoders, so should have 6 AFMTs +* DCE6 was verified to have 6th AFMT using HD7750 +* DCE4/5 has 6 audio blocks tied to DIG encoders +* DCE4.1 has 2 audio blocks tied to DIG encoders +*/ + if (ASIC_IS_DCE64(rdev)) + num_afmt = 2; + else if (ASIC_IS_DCE6(rdev)) + num_afmt = 6; + else if (ASIC_IS_DCE5(rdev)) num_afmt = 6; else if (ASIC_IS_DCE41(rdev)) num_afmt = 2; -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fix halting UVD
From: Christian König
Removing the clock/power or resetting the VCPU can cause
hangs if that happens in the middle of a register write.
Stall the memory and register bus before putting the VCPU
into reset. Keep it in reset when unloading the module or
suspending.
Signed-off-by: Christian König
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/cik.c |3 ++-
drivers/gpu/drm/radeon/evergreen.c |3 ++-
drivers/gpu/drm/radeon/ni.c |3 ++-
drivers/gpu/drm/radeon/r600.c| 28 +++-
drivers/gpu/drm/radeon/radeon_asic.h |2 +-
drivers/gpu/drm/radeon/rv770.c |2 ++
drivers/gpu/drm/radeon/si.c |6 --
7 files changed, 36 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 6dacec4..524db70 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -6194,7 +6194,7 @@ int cik_suspend(struct radeon_device *rdev)
radeon_vm_manager_fini(rdev);
cik_cp_enable(rdev, false);
cik_sdma_enable(rdev, false);
- r600_uvd_rbc_stop(rdev);
+ r600_uvd_stop(rdev);
radeon_uvd_suspend(rdev);
cik_irq_suspend(rdev);
radeon_wb_disable(rdev);
@@ -6358,6 +6358,7 @@ void cik_fini(struct radeon_device *rdev)
radeon_vm_manager_fini(rdev);
radeon_ib_pool_fini(rdev);
radeon_irq_kms_fini(rdev);
+ r600_uvd_stop(rdev);
radeon_uvd_fini(rdev);
cik_pcie_gart_fini(rdev);
r600_vram_scratch_fini(rdev);
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 038dcac..5b98e57 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -5291,10 +5291,10 @@ int evergreen_resume(struct radeon_device *rdev)
int evergreen_suspend(struct radeon_device *rdev)
{
r600_audio_fini(rdev);
+ r600_uvd_stop(rdev);
radeon_uvd_suspend(rdev);
r700_cp_stop(rdev);
r600_dma_stop(rdev);
- r600_uvd_rbc_stop(rdev);
evergreen_irq_suspend(rdev);
radeon_wb_disable(rdev);
evergreen_pcie_gart_disable(rdev);
@@ -5429,6 +5429,7 @@ void evergreen_fini(struct radeon_device *rdev)
radeon_ib_pool_fini(rdev);
radeon_irq_kms_fini(rdev);
evergreen_pcie_gart_fini(rdev);
+ r600_uvd_stop(rdev);
radeon_uvd_fini(rdev);
r600_vram_scratch_fini(rdev);
radeon_gem_fini(rdev);
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 56bd4f3..16e91b0 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -2286,7 +2286,7 @@ int cayman_suspend(struct radeon_device *rdev)
radeon_vm_manager_fini(rdev);
cayman_cp_enable(rdev, false);
cayman_dma_stop(rdev);
- r600_uvd_rbc_stop(rdev);
+ r600_uvd_stop(rdev);
radeon_uvd_suspend(rdev);
evergreen_irq_suspend(rdev);
radeon_wb_disable(rdev);
@@ -2418,6 +2418,7 @@ void cayman_fini(struct radeon_device *rdev)
radeon_vm_manager_fini(rdev);
radeon_ib_pool_fini(rdev);
radeon_irq_kms_fini(rdev);
+ r600_uvd_stop(rdev);
radeon_uvd_fini(rdev);
cayman_pcie_gart_fini(rdev);
r600_vram_scratch_fini(rdev);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 10f712e..0a9553a 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2697,12 +2697,29 @@ int r600_uvd_rbc_start(struct radeon_device *rdev)
return 0;
}
-void r600_uvd_rbc_stop(struct radeon_device *rdev)
+void r600_uvd_stop(struct radeon_device *rdev)
{
struct radeon_ring *ring = &rdev->ring[R600_RING_TYPE_UVD_INDEX];
/* force RBC into idle state */
WREG32(UVD_RBC_RB_CNTL, 0x11010101);
+
+ /* Stall UMC and register bus before resetting VCPU */
+ WREG32_P(UVD_LMI_CTRL2, 1 << 8, ~(1 << 8));
+ WREG32_P(UVD_RB_ARB_CTRL, 1 << 3, ~(1 << 3));
+ mdelay(1);
+
+ /* put VCPU into reset */
+ WREG32(UVD_SOFT_RESET, VCPU_SOFT_RESET);
+ mdelay(5);
+
+ /* disable VCPU clock */
+ WREG32(UVD_VCPU_CNTL, 0x0);
+
+ /* Unstall UMC and register bus */
+ WREG32_P(UVD_LMI_CTRL2, 0, ~(1 << 8));
+ WREG32_P(UVD_RB_ARB_CTRL, 0, ~(1 << 3));
+
ring->ready = false;
}
@@ -2722,6 +2739,11 @@ int r600_uvd_init(struct radeon_device *rdev)
/* disable interupt */
WREG32_P(UVD_MASTINT_EN, 0, ~(1 << 1));
+ /* Stall UMC and register bus before resetting VCPU */
+ WREG32_P(UVD_LMI_CTRL2, 1 << 8, ~(1 << 8));
+ WREG32_P(UVD_RB_ARB_CTRL, 1 << 3, ~(1 << 3));
+ mdelay(1);
+
/* put LMI, VCPU, RBC etc... into reset */
WREG32(UVD_SOFT_RESET, LMI_SOFT_RESET | VCPU_SOFT_RESET |
LBSI_SOFT_RESET | RBC_SOFT_RESET | CSM_SOFT_RESET |
@@ -2751,10 +2773,6 @@ int r600_uvd_init(struct radeon_device *rdev)
RE: [PATCH 3.11-rc3+] radeon: si_dpm: Fix 32 bit __divdi3 modpost failure
I've already got the fix queued in my -fixes branch: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.11&id=1d2867b98372929129c7f2ce2c83a9b446a1b43a > -Original Message- > From: Tim Gardner [mailto:tim.gard...@canonical.com] > Sent: Thursday, August 01, 2013 11:26 AM > To: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org > Cc: Tim Gardner; David Airlie; Deucher, Alexander > Subject: [PATCH 3.11-rc3+] radeon: si_dpm: Fix 32 bit __divdi3 modpost > failure > > ERROR: "__divdi3" [drivers/gpu/drm/radeon/radeon.ko] undefined! > make[3]: *** [__modpost] Error 1 > > gcc version 4.8.1 > > Cc: David Airlie > Cc: Alex Deucher > Signed-off-by: Tim Gardner > --- > drivers/gpu/drm/radeon/si_dpm.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/radeon/si_dpm.c > b/drivers/gpu/drm/radeon/si_dpm.c > index 7ad22e87..4182557 100644 > --- a/drivers/gpu/drm/radeon/si_dpm.c > +++ b/drivers/gpu/drm/radeon/si_dpm.c > @@ -1767,7 +1767,7 @@ static void > si_calculate_leakage_for_v_and_t_formula(const struct ni_leakage_coe > s64 temperature, t_slope, t_intercept, av, bv, t_ref; > s64 tmp; > > - i_leakage = drm_int2fixp(ileakage) / 100; > + i_leakage = div64_s64(drm_int2fixp(ileakage), 100); > vddc = div64_s64(drm_int2fixp(v), 1000); > temperature = div64_s64(drm_int2fixp(t), 1000); > > -- > 1.7.9.5 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix halting UVD
On Thu, Aug 1, 2013 at 11:34 AM, Christian König
wrote:
> From: Christian König
>
> Removing the clock/power or resetting the VCPU can cause
> hangs if that happens in the middle of a register write.
>
> Stall the memory and register bus before putting the VCPU
> into reset. Keep it in reset when unloading the module or
> suspending.
>
> Signed-off-by: Christian König
> Cc: sta...@vger.kernel.org
Applied to my -fixes queue.
Alex
> ---
> drivers/gpu/drm/radeon/cik.c |3 ++-
> drivers/gpu/drm/radeon/evergreen.c |3 ++-
> drivers/gpu/drm/radeon/ni.c |3 ++-
> drivers/gpu/drm/radeon/r600.c| 28 +++-
> drivers/gpu/drm/radeon/radeon_asic.h |2 +-
> drivers/gpu/drm/radeon/rv770.c |2 ++
> drivers/gpu/drm/radeon/si.c |6 --
> 7 files changed, 36 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 6dacec4..524db70 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -6194,7 +6194,7 @@ int cik_suspend(struct radeon_device *rdev)
> radeon_vm_manager_fini(rdev);
> cik_cp_enable(rdev, false);
> cik_sdma_enable(rdev, false);
> - r600_uvd_rbc_stop(rdev);
> + r600_uvd_stop(rdev);
> radeon_uvd_suspend(rdev);
> cik_irq_suspend(rdev);
> radeon_wb_disable(rdev);
> @@ -6358,6 +6358,7 @@ void cik_fini(struct radeon_device *rdev)
> radeon_vm_manager_fini(rdev);
> radeon_ib_pool_fini(rdev);
> radeon_irq_kms_fini(rdev);
> + r600_uvd_stop(rdev);
> radeon_uvd_fini(rdev);
> cik_pcie_gart_fini(rdev);
> r600_vram_scratch_fini(rdev);
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index 038dcac..5b98e57 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -5291,10 +5291,10 @@ int evergreen_resume(struct radeon_device *rdev)
> int evergreen_suspend(struct radeon_device *rdev)
> {
> r600_audio_fini(rdev);
> + r600_uvd_stop(rdev);
> radeon_uvd_suspend(rdev);
> r700_cp_stop(rdev);
> r600_dma_stop(rdev);
> - r600_uvd_rbc_stop(rdev);
> evergreen_irq_suspend(rdev);
> radeon_wb_disable(rdev);
> evergreen_pcie_gart_disable(rdev);
> @@ -5429,6 +5429,7 @@ void evergreen_fini(struct radeon_device *rdev)
> radeon_ib_pool_fini(rdev);
> radeon_irq_kms_fini(rdev);
> evergreen_pcie_gart_fini(rdev);
> + r600_uvd_stop(rdev);
> radeon_uvd_fini(rdev);
> r600_vram_scratch_fini(rdev);
> radeon_gem_fini(rdev);
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index 56bd4f3..16e91b0 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -2286,7 +2286,7 @@ int cayman_suspend(struct radeon_device *rdev)
> radeon_vm_manager_fini(rdev);
> cayman_cp_enable(rdev, false);
> cayman_dma_stop(rdev);
> - r600_uvd_rbc_stop(rdev);
> + r600_uvd_stop(rdev);
> radeon_uvd_suspend(rdev);
> evergreen_irq_suspend(rdev);
> radeon_wb_disable(rdev);
> @@ -2418,6 +2418,7 @@ void cayman_fini(struct radeon_device *rdev)
> radeon_vm_manager_fini(rdev);
> radeon_ib_pool_fini(rdev);
> radeon_irq_kms_fini(rdev);
> + r600_uvd_stop(rdev);
> radeon_uvd_fini(rdev);
> cayman_pcie_gart_fini(rdev);
> r600_vram_scratch_fini(rdev);
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index 10f712e..0a9553a 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -2697,12 +2697,29 @@ int r600_uvd_rbc_start(struct radeon_device *rdev)
> return 0;
> }
>
> -void r600_uvd_rbc_stop(struct radeon_device *rdev)
> +void r600_uvd_stop(struct radeon_device *rdev)
> {
> struct radeon_ring *ring = &rdev->ring[R600_RING_TYPE_UVD_INDEX];
>
> /* force RBC into idle state */
> WREG32(UVD_RBC_RB_CNTL, 0x11010101);
> +
> + /* Stall UMC and register bus before resetting VCPU */
> + WREG32_P(UVD_LMI_CTRL2, 1 << 8, ~(1 << 8));
> + WREG32_P(UVD_RB_ARB_CTRL, 1 << 3, ~(1 << 3));
> + mdelay(1);
> +
> + /* put VCPU into reset */
> + WREG32(UVD_SOFT_RESET, VCPU_SOFT_RESET);
> + mdelay(5);
> +
> + /* disable VCPU clock */
> + WREG32(UVD_VCPU_CNTL, 0x0);
> +
> + /* Unstall UMC and register bus */
> + WREG32_P(UVD_LMI_CTRL2, 0, ~(1 << 8));
> + WREG32_P(UVD_RB_ARB_CTRL, 0, ~(1 << 3));
> +
> ring->ready = false;
> }
>
> @@ -2722,6 +2739,11 @@ int r600_uvd_init(struct radeon_device *rdev)
> /* disable interupt */
> WREG32_P(UVD_MASTINT_EN, 0, ~(1 << 1));
>
> + /* Stall UMC and register bus before resetting VCPU */
> + WREG32_P(UVD_LMI_CTRL2, 1 << 8, ~(1 <
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #51 from Scias --- I just compiled the latest drm-fixes-3.11 and I got back to the starting point (3/4 hangs, messed up/slow X) Trying to figure out why... I was using a 3 days-old drm-fixes-3.11, maybe one of the latest pulls messed it up ? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #52 from Daniel --- Created attachment 83462 --> https://bugs.freedesktop.org/attachment.cgi?id=83462&action=edit vbios for RV620/M82 [Mobility Radeon HD 3450/3470 Just compiled the latest kernel from drm-fixes-3.11, all boots faild 13 out of 13 times. With or without radeon.aspm=0 makes no difference. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #53 from Sergey --- Patch from comment 40 + 'radeon.aspm=0' boot option doesn't change anything. I got: 1 successful boot, 8 hangs, and one boot with slow Xorg. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #54 from Scias --- I reverted to the "old" kernel + Comment 40 patch and it works now. I can't retrieve the git revision as I cleaned the sources but I cloned the drm-fixes-3.11 the 30/7 near 11:30 gmt. I'll try different versions in between with Comment 40 patch to spot the change that cause it to not work anymore. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #55 from Shawn Starr --- Created attachment 83469 --> https://bugs.freedesktop.org/attachment.cgi?id=83469&action=edit Corrupt screen 'frosting' after DPM enabled #1 Corrupt screen 'frosting' after DPM enabled #1 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #56 from Shawn Starr --- Created attachment 83470 --> https://bugs.freedesktop.org/attachment.cgi?id=83470&action=edit Corrupt screen 'frosting' after DPM enabled #2 both screens Corrupt screen 'frosting' after DPM enabled #2 both screens -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 Mace Moneta changed: What|Removed |Added Attachment #83469|text/plain |image/jpeg mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #57 from Shawn Starr --- I have a HD3650 Mobile RV635 and also a HD3650 non-mobile (didn't try DPM on this machine yet). I've attached some screenshots, is this what people are calling 'frosting' or do you you refer to another kind of effect (attach pictures if you can). These pictures came from 3.11 RC2+ w/o the latest changes from Alex. Thanks Shawn -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 Mace Moneta changed: What|Removed |Added Attachment #83470|text/plain |image/jpeg mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: const'ify ioctls table
Because, there is no reason for it not to be const.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
drivers/gpu/drm/gma500/psb_drv.c| 2 +-
drivers/gpu/drm/i810/i810_dma.c | 2 +-
drivers/gpu/drm/i810/i810_drv.h | 2 +-
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/mga/mga_drv.h | 2 +-
drivers/gpu/drm/mga/mga_state.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
drivers/gpu/drm/qxl/qxl_drv.h | 2 +-
drivers/gpu/drm/qxl/qxl_ioctl.c | 2 +-
drivers/gpu/drm/r128/r128_drv.h | 2 +-
drivers/gpu/drm/r128/r128_state.c | 2 +-
drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
drivers/gpu/drm/savage/savage_bci.c | 2 +-
drivers/gpu/drm/savage/savage_drv.h | 2 +-
drivers/gpu/drm/sis/sis_drv.h | 2 +-
drivers/gpu/drm/sis/sis_mm.c| 2 +-
drivers/gpu/drm/via/via_dma.c | 2 +-
drivers/gpu/drm/via/via_drv.h | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
drivers/gpu/host1x/drm/drm.c| 2 +-
drivers/staging/imx-drm/imx-drm-core.c | 2 +-
include/drm/drmP.h | 2 +-
26 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index ca2729a..053cdd0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -213,7 +213,7 @@ static const struct vm_operations_struct
exynos_drm_gem_vm_ops = {
.close = drm_gem_vm_close,
};
-static struct drm_ioctl_desc exynos_ioctls[] = {
+static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MAP_OFFSET,
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index bddea58..ffc9e25 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -131,7 +131,7 @@ static int psb_gamma_ioctl(struct drm_device *dev, void
*data,
static int psb_dpst_bl_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-static struct drm_ioctl_desc psb_ioctls[] = {
+static const struct drm_ioctl_desc psb_ioctls[] = {
DRM_IOCTL_DEF_DRV(GMA_ADB, psb_adb_ioctl, DRM_AUTH),
DRM_IOCTL_DEF_DRV(GMA_MODE_OPERATION, psb_mode_operation_ioctl,
DRM_AUTH),
diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
index ada49ed..eac755b 100644
--- a/drivers/gpu/drm/i810/i810_dma.c
+++ b/drivers/gpu/drm/i810/i810_dma.c
@@ -1241,7 +1241,7 @@ int i810_driver_dma_quiescent(struct drm_device *dev)
return 0;
}
-struct drm_ioctl_desc i810_ioctls[] = {
+const struct drm_ioctl_desc i810_ioctls[] = {
DRM_IOCTL_DEF_DRV(I810_INIT, i810_dma_init,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I810_VERTEX, i810_dma_vertex, DRM_AUTH|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I810_CLEAR, i810_clear_bufs, DRM_AUTH|DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/i810/i810_drv.h b/drivers/gpu/drm/i810/i810_drv.h
index 6e0acad..d4d16ed 100644
--- a/drivers/gpu/drm/i810/i810_drv.h
+++ b/drivers/gpu/drm/i810/i810_drv.h
@@ -125,7 +125,7 @@ extern void i810_driver_preclose(struct drm_device *dev,
extern int i810_driver_device_is_agp(struct drm_device *dev);
extern long i810_ioctl(struct file *file, unsigned int cmd, unsigned long arg);
-extern struct drm_ioctl_desc i810_ioctls[];
+extern const struct drm_ioctl_desc i810_ioctls[];
extern int i810_max_ioctl;
#define I810_BASE(reg) ((unsigned long) \
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 6ce9033..78ad4dc 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1834,7 +1834,7 @@ void i915_driver_postclose(struct drm_device *dev, struct
drm_file *file)
kfree(file_priv);
}
-struct drm_ioctl_desc i915_ioctls[] = {
+const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_INIT, i915_dma_init,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_FLUSH, i915_flush_ioctl, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_FLIP, i915_flip_bufs, DRM_AUTH),
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cef35d3..37d8c92 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1566,7 +1566,7 @@ struct drm_i915_file_private {
#define INTEL_RC6p_ENABLE (1<<1)
#define INTEL_RC6pp_ENABLE (1<<2)
-extern struct drm_ioctl_desc i915_ioctls[];
+extern const struct drm_ioctl_desc i915_ioctls[];
extern int i915_max_ioctl;
extern un
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #58 from Alex Deucher --- I finally found a system I could reproduce it on and I think I've figured it out. Patches momentarily... -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #59 from Alex Deucher --- please try this branch: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.11 after a cold shutdown. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #60 from Hrvoje Senjan --- (In reply to comment #59) > please try this branch: > http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.11 > after a cold shutdown. This seems to have fixed the issues here :-) /sys/kernel/debug/dri/0/radeon_pm_info uvdvclk: 0 dclk: 0 power level 0sclk: 11000 mclk: 4 vddc: 900 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Quick question on DCE8 (HD7770?)
On Qua, 2013-07-31 at 08:25 +0200, Rafał Miłecki wrote: > HI guys, > > I'm looking for the cheapest DCE8 GPU. I know there are 3 > (engineering) families using DCE8: KAVERI, BONAIRE and KABINI. > > The only GPU I know should be DCE8 is HD7790 (not even sure which > engineering family is that). Unfortunately it costs over 120€ here. > > Is there any other DCE8 card available on the market and (hopefully) > cheaper thatn HD7790? Any chance HD7770 is also DCE8? > Hi, DRI devel mailing list have been move to dri-devel@lists.freedesktop.org you may want post your question there . Best regards, -- Sérgio M. B. -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #61 from Hrvoje Senjan --- Created attachment 83472 --> https://bugs.freedesktop.org/attachment.cgi?id=83472&action=edit dmesg snippet with latest patches/successful dpm enabled boot -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Quick question on DCE8 (HD7770?)
2013/8/1 Sérgio Basto : > Hi, DRI devel mailing list have been move to > dri-devel@lists.freedesktop.org you may want post your question there . Thanks, I already did: http://lists.freedesktop.org/archives/dri-devel/2013-July/042583.html -- Rafał -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #62 from Scias --- (In reply to comment #59) > please try this branch: > http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.11 > after a cold shutdown. Working here. I still have the rather minor frost flickering issue and it still hangs if trying to wake up from suspend in the battery state. Actually now it doesn't hang, but it just takes ages to wake up (GPU just keeps soft resetting) and left X in an unuseable state, I still managed to kill X and get the dmesg output when the system was waking up from suspend : http://pastebin.com/UphthyFc . Restarting X afterwards results in unuseable X (and GPU reset loops again), obliged to restart completely. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #63 from Daniel --- Created attachment 83484 --> https://bugs.freedesktop.org/attachment.cgi?id=83484&action=edit successfully booting and waking up from suspend to ram dmesg with dpm=1, RV620/M82 [Mobility Radeon HD 3450/3470 Latest commit works fine here. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #64 from Scias --- (In reply to comment #63) > Created attachment 83484 [details] > successfully booting and waking up from suspend to ram dmesg with dpm=1, > RV620/M82 [Mobility Radeon HD 3450/3470 > > Latest commit works fine here. Yes suspend works fine if the power profile/state isn't set to battery. Try setting the battery state before. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/dpm: implement force performance levels for rs780
2013/8/1 Deucher, Alexander
> > -Original Message-
> > From: Anthoine Bourgeois [mailto:anthoine.bourge...@gmail.com]
> > Sent: Wednesday, July 31, 2013 6:34 PM
> > To: Deucher, Alexander; Koenig, Christian; Jerome Glisse; Anthoine
> > Bourgeois
> > Cc: dri-devel@lists.freedesktop.org
> > Subject: [PATCH] drm/radeon/dpm: implement force performance levels for
> > rs780
> >
> > Allows you to limit the selected power levels via sysfs.
> >
> > Force the feedback divider to select a power level.
>
> Nice work. A few comments below.
>
> Alex
>
> >
> > Signed-off-by: Anthoine Bourgeois
> > ---
> > drivers/gpu/drm/radeon/radeon_asic.c | 1 +
> > drivers/gpu/drm/radeon/radeon_asic.h | 2 ++
> > drivers/gpu/drm/radeon/rs780_dpm.c | 67
> > ++--
> > 3 files changed, 59 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
> > b/drivers/gpu/drm/radeon/radeon_asic.c
> > index f8f8b31..437d357 100644
> > --- a/drivers/gpu/drm/radeon/radeon_asic.c
> > +++ b/drivers/gpu/drm/radeon/radeon_asic.c
> > @@ -1272,6 +1272,7 @@ static struct radeon_asic rs780_asic = {
> > .get_mclk = &rs780_dpm_get_mclk,
> > .print_power_state = &rs780_dpm_print_power_state,
> > .debugfs_print_current_performance_level =
> > &rs780_dpm_debugfs_print_current_performance_level,
> > + .force_performance_level =
> > &rs780_dpm_force_performance_level,
> > },
> > .pflip = {
> > .pre_page_flip = &rs600_pre_page_flip,
> > diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
> > b/drivers/gpu/drm/radeon/radeon_asic.h
> > index 902479f..09841fc 100644
> > --- a/drivers/gpu/drm/radeon/radeon_asic.h
> > +++ b/drivers/gpu/drm/radeon/radeon_asic.h
> > @@ -437,6 +437,8 @@ void rs780_dpm_print_power_state(struct
> > radeon_device *rdev,
> >struct radeon_ps *ps);
> > void rs780_dpm_debugfs_print_current_performance_level(struct
> > radeon_device *rdev,
> > struct seq_file *m);
> > +int rs780_dpm_force_performance_level(struct radeon_device *rdev,
> > + enum radeon_dpm_forced_level level);
> >
> > /* uvd */
> > int r600_uvd_init(struct radeon_device *rdev);
> > diff --git a/drivers/gpu/drm/radeon/rs780_dpm.c
> > b/drivers/gpu/drm/radeon/rs780_dpm.c
> > index d1a1ce7..df58e34 100644
> > --- a/drivers/gpu/drm/radeon/rs780_dpm.c
> > +++ b/drivers/gpu/drm/radeon/rs780_dpm.c
> > @@ -404,6 +404,27 @@ static void rs780_force_voltage_to_high(struct
> > radeon_device *rdev)
> > WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
> > }
> >
> > +static void rs780_force_fbdiv(struct radeon_device *rdev, u32 fb_div)
> > +{
> > + struct igp_ps *current_state = rs780_get_ps(rdev-
> > >pm.dpm.current_ps);
> > +
> > + if ((current_state->sclk_low == fb_div) &&
> > + (current_state->sclk_high == fb_div))
> > + return;
>
> I'm not quite sure what you are checking here.
>
Oh yes, my mistake, fb_div shouldn't be in that condition. In my memory, I
just wanted to check that sclk_low is equal to sclk_high. In that case, no
need to force the fbdiv because there are the same.
>
> > +
> > + WREG32_P(GFX_MACRO_BYPASS_CNTL, SPLL_BYPASS_CNTL,
> > ~SPLL_BYPASS_CNTL);
> > +
> > + WREG32_P(FVTHROT_FBDIV_REG2,
> > FORCED_FEEDBACK_DIV(fb_div),
> > + ~FORCED_FEEDBACK_DIV_MASK);
> > + WREG32_P(FVTHROT_FBDIV_REG1,
> > STARTING_FEEDBACK_DIV(fb_div),
> > + ~STARTING_FEEDBACK_DIV_MASK);
> > + WREG32_P(FVTHROT_FBDIV_REG1, FORCE_FEEDBACK_DIV,
> > ~FORCE_FEEDBACK_DIV);
> > +
> > + udelay(100);
> > +
> > + WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
> > +}
> > +
> > static int rs780_set_engine_clock_scaling(struct radeon_device *rdev,
> > struct radeon_ps *new_ps,
> > struct radeon_ps *old_ps)
> > @@ -432,17 +453,7 @@ static int rs780_set_engine_clock_scaling(struct
> > radeon_device *rdev,
> > if (ret)
> > return ret;
> >
> > - WREG32_P(GFX_MACRO_BYPASS_CNTL, SPLL_BYPASS_CNTL,
> > ~SPLL_BYPASS_CNTL);
> > -
> > - WREG32_P(FVTHROT_FBDIV_REG2,
> > FORCED_FEEDBACK_DIV(max_dividers.fb_div),
> > - ~FORCED_FEEDBACK_DIV_MASK);
> > - WREG32_P(FVTHROT_FBDIV_REG1,
> > STARTING_FEEDBACK_DIV(max_dividers.fb_div),
> > - ~STARTING_FEEDBACK_DIV_MASK);
> > - WREG32_P(FVTHROT_FBDIV_REG1, FORCE_FEEDBACK_DIV,
> > ~FORCE_FEEDBACK_DIV);
> > -
> > - udelay(100);
> > -
> > - WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
> > + rs780_force_fbdiv(rdev, max_dividers.fb_div);
> >
> > if (max_dividers.fb_div > min_dividers.fb_div) {
> > WREG32_P(FVTHROT_FBDIV_REG0,
> > @@ -986,3 +997,37 @@ void
> > rs780_dpm_debugfs_print_current_performance_level(struct
> > radeon_device *rde
[Bug 63599] [r600] SUMO2 GPU lockup CP stall (kernel 3.2.47, 3.4, 3.8, 3.9, 3.10)
https://bugs.freedesktop.org/show_bug.cgi?id=63599 --- Comment #25 from pablow.1...@gmail.com --- Hi. I'm having a similar GPU lockup CP stall on a REDWOOD card. But it doesn't happen at login. With kernels 3.9, 3.10 I can run Xorg, use KDE Kwin effects without any issue; but when I start a game like 0a.d. or Need for Speed Most Wanted under wine, after some time a lockup happens. With kernel 3.11-rc3 lockups occurs while in desktop, little time after login -with or without radeon.dpm set to 1-. Here are two attachments (the two running a kernel 3.10) of dmesg, one with R600_HYPERZ=0 env var set, and the other not (as suggested on another bug). Is there anything else I can help? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63599] [r600] SUMO2 GPU lockup CP stall (kernel 3.2.47, 3.4, 3.8, 3.9, 3.10)
https://bugs.freedesktop.org/show_bug.cgi?id=63599 --- Comment #26 from pablow.1...@gmail.com --- Created attachment 83488 --> https://bugs.freedesktop.org/attachment.cgi?id=83488&action=edit dmesg output from ssh (hyperz enabled) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63599] [r600] SUMO2 GPU lockup CP stall (kernel 3.2.47, 3.4, 3.8, 3.9, 3.10)
https://bugs.freedesktop.org/show_bug.cgi?id=63599 --- Comment #27 from pablow.1...@gmail.com --- Created attachment 83489 --> https://bugs.freedesktop.org/attachment.cgi?id=83489&action=edit dmesg output from ssh (hyperz disabled) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63599] [r600] SUMO2 GPU lockup CP stall (kernel 3.2.47, 3.4, 3.8, 3.9, 3.10)
https://bugs.freedesktop.org/show_bug.cgi?id=63599 --- Comment #28 from Alex Deucher --- (In reply to comment #25) > Hi. I'm having a similar GPU lockup CP stall on a REDWOOD card. But it > doesn't happen at login. With kernels 3.9, 3.10 I can run Xorg, use KDE > Kwin effects without any issue; but when I start a game like 0a.d. or Need > for Speed Most Wanted under wine, after some time a lockup happens. With > kernel 3.11-rc3 lockups occurs while in desktop, little time after login > -with or without radeon.dpm set to 1-. > > Here are two attachments (the two running a kernel 3.10) of dmesg, one with > R600_HYPERZ=0 env var set, and the other not (as suggested on another bug). > > Is there anything else I can help? Please open a different bug. Your issues are not related to this one. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64503] audio glitches when running at 24hz/24p
https://bugs.freedesktop.org/show_bug.cgi?id=64503 --- Comment #19 from Alex Deucher --- does this patch help: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.11&id=dffd4b65ca8989acb914da3c685c798ca5fcf99c -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #65 from Daniel --- Created attachment 83491 --> https://bugs.freedesktop.org/attachment.cgi?id=83491&action=edit wake up from suspend with "battery" radeon_pm_state OK, I know what you mean now, Scias. A few tests here: 1. Setting to "balanced" state, waking up is fast and OK. 5/5 times. 2. Setting to "battery" state, waking up is fast, but with a white screen, the GPU hung. Sometimes I can see and move the cursor, but any other operation cannot be done, e.g. switching to a tty. 4/4 times. I have to shutdown by force. 3. Sometimes when the system booted into X(KDE splash screen), the GPU hung, have to shutdown by force, not very often. 4. Powered by AC or BAT, the state is always "balanced". For the last test, I have a question here: Should it switch from "balanced" to "battery" automatically when I unplug the power cabble or just stay "balanced"? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #66 from Daniel --- Created attachment 83492 --> https://bugs.freedesktop.org/attachment.cgi?id=83492&action=edit could see and move the cursor, also waking up from suspend with "battery" state -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60523] Lockup with radeon DPM on Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #12 from Alex Deucher --- Do you have any sort of background animations, compute jobs, or anything like that running? I have a very similar 5770, and I can't reproduce the issue. The multi-monitor state works fine here. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #67 from Alex Deucher --- (In reply to comment #65) > For the last test, I have a question here: > Should it switch from "balanced" to "battery" automatically when I unplug > the power cabble or just stay "balanced"? There is no automatic switching, you need to select the state you want via sysfs: /sys/class/drm/card0/device/power_dpm_state Since it's a policy decision, I leave it to userspace (some users want to switch to battery state others want to stay in performance/balanced). You can have a script listen for ac plug events and select a different state depending on what you want it to do. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #68 from Alex Deucher --- In the short term until we sort out why the battery state causes resume problems, you can select balanced or performance state in your suspend script. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #69 from Hrvoje Senjan --- (In reply to comment #60) > (In reply to comment #59) > > please try this branch: > > http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.11 > > after a cold shutdown. > > This seems to have fixed the issues here :-) > Works correctly only on cold boot. With reboots i get: [ 52.630102] radeon :01:00.0: GPU lockup CP stall for more than 27055msec [ 52.630115] radeon :01:00.0: GPU lockup (waiting for 0x0058 last fence id 0x0001) [ 52.993495] radeon :01:00.0: Saved 2809 dwords of commands on ring 0. [ 52.993508] radeon :01:00.0: GPU softreset: 0x0348 [ 52.993511] radeon :01:00.0: R_008010_GRBM_STATUS = 0xA0003030 [ 52.993514] radeon :01:00.0: R_008014_GRBM_STATUS2 = 0x0003 [ 52.993517] radeon :01:00.0: R_000E50_SRBM_STATUS = 0x200291C0 [ 52.993520] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [ 52.993523] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x [ 52.993526] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x0802 [ 52.993528] radeon :01:00.0: R_008680_CP_STAT = 0x80C1 [ 52.993531] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 53.369474] radeon :01:00.0: Wait for MC idle timedout ! [ 53.369478] radeon :01:00.0: R_008020_GRBM_SOFT_RESET=0x4001 [ 53.369532] radeon :01:00.0: SRBM_SOFT_RESET=0x00022500 [ 53.371674] radeon :01:00.0: R_008010_GRBM_STATUS = 0xA0003030 [ 53.371677] radeon :01:00.0: R_008014_GRBM_STATUS2 = 0x0003 [ 53.371680] radeon :01:00.0: R_000E50_SRBM_STATUS = 0x200210C0 [ 53.371683] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [ 53.371685] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x [ 53.371688] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x [ 53.371691] radeon :01:00.0: R_008680_CP_STAT = 0x8010 [ 53.371694] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 53.371700] radeon :01:00.0: GPU reset succeeded, trying to resume [ 53.536342] [drm] PCIE GART of 512M enabled (table at 0x0004). [ 53.536389] radeon :01:00.0: WB enabled [ 53.536393] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x2c00 and cpu addr 0x880137055c00 [ 53.536396] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x2c0c and cpu addr 0x880137055c0c [ 53.734069] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD) [ 53.734073] [drm:r600_resume] *ERROR* r600 startup failed on resume [ 53.736171] switching from power state: [ 53.736176] ui class: none [ 53.736180] internal class: boot [ 53.736184] caps: video [ 53.736189] uvdvclk: 0 dclk: 0 [ 53.736193] power level 0sclk: 6 mclk: 5 vddc: 1100 [ 53.736196] power level 1sclk: 6 mclk: 5 vddc: 1100 [ 53.736199] power level 2sclk: 6 mclk: 5 vddc: 1100 [ 53.736201] status: c b [ 53.736206] switching to power state: [ 53.736208] ui class: performance [ 53.736210] internal class: none [ 53.736214] caps: single_disp video [ 53.736219] uvdvclk: 0 dclk: 0 [ 53.736223] power level 0sclk: 11000 mclk: 4 vddc: 900 [ 53.736226] power level 1sclk: 3 mclk: 4 vddc: 900 [ 53.736229] power level 2sclk: 6 mclk: 5 vddc: 1100 [ 53.736231] status: r [ 60.620870] SysRq : Keyboard mode set to system default SysRQ + R,I brings back normal display -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60523] Lockup with radeon DPM on Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #13 from Tobias Droste --- The only active component is kwin with compositing. But even if I disable compositing and don't touch the mouse or keyboard for a while the state doesn't change. I also doubt that's the problem because # echo high > power_dpm_force_performance_level gives bash: echo: write error: Invalid argument with 2 monitors attached and works fine with 1 monitor. Maybe a weird bug in the bios? But the card works fine with catalyst in windows. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag
Hi Vikas,
On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
> connected with resolution 2560x1600, following error occured even with
> IOMMU enabled:
> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
> buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>
> This patch fixes the issue by adding a check for IOMMU.
>
> Signed-off-by: Vikas Sajjan
> Signed-off-by: Arun Kumar
> ---
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a8
> 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> #include "exynos_drm_drv.h"
> #include "exynos_drm_fb.h"
> @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct
> drm_fb_helper *helper, struct platform_device *pdev = dev->platformdev;
> unsigned long size;
> int ret;
> + unsigned int flag;
>
> DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
> sizes->surface_width, sizes->surface_height,
> @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
> drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
>
> /* 0 means to allocate physically continuous memory */
> - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
> + if (!is_drm_iommu_supported(dev))
> + flag = 0;
> + else
> + flag = EXYNOS_BO_NONCONTIG;
While noncontig memory might be used for devices that support IOMMU, there
should be no problem with using contig memory for them, so this seems more
like masking the original problem rather than tracking it down.
Could you check why the allocation fails when requesting contiguous
memory?
Best regards,
Tomasz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #70 from Sergey --- Works good for me: Major: 5 of 5 boots after shutdown. 5 of 5 boots after reboot. First boot after shutdown hanged though. Suspend: Works always for me 10 of 10. Checked different states. Hibernate: Works most of the time but sometimes hangs. Have seen a lot hangs on 'battery' state. But last boot to confirm worked fine 2 times. 2 hangs in default 'balanced' mode. After this hangs got 2-3 hangs in a row after shutdowns. Minor: If I run 'glxgear' hibernate resumes with slow Xorg, sometimes dies after resume. Same works with suspend. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag
On Thu, Aug 1, 2013 at 7:20 PM, Tomasz Figa wrote:
> Hi Vikas,
>
> On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
>> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
>> connected with resolution 2560x1600, following error occured even with
>> IOMMU enabled:
>> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
>> buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>>
>> This patch fixes the issue by adding a check for IOMMU.
>>
>> Signed-off-by: Vikas Sajjan
>> Signed-off-by: Arun Kumar
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a8
>> 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> @@ -16,6 +16,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "exynos_drm_drv.h"
>> #include "exynos_drm_fb.h"
>> @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct
>> drm_fb_helper *helper, struct platform_device *pdev = dev->platformdev;
>> unsigned long size;
>> int ret;
>> + unsigned int flag;
>>
>> DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
>> sizes->surface_width, sizes->surface_height,
>> @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
>> drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
>>
>> /* 0 means to allocate physically continuous memory */
>> - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
>> + if (!is_drm_iommu_supported(dev))
>> + flag = 0;
>> + else
>> + flag = EXYNOS_BO_NONCONTIG;
>
> While noncontig memory might be used for devices that support IOMMU, there
> should be no problem with using contig memory for them, so this seems more
> like masking the original problem rather than tracking it down.
it is probably a good idea to not require contig memory when it is not
needed for performance or functionality (and if it is only
performance, then fallback gracefully to non-contig).. but yeah, would
be good to know if this is masking another issue all the same
BR,
-R
> Could you check why the allocation fails when requesting contiguous
> memory?
>
> Best regards,
> Tomasz
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: CPU: 1 PID: 2846 at drivers/gpu/drm/i915/intel_sdvo.c:1378
This one may have been going on for some time - I haven't updated the old Intel Mac Mini in a while. And by "not updated" I also mean that it's some really old user-space: the machine is running F14, and cannot be updated to anything newer without having to reinstall everything because of a stupid small /boot partition. So it's not going to happen. But maybe somebody cares about the i915 warning anyway? Linus --- WARNING: CPU: 1 PID: 2846 at drivers/gpu/drm/i915/intel_sdvo.c:1378 intel_sdvo_get_config+0x158/0x160() SDVO pixel multiplier mismatch, port: 0, encoder: 1 Modules linked in: snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep CPU: 1 PID: 2846 Comm: Xorg Not tainted 3.11.0-rc3-00208-gbe1e8d7-dirty #19 Hardware name: Apple Computer, Inc. Macmini1,1/Mac-F4208EC8, BIOS MM11.88Z.0055.B03.0604071521 04/07/06 ef0afa54 c1597bbb c1737ea4 ef0afa84 c10392ca c1737e6c ef0afab0 0b1e c1737ea4 0562 c12dfbe8 c12dfbe8 ef0afb14 f697ec00 ef0afa9c c103936e 0009 ef0afa94 c1737e6c ef0afab0 ef0afadc Call Trace: [] dump_stack+0x41/0x56 [] warn_slowpath_common+0x7a/0xa0 [] warn_slowpath_fmt+0x2e/0x30 [] intel_sdvo_get_config+0x158/0x160 [] check_crtc_state+0x1e0/0xb10 [] intel_modeset_check_state+0x29d/0x7c0 [] intel_sdvo_dpms+0x5c/0xa0 [] drm_mode_obj_set_property_ioctl+0x40e/0x420 [] drm_mode_connector_property_set_ioctl+0x35/0x40 [] drm_ioctl+0x3e4/0x540 [] do_vfs_ioctl+0x72/0x570 [] SyS_ioctl+0x8f/0xa0 [] sysenter_do_call+0x12/0x22 ---[ end trace 7ce940aff1366d60 ]--- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Update][PATCH 0/3] Fix backlight issues on some Windows 8 systems
On Wed, 2013-07-31 at 02:01 +0200, Rafael J. Wysocki wrote: > On Thursday, July 18, 2013 02:16:09 AM Rafael J. Wysocki wrote: > > On Sunday, June 09, 2013 07:01:36 PM Matthew Garrett wrote: > > > Windows 8 introduced new policy for backlight control by pushing it out to > > > graphics drivers. This appears to have coincided with a range of vendors > > > adding Windows 8 checks to their backlight control code which trigger > > > either > > > awkward behaviour (Lenovo) or complete brokenness (some Dells). The > > > simplest > > > thing to do would be to just disable ACPI backlight control entirely if > > > the > > > firmware indicates Windows 8 support, but it's entirely possible that > > > individual graphics drivers might still make use of the ACPI > > > functionality in > > > preference to native control. > > > > > > The first two patches in this series are picked from other patchesets > > > aimed at > > > solving similar problems. The last simply unregisters ACPI backlight > > > control > > > on Windows 8 systems when using an Intel GPU. Similar code could be added > > > to > > > other drivers, but I'm reluctant to do so without further investigation as > > > to the behaviour of the vendor drivers under Windows. > > > > Well, after some more time spent on that, we now have a series of 3 patches > > (different from the $subject one) that we think may be used to address this > > issue. As far as I can say, it has been tested by multiple people whose > > systems have those problems and they generally saw improvement. > > > > It is not my ideal approach, but it seems to be the least intrusive and/or > > with the least amount of possible side effects that we can do right now > > as a general measure (alternatively, we could create a possibly long > > blacklist table of affected systems with different workarounds for them, > > but let's just say that is not overwhelmingly attractive). > > > > [1/3] Make ACPICA export things that we need for checking OSI(Win8). > > > > [2/3] Make acpi_video_device_find_cap() call acpi_video_init_brightness() > > even > > if it is not going to register the backlight interface (needed for > > Thinkpads). > > > > [3/3] Avoid using ACPI backlight if i915 is in use and the firmware believes > > we are Windows 8. > > > > Many thanks to everyone involved! > > So this didn't work, as we had to revert [3/3], but I think we should try to > make some progress with this nevertheless. A way forward I'm seeing now could > be to > (1) Split the ACPI video driver so that it is possible to register the > backlight control separately from the event interface. > (2) Add a command line option to i915 to make it use the native backlight > control (without registering the ACPI one) if set. Make unset the > default initially. > (3) Fix i915 backlight control issues for all systems known to have them > (that may take a while) and flip the defailt for that option to set when > we > think we're ready. > (4) If there still are problem reports, flip the default back to unset and > repeat (3). > > If this converges, everyone will be using the native backlight control by > default and the original problem will go away automatically. > > Thoughts? > > Rafael > > Good idea. I have 3-4 laptops with this problem. I can test, but I don't have devices, on which found regressions (in backlight) in previous patch. -- Igor Gnatenko Fedora release 19 (Schrödinger’s Cat) Linux 3.10.3-300.fc19.x86_64 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Update][PATCH 0/3] Fix backlight issues on some Windows 8 systems
On 07/31/2013 08:01 AM, Rafael J. Wysocki wrote: > On Thursday, July 18, 2013 02:16:09 AM Rafael J. Wysocki wrote: >> On Sunday, June 09, 2013 07:01:36 PM Matthew Garrett wrote: >>> Windows 8 introduced new policy for backlight control by pushing it out to >>> graphics drivers. This appears to have coincided with a range of vendors >>> adding Windows 8 checks to their backlight control code which trigger either >>> awkward behaviour (Lenovo) or complete brokenness (some Dells). The simplest >>> thing to do would be to just disable ACPI backlight control entirely if the >>> firmware indicates Windows 8 support, but it's entirely possible that >>> individual graphics drivers might still make use of the ACPI functionality >>> in >>> preference to native control. >>> >>> The first two patches in this series are picked from other patchesets aimed >>> at >>> solving similar problems. The last simply unregisters ACPI backlight control >>> on Windows 8 systems when using an Intel GPU. Similar code could be added to >>> other drivers, but I'm reluctant to do so without further investigation as >>> to the behaviour of the vendor drivers under Windows. >> >> Well, after some more time spent on that, we now have a series of 3 patches >> (different from the $subject one) that we think may be used to address this >> issue. As far as I can say, it has been tested by multiple people whose >> systems have those problems and they generally saw improvement. >> >> It is not my ideal approach, but it seems to be the least intrusive and/or >> with the least amount of possible side effects that we can do right now >> as a general measure (alternatively, we could create a possibly long >> blacklist table of affected systems with different workarounds for them, >> but let's just say that is not overwhelmingly attractive). >> >> [1/3] Make ACPICA export things that we need for checking OSI(Win8). >> >> [2/3] Make acpi_video_device_find_cap() call acpi_video_init_brightness() >> even >> if it is not going to register the backlight interface (needed for >> Thinkpads). >> >> [3/3] Avoid using ACPI backlight if i915 is in use and the firmware believes >> we are Windows 8. >> >> Many thanks to everyone involved! > > So this didn't work, as we had to revert [3/3], but I think we should try to > make some progress with this nevertheless. A way forward I'm seeing now could > be to > (1) Split the ACPI video driver so that it is possible to register the > backlight control separately from the event interface. > (2) Add a command line option to i915 to make it use the native backlight > control (without registering the ACPI one) if set. Make unset the > default initially. > (3) Fix i915 backlight control issues for all systems known to have them > (that may take a while) and flip the defailt for that option to set when > we > think we're ready. > (4) If there still are problem reports, flip the default back to unset and > repeat (3). > > If this converges, everyone will be using the native backlight control by > default and the original problem will go away automatically. > > Thoughts? Sounds good to me. -Aaron ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues
2013/7/30 Markus Trippelsdorf : > > I begin to wonder if: > [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD) > is an simple initialization bug that doesn't directly depend on kexec at > all. > > -- > Markus I bet on this (because I see the same error in another context) -- --joshua ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/gem: fix mmap vma size calculations
On Wed, Jul 31, 2013 at 6:46 PM, David Herrmann wrote: > Hi > > On Tue, Jul 30, 2013 at 9:52 AM, Sedat Dilek wrote: >> On Tue, Jul 30, 2013 at 9:41 AM, Sedat Dilek wrote: >>> On Fri, Jul 26, 2013 at 10:15 PM, Daniel Vetter wrote: On Fri, Jul 26, 2013 at 12:09:32PM +0200, David Herrmann wrote: > The VMA manager is page-size based so drm_vma_node_size() returns the size > in pages. However, drm_gem_mmap_obj() requires the size in bytes. Apply > PAGE_SHIFT so we no longer get EINVAL during mmaps due to too small > buffers. > > This bug was introduced in commit: > 0de23977cfeb5b357ec884ba15417ae118ff9e9b > "drm/gem: convert to new unified vma manager" > > Fixes i915 gtt mmap failure reported by Sedat Dilek in: > Re: linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ] > > Cc: Daniel Vetter > Cc: Chris Wilson > Signed-off-by: David Herrmann > Reported-by: Sedat Dilek > Tested-by: Sedat Dilek I remember that I even checked whether v4 was consistent with pages vs. bytes ;-) So >>> >>> Hi David, Daniel, and Dave, >>> >>> Just reading quickly "drm: add unified vma offset manager"... is that >>> below in the docs? >>> >>> "The VMA manager is page-size based so drm_vma_node_size() returns the size >>> in pages. However, drm_gem_mmap_obj() requires the size in bytes. Apply >>> PAGE_SHIFT so we no longer get EINVAL during mmaps due to too small >>> buffers." >>> >>> If not, do you mind adding it? >>> >> >> To quote this two: >> >> [ include/drm/drm_vma_manager.h ] >> >> /** >> * drm_vma_node_size() - Return size (page-based) >> * @node: Node to inspect >> * >> * Return the size as number of pages for the given node. This is the same >> size >> * that was passed to drm_vma_offset_add(). If no offset is allocated for the >> * node, this is 0. >> * >> * RETURNS: >> * Size of @node as number of pages. 0 if the node does not have an offset >> * allocated. >> */ >> >> [ drivers/gpu/drm/drm_gem.c ] > > It's actually "drm_gem_mmap_obj" which we have to look at and it says: > * @obj_size: the object size to be mapped, in bytes > > So both are already documented. > Good. I had only a quick view, you are the expert. > Regards > David > >> /** >> * drm_gem_mmap - memory map routine for GEM objects >> * @filp: DRM file pointer >> * @vma: VMA for the area to be mapped >> * >> * If a driver supports GEM object mapping, mmap calls on the DRM file >> * descriptor will end up here. >> * >> * Look up the GEM object based on the offset passed in (vma->vm_pgoff will >> * contain the fake offset we created when the GTT map ioctl was called on >> * the object) and map it with a call to drm_gem_mmap_obj(). >> */ >> >> - Sedat - >> >>> Thanks in advance! >>> >>> - Sedat - >>> Reviewed-by: Daniel Vetter on this little fixup. -Daniel > --- > drivers/gpu/drm/drm_gem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > index 3613b50..1f76572 100644 > --- a/drivers/gpu/drm/drm_gem.c > +++ b/drivers/gpu/drm/drm_gem.c > @@ -666,7 +666,7 @@ int drm_gem_mmap(struct file *filp, struct > vm_area_struct *vma) > } > > obj = container_of(node, struct drm_gem_object, vma_node); > - ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node), vma); > + ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node) << PAGE_SHIFT, > vma); > > mutex_unlock(&dev->struct_mutex); > > -- > 1.8.3.4 > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] drm/tilcdc drm/i2c/tda998x workaround for sync issues on TI SoC
On 07/25/2013 09:32 PM, Rob Clark wrote: On Thu, Jul 25, 2013 at 2:32 PM, Darren Etheridge wrote: [...] This patch set inverts the hsync signal coming from the tilcdc so the NXP is kept happy and then shifts the output to the right to compensate for the sync timing issues. Display modes from the NXP have been verified using a HDMI analyzer and are reporting correct timings at the output stage. Hopefully this will allow the dove/tda driver changes to progress now that were blocked as per this discussion: http://lists.freedesktop.org/archives/dri-devel/2013-July/040900.html Good find Darren! The patches look good to me from a quick review. It would be good to get a tested-by from someone on cubox, but it is good that we finally found the issue so that we can unblock further tda998x development. Darren, I now fully understand the issues of AM335x's LCD controller and your fix for it. I suggest to clarify the comments you added to tilcdc to allow others to understand it more quickly. Actually, the LCD controller always aligns vsync to the second edge of hsync, which will never give VESA-compliant sync. The (elegant) workaround you are proposing is to align both rising edges, so at least TDA998x can sync on those with some hskew added. Lucky you that it ignores hsync length but only looks for rising HS/VS edges ;) Should we prepare a new patch set comprising the following patches? Russell King: drm/i2c: nxp-tda998x: fix EDID reading on TDA19988 devices drm/i2c: nxp-tda998x: ensure VIP output mux is properly set drm/i2c: nxp-tda998x: fix npix/nline programming drm/i2c: nxp-tda998x: prepare for video input configuration drm/i2c: nxp-tda998x: add video and audio input configuration Sebastian Hesselbarth: drm/i2c: tda998x: fix sync generation and calculation Darren Etheridge: drm/i2c/tda998x prepare for tilcdc sync workaround drm/tilcdc fixup mode to workaound sync for tda998x Or do we keep them separated and possibly resend them if David cannot find them anymore? Sebastian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] drm/tilcdc drm/i2c/tda998x workaround for sync issues on TI SoC
On Wed, Jul 31, 2013 at 10:21:20PM +0200, Sebastian Hesselbarth wrote: > Should we prepare a new patch set comprising the following patches? > > Russell King: > drm/i2c: nxp-tda998x: fix EDID reading on TDA19988 devices > drm/i2c: nxp-tda998x: ensure VIP output mux is properly set > drm/i2c: nxp-tda998x: fix npix/nline programming > drm/i2c: nxp-tda998x: prepare for video input configuration > drm/i2c: nxp-tda998x: add video and audio input configuration > > Sebastian Hesselbarth: > drm/i2c: tda998x: fix sync generation and calculation Unless you've changed this one since I tested it, it needs fixes which basically revert the vsync changes back to the original code. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/dpm: implement force performance levels for rs780
Allows you to limit the selected power levels via sysfs.
Force the feedback divider to select a power level.
Signed-off-by: Anthoine Bourgeois
---
drivers/gpu/drm/radeon/radeon_asic.c | 1 +
drivers/gpu/drm/radeon/radeon_asic.h | 2 ++
drivers/gpu/drm/radeon/rs780_dpm.c | 67 ++--
3 files changed, 59 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index f8f8b31..437d357 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1272,6 +1272,7 @@ static struct radeon_asic rs780_asic = {
.get_mclk = &rs780_dpm_get_mclk,
.print_power_state = &rs780_dpm_print_power_state,
.debugfs_print_current_performance_level =
&rs780_dpm_debugfs_print_current_performance_level,
+ .force_performance_level = &rs780_dpm_force_performance_level,
},
.pflip = {
.pre_page_flip = &rs600_pre_page_flip,
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index 902479f..09841fc 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -437,6 +437,8 @@ void rs780_dpm_print_power_state(struct radeon_device *rdev,
struct radeon_ps *ps);
void rs780_dpm_debugfs_print_current_performance_level(struct radeon_device
*rdev,
struct seq_file *m);
+int rs780_dpm_force_performance_level(struct radeon_device *rdev,
+ enum radeon_dpm_forced_level level);
/* uvd */
int r600_uvd_init(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/rs780_dpm.c
b/drivers/gpu/drm/radeon/rs780_dpm.c
index d1a1ce7..df58e34 100644
--- a/drivers/gpu/drm/radeon/rs780_dpm.c
+++ b/drivers/gpu/drm/radeon/rs780_dpm.c
@@ -404,6 +404,27 @@ static void rs780_force_voltage_to_high(struct
radeon_device *rdev)
WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
}
+static void rs780_force_fbdiv(struct radeon_device *rdev, u32 fb_div)
+{
+ struct igp_ps *current_state = rs780_get_ps(rdev->pm.dpm.current_ps);
+
+ if ((current_state->sclk_low == fb_div) &&
+ (current_state->sclk_high == fb_div))
+ return;
+
+ WREG32_P(GFX_MACRO_BYPASS_CNTL, SPLL_BYPASS_CNTL, ~SPLL_BYPASS_CNTL);
+
+ WREG32_P(FVTHROT_FBDIV_REG2, FORCED_FEEDBACK_DIV(fb_div),
+~FORCED_FEEDBACK_DIV_MASK);
+ WREG32_P(FVTHROT_FBDIV_REG1, STARTING_FEEDBACK_DIV(fb_div),
+~STARTING_FEEDBACK_DIV_MASK);
+ WREG32_P(FVTHROT_FBDIV_REG1, FORCE_FEEDBACK_DIV, ~FORCE_FEEDBACK_DIV);
+
+ udelay(100);
+
+ WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
+}
+
static int rs780_set_engine_clock_scaling(struct radeon_device *rdev,
struct radeon_ps *new_ps,
struct radeon_ps *old_ps)
@@ -432,17 +453,7 @@ static int rs780_set_engine_clock_scaling(struct
radeon_device *rdev,
if (ret)
return ret;
- WREG32_P(GFX_MACRO_BYPASS_CNTL, SPLL_BYPASS_CNTL, ~SPLL_BYPASS_CNTL);
-
- WREG32_P(FVTHROT_FBDIV_REG2, FORCED_FEEDBACK_DIV(max_dividers.fb_div),
-~FORCED_FEEDBACK_DIV_MASK);
- WREG32_P(FVTHROT_FBDIV_REG1, STARTING_FEEDBACK_DIV(max_dividers.fb_div),
-~STARTING_FEEDBACK_DIV_MASK);
- WREG32_P(FVTHROT_FBDIV_REG1, FORCE_FEEDBACK_DIV, ~FORCE_FEEDBACK_DIV);
-
- udelay(100);
-
- WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
+ rs780_force_fbdiv(rdev, max_dividers.fb_div);
if (max_dividers.fb_div > min_dividers.fb_div) {
WREG32_P(FVTHROT_FBDIV_REG0,
@@ -986,3 +997,37 @@ void
rs780_dpm_debugfs_print_current_performance_level(struct radeon_device *rde
seq_printf(m, "power level 1sclk: %u vddc_index: %d\n",
ps->sclk_high, ps->max_voltage);
}
+
+int rs780_dpm_force_performance_level(struct radeon_device *rdev,
+ enum radeon_dpm_forced_level level)
+{
+ struct radeon_ps *rps = rdev->pm.dpm.current_ps;
+ struct igp_ps *ps = rs780_get_ps(rps);
+ struct atom_clock_dividers min_dividers, max_dividers;
+ int ret;
+
+ rs780_clk_scaling_enable(rdev, false);
+
+ if (level == RADEON_DPM_FORCED_LEVEL_HIGH) {
+ ret = radeon_atom_get_clock_dividers(rdev,
COMPUTE_ENGINE_PLL_PARAM,
+ps->sclk_high, false,
&max_dividers);
+ if (ret)
+ return ret;
+
+ rs780_force_fbdiv(rdev, max_dividers.fb_div);
+ } else if (level == RADEON_DPM_FORCED_LEVEL_LOW) {
+ ret = radeon_atom_get_clock_dividers(rdev,
COMPUTE_ENGINE_PLL_PARAM,
+
Re: i915 backlight
On 08/01/2013 12:36 AM, Borislav Petkov wrote: > On Wed, Jul 31, 2013 at 06:22:52PM +0200, Borislav Petkov wrote: >> Dudes, >> >> has anyone already reported this (happens on Linus of today + >> tip/master): > > Oh, one more thing: I can't control the backlight anymore on this x230 > with the Fn-Fx keys and this is most probably related to that recent > backlight revert story. If there is a new approach I can test, please > let me know. Can you please run acpi_listen and then press the Fn-Fx key, see if the events are correctly sent out? > > Btw, it worked before on this machine with "acpi_backlight=vendor" on > the cmdline. >From the bug page: https://bugzilla.kernel.org/show_bug.cgi?id=51231#c80 I got the impression that both the acpi_video interface and the vendor interface thinkpad_screen are broken. So adding this cmdline here works suggests that either thinkpad_screen works or thinkpad vendor driver doesn't get loaded or doesn't create that interface for some reason. Alternatively, if the intel_backlight interface works(highly possible), you can use xorg.conf to specify the that backlight interface for X. Section "Device" Option "Backlight" "intel_backlight" Identifier "Card0" Driver "intel" BusID "PCI:0:2:0" EndSection Thanks, Aaron ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915 backlight
On 08/01/2013 04:12 PM, Borislav Petkov wrote: > On Thu, Aug 01, 2013 at 09:13:35AM +0800, Aaron Lu wrote: >> Can you please run acpi_listen and then press the Fn-Fx key, see if the >> events are correctly sent out? > > Like this? > > # acpi_listen > video/brightnessdown BRTDN 0087 > video/brightnessup BRTUP 0086 > video/brightnessdown BRTDN 0087 > video/brightnessup BRTUP 0086 > video/brightnessdown BRTDN 0087 > video/brightnessup BRTUP 0086 > video/brightnessdown BRTDN 0087 > video/brightnessup BRTUP 0086 > video/brightnessdown BRTDN 0087 > ^C Yes, so the event is correctly sent out. > >> From the bug page: >> https://bugzilla.kernel.org/show_bug.cgi?id=51231#c80 >> I got the impression that both the acpi_video interface and the vendor >> interface thinkpad_screen are broken. So adding this cmdline here works >> suggests that either thinkpad_screen works or thinkpad vendor driver >> doesn't get loaded or doesn't create that interface for some reason. >> >> Alternatively, if the intel_backlight interface works(highly possible), >> you can use xorg.conf to specify the that backlight interface for X. >> >> Section "Device" >> Option "Backlight" "intel_backlight" >> Identifier "Card0" >> Driver "intel" >> BusID "PCI:0:2:0" >> EndSection > > Yeah, that didn't work *but* manually writing to both: > > /sys/class/backlight/acpi_video0/brightness > > and > > /sys/class/backlight/intel_backlight/brightness > > works. Err...we have the event sent out on hotkey press and the interface also works, but still, using hotkey to adjust brightness level is broken... I just found an old acer laptop that has similar issue(or even worse: on X starts, an almost black screen is shown and hotkey adjust doesn't work), I'll look into this. > > The ranges are different, though: > > intel_backlight/actual_brightness:1000 > intel_backlight/bl_power:0 > intel_backlight/brightness:1000 > intel_backlight/max_brightness:4437 > intel_backlight/type:raw > > acpi_video0/actual_brightness:41 > acpi_video0/bl_power:0 > acpi_video0/brightness:41 > acpi_video0/max_brightness:100 > acpi_video0/type:firmware Yes, different interface has different brightness ranges and a value in one range may turn out to be the same actual brightness level of another value in another range. > > I guess I need to write me a dirty script for now ... :-) :-) > > Thanks guys. > Thanks, Aaron ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag
While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
connected with resolution 2560x1600, following error occured even with
IOMMU enabled:
[0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer.
[0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
This patch fixes the issue by adding a check for IOMMU.
Signed-off-by: Vikas Sajjan
Signed-off-by: Arun Kumar
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 8e60bd6..2a8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "exynos_drm_drv.h"
#include "exynos_drm_fb.h"
@@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
*helper,
struct platform_device *pdev = dev->platformdev;
unsigned long size;
int ret;
+ unsigned int flag;
DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
sizes->surface_width, sizes->surface_height,
@@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
*helper,
size = mode_cmd.pitches[0] * mode_cmd.height;
/* 0 means to allocate physically continuous memory */
- exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
+ if (!is_drm_iommu_supported(dev))
+ flag = 0;
+ else
+ flag = EXYNOS_BO_NONCONTIG;
+
+ exynos_gem_obj = exynos_drm_gem_create(dev, flag, size);
if (IS_ERR(exynos_gem_obj)) {
ret = PTR_ERR(exynos_gem_obj);
goto err_release_framebuffer;
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau/acpi: de-dup use of DSM methods
Observe that nouveau_optimus_dsm and nouveau_dsm are equal except for
the parameters handling (UUID, revision ID and function arguments). The
function arguments are passed as Buffer in the "optimus dsm" and Integer
in "nvidia dsm". As buffers are implicitly converted to integers, merge
both functions.
The ACPI spec defines the fourth parameter (Arg3 a.k.a. "function
arguments") as Package, but many BIOSes expect a Buffer instead. For
instance, for the "nvidia DSM", the Lenovo T410s uses CreateByteField on
Arg3 which does not work with a package. The Clevo B7130 does something
similar for the "Optimus DSM". Unfortunately, this means that the
following ACPI warning (introduced with 29a241c) cannot be fixed (when
toggling power or muxing):
ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found
[Buffer], ACPI requires [Package] (20130517/nsarguments-95)
ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found
[Buffer], ACPI requires [Package] (20130517/nsarguments-95)
ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found
[Buffer], ACPI requires [Package] (20130517/nsarguments-95)
ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found
[Buffer], ACPI requires [Package] (20130517/nsarguments-95)
Signed-off-by: Peter Wu
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 67 ++
1 file changed, 20 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index d97f200..a75684f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -46,6 +46,9 @@ bool nouveau_is_v1_dsm(void) {
#define NOUVEAU_DSM_HAS_MUX 0x1
#define NOUVEAU_DSM_HAS_OPT 0x2
+#define NOUVEAU_DSM_REVID_NVIDIA 0x102
+#define NOUVEAU_DSM_REVID_OPTIMUS 0x100
+
static const char nouveau_dsm_muid[] = {
0xA0, 0xA0, 0x95, 0x9D, 0x60, 0x00, 0x48, 0x4D,
0xB3, 0x4D, 0x7E, 0x5F, 0xEA, 0x12, 0x9F, 0xD4,
@@ -56,7 +59,8 @@ static const char nouveau_op_dsm_muid[] = {
0xA7, 0x2B, 0x60, 0x42, 0xA6, 0xB5, 0xBE, 0xE0,
};
-static int nouveau_optimus_dsm(acpi_handle handle, int func, int arg, uint32_t
*result)
+static int nouveau_call_dsm(acpi_handle handle, const char *uuid, int revid,
+ int func, int arg, uint32_t *result)
{
struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
struct acpi_object_list input;
@@ -68,12 +72,15 @@ static int nouveau_optimus_dsm(acpi_handle handle, int
func, int arg, uint32_t *
input.count = 4;
input.pointer = params;
params[0].type = ACPI_TYPE_BUFFER;
- params[0].buffer.length = sizeof(nouveau_op_dsm_muid);
- params[0].buffer.pointer = (char *)nouveau_op_dsm_muid;
+ params[0].buffer.length = 16;
+ params[0].buffer.pointer = (char *)uuid;
params[1].type = ACPI_TYPE_INTEGER;
- params[1].integer.value = 0x0100;
+ params[1].integer.value = revid;
params[2].type = ACPI_TYPE_INTEGER;
params[2].integer.value = func;
+ /* Although the ACPI spec defines Arg3 as a Package, in practise
+* implementations expect a Buffer (CreateWordField and Index functions
+* are applied to it). */
params[3].type = ACPI_TYPE_BUFFER;
params[3].buffer.length = 4;
/* ACPI is little endian, AABBCCDD becomes {DD,CC,BB,AA} */
@@ -108,50 +115,16 @@ static int nouveau_optimus_dsm(acpi_handle handle, int
func, int arg, uint32_t *
return 0;
}
-static int nouveau_dsm(acpi_handle handle, int func, int arg, uint32_t *result)
-{
- struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
- struct acpi_object_list input;
- union acpi_object params[4];
- union acpi_object *obj;
- int err;
-
- input.count = 4;
- input.pointer = params;
- params[0].type = ACPI_TYPE_BUFFER;
- params[0].buffer.length = sizeof(nouveau_dsm_muid);
- params[0].buffer.pointer = (char *)nouveau_dsm_muid;
- params[1].type = ACPI_TYPE_INTEGER;
- params[1].integer.value = 0x0102;
- params[2].type = ACPI_TYPE_INTEGER;
- params[2].integer.value = func;
- params[3].type = ACPI_TYPE_INTEGER;
- params[3].integer.value = arg;
-
- err = acpi_evaluate_object(handle, "_DSM", &input, &output);
- if (err) {
- printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
- return err;
- }
-
- obj = (union acpi_object *)output.pointer;
-
- if (obj->type == ACPI_TYPE_INTEGER)
- if (obj->integer.value == 0x8002)
- return -ENODEV;
-
- if (obj->type == ACPI_TYPE_BUFFER) {
- if (obj->buffer.length == 4 && result) {
- *result = 0;
- *result |= obj->buffer.pointer[0];
- *result |= (obj->buffer.pointer[1] << 8);
-
[PATCH 3.11-rc3+] radeon: si_dpm: Fix 32 bit __divdi3 modpost failure
ERROR: "__divdi3" [drivers/gpu/drm/radeon/radeon.ko] undefined! make[3]: *** [__modpost] Error 1 gcc version 4.8.1 Cc: David Airlie Cc: Alex Deucher Signed-off-by: Tim Gardner --- drivers/gpu/drm/radeon/si_dpm.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c index 7ad22e87..4182557 100644 --- a/drivers/gpu/drm/radeon/si_dpm.c +++ b/drivers/gpu/drm/radeon/si_dpm.c @@ -1767,7 +1767,7 @@ static void si_calculate_leakage_for_v_and_t_formula(const struct ni_leakage_coe s64 temperature, t_slope, t_intercept, av, bv, t_ref; s64 tmp; - i_leakage = drm_int2fixp(ileakage) / 100; + i_leakage = div64_s64(drm_int2fixp(ileakage), 100); vddc = div64_s64(drm_int2fixp(v), 1000); temperature = div64_s64(drm_int2fixp(t), 1000); -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] i915: fix ACPI _DSM warning
Since commit 29a241c (ACPICA: Add argument typechecking for all
predefined ACPI names), _DSM parameters are validated which trigger the
following warning:
ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found
[Integer], ACPI requires [Package] (20130517/nsarguments-95)
ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found
[Integer], ACPI requires [Package] (20130517/nsarguments-95)
ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found
[Integer], ACPI requires [Package] (20130517/nsarguments-95)
ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found
[Integer], ACPI requires [Package] (20130517/nsarguments-95)
As the Intel _DSM method seems to ignore this parameter, let's comply to
the ACPI spec and use a Package instead.
Signed-off-by: Peter Wu
---
What is this code useful for? It seems unfinished, all it does it
printing some information when a mux is available, but besides that
there is no interaction with the driver.
---
drivers/gpu/drm/i915/intel_acpi.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_acpi.c
b/drivers/gpu/drm/i915/intel_acpi.c
index bcbbaea..57fe1ae 100644
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -28,7 +28,7 @@ static const u8 intel_dsm_guid[] = {
0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c
};
-static int intel_dsm(acpi_handle handle, int func, int arg)
+static int intel_dsm(acpi_handle handle, int func)
{
struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
struct acpi_object_list input;
@@ -46,8 +46,9 @@ static int intel_dsm(acpi_handle handle, int func, int arg)
params[1].integer.value = INTEL_DSM_REVISION_ID;
params[2].type = ACPI_TYPE_INTEGER;
params[2].integer.value = func;
- params[3].type = ACPI_TYPE_INTEGER;
- params[3].integer.value = arg;
+ params[3].type = ACPI_TYPE_PACKAGE;
+ params[3].package.count = 0;
+ params[3].package.elements = NULL;
ret = acpi_evaluate_object(handle, "_DSM", &input, &output);
if (ret) {
@@ -151,8 +152,9 @@ static void intel_dsm_platform_mux_info(void)
params[1].integer.value = INTEL_DSM_REVISION_ID;
params[2].type = ACPI_TYPE_INTEGER;
params[2].integer.value = INTEL_DSM_FN_PLATFORM_MUX_INFO;
- params[3].type = ACPI_TYPE_INTEGER;
- params[3].integer.value = 0;
+ params[3].type = ACPI_TYPE_PACKAGE;
+ params[3].package.count = 0;
+ params[3].package.elements = NULL;
ret = acpi_evaluate_object(intel_dsm_priv.dhandle, "_DSM", &input,
&output);
@@ -205,7 +207,7 @@ static bool intel_dsm_pci_probe(struct pci_dev *pdev)
return false;
}
- ret = intel_dsm(dhandle, INTEL_DSM_FN_SUPPORTED_FUNCTIONS, 0);
+ ret = intel_dsm(dhandle, INTEL_DSM_FN_SUPPORTED_FUNCTIONS);
if (ret < 0) {
DRM_DEBUG_KMS("failed to get supported _DSM functions\n");
return false;
--
1.8.3.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] gpu/vga_switcheroo: add driver control power feature. (v3)
Hi Dave,
I don't know anything of PM domains, but there was one minor thing I wanted to
mention, see below.
On Monday 29 July 2013 16:06:56 Dave Airlie wrote:
> From: Dave Airlie
Something went wrong here I guess?
> [..]
>
> +static int vga_switcheroo_runtime_resume_hdmi_audio(struct device *dev)
> +{
> + struct pci_dev *pdev = to_pci_dev(dev);
> + int ret;
> + struct vga_switcheroo_client *client, *found = NULL;
> +
> + /* we need to check if we have to switch back on the video
> +device so the audio device can come back */
> + list_for_each_entry(client, &vgasr_priv.clients, list) {
> + if ((client->pdev->devfn & ~(0x7)) == (pdev->devfn & ~(0x7)) &&
> client_is_vga(client)) {
Less obfuscated:
PCI_SLOT(client->pdev->devfn) == PCI_SLOT(pdev->devfn)
> + found = client;
> + ret = pm_runtime_get_sync(&client->pdev->dev);
> + if (ret) {
> + if (ret != 1)
> + return ret;
> + }
> + break;
> + }
> + }
> + ret = dev->bus->pm->runtime_resume(dev);
> + if (ret)
> + return ret;
> +
> + /* put the reference for the gpu */
> + if (found)
> + pm_runtime_put_autosuspend(&found->pdev->dev);
> + return 0;
> +}
> [..]
Regards,
Peter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: add fast boot support for Haswell
Enables getting correct mode clock when reading pipe config
Signed-off-by: Furquan Shaikh
---
drivers/gpu/drm/i915/intel_ddi.c | 8
drivers/gpu/drm/i915/intel_display.c | 9 -
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 931b4bb..fa0af9b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1269,6 +1269,7 @@ static void intel_ddi_get_config(struct intel_encoder
*encoder,
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
enum transcoder cpu_transcoder = intel_crtc->config.cpu_transcoder;
+ int port = intel_ddi_get_encoder_port(encoder);
u32 temp, flags = 0;
temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
@@ -1282,6 +1283,13 @@ static void intel_ddi_get_config(struct intel_encoder
*encoder,
flags |= DRM_MODE_FLAG_NVSYNC;
pipe_config->adjusted_mode.flags |= flags;
+
+ if (port == PORT_A) {
+ if ((I915_READ(DP_A) & DP_PLL_FREQ_MASK) == DP_PLL_FREQ_160MHZ)
+ pipe_config->port_clock = 162000;
+ else
+ pipe_config->port_clock = 27;
+ }
}
static void intel_ddi_destroy(struct drm_encoder *encoder)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3e66f05..681c99a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7176,6 +7176,8 @@ static void i9xx_crtc_clock_get(struct intel_crtc *crtc,
pipe_config->pixel_multiplier;
}
+#define div_ceil(A, B) ((A)/(B) + ((A)%(B) ? 1 : 0))
+
static void ironlake_crtc_clock_get(struct intel_crtc *crtc,
struct intel_crtc_config *pipe_config)
{
@@ -7218,7 +7220,11 @@ static void ironlake_crtc_clock_get(struct intel_crtc
*crtc,
return;
clock = ((u64)link_m * (u64)link_freq * (u64)repeat);
- do_div(clock, link_n);
+ /* This is required because the value comes out to be in fraction
+ (eg. 70699.54). Need to round it up since values are compared in
+ drm_mode_equal
+ */
+ clock = div_ceil(clock, link_n);
pipe_config->adjusted_mode.clock = clock;
}
@@ -9588,6 +9594,7 @@ static void intel_init_display(struct drm_device *dev)
if (HAS_DDI(dev)) {
dev_priv->display.get_pipe_config = haswell_get_pipe_config;
+ dev_priv->display.get_clock = ironlake_crtc_clock_get;
dev_priv->display.crtc_mode_set = haswell_crtc_mode_set;
dev_priv->display.crtc_enable = haswell_crtc_enable;
dev_priv->display.crtc_disable = haswell_crtc_disable;
--
1.8.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915 backlight
On 08/01/2013 05:07 PM, Aaron Lu wrote: > On 08/01/2013 04:12 PM, Borislav Petkov wrote: >> On Thu, Aug 01, 2013 at 09:13:35AM +0800, Aaron Lu wrote: >>> Can you please run acpi_listen and then press the Fn-Fx key, see if the >>> events are correctly sent out? >> >> Like this? >> >> # acpi_listen >> video/brightnessdown BRTDN 0087 >> video/brightnessup BRTUP 0086 >> video/brightnessdown BRTDN 0087 >> video/brightnessup BRTUP 0086 >> video/brightnessdown BRTDN 0087 >> video/brightnessup BRTUP 0086 >> video/brightnessdown BRTDN 0087 >> video/brightnessup BRTUP 0086 >> video/brightnessdown BRTDN 0087 >> ^C > > Yes, so the event is correctly sent out. > >> >>> From the bug page: >>> https://bugzilla.kernel.org/show_bug.cgi?id=51231#c80 >>> I got the impression that both the acpi_video interface and the vendor >>> interface thinkpad_screen are broken. So adding this cmdline here works >>> suggests that either thinkpad_screen works or thinkpad vendor driver >>> doesn't get loaded or doesn't create that interface for some reason. >>> >>> Alternatively, if the intel_backlight interface works(highly possible), >>> you can use xorg.conf to specify the that backlight interface for X. >>> >>> Section "Device" >>> Option "Backlight" "intel_backlight" >>> Identifier "Card0" >>> Driver "intel" >>> BusID "PCI:0:2:0" >>> EndSection >> >> Yeah, that didn't work *but* manually writing to both: >> >> /sys/class/backlight/acpi_video0/brightness >> >> and >> >> /sys/class/backlight/intel_backlight/brightness >> >> works. > > Err...we have the event sent out on hotkey press and the interface also > works, but still, using hotkey to adjust brightness level is broken... > > I just found an old acer laptop that has similar issue(or even worse: on > X starts, an almost black screen is shown and hotkey adjust doesn't > work), I'll look into this. Hi Jani & Daniel, It turned out there is an integer overflow problem, and the below patch fixed this problem on Acer Aspire 4732Z and thinkpad R61i. From: Aaron Lu Subject: [PATCH] drm/i915: avoid brightness overflow when doing scale Some card's max brightness level is pretty large, e.g. on Acer Aspire 4732Z, the max level is 989910. If user space set a large enough level then the current scale done in intel_panel_set_backlight will cause an integer overflow and the scaled level will be mistakenly small, leaving user with an almost black screen. This patch fixes this problem. Signed-off-by: Aaron Lu --- Since the only external user of intel_panel_set_backlight is operation region code where the max will be a constant of 255, this patch fixes the problem by comparing freq and max and then do things accordingly instead of converting to 64 bits. drivers/gpu/drm/i915/intel_panel.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index 67e2c1f..7c674f0 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -498,7 +498,10 @@ void intel_panel_set_backlight(struct drm_device *dev, u32 level, u32 max) } /* scale to hardware */ - level = level * freq / max; + if (freq < max) + level = level * freq / max; + else + level = freq / max * level; dev_priv->backlight.level = level; if (dev_priv->backlight.device) -- 1.8.3.1 Hi Boris, Since the sysfs interface works on your system, I think your problem should be different. Can you please file a bug for this? I can provide you with a debug patch and then see what happened. Please attach acpidump when filing the bug. https://bugzilla.kernel.org, ACPI/Power-Video. Thanks, Aaron > >> >> The ranges are different, though: >> >> intel_backlight/actual_brightness:1000 >> intel_backlight/bl_power:0 >> intel_backlight/brightness:1000 >> intel_backlight/max_brightness:4437 >> intel_backlight/type:raw >> >> acpi_video0/actual_brightness:41 >> acpi_video0/bl_power:0 >> acpi_video0/brightness:41 >> acpi_video0/max_brightness:100 >> acpi_video0/type:firmware > > Yes, different interface has different brightness ranges and a value in > one range may turn out to be the same actual brightness level of another > value in another range. > >> >> I guess I need to write me a dirty script for now ... :-) > > :-) > >> >> Thanks guys. >> > Thanks, > Aaron > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag
Hi Tomasz,
On 2 August 2013 04:50, Tomasz Figa wrote:
>
> Hi Vikas,
>
> On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
> > While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
> > connected with resolution 2560x1600, following error occured even with
> > IOMMU enabled:
> > [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
> > buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
> >
> > This patch fixes the issue by adding a check for IOMMU.
> >
> > Signed-off-by: Vikas Sajjan
> > Signed-off-by: Arun Kumar
> > ---
> > drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a8
> > 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "exynos_drm_drv.h"
> > #include "exynos_drm_fb.h"
> > @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct
> > drm_fb_helper *helper, struct platform_device *pdev = dev->platformdev;
> > unsigned long size;
> > int ret;
> > + unsigned int flag;
> >
> > DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
> > sizes->surface_width, sizes->surface_height,
> > @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
> > drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
> >
> > /* 0 means to allocate physically continuous memory */
> > - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
> > + if (!is_drm_iommu_supported(dev))
> > + flag = 0;
> > + else
> > + flag = EXYNOS_BO_NONCONTIG;
>
> While noncontig memory might be used for devices that support IOMMU, there
> should be no problem with using contig memory for them, so this seems more
> like masking the original problem rather than tracking it down.
>
> Could you check why the allocation fails when requesting contiguous
> memory?
>
It is failing if i am giving bigger resolution like 2560x1600, but if
i try for 1280x780 resolution, it works fine.
Looks like arm_dma_alloc() is NOT able to allocate bigger buffer of
size 2560 * 1600 * 4.
Hence i used flag = EXYNOS_BO_NONCONTIG;
>
> Best regards,
> Tomasz
>
--
Thanks and Regards
Vikas Sajjan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag
Hi Vikas,
On 1 August 2013 16:49, Vikas Sajjan wrote:
> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
> connected with resolution 2560x1600, following error occured even with
> IOMMU enabled:
> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer.
> [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>
> This patch fixes the issue by adding a check for IOMMU.
>
> Signed-off-by: Vikas Sajjan
> Signed-off-by: Arun Kumar
> ---
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 8e60bd6..2a8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> #include "exynos_drm_drv.h"
> #include "exynos_drm_fb.h"
> @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
> *helper,
> struct platform_device *pdev = dev->platformdev;
> unsigned long size;
> int ret;
> + unsigned int flag;
>
> DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
> sizes->surface_width, sizes->surface_height,
> @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
> *helper,
> size = mode_cmd.pitches[0] * mode_cmd.height;
>
> /* 0 means to allocate physically continuous memory */
This comment is now wrongly placed. Please use EXYNOS_BO_CONTIG instead of 0
and get rid of this comment altogether.
> - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
> + if (!is_drm_iommu_supported(dev))
> + flag = 0;
> + else
> + flag = EXYNOS_BO_NONCONTIG;
> +
> + exynos_gem_obj = exynos_drm_gem_create(dev, flag, size);
> if (IS_ERR(exynos_gem_obj)) {
> ret = PTR_ERR(exynos_gem_obj);
> goto err_release_framebuffer;
--
With warm regards,
Sachin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag
Hi Vikas,
On 2 August 2013 09:23, Vikas Sajjan wrote:
> Hi Tomasz,
>
>
> On 2 August 2013 04:50, Tomasz Figa wrote:
>>
>> Hi Vikas,
>>
>> On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
>> > While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
>> > connected with resolution 2560x1600, following error occured even with
>> > IOMMU enabled:
>> > [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
>> > buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>> >
>> > This patch fixes the issue by adding a check for IOMMU.
>> >
>> > Signed-off-by: Vikas Sajjan
>> > Signed-off-by: Arun Kumar
>> > ---
>> > drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
>> > 1 file changed, 8 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> > b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a8
>> > 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> > @@ -16,6 +16,7 @@
>> > #include
>> > #include
>> > #include
>> > +#include
>> >
>> > #include "exynos_drm_drv.h"
>> > #include "exynos_drm_fb.h"
>> > @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct
>> > drm_fb_helper *helper, struct platform_device *pdev = dev->platformdev;
>> > unsigned long size;
>> > int ret;
>> > + unsigned int flag;
>> >
>> > DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
>> > sizes->surface_width, sizes->surface_height,
>> > @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
>> > drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
>> >
>> > /* 0 means to allocate physically continuous memory */
>> > - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
>> > + if (!is_drm_iommu_supported(dev))
>> > + flag = 0;
>> > + else
>> > + flag = EXYNOS_BO_NONCONTIG;
>>
>> While noncontig memory might be used for devices that support IOMMU, there
>> should be no problem with using contig memory for them, so this seems more
>> like masking the original problem rather than tracking it down.
>>
>> Could you check why the allocation fails when requesting contiguous
>> memory?
>>
>
> It is failing if i am giving bigger resolution like 2560x1600, but if
> i try for 1280x780 resolution, it works fine.
> Looks like arm_dma_alloc() is NOT able to allocate bigger buffer of
> size 2560 * 1600 * 4.
You may need to increase the zoneorder (from current default 11 to say
13) if you need large physically contiguous pages.
However I am not sure if it is recommended.
--
With warm regards,
Sachin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau/acpi: de-dup use of DSM methods
On Fri, Aug 2, 2013 at 12:41 AM, Peter Wu wrote:
> Observe that nouveau_optimus_dsm and nouveau_dsm are equal except for
> the parameters handling (UUID, revision ID and function arguments). The
> function arguments are passed as Buffer in the "optimus dsm" and Integer
> in "nvidia dsm". As buffers are implicitly converted to integers, merge
> both functions.
>
> The ACPI spec defines the fourth parameter (Arg3 a.k.a. "function
> arguments") as Package, but many BIOSes expect a Buffer instead. For
> instance, for the "nvidia DSM", the Lenovo T410s uses CreateByteField on
> Arg3 which does not work with a package. The Clevo B7130 does something
> similar for the "Optimus DSM". Unfortunately, this means that the
> following ACPI warning (introduced with 29a241c) cannot be fixed (when
> toggling power or muxing):
By cannot be fixed, why is it there then? maybe ask the ACPI folks to
drop this error, since as far as I can see all optimus dsm want a
buffer here.
Dave.
>
> ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found
> [Buffer], ACPI requires [Package] (20130517/nsarguments-95)
> ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found
> [Buffer], ACPI requires [Package] (20130517/nsarguments-95)
> ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch -
> Found [Buffer], ACPI requires [Package] (20130517/nsarguments-95)
> ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch -
> Found [Buffer], ACPI requires [Package] (20130517/nsarguments-95)
>
> Signed-off-by: Peter Wu
> ---
> drivers/gpu/drm/nouveau/nouveau_acpi.c | 67
> ++
> 1 file changed, 20 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> index d97f200..a75684f 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> @@ -46,6 +46,9 @@ bool nouveau_is_v1_dsm(void) {
> #define NOUVEAU_DSM_HAS_MUX 0x1
> #define NOUVEAU_DSM_HAS_OPT 0x2
>
> +#define NOUVEAU_DSM_REVID_NVIDIA 0x102
> +#define NOUVEAU_DSM_REVID_OPTIMUS 0x100
> +
> static const char nouveau_dsm_muid[] = {
> 0xA0, 0xA0, 0x95, 0x9D, 0x60, 0x00, 0x48, 0x4D,
> 0xB3, 0x4D, 0x7E, 0x5F, 0xEA, 0x12, 0x9F, 0xD4,
> @@ -56,7 +59,8 @@ static const char nouveau_op_dsm_muid[] = {
> 0xA7, 0x2B, 0x60, 0x42, 0xA6, 0xB5, 0xBE, 0xE0,
> };
>
> -static int nouveau_optimus_dsm(acpi_handle handle, int func, int arg,
> uint32_t *result)
> +static int nouveau_call_dsm(acpi_handle handle, const char *uuid, int revid,
> + int func, int arg, uint32_t *result)
> {
> struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
> struct acpi_object_list input;
> @@ -68,12 +72,15 @@ static int nouveau_optimus_dsm(acpi_handle handle, int
> func, int arg, uint32_t *
> input.count = 4;
> input.pointer = params;
> params[0].type = ACPI_TYPE_BUFFER;
> - params[0].buffer.length = sizeof(nouveau_op_dsm_muid);
> - params[0].buffer.pointer = (char *)nouveau_op_dsm_muid;
> + params[0].buffer.length = 16;
> + params[0].buffer.pointer = (char *)uuid;
> params[1].type = ACPI_TYPE_INTEGER;
> - params[1].integer.value = 0x0100;
> + params[1].integer.value = revid;
> params[2].type = ACPI_TYPE_INTEGER;
> params[2].integer.value = func;
> + /* Although the ACPI spec defines Arg3 as a Package, in practise
> +* implementations expect a Buffer (CreateWordField and Index
> functions
> +* are applied to it). */
> params[3].type = ACPI_TYPE_BUFFER;
> params[3].buffer.length = 4;
> /* ACPI is little endian, AABBCCDD becomes {DD,CC,BB,AA} */
> @@ -108,50 +115,16 @@ static int nouveau_optimus_dsm(acpi_handle handle, int
> func, int arg, uint32_t *
> return 0;
> }
>
> -static int nouveau_dsm(acpi_handle handle, int func, int arg, uint32_t
> *result)
> -{
> - struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
> - struct acpi_object_list input;
> - union acpi_object params[4];
> - union acpi_object *obj;
> - int err;
> -
> - input.count = 4;
> - input.pointer = params;
> - params[0].type = ACPI_TYPE_BUFFER;
> - params[0].buffer.length = sizeof(nouveau_dsm_muid);
> - params[0].buffer.pointer = (char *)nouveau_dsm_muid;
> - params[1].type = ACPI_TYPE_INTEGER;
> - params[1].integer.value = 0x0102;
> - params[2].type = ACPI_TYPE_INTEGER;
> - params[2].integer.value = func;
> - params[3].type = ACPI_TYPE_INTEGER;
> - params[3].integer.value = arg;
> -
> - err = acpi_evaluate_object(handle, "_DSM", &input, &output);
> - if (err) {
> - printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
> - return err;
> - }
> -
> - obj = (union acpi_object *)output.pointer;
Re: i915 backlight
On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa wrote: > Hello, > > I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to > change to this parameter to the kernel boot: > > > GRUB_CMDLINE_LINUX="acpi_osi=\"!Windows 2012\"" I think it's pretty obvious that for the time being we need to blacklist a ton of machines so they boot without this OSI. In fact, in might make sense to simply remove the OSI completely for all machines (for now). -- Felipe Contreras ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
i915 backlight
On Wed, Jul 31, 2013 at 11:16:52PM +0200, Rafael J. Wysocki wrote: > Does reverting efaa14c help? Nope. But see my other reply to Aaron. Thanks.
i915 backlight
On Thu, Aug 01, 2013 at 09:13:35AM +0800, Aaron Lu wrote: > Can you please run acpi_listen and then press the Fn-Fx key, see if the > events are correctly sent out? Like this? # acpi_listen video/brightnessdown BRTDN 0087 video/brightnessup BRTUP 0086 video/brightnessdown BRTDN 0087 video/brightnessup BRTUP 0086 video/brightnessdown BRTDN 0087 video/brightnessup BRTUP 0086 video/brightnessdown BRTDN 0087 video/brightnessup BRTUP 0086 video/brightnessdown BRTDN 0087 ^C > From the bug page: > https://bugzilla.kernel.org/show_bug.cgi?id=51231#c80 > I got the impression that both the acpi_video interface and the vendor > interface thinkpad_screen are broken. So adding this cmdline here works > suggests that either thinkpad_screen works or thinkpad vendor driver > doesn't get loaded or doesn't create that interface for some reason. > > Alternatively, if the intel_backlight interface works(highly possible), > you can use xorg.conf to specify the that backlight interface for X. > > Section "Device" > Option "Backlight""intel_backlight" > Identifier "Card0" > Driver "intel" > BusID "PCI:0:2:0" > EndSection Yeah, that didn't work *but* manually writing to both: /sys/class/backlight/acpi_video0/brightness and /sys/class/backlight/intel_backlight/brightness works. The ranges are different, though: intel_backlight/actual_brightness:1000 intel_backlight/bl_power:0 intel_backlight/brightness:1000 intel_backlight/max_brightness:4437 intel_backlight/type:raw acpi_video0/actual_brightness:41 acpi_video0/bl_power:0 acpi_video0/brightness:41 acpi_video0/max_brightness:100 acpi_video0/type:firmware I guess I need to write me a dirty script for now ... :-) Thanks guys.
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #42 from Scias --- Comment 40 patch works here. -- 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/20130801/b525fcaf/attachment-0001.html>
[Bug 60674] New: linux 3.10.x RV740 (Radeon HD 4770) display problem
https://bugzilla.kernel.org/show_bug.cgi?id=60674 Bug ID: 60674 Summary: linux 3.10.x RV740 (Radeon HD 4770) display problem Product: Drivers Version: 2.5 Kernel Version: 3.10 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: yg.do at sfr.fr Regression: No Created attachment 107073 --> https://bugzilla.kernel.org/attachment.cgi?id=107073&action=edit Screenshot with kernel 3.10 (display BUG) Description: Hard to describe? It seems that fonts don?t get displayed. Seeing the screenshots, I?m not sure it is the only problem, though? (see icons for example) Linux console is OK. E17 is OK. Additional info: * OS: up-to-date Arch Linux * current (working kernel): 3.9.9 * tested non-working kernels: 3.10.2 and 3.10.3 Steps to reproduce: * upgrade kernel, * get this: [attached screenshot] As you can see, Enlightenment17 has no problem for some reason. However, all other applications I tried were displayed like the screenshot: Firefox, Thunderbird, Geany? and SLIM (the display manager)! On the login screen for example, I can enter my login name, but no text is shown on screen; it lets me login though. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 60674] linux 3.10.x RV740 (Radeon HD 4770) display problem
https://bugzilla.kernel.org/show_bug.cgi?id=60674 --- Comment #1 from Yves G. (theYinYeti) --- Created attachment 107074 --> https://bugzilla.kernel.org/attachment.cgi?id=107074&action=edit For comparison, same screenshot with kernel 3.9. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 05/27] drivers/gpu/host1x/drm: don't check resource with devm_ioremap_resource
On 23.07.2013 21:01, Wolfram Sang wrote: > diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c > index 01097da..9ffece6 100644 > --- a/drivers/gpu/host1x/drm/hdmi.c > +++ b/drivers/gpu/host1x/drm/hdmi.c > @@ -1248,9 +1248,6 @@ static int tegra_hdmi_probe(struct platform_device > *pdev) > return err; > > regs = platform_get_resource(pdev, IORESOURCE_MEM, 0); > - if (!regs) > - return -ENXIO; > - > hdmi->regs = devm_ioremap_resource(&pdev->dev, regs); > if (IS_ERR(hdmi->regs)) > return PTR_ERR(hdmi->regs); > Looks good to me. Reviewed-By: Terje Bergstrom Terje
[Intel-gfx] [PATCH 13/20] drm/gem: create drm_gem_dumb_destroy
On Tue, Jul 16, 2013 at 9:12 AM, Daniel Vetter
wrote:
> All the gem based kms drivers really want the same function to
> destroy a dumb framebuffer backing storage object.
>
> So give it to them and roll it out in all drivers.
>
> This still leaves the option open for kms drivers which don't use GEM
> for backing storage, but it does decently simplify matters for gem
> drivers.
>
> Cc: Inki Dae
> Cc: Laurent Pinchart
> Cc: Intel Graphics Development
> Cc: Ben Skeggs
> Cc: Rob Clark
> Cc: Alex Deucher
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/ast/ast_drv.c | 2 +-
> drivers/gpu/drm/ast/ast_drv.h | 3 ---
> drivers/gpu/drm/ast/ast_main.c| 7 ---
> drivers/gpu/drm/cirrus/cirrus_drv.c | 2 +-
> drivers/gpu/drm/cirrus/cirrus_drv.h | 3 ---
> drivers/gpu/drm/cirrus/cirrus_main.c | 7 ---
> drivers/gpu/drm/drm_gem.c | 14 ++
> drivers/gpu/drm/drm_gem_cma_helper.c | 10 --
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 20
> drivers/gpu/drm/exynos/exynos_drm_gem.h | 9 -
> drivers/gpu/drm/gma500/gem.c | 17 -
> drivers/gpu/drm/gma500/psb_drv.c | 2 +-
> drivers/gpu/drm/gma500/psb_drv.h | 2 --
> drivers/gpu/drm/i915/i915_drv.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 2 --
> drivers/gpu/drm/i915/i915_gem.c | 7 ---
> drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +-
> drivers/gpu/drm/mgag200/mgag200_drv.h | 3 ---
> drivers/gpu/drm/mgag200/mgag200_main.c| 7 ---
> drivers/gpu/drm/nouveau/nouveau_display.c | 7 ---
> drivers/gpu/drm/nouveau/nouveau_display.h | 2 --
> drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_drv.c| 2 +-
> drivers/gpu/drm/omapdrm/omap_drv.h| 2 --
> drivers/gpu/drm/omapdrm/omap_gem.c| 15 ---
> drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
> drivers/gpu/drm/qxl/qxl_drv.h | 3 ---
> drivers/gpu/drm/qxl/qxl_dumb.c| 7 ---
> drivers/gpu/drm/radeon/radeon.h | 3 ---
> drivers/gpu/drm/radeon/radeon_drv.c | 5 +
> drivers/gpu/drm/radeon/radeon_gem.c | 7 ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +-
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
> drivers/gpu/drm/udl/udl_drv.c | 2 +-
> drivers/gpu/drm/udl/udl_drv.h | 2 --
> drivers/gpu/drm/udl/udl_gem.c | 6 --
> drivers/gpu/host1x/drm/drm.c | 2 +-
> drivers/gpu/host1x/drm/gem.c | 6 --
> drivers/gpu/host1x/drm/gem.h | 2 --
> drivers/staging/imx-drm/imx-drm-core.c| 2 +-
> include/drm/drmP.h| 3 +++
> include/drm/drm_gem_cma_helper.h | 8
> 44 files changed, 33 insertions(+), 186 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
> index df0d0a0..a144fb0 100644
> --- a/drivers/gpu/drm/ast/ast_drv.c
> +++ b/drivers/gpu/drm/ast/ast_drv.c
> @@ -216,7 +216,7 @@ static struct drm_driver driver = {
> .gem_free_object = ast_gem_free_object,
> .dumb_create = ast_dumb_create,
> .dumb_map_offset = ast_dumb_mmap_offset,
> - .dumb_destroy = ast_dumb_destroy,
> + .dumb_destroy = drm_gem_dumb_destroy,
>
> };
>
> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> index 622d4ae..796dbb2 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -322,9 +322,6 @@ ast_bo(struct ttm_buffer_object *bo)
> extern int ast_dumb_create(struct drm_file *file,
>struct drm_device *dev,
>struct drm_mode_create_dumb *args);
> -extern int ast_dumb_destroy(struct drm_file *file,
> - struct drm_device *dev,
> - uint32_t handle);
>
> extern int ast_gem_init_object(struct drm_gem_object *obj);
> extern void ast_gem_free_object(struct drm_gem_object *obj);
> diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
> index f60fd7b..0ef4228 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -449,13 +449,6 @@ int ast_dumb_create(struct drm_file *file,
> return 0;
> }
>
> -int ast_dumb_destroy(struct drm_file *file,
> -struct drm_device *dev,
> -uint32_t handle)
> -{
> - return drm_gem_handle_delete(file, handle);
> -}
> -
> int ast_gem_init_object(struct drm_gem_object *obj)
> {
> BUG();
> diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
> b/drivers/gpu/drm/cirrus/cirrus_drv.c
> index 8ecb601..d35d99c 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_drv.c
> +++ b/d
[Bug 60674] linux 3.10.x RV740 (Radeon HD 4770) display problem
https://bugzilla.kernel.org/show_bug.cgi?id=60674 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2 from Alex Deucher --- Just to be sure, is the only component you changed the kernel (i.e., you didn't change the mesa version as well)? If so, can you bisect the kernel? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #43 from Alex Deucher --- Can you guys attach a copy of your vbios? (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/ echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom -- 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/20130801/abac3013/attachment.html>
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #44 from Sergey --- Created attachment 83431 --> https://bugs.freedesktop.org/attachment.cgi?id=83431&action=edit vbios used for ATI RV620/M82 [Mobility Radeon HD 3450/3470] -- 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/20130801/09698bd3/attachment.html>
[PATCH] drm/radeon: use loop for initializing AFMT blocks
On Thu, Aug 1, 2013 at 1:54 AM, Rafa? Mi?ecki wrote: > 2013/7/31 Alex Deucher : >> On Wed, Jul 31, 2013 at 11:50 AM, Rafa? Mi?ecki wrote: >>> >>> Signed-off-by: Rafa? Mi?ecki >>> --- >>> Dave/Alex: please decide who picks this patch :) >> >> I think it might be easier to just assume 6 afmt blocks on all DCE4+ >> hardware (DCE6 too). It's makes the logic simpler in the driver. The >> afmt block is tied to the dig encoder so the correct one will always >> get selected even if a particular asic has more allocated than it has >> physically. > > I'm not sure about idea of allocating memory for parts of hardware > that don't exist (read: wasting some memory). It could be a nice > solution to allocate AFMT blocks depending on the amount of DIG > encoders. Unfortunately, I'm afraid we don't have anything like > "num_dig", do we? We assign "dig->dig_encoder" value using > radeon_atom_pick_dig_encoder, but it just check for encoder/link/crtc. > > Any other idea? Or should we just waste some memory? Is this worth it It seems simpler to me, but it's not that big a deal either way. > to avoid this simple > if (ASIC_IS_DCE64(rdev)) > num_afmt = 2; Need to double check which PHYs oland actually has. I think it's just the first two. > else if (ASIC_IS_DCE61(rdev)) > num_afmt = 4; Trinity supports 6 dig encoders. > else if (ASIC_IS_DCE6(rdev)) > num_afmt = 6; > else if (ASIC_IS_DCE5(rdev)) > num_afmt = 6; > else if (ASIC_IS_DCE41(rdev)) > num_afmt = 2; > else /* DCE4 */ > num_afmt = 6; > ? > > > -- > Rafa?
[PATCH] drm/radeon: fix 64 bit divide in SI spm code
From: Alex Deucher Forgot to use the appropriate math64 function. Signed-off-by: Alex Deucher --- This is already in my -fixes queue, but for those that are running into issues, here's the fix. drivers/gpu/drm/radeon/si_dpm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c index 7ad22e8..4182557 100644 --- a/drivers/gpu/drm/radeon/si_dpm.c +++ b/drivers/gpu/drm/radeon/si_dpm.c @@ -1767,7 +1767,7 @@ static void si_calculate_leakage_for_v_and_t_formula(const struct ni_leakage_coe s64 temperature, t_slope, t_intercept, av, bv, t_ref; s64 tmp; - i_leakage = drm_int2fixp(ileakage) / 100; + i_leakage = div64_s64(drm_int2fixp(ileakage), 100); vddc = div64_s64(drm_int2fixp(v), 1000); temperature = div64_s64(drm_int2fixp(t), 1000); -- 1.7.7.5
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #45 from Scias --- Created attachment 83432 --> https://bugs.freedesktop.org/attachment.cgi?id=83432&action=edit vbios for RV635/M86 [Mobility Radeon HD 3650] vbios for RV635/M86 [Mobility Radeon HD 3650] -- 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/20130801/202b4477/attachment.html>
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #46 from Francisco Pina Martins --- I am trying to do some testing too, but I cannot seem to apply the patch from comment 40 to the mainline kernel. Should I be getting the changes from a specific branch in git://people.freedesktop.org/~agd5f/linux ? Thanks and sorry about the noise. -- 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/20130801/53403587/attachment.html>
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #47 from Alex Deucher --- I've pushed my latest -fixes branch: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.11 it already includes the fix from comment 40. -- 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/20130801/c243b852/attachment-0001.html>
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #48 from Alex Deucher --- Sergey, On a kernel that has the patch in comment 40, does booting with radeon.aspm=0 help? -- 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/20130801/584816ed/attachment.html>
[PATCH] drm/radeon/dpm: implement force performance levels for rs780
> -Original Message-
> From: Anthoine Bourgeois [mailto:anthoine.bourgeois at gmail.com]
> Sent: Wednesday, July 31, 2013 6:34 PM
> To: Deucher, Alexander; Koenig, Christian; Jerome Glisse; Anthoine
> Bourgeois
> Cc: dri-devel at lists.freedesktop.org
> Subject: [PATCH] drm/radeon/dpm: implement force performance levels for
> rs780
>
> Allows you to limit the selected power levels via sysfs.
>
> Force the feedback divider to select a power level.
Nice work. A few comments below.
Alex
>
> Signed-off-by: Anthoine Bourgeois
> ---
> drivers/gpu/drm/radeon/radeon_asic.c | 1 +
> drivers/gpu/drm/radeon/radeon_asic.h | 2 ++
> drivers/gpu/drm/radeon/rs780_dpm.c | 67
> ++--
> 3 files changed, 59 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
> b/drivers/gpu/drm/radeon/radeon_asic.c
> index f8f8b31..437d357 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.c
> +++ b/drivers/gpu/drm/radeon/radeon_asic.c
> @@ -1272,6 +1272,7 @@ static struct radeon_asic rs780_asic = {
> .get_mclk = &rs780_dpm_get_mclk,
> .print_power_state = &rs780_dpm_print_power_state,
> .debugfs_print_current_performance_level =
> &rs780_dpm_debugfs_print_current_performance_level,
> + .force_performance_level =
> &rs780_dpm_force_performance_level,
> },
> .pflip = {
> .pre_page_flip = &rs600_pre_page_flip,
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
> b/drivers/gpu/drm/radeon/radeon_asic.h
> index 902479f..09841fc 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.h
> +++ b/drivers/gpu/drm/radeon/radeon_asic.h
> @@ -437,6 +437,8 @@ void rs780_dpm_print_power_state(struct
> radeon_device *rdev,
>struct radeon_ps *ps);
> void rs780_dpm_debugfs_print_current_performance_level(struct
> radeon_device *rdev,
> struct seq_file *m);
> +int rs780_dpm_force_performance_level(struct radeon_device *rdev,
> + enum radeon_dpm_forced_level level);
>
> /* uvd */
> int r600_uvd_init(struct radeon_device *rdev);
> diff --git a/drivers/gpu/drm/radeon/rs780_dpm.c
> b/drivers/gpu/drm/radeon/rs780_dpm.c
> index d1a1ce7..df58e34 100644
> --- a/drivers/gpu/drm/radeon/rs780_dpm.c
> +++ b/drivers/gpu/drm/radeon/rs780_dpm.c
> @@ -404,6 +404,27 @@ static void rs780_force_voltage_to_high(struct
> radeon_device *rdev)
> WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
> }
>
> +static void rs780_force_fbdiv(struct radeon_device *rdev, u32 fb_div)
> +{
> + struct igp_ps *current_state = rs780_get_ps(rdev-
> >pm.dpm.current_ps);
> +
> + if ((current_state->sclk_low == fb_div) &&
> + (current_state->sclk_high == fb_div))
> + return;
I'm not quite sure what you are checking here.
> +
> + WREG32_P(GFX_MACRO_BYPASS_CNTL, SPLL_BYPASS_CNTL,
> ~SPLL_BYPASS_CNTL);
> +
> + WREG32_P(FVTHROT_FBDIV_REG2,
> FORCED_FEEDBACK_DIV(fb_div),
> + ~FORCED_FEEDBACK_DIV_MASK);
> + WREG32_P(FVTHROT_FBDIV_REG1,
> STARTING_FEEDBACK_DIV(fb_div),
> + ~STARTING_FEEDBACK_DIV_MASK);
> + WREG32_P(FVTHROT_FBDIV_REG1, FORCE_FEEDBACK_DIV,
> ~FORCE_FEEDBACK_DIV);
> +
> + udelay(100);
> +
> + WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
> +}
> +
> static int rs780_set_engine_clock_scaling(struct radeon_device *rdev,
> struct radeon_ps *new_ps,
> struct radeon_ps *old_ps)
> @@ -432,17 +453,7 @@ static int rs780_set_engine_clock_scaling(struct
> radeon_device *rdev,
> if (ret)
> return ret;
>
> - WREG32_P(GFX_MACRO_BYPASS_CNTL, SPLL_BYPASS_CNTL,
> ~SPLL_BYPASS_CNTL);
> -
> - WREG32_P(FVTHROT_FBDIV_REG2,
> FORCED_FEEDBACK_DIV(max_dividers.fb_div),
> - ~FORCED_FEEDBACK_DIV_MASK);
> - WREG32_P(FVTHROT_FBDIV_REG1,
> STARTING_FEEDBACK_DIV(max_dividers.fb_div),
> - ~STARTING_FEEDBACK_DIV_MASK);
> - WREG32_P(FVTHROT_FBDIV_REG1, FORCE_FEEDBACK_DIV,
> ~FORCE_FEEDBACK_DIV);
> -
> - udelay(100);
> -
> - WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
> + rs780_force_fbdiv(rdev, max_dividers.fb_div);
>
> if (max_dividers.fb_div > min_dividers.fb_div) {
> WREG32_P(FVTHROT_FBDIV_REG0,
> @@ -986,3 +997,37 @@ void
> rs780_dpm_debugfs_print_current_performance_level(struct
> radeon_device *rde
> seq_printf(m, "power level 1sclk: %u vddc_index: %d\n",
> ps->sclk_high, ps->max_voltage);
> }
> +
> +int rs780_dpm_force_performance_level(struct radeon_device *rdev,
> + enum radeon_dpm_forced_level level)
> +{
> + struct radeon_ps *rps = rdev->pm.dpm.current_ps;
> + struct igp_ps *ps = rs780_get_ps(rps);
> + struct atom_clock_dividers min_dividers, max_dividers;
You can
