Hi Takashi,
It seems the patches for DP MST in gfx is not merged into Linus branch.
Do we have plan to merge gfx branch manually and review the patches for audio?
Or we will wait the DP MST patches for i915 merged into Linus branch?
Regards,
Libin
>-Original Message-
>From: Takashi Iw
On Sunday 08 January 2017 01:14 AM, Chris Wilson wrote:
On Sat, Jan 07, 2017 at 11:42:04PM +0530, vathsala nagaraju wrote:
As per bpsec, CHICKEN_TRANS_EDP bit 12 ,15
must be programmed.
Enable bit 12 for programmable header packet.
Enable bit 15 for Y cordinate support.
v2: (Rodrigo)
- move CHI
On 2017.01.06 19:58:16 +, Chris Wilson wrote:
> set_gma_to_bb_cmd() is completely bogus - it is (incorrectly) applying
> the rules to read a GTT offset from a command as opposed to writing the
> GTT offset. And to cap it all set_gma_to_bb_cmd() is called within a list
> iterator of the most str
This has so far only happened once, so I don't know how repeatable it
is, but here goes..
My nice stable XPS13 just oopsed on shutdown. It is possibly related
to the X server SIGSEGV'ing too, although honestly, I am not sure
which caused which. Maybe the kernel oops caused the X problem. They
defi
Link to FDO regression
list:https://bugs.freedesktop.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&component=DRM%2FIntel&f0=OP&f1=OP&f2=short_desc&f3=keywords&f4=CP&f5=CP&j1=OR&known_name=i915%20regressions&list_id=600614&o2=anywordssubstr&o3=anywordss
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 not i915 drm
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 trying to acc
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?
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 to the punit wh
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
> -
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
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
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
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
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
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:
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
-Remove-WaDisableLSQCROPERFforOCL-KBL-workaround/20170108-193533
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x012-201702 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
23 matches
Mail list logo
