attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170108/6dfb6e26/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=191281
--- Comment #3 from Johannes Hirte ---
With amdgpu.dpm=0 this doesn't occur. Also tested with amdgpu.powerplay=0, but
it didn't help. I don't know about the meaning of the values applied in
vce_v3_0_set_vce_sw_clock_gating(), but just inverting t
mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170108/b28ac721/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170108/809780a7/attachment.html>
On Sun, 2017-01-08 at 16:30 +0100, Hans de Goede wrote:
> Hi,
>
> On 08-01-17 16:16, Andy Shevchenko wrote:
> > On Sun, 2017-01-08 at 14:44 +0100, Hans de Goede wrote:
> > > One some systems the punit accesses the pmic to change various
> > > voltages
> > > through the same bus as other kernel dri
On Sun, 2017-01-08 at 14:44 +0100, Hans de Goede wrote:
> Make sure the punit i2c bus is not in use when we send a request to
> the punit by calling iosf_mbi_punit_lock() / iosf_mbi_punit_unlock()
> around punit write accesses.
>
But should not i915 drm eventually share the same iosf_mbi driver?
On Sun, 2017-01-08 at 14:44 +0100, Hans de Goede wrote:
> Take the punit lock to stop others from accessing the punit while the
> pmic i2c bus is in use. This is necessary because accessing the punit
> from the kernel may result in the punit trying to access the pmic i2c
> bus, which results in a h
On Sun, 2017-01-08 at 14:44 +0100, Hans de Goede wrote:
> Call the iosf_mbi pmic_bus_access_notifier_chain on bus acquire /
> release.
>
FWIW:
Reviewed-by: Andy Shevchenko
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
> Signed-off-by: Hans de Goede
> Tested-by: tagorereddy
> -
Hi All,
Booted 4.10-rc2 today, and the display shows random spots of flickering
short horizontal bars 1px tall, maybe 8 or 16px wide. Machine is the
venerable X61s thinkpad, 1.8ghz, XGA. Problem was not present on 4.9.0,
same kernel config.
I'll see if I can get around to bisecting, consider th
On Sun, 2017-01-08 at 14:44 +0100, Hans de Goede wrote:
> Some drivers may need to acquire punit managed resources from
> interrupt
> context, where they cannot call iosf_mbi_punit_lock().
>
> This commit adds a notifier chain which allows a driver to get
> notified
> (in a process context) before
On Sun, 2017-01-08 at 14:44 +0100, Hans de Goede wrote:
> One some systems the punit accesses the pmic to change various
> voltages
> through the same bus as other kernel drivers use for e.g. battery
> monitoring.
>
> If a driver sends requests to the punit which require the punit to
> access
> th
Hi,
On 08-01-17 16:34, Andy Shevchenko wrote:
> On Sun, 2017-01-08 at 14:44 +0100, Hans de Goede wrote:
>> Make sure the punit i2c bus is not in use when we send a request to
>> the punit by calling iosf_mbi_punit_lock() / iosf_mbi_punit_unlock()
>> around punit write accesses.
>>
>
> But should n
Hi,
On 08-01-17 16:27, Andy Shevchenko wrote:
> On Sun, 2017-01-08 at 14:44 +0100, Hans de Goede wrote:
>> Take the punit lock to stop others from accessing the punit while the
>> pmic i2c bus is in use. This is necessary because accessing the punit
>> from the kernel may result in the punit tryin
Hi,
On 08-01-17 16:16, Andy Shevchenko wrote:
> On Sun, 2017-01-08 at 14:44 +0100, Hans de Goede wrote:
>> One some systems the punit accesses the pmic to change various
>> voltages
>> through the same bus as other kernel drivers use for e.g. battery
>> monitoring.
>>
>> If a driver sends requests
Make sure the punit i2c bus is not in use when we send a request to
the punit by calling iosf_mbi_punit_lock() / iosf_mbi_punit_unlock()
around punit write accesses.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
Signed-off-by: Hans de Goede
Tested-by: tagorereddy
---
drivers/gpu/d
Listen for pmic bus access notifications and get FORCEWAKE_ALL while
the bus is accessed to avoid needing to do any forcewakes, which need
pmic bus access, while the pmic bus is busy:
This fixes errors like these showing up in dmesg, usually followed
by a gfx or system freeze:
[drm:fw_domains_get
Rename intel_uncore_early_sanitize to intel_uncore_resume, dropping the
(always true) restore_forcewake argument and add a new intel_uncore_resume
function to replace the intel_uncore_forcewake_reset(dev_priv, false)
calls done from the suspend / runtime_suspend functions and make
intel_uncore_forc
Call the iosf_mbi pmic_bus_access_notifier_chain on bus acquire / release.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
Signed-off-by: Hans de Goede
Tested-by: tagorereddy
---
drivers/i2c/busses/i2c-designware-baytrail.c | 4
1 file changed, 4 insertions(+)
diff --git a/dri
Take the punit lock to stop others from accessing the punit while the
pmic i2c bus is in use. This is necessary because accessing the punit
from the kernel may result in the punit trying to access the pmic i2c
bus, which results in a hang when it happens while we own the pmic i2c
bus semaphore.
Bu
Some drivers may need to acquire punit managed resources from interrupt
context, where they cannot call iosf_mbi_punit_lock().
This commit adds a notifier chain which allows a driver to get notified
(in a process context) before other drivers start accessing the pmic bus,
so that the driver can ac
One some systems the punit accesses the pmic to change various voltages
through the same bus as other kernel drivers use for e.g. battery
monitoring.
If a driver sends requests to the punit which require the punit to access
the pmic bus while another driver is also accessing the pmic bus various
b
Hi All,
Here is a non RFC version of my previous RFC series for coordinating
cht i2c-pmic and i915-punit accesses. New in this non RFC version is
that forcewake accesses are coodinated now too.
The problem:
This series fixes an issue where the following messages are shown in dmesg:
https://bugzilla.kernel.org/show_bug.cgi?id=107381
--- Comment #17 from Jean-Pierre van Riel ---
Until VCE gets fixed for Mars/, there might be a way to disable VCE (I need to
look into it more)
https://github.com/torvalds/linux/commit/fabb5935871db1f31fcd2684fd154e24de04d917#diff-9bc1b4aaf15dd5
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170108/ca4ab04c/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170108/894ea0a4/attachment.html>
|hangs on latest r600|hang on latest r600
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170108/605a08f7/attachment.html>
r600g driver
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170108/eea39e71/attachment.html>
hment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170108/dd799d59/attachment-0001.html>
...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170108/2f278458/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170108/f2374a5a/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170108/da27faac/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170108/8a21a6b0/attachment.html>
org/archives/dri-devel/attachments/20170108/fb789490/attachment.html>
33 matches
Mail list logo
