[Bug 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 --- Comment #19 from bgunte...@gmail.com --- what other information do you need??? -- 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 62721] GPU lockup: radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec...
https://bugzilla.kernel.org/show_bug.cgi?id=62721 --- Comment #3 from Egor Y. Egorov egorov_e...@bk.ru --- (In reply to Alex Deucher from comment #2) Please attach your full dmesg output. Why journalctl -a not enough? If that need I'll post dmesg soon. What GPU is this? RV570 Are you sure cb51bb7107aa040f9779be931e3bd6a7b50e0f69 is the correct commit? That commit only affects the debugfs output. If you don't access those debugfs files, that code in question is never called. Perhaps the fault is not that commit, but 3.11.3 worked entirely without problems. After the upgrade to 3.11.4 similar problems began to arise. I tried to roll back this commit, and was able to work at a computer for long enough. In any case, I will test again. Did you also happen to update your userspace drivers (mesa or xf86-video-ati)? xf86-video-ati and mesa has not been updated in my system for a long time. -- 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 70303] New: Kernel stack trace at drivers/gpu/drm/drm_crtc.c:1992
https://bugs.freedesktop.org/show_bug.cgi?id=70303 Priority: medium Bug ID: 70303 Assignee: dri-devel@lists.freedesktop.org Summary: Kernel stack trace at drivers/gpu/drm/drm_crtc.c:1992 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: pwri...@rubiconproject.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/other Product: DRI System setup: OS: Fedora-19 GFX: ATI kernel: Linux malibu..com 3.11.3-201.fc19.x86_64 #1 SMP Thu Oct 3 00:47:03 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Trace: Oct 8 20:59:27 malibu kernel: [56515.220579] [ cut here ] Oct 8 20:59:27 malibu kernel: [56515.220603] WARNING: CPU: 4 PID: 364 at drivers/gpu/drm/drm_crtc.c:1992 drm_mode_set_config_internal+0xd6/0xe0 [drm]() Oct 8 20:59:27 malibu kernel: [56515.220615] Modules linked in: ebtable_nat xt_CHECKSUM fuse tun bridge stp llc nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_nat nf_nat_ipv 6 ip6table_mangle ip6table_security ip6table_raw ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle iptable_security iptable_raw nf_conntrack_ipv4 nf_defrag_i pv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables rfcomm bnep vsock snd_hda_codec_hdmi snd_hda_codec_idt iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal coretemp kvm _intel kvm crc32_pclmul crc32c_intel hp_wmi ghash_clmulni_intel sparse_keymap ppdev arc4 iwldvm btusb mac80211 microcode joydev uvcvideo bluetooth videobuf2_vmalloc videobuf2_memops snd_hda_intel vi deobuf2_core snd_hda_codec videodev iwlwifi snd_hwdep serio_raw snd_seq cfg80211 media sdhci_pci sdhci snd_seq_device mmc_core rfkill snd_pcm lpc_ich e1000e snd_page_alloc mfd_core snd_timer snd ptp mei_me soundcore mei pps_core shpchp wmi parport_pc tpm_tis parport tpm_infineon tpm tpm_bios hp_accel lis3lv02d video input_polldev mperf binfmt_misc uinput radeon i2c_algo_bit drm_kms_helper ttm firewire_ohci drm firewire_core crc_itu_t i2c_core Oct 8 20:59:27 malibu kernel: [56515.220626] CPU: 4 PID: 364 Comm: Xorg Tainted: GW3.11.3-201.fc19.x86_64 #1 Oct 8 20:59:27 malibu kernel: [56515.220626] Hardware name: Hewlett-Packard HP EliteBook 8470w/179B, BIOS 68ICF Ver. F.32 12/05/2012 Oct 8 20:59:27 malibu kernel: [56515.220628] 0009 88035e7fdae0 8164777f Oct 8 20:59:27 malibu kernel: [56515.220630] 88035e7fdb18 8106715d 8804246184a0 Oct 8 20:59:27 malibu kernel: [56515.220631] 8804277fe000 880424319860 0080 88035e7fdb28 Oct 8 20:59:27 malibu kernel: [56515.220631] Call Trace: Oct 8 20:59:27 malibu kernel: [56515.220636] [8164777f] dump_stack+0x45/0x56 Oct 8 20:59:27 malibu kernel: [56515.220638] [8106715d] warn_slowpath_common+0x7d/0xa0 Oct 8 20:59:27 malibu kernel: [56515.220639] [8106723a] warn_slowpath_null+0x1a/0x20 Oct 8 20:59:27 malibu kernel: [56515.220646] [a003fae6] drm_mode_set_config_internal+0xd6/0xe0 [drm] Oct 8 20:59:27 malibu kernel: [56515.220649] [a00ab641] drm_fb_helper_set_par+0x71/0xf0 [drm_kms_helper] Oct 8 20:59:27 malibu kernel: [56515.220652] [813457b1] fb_set_var+0x191/0x430 Oct 8 20:59:27 malibu kernel: [56515.220655] [81144606] ? free_hot_cold_page_list+0x46/0xa0 Oct 8 20:59:27 malibu kernel: [56515.220657] [81350f81] fbcon_blank+0x1d1/0x2d0 Oct 8 20:59:27 malibu kernel: [56515.220658] [813c68f4] do_unblank_screen+0xb4/0x1e0 Oct 8 20:59:27 malibu kernel: [56515.220660] [813bd973] vt_ioctl+0x10d3/0x1150 Oct 8 20:59:27 malibu kernel: [56515.220662] [81646e5b] ? avc_compute_av+0x1a3/0x1b5 Oct 8 20:59:27 malibu kernel: [56515.220663] [813b1695] tty_ioctl+0x275/0xb70 Oct 8 20:59:27 malibu kernel: [56515.220665] [8129a269] ? avc_has_perm_flags+0xc9/0x180 Oct 8 20:59:27 malibu kernel: [56515.220668] [811b9f4d] do_vfs_ioctl+0x2dd/0x4b0 Oct 8 20:59:27 malibu kernel: [56515.220670] [811a9d6e] ? fput+0xe/0x10 Oct 8 20:59:27 malibu kernel: [56515.220671] [811ba1a1] SyS_ioctl+0x81/0xa0 Oct 8 20:59:27 malibu kernel: [56515.220673] [81656959] system_call_fastpath+0x16/0x1b Oct 8 20:59:27 malibu kernel: [56515.220674] ---[ end trace 0e5b42bab49a2c03 ]--- Oct 8 20:59:27 malibu kernel: [56515.239621] [ cut 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
Re: [PATCH] drm/i915/dp: use drm_edid_duplicate
On Tue, Oct 1, 2013 at 5:38 PM, Jani Nikula jani.nik...@intel.com wrote: v2: duplicate intel_connector-edid, not uninitialized edid (Dave Airlie). Okay I merged this one, Thanks, Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] DRM device-alloc cleanup
On Wed, Oct 2, 2013 at 7:23 PM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
This cleans up the bus drivers in DRM. Instead of copying the device
alloc/free
semantics into each bus driver (drm_{pci,platform,usb}.c) we now have a
central
place in drm_stub.c.
This introduces drm_dev_{alloc,free,register,unregister}(). They have the same
semantics as most other kernel subsystems. *_alloc() allocates a new device
and
populates the static fields and sub-objects. *_free() frees an unregistered
object allocated via *_alloc(). *_register() registers a DRM device and
*_unregister() obviously unregisters a DRM device. A *_free() is still needed
after calling *_unregister() (same as for struct device). No ref-counting is
added as it is not required by any driver.
Note that the bus drivers are modified to use the new helpers directly.
However,
I didn't modify the drivers to use *_unregister() and *_free() directly.
Instead, the drm_put_dev() helper was modified to use these. Reason for that
is
that I have pending patches to make device hotplugging safer regarding mmaps.
But these aren't ready, yet. Hopefully I can get them ready for rc5 or rc6.
Tested on nouveau.
Okay I've merged this series, a follow-on to fix the AGP bits like
Daniel suggested would be good.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm: kill -gem_init_object() and friends
All drivers embed gem-objects into their own buffer objects. There is no reason to keep drm_gem_object_alloc(), gem-driver_private and -gem_init_object() anymore. New drivers are highly encouraged to do the same. There is no benefit in allocating gem-objects separately. Merged both of these to -next. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/10] drm: drm_device house cleaning
This series does some house cleaning on struct drm_device. Merged 1-9, not sure the last pahole moving stuff around is a real help or not, will mull it over a bit. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] DRM device-alloc cleanup
On Wed, Oct 9, 2013 at 3:31 PM, Dave Airlie airl...@gmail.com wrote:
On Wed, Oct 2, 2013 at 7:23 PM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
This cleans up the bus drivers in DRM. Instead of copying the device
alloc/free
semantics into each bus driver (drm_{pci,platform,usb}.c) we now have a
central
place in drm_stub.c.
This introduces drm_dev_{alloc,free,register,unregister}(). They have the
same
semantics as most other kernel subsystems. *_alloc() allocates a new device
and
populates the static fields and sub-objects. *_free() frees an unregistered
object allocated via *_alloc(). *_register() registers a DRM device and
*_unregister() obviously unregisters a DRM device. A *_free() is still needed
after calling *_unregister() (same as for struct device). No ref-counting
is
added as it is not required by any driver.
Note that the bus drivers are modified to use the new helpers directly.
However,
I didn't modify the drivers to use *_unregister() and *_free() directly.
Instead, the drm_put_dev() helper was modified to use these. Reason for that
is
that I have pending patches to make device hotplugging safer regarding mmaps.
But these aren't ready, yet. Hopefully I can get them ready for rc5 or rc6.
Tested on nouveau.
Okay I've merged this series, a follow-on to fix the AGP bits like
Daniel suggested would be good.
Actually this oopses i915 on startup, I fixed up the lack of passing
flags into drm_dev_register,
so it can be passed to load, and it seems to work now, I've squashed
my fix into the series in my tree
please read/review the series for your learning pleasure.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv4 0/5] gpu: host1x: Add runtime pm support
On 08.10.2013 09:27, Arto Merilainen wrote: This series adds runtime pm support for host1x, gr2d and dc. It retains the current behaviour if CONFIG_PM_RUNTIME is not enabled. The gr2d clock is enabled when a new job is submitted and disabled when the work is done. Due to parent-child relations between host1x-gr2d, this scheme enables and disables host1x clock. For dc, the clocks are enabled in .probe and disabled in .remove via runtime pm instead of direct clock APIs. Mayuresh is unfortunately not available to continue with the series and hence I will continue working on the patches. The series, Acked-By: Terje Bergstrom tbergst...@nvidia.com Terje ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Kconfig option to disable the legacy fbdev support
Boots Just Fine (tm)! The only glitch seems to be that at least on Fedora the boot splash gets confused and doesn't display much at all. And since there's no ugly console flickering anymore in between, the flicker while switching between X servers (VT support is still enabled) is even more jarring. Also, I'm unsure whether we don't need to somehow kick out vgacon, now that nothing else gets in the way. But stuff seems to work, so I don't care. Also everything still works as well with VGA_CONSOLE=n Also the #ifdef mess needs a bit of a cleanup, follow-up patches will do just that. To keep the Kconfig tidy, extract all the i915 options into its own file. v2: - Rebase on top of the preliminary hw support option and the intel_drv.h cleanup. - Shut up warnings in i915_debugfs.c v3: Use the right CONFIG variable, spotted by Chon Ming. Cc: Lee, Chon Ming chon.ming@intel.com Cc: David Herrmann dh.herrm...@gmail.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/Kconfig | 60 +--- drivers/gpu/drm/i915/Kconfig | 67 drivers/gpu/drm/i915/Makefile| 3 +- drivers/gpu/drm/i915/i915_debugfs.c | 9 ++--- drivers/gpu/drm/i915/i915_dma.c | 6 drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_display.c | 10 ++ drivers/gpu/drm/i915/intel_drv.h | 36 +++ 8 files changed, 122 insertions(+), 71 deletions(-) create mode 100644 drivers/gpu/drm/i915/Kconfig diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 3104b6d..b4e4fc0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -128,65 +128,7 @@ config DRM_I810 selected, the module will be called i810. AGP support is required for this driver to work. -config DRM_I915 - tristate Intel 8xx/9xx/G3x/G4x/HD Graphics - depends on DRM - depends on AGP - depends on AGP_INTEL - # we need shmfs for the swappable backing store, and in particular - # the shmem_readpage() which depends upon tmpfs - select SHMEM - select TMPFS - select DRM_KMS_HELPER - select DRM_KMS_FB_HELPER - select FB_CFB_FILLRECT - select FB_CFB_COPYAREA - select FB_CFB_IMAGEBLIT - # i915 depends on ACPI_VIDEO when ACPI is enabled - # but for select to work, need to select ACPI_VIDEO's dependencies, ick - select BACKLIGHT_LCD_SUPPORT if ACPI - select BACKLIGHT_CLASS_DEVICE if ACPI - select VIDEO_OUTPUT_CONTROL if ACPI - select INPUT if ACPI - select THERMAL if ACPI - select ACPI_VIDEO if ACPI - select ACPI_BUTTON if ACPI - help - Choose this option if you have a system that has Intel Graphics - Media Accelerator or HD Graphics integrated graphics, - including 830M, 845G, 852GM, 855GM, 865G, 915G, 945G, 965G, - G35, G41, G43, G45 chipsets and Celeron, Pentium, Core i3, - Core i5, Core i7 as well as Atom CPUs with integrated graphics. - If M is selected, the module will be called i915. AGP support - is required for this driver to work. This driver is used by - the Intel driver in X.org 6.8 and XFree86 4.4 and above. It - replaces the older i830 module that supported a subset of the - hardware in older X.org releases. - - Note that the older i810/i815 chipsets require the use of the - i810 driver instead, and the Atom z5xx series has an entirely - different implementation. - -config DRM_I915_KMS - bool Enable modesetting on intel by default - depends on DRM_I915 - help - Choose this option if you want kernel modesetting enabled by default, - and you have a new enough userspace to support this. Running old - userspaces with this enabled will cause pain. Note that this causes - the driver to bind to PCI devices, which precludes loading things - like intelfb. - -config DRM_I915_PRELIMINARY_HW_SUPPORT - bool Enable preliminary support for prerelease Intel hardware by default - depends on DRM_I915 - help - Choose this option if you have prerelease Intel hardware and want the - i915 driver to support it by default. You can enable such support at - runtime with the module option i915.preliminary_hw_support=1; this - option changes the default for that module option. - - If in doubt, say N. +source drivers/gpu/drm/i915/Kconfig config DRM_MGA tristate Matrox g200/g400 diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig new file mode 100644 index 000..6199d0b --- /dev/null +++ b/drivers/gpu/drm/i915/Kconfig @@ -0,0 +1,67 @@ +config DRM_I915 + tristate Intel 8xx/9xx/G3x/G4x/HD Graphics + depends on DRM + depends on AGP + depends on AGP_INTEL + # we need shmfs for the
Re: [PATCH 0/5] DRM device-alloc cleanup
On Wed, Oct 09, 2013 at 04:00:00PM +1000, Dave Airlie wrote:
On Wed, Oct 9, 2013 at 3:31 PM, Dave Airlie airl...@gmail.com wrote:
On Wed, Oct 2, 2013 at 7:23 PM, David Herrmann dh.herrm...@gmail.com
wrote:
Hi
This cleans up the bus drivers in DRM. Instead of copying the device
alloc/free
semantics into each bus driver (drm_{pci,platform,usb}.c) we now have a
central
place in drm_stub.c.
This introduces drm_dev_{alloc,free,register,unregister}(). They have the
same
semantics as most other kernel subsystems. *_alloc() allocates a new
device and
populates the static fields and sub-objects. *_free() frees an unregistered
object allocated via *_alloc(). *_register() registers a DRM device and
*_unregister() obviously unregisters a DRM device. A *_free() is still
needed
after calling *_unregister() (same as for struct device). No
ref-counting is
added as it is not required by any driver.
Note that the bus drivers are modified to use the new helpers directly.
However,
I didn't modify the drivers to use *_unregister() and *_free() directly.
Instead, the drm_put_dev() helper was modified to use these. Reason for
that is
that I have pending patches to make device hotplugging safer regarding
mmaps.
But these aren't ready, yet. Hopefully I can get them ready for rc5 or rc6.
Tested on nouveau.
Okay I've merged this series, a follow-on to fix the AGP bits like
Daniel suggested would be good.
Actually this oopses i915 on startup, I fixed up the lack of passing
flags into drm_dev_register,
so it can be passed to load, and it seems to work now, I've squashed
my fix into the series in my tree
please read/review the series for your learning pleasure.
Oops, shame on me for failing to spot the unconditional 0 passed for
flags. i915.ko really doesn't like that ;-)
-Daniel
--
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: [Intel-gfx] [PATCH] drm/i915: Kconfig option to disable the legacy fbdev support
On Wed, Oct 09, 2013 at 09:18:51AM +0200, Daniel Vetter wrote:
mode_fits_in_fbdev(struct drm_device *dev,
struct drm_display_mode *mode)
{
+#ifdef CONFIG_DRM_I915_FBDEV
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_i915_gem_object *obj;
struct drm_framebuffer *fb;
@@ -7338,6 +7339,9 @@ mode_fits_in_fbdev(struct drm_device *dev,
return NULL;
return fb;
+#else
+ return NULL;
+#endif
This for example is not fbdev specific. There used to be code, extracted
from this function, to sanity check that the mode fitted in the fb
provided by the user and by the bios. Which caught a few problems in the
past.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] tty/vt: add con_bind and con_unbind functions
On Tue, Oct 08, 2013 at 06:12:15PM -0300, Paulo Zanoni wrote: 2013/10/1 Ville Syrjälä ville.syrj...@linux.intel.com: On Thu, Sep 26, 2013 at 08:06:00PM -0300, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com The consoles who need to do something when unbinding or binding can optionally implement these functions. The current problem I'm trying to solve is that when i915+fbcon is loaded on Haswell, if we disable the power well (to save power) the VGA interface gets completely disabled, so when we unbind fbcon we need to restore the VGA interface to allow vgacon to work. We don't need to make it work. No one else does, and in the general case it's even impossible since on some hardware that would definitely corrupt the state that the real driver is attempting to use. The only case where it might be nice to restore vgacon is on i915 unload, but no one else does that either AFAIK, so I would not waste any cycles on attempting that. I don't understand your point. Without patches 3-4-5, module_reload doesn't work at all if the power well is disabled: we need these patches to fix it. The plan is not to restore everything to make vgacon actually work, the plan is just to prevent it from breaking module_reload. How does the power well vs. vgacon break module_reload? BTW module_reload seems to be busted on ILK and IVB too currently. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: check gem bo size when creating framebuffers
It's better to catch such fallout early, and this way we can rely on the checking done by the drm core on fb-heigh/width at modeset time. If we ever support planar formats on intel we might want to look into a common helper to do all this, but for now this is good enough. Requested-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/intel_display.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f5126b8..3073154 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -10069,6 +10069,10 @@ int intel_framebuffer_init(struct drm_device *dev, if (mode_cmd-offsets[0] != 0) return -EINVAL; + /* FIXME drm helper for size checks (especially planar formats)? */ + if (obj-base.size mode_cmd-height * mode_cmd-pitches[0]) + return -EINVAL; + drm_helper_mode_fill_fb_struct(intel_fb-base, mode_cmd); intel_fb-obj = obj; -- 1.8.4.rc3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/vmwgfx: Don't put resources with invalid id's on lru list
The evict code may try to swap them out causing a BUG in the destroy function. Signed-off-by: Thomas Hellstrom thellst...@vmware.com Reviewed-by: Jakob Bornecrantz ja...@vmware.com Cc: sta...@vger.kernel.org --- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c index 0e67cf4..37fb4be 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c @@ -970,7 +970,7 @@ void vmw_resource_unreserve(struct vmw_resource *res, if (new_backup) res-backup_offset = new_backup_offset; - if (!res-func-may_evict) + if (!res-func-may_evict || res-id == -1) return; write_lock(dev_priv-resource_lock); -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/vmwgfx: Don't kill clients on VT switch
DRI clients that tried to grab the TTM lock when the master (X server) was
switched away during a VT switch were sent the SIGTERM signal by the
kernel. Fix this so that they are only sent that signal when the master has
exited.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Reviewed-by: Jakob Bornecrantz ja...@vmware.com
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 1a90f0a..0508f93 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -740,9 +740,17 @@ static void vmw_postclose(struct drm_device *dev,
struct vmw_fpriv *vmw_fp;
vmw_fp = vmw_fpriv(file_priv);
- ttm_object_file_release(vmw_fp-tfile);
- if (vmw_fp-locked_master)
+
+ if (vmw_fp-locked_master) {
+ struct vmw_master *vmaster =
+ vmw_master(vmw_fp-locked_master);
+
+ ttm_lock_set_kill(vmaster-lock, true, SIGTERM);
+ ttm_vt_unlock(vmaster-lock);
drm_master_put(vmw_fp-locked_master);
+ }
+
+ ttm_object_file_release(vmw_fp-tfile);
kfree(vmw_fp);
}
@@ -925,14 +933,13 @@ static void vmw_master_drop(struct drm_device *dev,
vmw_fp-locked_master = drm_master_get(file_priv-master);
ret = ttm_vt_lock(vmaster-lock, false, vmw_fp-tfile);
- vmw_execbuf_release_pinned_bo(dev_priv);
-
if (unlikely((ret != 0))) {
DRM_ERROR(Unable to lock TTM at VT switch.\n);
drm_master_put(vmw_fp-locked_master);
}
- ttm_lock_set_kill(vmaster-lock, true, SIGTERM);
+ ttm_lock_set_kill(vmaster-lock, false, SIGTERM);
+ vmw_execbuf_release_pinned_bo(dev_priv);
if (!dev_priv-enable_fb) {
ret = ttm_bo_evict_mm(dev_priv-bdev, TTM_PL_VRAM);
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Kconfig option to disable the legacy fbdev support
On Wed, 09 Oct 2013, Daniel Vetter daniel.vet...@ffwll.ch wrote: Boots Just Fine (tm)! The only glitch seems to be that at least on Fedora the boot splash gets confused and doesn't display much at all. And since there's no ugly console flickering anymore in between, the flicker while switching between X servers (VT support is still enabled) is even more jarring. Also, I'm unsure whether we don't need to somehow kick out vgacon, now that nothing else gets in the way. But stuff seems to work, so I don't care. Also everything still works as well with VGA_CONSOLE=n Also the #ifdef mess needs a bit of a cleanup, follow-up patches will do just that. To keep the Kconfig tidy, extract all the i915 options into its own file. Obligatory bikeshed: I'd really like the Kconfig move to be a separate prep patch. BR, Jani. v2: - Rebase on top of the preliminary hw support option and the intel_drv.h cleanup. - Shut up warnings in i915_debugfs.c v3: Use the right CONFIG variable, spotted by Chon Ming. Cc: Lee, Chon Ming chon.ming@intel.com Cc: David Herrmann dh.herrm...@gmail.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/Kconfig | 60 +--- drivers/gpu/drm/i915/Kconfig | 67 drivers/gpu/drm/i915/Makefile| 3 +- drivers/gpu/drm/i915/i915_debugfs.c | 9 ++--- drivers/gpu/drm/i915/i915_dma.c | 6 drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_display.c | 10 ++ drivers/gpu/drm/i915/intel_drv.h | 36 +++ 8 files changed, 122 insertions(+), 71 deletions(-) create mode 100644 drivers/gpu/drm/i915/Kconfig diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 3104b6d..b4e4fc0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -128,65 +128,7 @@ config DRM_I810 selected, the module will be called i810. AGP support is required for this driver to work. -config DRM_I915 - tristate Intel 8xx/9xx/G3x/G4x/HD Graphics - depends on DRM - depends on AGP - depends on AGP_INTEL - # we need shmfs for the swappable backing store, and in particular - # the shmem_readpage() which depends upon tmpfs - select SHMEM - select TMPFS - select DRM_KMS_HELPER - select DRM_KMS_FB_HELPER - select FB_CFB_FILLRECT - select FB_CFB_COPYAREA - select FB_CFB_IMAGEBLIT - # i915 depends on ACPI_VIDEO when ACPI is enabled - # but for select to work, need to select ACPI_VIDEO's dependencies, ick - select BACKLIGHT_LCD_SUPPORT if ACPI - select BACKLIGHT_CLASS_DEVICE if ACPI - select VIDEO_OUTPUT_CONTROL if ACPI - select INPUT if ACPI - select THERMAL if ACPI - select ACPI_VIDEO if ACPI - select ACPI_BUTTON if ACPI - help - Choose this option if you have a system that has Intel Graphics - Media Accelerator or HD Graphics integrated graphics, - including 830M, 845G, 852GM, 855GM, 865G, 915G, 945G, 965G, - G35, G41, G43, G45 chipsets and Celeron, Pentium, Core i3, - Core i5, Core i7 as well as Atom CPUs with integrated graphics. - If M is selected, the module will be called i915. AGP support - is required for this driver to work. This driver is used by - the Intel driver in X.org 6.8 and XFree86 4.4 and above. It - replaces the older i830 module that supported a subset of the - hardware in older X.org releases. - - Note that the older i810/i815 chipsets require the use of the - i810 driver instead, and the Atom z5xx series has an entirely - different implementation. - -config DRM_I915_KMS - bool Enable modesetting on intel by default - depends on DRM_I915 - help - Choose this option if you want kernel modesetting enabled by default, - and you have a new enough userspace to support this. Running old - userspaces with this enabled will cause pain. Note that this causes - the driver to bind to PCI devices, which precludes loading things - like intelfb. - -config DRM_I915_PRELIMINARY_HW_SUPPORT - bool Enable preliminary support for prerelease Intel hardware by default - depends on DRM_I915 - help - Choose this option if you have prerelease Intel hardware and want the - i915 driver to support it by default. You can enable such support at - runtime with the module option i915.preliminary_hw_support=1; this - option changes the default for that module option. - - If in doubt, say N. +source drivers/gpu/drm/i915/Kconfig config DRM_MGA tristate Matrox g200/g400 diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig new file mode 100644 index 000..6199d0b --- /dev/null +++ b/drivers/gpu/drm/i915/Kconfig @@ -0,0 +1,67 @@ +config
[Bug 69463] RadeonSI : xserver crashes with Segmentation Fault
https://bugs.freedesktop.org/show_bug.cgi?id=69463 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #10 from Michel Dänzer mic...@daenzer.net --- (In reply to comment #9) The issue is resolved with upgrading mesa to latest 9.3.0-devel(git-59157d1) and with glamor-0.5.0 Looks like you were hitting this crash again in bug 69961. Was it upgrading Mesa or downgrading glamor which resolved it 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: [Intel-gfx] [PATCH] drm/i915: check gem bo size when creating framebuffers
On Wed, Oct 09, 2013 at 10:33:08AM +0200, Daniel Vetter wrote: It's better to catch such fallout early, and this way we can rely on the checking done by the drm core on fb-heigh/width at modeset time. If we ever support planar formats on intel we might want to look into a common helper to do all this, but for now this is good enough. I had a helper to do that, and I think I even posted it a few times. But it didn't take tiling into account, so I didn't feel it was quite good enough. I think this may be the last one: http://lists.freedesktop.org/archives/dri-devel/2011-December/017581.html Your patch doesn't account for tiling either. Requested-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/intel_display.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f5126b8..3073154 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -10069,6 +10069,10 @@ int intel_framebuffer_init(struct drm_device *dev, if (mode_cmd-offsets[0] != 0) return -EINVAL; + /* FIXME drm helper for size checks (especially planar formats)? */ + if (obj-base.size mode_cmd-height * mode_cmd-pitches[0]) + return -EINVAL; + drm_helper_mode_fill_fb_struct(intel_fb-base, mode_cmd); intel_fb-obj = obj; -- 1.8.4.rc3 ___ Intel-gfx mailing list intel-...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69341] [radeonsi] KDE 4.11 is EXTREMELY slow with Raster QT backend
https://bugs.freedesktop.org/show_bug.cgi?id=69341 --- Comment #13 from Michel Dänzer mic...@daenzer.net --- (In reply to comment #12) I noticed something weird: if I start KDE with desktop effects off it is *much* faster and there is corruption in the title bar. The corruption indicates it's using the native Qt backend, not Raster. Also I noticed it is much faster when I set resolution to 1920x1200 compared to 2560x1600, at least when starting KDE with desktop effects off. 2560x1600 is almost twice as many pixels as 1920x1200, so some difference in performance between them is expected. -- 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 RFC] drm/ttm: Allow vm fault retries
Make use of the FAULT_FLAG_ALLOW_RETRY flag to allow dropping the
mmap_sem while waiting for bo idle.
FAULT_FLAG_ALLOW_RETRY appears to be primarily designed for disk waits
but should work just as fine for GPU waits..
Only compile-tested so far pending comments.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 61 ++-
1 file changed, 48 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 1006c15..6510ce2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -41,6 +41,50 @@
#define TTM_BO_VM_NUM_PREFAULT 16
+static int ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
+ struct vm_area_struct *vma,
+ struct vm_fault *vmf)
+{
+ struct ttm_bo_device *bdev = bo-bdev;
+ int ret = 0;
+
+ spin_lock(bdev-fence_lock);
+ if (likely(!test_bit(TTM_BO_PRIV_FLAG_MOVING, bo-priv_flags)))
+ goto out_unlock;
+
+ /*
+* Quick non-stalling check for idle.
+*/
+ ret = ttm_bo_wait(bo, false, false, true);
+ if (likely(ret == 0))
+ goto out_unlock;
+
+ /*
+* If possible, avoid waiting for GPU with mmap_sem
+* held.
+*/
+ if (vmf-flags FAULT_FLAG_ALLOW_RETRY) {
+ ret = VM_FAULT_RETRY;
+ if (vmf-flags FAULT_FLAG_RETRY_NOWAIT)
+ goto out_unlock;
+
+ up_read(vma-vm_mm-mmap_sem);
+ (void) ttm_bo_wait(bo, false, true, false);
+ goto out_unlock;
+ }
+
+ /*
+* Ordinary wait.
+*/
+ ret = ttm_bo_wait(bo, false, true, false);
+ if (unlikely(ret != 0))
+ ret = (ret == -ERESTARTSYS) ? VM_FAULT_SIGBUS :
+ VM_FAULT_NOPAGE;
+out_unlock:
+ spin_unlock(bdev-fence_lock);
+ return ret;
+}
+
static int ttm_bo_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
struct ttm_buffer_object *bo = (struct ttm_buffer_object *)
@@ -91,19 +135,10 @@ static int ttm_bo_vm_fault(struct vm_area_struct *vma,
struct vm_fault *vmf)
* Wait for buffer data in transit, due to a pipelined
* move.
*/
-
- spin_lock(bdev-fence_lock);
- if (test_bit(TTM_BO_PRIV_FLAG_MOVING, bo-priv_flags)) {
- ret = ttm_bo_wait(bo, false, true, false);
- spin_unlock(bdev-fence_lock);
- if (unlikely(ret != 0)) {
- retval = (ret != -ERESTARTSYS) ?
- VM_FAULT_SIGBUS : VM_FAULT_NOPAGE;
- goto out_unlock;
- }
- } else
- spin_unlock(bdev-fence_lock);
-
+ retval = ttm_bo_vm_fault_idle(bo, vma, vmf);
+ if (unlikely(retval != 0))
+ goto out_unlock;
+
ret = ttm_mem_io_lock(man, true);
if (unlikely(ret != 0)) {
retval = VM_FAULT_NOPAGE;
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/radeon: fixup locking inversion between mmap_sem and reservations
op 08-10-13 18:47, Jerome Glisse schreef: On Tue, Oct 08, 2013 at 06:29:35PM +0200, Thomas Hellstrom wrote: On 10/08/2013 04:55 PM, Jerome Glisse wrote: On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote: Am 08.10.2013 16:33, schrieb Jerome Glisse: On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote: Allocate and copy all kernel memory before doing reservations. This prevents a locking inversion between mmap_sem and reservation_class, and allows us to drop the trylocking in ttm_bo_vm_fault without upsetting lockdep. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com I would say NAK. Current code only allocate temporary page in AGP case. So AGP case is userspace - temp page - cs checker - radeon ib. Non AGP is directly memcpy to radeon IB. Your patch allocate memory memcpy userspace to it and it will then be memcpy to IB. Which means you introduce an extra memcpy in the process not something we want. Totally agree. Additional to that there is no good reason to provide anything else than anonymous system memory to the CS ioctl, so the dependency between the mmap_sem and reservations are not really clear to me. Christian. I think is that in other code path you take mmap_sem first then reserve bo. But here we reserve bo and then we take mmap_sem because of copy from user. Cheers, Jerome Actually the log message is a little confusing. I think the mmap_sem locking inversion problem is orthogonal to what's being fixed here. This patch fixes the possible recursive bo::reserve caused by malicious user-space handing a pointer to ttm memory so that the ttm fault handler is called when bos are already reserved. That may cause a (possibly interruptible) livelock. Once that is fixed, we are free to choose the mmap_sem - bo::reserve locking order. Currently it's bo::reserve-mmap_sem(), but the hack required in the ttm fault handler is admittedly a bit ugly. The plan is to change the locking order to mmap_sem-bo::reserve I'm not sure if it applies to this particular case, but it should be possible to make sure that copy_from_user_inatomic() will always succeed, by making sure the pages are present using get_user_pages(), and release the pages after copy_from_user_inatomic() is done. That way there's no need for a double memcpy slowpath, but if the copied data is very fragmented I guess the resulting code may look ugly. The get_user_pages() function will return an error if it hits TTM pages. /Thomas get_user_pages + copy_from_user_inatomic is overkill. We should just do get_user_pages which fails with ttm memory and then use copy_highpage helper. I don't think we have to do anything that complicated, the easiest solution seems to be to call radeon_ib_get before calling radeon_cs_parser_relocs, and copy everything to the ib buffer before taking the reserve lock. ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: signal all fences after lockup to avoid endless waiting in GEM_WAIT
Mhm, that doesn't looks like anything related but more like the reset of the compute ring didn't worked. How often does that happen? And do you still get the problem where X waits for a fence that never comes back? Christian. Am 09.10.2013 12:36, schrieb Marek Olšák: I'm afraid your patch sometimes causes the GPU reset to fail, which had never happened before IIRC. The dmesg log from the failure is attached. Marek On Tue, Oct 8, 2013 at 6:21 PM, Christian König deathsim...@vodafone.de wrote: Hi Marek, please try the attached patch as a replacement for your signaling all fences patch. I'm not 100% sure if it fixes all issues, but it's at least a start. Thanks, Christian. Am 07.10.2013 13:08, schrieb Christian König: First of all, I can't complain about the reliability of the hardware GPU reset. It's mostly the kernel driver that happens to run into a deadlock at the same time. Alex and I spend quite some time on making this reliable again after activating more rings and adding VM support. The main problem is that I couldn't figure out where the CPU deadlock comes from, cause I couldn't reliable reproduce the issue. What is the content of /proc/pid of X server/task/*/stack and sys/kernel/debug/dri/0/radeon_fence_info when the X server is stuck in the deadlock situation? I'm pretty sure that we nearly always have a problem when two threads are waiting for fences on one of them detects that we have a lockup while the other one keeps holding the exclusive lock. Signaling all fences might work around that problem, but it probably would be better to fix the underlying issue. Going to take a deeper look into it. Christian. Am 03.10.2013 02:45, schrieb Marek Olšák: First of all, I can't complain about the reliability of the hardware GPU reset. It's mostly the kernel driver that happens to run into a deadlock at the same time. Regarding the issue with fences, the problem is that the GPU reset completes successfully according to dmesg, but X doesn't respond. I can move the cursor on the screen, but I can't do anything else and the UI is frozen. gdb says that X is stuck in GEM_WAIT_IDLE. I can easily reproduce this, because it's the most common reason why a GPU lockup leads to frozen X. The GPU actually recovers, but X is hung. I can't tell whether the fences are just not signalled or whether there is actually a real CPU deadlock I can't see. This patch makes the problem go away and GPU resets are successful (except for extreme cases, see below). With a small enough lockup timeout, the lockups are just a minor annoyance and I thought I could get through a piglit run just with a few tens or hundreds of GPU resets... A different type of deadlock showed up, though it needs a lot of concurrently-running apps like piglit. What happened is that the kernel driver was stuck/deadlocked in radeon_cs_ioctl presumably due to a GPU hang while holding onto the exclusive lock, and another thread wanting to do the GPU reset was unable to acquire the lock. That said, I will use the patch locally, because it helps a lot. I got a few lockups while writing this email and I'm glad I didn't have to reboot. Marek On Wed, Oct 2, 2013 at 4:50 PM, Christian König deathsim...@vodafone.de wrote: Possible, but I would rather guess that this doesn't work because the IB test runs into a deadlock situation and so the GPU reset never fully completes. Can you reproduce the problem? If you want to make GPU resets more reliable I would rather suggest to remove the ring lock dependency. Then we should try to give all the fence wait functions a (reliable) timeout and move reset handling a layer up into the ioctl functions. But for this you need to rip out the old PM code first. Christian. Marek Olšák mar...@gmail.com schrieb: I'm afraid signalling the fences with an IB test is not reliable. Marek On Wed, Oct 2, 2013 at 3:52 PM, Christian König deathsim...@vodafone.de wrote: NAK, after recovering from a lockup the first thing we do is signalling all remaining fences with an IB test. If we don't recover we indeed signal all fences manually. Signalling all fences regardless of the outcome of the reset creates problems with both types of partial resets. Christian. Marek Olšák mar...@gmail.com schrieb: From: Marek Olšák marek.ol...@amd.com After a lockup, fences are not signalled sometimes, causing the GEM_WAIT_IDLE ioctl to never return, which sometimes results in an X server freeze. This fixes only one of many deadlocks which can occur during a lockup. Signed-off-by: Marek Olšák marek.ol...@amd.com --- drivers/gpu/drm/radeon/radeon_device.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 841d0e0..7b97baa 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -1552,6 +1552,11 @@ int radeon_gpu_reset(struct radeon_device *rdev) radeon_save_bios_scratch_regs(rdev);
[PATCH 0/3] gpu: host1x: Add syncpoint base support
The host1x driver uses currently syncpoints statically from host1x point of view. If we do a wait inside a job, it always has a constant value to wait. host1x supports also doing relative syncpoint waits with respect to syncpoint bases. This allows doing multiple operations inside a single submit and waiting an operation to complete before moving to next one. This set of patches adds support for syncpoint bases to host1x driver and enables the support for gr2d client. The series is based on 3.12-rc4. I have tested the series using the host1x test application (available at [0], function test_wait_base() in tests/tegra/host1x/tegra_host1x_test.c) on cardhu. I would appreciate help in reviewing the series and testing the patches on other boards. [0] https://gitorious.org/linux-host1x/libdrm-host1x Arto Merilainen (3): gpu: host1x: Add syncpoint base support drm/tegra: Deliver syncpoint base to user space drm/tegra: Reserve base for gr2d drivers/gpu/host1x/dev.h | 2 ++ drivers/gpu/host1x/drm/drm.c | 2 ++ drivers/gpu/host1x/drm/gr2d.c | 2 +- drivers/gpu/host1x/hw/channel_hw.c | 19 +++ drivers/gpu/host1x/hw/hw_host1x01_uclass.h | 6 drivers/gpu/host1x/syncpt.c| 55 +++--- drivers/gpu/host1x/syncpt.h| 10 ++ include/uapi/drm/tegra_drm.h | 4 ++- 8 files changed, 93 insertions(+), 7 deletions(-) -- 1.8.1.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] gpu: host1x: Add syncpoint base support
This patch adds support for hardware syncpoint bases. This creates
a simple mechanism for waiting an operation to complete in the middle
of the command buffer.
Signed-off-by: Arto Merilainen amerilai...@nvidia.com
---
drivers/gpu/host1x/dev.h | 2 ++
drivers/gpu/host1x/hw/channel_hw.c | 19 +++
drivers/gpu/host1x/hw/hw_host1x01_uclass.h | 6
drivers/gpu/host1x/syncpt.c| 55 +++---
drivers/gpu/host1x/syncpt.h| 10 ++
5 files changed, 87 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index bed90a8..89a3c1e 100644
--- a/drivers/gpu/host1x/dev.h
+++ b/drivers/gpu/host1x/dev.h
@@ -26,6 +26,7 @@
#include cdma.h
#include job.h
+struct host1x_base;
struct host1x_syncpt;
struct host1x_channel;
struct host1x_cdma;
@@ -102,6 +103,7 @@ struct host1x {
void __iomem *regs;
struct host1x_syncpt *syncpt;
+ struct host1x_base *bases;
struct device *dev;
struct clk *clk;
diff --git a/drivers/gpu/host1x/hw/channel_hw.c
b/drivers/gpu/host1x/hw/channel_hw.c
index ee19962..5f9f735 100644
--- a/drivers/gpu/host1x/hw/channel_hw.c
+++ b/drivers/gpu/host1x/hw/channel_hw.c
@@ -67,6 +67,21 @@ static void submit_gathers(struct host1x_job *job)
}
}
+static inline void synchronize_syncpt_base(struct host1x_job *job)
+{
+ struct host1x_channel *ch = job-channel;
+ struct host1x *host = dev_get_drvdata(ch-dev-parent);
+ struct host1x_syncpt *sp = host-syncpt + job-syncpt_id;
+ u32 base_id = sp-base-id;
+ u32 base_val = host1x_syncpt_read_max(sp);
+
+ host1x_cdma_push(ch-cdma,
+host1x_opcode_setclass(HOST1X_CLASS_HOST1X,
+ host1x_uclass_load_syncpt_base_r(), 1),
+host1x_uclass_load_syncpt_base_base_indx_f(base_id) |
+host1x_uclass_load_syncpt_base_value_f(base_val));
+}
+
static int channel_submit(struct host1x_job *job)
{
struct host1x_channel *ch = job-channel;
@@ -118,6 +133,10 @@ static int channel_submit(struct host1x_job *job)
host1x_syncpt_read_max(sp)));
}
+ /* Synchronize base register to allow using it for relative waiting */
+ if (sp-base)
+ synchronize_syncpt_base(job);
+
syncval = host1x_syncpt_incr_max(sp, user_syncpt_incrs);
job-syncpt_end = syncval;
diff --git a/drivers/gpu/host1x/hw/hw_host1x01_uclass.h
b/drivers/gpu/host1x/hw/hw_host1x01_uclass.h
index 42f3ce1..f755359 100644
--- a/drivers/gpu/host1x/hw/hw_host1x01_uclass.h
+++ b/drivers/gpu/host1x/hw/hw_host1x01_uclass.h
@@ -111,6 +111,12 @@ static inline u32
host1x_uclass_wait_syncpt_base_offset_f(u32 v)
}
#define HOST1X_UCLASS_WAIT_SYNCPT_BASE_OFFSET_F(v) \
host1x_uclass_wait_syncpt_base_offset_f(v)
+static inline u32 host1x_uclass_load_syncpt_base_r(void)
+{
+ return 0xb;
+}
+#define HOST1X_UCLASS_LOAD_SYNCPT_BASE \
+ host1x_uclass_load_syncpt_base_r()
static inline u32 host1x_uclass_load_syncpt_base_base_indx_f(u32 v)
{
return (v 0xff) 24;
diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
index 409745b..48927b1 100644
--- a/drivers/gpu/host1x/syncpt.c
+++ b/drivers/gpu/host1x/syncpt.c
@@ -30,9 +30,32 @@
#define SYNCPT_CHECK_PERIOD (2 * HZ)
#define MAX_STUCK_CHECK_COUNT 15
+static struct host1x_base *host1x_base_alloc(struct host1x *host)
+{
+ struct host1x_base *base = host-bases;
+ int i;
+
+ for (i = 0; i host-info-nb_bases base-reserved; i++, base++)
+ ;
+
+ if (i = host-info-nb_bases)
+ return NULL;
+
+ base-reserved = true;
+ return base;
+}
+
+static void host1x_base_free(struct host1x_base *base)
+{
+ if (!base)
+ return;
+ base-reserved = false;
+}
+
static struct host1x_syncpt *_host1x_syncpt_alloc(struct host1x *host,
struct device *dev,
- bool client_managed)
+ bool client_managed,
+ bool support_base)
{
int i;
struct host1x_syncpt *sp = host-syncpt;
@@ -44,6 +67,12 @@ static struct host1x_syncpt *_host1x_syncpt_alloc(struct
host1x *host,
if (i = host-info-nb_pts)
return NULL;
+ if (support_base) {
+ sp-base = host1x_base_alloc(host);
+ if (!sp-base)
+ return NULL;
+ }
+
name = kasprintf(GFP_KERNEL, %02d-%s, sp-id,
dev ? dev_name(dev) : NULL);
if (!name)
@@ -304,24 +333,31 @@ int host1x_syncpt_patch_wait(struct host1x_syncpt *sp,
void *patch_addr)
int host1x_syncpt_init(struct host1x *host)
{
struct host1x_syncpt
[PATCH 2/3] drm/tegra: Deliver syncpoint base to user space
This patch makes the necessary additions to deliver syncpoint base
to the user space.
This patch splits the index field in the drm_tegra_get_syncpt structure
into three separate fields (index, support_base, base_id). This allows
to keep compatibility over kernel versions:
- The placing of index field stays constant and therefore the interface
should stay compatible with earlier userspace versions.
- The old index field was input-only and it was not supposed to be read
afterwards. Delivering data back in the same field should not introduce
regressions to any old user space applications.
- Old kernels left support_base and base_id fields intact (zero) and
hence the new user space applications get the correct response from
the kernel (=syncpoint does not have a base).
Signed-off-by: Arto Merilainen amerilai...@nvidia.com
---
drivers/gpu/host1x/drm/drm.c | 2 ++
include/uapi/drm/tegra_drm.h | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
index 8c61cee..4251563 100644
--- a/drivers/gpu/host1x/drm/drm.c
+++ b/drivers/gpu/host1x/drm/drm.c
@@ -468,6 +468,8 @@ static int tegra_get_syncpt(struct drm_device *drm, void
*data,
syncpt = context-client-syncpts[args-index];
args-id = host1x_syncpt_id(syncpt);
+ args-support_base = syncpt-base ? 1 : 0;
+ args-base_id = syncpt-base ? syncpt-base-id : 0;
return 0;
}
diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index 73bde4e..7a79ca5 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -61,7 +61,9 @@ struct drm_tegra_close_channel {
struct drm_tegra_get_syncpt {
__u64 context;
- __u32 index;
+ __u16 index;
+ __u8 support_base;
+ __u8 base_id;
__u32 id;
};
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/tegra: Reserve base for gr2d
This patch modifies the gr2d to reserve a base for syncpoint.
Signed-off-by: Arto Merilainen amerilai...@nvidia.com
---
drivers/gpu/host1x/drm/gr2d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/host1x/drm/gr2d.c b/drivers/gpu/host1x/drm/gr2d.c
index 27ffcf1..f0c3fd5 100644
--- a/drivers/gpu/host1x/drm/gr2d.c
+++ b/drivers/gpu/host1x/drm/gr2d.c
@@ -285,7 +285,7 @@ static int gr2d_probe(struct platform_device *pdev)
if (!gr2d-channel)
return -ENOMEM;
- *syncpts = host1x_syncpt_request(dev, false);
+ *syncpts = host1x_syncpt_request_based(dev, false);
if (!(*syncpts)) {
host1x_channel_free(gr2d-channel);
return -ENOMEM;
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: signal all fences after lockup to avoid endless waiting in GEM_WAIT
The ring test of the first compute ring always fails and it shouldn't affect the GPU reset in any way. I can't tell if the deadlock issue is fixed, because the GPU reset usually fails with your patch. It always succeeded without your patch. Marek On Wed, Oct 9, 2013 at 1:09 PM, Christian König deathsim...@vodafone.de wrote: Mhm, that doesn't looks like anything related but more like the reset of the compute ring didn't worked. How often does that happen? And do you still get the problem where X waits for a fence that never comes back? Christian. Am 09.10.2013 12:36, schrieb Marek Olšák: I'm afraid your patch sometimes causes the GPU reset to fail, which had never happened before IIRC. The dmesg log from the failure is attached. Marek On Tue, Oct 8, 2013 at 6:21 PM, Christian König deathsim...@vodafone.de wrote: Hi Marek, please try the attached patch as a replacement for your signaling all fences patch. I'm not 100% sure if it fixes all issues, but it's at least a start. Thanks, Christian. Am 07.10.2013 13:08, schrieb Christian König: First of all, I can't complain about the reliability of the hardware GPU reset. It's mostly the kernel driver that happens to run into a deadlock at the same time. Alex and I spend quite some time on making this reliable again after activating more rings and adding VM support. The main problem is that I couldn't figure out where the CPU deadlock comes from, cause I couldn't reliable reproduce the issue. What is the content of /proc/pid of X server/task/*/stack and sys/kernel/debug/dri/0/radeon_fence_info when the X server is stuck in the deadlock situation? I'm pretty sure that we nearly always have a problem when two threads are waiting for fences on one of them detects that we have a lockup while the other one keeps holding the exclusive lock. Signaling all fences might work around that problem, but it probably would be better to fix the underlying issue. Going to take a deeper look into it. Christian. Am 03.10.2013 02:45, schrieb Marek Olšák: First of all, I can't complain about the reliability of the hardware GPU reset. It's mostly the kernel driver that happens to run into a deadlock at the same time. Regarding the issue with fences, the problem is that the GPU reset completes successfully according to dmesg, but X doesn't respond. I can move the cursor on the screen, but I can't do anything else and the UI is frozen. gdb says that X is stuck in GEM_WAIT_IDLE. I can easily reproduce this, because it's the most common reason why a GPU lockup leads to frozen X. The GPU actually recovers, but X is hung. I can't tell whether the fences are just not signalled or whether there is actually a real CPU deadlock I can't see. This patch makes the problem go away and GPU resets are successful (except for extreme cases, see below). With a small enough lockup timeout, the lockups are just a minor annoyance and I thought I could get through a piglit run just with a few tens or hundreds of GPU resets... A different type of deadlock showed up, though it needs a lot of concurrently-running apps like piglit. What happened is that the kernel driver was stuck/deadlocked in radeon_cs_ioctl presumably due to a GPU hang while holding onto the exclusive lock, and another thread wanting to do the GPU reset was unable to acquire the lock. That said, I will use the patch locally, because it helps a lot. I got a few lockups while writing this email and I'm glad I didn't have to reboot. Marek On Wed, Oct 2, 2013 at 4:50 PM, Christian König deathsim...@vodafone.de wrote: Possible, but I would rather guess that this doesn't work because the IB test runs into a deadlock situation and so the GPU reset never fully completes. Can you reproduce the problem? If you want to make GPU resets more reliable I would rather suggest to remove the ring lock dependency. Then we should try to give all the fence wait functions a (reliable) timeout and move reset handling a layer up into the ioctl functions. But for this you need to rip out the old PM code first. Christian. Marek Olšák mar...@gmail.com schrieb: I'm afraid signalling the fences with an IB test is not reliable. Marek On Wed, Oct 2, 2013 at 3:52 PM, Christian König deathsim...@vodafone.de wrote: NAK, after recovering from a lockup the first thing we do is signalling all remaining fences with an IB test. If we don't recover we indeed signal all fences manually. Signalling all fences regardless of the outcome of the reset creates problems with both types of partial resets. Christian. Marek Olšák mar...@gmail.com schrieb: From: Marek Olšák marek.ol...@amd.com After a lockup, fences are not signalled sometimes, causing the GEM_WAIT_IDLE ioctl to never return, which sometimes results in an X server freeze. This fixes only one of many deadlocks which can occur during a lockup. Signed-off-by: Marek Olšák
[PATCH] drm: Fix typo in debug message
Fix a typo (iotcl - ioctl) in the debug message when an unknown IOCTL is encountered. Signed-off-by: Thierry Reding tred...@nvidia.com --- drivers/gpu/drm/drm_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index e79d8d9..e8737c0 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -467,7 +467,7 @@ long drm_ioctl(struct file *filp, err_i1: if (!ioctl) - DRM_DEBUG(invalid iotcl: pid=%d, dev=0x%lx, auth=%d, cmd=0x%02x, nr=0x%02x\n, + DRM_DEBUG(invalid ioctl: pid=%d, dev=0x%lx, auth=%d, cmd=0x%02x, nr=0x%02x\n, task_pid_nr(current), (long)old_encode_dev(file_priv-minor-device), file_priv-authenticated, cmd, nr); -- 1.8.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v2] drm/radeon: fixup locking inversion between, mmap_sem and reservations
op 08-10-13 18:58, Thomas Hellstrom schreef:
On 10/08/2013 06:47 PM, Jerome Glisse wrote:
On Tue, Oct 08, 2013 at 06:29:35PM +0200, Thomas Hellstrom wrote:
On 10/08/2013 04:55 PM, Jerome Glisse wrote:
On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote:
Am 08.10.2013 16:33, schrieb Jerome Glisse:
On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
Allocate and copy all kernel memory before doing reservations. This
prevents a locking
inversion between mmap_sem and reservation_class, and allows us to drop
the trylocking
in ttm_bo_vm_fault without upsetting lockdep.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
I would say NAK. Current code only allocate temporary page in AGP case.
So AGP case is userspace - temp page - cs checker - radeon ib.
Non AGP is directly memcpy to radeon IB.
Your patch allocate memory memcpy userspace to it and it will then be
memcpy to IB. Which means you introduce an extra memcpy in the process
not something we want.
Totally agree. Additional to that there is no good reason to provide
anything else than anonymous system memory to the CS ioctl, so the
dependency between the mmap_sem and reservations are not really
clear to me.
Christian.
I think is that in other code path you take mmap_sem first then reserve
bo. But here we reserve bo and then we take mmap_sem because of copy
from user.
Cheers,
Jerome
Actually the log message is a little confusing. I think the mmap_sem
locking inversion problem is orthogonal to what's being fixed here.
This patch fixes the possible recursive bo::reserve caused by
malicious user-space handing a pointer to ttm memory so that the ttm
fault handler is called when bos are already reserved. That may
cause a (possibly interruptible) livelock.
Once that is fixed, we are free to choose the mmap_sem -
bo::reserve locking order. Currently it's bo::reserve-mmap_sem(),
but the hack required in the ttm fault handler is admittedly a bit
ugly. The plan is to change the locking order to
mmap_sem-bo::reserve
I'm not sure if it applies to this particular case, but it should be
possible to make sure that copy_from_user_inatomic() will always
succeed, by making sure the pages are present using
get_user_pages(), and release the pages after
copy_from_user_inatomic() is done. That way there's no need for a
double memcpy slowpath, but if the copied data is very fragmented I
guess the resulting code may look ugly. The get_user_pages()
function will return an error if it hits TTM pages.
/Thomas
get_user_pages + copy_from_user_inatomic is overkill. We should just
do get_user_pages which fails with ttm memory and then use copy_highpage
helper.
Cheers,
Jerome
Yeah, it may well be that that's the preferred solution.
/Thomas
I still disagree, and shuffled radeon_ib_get around to be called sooner.
How does the patch below look?
8---
Allocate and copy all kernel memory before doing reservations. This prevents a
locking
inversion between mmap_sem and reservation_class, and allows us to drop the
trylocking
in ttm_bo_vm_fault without upsetting lockdep.
Changes since v1:
- Kill extra memcpy for !AGP case.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/radeon/r600_cs.c | 16 +-
drivers/gpu/drm/radeon/radeon.h| 15 +-
drivers/gpu/drm/radeon/radeon_cs.c | 298 -
3 files changed, 106 insertions(+), 223 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 01a3ec8..1abaa2b 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -2328,13 +2328,8 @@ static void r600_cs_parser_fini(struct radeon_cs_parser
*parser, int error)
unsigned i;
kfree(parser-relocs);
- for (i = 0; i parser-nchunks; i++) {
- kfree(parser-chunks[i].kdata);
- if (parser-rdev (parser-rdev-flags RADEON_IS_AGP)) {
- kfree(parser-chunks[i].kpage[0]);
- kfree(parser-chunks[i].kpage[1]);
- }
- }
+ for (i = 0; i parser-nchunks; i++)
+ drm_free_large(parser-chunks[i].kdata);
kfree(parser-chunks);
kfree(parser-chunks_array);
}
@@ -2391,13 +2386,12 @@ int r600_cs_legacy(struct drm_device *dev, void *data,
struct drm_file *filp,
ib_chunk = parser.chunks[parser.chunk_ib_idx];
parser.ib.length_dw = ib_chunk-length_dw;
*l = parser.ib.length_dw;
- r = r600_cs_parse(parser);
- if (r) {
- DRM_ERROR(Invalid command stream !\n);
+ if (DRM_COPY_FROM_USER(ib, ib_chunk-user_ptr, ib_chunk-length_dw *
4)) {
+ r = -EFAULT;
r600_cs_parser_fini(parser, r);
return r;
}
- r = radeon_cs_finish_pages(parser);
+ r = r600_cs_parse(parser);
if (r) {
DRM_ERROR(Invalid
[Bug 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 --- Comment #20 from Alex Deucher ag...@yahoo.com --- Does attachment 86939 from bug 57919 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 70035] GPU Lockup on AMD RS880 HD4200
https://bugs.freedesktop.org/show_bug.cgi?id=70035 Tasev tasev.stefano...@skynet.be changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- --- Comment #13 from Tasev tasev.stefano...@skynet.be --- Hi, I was just lucky yesterday. Today during boot the gpu lockup once again for 10 seconds, after that the boot goes normaly. The dmesg is attached. I update again the system now to version 9.3~git1310080951.20bf50+glvdpau~gd~p from the oibaf ppa. I use the system normaly for 15 minutes now. -- 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 70035] GPU Lockup on AMD RS880 HD4200
https://bugs.freedesktop.org/show_bug.cgi?id=70035 --- Comment #14 from Tasev tasev.stefano...@skynet.be --- Created attachment 87338 -- https://bugs.freedesktop.org/attachment.cgi?id=87338action=edit dmesg-3.12rc4.txt The lockup occurs at the 34 seconds of the boot process -- 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 62721] GPU lockup: radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec...
https://bugzilla.kernel.org/show_bug.cgi?id=62721 --- Comment #4 from Alex Deucher alexdeuc...@gmail.com --- (In reply to Egor Y. Egorov from comment #3) (In reply to Alex Deucher from comment #2) Please attach your full dmesg output. Why journalctl -a not enough? If that need I'll post dmesg soon. That's fine. No need for dmesg output. -- 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 v2 0/2] drm: omap: Fix omapdrm probe and module insertion/removal issues
Hi Rob, On Monday 07 October 2013 03:08 PM, Archit Taneja wrote: With the new omapdss device model. The user(omapdrm/omapfb) of a omap_dss_device has to call connect() to use the device. A connect() call can request to defer probe if the device(or the previous entities in the chain) have missing resources like a regulator or an I2C bus. We make omapdrm defer probe by trying to first connect all panels, and request for deferral if any panel requests for a defer. This makes sure that all the panels are set up correctly when we finally proceed with omapdrm initialization. In order for omapdrm module to be removed successfully, we need to disconnect the panels which omapdrm connected. Another thing noticed was that omapdrm insertion followed by some usage results in panels getting enabled. Trying to remove omapdrm with a panel enabled results in failure while disconnecting. This leaves omapdss panels in a bad state. I have added an explicit panel disable in the omap_encoder_destroy() op, I needed some suggestions on whether there is a better way to do this. changes in v2: - Add special case when no panels are available to connect. - Make sure panels are diabled (and then disconnected) when omapdrm is removed omapdrm fails when built-in in 3.12, the first patch fixes this. The second one fixes issues seen with successive module insertion and removals. It'll be great if the first one can at least make it to 3.12. Could you have a look at it? Thanks, Archit ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 --- Comment #21 from stevenvandenbrandenst...@gmail.com --- im sorry to ask but the patch is for the kernel or for this ati-dri (in archlinux) driver? -- 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 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 --- Comment #22 from Alex Deucher ag...@yahoo.com --- kernel. -- 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: [Linaro-mm-sig] thoughts of looking at android fences
Hey,
op 08-10-13 19:37, John Stultz schreef:
On Wed, Oct 2, 2013 at 11:13 AM, Erik Gilling konk...@android.com wrote:
On Wed, Oct 2, 2013 at 12:35 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Depending on feedback I'll try reflashing my nexus 7 to stock android, and
work on trying to convert android
syncpoints to dma-fence, which I'll probably rename to syncpoints.
I thought the plan decided at plumbers was to investigate backing
dma_buf with the android sync solution not the other way around. It
doesn't make sense to me to take a working, tested, end-to-end
solution with a released compositing system built around it, throw it
out, and replace it with new un-tested code to
support a system which is not yet built.
Hey Erik,
Thanks for the clarifying points in your email, your insights and
feedback are critical, and I think having you and Maarten continue to
work out the details here will make this productive.
My recollection from the discussion was that Rob was ok with trying to
pipe the sync arguments through the various interfaces in order to
support the explicit sync, but I think he did suggest having it backed
by the dma-buf fences underneath.
I know this can be frustrating to watch things be reimplemented when
you have a pre-baked solution, but some compromise will be needed to
get things merged (and Maarten is taking the initiative here), but its
important to keep discussing this so the *right* compromises are made
that don't hurt performance, etc.
My hope is Maarten's approach of getting the dma-fence core
integrated, and then moving the existing Android sync interface over
to the shared back-end, will allow for proper apples-to-apples
comparisons of the same interface. And if the functionality isn't
sufficient we can hold off on merging the sync interface conversion
until that gets resolved.
Yeah, I'm trying to understand the android side too. I think a unified
interface would benefit both. I'm
toying a bit with the sw_sync driver in staging because it's the easiest to try
out on my desktop.
The timeline stuff looks like it could be simplified. The main difference that
there seems to be is that
I didn't want to create a separate timeline struct for synchronization but let
the drivers handle it.
If you use rcu for reference lifetime management of timeline, the kref can be
dropped. Signalling all
syncpts on timeline destroy to a new destroyed state would kill the need for a
destroyed member.
The active list is unneeded and can be killed if only a linear progression of
child_list is allowed.
Which probably leaves this nice structure:
struct sync_timeline {
const struct sync_timeline_ops*ops;
charname[32];
struct list_headchild_list_head;
spinlock_tchild_list_lock;
struct list_headsync_timeline_list;
};
Where name, and sync_timeline_list are nice for debugging, but I guess not
necessarily required. so that
could be split out into a separate debugfs thing if required. I've moved the
pointer to ops to the fence
for dma-fence, which leaves this..
struct sync_timeline {
struct list_headchild_list_head;
spinlock_tchild_list_lock;
struct sync_timeline_debug {
struct list_headsync_timeline_list;
char name[32];
};
};
Hm, this looks familiar, the drm drivers had some structure for protecting the
active fence list that has
an identical definition, but with a slightly different list offset..
struct __wait_queue_head {
spinlock_t lock;
struct list_head task_list;
};
typedef struct __wait_queue_head wait_queue_head_t;
This is nicer to convert the existing drm drivers, which already implement
synchronous wait with a waitqueue.
The default wait op is in fact
Ok enough of this little excercise. I just wanted to see how different the 2
are. I think even if the
fence interface will end up being incompatible it wouldn't be too hard to
convert android..
Main difference is the ops, android has a lot more than what I used for
dma-fence:
struct fence_ops {
bool (*enable_signaling)(struct fence *fence); // required, callback
called with fence-lock held,
// fence-lock is a pointer passed to __fence_init. Callback should
make sure that the fence will
// be signaled asap.
bool (*signaled)(struct fence *fence); // optional, but if set to NULL
fence_is_signaled is not
// required to ever return true, unless enable_signaling is called,
similar to has_signaled
long (*wait)(struct fence *fence, bool intr, signed long timeout); //
required, but it can be set
// to the default fence_default_wait implementation which is
recommended. It calls enable_signaling
// and appends itself to async callback list. Identical semantics to
wait_event_interruptible_timeout.
void (*release)(struct fence *fence); // free_pt
};
Because every fence has a stamp, there is no need for a
Re: [PATCH 0/5] Armada DRM stuff
On Wed, Oct 9, 2013 at 10:31 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Oct 07, 2013 at 11:47:55PM +0200, Sebastian Hesselbarth wrote: On 10/07/2013 12:07 AM, Russell King - ARM Linux wrote: The Armada DRM drivers again, along with the TDA998x HDMI output support, and an illustration to show how to add Armada 610 support (and others.) Rob has looked at this a couple of times since its last posting, and has provided additional useful feedback which has been incorporated. I believe all the major issues have been addressed now. Tested-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com on Marvell Armada 510, SolidRun CuBox with quick-hack DT support added. Let's please get this driver mainlined and start working on proper DT support for it. Thanks for driver and the patience to work out all issues! Sebastian, I've added your tested-by now, and also updated the TDA998x patch to use the HDMI definitions that Jean-Francois pointed out (which is a really small delta, so isn't worth resending the patch set just for that). Thanks. All the points brought up in previous reviews concerning the physical address exposure, and the location of the DRM helpers have all been addressed, so it is now ready to be merged into mainline. So now the question is how to proceed with it. However, I see no response from any DRM developers, even though they are around - they've been responding on a different thread about driver model/sysfs abuse by DRM. I'm going to pull it into my nightly build tree so it can have some testing with non-dove builds, and if there's still no response from DRM people next week, I'll put it in to linux-next via my tree so at least it can get some exposure and integration validation there. fyi, I think this is in pretty good shape.. I've reviewed earlier versions, and had an initial look at this version which addresses my concerns, although I still intend to give a closer review of the final version (still on my TODO list, but we have a bit of time before 3.13 merge window.. I should at least get to it by the weekend) BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68792] Problems during playback of h264 files using UVD and VLC on AMD E-350 CPU
https://bugs.freedesktop.org/show_bug.cgi?id=68792 --- Comment #4 from Dieter Nützel die...@nuetzel-hh.de --- With this landed, I get this with vlc on my RV730 AGP: vlc /data/Filme/Serenity\ -\ HD\ DVD\ Trailer.mp4 VLC media player 2.1.0 Rincewind (revision 2.1.0-0-gedd8835) [0x9a2ee58] main interface error: no suitable interface module [0x99393f8] main libvlc error: interface globalhotkeys,none initialization failed [0x99393f8] main libvlc: VLC wird mit dem Standard-Interface ausgeführt. Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden. [0xb4930640] avcodec decoder: Using G3DVL VDPAU Driver Shared Library version 1.0 for hardware decoding. [0xb4930640] avcodec decoder: Using G3DVL VDPAU Driver Shared Library version 1.0 for hardware decoding. [0xb49402c0] main vout display error: Failed to resize display [0x9c6b780] vdpau generic error: surface copy failure: No backend implementation could be loaded. [0x9c6b780] vdpau generic error: surface copy failure: No backend implementation could be loaded. [0x9c6b780] vdpau generic error: surface copy failure: No backend implementation could be loaded. [-] mplayer can...;-) /opt/mesa mplayer -vo vdpau /data/Filme/Serenity\ -\ HD\ DVD\ Trailer.mp4 MPlayer dev-SVN-r35127-4.7-openSUSE Linux 12.3 (i586)-Packman (C) 2000-2012 MPlayer Team Can't open joystick device /dev/input/js0: No such file or directory Can't init input joystick mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Loading extension-related profile 'vo.vdpau' Playing /data/Filme/Serenity - HD DVD Trailer.mp4. libavformat version 54.25.104 (internal) libavformat file format detected. [mov,mp4,m4a,3gp,3g2,mj2 @ 0x8abc120]max_analyze_duration 500 reached at 5005000 [lavf] stream 0: video (h264), -vid 0 [lavf] stream 1: audio (aac), -aid 0, -alang und [lavf] stream 2: video (mjpeg), -vid 1 VIDEO: [H264] 1280x720 24bpp 23.976 fps 4674.1 kbps (570.6 kbyte/s) Clip info: major_brand: isom minor_version: 1 compatible_brands: isomavc1 creation_time: 1937-04-23 22:52:15 genre: Trailer artist: Universal Pictures title: Serenity - HD DVD Trailer date: 2005 Load subtitles in /data/Filme/ == Forced video codec: ffmpeg12vdpau Forced video codec: ffwmv3vdpau Forced video codec: ffvc1vdpau Forced video codec: ffh264vdpau Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family libavcodec version 54.54.100 (internal) Selected video codec: [ffh264vdpau] vfm: ffmpeg (FFmpeg H.264 (VDPAU)) == == Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 48000 Hz, 2 ch, s16le, 127.5 kbit/8.30% (ratio: 15942-192000) Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio)) == AO: [pulse] 48000Hz 2ch s16le (2 bytes per sample) Starting playback... [VD_FFMPEG] Trying pixfmt=0. Movie-Aspect is undefined - no prescaling applied. VO: [vdpau] 1280x720 = 1280x720 H.264 VDPAU acceleration [VD_FFMPEG] XVMC-accelerated MPEG-2. A: 1.0 V: 1.0 A-V: 0.004 ct: 0.007 0/ 0 465% 17% 0.6% 3 0 Exiting... (Quit) Inconsistency detected by ld.so: dl-close.c: 765: _dl_close: Assertion `map-l_init_called' failed! But much better support, now. Thank you! -Dieter -- 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: nouveau: fix nvbe leakage
Rather, the first member of nvbe is ttm (same address). Got it.
Please, disregard this patch. Thank you.
Geyslan Gregório Bem
hackingbits.com
2013/10/7 Ben Skeggs bske...@redhat.com:
- Original Message -
From: Geyslan Gregório Bem geys...@gmail.com
To: Felipe Pena felipe...@gmail.com
Cc: Ben Skeggs bske...@redhat.com, airl...@linux.ie,
dri-devel@lists.freedesktop.org,
linux-ker...@vger.kernel.org, kernel-br kernel...@googlegroups.com
Sent: Tuesday, 8 October, 2013 9:39:02 AM
Subject: Re: [PATCH] drm: nouveau: fix nvbe leakage
Felipe, thank you too.
I realized this after a code review.
Ben, what do you think?
Geyslan Gregório Bem
hackingbits.com
2013/10/7 Felipe Pena felipe...@gmail.com:
Hi,
On Mon, Oct 7, 2013 at 7:35 PM, Ben Skeggs bske...@redhat.com wrote:
- Original Message -
From: Geyslan G. Bem geys...@gmail.com
To: airl...@linux.ie, bske...@redhat.com, dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org, kernel...@googlegroups.com, Geyslan G.
Bem geys...@gmail.com
Sent: Tuesday, 8 October, 2013 8:14:26 AM
Subject: [PATCH] drm: nouveau: fix nvbe leakage
Free memory allocated to nvbe when returning NULL.
Signed-off-by: Geyslan G. Bem geys...@gmail.com
NACK. ttm_dma_tt_init() calls the destructor if it fails, which frees the
memory.
Ben.
But ttm_tt_destroy() just handles the ttm_tt part from nvbe, the nvbe
pointer itself is not being free'd.
Actually look at ttm_tt_destroy() and you'll see that right at the end it
goes ttm-func-destroy(ttm), which is nouveau_sgdma_destroy().
Ben.
---
drivers/gpu/drm/nouveau/nouveau_sgdma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
index 0843ebc..af8b66d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -105,6 +105,9 @@ nouveau_sgdma_create_ttm(struct ttm_bo_device *bdev,
nvbe-ttm.ttm.func = nv50_sgdma_backend;
if (ttm_dma_tt_init(nvbe-ttm, bdev, size, page_flags,
dummy_read_page))
+ {
+ kfree(nvbe);
return NULL;
+ }
return nvbe-ttm.ttm;
}
--
1.8.4
--
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/
--
Regards,
Felipe Pena
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] DRM: TTM: Fix memory leak issue in ttm_agp_tt_create().
This patch adds kfree() in ttm_agp_tt_create() to avoide the
memory leak, without this there is a chance of memory leak in
ttm_tt_init() fail case.
Signed-off-by: Jeyaraman R jeyaraman.rangas...@lge.com
Signed-off-by: Manjunath Goudar csmanjuvi...@gmail.com
Cc: David Airlie airl...@linux.ie
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: David Howells dhowe...@redhat.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Dave Jones da...@redhat.com
Cc: Dave Airlie airl...@redhat.com
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
drivers/gpu/drm/ttm/ttm_agp_backend.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
b/drivers/gpu/drm/ttm/ttm_agp_backend.c
index 3302f99..764be36 100644
--- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
+++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
@@ -126,6 +126,7 @@ struct ttm_tt *ttm_agp_tt_create(struct ttm_bo_device *bdev,
agp_be-ttm.func = ttm_agp_func;
if (ttm_tt_init(agp_be-ttm, bdev, size, page_flags, dummy_read_page))
{
+ kfree(agp_be);
return NULL;
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] SHMOBILE: DRM: Fix backlight_device register and unregister undefined errors.
This patch adds a BACKLIGHT_CLASS_DEVICE dependency to configure the DRM_SHMOBILE. Without this patch, build system can lead to build failure. This was observed during randconfig testing, in which DRM_SHMOBILE was enabled w/o BACKLIGHT_CLASS_DEVICE being enabled. Following was the error: Building modules, stage 2. MODPOST 516 modules ERROR: backlight_device_register [drivers/gpu/drm/shmobile/shmob-drm.ko] undefined! ERROR: backlight_device_unregister [drivers/gpu/drm/shmobile/shmob-drm.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Signed-off-by: Manjunath Goudar csmanjuvi...@gmail.com Cc: David Airlie airl...@linux.ie Cc: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Cc: Sascha Hauer s.ha...@pengutronix.de Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org --- drivers/gpu/drm/shmobile/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/shmobile/Kconfig b/drivers/gpu/drm/shmobile/Kconfig index ca498d1..eaf822e 100644 --- a/drivers/gpu/drm/shmobile/Kconfig +++ b/drivers/gpu/drm/shmobile/Kconfig @@ -1,6 +1,6 @@ config DRM_SHMOBILE tristate DRM Support for SH Mobile - depends on DRM (ARM || SUPERH) + depends on DRM (ARM || SUPERH) BACKLIGHT_CLASS_DEVICE select DRM_KMS_HELPER select DRM_KMS_CMA_HELPER select DRM_GEM_CMA_HELPER -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Kconfig option to disable the legacy fbdev support
On 10/08 17:44, Daniel Vetter wrote:
mutex_lock(dev-mode_config.fb_lock);
list_for_each_entry(fb, dev-mode_config.fb_list, base.head) {
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index f221631..057ddeb 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1416,6 +1416,7 @@ void i915_master_destroy(struct drm_device *dev, struct
drm_master *master)
master-driver_priv = NULL;
}
+#ifdef CONFIG_FB
Why use CONFIG_FB here, as this is i915, should use CONFIG_DRM_I915_FBDEV right?
static void i915_kick_out_firmware_fb(struct drm_i915_private *dev_priv)
{
struct apertures_struct *ap;
@@ -1436,6 +1437,11 @@ static void i915_kick_out_firmware_fb(struct
drm_i915_private *dev_priv)
kfree(ap);
}
+#else
+static void i915_kick_out_firmware_fb(struct drm_i915_private *dev_priv)
+{
+}
+#endif
Regards,
Chon Ming
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 00/19] Common Display Framework
On 10/02/2013 03:24 PM, Tomi Valkeinen wrote: Hi Andrzej, On 02/10/13 15:23, Andrzej Hajda wrote: Using Linux buses for DBI/DSI = I still don't see how it would work. I've covered this multiple times in previous posts so I'm not going into more details now. I implemented DSI (just command mode for now) as a video bus but with bunch of extra ops for sending the control messages. Could you post the list of ops you have to create. I'd rather not post the ops I have in my prototype, as it's still a total hack. However, they are very much based on the current OMAP DSS's ops, so I'll describe them below. I hope I find time to polish my CDF hacks more, so that I can publish them. I have posted some time ago my implementation of DSI bus: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/69358/focus=69362 A note about the DT data on your series, as I've been stuggling to figure out the DT data for OMAP: some of the DT properties look like configuration, not hardware description. For example, samsung,bta-timeout doesn't describe hardware. As I have adopted existing internal driver for MIPI-DSI bus, I did not take too much care for DT. You are right, 'bta-timeout' is a configuration parameter (however its minimal value is determined by characteristic of the DSI-slave). On the other side currently there is no good place for such configuration parameters AFAIK. I needed three quite generic ops to make it working: - set_power(on/off), - set_stream(on/off), - transfer(dsi_transaction_type, tx_buf, tx_len, rx_buf, rx_len) I have recently replaced set_power by PM_RUNTIME callbacks, but I had to add .initialize ops. We have a bit more on omap: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/video/omapdss.h#n648 Some of those should be removed and some should be omap DSI's internal matters, not part of the API. But it gives an idea of the ops we use. Shortly about the ops: - (dis)connect, which might be similar to your initialize. connect is meant to connect the pipeline, reserving the video ports used, etc. - enable/disable, enable the DSI bus. If the DSI peripheral requires a continous DSI clock, it's also started at this point. - set_config configures the DSI bus (like, command/video mode, etc.). - configure_pins can be ignored, I think that function is not needed. - enable_hs and enable_te, used to enable/disable HS mode and tearing-elimination It seems there should be a way to synchronize TE signal with panel, in case signal is provided only to dsi-master. Some callback I suppose? Or transfer synchronization should be done by dsi-master. - update, which does a single frame transfer - bus_lock/unlock can be ignored - enable_video_output starts the video stream, when using DSI video mode - the request_vc, set_vc_id, release_vc can be ignored - Bunch of transfer funcs. Perhaps a single func could be used, as you do. We have sync write funcs, which do a BTA at the end of the write and wait for reply, and nosync version, which just pushes the packet to the TX buffers. - bta_sync, which sends a BTA and waits for the peripheral to reply - set_max_rx_packet_size, used to configure the max rx packet size. Similar callbacks should be added to mipi-dsi-bus ops as well, to make it complete/generic. Regarding the discussion how and where to implement control bus I have though about different alternatives: 1. Implement DSI-master as a parent dev which will create DSI-slave platform dev in a similar way as for MFD devices (ssbi.c seems to me a good example). 2. Create universal mipi-display-bus which will cover DSI, DBI and possibly other buses - they have have few common things - for example MIPI-DCS commands. I am not really convinced to either solution all have some advantages and disadvantages. I think a dedicated DSI bus and your alternatives all have the same issues with splitting the DSI control into two. I've shared some of my thoughts here: http://article.gmane.org/gmane.comp.video.dri.devel/90651 http://article.gmane.org/gmane.comp.video.dri.devel/91269 http://article.gmane.org/gmane.comp.video.dri.devel/91272 I still think that it's best to consider DSI and DBI as a video bus (not as a separate video bus and a control bus), and provide the packet transfer methods as part of the video ops. I have read all posts regarding this issue and currently I tend to solution where CDF is used to model only video streams, with control bus implemented in different framework. The only concerns I have if we should use Linux bus for that. Andrzej Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] Armada DRM stuff
On Mon, Oct 07, 2013 at 11:47:55PM +0200, Sebastian Hesselbarth wrote: On 10/07/2013 12:07 AM, Russell King - ARM Linux wrote: The Armada DRM drivers again, along with the TDA998x HDMI output support, and an illustration to show how to add Armada 610 support (and others.) Rob has looked at this a couple of times since its last posting, and has provided additional useful feedback which has been incorporated. I believe all the major issues have been addressed now. Tested-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com on Marvell Armada 510, SolidRun CuBox with quick-hack DT support added. Let's please get this driver mainlined and start working on proper DT support for it. Thanks for driver and the patience to work out all issues! Sebastian, I've added your tested-by now, and also updated the TDA998x patch to use the HDMI definitions that Jean-Francois pointed out (which is a really small delta, so isn't worth resending the patch set just for that). Thanks. All the points brought up in previous reviews concerning the physical address exposure, and the location of the DRM helpers have all been addressed, so it is now ready to be merged into mainline. So now the question is how to proceed with it. However, I see no response from any DRM developers, even though they are around - they've been responding on a different thread about driver model/sysfs abuse by DRM. I'm going to pull it into my nightly build tree so it can have some testing with non-dove builds, and if there's still no response from DRM people next week, I'll put it in to linux-next via my tree so at least it can get some exposure and integration validation there. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1
https://bugs.freedesktop.org/show_bug.cgi?id=68451 --- Comment #27 from Rune Petersen r...@megahurts.dk --- fun observation: Instead of reverting, setting this at the end of r600_cp_dma_copy_buffer() appears to fix it for me: rctx-b.flags |= R600_CONTEXT_INV_VERTEX_CACHE; (R600_CONTEXT_INV_CONST_CACHE will also work) Thing I don't understand about this is that if I instead set the flag just before r600_flush_emit() is called (2 places) the corruption is still there. I must be missing something. -- 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 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 --- Comment #23 from Mirko mailbox.s...@gmail.com --- (In reply to comment #20) Does attachment 86939 [details] [review] from bug 57919 help? I'll try it tonight. Patch it's for a specific kernel version? -- 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 68792] Problems during playback of h264 files using UVD and VLC on AMD E-350 CPU
https://bugs.freedesktop.org/show_bug.cgi?id=68792 --- Comment #5 from Grigori Goronzy g...@chown.ath.cx --- You have to enable VDPAU output as well. If you don't do that, in case the readback method is used, it won't work because the necessary format conversions have not been implemented yet (I'm working on it). -- 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 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 --- Comment #24 from Alex Deucher ag...@yahoo.com --- It was against my drm-fixes tree, but it should apply pretty easily to most kernels. -- 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 69341] [radeonsi] KDE 4.11 is EXTREMELY slow with Raster QT backend
https://bugs.freedesktop.org/show_bug.cgi?id=69341 --- Comment #15 from darkbasic darkba...@linuxsystems.it --- Another user with the same distro (Gentoo) and HD7700 (radeonsi) told me he doesn't have this problem: http://phoronix.com/forums/showthread.php?85135-GLAMOR-ized-Radeon-Driver-Shows-Hope-Over-EXAp=361630#post361630 http://phoronix.com/forums/showthread.php?85135-GLAMOR-ized-Radeon-Driver-Shows-Hope-Over-EXAp=361970#post361970 oibaf pointed me to some glamor patches: http://lists.freedesktop.org/archives/glamor/2013-October/date.html I can't try them right now (I'm in Spain) but I will in a week or two. -- 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
Requesting feedback on disallowing handle attribute values in EGLint attribute lists
Khronos is proposing a change affecting EGL attribute lists, and they are requesting feedback on this forum thread [1]. They have specifically requested feedback from the opensource community. [1] http://www.khronos.org/message_boards/showthread.php/9138-Requesting-feedback-on-disallowing-handle-attribute-values-in-EGLint-attribute-lists The root of the problem is that the EGL headers define EGLint to be 32-bit, but the EGL spec states that EGLint is large enough to hold pointers and handles. This, of course, causes a conflict on 64-bit platforms. Don't worry. Khronos does not intend to break the EGL ABI by redefining EGLint as 64-bit. The EGL spec authors' intention was that EGL attribute lists (whose type is an array of EGLint) should be able to hold pointer values. In reality, there are only two instances where an attribute list needs to hold a pointer: the EGL_MATCH_NATIVE_PIXMAP attribute to eglChooseConfig and the EGL_CL_EVENT_HANDLE_KHR attribute to eglCreateSyncKHR for EGL_KHR_cl_event. The take-away message is: Don't try to put pointers in EGLint attribute lists, because it will break on 64-bit platforms. For future EGL extensions, Khronos is planning to define a new EGLattrib type for attribute lists, which will properly hold a pointer. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70303] Kernel stack trace at drivers/gpu/drm/drm_crtc.c:1992
https://bugs.freedesktop.org/show_bug.cgi?id=70303 Pete Wright pwri...@rubiconproject.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Pete Wright pwri...@rubiconproject.com --- I am going to close this Bug I opened. I have reached out to the Fedora developers and will work with them on this as it looks like a potential X11 driver issue. -- 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 70327] New: Casting floating point variable to integer not working properly while constant gets converted properly
https://bugs.freedesktop.org/show_bug.cgi?id=70327 Priority: medium Bug ID: 70327 Assignee: dri-devel@lists.freedesktop.org Summary: Casting floating point variable to integer not working properly while constant gets converted properly Severity: normal Classification: Unclassified OS: Linux (All) Reporter: tony.wasse...@dolphin-emu.org Hardware: All Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 87353 -- https://bugs.freedesktop.org/attachment.cgi?id=87353action=edit Full rendered scene with bug visible I've recently been working on converting the shaders used by the Dolphin emulator to use integers instead of floating point numbers (for better emulation accuracy). This seems to have exposed a bug in the r600g driver possibly related to float-int casting. The core of the issue is this GLSL code line: iprev.rgb = (iprev.rgb * (int(256.0-fog))) / 256; (*) where fog has been initialized before as float fog = clamp(ze - fog_uniform.z, 0.0, 1.0); The point is, while fog seems to be zero (a fog==0.0 condition in the code will return true), the pixel shader result of (*) is different than the one that I get by substituting fog with 0.0. This gets very apparent in the rendered scene, cf -- 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 70327] Casting floating point variable to integer not working properly while constant gets converted properly
https://bugs.freedesktop.org/show_bug.cgi?id=70327 --- Comment #1 from tony.wasse...@dolphin-emu.org --- ...cf. first attachment Full rendered scene with bug visible. Second attachement Full rendered scene with software renderer shows the same scene rendered properly with LIBGL_ALWAYS_SOFTWARE=1 (I don't know if it was using llvmpipe or swrast, took halve a minute to render if that says anything). I'll provide a way to reproduce the issue in a followup comment. -- 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 70327] Casting floating point variable to integer not working properly while constant gets converted properly
https://bugs.freedesktop.org/show_bug.cgi?id=70327 --- Comment #2 from tony.wasse...@dolphin-emu.org --- Created attachment 87355 -- https://bugs.freedesktop.org/attachment.cgi?id=87355action=edit Full rendered scene with software renderer -- 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 70327] Casting floating point variable to integer not working properly while constant gets converted properly
https://bugs.freedesktop.org/show_bug.cgi?id=70327 tony.wasse...@dolphin-emu.org changed: What|Removed |Added Attachment #87353|0 |1 is obsolete|| --- Comment #3 from tony.wasse...@dolphin-emu.org --- Created attachment 87356 -- https://bugs.freedesktop.org/attachment.cgi?id=87356action=edit Full rendered scene with bug visible -- 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 70327] Casting floating point variable to integer not working properly while constant gets converted properly
https://bugs.freedesktop.org/show_bug.cgi?id=70327 --- Comment #4 from tony.wasse...@dolphin-emu.org --- Created attachment 87357 -- https://bugs.freedesktop.org/attachment.cgi?id=87357action=edit dff file to reproduce the issue by rendering a subset of the reference scene in Dolphin -- 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 70327] Casting floating point variable to integer not working properly while constant gets converted properly
https://bugs.freedesktop.org/show_bug.cgi?id=70327 --- Comment #5 from tony.wasse...@dolphin-emu.org --- Created attachment 87359 -- https://bugs.freedesktop.org/attachment.cgi?id=87359action=edit Output of R600_DEBUG=vs,ps,fs,sbdisasm when rendering the reduced scene -- 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 70327] Casting floating point variable to integer not working properly while constant gets converted properly
https://bugs.freedesktop.org/show_bug.cgi?id=70327 --- Comment #6 from tony.wasse...@dolphin-emu.org --- Steps the reproduce the issue: 1. Clone the dolphin repository from the url provided at http://code.google.com/p/dolphin-emu/source/checkout 2. Checkout the tev_fixes_new branch at commit 5d8cfade42ce . 3. Build Dolphin with the build instructions outlined at http://code.google.com/p/dolphin-emu/wiki/Linux_Build . We use CMake for our build system, so if you're familiar with that you should be able to get it running quickly. 4. run dolphin-emu -b -e path to the attached dff file. Alternatively, run Dolphin normally and open the dff file manually. 5. You should be able to see Mario (the main character of the game in the rendered scene), and only Mario (I removed all unimportant stuff from the scene). If you don't, try to make sure things work all by running any gamecube demo elf (sorry, got no link) and following the instructions at http://wiki.dolphin-emu.org/index.php?title=FifoPlayer under How to play back a fifo log? Basically, r600g renders the broken screenshot that I attached, while the software renderer renders the scene fine. Replacing fog in the iprev.rgb = (iprev.rgb * (int(256.0-fog))) / 256; line with 0.0 makes the scene render correctly. -- 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 70327] Casting floating point variable to integer not working properly while constant gets converted properly
https://bugs.freedesktop.org/show_bug.cgi?id=70327 --- Comment #7 from tony.wasse...@dolphin-emu.org --- Created attachment 87360 -- https://bugs.freedesktop.org/attachment.cgi?id=87360action=edit Sample GLSL shader that is used during rendering the glitched character Attached you find one of the glitched GLSL shaders which uses the mentioned line at line 149. Sorry for the dumb source layout, that's because the shaders aren't hand written but automatically generated. -- 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
[pull] radeon drm-fixes-3.12
Hi Dave, More radeon fixes for 3.12. Regression fixes for audio and UVD, several hang fixes, and some dpm fixes. The following changes since commit 1d083bc93d159ebcb46c5cbeca512ddd74a74e4b: Merge remote-tracking branch 'nouveau/drm-nouveau-next' into drm-fixes (2013-10-09 16:09:25 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.12 for you to fetch changes up to 4076a65544e2de310cbf4eaadb13ee15bbfaaf4f: drm/radeon/dpm: disable bapm on TN asics (2013-10-09 17:13:50 -0400) Alex Deucher (9): drm/edid: catch kmalloc failure in drm_edid_to_speaker_allocation drm/radeon: use 64-bit math to calculate CTS values for audio (v2) drm/radeon: fix N/CTS clock matching for audio drm/radeon: use hw generated CTS/N values for audio drm/radeon/dpm: disable multiple UVD states drm/radeon: fix typo in CP DMA register headers drm/radeon: improve soft reset on SI drm/radeon: improve soft reset on CIK drm/radeon/dpm: disable bapm on TN asics Dan Carpenter (3): drm/radeon: forever loop on error in radeon_do_test_moves() drm/radeon/dpm/btc: off by one in btc_set_mc_special_registers() drm/radeon/dpm: off by one in si_set_mc_special_registers() wojciech kapuscinski (1): drm/radeon: fix hw contexts for SUMO2 asics drivers/gpu/drm/drm_edid.c | 2 ++ drivers/gpu/drm/radeon/btc_dpm.c| 6 +++--- drivers/gpu/drm/radeon/cik.c| 6 ++ drivers/gpu/drm/radeon/evergreen.c | 2 +- drivers/gpu/drm/radeon/evergreen_hdmi.c | 3 +-- drivers/gpu/drm/radeon/evergreend.h | 4 ++-- drivers/gpu/drm/radeon/r600_hdmi.c | 20 +--- drivers/gpu/drm/radeon/r600d.h | 2 +- drivers/gpu/drm/radeon/radeon_pm.c | 3 +++ drivers/gpu/drm/radeon/radeon_test.c| 4 ++-- drivers/gpu/drm/radeon/radeon_uvd.c | 3 ++- drivers/gpu/drm/radeon/si.c | 10 ++ drivers/gpu/drm/radeon/si_dpm.c | 6 +++--- drivers/gpu/drm/radeon/sid.h| 4 ++-- drivers/gpu/drm/radeon/trinity_dpm.c| 2 +- 15 files changed, 52 insertions(+), 25 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70327] Casting floating point variable to integer not working properly while constant gets converted properly
https://bugs.freedesktop.org/show_bug.cgi?id=70327 --- Comment #8 from tony.wasse...@dolphin-emu.org --- Created attachment 87361 -- https://bugs.freedesktop.org/attachment.cgi?id=87361action=edit R600_DEBUG=vs,ps,fs,sbdisasm for small scene with the shader that we actually use -- 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 70327] Casting floating point variable to integer not working properly while constant gets converted properly
https://bugs.freedesktop.org/show_bug.cgi?id=70327 --- Comment #9 from tony.wasse...@dolphin-emu.org --- Created attachment 87362 -- https://bugs.freedesktop.org/attachment.cgi?id=87362action=edit R600_DEBUG=vs,ps,fs,sbdisasm for small scene with the shader where I replaced fog with 0.0 in the problematic line -- 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: [TIP] Catalyst / fglrx and DVI to HDMI adapters (audio)
Whee, I see some crazy paranoia on the news sites, and I figured I'd chime in having had to deal with weird DVI-HDMI conversion in the past.. On Tue, Oct 8, 2013 at 3:29 AM, Christian König deathsim...@vodafone.de wrote: So the poor little one which came with the gfx card should be sufficient, but if you want to use fglrx + some other adapter you might run into problems. As far as I can tell, these dongles are exclusively converting from dual-link DVI or standard DVI ports on high-end graphics cards into HDMI ports so that you can just connect an HDMI display (most likely a TV) to them. This is no conversion at all, really - the transmission encoding (TMDS) is identical, the pins and levels and signals are identical up to the point DVI is defined, and HDMI was designed with this compatibility in mind. The difference is entirely down to the content and type of the frames (as in packetized data, not framebuffers) being transmitted, HDMI interleaves a huge bunch of stuff between what would otherwise be pauses in the data stream (actually the various porches and synchronization intervals) on DVI. This includes audio, but also things like HDMI infoframes (there are a lot of different kinds of these). The question is simple; given a card with only a DVI connector, but the possibility to connect to HDMI or even DisplayPort, how do you tell if you should be generating these extra frames be interleaved in the data stream, in these spaces where a monitor may assume nothing at all is being transmitted and/or useful? The answer is super complicated. The only way you can tell your monitor is HDMI and supports audio is seeing a CEA extension block or two, one containing the HDMI vendor OUI (this means this thing says it should be HDMI compliant, but that doesn't actually MEAN anything in real life, in my experience) and one containing audio acceptance information (frequency, bits, rates, compression methods, which is also often wrong). I have had plenty of monitors which have both an HDMI port and a DVI port on the back. Both of them respond with identical EDID information. The DVI port - while perfectly possible that it could support audio as above - doesn't do audio. In fact, if you enable *ANY* extra HDMI infoframes like AVI, SPD or so, what you get is a random resolution failing to work or if you enable audio, it manifests as a huge pink line down the side of the screen, or a skewed display (the left edge of the screen starts around half way in horizontally, and as it progresses down vertically it gets closer to the real left edge of the panel - so if you had anything important in the top right of your screen, you wouldn't have a good day..). Others just go black, others say No Signal or Unsupported Timing (which is ironic since the timings were from the EDID detail timings or the CEA spec) Note, if your driver didn't parse the EDID properly and just lets you force enable audio or HDMI mode, or if somehow the driver starts off with an assumption about being HDMI.. on an old DVI monitor, too, you'll get the same stuff happen. What is inside the monitor described above is two decoders, one on the HDMI side connected to the LCD, and one on the DVI side connected to the LCD, for some reason both are converted to parallel RGB and shunted through an external encoder to the panel. The HDMI decoder is hooked up to the speakers.. the DVI one is not. I also have had access to a couple TVs where HDMI audio *does not work* on the side or HDMI 3 port on the back of the TV. There are FAQs on the vendor site that say, if it doesn't work, try connecting it to HDMI 1. I broke this one open and it has two HDMI decoders connected into the system, and a quick check at the time showed that they are dual-input decoders with i2s audio output to a codec and display data to a panel. So to get 4 HDMI inputs on the TV they needed two chips. A single-chip, 4-input decoder didn't exist at the time. It turns out the other one is actually a DVI product - no audio, just DVI-panel. From a design point of view the monitor vendor saved all of a few cents on eeprom flashing/manufacture costs, or by not buying a micro-controller with i2c that has space for an extra couple 128 byte binary blobs. After all, if you can fit your entire EDID and DDC/CI stuff into a chip with 1KiB of flash, and then you start thinking you need 256 or 512 bytes more to store different EDIDs, you have to move up to a 2KiB controller, which could be a mite more expensive. For 10 million TVs, half a cent per TV extra is a lot of money on the production run. Additionally, if you don't do DDC/CI then your driver could be made very simple if all your had to do was send parts of a single 128 byte array over the bus. No addressing, save space on pointers.. less guys in the software department to employ, and less time spent writing it in the first place. I've seen designs where the EDID for some ports says it has audio support, but actually the second HDMI decoder
Re: [PATCH v4 3/4] ACPI / video: Do not register backlight if win8 and native interface exists
On Tuesday, October 08, 2013 02:40:00 PM Aaron Lu wrote:
According to Matthew Garrett, Windows 8 leaves backlight control up
to individual graphics drivers rather than making ACPI calls itself.
There's plenty of evidence to suggest that the Intel driver for
Windows [8] doesn't use the ACPI interface, including the fact that
it's broken on a bunch of machines when the OS claims to support
Windows 8. The simplest thing to do appears to be to disable the
ACPI backlight interface on these systems.
So for Win8 systems, if there is native backlight control interface
registered by GPU driver, ACPI video will not register its own. For
users who prefer to keep ACPI video's backlight interface, the existing
kernel cmdline option acpi_backlight=video can be used.
Signed-off-by: Aaron Lu aaron...@intel.com
Tested-by: Igor Gnatenko i.gnatenko.br...@gmail.com
Tested-by: Yves-Alexis Perez cor...@debian.org
Tested-by: Mika Westerberg mika.westerb...@linux.intel.com
---
drivers/acpi/internal.h | 5 ++---
drivers/acpi/video.c| 10 +-
drivers/acpi/video_detect.c | 14 --
3 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 20f4233..453ae8d 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -169,9 +169,8 @@ int acpi_create_platform_device(struct acpi_device *adev,
Video
--
*/
#if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE)
-bool acpi_video_backlight_quirks(void);
-#else
-static inline bool acpi_video_backlight_quirks(void) { return false; }
+bool acpi_osi_is_win8(void);
+bool acpi_video_verify_backlight_support(void);
#endif
#endif /* _ACPI_INTERNAL_H_ */
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 3bd1eaa..343db59 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1256,8 +1256,8 @@ acpi_video_switch_brightness(struct acpi_video_device
*device, int event)
unsigned long long level_current, level_next;
int result = -EINVAL;
- /* no warning message if acpi_backlight=vendor is used */
- if (!acpi_video_backlight_support())
+ /* no warning message if acpi_backlight=vendor or a quirk is used */
+ if (!acpi_video_verify_backlight_support())
return 0;
if (!device-brightness)
@@ -1386,13 +1386,13 @@ acpi_video_bus_get_devices(struct acpi_video_bus
*video,
static int acpi_video_bus_start_devices(struct acpi_video_bus *video)
{
return acpi_video_bus_DOS(video, 0,
- acpi_video_backlight_quirks() ? 1 : 0);
+ acpi_osi_is_win8() ? 1 : 0);
}
static int acpi_video_bus_stop_devices(struct acpi_video_bus *video)
{
return acpi_video_bus_DOS(video, 0,
- acpi_video_backlight_quirks() ? 0 : 1);
+ acpi_osi_is_win8() ? 0 : 1);
}
static void acpi_video_bus_notify(struct acpi_device *device, u32 event)
@@ -1558,7 +1558,7 @@ acpi_video_bus_match(acpi_handle handle, u32 level,
void *context,
static void acpi_video_dev_register_backlight(struct acpi_video_device
*device)
{
- if (acpi_video_backlight_support()) {
+ if (acpi_video_verify_backlight_support()) {
struct backlight_properties props;
struct pci_dev *pdev;
acpi_handle acpi_parent;
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 940edbf..23d7d26 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -37,6 +37,7 @@
#include linux/acpi.h
#include linux/dmi.h
#include linux/pci.h
+#include linux/backlight.h
#include internal.h
@@ -233,11 +234,11 @@ static void acpi_video_caps_check(void)
acpi_video_get_capabilities(NULL);
}
-bool acpi_video_backlight_quirks(void)
+bool acpi_osi_is_win8(void)
{
return acpi_gbl_osi_data = ACPI_OSI_WIN_8;
}
-EXPORT_SYMBOL(acpi_video_backlight_quirks);
+EXPORT_SYMBOL(acpi_osi_is_win8);
/* Promote the vendor interface instead of the generic video module.
* This function allow DMI blacklists to be implemented by externals
@@ -283,6 +284,15 @@ int acpi_video_backlight_support(void)
}
EXPORT_SYMBOL(acpi_video_backlight_support);
+bool acpi_video_verify_backlight_support(void)
+{
+ if (!(acpi_video_support ACPI_VIDEO_BACKLIGHT_FORCE_VIDEO)
+ acpi_osi_is_win8() backlight_device_registered(BACKLIGHT_RAW))
+ return false;
If I'm not mistaken, this will introduce a regression for the people who have
problems with the native i915 backlight on Win8-compatible systems. I'd prefer
to avoid that at this point.
+ return acpi_video_backlight_support();
+}
[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1
https://bugs.freedesktop.org/show_bug.cgi?id=68451 --- Comment #29 from Alexandre Demers alexandre.f.dem...@gmail.com --- (In reply to comment #27) fun observation: Instead of reverting, setting this at the end of r600_cp_dma_copy_buffer() appears to fix it for me: rctx-b.flags |= R600_CONTEXT_INV_VERTEX_CACHE; (R600_CONTEXT_INV_CONST_CACHE will also work) Thing I don't understand about this is that if I instead set the flag just before r600_flush_emit() is called (2 places) the corruption is still there. I must be missing something. Your observation also applies to my HD 6950. -- 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 70327] Casting floating point variable to integer not working properly while constant gets converted properly
https://bugs.freedesktop.org/show_bug.cgi?id=70327 --- Comment #10 from Vadim Girlin pt...@yandex.ru --- Created attachment 87364 -- https://bugs.freedesktop.org/attachment.cgi?id=87364action=edit patch This patch should fix the issue (only compile-tested so far, I can't test with r600g card right now, but hopefully it's simple enough to be correct). -- 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 68792] Problems during playback of h264 files using UVD and VLC on AMD E-350 CPU
https://bugs.freedesktop.org/show_bug.cgi?id=68792 --- Comment #6 from Dieter Nützel die...@nuetzel-hh.de --- (In reply to comment #5) You have to enable VDPAU output as well. Sorry, but where and how? In VLC? *.conf file? If you don't do that, in case the readback method is used, I read something about it. Can I disable 'readback method' as interrims solution? it won't work because the necessary format conversions have not been implemented yet (I'm working on it). Go ahead ;-) -- 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 3/5] drm/bridge: Add PTN3460 bridge driver
-Original Message- From: Mark Brown [mailto:broo...@kernel.org] Sent: Thursday, October 10, 2013 3:29 AM To: Inki Dae Cc: Olof Johansson; Sean Paul; devicet...@vger.kernel.org; linux-samsung- s...@vger.kernel.org; linux-...@vger.kernel.org; linux- ker...@vger.kernel.org; DRI mailing list; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver On Fri, Oct 04, 2013 at 11:05:48AM +0900, Inki Dae wrote: 2013/10/4 Olof Johansson o...@lixom.net: If PD_N is LOW, then the device is in Deep power-down completely, even if supply rail is ON; for the device to be able to operate, the PD_N pin must be HIGH. I still think the pin could be replaced with a regulator. But lvds-bridge node has powerdown-gpio property - it say this board will use gpio pin - specific to board. So it seems no problem. No, don't model things that aren't regulators as regulators - it's just confusing from a usability standpoint and causes breakage when the pins don't behave like regulators. It seems that there was your missing point. That _is not_ what I mentioned. I mean that other boards can use a regulator instead of gpio pin. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/4] backlight: introduce backlight_device_registered
On Thu, 10 Oct 2013, Aaron Lu aaron...@intel.com wrote:
On 10/10/2013 08:25 AM, Rafael J. Wysocki wrote:
On Tuesday, October 08, 2013 02:39:58 PM Aaron Lu wrote:
+bool backlight_device_registered(enum backlight_type type)
+{
+ bool found = false;
+ struct backlight_device *bd;
+
+ mutex_lock(bd_list_mutex);
+ list_for_each_entry(bd, bd_list_head, entry) {
+ if (bd-props.type == type) {
+ found = true;
+ break;
+ }
+ }
Isn't it useful to be able to register more than one backlight device of the
same type sometimes?
I think so for some kind of computers. OTOH, the above function should
be enough for the problem we are solving here, if someday we need to
differentiate, we can enhance the code then.
Since both Baytrail and Haswell already have two backlight PWMs, this
may be needed sooner than you think. But we shouldn't let that block
fixing the more urgent issue we have now. So I'm fine with this. It
doesn't prevent one from registering more than one device of the same
type anyway.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/4] backlight: introduce backlight_device_registered
On Thu, 10 Oct 2013, Aaron Lu aaron...@intel.com wrote:
On 10/10/2013 12:29 PM, Jani Nikula wrote:
On Thu, 10 Oct 2013, Aaron Lu aaron...@intel.com wrote:
On 10/10/2013 08:25 AM, Rafael J. Wysocki wrote:
On Tuesday, October 08, 2013 02:39:58 PM Aaron Lu wrote:
+bool backlight_device_registered(enum backlight_type type)
+{
+ bool found = false;
+ struct backlight_device *bd;
+
+ mutex_lock(bd_list_mutex);
+ list_for_each_entry(bd, bd_list_head, entry) {
+ if (bd-props.type == type) {
+ found = true;
+ break;
+ }
+ }
Isn't it useful to be able to register more than one backlight device of
the
same type sometimes?
I think so for some kind of computers. OTOH, the above function should
be enough for the problem we are solving here, if someday we need to
differentiate, we can enhance the code then.
Since both Baytrail and Haswell already have two backlight PWMs, this
may be needed sooner than you think. But we shouldn't let that block
Do we need to differentiate which backlight PWM is registered to decide
if ACPI video backlight interface should be skipped? My understanding is
no.
That's correct. If things change, we can fix it then.
Jani.
Thanks,
Aaron
fixing the more urgent issue we have now. So I'm fine with this. It
doesn't prevent one from registering more than one device of the same
type anyway.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] radeon drm-fixes-3.12
2013/10/10 Alex Deucher alexdeuc...@gmail.com: drm/radeon: use hw generated CTS/N values for audio I'd like to see such patches earlier :| I'm OK with the change for DCE4+ (Evergreen) (I even suggested that change myself recently), but I didn't have time to check how this should be programmed on DCE2/3/4... In your patch 0001-WIP-port-of-hdmi-dp-audio-code-to-newer-kernel.patch based on (AFAIU) internal specs you were setting HDMI_ACR_SOURCE. According to the Christian R6xx may really have some bug for generating values by the hw, see: https://bugs.freedesktop.org/show_bug.cgi?id=69675#c12 So it doesn't look like a good patch for -fixes, especially without testing it on some hardware. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
