[Bug 100443] DMESG: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table!

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100443

--- Comment #7 from Gjorgji Jankovski  ---
I can confirm this as well, hardware:


Ryzen 7 1700
MSI B350 TOMAHAWK
Xfx RS RX 480 4GB

Fedora 26
Kernel: 4.11.0-1.fc26.x86_64

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100437] IO_PAGE_FAULT is spammed in dmesg

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100437

Gjorgji Jankovski  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #4 from Gjorgji Jankovski  ---
This is definitely not fixed yet, at least for me.

Ryzen 7 1700
MSI B350 TOMAHAWK
RX 480

Fedora 26
Kernel: 4.11.0-1.fc26.x86_64

My error message is this:

[2.339023] AMD-Vi: Event logged [
[2.339024] IO_PAGE_FAULT device=23:00.0 domain=0x0003
address=0x00f4001f0400 flags=0x0010]


Reappears a lot in dmesg.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99488] [r600g]ImageMagick issues in Gaussian Blur kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99488

--- Comment #16 from nixscrip...@gmail.com ---
Good news! I tried a new version:

LLVM r302002
Mesa commit 3bf3f9866c

And the unit tests on the ImageMagick master branch don't hang anymore!

A little more testing today, and I may be able to close this one.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm pull for v4.12

[Linus Torvalds]

On Tue, May 2, 2017 at 8:44 PM, Dave Airlie  wrote:
>
> i915:
> vblank evasion improvements

These may be "improvements", but they end up being very noisy.

I geta fair amount of messages like

  [drm] Atomic update on pipe (A) took 161 us, max time under evasion is 100 us

on my desktop (i7-6700K) and I've seen it once on my laptop (i7-6560U) too.

The commit message says "This will make it easier to find cases where
we potentially miss vblanks." but I'm not sure how that is the case.
There's nothing else helpful in the log, and it doesn't seem to be
associated with anything in particular (I'm just at the desktop,
running a few xterms and google-chrome).

 Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100941] Improve time to suspend on Radeon HD 6310

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100941

--- Comment #3 from Paul Menzel  ---
(In reply to Christian König from comment #2)
> That is expected. During suspend we need to backup VRAM and that can be
> multiple gigs of memory.

The board has the Fusion APU E-350, which is not external card, and which uses
the “normal system memory”, right? So I wonder what needs to be backed up?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100941] Improve time to suspend on Radeon HD 6310

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100941

Christian König  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #2 from Christian König  ---
That is expected. During suspend we need to backup VRAM and that can be
multiple gigs of memory.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100941] Improve time to suspend on Radeon HD 6310

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100941

Paul Menzel  changed:

   What|Removed |Added

Summary|Improve time to suspend on  |Improve time to suspend on
   ||Radeon HD 6310

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100577] DC + TearFree display lock

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100577

--- Comment #4 from Nikola Forró  ---
Bisected to this commit:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-4.9&id=afbeb2d0961b2139bcf6553a710e6a8ae5d09d34

Which makes me think I'm experiencing a different issue, because this bug was
reported long before that commit emerged.

My reproducer is to fill the screen with two xterm windows next to each other
and generate random lines of text in both of them, using command like this for
example:

tr -dc a-z1-4 50' | tr
3-4 ' ' | sed 's/^ *//' | cat -s | sed 's/ / /g' | fmt

The screen lock will occur in a couple of minutes.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: GPU-DRM-STI: Fine-tuning for some function implementations

[SF Markus Elfring]

>> 1. I suggest to combine a few functions into fewer ones.
>>* Do you spot any programming mistakes in these concrete cases?
> 
> Not in the patches I skimmed.

Thanks for such feedback.


> However, your history of breaking code tells me that there have been mistakes
> missed in the past.

I admit that I had my own share of software development hiccups. I would also
like to reduce them. But a probability remains that I will stumble on
various glitches as usual.


> As such, I'm not willing to take untested code from you that does not change
> functionality at the risk of breaking something that is currently working.

I imagine that the shown software refactoring will improve the affected
sequence outputs in useful ways, won't it?


> This is non-negotiable.

It seems that we have got different views around the ways to get to acceptable
final system test results.


> As I said before, if you test it, I'll consider it.

I got a few doubts for this information. If you find my software development
reputation so questionable, I assume that you would not trust any tests
that I would try out on my own.


> If you are unwilling to test your changes, I'm unwilling to apply them.

I guess that the desired willingness will depend on a test environment
which will be trusted by all involved parties. Other incentives might
also matter.


> I'm not interested in double checking all of your work, and fixing your bugs
> for no functional benefit.

Do you care for improvements in the implementation of logging functions?


> I find less value in these patches if they're from someone seemingly
> trying to rack up patch count.

I am picking special source code search patterns up.
The evolving development tools can point then hundreds of source files
out which contain similar update candidates.
I found also a few spelling weaknesses while I was looking around
in affected source code. These tools can also increase the awareness
for such change possibilities, can't they?

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: GPU-DRM-STI: Fine-tuning for some function implementations

[Sean Paul]

On Sat, May 06, 2017 at 03:54:51PM +0200, SF Markus Elfring wrote:
> > Generally speaking, I don't care about checkpatch/cocci changes that aren't 
> > tested.
> 
> I find this view interesting only to some degree.

We're bordering on becoming unproductive here, but I'll try once more.

> 
> 1. I suggest to combine a few functions into fewer ones.
>* Do you spot any programming mistakes in these concrete cases?

Not in the patches I skimmed. However, your history of breaking code tells me 
that
there have been mistakes missed in the past. As such, I'm not willing to take
untested code from you that does not change functionality at the risk of
breaking something that is currently working. This is non-negotiable.

>* Can such code reduction result into desired effects?
> 
> 2. I propose to use the function “seq_putc” at more source code places.
>* Do you really find any previous system test approaches insufficient 
> around
>  such a Linux feature?
>* Does the programming interface “seq_puts” provide any properties
>  that you prefer over the other one for the sequence output of single 
> characters?
>  http://elixir.free-electrons.com/linux/v4.11/source/fs/seq_file.c#L664
> 

As I said before, if you test it, I'll consider it. If you are unwilling to test
your changes, I'm unwilling to apply them. I'm not interested in double checking
all of your work, and fixing your bugs for no functional benefit.

> 
> > With your changes, we don't have this upside.
> 
> How do you think about to pick spelling corrections up for two comment lines?

Well, it wouldn't break anything, so that's positive. As I said in my last
email, these types of changes are perfect for new contributors to get started
with kernel development. I find less value in these patches if they're from
someone seemingly trying to rack up patch count.

Sean


> 
> Regards,
> Markus

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Keith Packard]

Mario Kleiner  writes:

> Just please make sure that one (user configurable/opt-in if necessary) 
> policy from the beginning is to allow leasing out any output to 
> applications, not just HMDs.

That's entirely a given -- the leasing API is under the control of the
application which can lease any set of resources it likes.

The only question here is how to avoid flashing the desktop contents
onto the HMD when you plug it in, and that means not listing some
displays as 'connected' in the default RandR requests. There will be a
separate request which lists them all.

-- 
-keith


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100239] Incorrect rendering in CS:GO

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100239

--- Comment #8 from Samuel Pitoiset  ---
Thanks for the trace.

The issue can be reproduced with mesa/llvm from today on RX480. I'm
investigating.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: GPU-DRM-STI: Fine-tuning for some function implementations

[SF Markus Elfring]

> Generally speaking, I don't care about checkpatch/cocci changes that aren't 
> tested.

I find this view interesting only to some degree.

1. I suggest to combine a few functions into fewer ones.
   * Do you spot any programming mistakes in these concrete cases?
   * Can such code reduction result into desired effects?

2. I propose to use the function “seq_putc” at more source code places.
   * Do you really find any previous system test approaches insufficient around
 such a Linux feature?
   * Does the programming interface “seq_puts” provide any properties
 that you prefer over the other one for the sequence output of single 
characters?
 http://elixir.free-electrons.com/linux/v4.11/source/fs/seq_file.c#L664


> With your changes, we don't have this upside.

How do you think about to pick spelling corrections up for two comment lines?

Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: GPU-DRM-STI: Fine-tuning for some function implementations

[Sean Paul]

On Fri, May 05, 2017 at 05:04:40PM +0200, SF Markus Elfring wrote:
> > It seems like you're back to submitting cocci patches again :)
> 
> My contribution activities are varying also for Linux software over time.   
> ;-)
> 
> The corresponding source code search patterns get different popularity.
> 
> 
> > I don't want to waste your time by ignoring your patches, so please ensure 
> > that
> > your patches provide value and that they are tested.
> 
> Which benchmarks and system tests would you find representative for this 
> patch series?
> 

Given your history of submitting changes which break working code, I want
assurance that you've actually run the code and verified that it does what you
want it to do.

> How do you think generally about the proposed change possibilities?

Generally speaking, I don't care about checkpatch/cocci changes that aren't
tested. They clutter the log and don't provide enough value to justify the risk
of breaking stuff. 

IMO, the only time this would be acceptable is if a new contributor wanted to
wet their feet with a couple cleanup patches before diving in to actual
functional changes. In that case, I wouldn't mind dealing with breakage since
we'll benefit from their contributions in the future. With your changes, we
don't have this upside.

Sean


> 
> Regards,
> Markus

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 8/8] omapdrm: hdmi4: hook up the HDMI CEC support

[Hans Verkuil]

Hi Tomi,

I did some more testing, and I discovered a bug in this code, but I am not
sure how to solve it.

On 04/14/2017 12:25 PM, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Hook up the HDMI CEC support in the hdmi4 driver.
> 
> It add the CEC irq handler, the CEC (un)init calls and tells the CEC
> implementation when the physical address changes.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/gpu/drm/omapdrm/dss/Kconfig  |  9 +
>  drivers/gpu/drm/omapdrm/dss/Makefile |  1 +
>  drivers/gpu/drm/omapdrm/dss/hdmi4.c  | 23 ++-
>  3 files changed, 32 insertions(+), 1 deletion(-)
> 



> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c 
> b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> index e371b47ff6ff..ebe5b27cee6f 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c



> @@ -392,6 +401,8 @@ static void hdmi_display_disable(struct omap_dss_device 
> *dssdev)
>  
>   DSSDBG("Enter hdmi_display_disable\n");
>  
> + hdmi4_cec_set_phys_addr(&hdmi.core, CEC_PHYS_ADDR_INVALID);
> +
>   mutex_lock(&hdmi.lock);
>  
>   spin_lock_irqsave(&hdmi.audio_playing_lock, flags);

My assumption was that hdmi_display_disable() was called when the hotplug would 
go
away. But I discovered that that isn't the case, or at least not when X is 
running.
It seems that the actual HPD check is done in hdmic_detect() in
omapdrm/displays/connector-hdmi.c.

But there I have no access to hdmi.core (needed for the 
hdmi4_cec_set_phys_addr() call).

Any idea how to solve this? I am not all that familiar with drm, let alone 
omapdrm,
so if you can point me in the right direction, then that would be very helpful.

Regards,

Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Mario Kleiner]

On 05/05/2017 04:25 PM, Keith Packard wrote:

Pekka Paalanen  writes:


I disagree on the details, more below.



Such a RandR request is something I would not like to have to replicate
on Wayland. The display server contains the policy, it should not just
expose everything up for grabs. This is a fundamental difference
between X11 and Wayland architectures, and I think the output
information database should support both ways.


Sounds like a good idea; if you want to work on how this should appear
in Wayland, that would be great as it would provide two implementations,
rather than just one.


I disagree. Wayland will likely have a special protocol extension
exclusively for advertising HMDs, so the display server will need to
know which ones are HMDs and which one are not, regardless whether the
desktop is extended there or not. This extension could also offer the
DRM leasing capabilities.


What I was thinking that a display which the window system cannot drive
natively should probably just be ignored entirely. An HMD which can
natively handle a desktop (such as the PSVR system) might well be
advertised as 'desktop capable', even though it is an HMD.

However, I also think you're right -- while the window system can't deal
with it *today*, that doesn't mean the window system won't be able to do
that in the future.

Hrm. I think the important distinction here is that the user installed
an application which is designed to talk directly to this display. From
that, we should probably infer that the user would like to use that
application with the display.


Having the window manager know what is a HMD and which client is active
on it will let it make better management decisions and even allow
switching between VR apps, or temporarily switching from VR app to the
desktop when supported, and back.


The window system will know when outputs are leased to another client,
so it can tell when to bring them back to the desktop. In the PSVR
instance, you'd list the device as 'desktop', but still allow
leasing. When no lease was active, the desktop could extend into the
PSVR environment. When the custom application started, it would request
a lease at which time the desktop would move off of the PSVR.


Thanks again; I'm sensing that a simple 'ignore this monitor for the
desktop' might suffice for now, but that we'll end up wanting something
more complicated in the future. I think the key is to try and avoid
making that harder by what we do now, but I don't think we should be
trying to implement a larger solution too soon.


Yes, that I agree with.


I guess that's the question -- is a simple command to ignore a monitor
for purposes of the desktop sufficient for now? Or do we need to worry
about a possible future in which the window system implements native HMD
support?


Ultimately I would envision an output device database describing
what kind of a device it is (a normal monitor, a video projector, a
HMD, a TV, ...) and then the software that implements the desktop or UI
policy will decide how that will be used. Some policy examples:

- A projector: do not extend desktop UI, but have the output normally
  available, so one can put regular windows there (presentation
  software). Turned on by default.

- A HMD: Do not extend desktop, do not expose to normal apps, keep it
  off until special request.

- A HMD with cinematic mode support: Extend desktop, turn on by
  default, allow special HMD requests.

- A TV: Try to disable overscan or try to compensate for it by
default.


Those all sound useful. I wonder how much we might be able to guess from
EDID info and whether we want to programmatically do some of this
(especially the TV thing; that's really annoying :-). In any case, a
problem for the future.


I would suggest to have a "output device type" attribute in the
database, and support only one value for now: "HMD". Then all display
servers can encode the policy to hide all HMDs by default.
Implementationwise it is no different from your idea, but separating
device description from usage policy would be a good thing in my
opinion. You can still document suggested policies in the spec if you
wish, only the wording will be more of a recommendation than a
requirement.


The only issue here is that now we're encoding policy in code, which is
hard to change for the average user, rather than in a configuration
file, which is easy to change. However, as we've defined it, these files
are installed by the system and it would be nice if they weren't
expected to be overridden by the user, so encoding policy there is
almost worse than in the code.

Hrm. How about we adopt your design and encode the device type in the
file, provide a fixed policy in the window system for now and consider
the possibility of changing the window system in the future to support
more advanced policy mechanisms. I don't think that shuts any doors
permanently.



Just please make sure that one (user configurable/opt-in if necessary) 
policy from t

I2C failures with recent laptops and docking stations

[Sanford Rockowitz]

The following bug was just posted: i915 failures with recent chips and
docking stations 
and follows up this thread
in the
intel-gfx mailing list.  Per suggestion of Jani Nikula of Intel, I'm
also posting a brief summary to this list.

I am the developer of ddcutil , a Linux utility
that manages monitor settings using DDC/CI. I am seeing a pattern of
user error reports in which I2C communication is not working when a
system with a recent Intel chip, using the i915 driver, is plugged into
a docking station.

ddcutil looks for displays by examining all non-SMBus /dev/i2c devices
on the system. If checks for the presence of slave address x50 and x37.
If they exist it tries to read the EDID on x50 and a Virtual Control
Panel feature value on x37. Examining one of the user logs, I see that
two  /dev/i2c-n devices have udev sysattr name DPMST. When ddcutil
probes those /dev/i2c devices, slave addresses x50 and x37 appear
active, but reading the EDID fails.

Per Jani Nikola, this is likely a bug in the core drm DP MST code.

Sanford Rockowitz



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel