[Bug 75127] runpm hang with PowerXpress/hybrid laptop
https://bugs.freedesktop.org/show_bug.cgi?id=75127 --- Comment #34 from Sandeep --- Even with the latest patch applied (https://bugs.freedesktop.org/attachment.cgi?id=97193) the problem still occurs. The system does recover from the reset faster than before though - suspends and resumes in a few seconds now, whereas earlier it would take a few tens of seconds to snap out of the reset cycle. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/1e1d61a1/attachment.html>
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 --- Comment #36 from Ed Tomlinson --- I've tried 8 and 4 with no luck. Lots of corruptions and the gpu crashes/stall fairly quickly. More tomorrow. Does when the mclk is changed have any importance? What about setting it to the max and disabling any other changes? Thanks -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/c11952a7/attachment.html>
[PATCH 0/6] File Sealing & memfd_create()
Colin Walters wrote: > On Thu, Apr 10, 2014 at 3:15 PM, Andy Lutomirski > wrote: >> >> >> COW links can do this already, I think. Of course, you'll have to >> use a >> filesystem that supports them. > > COW is nice if the filesystem supports them, but my userspace code > needs to be filesystem agnostic. Because of that, the design for > userspace simply doesn't allow arbitrary writes. > > Instead, I have to painfully audit every rpm %post/dpkg postinst type > script to ensure they break hardlinks, and furthermore only allow > executing scripts that are known to do so. > > But I think even in a btrfs world it'd still be useful to mark files as > content-immutable. If you create each tree as a subvolume and when it's complete put it in place with btrfs subvolume snapshot -r FOO_inprogress /ostree/repo/FOO, you get exactly that. You can even use the new(ish) btrfs out-of-band dedup functionality to deduplicate read-only snapshots safely.
[PATCH 0/6] File Sealing & memfd_create()
Hi
On Thu, Apr 10, 2014 at 10:37 PM, Andy Lutomirski
wrote:
> It occurs to me that, before going nuts with these kinds of flags, it
> may pay to just try to fix the /proc/self/fd issue for real -- we
> could just make open("/proc/self/fd/3", O_RDWR) fail if fd 3 is
> read-only. That may be enough for the file sealing thing.
For the sealing API, none of this is needed. As long as the inode is
owned by the uid who creates the memfd, you can pass it around and
no-one besides root and you can open /proc/self/fd/$fd (assuming chmod
700). If you share the fd with someone with the same uid as you,
you're screwed anyway. We don't protect users against themselves (I
mean, they can ptrace you, or kill()..). Therefore, I'm not really
convinced that we want this for memfd. At least no-one has provided a
_proper_ use-case for this so far.
Thanks
David
[Bug 42960] Display does not work when resuming from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=42960 --- Comment #34 from D --- (In reply to comment #32) > I tested with 3.15-git , and it looks like the kernel parameter has no > effect there - the same problem occurs again! Even with acpi_sleep=s3_bios , > on suspend and resume the laptop LVDS display is blank. > > Does anyone know if this was an intentional change, to remove the ability to > do this? Hi, did you check using echo mem > /sys/power/state? Because e.g. pm-suspend resets those parameters via /proc/sys/kernel/acpi_video_flags. (Value should be 1, 2, or 3 if you have kernel parameters set) For pm-suspend to work (e.g. *Ubuntu) you need to create a file /etc/pm/config.d/radeon which contains QUIRK_S3_BIOS="true" QUIRK_S3_MODE="true" -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/1e295df7/attachment.html>
[Bug 42960] Display does not work when resuming from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=42960 --- Comment #33 from Sandeep --- After poking around a bit, I found out that I can re-enable the LVDS display using KDE's display settings (which uses xrandr), so it's just that the display isn't turned on by default for some reason (even though it was being used before suspend) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/cdcc65ea/attachment.html>
[Bug 42960] Display does not work when resuming from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=42960 --- Comment #32 from Sandeep --- I tested with 3.15-git , and it looks like the kernel parameter has no effect there - the same problem occurs again! Even with acpi_sleep=s3_bios , on suspend and resume the laptop LVDS display is blank. Does anyone know if this was an intentional change, to remove the ability to do this? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/a804cf38/attachment.html>
[PATCH] drm/radeon: disable mclk dpm on R7 260X
Setting higher mclks seems to cause stability issues on some R7 260X boards. Disable it for now for stability until we find a proper fix. bug: https://bugs.freedesktop.org/show_bug.cgi?id=75992 Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/ci_dpm.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c index f92ac5e..18e91ee 100644 --- a/drivers/gpu/drm/radeon/ci_dpm.c +++ b/drivers/gpu/drm/radeon/ci_dpm.c @@ -5147,6 +5147,10 @@ int ci_dpm_init(struct radeon_device *rdev) pi->mclk_dpm_key_disabled = 0; pi->pcie_dpm_key_disabled = 0; + /* mclk dpm is unstable on some R7 260X cards */ + if (rdev->pdev->device == 0x6658) + pi->mclk_dpm_key_disabled = 1; + pi->caps_sclk_ds = true; pi->mclk_strobe_mode_threshold = 4; -- 1.8.3.1
[PATCH] drm/radeon: update CI DPM powertune settings
As per internal recommendations.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/ci_dpm.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index cad89a9..f92ac5e 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -202,24 +202,29 @@ static void ci_initialize_powertune_defaults(struct
radeon_device *rdev)
struct ci_power_info *pi = ci_get_pi(rdev);
switch (rdev->pdev->device) {
+ case 0x6649:
case 0x6650:
+ case 0x6651:
case 0x6658:
case 0x665C:
+ case 0x665D:
default:
pi->powertune_defaults = &defaults_bonaire_xt;
break;
- case 0x6651:
- case 0x665D:
- pi->powertune_defaults = &defaults_bonaire_pro;
- break;
case 0x6640:
- pi->powertune_defaults = &defaults_saturn_xt;
- break;
case 0x6641:
- pi->powertune_defaults = &defaults_saturn_pro;
+ case 0x6646:
+ case 0x6647:
+ pi->powertune_defaults = &defaults_saturn_xt;
break;
case 0x67B8:
case 0x67B0:
+ pi->powertune_defaults = &defaults_hawaii_xt;
+ break;
+ case 0x67BA:
+ case 0x67B1:
+ pi->powertune_defaults = &defaults_hawaii_pro;
+ break;
case 0x67A0:
case 0x67A1:
case 0x67A2:
@@ -228,11 +233,7 @@ static void ci_initialize_powertune_defaults(struct
radeon_device *rdev)
case 0x67AA:
case 0x67B9:
case 0x67BE:
- pi->powertune_defaults = &defaults_hawaii_xt;
- break;
- case 0x67BA:
- case 0x67B1:
- pi->powertune_defaults = &defaults_hawaii_pro;
+ pi->powertune_defaults = &defaults_bonaire_xt;
break;
}
--
1.8.3.1
[PATCH] drm/radeon: fix runpm handling on APUs (v4)
Don't try and runtime suspend the APU in PX systems. We
only want to power down the dGPU.
v2: fix harder
v3: fix stupid typo
v4: consolidate runpm enablement to a single flag
bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=75127
https://bugzilla.kernel.org/show_bug.cgi?id=72701
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon.h | 1 +
drivers/gpu/drm/radeon/radeon_atpx_handler.c | 2 +-
drivers/gpu/drm/radeon/radeon_device.c | 19 ++-
drivers/gpu/drm/radeon/radeon_drv.c | 24
drivers/gpu/drm/radeon/radeon_family.h | 1 +
drivers/gpu/drm/radeon/radeon_kms.c | 14 ++
6 files changed, 27 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index f0fc2c8..3d94c0d 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2318,6 +2318,7 @@ struct radeon_device {
bool have_disp_power_ref;
};
+bool radeon_is_px(struct drm_device *dev);
int radeon_device_init(struct radeon_device *rdev,
struct drm_device *ddev,
struct pci_dev *pdev,
diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
index fa9a9c0..dedea72 100644
--- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
+++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
@@ -59,7 +59,7 @@ struct atpx_mux {
u16 mux;
} __packed;
-bool radeon_is_px(void) {
+bool radeon_has_atpx(void) {
return radeon_atpx_priv.atpx_detected;
}
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 2e72dcd..00b19d0 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -102,11 +102,14 @@ static const char radeon_family_name[][16] = {
"LAST",
};
-#if defined(CONFIG_VGA_SWITCHEROO)
-bool radeon_is_px(void);
-#else
-static inline bool radeon_is_px(void) { return false; }
-#endif
+bool radeon_is_px(struct drm_device *dev)
+{
+ struct radeon_device *rdev = dev->dev_private;
+
+ if (rdev->flags & RADEON_IS_PX)
+ return true;
+ return false;
+}
/**
* radeon_program_register_sequence - program an array of registers.
@@ -1082,7 +1085,7 @@ static void radeon_switcheroo_set_state(struct pci_dev
*pdev, enum vga_switchero
{
struct drm_device *dev = pci_get_drvdata(pdev);
- if (radeon_is_px() && state == VGA_SWITCHEROO_OFF)
+ if (radeon_is_px(dev) && state == VGA_SWITCHEROO_OFF)
return;
if (state == VGA_SWITCHEROO_ON) {
@@ -1301,9 +1304,7 @@ int radeon_device_init(struct radeon_device *rdev,
* ignore it */
vga_client_register(rdev->pdev, rdev, NULL, radeon_vga_set_decode);
- if (radeon_runtime_pm == 1)
- runtime = true;
- if ((radeon_runtime_pm == -1) && radeon_is_px())
+ if (rdev->flags & RADEON_IS_PX)
runtime = true;
vga_switcheroo_register_client(rdev->pdev, &radeon_switcheroo_ops,
runtime);
if (runtime)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 2dc2cc4..3811812 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -114,6 +114,7 @@ extern int radeon_get_crtc_scanoutpos(struct drm_device
*dev, int crtc,
unsigned int flags,
int *vpos, int *hpos, ktime_t *stime,
ktime_t *etime);
+extern bool radeon_is_px(struct drm_device *dev);
extern const struct drm_ioctl_desc radeon_ioctls_kms[];
extern int radeon_max_kms_ioctl;
int radeon_mmap(struct file *filp, struct vm_area_struct *vma);
@@ -143,11 +144,9 @@ void radeon_debugfs_cleanup(struct drm_minor *minor);
#if defined(CONFIG_VGA_SWITCHEROO)
void radeon_register_atpx_handler(void);
void radeon_unregister_atpx_handler(void);
-bool radeon_is_px(void);
#else
static inline void radeon_register_atpx_handler(void) {}
static inline void radeon_unregister_atpx_handler(void) {}
-static inline bool radeon_is_px(void) { return false; }
#endif
int radeon_no_wb;
@@ -404,12 +403,7 @@ static int radeon_pmops_runtime_suspend(struct device *dev)
struct drm_device *drm_dev = pci_get_drvdata(pdev);
int ret;
- if (radeon_runtime_pm == 0) {
- pm_runtime_forbid(dev);
- return -EBUSY;
- }
-
- if (radeon_runtime_pm == -1 && !radeon_is_px()) {
+ if (!radeon_is_px(drm_dev)) {
pm_runtime_forbid(dev);
return -EBUSY;
}
@@ -433,10 +427,7 @@ static int radeon_pmops_runtime_resume(struct device *dev)
struct drm_device *drm_dev = pci_get_drvdata(pdev);
int ret;
- if (radeon_runtime_pm == 0)
- return -EINVAL;
-
-
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 --- Comment #35 from Alex Deucher --- (In reply to comment #32) > limit mclk - lots of corruptions (not just the normal one or two) and an > almost > immediate gpu stall/crash Can you try adjusting the mclk value in that patch down? E.g., change 157500 to: 15 10 8 5 3 etc. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/50f467b9/attachment.html>
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 --- Comment #34 from Ed Tomlinson --- Created attachment 97196 --> https://bugs.freedesktop.org/attachment.cgi?id=97196&action=edit lspci -vnn (just the graphics card details posted) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/b516a0c3/attachment.html>
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 --- Comment #33 from Ed Tomlinson --- Pressed enter too quickly. Both patches were tested against linux-git as of about 5pm EDT. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/2099034b/attachment.html>
[PATCH] drm/radeon: Inline r100_mm_rreg
On Thu, 10 Apr 2014 12:19:10 -0400
Ilia Mirkin wrote:
> > +static inline uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t
> > reg,
> > + bool always_indirect)
> > +{
> > + if (reg < rdev->rmmio_size && !always_indirect)
> > + return readl(((void __iomem *)rdev->rmmio) + reg);
>
> Quick thought from someone entirely unfamiliar with the hardware:
> perhaps you can get the performance benefit without the size increase
> by moving the else portion into a non-inline function? I'm guessing
> that most accesses happen in the "if" branch.
The function call overhead is about equal to branching overhead, so
splitting it would only help about half that. It's called from many
places, and a lot of calls per sec.
Of course the future kernel LTO will all make this go away, but that's
probably two years in the future before it's stable.
- Lauri
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 --- Comment #32 from Ed Tomlinson --- Niether patches fixes the issue disable voltage control - no corruptions, 6.5fps limit mclk - lots of corruptions (not just the normal one or two) and an almost immediate gpu stall/crash -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/5e37ae02/attachment-0001.html>
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 --- Comment #31 from nicolas.laplante at gmail.com --- Created attachment 97194 --> https://bugs.freedesktop.org/attachment.cgi?id=97194&action=edit lspci -vnn for me too -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/4e91cc30/attachment.html>
[PATCH] drm/radeon: Inline r100_mm_rreg
Am 10.04.2014 20:52, schrieb Ilia Mirkin:
> On Thu, Apr 10, 2014 at 2:46 PM, Lauri Kasanen wrote:
>> On Thu, 10 Apr 2014 12:19:10 -0400
>> Ilia Mirkin wrote:
>>
+static inline uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t
reg,
+ bool always_indirect)
+{
+ if (reg < rdev->rmmio_size && !always_indirect)
+ return readl(((void __iomem *)rdev->rmmio) + reg);
>>> Quick thought from someone entirely unfamiliar with the hardware:
>>> perhaps you can get the performance benefit without the size increase
>>> by moving the else portion into a non-inline function? I'm guessing
>>> that most accesses happen in the "if" branch.
>> The function call overhead is about equal to branching overhead, so
>> splitting it would only help about half that. It's called from many
>> places, and a lot of calls per sec.
Actually direct register access shouldn't be necessary so often. Apart
from page flips, write/read pointer updates and irq processing there
shouldn't be so many of them. Could you clarify a bit more what issue
you are seeing here?
> Is that really true? I haven't profiled it, but a function call has to
> save/restore registers, set up new stack, etc. And the jump is to some
> far-away code, so perhaps less likely to be in i-cache? (But maybe
> not, not sure on the details of how all that works.) And I'm guessing
> most of the size increase is coming from the spinlock/unlock, which,
> I'm guessing again, is the much-rarer case.
>
> And the branch would happen either way... so that's a sunk cost.
> (Except I bet that the always_indirect param is always constant and
> that bit of the if can be resolved at compile time with that part
> being inlined.)
>
> Anyways, it was just a thought.
And a pretty much correct one. The "else" case shouldn't be necessary on
modern hardware any more and so nearly never taken.
Christian.
>
>-ilia
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 74539] [r600g] Memory leak when playing WoW with RV790
https://bugs.freedesktop.org/show_bug.cgi?id=74539 --- Comment #30 from Chris Rankin --- (In reply to comment #29) > With kernel 3.15, you can watch GPU memory usage by setting: > GALLIUM_HUD=VRAM-usage,GTT-usage Is this support sufficiently non-invasive to be backported to 3.14-stable? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/23121b65/attachment.html>
[ANNOUNCE] libdrm 2.4.53
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Libdrm 2.4.53 has been released. Emil Velikov (1): freedreno: do not leak drmVersion Fran?ois Tigeot (1): Enable libkms by default on DragonFly Lucas Stach (1): modeprint: pretty print connector names Marek Ol??k (2): radeon: sync with radeon_drm.h from kernel headers Bump version to 2.4.53 for release Rob Clark (6): freedreno: fix license freedreno: some msm-ring reset/flush fixes freedreno: simplify device creation freedreno: fix null ptr in error path freedreno/kgsl: don't even bother trying CREATE_FD freedreno: zero out unused field Robert Millan (1): drm: Implement drmCheckModesettingSupported() for FreeBSD git tag: libdrm-2.4.53 http://dri.freedesktop.org/libdrm/libdrm-2.4.53.tar.bz2 MD5: 342886a137ddd9ed4341675d132388ad libdrm-2.4.53.tar.bz2 SHA1: d3381432045984faa060a43425d67fd359bf29e3 libdrm-2.4.53.tar.bz2 SHA256: 1b0c28fd2f2b92d2df0a73d1aed88f43cb0dee1267aea6bc52ccb5fca5757a08 libdrm-2.4.53.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.53.tar.gz MD5: 12e30247fb3caafc835e5f3f768c426a libdrm-2.4.53.tar.gz SHA1: d90a475dede0cd2b78a27a3de5a85c7ad63b8e40 libdrm-2.4.53.tar.gz SHA256: 272db7c2ccddeeef476f3ffdd6fd2c8f4ea693d048d9e84e9c40e6716e0d3abd libdrm-2.4.53.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJTRu7FAAoJEP3RXVrO8PKxiRAIANfs7N+indhohGoWWGvQgXjx 4lXtSt1xdVPe5VXauaFFaKY10hddnkik7uxZvLftAnFE4JP/W0WWbzH/hSgrTOWj 3OHlIBgWyHY9FyIu2aHnxTyaLRnJfmPhGvvu87GhTvPk3ZDGf/XAUEyE01l+XK2B ymVWgcm8gFuuZ/c6etCdu+MIFsknKUpvXPotd32oZ3uY8NxfjDlWpxOWCa35850C e5PN4mhwFjwxeMUkDJPlvcozACNgycgquAS516/dQMT3ORmVfvFf1CuZM3EVkLPX CYzpDtRNMw+l+1kDIFWVBSdjv3KzWlwEZFwPzEBeoSrj0/LbrI8/WiEDuyRsEM4= =v6zD -END PGP SIGNATURE-
[Bug 75127] runpm hang with PowerXpress/hybrid laptop
https://bugs.freedesktop.org/show_bug.cgi?id=75127 Alex Deucher changed: What|Removed |Added Attachment #97106|0 |1 is obsolete|| --- Comment #33 from Alex Deucher --- Created attachment 97193 --> https://bugs.freedesktop.org/attachment.cgi?id=97193&action=edit possible fix New patch. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/ba04cd3a/attachment.html>
[Bug 74539] [r600g] Memory leak when playing WoW with RV790
https://bugs.freedesktop.org/show_bug.cgi?id=74539 --- Comment #29 from Marek Ol??k --- With kernel 3.15, you can watch GPU memory usage by setting: GALLIUM_HUD=VRAM-usage,GTT-usage You should able to see if we leak GPU memory or not. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/a33e09af/attachment.html>
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 --- Comment #30 from Egon Ashrafinia --- "echo "high" > /sys/class/drm/card0/device/power_profile" crashes me too when I try to set it after "radeon.dpm=0". Because the default one is really on a low level. No OpenGL animation works smooth. My hole Display turned black, but the computer was still turned on. ... No reactions anymore. Hard Restart required. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/3d170444/attachment.html>
[Bug 74539] [r600g] Memory leak when playing WoW with RV790
https://bugs.freedesktop.org/show_bug.cgi?id=74539 --- Comment #28 from Chris Rankin --- (In reply to comment #26) > Does the patch from bug 74868 help? Hmm, it hasn't OOM-ed yet. But one of the symptoms that I'd come to associate with the memory problem was an increasing jerkiness in the game play over time. That symptom at least is still present. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/2a5f5fd6/attachment-0001.html>
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 --- Comment #29 from Egon Ashrafinia --- Created attachment 97191 --> https://bugs.freedesktop.org/attachment.cgi?id=97191&action=edit lspci (Ashrafinia) As my Bug report (77281) is a duplicate of this bug here, I will help you to figure out the issue. I have the same issue as you may knowl Here is my lspci. I hope you also got some information from my bug report. Please ask me as much as you want to. I really want to fix this. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/77837bf9/attachment.html>
[Bug 77274] [drm:dce6_afmt_write_speaker_allocation] *ERROR* Couldn't read Speaker Allocation Data Block: 0
https://bugs.freedesktop.org/show_bug.cgi?id=77274 --- Comment #6 from Alex Deucher --- (In reply to comment #5) > I'm sorry about having pointed to an external pastebin, I've attached dmesg > and Xorg.0.log to the discussion now. > > I'm quite sure I'm experiencing the same issues of the bug 77002 so I'm > going to follow that discussion. > > I don't know what you mean for bisecting but if needed I can try with > different kernels, the last one that worked for me was the 3.13.8. I can > also try patches or test on different hardwares. If the fix from that bug does it, you can mark this as a duplicate. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/d409cff6/attachment.html>
[Bug 77281] Display corruption and stripes on the display Linux 3.14
https://bugs.freedesktop.org/show_bug.cgi?id=77281 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Alex Deucher --- *** This bug has been marked as a duplicate of bug 75992 *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/133f3d50/attachment.html>
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 Alex Deucher changed: What|Removed |Added CC||e.ashrafinia at gmail.com --- Comment #28 from Alex Deucher --- *** Bug 77281 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/0f83b096/attachment.html>
[PATCH] MAINTAINERS: update maintainer entry for Exynos DP driver
Recently, Exynos DP driver was moved from drivers/video/exynos/ directory to drivers/gpu/drm/exynos/ directory. So, I update and add maintainer entry for Exynos DP driver. Signed-off-by: Jingoo Han --- MAINTAINERS |6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index beaa87a..30c1c50 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3485,6 +3485,12 @@ S: Maintained F: drivers/extcon/ F: Documentation/extcon/ +EXYNOS DP DRIVER +M: Jingoo Han +L: dri-devel at lists.freedesktop.org +S: Maintained +F: drivers/gpu/drm/exynos/exynos_dp* + EXYNOS MIPI DISPLAY DRIVERS M: Inki Dae M: Donghwa Lee -- 1.7.10.4
[Bug 77274] [drm:dce6_afmt_write_speaker_allocation] *ERROR* Couldn't read Speaker Allocation Data Block: 0
https://bugs.freedesktop.org/show_bug.cgi?id=77274 --- Comment #5 from Daniele Peruzzi --- I'm sorry about having pointed to an external pastebin, I've attached dmesg and Xorg.0.log to the discussion now. I'm quite sure I'm experiencing the same issues of the bug 77002 so I'm going to follow that discussion. I don't know what you mean for bisecting but if needed I can try with different kernels, the last one that worked for me was the 3.13.8. I can also try patches or test on different hardwares. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/c52ec9b9/attachment-0001.html>
[Bug 77281] Display corruption and stripes on the display Linux 3.14
https://bugs.freedesktop.org/show_bug.cgi?id=77281 --- Comment #4 from Egon Ashrafinia --- Created attachment 97187 --> https://bugs.freedesktop.org/attachment.cgi?id=97187&action=edit Xorg.0.log If anything else if missing, please contact me. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/813ab94c/attachment.html>
[Bug 77274] [drm:dce6_afmt_write_speaker_allocation] *ERROR* Couldn't read Speaker Allocation Data Block: 0
https://bugs.freedesktop.org/show_bug.cgi?id=77274 --- Comment #4 from Daniele Peruzzi --- Created attachment 97186 --> https://bugs.freedesktop.org/attachment.cgi?id=97186&action=edit Xorg.0.log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/3528cc3c/attachment.html>
[Bug 77281] Display corruption and stripes on the display Linux 3.14
https://bugs.freedesktop.org/show_bug.cgi?id=77281 --- Comment #3 from Egon Ashrafinia --- Created attachment 97185 --> https://bugs.freedesktop.org/attachment.cgi?id=97185&action=edit dmesg -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/2e188999/attachment.html>
[Bug 77274] [drm:dce6_afmt_write_speaker_allocation] *ERROR* Couldn't read Speaker Allocation Data Block: 0
https://bugs.freedesktop.org/show_bug.cgi?id=77274 --- Comment #3 from Daniele Peruzzi --- Created attachment 97183 --> https://bugs.freedesktop.org/attachment.cgi?id=97183&action=edit dmesg -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/ce997ce6/attachment.html>
[PATCH 0/6] File Sealing & memfd_create()
On Thu, Apr 10, 2014 at 3:15 PM, Andy Lutomirski wrote: > > > COW links can do this already, I think. Of course, you'll have to > use a > filesystem that supports them. COW is nice if the filesystem supports them, but my userspace code needs to be filesystem agnostic. Because of that, the design for userspace simply doesn't allow arbitrary writes. Instead, I have to painfully audit every rpm %post/dpkg postinst type script to ensure they break hardlinks, and furthermore only allow executing scripts that are known to do so. But I think even in a btrfs world it'd still be useful to mark files as content-immutable.
[Bug 77281] Display corruption and stripes on the display Linux 3.14
https://bugs.freedesktop.org/show_bug.cgi?id=77281 Egon Ashrafinia changed: What|Removed |Added Attachment #97181|0 |1 is obsolete|| --- Comment #2 from Egon Ashrafinia --- Created attachment 97182 --> https://bugs.freedesktop.org/attachment.cgi?id=97182&action=edit Screenshot of my issues -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/29e573e2/attachment.html>
[Bug 77281] Display corruption and stripes on the display Linux 3.14
https://bugs.freedesktop.org/show_bug.cgi?id=77281 Egon Ashrafinia changed: What|Removed |Added Priority|medium |high -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/7df7cc73/attachment.html>
[Bug 77281] Display corruption and stripes on the display Linux 3.14
https://bugs.freedesktop.org/show_bug.cgi?id=77281 --- Comment #1 from Egon Ashrafinia --- Comment on attachment 97181 --> https://bugs.freedesktop.org/attachment.cgi?id=97181 Screenshot of my issues This is wrong! Sorry -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/ff779190/attachment.html>
[Bug 77281] New: Display corruption and stripes on the display Linux 3.14
https://bugs.freedesktop.org/show_bug.cgi?id=77281 Priority: medium Bug ID: 77281 Assignee: dri-devel at lists.freedesktop.org Summary: Display corruption and stripes on the display Linux 3.14 Severity: major Classification: Unclassified OS: Linux (All) Reporter: e.ashrafinia at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 97181 --> https://bugs.freedesktop.org/attachment.cgi?id=97181&action=edit Screenshot of my issues Hello First I would like to include this here https://lkml.org/lkml/2014/3/10/379 as it exactly descripes my problem. I am running a AMD Radeon R7 260X from HIS and since my update to the linux kernel 3.14 (using Archlinux) I have massive problems with display corruption and stripes on my display. I am using Gnome-Shell 3.12 and specially in Firefox my display is flickering and showing weired stuff. I will attach a screenshot any my logs. Thank you for your help Greetings -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/d424c842/attachment-0001.html>
[PATCH v2 libdrm 5/7] tegra: Add helper library for tests
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
wrote:
> From: Thierry Reding
>
> This library provides helpers for common functionality needed by test
> programs.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v2:
> - fix a couple of memory leaks and get rid of some unneeded code
>
> tests/tegra/Makefile.am | 10 +-
> tests/tegra/drm-test-tegra.c | 137
> tests/tegra/drm-test-tegra.h | 55 ++
> tests/tegra/drm-test.c | 248
> +++
> tests/tegra/drm-test.h | 72 +
> 5 files changed, 521 insertions(+), 1 deletion(-)
> create mode 100644 tests/tegra/drm-test-tegra.c
> create mode 100644 tests/tegra/drm-test-tegra.h
> create mode 100644 tests/tegra/drm-test.c
> create mode 100644 tests/tegra/drm-test.h
This isn't really important at this point, but it looks to me like
tests/tegra/drm-test.[ch] isn't really tegra-specific. If so, perhaps
some other tests can benefit from it? Doing so is of course something
whoever writes those tests should do, though. Leaving them in the
tegra-subdir is probably fine.
> +int drm_tegra_gr2d_fill(struct drm_tegra_gr2d *gr2d, struct drm_framebuffer
> *fb,
> + unsigned int x, unsigned int y, unsigned int width,
> + unsigned int height, uint32_t color)
> +{
> + struct drm_tegra_bo *fbo = fb->data;
> + struct drm_tegra_pushbuf *pushbuf;
> + struct drm_tegra_fence *fence;
> + struct drm_tegra_job *job;
> + int err;
> +
> + err = drm_tegra_job_new(&job, gr2d->channel);
> + if (err < 0)
> + return err;
> +
> + err = drm_tegra_pushbuf_new(&pushbuf, job);
> + if (err < 0)
> + return err;
> +
I think this helper would be generally more useful if it skipped the
above two, and required the call-sites to do them instead.
> + err = drm_tegra_pushbuf_prepare(pushbuf, 32);
> + if (err < 0)
> + return err;
> +
> + *pushbuf->ptr++ = HOST1X_OPCODE_SETCL(0, HOST1X_CLASS_GR2D, 0);
> +
> + *pushbuf->ptr++ = HOST1X_OPCODE_MASK(0x9, 0x9);
> + *pushbuf->ptr++ = 0x003a;
> + *pushbuf->ptr++ = 0x;
> +
> + *pushbuf->ptr++ = HOST1X_OPCODE_MASK(0x1e, 0x7);
> + *pushbuf->ptr++ = 0x;
> + *pushbuf->ptr++ = (2 << 16) | (1 << 6) | (1 << 2);
> + *pushbuf->ptr++ = 0x00cc;
> +
> + *pushbuf->ptr++ = HOST1X_OPCODE_MASK(0x2b, 0x9);
> +
> + /* relocate destination buffer */
> + err = drm_tegra_pushbuf_relocate(pushbuf, fbo, 0, 0);
> + if (err < 0) {
> + fprintf(stderr, "failed to relocate buffer object: %d\n",
> err);
> + return err;
> + }
> +
> + *pushbuf->ptr++ = fb->pitch;
> +
> + *pushbuf->ptr++ = HOST1X_OPCODE_NONINCR(0x35, 1);
> + *pushbuf->ptr++ = color;
> +
> + *pushbuf->ptr++ = HOST1X_OPCODE_NONINCR(0x46, 1);
> + *pushbuf->ptr++ = 0x;
> +
> + *pushbuf->ptr++ = HOST1X_OPCODE_MASK(0x38, 0x5);
> + *pushbuf->ptr++ = height << 16 | width;
> + *pushbuf->ptr++ = y << 16 | x;
> +
...and stop here.
That way we can use it for tests that perform multiple fills in one submit etc.
> +#define HOST1X_OPCODE_SETCL(offset, classid, mask) \
> +((0x0 << 28) | (((offset) & 0xfff) << 16) | (((classid) & 0x3ff) << 6) |
> ((mask) & 0x3f))
> +#define HOST1X_OPCODE_INCR(offset, count) \
> +((0x1 << 28) | (((offset) & 0xfff) << 16) | ((count) & 0x))
> +#define HOST1X_OPCODE_NONINCR(offset, count) \
> +((0x2 << 28) | (((offset) & 0xfff) << 16) | ((count) & 0x))
> +#define HOST1X_OPCODE_MASK(offset, mask) \
> +((0x3 << 28) | (((offset) & 0xfff) << 16) | ((mask) & 0x))
> +#define HOST1X_OPCODE_IMM(offset, data) \
> +((0x4 << 28) | (((offset) & 0xfff) << 16) | ((data) & 0x))
> +#define HOST1X_OPCODE_EXTEND(subop, value) \
> +((0xe << 28) | (((subop) & 0xf) << 24) | ((value) & 0xff))
> +
> +#define HOST1X_CLASS_GR2D 0x51
Hmm, shouldn't these be available from somewhere else already? No
point in repeating the same macros over and over again, no?
> diff --git a/tests/tegra/drm-test.c b/tests/tegra/drm-test.c
> new file mode 100644
> index ..1f91d17f61bb
> --- /dev/null
> +++ b/tests/tegra/drm-test.c
> @@ -0,0 +1,248 @@
> +/*
> + * Copyright ? 2014 NVIDIA Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all co
[PATCH v2 libdrm 6/7] tegra: Add gr2d-fill test
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
wrote:
> diff --git a/tests/tegra/gr2d-fill.c b/tests/tegra/gr2d-fill.c
> new file mode 100644
> index ..b6ba35a9d668
> --- /dev/null
> +++ b/tests/tegra/gr2d-fill.c
> @@ -0,0 +1,146 @@
> +/*
> + * Copyright ? 2014 NVIDIA Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +# include "config.h"
> +#endif
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "xf86drm.h"
> +#include "xf86drmMode.h"
> +#include "drm_fourcc.h"
> +
> +#include "drm-test-tegra.h"
> +#include "tegra.h"
> +
> +int main(int argc, char *argv[])
> +{
> + uint32_t format = DRM_FORMAT_XRGB;
> + struct drm_tegra_gr2d *gr2d;
> + struct drm_framebuffer *fb;
> + struct drm_screen *screen;
> + unsigned int pitch, size;
> + struct drm_tegra_bo *bo;
> + struct drm_tegra *drm;
> + uint32_t handle;
> + int fd, err;
> + void *ptr;
> +
> + fd = drm_open(argv[1]);
> + if (fd < 0) {
> + fprintf(stderr, "failed to open DRM device %s: %s\n", argv[1],
> + strerror(errno));
> + return 1;
> + }
I'm not quite sure I understand this part. Why would argv[1] be
anything else than NULL? Is this useful for manual debugging, perhaps?
> + err = drm_tegra_gr2d_fill(gr2d, fb, fb->width / 4, fb->height / 4,
> + fb->width / 2, fb->height / 2, 0x);
> + if (err < 0) {
> + fprintf(stderr, "failed to fill rectangle: %s\n",
> + strerror(-err));
> + return 1;
> + }
> +
> + sleep(1);
> +
Why do we need to sleep here?
[PATCH v2 libdrm 3/7] tegra: Add simple test for drm_tegra_open()
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding wrote: > From: Thierry Reding > > This test opens a device, dumps the version information and checks that > a Tegra DRM context can be opened on it. > > Signed-off-by: Thierry Reding Looks good!
[PATCH v2 libdrm 2/7] libdrm: Add NVIDIA Tegra support
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding wrote: > From: Thierry Reding > > Add the libdrm_tegra helper library to encapsulate Tegra-specific > interfaces to the DRM. > > Furthermore, Tegra is added to the list of supported chips in the > modetest and vbltest programs. > > Signed-off-by: Thierry Reding > Signed-off-by: Erik Faye-Lund > Signed-off-by: Thierry Reding Looks good to me!
[Bug 75127] runpm hang with PowerXpress/hybrid laptop
https://bugs.freedesktop.org/show_bug.cgi?id=75127 --- Comment #32 from kh3095 at yandex.ru --- Created attachment 97179 --> https://bugs.freedesktop.org/attachment.cgi?id=97179&action=edit dmesg, linux 3.13.7, patched with v3 Here you are... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/35a63a1a/attachment.html>
[PATCH 4/5] drm/exynos: add support for apb mapped phys in hdmi driver
Hi Rahul,
On 02.04.2014 19:13, Rahul Sharma wrote:
> From: Rahul Sharma
>
> Previous SoCs have hdmi phys which are accessible through
> dedicated i2c lines. Newer SoCs have Apb mapped hdmi phys.
> Hdmi driver is modified to support apb mapped phys.
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 142
> +-
> drivers/gpu/drm/exynos/regs-hdmi.h |7 ++
> 2 files changed, 96 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 5b2cfe7..5989770 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -68,6 +69,8 @@ enum hdmi_type {
>
> struct hdmi_driver_data {
> unsigned int type;
> + const struct hdmiphy_config *phy_confs;
> + unsigned int phy_conf_count;
> unsigned int is_apb_phy:1;
> };
>
> @@ -196,9 +199,12 @@ struct hdmi_context {
> struct hdmi_resources res;
>
> int hpd_gpio;
> + void __iomem*regs_hdmiphy;
> struct regmap *pmureg;
>
> enum hdmi_type type;
> + const struct hdmiphy_config *phy_confs;
> + unsigned intphy_conf_count;
> };
>
> struct hdmiphy_config {
> @@ -206,14 +212,6 @@ struct hdmiphy_config {
> u8 conf[32];
> };
>
> -struct hdmi_driver_data exynos4212_hdmi_driver_data = {
> - .type = HDMI_TYPE14,
> -};
> -
> -struct hdmi_driver_data exynos5_hdmi_driver_data = {
> - .type = HDMI_TYPE14,
> -};
> -
> /* list of phy config settings */
> static const struct hdmiphy_config hdmiphy_v13_configs[] = {
> {
> @@ -428,6 +426,21 @@ static const struct hdmiphy_config hdmiphy_v14_configs[]
> = {
> },
> };
>
> +
> +struct hdmi_driver_data exynos4212_hdmi_driver_data = {
> + .type = HDMI_TYPE14,
> + .phy_confs = hdmiphy_v14_configs,
> + .phy_conf_count = ARRAY_SIZE(hdmiphy_v14_configs),
> + .is_apb_phy = 0,
> +};
> +
> +struct hdmi_driver_data exynos5_hdmi_driver_data = {
> + .type = HDMI_TYPE14,
> + .phy_confs = hdmiphy_v13_configs,
> + .phy_conf_count = ARRAY_SIZE(hdmiphy_v13_configs),
> + .is_apb_phy = 0,
> +};
> +
> static inline u32 hdmi_reg_read(struct hdmi_context *hdata, u32 reg_id)
> {
> return readl(hdata->regs + reg_id);
> @@ -447,6 +460,48 @@ static inline void hdmi_reg_writemask(struct
> hdmi_context *hdata,
> writel(value, hdata->regs + reg_id);
> }
>
> +static int hdmiphy_reg_writeb(struct hdmi_context *hdata,
> + u32 reg_offset, u8 value)
> +{
> + if (hdata->hdmiphy_port) {
> + u8 buffer[2];
> + int ret;
> +
> + buffer[0] = reg_offset;
> + buffer[1] = value;
> +
> + ret = i2c_master_send(hdata->hdmiphy_port, buffer, 2);
> + if (ret == 2)
> + return 0;
> + return ret;
> + } else {
> + writeb(value, hdata->regs_hdmiphy + (reg_offset<<2));
> + return 0;
> + }
> +}
> +
> +static int hdmiphy_reg_write_buf(struct hdmi_context *hdata,
> + u32 reg_offset, const u8 *buf, u32 len)
> +{
> + if ((reg_offset + len) > 32)
> + return -EINVAL;
> +
> + if (hdata->hdmiphy_port) {
> + int ret;
> +
> + ret = i2c_master_send(hdata->hdmiphy_port, buf, len);
reg_offset doesn't seem to be used in I2C code path in any way. Are you
sure this is correct?
> + if (ret == len)
> + return 0;
> + return ret;
> + } else {
> + int i;
> + for (i = 0; i < len; i++)
> + writeb(buf[i], hdata->regs_hdmiphy +
> + ((reg_offset + i)<<2));
> + return 0;
> + }
> +}
I wonder if those functions couldn't be abstracted as two callbacks in
hdmi_driver_data struct to eliminate such if clauses as above.
--
Best regards,
Tomasz
[PATCH v2 libdrm 1/7] configure: Support symbol visibility when available
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding wrote: > diff --git a/libdrm.h b/libdrm.h > new file mode 100644 > index ..23926e6f6741 > --- /dev/null > +++ b/libdrm.h > @@ -0,0 +1,34 @@ > +/* > + * Copyright ? 2014 NVIDIA Corporation > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > + * OTHER DEALINGS IN THE SOFTWARE. > + */ > + > +#ifndef LIBDRM_LIBDRM_H > +#define LIBDRM_LIBDRM_H LIBDRM_LIBDRM_H sounds a bit clunky to me. Why LIBDRM twice? The other headers don't seem to prefix LIBDRM_ to their header-guards. In fact, many of them don't even have header-guards. Also, does these macro really warrant making a top-level, generically named header?
[PATCH v2 libdrm 4/7] tegra: Add channel, job, pushbuf and fence APIs
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
wrote:
> diff --git a/tegra/fence.c b/tegra/fence.c
> new file mode 100644
> index ..f58725ca8472
> --- /dev/null
> +++ b/tegra/fence.c
> +drm_public
> +int drm_tegra_fence_wait(struct drm_tegra_fence *fence)
> +{
> + return drm_tegra_fence_wait_timeout(fence, -1);
> +}
Perhaps a convenience-wrapper like this should be inline in the header
to reduce function-call overhead?
> +drm_public
> +int drm_tegra_job_submit(struct drm_tegra_job *job,
> +struct drm_tegra_fence **fencep)
> +{
> + struct drm_tegra *drm = job->channel->drm;
> + struct drm_tegra_pushbuf_private *pushbuf;
> + struct drm_tegra_fence *fence = NULL;
> + struct drm_tegra_cmdbuf *cmdbufs;
> + struct drm_tegra_syncpt *syncpts;
> + struct drm_tegra_submit args;
> + unsigned int i;
> + int err;
> +
> + /*
> +* Make sure the current command stream buffer is queued for
> +* submission.
> +*/
> + err = drm_tegra_pushbuf_queue(job->pushbuf);
> + if (err < 0)
> + return err;
> +
> + job->pushbuf = NULL;
> +
> + if (fencep) {
> + fence = calloc(1, sizeof(*fence));
> + if (!fence)
> + return -ENOMEM;
> + }
> +
> + syncpts = calloc(1, sizeof(*syncpts));
> + if (!syncpts) {
> + free(cmdbufs);
cmdbufs never gets assigned to, yet it gets free'd here (and a few
more places further down). I guess this is left-overs from the
previous round that should just die?
But this raises the question, how is job->cmdbufs (and job->relocs)
supposed to get free'd?
I'm a bit curious as to what the expected life-time of these objects
are. Do I need to create a new job-object for each submit, or can I
reuse a job? I think the latter would be preferable... So perhaps we
should have a drm_tegra_job_reset that allows us to throw away the
accumulated cmdbufs and relocs, and start building a new job?
> diff --git a/tegra/private.h b/tegra/private.h
> index 9b6bc9395d23..fc74fb56b58d 100644
> --- a/tegra/private.h
> +++ b/tegra/private.h
> @@ -26,13 +26,31 @@
> #define __DRM_TEGRA_PRIVATE_H__ 1
>
> #include
> +#include
> #include
>
> #include
> +#include
> #include
>
> +#include "tegra_drm.h"
> #include "tegra.h"
>
> +#define container_of(ptr, type, member) ({ \
> + const typeof(((type *)0)->member) *__mptr = (ptr); \
> + (type *)((char *)__mptr - offsetof(type, member)); \
> + })
> +
> +
> +struct drm_tegra_pushbuf_private {
> + struct drm_tegra_pushbuf base;
> + struct drm_tegra_job *job;
> + drmMMListHead list;
> + drmMMListHead bos;
> +
> + struct drm_tegra_bo *bo;
> + uint32_t *start;
> + uint32_t *end;
> +};
> +
> +static inline struct drm_tegra_pushbuf_private *
> +pushbuf_priv(struct drm_tegra_pushbuf *pb)
> +{
> + return container_of(pb, struct drm_tegra_pushbuf_private, base);
> +}
> +
This seems to be the only use-case for container_of, and it just
happens to return the exact same pointer as was passed in... so do we
really need that helper?
> diff --git a/tegra/pushbuf.c b/tegra/pushbuf.c
> new file mode 100644
> index ..178d5cd57541
> --- /dev/null
> +++ b/tegra/pushbuf.c
> @@ -0,0 +1,205 @@
> +drm_public
> +int drm_tegra_pushbuf_new(struct drm_tegra_pushbuf **pushbufp,
> + struct drm_tegra_job *job)
> +{
> + struct drm_tegra_pushbuf_private *pushbuf;
> + void *ptr;
> + int err;
> +
> + pushbuf = calloc(1, sizeof(*pushbuf));
> + if (!pushbuf)
> + return -ENOMEM;
> +
> + DRMINITLISTHEAD(&pushbuf->list);
> + DRMINITLISTHEAD(&pushbuf->bos);
> + pushbuf->job = job;
> +
> + *pushbufp = &pushbuf->base;
> +
> + DRMLISTADD(&pushbuf->list, &job->pushbufs);
Hmm. So the job keeps a list of pushbufs. What purpose does this
serve? Shouldn't the job only need the cmdbuf-list (which it already
has) and the BOs (so they can be dereferenced after being submitted)?
AFAICT, we could make drm_tegra_pushbuf_queue append the BO to a list
in the job instead. That way we don't need to keep all the
pushbuf-objects around, and we might even be able to reuse the same
object rather than keep reallocating them. No?
> +drm_public
> +int drm_tegra_pushbuf_sync(struct drm_tegra_pushbuf *pushbuf,
> + enum drm_tegra_syncpt_cond cond)
> +{
> + struct drm_tegra_pushbuf_private *priv = pushbuf_priv(pushbuf);
> +
> + if (cond >= DRM_TEGRA_SYNCPT_COND_MAX)
> + return -EINVAL;
> +
> + *pushbuf->ptr++ = HOST1X_OPCODE_NONINCR(0x0, 0x1);
> + *pushbuf->ptr++ = cond << 8 | priv->job->syncpt;
Perhaps "HOST1X_OPCODE_IMM(0x0, cond << 8 | priv->job->syncpt)", which
saves a word?
Either way, I think this should either ca
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 --- Comment #27 from Alex Deucher --- Created attachment 97176 --> https://bugs.freedesktop.org/attachment.cgi?id=97176&action=edit limit mclk Another patch to try. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/959c434e/attachment.html>
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 --- Comment #26 from Alex Deucher --- Created attachment 97175 --> https://bugs.freedesktop.org/attachment.cgi?id=97175&action=edit disable voltage control Does this patch help? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/b6be7ea7/attachment.html>
[PATCH 3/5] drm/exynos: remove unnecessary read for phy configuration values
On 02.04.2014 19:13, Rahul Sharma wrote:
> From: Rahul Sharma
>
> Cleaning up unnecessary i2c read call after hdmiphy configuration.
> This check is redundant since check for hdmiphy pll lock status
> confirms the correct settings for phy.
>
> Signed-off-by: Rahul Sharma
> Signed-off-by: Daniel Kurtz
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 47b8c06..5b2cfe7 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1518,7 +1518,6 @@ static void hdmiphy_conf_apply(struct hdmi_context
> *hdata)
> const u8 *hdmiphy_data;
> u8 buffer[32];
> u8 operation[2];
> - u8 read_buffer[32] = {0, };
> int ret;
> int i;
>
> @@ -1558,15 +1557,6 @@ static void hdmiphy_conf_apply(struct hdmi_context
> *hdata)
> return;
> }
>
> - ret = i2c_master_recv(hdata->hdmiphy_port, read_buffer, 32);
> - if (ret < 0) {
> - DRM_ERROR("failed to read hdmiphy config\n");
> - return;
> - }
> -
> - for (i = 0; i < ret; i++)
> - DRM_DEBUG_KMS("hdmiphy[0x%02x] write[0x%02x] - "
> - "recv [0x%02x]\n", i, buffer[i], read_buffer[i]);
> }
>
> static void hdmi_conf_apply(struct hdmi_context *hdata)
>
Reviewed-by: Tomasz Figa
--
Best regards,
Tomasz
[PATCH 2/5] drm/exynos: use regmap interface to set hdmiphy control bit in pmu
Hi Rahul,
On 02.04.2014 19:13, Rahul Sharma wrote:
> From: Rahul Sharma
>
> Hdmiphy control bit needs to be set before setting the resolution
> to hdmi hardware. This was handled using dummy hdmiphy clock which
> is removed now.
>
> PMU is already defined as system controller for exynos SoC. Registers
> of PMU are accessed using regmap interfaces.
>
> Devicetree binding document for hdmi is also updated.
>
> Signed-off-by: Rahul Sharma
> ---
> .../devicetree/bindings/video/exynos_hdmi.txt |2 ++
> drivers/gpu/drm/exynos/exynos_hdmi.c | 17 +
> drivers/gpu/drm/exynos/regs-hdmi.h |4
> 3 files changed, 23 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index f9187a2..243a499 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -27,6 +27,7 @@ Required properties:
> "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
> - ddc: phandle to the hdmi ddc node
> - phy: phandle to the hdmi phy node
> +- samsung,syscon-phandle: phandle for system controller node for PMU.
>
> Example:
>
> @@ -37,4 +38,5 @@ Example:
> hpd-gpio = <&gpx3 7 1>;
> ddc = <&hdmi_ddc_node>;
> phy = <&hdmi_phy_node>;
> + samsung,syscon-phandle = <&pmu_system_controller>;
> };
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 23abfa0..47b8c06 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -36,6 +36,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
>
> @@ -194,6 +196,7 @@ struct hdmi_context {
> struct hdmi_resources res;
>
> int hpd_gpio;
> + struct regmap *pmureg;
>
> enum hdmi_type type;
> };
> @@ -1853,6 +1856,9 @@ static void hdmi_poweron(struct exynos_drm_display
> *display)
> if (regulator_bulk_enable(res->regul_count, res->regul_bulk))
> DRM_DEBUG_KMS("failed to enable regulator bulk\n");
>
> + /* set pmu hdmiphy control bit to enable hdmiphy */
> + regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
> + PMU_HDMI_PHY_ENABLE_BIT, 1);
> clk_prepare_enable(res->hdmi);
> clk_prepare_enable(res->sclk_hdmi);
>
> @@ -1879,6 +1885,10 @@ static void hdmi_poweroff(struct exynos_drm_display
> *display)
>
> clk_disable_unprepare(res->sclk_hdmi);
> clk_disable_unprepare(res->hdmi);
nit: Blank line would beautify the code a bit.
> + /* reset pmu hdmiphy control bit to disable hdmiphy */
> + regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
> + PMU_HDMI_PHY_ENABLE_BIT, 0);
> +
> regulator_bulk_disable(res->regul_count, res->regul_bulk);
>
> pm_runtime_put_sync(hdata->dev);
> @@ -2128,6 +2138,13 @@ static int hdmi_probe(struct platform_device *pdev)
> goto err_hdmiphy;
> }
>
> + hdata->pmureg = syscon_regmap_lookup_by_phandle(dev->of_node,
> + "samsung,syscon-phandle");
> + if (IS_ERR_OR_NULL(hdata->pmureg)) {
IS_ERR() is the correct macro to check return value of this function.
> + DRM_ERROR("syscon regmap lookup failed.\n");
> + goto err_hdmiphy;
> + }
> +
> pm_runtime_enable(dev);
>
> hdmi_display.ctx = hdata;
> diff --git a/drivers/gpu/drm/exynos/regs-hdmi.h
> b/drivers/gpu/drm/exynos/regs-hdmi.h
> index ef1b3eb..9811d6f 100644
> --- a/drivers/gpu/drm/exynos/regs-hdmi.h
> +++ b/drivers/gpu/drm/exynos/regs-hdmi.h
> @@ -578,4 +578,8 @@
> #define HDMI_TG_VACT_ST4_H HDMI_TG_BASE(0x0074)
> #define HDMI_TG_3D HDMI_TG_BASE(0x00F0)
>
> +/* PMU Registers for PHY */
> +#define PMU_HDMI_PHY_CONTROL 0x700
> +#define PMU_HDMI_PHY_ENABLE_BIT (1<<0)
BIT() macro could be used instead of open coding the shift.
Best regards,
Tomasz
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 --- Comment #25 from Ed Tomlinson --- On the positive side I was able to get a few benchmarks to run to completion and they are up from 30fps on .14 to 40fps with .15-git. The fglrx drivers are faster (80fps) but eventually crash after a day or so which is not unexpected with the (beta) versions. There are now four of us reporting this issue in .14 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/46d5eeec/attachment.html>
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 --- Comment #24 from Ed Tomlinson --- Just to see what happens with the latest drm fixes I built linux from git (last commit 4ba85265790ba3681deeaf73f018c0eb829a7341). I am still seeing corruptions and eventually get stalls. Lots of Apr 10 14:17:11 localhost kernel: [ 2390.829175] VM fault (0x00, vmid 0) at page 0, read from '' (0x) (0) Apr 10 14:17:11 localhost kernel: [ 2390.829178] radeon :01:00.0: GPU fault detected: 147 0x049a4408 Apr 10 14:17:11 localhost kernel: [ 2390.829179] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x Apr 10 14:17:11 localhost kernel: [ 2390.829180] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x with a few like (maybe one for every 100 of the one above): Apr 10 14:17:11 localhost kernel: [ 2390.828639] VM fault (0x08, vmid 13) at page 0, read from 'TC3' (0x54433300) (68) Apr 10 14:17:11 localhost kernel: [ 2390.828642] radeon :01:00.0: GPU fault detected: 147 0x049a0408 Apr 10 14:17:11 localhost kernel: [ 2390.828643] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x Apr 10 14:17:11 localhost kernel: [ 2390.828644] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x1A008008 or Apr 10 14:17:11 localhost kernel: [ 2390.805747] VM fault (0x08, vmid 13) at page 31524, read from 'TC2' (0x54433200) (72) Apr 10 14:17:11 localhost kernel: [ 2390.805749] radeon :01:00.0: GPU fault detected: 147 0x049a4808 Apr 10 14:17:11 localhost kernel: [ 2390.805749] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x Apr 10 14:17:11 localhost kernel: [ 2390.805750] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x or Apr 10 13:42:44 localhost kernel: [ 321.759360] VM fault (0x04, vmid 1) at page 29021, read from 'TC3' (0x54433300) (68) Apr 10 13:42:44 localhost kernel: [ 321.759362] radeon :01:00.0: GPU fault detected: 146 0x0ba20404 Apr 10 13:42:44 localhost kernel: [ 321.759363] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x Apr 10 13:42:44 localhost kernel: [ 321.759363] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x interposed between the much more common message above. These error happen with and without hyperz enabled ( via the following in .xinitrc export R600_HYPERZ=0 export R600_DEBUG=nohyperz ) This is with ddx, glamor, mesa built from todays git (13:30 or so EDT) Once I can get xorg rc to build with builtin glamor I'll try with it too. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/56e30573/attachment-0001.html>
[PATCH 2/6] shm: add sealing API
On 04/10/2014 05:22 PM, David Herrmann wrote: > Hi > > On Thu, Apr 10, 2014 at 11:33 PM, Tony Battersby > wrote: >> For O_DIRECT the kernel pins the submitted pages in memory for DMA by >> incrementing the page reference counts when the I/O is submitted, >> allowing the pages to be modified by DMA even if they are no longer >> mapped in the address space of the process. This is different from a >> regular read(), which uses the CPU to copy the data and will fail if the >> pages are not mapped. > > Can you please provide an example code-path? For instance, > file_read_actor() does not pin any pages but only keeps the user-space > address and resolves it once it has data to write. This may be an issue for anything in the kernel that calls get_user_pages and holds onto the result at any time that mmap_sem isn't held. I don't know exactly what does that, but RDMA comes to mind. So does (ugh!) vmsplice, although I suspect that vmsplice doesn't write. --Andy
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 --- Comment #23 from dunkelfuerst --- Created attachment 97173 --> https://bugs.freedesktop.org/attachment.cgi?id=97173&action=edit lspci -vnn Here you go. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/48aa7175/attachment.html>
[PATCH 2/6] shm: add sealing API
(reposted from my comments at http://lwn.net/Articles/593918/) I may have thought of a way to subvert SEAL_WRITE using O_DIRECT and asynchronous I/O. I am not sure if this is a real problem or not, but better to ask, right? The exploit would go like this: 1) mmap() the shared memory 2) open some *other* file with O_DIRECT 3) prepare a read-type iocb for the *other* file pointing to the mmap()ed memory 4) io_submit(), but don't wait for it to complete 5) munmap() the shared memory 6) SEAL_WRITE the shared memory 7) the "sealed" memory is overwritten by DMA from the disk drive at some point in the future when the I/O completes So this exploit effectively changes the contents of the supposedly write-protected memory after SEAL_WRITE is granted. For O_DIRECT the kernel pins the submitted pages in memory for DMA by incrementing the page reference counts when the I/O is submitted, allowing the pages to be modified by DMA even if they are no longer mapped in the address space of the process. This is different from a regular read(), which uses the CPU to copy the data and will fail if the pages are not mapped. I am sure there are also other direct I/O mechanisms in the kernel that can be used to setup a DMA transfer to change the contents of unmapped memory; the SCSI generic driver comes to mind. I suppose SEAL_WRITE could iterate over all the pages in the file and check to make sure no page refcount is greater than the "expected" value, and return an error instead of granting the seal if a page is found with an unexpected extra reference that might have been added by e.g. get_user_pages() for direct I/O. But looking over shmem_set_seals() in patch 2/6, it doesn't seem to do that. Tony Battersby Cybernetics
[PATCH 1/5] drm/exynos: remove dummy hdmiphy clock from hdmi driver
Hi Rahul,
On 02.04.2014 19:13, Rahul Sharma wrote:
> From: Rahul Sharma
>
> Exynos drm hdmi driver used to get dummy hdmiphy clock to
> control the PMU bit for hdmiphy. This clock is removed
> during CCF migration. This should also be cleaned from
> hdmi driver.
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c |8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 25bf65a..23abfa0 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -74,7 +74,6 @@ struct hdmi_resources {
> struct clk *sclk_hdmi;
> struct clk *sclk_pixel;
> struct clk *sclk_hdmiphy;
> - struct clk *hdmiphy;
> struct clk *mout_hdmi;
> struct regulator_bulk_data *regul_bulk;
> int regul_count;
> @@ -1854,7 +1853,6 @@ static void hdmi_poweron(struct exynos_drm_display
> *display)
> if (regulator_bulk_enable(res->regul_count, res->regul_bulk))
> DRM_DEBUG_KMS("failed to enable regulator bulk\n");
>
> - clk_prepare_enable(res->hdmiphy);
> clk_prepare_enable(res->hdmi);
> clk_prepare_enable(res->sclk_hdmi);
>
> @@ -1881,7 +1879,6 @@ static void hdmi_poweroff(struct exynos_drm_display
> *display)
>
> clk_disable_unprepare(res->sclk_hdmi);
> clk_disable_unprepare(res->hdmi);
> - clk_disable_unprepare(res->hdmiphy);
> regulator_bulk_disable(res->regul_count, res->regul_bulk);
>
> pm_runtime_put_sync(hdata->dev);
> @@ -1977,11 +1974,6 @@ static int hdmi_resources_init(struct hdmi_context
> *hdata)
> DRM_ERROR("failed to get clock 'sclk_hdmiphy'\n");
> goto fail;
> }
> - res->hdmiphy = devm_clk_get(dev, "hdmiphy");
> - if (IS_ERR(res->hdmiphy)) {
> - DRM_ERROR("failed to get clock 'hdmiphy'\n");
> - goto fail;
> - }
> res->mout_hdmi = devm_clk_get(dev, "mout_hdmi");
> if (IS_ERR(res->mout_hdmi)) {
> DRM_ERROR("failed to get clock 'mout_hdmi'\n");
>
This patch makes the series non-bisectable. If you remove handling of
this dummy clock until you add proper support for PHY isolation setting,
then at this point you end up with non-working code.
You should first provide new infrastructure in parallel to existing one,
then move all users to new one and only then drop the old one.
Best regards,
Tomasz
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 --- Comment #22 from Alex Deucher --- Can you post the pci ids and subsystem ids for your cards? e.g., lspci -vnn -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/59ff658e/attachment.html>
[PATCH 2/2] [RFC v2 with seqcount] reservation: add suppport for read-only access using rcu
op 10-04-14 13:08, Thomas Hellstrom schreef:
> On 04/10/2014 12:07 PM, Maarten Lankhorst wrote:
>> Hey,
>>
>> op 10-04-14 10:46, Thomas Hellstrom schreef:
>>> Hi!
>>>
>>> Ugh. This became more complicated than I thought, but I'm OK with moving
>>> TTM over to fence while we sort out
>>> how / if we're going to use this.
>>>
>>> While reviewing, it struck me that this is kind of error-prone, and hard
>>> to follow since we're operating on a structure that may be
>>> continually updated under us, needing a lot of RCU-specific macros and
>>> barriers.
>> Yeah, but with the exception of dma_buf_poll I don't think there is
>> anything else
>> outside drivers/base/reservation.c has to deal with rcu.
>>
>>> Also the rcu wait appears to not complete until there are no busy fences
>>> left (new ones can be added while we wait) rather than
>>> waiting on a snapshot of busy fences.
>> This has been by design, because 'wait for bo idle' type of functions
>> only care
>> if the bo is completely idle or not.
> No, not when using RCU, because the bo may be busy again before the
> function returns :)
> Complete idleness can only be guaranteed if holding the reservation, or
> otherwise making sure
> that no new rendering is submitted to the buffer, so it's an overkill to
> wait for complete idleness here.
You're probably right, but it makes waiting a lot easier if I don't have to
deal with memory allocations. :P
>> It would be easy to make a snapshot even without seqlocks, just copy
>> reservation_object_test_signaled_rcu to return a shared list if
>> test_all is set, or return pointer to exclusive otherwise.
>>
>>> I wonder if these issues can be addressed by having a function that
>>> provides a snapshot of all busy fences: This can be accomplished
>>> either by including the exclusive fence in the fence_list structure and
>>> allocate a new such structure each time it is updated. The RCU reader
>>> could then just make a copy of the current fence_list structure pointed
>>> to by &obj->fence, but I'm not sure we want to reallocate *each* time we
>>> update the fence pointer.
>> No, the most common operation is updating fence pointers, which is why
>> the current design makes that cheap. It's also why doing rcu reads is
>> more expensive.
>>> The other approach uses a seqlock to obtain a consistent snapshot, and
>>> I've attached an incomplete outline, and I'm not 100% whether it's OK to
>>> combine RCU and seqlocks in this way...
>>>
>>> Both these approaches have the benefit of hiding the RCU snapshotting in
>>> a single function, that can then be used by any waiting
>>> or polling function.
>>>
>> I think the middle way with using seqlocks to protect the fence_excl
>> pointer and shared list combination,
>> and using RCU to protect the refcounts for fences and the availability
>> of the list could work for our usecase
>> and might remove a bunch of memory barriers. But yeah that depends on
>> layering rcu and seqlocks.
>> No idea if that is allowed. But I suppose it is.
>>
>> Also, you're being overly paranoid with seqlock reading, we would only
>> need something like this:
>>
>> rcu_read_lock()
>> preempt_disable()
>> seq = read_seqcount_begin()
>> read fence_excl, shared_count = ACCESS_ONCE(fence->shared_count)
>> copy shared to a struct.
>> if (read_seqcount_retry()) { unlock and retry }
>>preempt_enable();
>>use fence_get_rcu() to bump refcount on everything, if that fails
>> unlock, put, and retry
>> rcu_read_unlock()
>>
>> But the shared list would still need to be RCU'd, to make sure we're
>> not reading freed garbage.
> Ah. OK,
> But I think we should use rcu inside seqcount, because
> read_seqcount_begin() may spin for a long time if there are
> many writers. Also I don't think the preempt_disable() is needed for
> read_seq critical sections other than they might
> decrease the risc of retries..
>
Reading the seqlock code makes me suspect that's the case too. The lockdep code
calls
local_irq_disable, so it's probably safe without preemption disabled.
~Maarten
I like the ability of not allocating memory, so I kept
reservation_object_wait_timeout_rcu mostly
the way it was. This code appears to fail on nouveau when using the shared
members,
but I'm not completely sure whether the error is in nouveau or this code yet.
--8<
[RFC v2] reservation: add suppport for read-only access using rcu
This adds 4 more functions to deal with rcu.
reservation_object_get_fences_rcu() will obtain the list of shared
and exclusive fences without obtaining the ww_mutex.
reservation_object_wait_timeout_rcu() will wait on all fences of the
reservation_object, without obtaining the ww_mutex.
reservation_object_test_signaled_rcu() will test if all fences of the
reservation_object are signaled without using the ww_mutex.
reservation_object_get_excl() is added because touching the fence_excl
member directly will trigger a sparse warning.
Signed-off-by: Maarten Lankhorst
diff --git a/dr
[PATCH 0/6] File Sealing & memfd_create()
On Thu, Apr 10, 2014 at 12:14:27PM -0700, Andy Lutomirski wrote: > > This is the second time in a week that someone has asked for a way to > have a struct file (or struct inode or whatever) that can't be reopened > through /proc/pid/fd. This should be quite easy to implement as a > separate feature. What I suggested on a different thread was to add the following new file descriptor flags, to join FD_CLOEXEC, which would be maniuplated using the F_GETFD and F_SETFD fcntl commands: FD_NOPROCFS disallow being able to open the inode via /proc//fd FD_NOPASSFD disallow being able to pass the fd via a unix domain socket FD_LOCKFLAGSif this bit is set, disallow any further changes of FD_CLOEXEC, FD_NOPROCFS, FD_NOPASSFD, and FD_LOCKFLAGS flags. Regardless of what else we might need to meet the use case for the proposed File Sealing API, I think this is a useful feature that could be used in many other contexts besides just the proposed memfd_create() use case. Cheers, - Ted
[PATCH 0/6] File Sealing & memfd_create()
On Thu, Apr 10, 2014 at 4:16 PM, David Herrmann wrote: > Hi > > On Fri, Apr 11, 2014 at 1:05 AM, Andy Lutomirski > wrote: >> /proc/pid/fd is a really weird corner case in which the mode of an >> inode that doesn't have a name matters. I suspect that almost no one >> will ever want to open one of these things out of /proc/self/fd, and >> those who do should be made to think about it. > > I'm arguing in the context of memfd, and there's no security leak if > people get access to the underlying inode (at least I'm not aware of > any). I'm not sure what you mean. > As I said, context information is attached to the inode, not > file context, so I'm fine if people want to open multiple file > contexts via /proc. If someone wants to forbid open(), I want to hear > _why_. I assume the memfd object has uid==uid-of-creator and > mode==(777 & ~umask) (which usually results in X00, so no access for > non-owners). I cannot see how /proc is a security issue here. On further reflection, my argument for 000 is crap. As far as I can see, the only time that the mode matters at all when playing with /proc/pid/fd, and they only way to get a non-O_RDWR memfd is using /proc/pid/fd, so I'll argue for 0600 instead. Argument why 0600 is better than 0600 & ~umask: either callers don't care because the inode mode simply doesn't matter or they're using /proc/pid/fd to *reduce* permissions, in which case they'd probably like to avoid having to play with umask or call fchmod. Argument why 0600 is better than 0777 & ~umask: People /prod/pid/fd are the only ones who care, in which case they probably prefer for the permissions not be increased by other users if they give them a reduced-permission fd. Anyway, this is all mostly unimportant. Some text in the man page is probably sufficient, but I still think that 0600 is trivial to implement and a little bit more friendly. --Andy > > Thanks > David -- Andy Lutomirski AMA Capital Management, LLC
[Bug 77274] [drm:dce6_afmt_write_speaker_allocation] *ERROR* Couldn't read Speaker Allocation Data Block: 0
https://bugs.freedesktop.org/show_bug.cgi?id=77274 --- Comment #2 from Alex Deucher --- Might be a duplicate of bug 77002. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/bf8b06cd/attachment.html>
[Bug 77274] [drm:dce6_afmt_write_speaker_allocation] *ERROR* Couldn't read Speaker Allocation Data Block: 0
https://bugs.freedesktop.org/show_bug.cgi?id=77274 --- Comment #1 from Alex Deucher --- Can you bisect? Also, Please attach your dmesg and xorg log rather than pointing to an external pastebin. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/568c44b0/attachment.html>
[PATCH] [ACPI] Default to using the native backlight control on Windows 8 systems
The list of machines in the "Use native backlight" table is getting longer
and longer, which is a solid indication that we're doing something wrong.
Disable the ACPI backlight interface if the system claims to be Windows 8
or later.
Signed-off-by: Matthew Garrett
---
Let's at least get this into -next for 3.16 and figure out whether the
drivers actually work now.
drivers/acpi/video.c | 139 +--
1 file changed, 1 insertion(+), 138 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 48c7e8a..21d2fc9 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -78,14 +78,6 @@ module_param(brightness_switch_enabled, bool, 0644);
static bool allow_duplicates;
module_param(allow_duplicates, bool, 0644);
-/*
- * For Windows 8 systems: used to decide if video module
- * should skip registering backlight interface of its own.
- */
-static int use_native_backlight_param = -1;
-module_param_named(use_native_backlight, use_native_backlight_param, int,
0444);
-static bool use_native_backlight_dmi = false;
-
static int register_count;
static struct mutex video_list_lock;
static struct list_head video_bus_head;
@@ -230,18 +222,9 @@ static int acpi_video_get_next_level(struct
acpi_video_device *device,
static int acpi_video_switch_brightness(struct acpi_video_device *device,
int event);
-static bool acpi_video_use_native_backlight(void)
-{
- if (use_native_backlight_param != -1)
- return use_native_backlight_param;
- else
- return use_native_backlight_dmi;
-}
-
static bool acpi_video_verify_backlight_support(void)
{
- if (acpi_osi_is_win8() && acpi_video_use_native_backlight() &&
- backlight_device_registered(BACKLIGHT_RAW))
+ if (acpi_osi_is_win8() && backlight_device_registered(BACKLIGHT_RAW))
return false;
return acpi_video_backlight_support();
}
@@ -405,12 +388,6 @@ static int __init video_set_bqc_offset(const struct
dmi_system_id *d)
return 0;
}
-static int __init video_set_use_native_backlight(const struct dmi_system_id *d)
-{
- use_native_backlight_dmi = true;
- return 0;
-}
-
static struct dmi_system_id video_dmi_table[] __initdata = {
/*
* Broken _BQC workaround
http://bugzilla.kernel.org/show_bug.cgi?id=13121
@@ -455,120 +432,6 @@ static struct dmi_system_id video_dmi_table[] __initdata
= {
DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 7720"),
},
},
- {
-.callback = video_set_use_native_backlight,
-.ident = "ThinkPad T430s",
-.matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
- DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T430s"),
- },
- },
- {
-.callback = video_set_use_native_backlight,
-.ident = "ThinkPad X230",
-.matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
- DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X230"),
- },
- },
- {
- .callback = video_set_use_native_backlight,
- .ident = "ThinkPad X1 Carbon",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
- DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X1 Carbon"),
- },
- },
- {
-.callback = video_set_use_native_backlight,
-.ident = "Lenovo Yoga 13",
-.matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
- DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo IdeaPad Yoga 13"),
- },
- },
- {
-.callback = video_set_use_native_backlight,
-.ident = "Dell Inspiron 7520",
-.matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
- DMI_MATCH(DMI_PRODUCT_VERSION, "Inspiron 7520"),
- },
- },
- {
-.callback = video_set_use_native_backlight,
-.ident = "Acer Aspire 5733Z",
-.matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
- DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5733Z"),
- },
- },
- {
-.callback = video_set_use_native_backlight,
-.ident = "Acer Aspire V5-431",
-.matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
- DMI_MATCH(DMI_PRODUCT_NAME, "Aspire V5-431"),
- },
- },
- {
- .callback = video_set_use_native_backlight,
- .ident = "HP ProBook 4340s",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
- DMI_MATCH(DMI_PRODUCT_VERSION, "HP ProBook 4340s"),
- },
- },
- {
- .callback = video_set_use_native_backlight,
- .ident = "HP ProBook 2013 models",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
- DMI_MATCH(DMI_PRODUCT_NAME, "HP ProB
[Bug 77274] New: [drm:dce6_afmt_write_speaker_allocation] *ERROR* Couldn't read Speaker Allocation Data Block: 0
https://bugs.freedesktop.org/show_bug.cgi?id=77274 Priority: medium Bug ID: 77274 Assignee: dri-devel at lists.freedesktop.org Summary: [drm:dce6_afmt_write_speaker_allocation] *ERROR* Couldn't read Speaker Allocation Data Block: 0 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: amnesiac2001 at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI After I upgraded to 3.14 Linux Kernel from 3.13 the HDMI audio isn't working anymore while before it was. After I checked dmesg output I found this row: [drm:dce6_afmt_write_speaker_allocation] *ERROR* Couldn't read Speaker Allocation Data Block: 0 so I thought it was something related to the kernel wasn't able to retrieve correct info from my EDID's display. I'm currently using arch linux distro with mesa 10.1 and xf86-video-ati 7.3.0 Here are my log files: dmesg http://pastebin.com/fH88rXNs Xorg.0.log http://pastebin.com/qcKhTiAs lspci -vv http://pastebin.com/SLcyJJaE -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/5ebd0bb9/attachment.html>
[PATCH v2 1/4] drm: Adding new flag to restrict bitmask drm properties as 32 bit type and 32 bit value pair
Adding Rob and Rusty in the review thread.
Kindly review these patches for interface being proposed to set
color/alpha property of planes modeled after glBlendFunc.
http://lists.freedesktop.org/archives/intel-gfx/2014-March/042350.html
http://lists.freedesktop.org/archives/intel-gfx/2014-March/042351.html
http://lists.freedesktop.org/archives/intel-gfx/2014-March/042352.html
http://lists.freedesktop.org/archives/intel-gfx/2014-March/042587.html
http://lists.freedesktop.org/archives/intel-gfx/2014-March/042354.html
thanks,
Sagar
On Tue, 2014-03-25 at 20:02 +0530, sagar.a.kamble at intel.com wrote:
> From: Sagar Kamble
>
> With this patch new flag DRM_MODE_PROP_32BIT_PAIR is added that will help
> make use
> of 64 bit value of bitmask property as two 32 bit values.
>
> Cc: airlied at linux.ie
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: Sagar Kamble
> ---
> drivers/gpu/drm/drm_crtc.c | 22 --
> include/uapi/drm/drm_mode.h | 3 +++
> 2 files changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 4e43fc2..d0d03ec 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2993,10 +2993,13 @@ int drm_property_add_enum(struct drm_property
> *property, int index,
>
> /*
>* Bitmask enum properties have the additional constraint of values
> - * from 0 to 63
> + * from 0 to 63. For properties with 32BIT_PAIR Flag set this constraint
> + * range is 0 to 31.
>*/
> - if ((property->flags & DRM_MODE_PROP_BITMASK) && (value > 63))
> - return -EINVAL;
> + if (property->flags & DRM_MODE_PROP_BITMASK)
> + if (((property->flags & DRM_MODE_PROP_32BIT_PAIR) && (value >
> 31)) ||
> + (value > 63))
> + return -EINVAL;
>
> if (!list_empty(&property->enum_blob_list)) {
> list_for_each_entry(prop_enum, &property->enum_blob_list, head)
> {
> @@ -3305,9 +3308,16 @@ static bool drm_property_change_is_valid(struct
> drm_property *property,
> } else if (property->flags & DRM_MODE_PROP_BITMASK) {
> int i;
> uint64_t valid_mask = 0;
> - for (i = 0; i < property->num_values; i++)
> - valid_mask |= (1ULL << property->values[i]);
> - return !(value & ~valid_mask);
> + uint32_t valid_32bit_mask = 0;
> + if (property->flags & DRM_MODE_PROP_32BIT_PAIR) {
> + for (i = 0; i < property->num_values; i++)
> + valid_32bit_mask |= (1UL <<
> property->values[i]);
> + return !((value & 0x) & ~valid_32bit_mask);
> + } else {
> + for (i = 0; i < property->num_values; i++)
> + valid_mask |= (1ULL << property->values[i]);
> + return !(value & ~valid_mask);
> + }
> } else if (property->flags & DRM_MODE_PROP_BLOB) {
> /* Only the driver knows */
> return true;
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index f104c26..5e3a7d9 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -250,6 +250,9 @@ struct drm_mode_get_connector {
> #define DRM_MODE_PROP_ENUM (1<<3) /* enumerated type with text strings */
> #define DRM_MODE_PROP_BLOB (1<<4)
> #define DRM_MODE_PROP_BITMASK(1<<5) /* bitmask of enumerated types */
> +#define DRM_MODE_PROP_32BIT_PAIR (1<<6) /* 32 bit bitmask of enumerated types
> + * and 32 bit of value of the type */
> +
>
> struct drm_mode_property_enum {
> __u64 value;
[PATCH] drm/radeon: Inline r100_mm_rreg
This was originally un-inlined by Andi Kleen in 2011 citing size concerns.
Indeed, inlining it grows radeon.ko by 7%.
However, 2% of cpu is spent in this function. Inlining it gives 1% more fps
in Urban Terror.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/r100.c | 18 --
drivers/gpu/drm/radeon/radeon.h | 20 ++--
2 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index b6c3264..8169e82 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -4086,24 +4086,6 @@ int r100_init(struct radeon_device *rdev)
return 0;
}
-uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t reg,
- bool always_indirect)
-{
- if (reg < rdev->rmmio_size && !always_indirect)
- return readl(((void __iomem *)rdev->rmmio) + reg);
- else {
- unsigned long flags;
- uint32_t ret;
-
- spin_lock_irqsave(&rdev->mmio_idx_lock, flags);
- writel(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX);
- ret = readl(((void __iomem *)rdev->rmmio) + RADEON_MM_DATA);
- spin_unlock_irqrestore(&rdev->mmio_idx_lock, flags);
-
- return ret;
- }
-}
-
void r100_mm_wreg(struct radeon_device *rdev, uint32_t reg, uint32_t v,
bool always_indirect)
{
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5cf10a7..9231100 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2330,8 +2330,24 @@ int radeon_device_init(struct radeon_device *rdev,
void radeon_device_fini(struct radeon_device *rdev);
int radeon_gpu_wait_for_idle(struct radeon_device *rdev);
-uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t reg,
- bool always_indirect);
+static inline uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t reg,
+ bool always_indirect)
+{
+ if (reg < rdev->rmmio_size && !always_indirect)
+ return readl(((void __iomem *)rdev->rmmio) + reg);
+ else {
+ unsigned long flags;
+ uint32_t ret;
+
+ spin_lock_irqsave(&rdev->mmio_idx_lock, flags);
+ writel(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX);
+ ret = readl(((void __iomem *)rdev->rmmio) + RADEON_MM_DATA);
+ spin_unlock_irqrestore(&rdev->mmio_idx_lock, flags);
+
+ return ret;
+ }
+}
+
void r100_mm_wreg(struct radeon_device *rdev, uint32_t reg, uint32_t v,
bool always_indirect);
u32 r100_io_rreg(struct radeon_device *rdev, u32 reg);
--
1.8.3.1
[PATCH 0/6] File Sealing & memfd_create()
On Thu, Apr 10, 2014 at 3:57 PM, David Herrmann wrote: > Hi > > On Thu, Apr 10, 2014 at 11:16 PM, Andy Lutomirski > wrote: >> Would it make sense for the initial mode on a memfd inode to be 000? >> Anyone who finds this to be problematic could use fchmod to fix it. > > memfd_create() should be subject to umask() just like anything else. > That should solve any possible race here, right? Yes, but how many people will actually think about umask when doing things that don't really look like creating files? /proc/pid/fd is a really weird corner case in which the mode of an inode that doesn't have a name matters. I suspect that almost no one will ever want to open one of these things out of /proc/self/fd, and those who do should be made to think about it. It also avoids odd screwups where things are secure until someone runs them with umask 000. --Andy
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 --- Comment #21 from johann.fot at gmail.com --- Happens to me too. Only radeon.dpm=0 stabilizes the system. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/380dc5fc/attachment-0001.html>
[PATCH] drm/radeon: Inline r100_mm_rreg
On Thu, Apr 10, 2014 at 2:46 PM, Lauri Kasanen wrote:
> On Thu, 10 Apr 2014 12:19:10 -0400
> Ilia Mirkin wrote:
>
>> > +static inline uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t
>> > reg,
>> > + bool always_indirect)
>> > +{
>> > + if (reg < rdev->rmmio_size && !always_indirect)
>> > + return readl(((void __iomem *)rdev->rmmio) + reg);
>>
>> Quick thought from someone entirely unfamiliar with the hardware:
>> perhaps you can get the performance benefit without the size increase
>> by moving the else portion into a non-inline function? I'm guessing
>> that most accesses happen in the "if" branch.
>
> The function call overhead is about equal to branching overhead, so
> splitting it would only help about half that. It's called from many
> places, and a lot of calls per sec.
Is that really true? I haven't profiled it, but a function call has to
save/restore registers, set up new stack, etc. And the jump is to some
far-away code, so perhaps less likely to be in i-cache? (But maybe
not, not sure on the details of how all that works.) And I'm guessing
most of the size increase is coming from the spinlock/unlock, which,
I'm guessing again, is the much-rarer case.
And the branch would happen either way... so that's a sunk cost.
(Except I bet that the always_indirect param is always constant and
that bit of the if can be resolved at compile time with that part
being inlined.)
Anyways, it was just a thought.
-ilia
Possible fb ref count issue with drm_plane_force_disable()
Hi, I've been debugging omapdrm issues on top of the latest drm mainline changes. Sometimes a drm_framebuffer ref count drops to -1 when aborting a drm application, or unloading the modules. The setup is very basic, just a single crtc with the crtc's primary plane. What seems to happen is: - App is started - fb is created, and taken into use by omapdrm. omapdrm takes a ref to the fb. - the app is starts to shut down - drm_framebuffer_remove is called - fb->refcount.refcount > 1, so it goes to disable stuff - drm_plane_force_disable is called for the primary plane - drm_plane_force_disable does plane->disable_plane, which on omapdrm puts stuff on a workqueue as plane cannot be disabled immediately - drm_plane_force_disable calls __drm_framebuffer_unreference() - at the end of drm_framebuffer_remove(), there's drm_framebuffer_unreference, which causes ref count to go to zero, and the fb to be destroyed - a bit later, the queued work is ran, which does drm_framebuffer_unreference(), and ref count goes to -1. Here omapdrm is removing the ref that had been taken in the beginning. So the explicit unref done by drm_plane_force_disable() seems a bit out of place. I can't figure out which drm_framebuffer_reference() would be the matching one for the unref done by drm_plane_force_disable(). Any ideas what ref is that? Or is the __drm_framebuffer_unreference() extra in drm_plane_force_disable()? Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/dec5cde4/attachment.sig>
[PATCH 0/6] File Sealing & memfd_create()
On Thu, Mar 20, 2014 at 11:32 AM, tytso at mit.edu wrote: > > Looking at your patches, and what files you are modifying, you are > enforcing this in the low-level file system. I would love for this to be implemented in the filesystem level as well. Something like the ext4 immutable bit, but with the ability to still make hardlinks would be *very* useful for OSTree. And anyone else that uses hardlinks as a data source. The vserver people do something similiar: http://linux-vserver.org/util-vserver:Vhashify At the moment I have a read-only bind mount over /usr, but what I really want is to make the individual objects in the object store in /ostree/repo/objects be immutable, so even if a user or app navigates out to /sysroot they still can't mutate them (or the link targets in the visible /usr).
[Bug 77002] hdmi audio problems with 3.14
https://bugs.freedesktop.org/show_bug.cgi?id=77002 --- Comment #35 from bgunteriv at gmail.com --- (In reply to comment #34) > (In reply to comment #29) > > Garret, > > > > make sure your tree is in sync. The patch done by Anssi has already been > > included. It's here: > > https://github.com/OpenELEC/OpenELEC.tv/commit/ > > a333166f7d6fda668cc2184797d302fe89288c9d > > OK the build finished this AM and in the linux/3.14 folder this > reverse-order patch was present. But unfortunately playback is the same. > Machine gun like cyclical sounds with audio coming in and out. > > Any more info needed, please let me know. > > Here is my card [Diamond 7750PE51G]: > > http://www.newegg.com/Product/Product.aspx?Item=N82E16814103206 > > thanks, > Garrett this was my fear. I don't think your problem fits the scope of this bug. Garrett, can you open a new bug report, and i'll put up my logs as well. this way we won't get the devs confused on this situation. send me a PM on XBMC once you've got it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/93a4e11e/attachment.html>
[PATCH libdrm] drm: Add universal plane capability bit and plane type enums
Signed-off-by: Matt Roper
---
include/drm/drm.h | 8
xf86drmMode.h | 4
2 files changed, 12 insertions(+)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index f0b4c16..229a29f 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -627,6 +627,14 @@ struct drm_get_cap {
*/
#define DRM_CLIENT_CAP_STEREO_3D 1
+/**
+ * DRM_CLIENT_CAP_UNIVERSAL_PLANES
+ *
+ * if set to 1, the DRM core will expose the full universal plane list
+ * (including primary and cursor planes).
+ */
+#define DRM_CLIENT_CAP_UNIVERSAL_PLANES 2
+
/** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
struct drm_set_client_cap {
__u64 capability;
diff --git a/xf86drmMode.h b/xf86drmMode.h
index 9bcb1d1..a0db82b 100644
--- a/xf86drmMode.h
+++ b/xf86drmMode.h
@@ -296,6 +296,10 @@ typedef struct _drmModeConnector {
uint32_t *encoders; /**< List of encoder ids */
} drmModeConnector, *drmModeConnectorPtr;
+#define DRM_PLANE_TYPE_OVERLAY 0
+#define DRM_PLANE_TYPE_PRIMARY 1
+#define DRM_PLANE_TYPE_CURSOR 2
+
typedef struct _drmModeObjectProperties {
uint32_t count_props;
uint32_t *props;
--
1.8.5.1
[Bug 77002] hdmi audio problems with 3.14
https://bugs.freedesktop.org/show_bug.cgi?id=77002 --- Comment #34 from Garrett --- (In reply to comment #29) > Garret, > > make sure your tree is in sync. The patch done by Anssi has already been > included. It's here: > https://github.com/OpenELEC/OpenELEC.tv/commit/ > a333166f7d6fda668cc2184797d302fe89288c9d OK the build finished this AM and in the linux/3.14 folder this reverse-order patch was present. But unfortunately playback is the same. Machine gun like cyclical sounds with audio coming in and out. Any more info needed, please let me know. Here is my card [Diamond 7750PE51G]: http://www.newegg.com/Product/Product.aspx?Item=N82E16814103206 thanks, Garrett -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/c74601ff/attachment-0001.html>
[Bug 77269] New: libdrm (git) 2.4.52 make check fail
https://bugs.freedesktop.org/show_bug.cgi?id=77269 Priority: medium Bug ID: 77269 Assignee: dri-devel at lists.freedesktop.org Summary: libdrm (git) 2.4.52 make check fail Severity: normal Classification: Unclassified OS: All Reporter: monts.here2 at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: DRI CVS Component: libdrm Product: DRI config Core i3 haswell uname -a Linux em1 3.15.0-0.rc0.git9.2.fc21.x86_64 #1 SMP Mon Apr 7 13:25:48 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-isl=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/cloog-install --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) ===config ./autogen.sh --enable-udev --disable-radeon --disable-nouveau make -j8 make -j check <= fails ../build-aux/test-driver: line 95: 23128 Aborted (core dumped) "$@" > $log_file 2>&1 FAIL: updatedraw PASS: gem_flink ../build-aux/test-driver: line 95: 23130 Aborted (core dumped) "$@" > $log_file 2>&1 FAIL: setversion PASS: gem_readwrite PASS: gem_mmap make[5]: Entering directory `/opt/src/drm/tests' Making all in modeprint make[6]: Entering directory `/opt/src/drm/tests/modeprint' make[6]: Nothing to be done for `all'. make[6]: Leaving directory `/opt/src/drm/tests/modeprint' Making all in kmstest make[6]: Entering directory `/opt/src/drm/tests/kmstest' make[6]: Nothing to be done for `all'. make[6]: Leaving directory `/opt/src/drm/tests/kmstest' Making all in modetest make[6]: Entering directory `/opt/src/drm/tests/modetest' make[6]: Nothing to be done for `all'. make[6]: Leaving directory `/opt/src/drm/tests/modetest' Making all in vbltest make[6]: Entering directory `/opt/src/drm/tests/vbltest' make[6]: Nothing to be done for `all'. make[6]: Leaving directory `/opt/src/drm/tests/vbltest' make[6]: Entering directory `/opt/src/drm/tests' make[6]: Nothing to be done for `all-am'. make[6]: Leaving directory `/opt/src/drm/tests' make[5]: Leaving directory `/opt/src/drm/tests' Testsuite summary for libdrm 2.4.52 # TOTAL: 11 # PASS: 9 # SKIP: 0 # XFAIL: 0 # FAIL: 2 # XPASS: 0 # ERROR: 0 See tests/test-suite.log Please report to https://bugs.freedesktop.org/enter_bug.cgi?product=DRI make[4]: *** [test-suite.log] Error 1 make[4]: Leaving directory `/opt/src/drm/tests' make[3]: *** [check-TESTS] Error 2 make[3]: Leaving directory `/opt/src/drm/tests' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/opt/src/drm/tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/opt/src/drm/tests' make: *** [check-recursive] Error 1 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/cd9a06f3/attachment.html>
[PATCH] drm/plane-helper: Fix primary plane scaling check
The src_w / src_h parameters to update_plane include a subpixel offset;
we need to shift off the subpixel bits before comparing to CRTC size
when checking for primary plane scaling.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_plane_helper.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/drivers/gpu/drm/drm_plane_helper.c
index e768d35..9eca283 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -145,6 +145,8 @@ int drm_primary_helper_update(struct drm_plane *plane,
struct drm_crtc *crtc,
}
/* Disallow scaling */
+ src_w >>= 16;
+ src_h >>= 16;
if (crtc_w != src_w || crtc_h != src_h) {
DRM_DEBUG_KMS("Can't scale primary plane\n");
return -EINVAL;
--
1.8.5.1
[PATCH 0/6] File Sealing & memfd_create()
On Thu, Apr 10, 2014 at 1:49 PM, David Herrmann
wrote:
> Hi
>
> On Thu, Apr 10, 2014 at 10:37 PM, Andy Lutomirski
> wrote:
>> It occurs to me that, before going nuts with these kinds of flags, it
>> may pay to just try to fix the /proc/self/fd issue for real -- we
>> could just make open("/proc/self/fd/3", O_RDWR) fail if fd 3 is
>> read-only. That may be enough for the file sealing thing.
>
> For the sealing API, none of this is needed. As long as the inode is
> owned by the uid who creates the memfd, you can pass it around and
> no-one besides root and you can open /proc/self/fd/$fd (assuming chmod
> 700). If you share the fd with someone with the same uid as you,
> you're screwed anyway. We don't protect users against themselves (I
> mean, they can ptrace you, or kill()..). Therefore, I'm not really
> convinced that we want this for memfd. At least no-one has provided a
> _proper_ use-case for this so far.
Hmm. Fair enough.
Would it make sense for the initial mode on a memfd inode to be 000?
Anyone who finds this to be problematic could use fchmod to fix it.
I might even go so far as to suggest that the default uid on the inode
should be 0 (i.e. global root), since there is the odd corner case of
root setting euid != 0, creating a memfd, and setting euid back to 0.
The latter might cause resource accounting issues, though.
--Andy
[Bug 71891] 3.13 fails to boot with the radeon module
https://bugzilla.kernel.org/show_bug.cgi?id=71891 --- Comment #10 from Christian K?nig --- Created attachment 131871 --> https://bugzilla.kernel.org/attachment.cgi?id=131871&action=edit Possible fix. Please try the attached patch. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 77009] 24P playback video signal loss with latest DRI patches
https://bugs.freedesktop.org/show_bug.cgi?id=77009 --- Comment #29 from Garrett --- (In reply to comment #28) > Depending on the details of their electrical implementation all PLLs behave > more or less like this. The trick is to know how to find the right numbers > without violating the contrains. yup.. This is a fun one to deal with in the embedded environment (love that scope.). I consider this bug fixed. I am not sure if I am supposed to mark it ok or something. Else I will leave it. I thought about the pll thing. I don't know the HDMI message layer at all. I am not sure it is public knowledge anyhow. To get higher divs, I was thinking a potential algo could go (MUCH easier said than done, I know): 1) Run a setup program each time a hardware change is detected. (EDID or GPU) 2) Test LCD/Panel at various popular refresh rates. a) crank up the pll with your new algo. >> *test* if tv accepted it. (requires a knowledge of protocol to check display state, or have user answer ok with a timeout in case it is not readable) >> save the new div setting (maybe the 10% lower ones to be safe) to a config with a table for that hardware/refresh. 3) on reboot load new optimized saved PLL dividers from the table. And on each refresh rate change use the table. But that said. It does not really matter for me to make it closer. Your new algo with your "arbitrary" 100 limit works well on my hardware. I tested 368 and it looked great, too. 368 vs 100 on 24P made vary little difference too me. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/afa0392f/attachment.html>
[PATCH 0/6] File Sealing & memfd_create()
On Thu, Apr 10, 2014 at 1:32 PM, Theodore Ts'o wrote:
> On Thu, Apr 10, 2014 at 12:14:27PM -0700, Andy Lutomirski wrote:
>>
>> This is the second time in a week that someone has asked for a way to
>> have a struct file (or struct inode or whatever) that can't be reopened
>> through /proc/pid/fd. This should be quite easy to implement as a
>> separate feature.
>
> What I suggested on a different thread was to add the following new
> file descriptor flags, to join FD_CLOEXEC, which would be maniuplated
> using the F_GETFD and F_SETFD fcntl commands:
>
> FD_NOPROCFS disallow being able to open the inode via /proc//fd
>
> FD_NOPASSFD disallow being able to pass the fd via a unix domain socket
>
> FD_LOCKFLAGSif this bit is set, disallow any further changes of
> FD_CLOEXEC,
> FD_NOPROCFS, FD_NOPASSFD, and FD_LOCKFLAGS flags.
>
> Regardless of what else we might need to meet the use case for the
> proposed File Sealing API, I think this is a useful feature that could
> be used in many other contexts besides just the proposed
> memfd_create() use case.
It occurs to me that, before going nuts with these kinds of flags, it
may pay to just try to fix the /proc/self/fd issue for real -- we
could just make open("/proc/self/fd/3", O_RDWR) fail if fd 3 is
read-only. That may be enough for the file sealing thing.
--Andy
[PATCH 2/2] [RFC] reservation: add suppport for read-only access using rcu
On 04/10/2014 01:08 PM, Thomas Hellstrom wrote: > On 04/10/2014 12:07 PM, Maarten Lankhorst wrote: >> Hey, >> >> op 10-04-14 10:46, Thomas Hellstrom schreef: >>> Hi! >>> >>> Ugh. This became more complicated than I thought, but I'm OK with moving >>> TTM over to fence while we sort out >>> how / if we're going to use this. >>> >>> While reviewing, it struck me that this is kind of error-prone, and hard >>> to follow since we're operating on a structure that may be >>> continually updated under us, needing a lot of RCU-specific macros and >>> barriers. >> Yeah, but with the exception of dma_buf_poll I don't think there is >> anything else >> outside drivers/base/reservation.c has to deal with rcu. >> >>> Also the rcu wait appears to not complete until there are no busy fences >>> left (new ones can be added while we wait) rather than >>> waiting on a snapshot of busy fences. >> This has been by design, because 'wait for bo idle' type of functions >> only care >> if the bo is completely idle or not. > No, not when using RCU, because the bo may be busy again before the > function returns :) > Complete idleness can only be guaranteed if holding the reservation, or > otherwise making sure > that no new rendering is submitted to the buffer, so it's an overkill to > wait for complete idleness here. > Although, if we fail to get a refcount for a fence, and it's still busy we need to do a seq retry, because the fence might have been replaced by another fence from the same context, without being idle. That check is not present in the snapshot code I sent. /Thomas
[Bug 75127] runpm hang with PowerXpress/hybrid laptop
https://bugs.freedesktop.org/show_bug.cgi?id=75127 --- Comment #31 from Alex Deucher --- (In reply to comment #30) > Patch v3 (applied to 3.13.7) doesn't work for me. Again the same messages: > >20.528628] pciehp :00:03.0:pcie04: Device :02:00.0 already exists > at :02:00, cannot hot-add > [ 20.528807] pciehp :00:03.0:pcie04: Cannot add device at :02:00 Please attach your dmesg output with the patch applied. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/0b570f5d/attachment.html>
[PATCH] drm/tegra: Remove gratuitous pad field
On 09.04.2014 15:39, Thierry Reding wrote:
> From: Thierry Reding
>
> The version of the drm_tegra_submit structure that was merged all the
> way back in 3.10 contains a pad field that was originally intended to
> properly pad the following __u64 field. Unfortunately it seems like a
> different field was dropped during review that caused this padding to
> become unnecessary, but the pad field wasn't removed at that time.
>
> One possible side-effect of this is that since the __u64 following the
> pad is now no longer properly aligned, the compiler may (or may not)
> introduce padding itself, which results in no predictable ABI.
>
> Rectify this by removing the pad field so that all fields are again
> naturally aligned. Technically this is breaking existing userspace ABI,
> but given that there aren't any (released) userspace drivers that make
> use of this yet, the fallout should be minimal.
>
> Signed-off-by: Thierry Reding
> ---
> include/uapi/drm/tegra_drm.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
> index b042b48495d9..b75482112428 100644
> --- a/include/uapi/drm/tegra_drm.h
> +++ b/include/uapi/drm/tegra_drm.h
> @@ -120,7 +120,6 @@ struct drm_tegra_submit {
> __u32 num_waitchks;
> __u32 waitchk_mask;
> __u32 timeout;
> - __u32 pad;
> __u64 syncpts;
> __u64 cmdbufs;
> __u64 relocs;
>
The padding is hilarious. I added it to remove the possibility for
compiler to add implicit padding, but it does completely the opposite.
If we'd care about binary compatibility, we could have also just added
__packed to the definition. But as this is in staging, I don't think
that's necessary.
Acked-By: tbergstrom at nvidia.com
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
[PATCH 2/2] [RFC] reservation: add suppport for read-only access using rcu
On 04/10/2014 12:07 PM, Maarten Lankhorst wrote:
> Hey,
>
> op 10-04-14 10:46, Thomas Hellstrom schreef:
>> Hi!
>>
>> Ugh. This became more complicated than I thought, but I'm OK with moving
>> TTM over to fence while we sort out
>> how / if we're going to use this.
>>
>> While reviewing, it struck me that this is kind of error-prone, and hard
>> to follow since we're operating on a structure that may be
>> continually updated under us, needing a lot of RCU-specific macros and
>> barriers.
> Yeah, but with the exception of dma_buf_poll I don't think there is
> anything else
> outside drivers/base/reservation.c has to deal with rcu.
>
>> Also the rcu wait appears to not complete until there are no busy fences
>> left (new ones can be added while we wait) rather than
>> waiting on a snapshot of busy fences.
> This has been by design, because 'wait for bo idle' type of functions
> only care
> if the bo is completely idle or not.
No, not when using RCU, because the bo may be busy again before the
function returns :)
Complete idleness can only be guaranteed if holding the reservation, or
otherwise making sure
that no new rendering is submitted to the buffer, so it's an overkill to
wait for complete idleness here.
>
> It would be easy to make a snapshot even without seqlocks, just copy
> reservation_object_test_signaled_rcu to return a shared list if
> test_all is set, or return pointer to exclusive otherwise.
>
>> I wonder if these issues can be addressed by having a function that
>> provides a snapshot of all busy fences: This can be accomplished
>> either by including the exclusive fence in the fence_list structure and
>> allocate a new such structure each time it is updated. The RCU reader
>> could then just make a copy of the current fence_list structure pointed
>> to by &obj->fence, but I'm not sure we want to reallocate *each* time we
>> update the fence pointer.
> No, the most common operation is updating fence pointers, which is why
> the current design makes that cheap. It's also why doing rcu reads is
> more expensive.
>> The other approach uses a seqlock to obtain a consistent snapshot, and
>> I've attached an incomplete outline, and I'm not 100% whether it's OK to
>> combine RCU and seqlocks in this way...
>>
>> Both these approaches have the benefit of hiding the RCU snapshotting in
>> a single function, that can then be used by any waiting
>> or polling function.
>>
>
> I think the middle way with using seqlocks to protect the fence_excl
> pointer and shared list combination,
> and using RCU to protect the refcounts for fences and the availability
> of the list could work for our usecase
> and might remove a bunch of memory barriers. But yeah that depends on
> layering rcu and seqlocks.
> No idea if that is allowed. But I suppose it is.
>
> Also, you're being overly paranoid with seqlock reading, we would only
> need something like this:
>
> rcu_read_lock()
> preempt_disable()
> seq = read_seqcount_begin()
> read fence_excl, shared_count = ACCESS_ONCE(fence->shared_count)
> copy shared to a struct.
> if (read_seqcount_retry()) { unlock and retry }
> preempt_enable();
> use fence_get_rcu() to bump refcount on everything, if that fails
> unlock, put, and retry
> rcu_read_unlock()
>
> But the shared list would still need to be RCU'd, to make sure we're
> not reading freed garbage.
Ah. OK,
But I think we should use rcu inside seqcount, because
read_seqcount_begin() may spin for a long time if there are
many writers. Also I don't think the preempt_disable() is needed for
read_seq critical sections other than they might
decrease the risc of retries..
Thanks,
Thomas
>
> ~Maarten
[PATCH] drm/radeon: Inline r100_mm_rreg
On Thu, Apr 10, 2014 at 9:08 AM, Lauri Kasanen wrote:
> This was originally un-inlined by Andi Kleen in 2011 citing size concerns.
> Indeed, inlining it grows radeon.ko by 7%.
>
> However, 2% of cpu is spent in this function. Inlining it gives 1% more fps
> in Urban Terror.
>
> Signed-off-by: Lauri Kasanen
> ---
> drivers/gpu/drm/radeon/r100.c | 18 --
> drivers/gpu/drm/radeon/radeon.h | 20 ++--
> 2 files changed, 18 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index b6c3264..8169e82 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -4086,24 +4086,6 @@ int r100_init(struct radeon_device *rdev)
> return 0;
> }
>
> -uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t reg,
> - bool always_indirect)
> -{
> - if (reg < rdev->rmmio_size && !always_indirect)
> - return readl(((void __iomem *)rdev->rmmio) + reg);
> - else {
> - unsigned long flags;
> - uint32_t ret;
> -
> - spin_lock_irqsave(&rdev->mmio_idx_lock, flags);
> - writel(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX);
> - ret = readl(((void __iomem *)rdev->rmmio) + RADEON_MM_DATA);
> - spin_unlock_irqrestore(&rdev->mmio_idx_lock, flags);
> -
> - return ret;
> - }
> -}
> -
> void r100_mm_wreg(struct radeon_device *rdev, uint32_t reg, uint32_t v,
> bool always_indirect)
> {
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 5cf10a7..9231100 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -2330,8 +2330,24 @@ int radeon_device_init(struct radeon_device *rdev,
> void radeon_device_fini(struct radeon_device *rdev);
> int radeon_gpu_wait_for_idle(struct radeon_device *rdev);
>
> -uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t reg,
> - bool always_indirect);
> +static inline uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t reg,
> + bool always_indirect)
> +{
> + if (reg < rdev->rmmio_size && !always_indirect)
> + return readl(((void __iomem *)rdev->rmmio) + reg);
Quick thought from someone entirely unfamiliar with the hardware:
perhaps you can get the performance benefit without the size increase
by moving the else portion into a non-inline function? I'm guessing
that most accesses happen in the "if" branch.
> + else {
> + unsigned long flags;
> + uint32_t ret;
> +
> + spin_lock_irqsave(&rdev->mmio_idx_lock, flags);
> + writel(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX);
> + ret = readl(((void __iomem *)rdev->rmmio) + RADEON_MM_DATA);
> + spin_unlock_irqrestore(&rdev->mmio_idx_lock, flags);
> +
> + return ret;
> + }
> +}
> +
> void r100_mm_wreg(struct radeon_device *rdev, uint32_t reg, uint32_t v,
> bool always_indirect);
> u32 r100_io_rreg(struct radeon_device *rdev, u32 reg);
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] File Sealing & memfd_create()
On 04/08/2014 06:00 AM, Florian Weimer wrote: > On 03/19/2014 08:06 PM, David Herrmann wrote: > >> Unlike existing techniques that provide similar protection, sealing >> allows >> file-sharing without any trust-relationship. This is enforced by >> rejecting seal >> modifications if you don't own an exclusive reference to the given >> file. So if >> you own a file-descriptor, you can be sure that no-one besides you can >> modify >> the seals on the given file. This allows mapping shared files from >> untrusted >> parties without the fear of the file getting truncated or modified by an >> attacker. > > How do you keep these promises on network and FUSE file systems? Surely > there is still some trust involved for such descriptors? > > What happens if you create a loop device on a sealed descriptor? > > Why does memfd_create not create a file backed by a memory region in the > current process? Wouldn't this be a far more generic primitive? > Creating aliases of memory regions would be interesting for many things > (not just libffi bypassing SELinux-enforced NX restrictions :-). If you write a patch to prevent selinux from enforcing NX, I will ack that patch with all my might. I don't know how far it would get me, but I think that selinux has no business going anywhere near execmem. Adding a clone mode to mremap might be a better bet. But memfd solves that problem, too, albeit messily. --Andy
[PATCH 0/6] File Sealing & memfd_create()
On 04/10/2014 07:45 AM, Colin Walters wrote: > On Thu, Mar 20, 2014 at 11:32 AM, tytso at mit.edu wrote: >> >> Looking at your patches, and what files you are modifying, you are >> enforcing this in the low-level file system. > > I would love for this to be implemented in the filesystem level as > well. Something like the ext4 immutable bit, but with the ability to > still make hardlinks would be *very* useful for OSTree. And anyone else > that uses hardlinks as a data source. The vserver people do something > similiar: > http://linux-vserver.org/util-vserver:Vhashify > > At the moment I have a read-only bind mount over /usr, but what I really > want is to make the individual objects in the object store in > /ostree/repo/objects be immutable, so even if a user or app navigates > out to /sysroot they still can't mutate them (or the link targets in the > visible /usr). COW links can do this already, I think. Of course, you'll have to use a filesystem that supports them. --Andy
[PATCH 0/6] File Sealing & memfd_create()
On 03/20/2014 09:38 AM, tytso at mit.edu wrote: > On Thu, Mar 20, 2014 at 04:48:30PM +0100, David Herrmann wrote: >> On Thu, Mar 20, 2014 at 4:32 PM, wrote: >>> Why not make sealing an attribute of the "struct file", and enforce it >>> at the VFS layer? That way all file system objects would have access >>> to sealing interface, and for memfd_shmem, you can't get another >>> struct file pointing at the object, the security properties would be >>> identical. >> >> Sealing as introduced here is an inode-attribute, not "struct file". >> This is intentional. For instance, a gfx-client can get a read-only FD >> via /proc/self/fd/ and pass it to the compositor so it can never >> overwrite the contents (unless the compositor has write-access to the >> inode itself, in which case it can just re-open it read-write). > > Hmm, good point. I had forgotten about the /proc/self/fd hole. > Hmm... what if we have a SEAL_PROC which forces the permissions of > /proc/self/fd to be 000? This is the second time in a week that someone has asked for a way to have a struct file (or struct inode or whatever) that can't be reopened through /proc/pid/fd. This should be quite easy to implement as a separate feature. Actually, that feature would solve a major pet peeve of mine, I think: I want something like memfd that allows me to keep the thing read-write but that whomever I pass the fd to can't change. With this feature, I could do: fd_rw = memfd_create (or O_TMPFILE or whatever) fd_ro = open(/proc/self/fd/fd_ro, O_RDONLY); fcntl(fd_ro, F_RESTRICT, F_RESTRICT_REOPEN); send fd_ro via SCM_RIGHTS. To really make this work well, I also want to SEAL_SHRINK the inode so that the receiver can verify that I'm not going to truncate the file out from under it. Bingo, fast and secure one-way IPC. --Andy
[PATCH 2/2] [RFC] reservation: add suppport for read-only access using rcu
Hey,
op 10-04-14 10:46, Thomas Hellstrom schreef:
> Hi!
>
> Ugh. This became more complicated than I thought, but I'm OK with moving
> TTM over to fence while we sort out
> how / if we're going to use this.
>
> While reviewing, it struck me that this is kind of error-prone, and hard
> to follow since we're operating on a structure that may be
> continually updated under us, needing a lot of RCU-specific macros and
> barriers.
Yeah, but with the exception of dma_buf_poll I don't think there is anything
else
outside drivers/base/reservation.c has to deal with rcu.
> Also the rcu wait appears to not complete until there are no busy fences
> left (new ones can be added while we wait) rather than
> waiting on a snapshot of busy fences.
This has been by design, because 'wait for bo idle' type of functions only care
if the bo is completely idle or not.
It would be easy to make a snapshot even without seqlocks, just copy
reservation_object_test_signaled_rcu to return a shared list if test_all is
set, or return pointer to exclusive otherwise.
> I wonder if these issues can be addressed by having a function that
> provides a snapshot of all busy fences: This can be accomplished
> either by including the exclusive fence in the fence_list structure and
> allocate a new such structure each time it is updated. The RCU reader
> could then just make a copy of the current fence_list structure pointed
> to by &obj->fence, but I'm not sure we want to reallocate *each* time we
> update the fence pointer.
No, the most common operation is updating fence pointers, which is why
the current design makes that cheap. It's also why doing rcu reads is more
expensive.
> The other approach uses a seqlock to obtain a consistent snapshot, and
> I've attached an incomplete outline, and I'm not 100% whether it's OK to
> combine RCU and seqlocks in this way...
>
> Both these approaches have the benefit of hiding the RCU snapshotting in
> a single function, that can then be used by any waiting
> or polling function.
>
I think the middle way with using seqlocks to protect the fence_excl pointer
and shared list combination,
and using RCU to protect the refcounts for fences and the availability of the
list could work for our usecase
and might remove a bunch of memory barriers. But yeah that depends on layering
rcu and seqlocks.
No idea if that is allowed. But I suppose it is.
Also, you're being overly paranoid with seqlock reading, we would only need
something like this:
rcu_read_lock()
preempt_disable()
seq = read_seqcount_begin();
read fence_excl, shared_count = ACCESS_ONCE(fence->shared_count)
copy shared to a struct.
if (read_seqcount_retry()) { unlock and retry }
preempt_enable();
use fence_get_rcu() to bump refcount on everything, if that fails unlock,
put, and retry
rcu_read_unlock()
But the shared list would still need to be RCU'd, to make sure we're not
reading freed garbage.
~Maarten
[PATCH 3/6] shm: add memfd_create() syscall
On 04/02/2014 06:38 AM, Konstantin Khlebnikov wrote: > On Wed, Mar 19, 2014 at 11:06 PM, David Herrmann > wrote: >> memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor >> that you can pass to mmap(). It explicitly allows sealing and >> avoids any connection to user-visible mount-points. Thus, it's not >> subject to quotas on mounted file-systems, but can be used like >> malloc()'ed memory, but with a file-descriptor to it. >> >> memfd_create() does not create a front-FD, but instead returns the raw >> shmem file, so calls like ftruncate() can be used. Also calls like fstat() >> will return proper information and mark the file as regular file. Sealing >> is explicitly supported on memfds. >> >> Compared to O_TMPFILE, it does not require a tmpfs mount-point and is not >> subject to quotas and alike. > > Instead of adding new syscall we can extend existing openat() a little > bit more: > > openat(AT_FDSHM, "name", O_TMPFILE | O_RDWR, 0666) Please don't. O_TMPFILE is a messy enough API, and the last thing we need to do is to extend it. If we want a fancy API for creating new inodes with no corresponding dentry, let's create one. Otherwise, let's just stick with a special-purpose API for these shm files. --Andy
REGRESSION Re: [PATCH] drm/nouveau/bios: fix bug introduced in 457e77b2
Hello Andreas, after pulling and rebooting my machine this morning, nouveau was no longer working: [6.455247] nouveau [ DEVICE][:02:00.0] BOOT0 : 0x0ac080b1 [6.455312] nouveau [ DEVICE][:02:00.0] Chipset: MCP79/MCP7A (NVAC) [6.455374] nouveau [ DEVICE][:02:00.0] Family : NV50 [6.456730] nouveau [ VBIOS][:02:00.0] checking PRAMIN for image... [6.456796] nouveau [ VBIOS][:02:00.0] ... signature not found [6.456858] nouveau [ VBIOS][:02:00.0] checking PROM for image... [6.471198] nouveau [ VBIOS][:02:00.0] ... signature not found [6.471265] nouveau [ VBIOS][:02:00.0] checking ACPI for image... [6.471328] nouveau [ VBIOS][:02:00.0] ... signature not found [6.471390] nouveau [ VBIOS][:02:00.0] checking PCIROM for image... [6.477478] nouveau [ VBIOS][:02:00.0] ... appears to be valid [6.477549] nouveau [ VBIOS][:02:00.0] using image from PCIROM [6.477789] nouveau [ VBIOS][:02:00.0] BIT signature found [6.477852] nouveau [ VBIOS][:02:00.0] version 62.79.4e.00.01 [6.486539] nouveau E[ VBIOS][:02:00.0] 0xd97c[ ]: unknown opcode 0x00 [6.486611] nouveau E[ DEVINIT][:02:00.0] init failed, -22 [6.486673] nouveau E[ DRM] failed to create 0x8080, -22 [6.488470] nouveau: probe of :02:00.0 failed with error -22 I bisected the problem: # bad: [39de65aa2c3eee901db020a4f1396998e09602a3] Merge branch 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux # good: [b003d7706abc5d75cb58de0c9de8f1fc77e57008] Merge branch 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild git bisect start 'HEAD' 'v3.14-11011-gb003d77' 'drivers/gpu/drm/' # good: [e19b9137142988bec5a76c5f8bdf12a77ea802b0] Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next git bisect good e19b9137142988bec5a76c5f8bdf12a77ea802b0 # bad: [60f2b4af1258c05e6b037af866be81abc24438f7] drm/i915: fix build warning on 32-bit (v2) git bisect bad 60f2b4af1258c05e6b037af866be81abc24438f7 # good: [f3381dfc9745bcd8b6be676ec4f68c52e71d24f1] drm/radeon/dp: use i2c_get_adapdata rather than casting git bisect good f3381dfc9745bcd8b6be676ec4f68c52e71d24f1 # good: [420b94697722512a2c0732970dc1530197a49adb] support for platform devices git bisect good 420b94697722512a2c0732970dc1530197a49adb # bad: [fc243d7f92d95d961186126efaad36197f133ab1] drm/nouveau/disp: limit dp capabilities as per dcb git bisect bad fc243d7f92d95d961186126efaad36197f133ab1 # bad: [88e98d49a1b3e0f8103cdd4fd80d576ec33133ab] drm/gf100-/gr: split ppc state into its subunits git bisect bad 88e98d49a1b3e0f8103cdd4fd80d576ec33133ab # bad: [e21bfd171a192dfba4a8907f2fcc41acac0f685f] drm/gf110/gr: fixup gpc/tpc initvals lists git bisect bad e21bfd171a192dfba4a8907f2fcc41acac0f685f # bad: [eeb0558e074215656ae11a170059a5f2ce29963f] drm/gf104/gr: rename gf104 (nvc4), it came before gf106 (nvc3) git bisect bad eeb0558e074215656ae11a170059a5f2ce29963f # bad: [6acc09b99d5d8f276a4f9bffc32f0bb0f939c7ca] drm/nvc0-/graph: fix gpccs fuc stack setup git bisect bad 6acc09b99d5d8f276a4f9bffc32f0bb0f939c7ca # bad: [457e77b26428ab4a24998eecfb99f27fa4195397] drm/nouveau/bios: add more checks to PRAMIN image fetching git bisect bad 457e77b26428ab4a24998eecfb99f27fa4195397 Than I saw your posting on LKML and tried your fix and your fix resolves my problem on top of Linus tip. Tested-by: Thomas Glanzmann Cheers, Thomas
[PATCH] drm: Split out drm_probe_helper.c from drm_crtc_helper.c
This is leftover stuff from my previous doc round which I kinda wanted
to do but didn't yet due to rebase hell.
The modeset helpers and the probing helpers a independent and e.g.
i915 uses the probing stuff but has its own modeset infrastructure. It
hence makes to split this up. While at it add a DOC: comment for the
probing libraray.
It would be rather neat to pull some of the DocBook documenting these
two helpers into in-line DOC: comments. But unfortunately kerneldoc
doesn't support markdown or something similar to make nice-looking
documentation, so the current state is better.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 5 +
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_crtc_helper.c | 370
drivers/gpu/drm/drm_probe_helper.c | 426 +
include/drm/drm_crtc_helper.h | 6 +-
5 files changed, 437 insertions(+), 372 deletions(-)
create mode 100644 drivers/gpu/drm/drm_probe_helper.c
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 702c4474919c..677a02553ec0 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2287,6 +2287,11 @@ void intel_crt_init(struct drm_device *dev)
!Edrivers/gpu/drm/drm_crtc_helper.c
+ Output Probing Helper Functions Reference
+!Pdrivers/gpu/drm/drm_probe_helper.c output probing helper overview
+!Edrivers/gpu/drm/drm_probe_helper.c
+
+
fbdev Helper Functions Reference
!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
!Edrivers/gpu/drm/drm_fb_helper.c
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 9d25dbbe6771..48e38ba22783 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -23,7 +23,7 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
drm-usb-y := drm_usb.o
-drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
+drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o
drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 1fbe8427c70e..92d5f4e93fa3 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -72,147 +72,6 @@ void drm_helper_move_panel_connectors_to_head(struct
drm_device *dev)
}
EXPORT_SYMBOL(drm_helper_move_panel_connectors_to_head);
-static bool drm_kms_helper_poll = true;
-module_param_named(poll, drm_kms_helper_poll, bool, 0600);
-
-static void drm_mode_validate_flag(struct drm_connector *connector,
- int flags)
-{
- struct drm_display_mode *mode;
-
- if (flags == (DRM_MODE_FLAG_DBLSCAN | DRM_MODE_FLAG_INTERLACE |
- DRM_MODE_FLAG_3D_MASK))
- return;
-
- list_for_each_entry(mode, &connector->modes, head) {
- if ((mode->flags & DRM_MODE_FLAG_INTERLACE) &&
- !(flags & DRM_MODE_FLAG_INTERLACE))
- mode->status = MODE_NO_INTERLACE;
- if ((mode->flags & DRM_MODE_FLAG_DBLSCAN) &&
- !(flags & DRM_MODE_FLAG_DBLSCAN))
- mode->status = MODE_NO_DBLESCAN;
- if ((mode->flags & DRM_MODE_FLAG_3D_MASK) &&
- !(flags & DRM_MODE_FLAG_3D_MASK))
- mode->status = MODE_NO_STEREO;
- }
-
- return;
-}
-
-/**
- * drm_helper_probe_single_connector_modes - get complete set of display modes
- * @connector: connector to probe
- * @maxX: max width for modes
- * @maxY: max height for modes
- *
- * Based on the helper callbacks implemented by @connector try to detect all
- * valid modes. Modes will first be added to the connector's probed_modes
list,
- * then culled (based on validity and the @maxX, @maxY parameters) and put into
- * the normal modes list.
- *
- * Intended to be use as a generic implementation of the ->fill_modes()
- * @connector vfunc for drivers that use the crtc helpers for output mode
- * filtering and detection.
- *
- * Returns:
- * The number of modes found on @connector.
- */
-int drm_helper_probe_single_connector_modes(struct drm_connector *connector,
- uint32_t maxX, uint32_t maxY)
-{
- struct drm_device *dev = connector->dev;
- struct drm_display_mode *mode;
- struct drm_connector_helper_funcs *connector_funcs =
- connector->helper_private;
- int count = 0;
- int mode_flags = 0;
- bool verbose_prune = true;
-
- WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
-
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
- drm_get_connector_name(connector));
- /* set all modes to the unverified state */
-
[PATCH 2/2] [RFC] reservation: add suppport for read-only access using rcu
Hi! Ugh. This became more complicated than I thought, but I'm OK with moving TTM over to fence while we sort out how / if we're going to use this. While reviewing, it struck me that this is kind of error-prone, and hard to follow since we're operating on a structure that may be continually updated under us, needing a lot of RCU-specific macros and barriers. Also the rcu wait appears to not complete until there are no busy fences left (new ones can be added while we wait) rather than waiting on a snapshot of busy fences. I wonder if these issues can be addressed by having a function that provides a snapshot of all busy fences: This can be accomplished either by including the exclusive fence in the fence_list structure and allocate a new such structure each time it is updated. The RCU reader could then just make a copy of the current fence_list structure pointed to by &obj->fence, but I'm not sure we want to reallocate *each* time we update the fence pointer. The other approach uses a seqlock to obtain a consistent snapshot, and I've attached an incomplete outline, and I'm not 100% whether it's OK to combine RCU and seqlocks in this way... Both these approaches have the benefit of hiding the RCU snapshotting in a single function, that can then be used by any waiting or polling function. /Thomas On 04/09/2014 04:49 PM, Maarten Lankhorst wrote: > This adds 3 more functions to deal with rcu. > > reservation_object_wait_timeout_rcu() will wait on all fences of the > reservation_object, without obtaining the ww_mutex. > > reservation_object_test_signaled_rcu() will test if all fences of the > reservation_object are signaled without using the ww_mutex. > > reservation_object_get_excl() is added because touching the fence_excl > member directly will trigger a sparse warning. > > Signed-off-by: Maarten Lankhorst > --- > drivers/base/dma-buf.c | 46 +++-- > drivers/base/reservation.c | 147 > +-- > include/linux/fence.h | 22 ++ > include/linux/reservation.h | 40 > 4 files changed, 224 insertions(+), 31 deletions(-) > -- next part -- A non-text attachment was scrubbed... Name: rcu_fence.diff Type: text/x-patch Size: 4139 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/2d0922a9/attachment-0001.bin>
[Bug 68805] 48 fps and 50 fps video decoding is stutter on UVD
https://bugs.freedesktop.org/show_bug.cgi?id=68805 russianneuromancer at ya.ru changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from russianneuromancer at ya.ru --- Certainly fixed now. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/7568c976/attachment.html>
[Bug 71891] 3.13 fails to boot with the radeon module
https://bugzilla.kernel.org/show_bug.cgi?id=71891 --- Comment #9 from sdh --- Hi, Any update on this? Is there any other information required to fix the bug? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 2/2] dma-buf: update exp_name when using dma_buf_export()
On Thu, Apr 10, 2014 at 01:30:06AM +0200, Javier Martinez Canillas wrote:
> commit c0b00a5 ("dma-buf: update debugfs output") modified the
> default exporter name to be the KBUILD_MODNAME pre-processor
> macro instead of __FILE__ but the documentation was not updated.
>
> Also the "Supporting existing mmap interfaces in exporters" section
> title seems wrong since talks about the interface used by importers.
>
> Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
> ---
> Documentation/dma-buf-sharing.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/dma-buf-sharing.txt
> b/Documentation/dma-buf-sharing.txt
> index 505e711..7d61cef 100644
> --- a/Documentation/dma-buf-sharing.txt
> +++ b/Documentation/dma-buf-sharing.txt
> @@ -66,7 +66,7 @@ The dma_buf buffer sharing API usage contains the following
> steps:
>
> Exporting modules which do not wish to provide any specific name may use
> the
> helper define 'dma_buf_export()', with the same arguments as above, but
> - without the last argument; a __FILE__ pre-processor directive will be
> + without the last argument; a KBUILD_MODNAME pre-processor directive will
> be
> inserted in place of 'exp_name' instead.
>
> 2. Userspace gets a handle to pass around to potential buffer-users
> @@ -352,7 +352,7 @@ Being able to mmap an export dma-buf buffer object has 2
> main use-cases:
>
> No special interfaces, userspace simply calls mmap on the dma-buf fd.
>
> -2. Supporting existing mmap interfaces in exporters
> +2. Supporting existing mmap interfaces in importers
>
> Similar to the motivation for kernel cpu access it is again important that
> the userspace code of a given importing subsystem can use the same
> interfaces
> --
> 1.9.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2] drm: make mode_valid callback optional
Hi Dave,
Could you pick up this patch?
It touches drm core and different drm drivers so I guess
your repo is the best place for it.
Regards
Andrzej
On 04/03/2014 11:21 PM, Daniel Vetter wrote:
> On Wed, Apr 02, 2014 at 12:29:46PM +0200, Andrzej Hajda wrote:
>> Many drm connectors do not need mode validation.
>> The patch makes this callback optional and removes dumb implementations.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> v2:
>> - added comment and updated DocBook
> Reviewed-by: Daniel Vetter
>
>> ---
>> Documentation/DocBook/drm.tmpl | 6 +++---
>> drivers/gpu/drm/ast/ast_mode.c | 7 ---
>> drivers/gpu/drm/bridge/ptn3460.c | 7 ---
>> drivers/gpu/drm/cirrus/cirrus_mode.c | 8
>> drivers/gpu/drm/drm_crtc_helper.c | 2 +-
>> drivers/gpu/drm/exynos/exynos_dp_core.c| 7 ---
>> drivers/gpu/drm/exynos/exynos_drm_dpi.c| 7 ---
>> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 7 ---
>> drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 7 ---
>> drivers/gpu/drm/rcar-du/rcar_du_vgacon.c | 7 ---
>> drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 7 ---
>> drivers/staging/imx-drm/imx-hdmi.c | 8
>> drivers/staging/imx-drm/imx-ldb.c | 7 ---
>> drivers/staging/imx-drm/parallel-display.c | 7 ---
>> include/drm/drm_crtc_helper.h | 2 +-
>> 15 files changed, 5 insertions(+), 91 deletions(-)
>>
>> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
>> index 702c4474..92b4fa3 100644
>> --- a/Documentation/DocBook/drm.tmpl
>> +++ b/Documentation/DocBook/drm.tmpl
>> @@ -1903,8 +1903,8 @@ void intel_crt_init(struct drm_device *dev)
>>
>> The function filters out modes larger than
>> max_width and
>> max_height
>> -if specified. It then calls the connector
>> -mode_valid helper operation for each
>> mode in
>> +if specified. It then calls the optional connector
>> +mode_valid helper operation for each
>> mode in
>> the probed list to check whether the mode is valid for the
>> connector.
>>
>>
>> @@ -2265,7 +2265,7 @@ void intel_crt_init(struct drm_device *dev)
>>
>> Verify whether a mode is valid for the connector. Return
>> MODE_OK for
>> supported modes and one of the enum drm_mode_status values
>> (MODE_*)
>> -for unsupported modes. This operation is mandatory.
>> +for unsupported modes. This operation is optional.
>>
>>
>> As the mode rejection reason is currently not used beside for
>> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
>> index a4afdc8..e599d64 100644
>> --- a/drivers/gpu/drm/ast/ast_mode.c
>> +++ b/drivers/gpu/drm/ast/ast_mode.c
>> @@ -743,12 +743,6 @@ static int ast_get_modes(struct drm_connector
>> *connector)
>> return 0;
>> }
>>
>> -static int ast_mode_valid(struct drm_connector *connector,
>> - struct drm_display_mode *mode)
>> -{
>> -return MODE_OK;
>> -}
>> -
>> static void ast_connector_destroy(struct drm_connector *connector)
>> {
>> struct ast_connector *ast_connector = to_ast_connector(connector);
>> @@ -765,7 +759,6 @@ ast_connector_detect(struct drm_connector *connector,
>> bool force)
>> }
>>
>> static const struct drm_connector_helper_funcs ast_connector_helper_funcs =
>> {
>> -.mode_valid = ast_mode_valid,
>> .get_modes = ast_get_modes,
>> .best_encoder = ast_best_single_encoder,
>> };
>> diff --git a/drivers/gpu/drm/bridge/ptn3460.c
>> b/drivers/gpu/drm/bridge/ptn3460.c
>> index a9e5c1a..3ff2813 100644
>> --- a/drivers/gpu/drm/bridge/ptn3460.c
>> +++ b/drivers/gpu/drm/bridge/ptn3460.c
>> @@ -225,12 +225,6 @@ out:
>> return num_modes;
>> }
>>
>> -static int ptn3460_mode_valid(struct drm_connector *connector,
>> -struct drm_display_mode *mode)
>> -{
>> -return MODE_OK;
>> -}
>> -
>> struct drm_encoder *ptn3460_best_encoder(struct drm_connector *connector)
>> {
>> struct ptn3460_bridge *ptn_bridge;
>> @@ -242,7 +236,6 @@ struct drm_encoder *ptn3460_best_encoder(struct
>> drm_connector *connector)
>>
>> struct drm_connector_helper_funcs ptn3460_connector_helper_funcs = {
>> .get_modes = ptn3460_get_modes,
>> -.mode_valid = ptn3460_mode_valid,
>> .best_encoder = ptn3460_best_encoder,
>> };
>>
>> diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c
>> b/drivers/gpu/drm/cirrus/cirrus_mode.c
>> index 2d64aea..057c7d1 100644
>> --- a/drivers/gpu/drm/cirrus/cirrus_mode.c
>> +++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
>> @@ -502,13 +502,6 @@ static int cirrus_vga_get_modes(struct drm_connector
>> *connector)
>> return count;
>> }
>>
>> -static int cirrus_vga_mode_valid(struct drm_connector *connector,
>> - struct drm_display_mode *
[patch] drm/panel: s6e8aa0: silence array overflow warning
Hi Dan,
Thanks for the patch.
On 04/09/2014 05:21 PM, Dan Carpenter wrote:
> Smatch complains that we are reading beyond the end of the array here:
>
> drivers/gpu/drm/panel/panel-s6e8aa0.c:852 s6e8aa0_read_mtp_id()
> warn: buffer overflow 's6e8aa0_variants' 4 <= 4
>
> We set the error code, so it's not harmful but it looks like a return
> was intended here so lets add that and silence the warning.
>
> Signed-off-by: Dan Carpenter
Acked-by: Andrzej Hajda
> ---
> Compile tested only.
>
> diff --git a/drivers/gpu/drm/panel/panel-s6e8aa0.c
> b/drivers/gpu/drm/panel/panel-s6e8aa0.c
> index 35941d2..06e57a2 100644
> --- a/drivers/gpu/drm/panel/panel-s6e8aa0.c
> +++ b/drivers/gpu/drm/panel/panel-s6e8aa0.c
> @@ -847,6 +847,7 @@ static void s6e8aa0_read_mtp_id(struct s6e8aa0 *ctx)
> if (i >= ARRAY_SIZE(s6e8aa0_variants)) {
> dev_err(ctx->dev, "unsupported display version %d\n", id[1]);
> ctx->error = -EINVAL;
> + return;
> }
>
> ctx->variant = &s6e8aa0_variants[i];
>
[PATCH] fix memory leak
Please re-send this patch with a correct commit message (subject). Add at least "drm: " prefix to it. 2014-04-09 23:11 GMT+02:00 Micah Richert : > Signed-off-by: Micah Richert You have some weird indent before "Signed-off-by".
[Bug 74868] r600g: Diablo III Crashes After a few minutes
https://bugs.freedesktop.org/show_bug.cgi?id=74868 Michel D?nzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #21 from Michel D?nzer --- Module: Mesa Branch: master Commit: ee2bcf38a4c8930d8f9cecfac580030a45c41dae URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=ee2bcf38a4c8930d8f9cecfac580030a45c41dae Author: Michel D?nzer Date: Wed Apr 9 15:38:21 2014 +0900 r600g: Don't leak bytecode on shader compile failure -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/1e97dd6b/attachment.html>
