Yesterday CI got lagged for a bit while I was tuning timeouts in host
connectivity. We're
now using nmap (instead of ping) to get better results over firewalls and long
distances. Change sparked from connecting French DUT to our Jenkins.
The results for this series were run, but not posted for
== Series Details ==
Series: series starting with [CI-ping,1/9] drm/i915: Include
engine->last_submitted_seqno in GPU error state
URL : https://patchwork.freedesktop.org/series/5400/
State : failure
== Summary ==
Series 5400v1 Series without cover letter
http://patchwork.freedesktop.org/api/1
On to, 2016-04-07 at 18:57 +0100, Dave Gordon wrote:
> Where we have a suitable dev_priv pointer, we can use that rather than
> 'dev' for accessing INTEL_INFO(). This removes one level of memory
> reference, decreasing code size a little and possibly making everything
> a little faster. We could a
On Wed, Mar 30, 2016 at 10:00:05AM +0200, Maarten Lankhorst wrote:
> Check functions are used by atomic to see if the new state will
> be allowed. There's also a hw state checker which checks afterwards
> that the committed state is correct. Rename it to hw state verifier
> to reduce some confusion
On Wed, Mar 23, 2016 at 02:58:07PM +0100, Maarten Lankhorst wrote:
> The modeset state checker no longer has full access to the hardware,
> instead it should only check affected crtc's.
>
> Looking for disabled stuff can be checked immediately after all crtc
> disables have completed, while each e
On Wed, Mar 23, 2016 at 02:58:06PM +0100, Maarten Lankhorst wrote:
> This will make it easier to keep the crtc checker when atomic
> commit is reworked to take a intel_flip_work.
Looks good overall. You might want to expand the commit message
slightly since 'intel_flip_work' isn't something that
From: Alex Dai
No need for this workaround since SKL C0 and BXT B0.
Issue: VIZ-7615
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/intel_guc_loader.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/in
Hi Mark,
On Wed, 30 Mar 2016 14:24:10 -0700
Mark Brown wrote:
> On Wed, Mar 30, 2016 at 10:03:53PM +0200, Boris Brezillon wrote:
> > The continuous PWM voltage regulator is caching the voltage value in
> > the ->volt_uV field. While most of the time this value should reflect the
> > real voltage
On 04/07/2016 10:21 AM, Dave Gordon wrote:
During a hibernate/resume cycle, the driver, the GuC, and the doorbell
hardware can end up in inconsistent states. This patch refactors the
driver's handling and tracking of doorbells, in preparation for a later
one which will resolve the issue.
Signe
On Thu, 2016-04-07 at 20:22 +0530, Animesh Manna wrote:
> Along with below patches sharing some background details/design.
> - On BXT, Display cannot generate an interrupt when in D3.
> - Without display in D3, S0ix can be achieved, Power impact
> will be zero if d3 is blocked. PMCSR for Graphics/D
On Thu, Apr 07, 2016 at 08:20:15PM +0200, Mark Kettenis wrote:
> On OpenBSD I implemented idr_alloc() to return random IDs. While the
> xf86-video-modesetting driver is perfectly happy with this, the
> xf86-video-intel driver doesn't like it very much. I quickly figured
> out that that driver tru
On Thu, Apr 07, 2016 at 08:39:49PM +0200, Michał Winiarski wrote:
> From: Artur Harasimiuk
>
> It's possible to trigger a race between vma eviction and closing the
> object backing it when handling colliding addresses, resulting in
> use-after-free.
This test already exists in igt/gem_softpin, i
On OpenBSD I implemented idr_alloc() to return random IDs. While the
xf86-video-modesetting driver is perfectly happy with this, the
xf86-video-intel driver doesn't like it very much. I quickly figured
out that that driver truncates the identifiers to 8-bits when it
stores the values in its sna_c
When the memory backing the userptr object is freed by the user, but the
BO itself is not closed, it's possible to trigger recursive deadlock
caused by operations done on different BO mapped in that region.
Testcases are simulating such behaviour by using MAP_FIXED mmap flag.
v2: Grammar/naming fi
From: Artur Harasimiuk
It's possible to trigger a race between vma eviction and closing the
object backing it when handling colliding addresses, resulting in
use-after-free.
Cc: Chris Wilson
Cc: Thomas Daniel
Signed-off-by: Artur Harasimiuk
Signed-off-by: Michał Winiarski
---
tests/gem_soft
Test description suggested that all platforms were testing qword writes,
while in fact only gen4-gen5 did.
v2: Test dword/qword writes for all available platforms.
v3: Rewrite, drop libdrm/intel_batchbuffer dependencies,
drop brw_emit_post_sync_nonzero_flush WA for gen6/gen7,
drop WC_FLUSH
Where we have a suitable dev_priv pointer, we can use that rather than
'dev' for accessing INTEL_INFO(). This removes one level of memory
reference, decreasing code size a little and possibly making everything
a little faster. We could also do this for all the macros that implicitly
use INTEL_INFO
Add some additional information (input vs. output port, sink associated
with VC, peer device type, max number of VCs supported) and ensure that
any embedded '\0' characters in a branch device's devid string are not
written to debugfs.
v2: Rebase + change drm_edid_get_monitor_name() call to reflect
Modify the debugfs output for i915_dp_mst_info to list the source port for
the DP MST topology in question.
v2: rebase
Signed-off-by: Jim Bride
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/dr
In order to include monitor name information in debugfs
output we needed to add a function that would extract the
monitor name from the EDID, and that function needed to
reside in the file where the rest of the EDID helper
functions are implemented.
v2: Refactor to have drm_edid_get_monitor_name(
Split the function of "enable_guc_submission" into two separate options.
The new one "enable_guc_loading" controls only the *fetching and loading*
of the GuC firmware image. The existing one is redefined to control only
the *use* of the GuC for batch submission once the firmware is loaded.
In addi
During a hibernate/resume cycle, the driver, the GuC, and the doorbell
hardware can end up in inconsistent states. This patch refactors the
driver's handling and tracking of doorbells, in preparation for a later
one which will resolve the issue.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i91
Several issues have been found and recently fixed around the general
area of resetting and reloading the GuC, but the driver can still
leave the doorbell hardware in an inconsistent state after a reset
and reload, such as during a hibernate-and-resume cycle.
This set of patches provides solutions
Just code movement, no actual change to the function. This is in
preparation for the next patch, which will reorganise all the other
doorbell code, but doesn't change this function. So let's shuffle it
down near its caller rather than leaving it mixed in with the setup
code. Unlike the doorbell man
During a hibernate/resume cycle, the whole system is reset, including
the GuC and the doorbell hardware. Then the system is booted up, drivers
are loaded, etc -- the GuC firmware may be loaded and set running at this
point. But then, the booted kernel is replaced by the hibernated image,
and this r
When resetting and reloading the GuC, the GuC submission management code
also needs to destroy and recreate the GuC client(s). Currently this is
done by a separate call from the GuC loader, but really, it's just an
internal detail of the submission code. So here we remove the call from
the loader (
To properly verify the driver->doorbell->GuC functionality, validation
needs to know how the driver has assigned the doorbell cache lines and
registers, so make them visible through debugfs.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c | 8
1 file changed, 8 insert
== Series Details ==
Series: HPD support during suspend. (rev2)
URL : https://patchwork.freedesktop.org/series/5322/
State : failure
== Summary ==
Series 5322v2 HPD support during suspend.
http://patchwork.freedesktop.org/api/1.0/series/5322/revisions/2/mbox/
Test drv_getparams_basic:
== Series Details ==
Series: series starting with [1/3] drm/i915: Extract knowledge of register
forcewake domains
URL : https://patchwork.freedesktop.org/series/5419/
State : failure
== Summary ==
Series 5419v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5419/r
== Series Details ==
Series: drm/i915/dsi: improved gpio element support for vlv/chv/bxt (rev4)
URL : https://patchwork.freedesktop.org/series/4625/
State : failure
== Summary ==
Series 4625v4 drm/i915/dsi: improved gpio element support for vlv/chv/bxt
http://patchwork.freedesktop.org/api/1.0/
Hi Adam,
If you have cloned piglit into i-g-t directory go in scripts/
directory and run it from there (./run-tests.sh -t basic -s).
It might be that a results/ directory already exists so remove the
directory before this. There's currently some discussion on how to
handle this wit
On Thu, Apr 07, 2016 at 11:15:38AM +0300, Ander Conselvan De Oliveira wrote:
> On Wed, 2016-04-06 at 16:00 -0700, Jim Bride wrote:
> > In commit 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse") some
> > much needed clean-up was done, but unfortunately part of the change
> > broke DP MST. The
There are some results on PW: https://patchwork.freedesktop.org/series/5400/
Fi CI seems to be a little bit late on the results
On Thu, Apr 07, 2016 at 04:06:49PM +0100, Chris Wilson wrote:
> On Thu, Apr 07, 2016 at 07:29:10AM +0100, Chris Wilson wrote:
> > It's useful to look at the last seq
From: Tvrtko Ursulin
Because it is based on jiffies, current implementation releases the
forcewake at any time between straight away and between 1ms and 10ms,
depending on the kernel configuration (CONFIG_HZ).
This is probably not what has been desired, since the dynamics of keeping
parts of the
From: Tvrtko Ursulin
On platforms with multiple forcewake domains it seems more efficient
to request all desired ones and then to wait for acks to avoid
needlessly serializing on each domain.
v2: Rebase.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_u
From: Tvrtko Ursulin
As the vast majority of users do not use the domain id variable,
we can eliminate it from the iterator and also change the latter
using the same principle as was recently done for for_each_engine.
For a couple of callers which do need the domain mask, store it
in the domain
From: Tvrtko Ursulin
Rather than blindly waking up all forcewake domains on command
submission, we can teach each engine what is (or are) the correct
one to take.
On platforms with multiple forcewake domains like VLV, CHV, SKL
and BXT, this has the potential of lowering the GPU and CPU
power use
On Thu, Apr 07, 2016 at 03:52:46PM +0100, Tvrtko Ursulin wrote:
>
>
> On 07/04/16 15:35, Chris Wilson wrote:
> >On Thu, Apr 07, 2016 at 03:05:40PM +0100, Tvrtko Ursulin wrote:
> >>diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> >>b/drivers/gpu/drm/i915/intel_lrc.c
> >>index a1db6a02cf23..cac387f
== Series Details ==
Series: drm/i915: Fixing eDP detection on certain platforms (rev3)
URL : https://patchwork.freedesktop.org/series/5408/
State : failure
== Summary ==
Series 5408v3 drm/i915: Fixing eDP detection on certain platforms
http://patchwork.freedesktop.org/api/1.0/series/5408/revi
== Series Details ==
Series: RFC drm/i915: Emulate 64bit registers for residency counters
URL : https://patchwork.freedesktop.org/series/5414/
State : failure
== Summary ==
Series 5414v1 RFC drm/i915: Emulate 64bit registers for residency counters
http://patchwork.freedesktop.org/api/1.0/serie
Hi Jani,
[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v4.6-rc2 next-20160407]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Jani-Nikula/drm-i915-dsi-improved-gpio
On Thu, Apr 07, 2016 at 07:29:10AM +0100, Chris Wilson wrote:
> It's useful to look at the last seqno submitted on a particular engine
> and compare it against the HWS value to check for irregularities.
CI, what have I done to offend you?
-Chris
--
Chris Wilson, Intel Open Source Technology Cent
On Thu, Apr 07, 2016 at 03:36:04PM +0100, Tvrtko Ursulin wrote:
>
> On 07/04/16 15:24, Chris Wilson wrote:
> >On Thu, Apr 07, 2016 at 03:05:40PM +0100, Tvrtko Ursulin wrote:
> >>@@ -2099,6 +2101,12 @@ logical_ring_init(struct drm_device *dev, struct
> >>intel_engine_cs *engine)
> >>
> >>logic
For BXT, display engine can not generate interrupt when in D3.
On the othen hand S0ix can be achieved without display in D3. So,
Display should not put into D3 for HPD to work and will not
have any power impact.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_drv.c | 6 ++
1 file
To support hpd during sleep a new feature flag is
added in vbt and also in dev_priv for enabling/disabling
inside driver. By default this feature will be
disabled and based on oem request this feature can
be enabled by changing vbt feature flag.
v1: Initial version as RFC.
v2: Based on review com
Guid is changed for bxt platform, so corrected the guid for bxt.
Signed-off-by: Ananth Krishna R
Signed-off-by: Bharath K Veera
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/intel_acpi.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/int
While suspending the device hpd related interrupts are enabled
to get the interrupt when device is in suspend state.
Though display is in DC9 but system can be in S0 or S0i3 state.
Hot plug during S0 state will generate de_port_interrupt but if
system is in S0i3 state then display driver will get
Along with below patches sharing some background details/design.
- On BXT, Display cannot generate an interrupt when in D3.
- Without display in D3, S0ix can be achieved, Power impact
will be zero if d3 is blocked. PMCSR for Graphics/Display
is irrelevant, as the power management for them is taken
_DSM is added to program HPD_CTL(0x1094) register
of PMC from i915 driver which will be called
based on driver feature flag. PMC hpd control register
programming will enable PMC to get hpd interrupt
during dc9.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/intel_acpi.c | 45 +
On 07/04/16 15:35, Chris Wilson wrote:
On Thu, Apr 07, 2016 at 03:05:40PM +0100, Tvrtko Ursulin wrote:
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a1db6a02cf23..cac387f38cf6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/inte
Only support NC GPIOs for now, and assume the vlv gpio table only has NC
GPIOs for now.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/
On Thu, Apr 07, 2016 at 03:05:39PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Chris Wilson points out that we can remove them from the array
> since they are always written to with raw accessors.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson,
On Thu, Apr 07, 2016 at 03:05:38PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Knowledge of which register per platform belonds in which
> forcewake domain was embedded in the MMIO accessors themselves.
>
> Extract it into standalone macros so they can be used from
> new code in the
On 07/04/16 15:24, Chris Wilson wrote:
On Thu, Apr 07, 2016 at 03:05:40PM +0100, Tvrtko Ursulin wrote:
@@ -2099,6 +2101,12 @@ logical_ring_init(struct drm_device *dev, struct
intel_engine_cs *engine)
logical_ring_init_platform_invariants(engine);
+ engine->fw_domains_elsp =
+
On Thu, Apr 07, 2016 at 03:05:40PM +0100, Tvrtko Ursulin wrote:
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index a1db6a02cf23..cac387f38cf6 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -418,6 +418,7 @@ sta
Request the GPIO by index through the consumer API. For now, use a quick
hack to store the already requested ones, simply because I have no idea
whether this actually works or not, and I have no way to test it.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 28 ++
Add support for CHV gpio programming in DSI gpio elements.
v2: Overhaul macros according to Ville's review.
v3: Address Ville's review:
- swap E and SE gpio ranges
- add a note about max SE index
- use GPO, not HIZ
- swap cfg0 and cfg1
[Rewritten by Jani, based on earlier work by Yogesh and
False ideas introduced in
commit 1d96a4a8ace6c1b08c7d203d9533b14e59f2200b
Author: Jani Nikula
Date: Fri Mar 18 13:11:10 2016 +0200
drm/i915/dsi: add support for DSI sequence block v2 gpio element
Acked-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_pane
Series v4 after [1].
BR,
Jani.
[1] http://mid.gmane.org/cover.1459884518.git.jani.nik...@intel.com
Jani Nikula (4):
drm/i915/dsi: don't pretend we support SC GPIOs
drm/i915/dsi: add support for sequence block v3 gpio for VLV
drm/i915/dsi: add support for gpio elements on CHV
drm/i915/bxt
On Thu, Apr 07, 2016 at 03:05:40PM +0100, Tvrtko Ursulin wrote:
> @@ -2099,6 +2101,12 @@ logical_ring_init(struct drm_device *dev, struct
> intel_engine_cs *engine)
>
> logical_ring_init_platform_invariants(engine);
>
> + engine->fw_domains_elsp =
> + intel_reg_write_fw_d
On Thu, Apr 07, 2016 at 02:58:01PM +0100, Chris Wilson wrote:
> On Thu, Apr 07, 2016 at 04:18:16PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 07, 2016 at 01:59:44PM +0100, Chris Wilson wrote:
> > > Can we set that bit ourselves? That puts the overflow into the 1 hour
> > > mark. Thanks,
> >
> > I
== Series Details ==
Series: More robust i915 / audio binding
URL : https://patchwork.freedesktop.org/series/5412/
State : failure
== Summary ==
Series 5412v1 More robust i915 / audio binding
http://patchwork.freedesktop.org/api/1.0/series/5412/revisions/1/mbox/
Test core_auth:
Subgro
From: Tvrtko Ursulin
Knowledge of which register per platform belonds in which
forcewake domain was embedded in the MMIO accessors themselves.
Extract it into standalone macros so they can be used from
new code in the following patches.
This causes GCC to compile some of the MMIO accessors slig
From: Tvrtko Ursulin
Chris Wilson points out that we can remove them from the array
since they are always written to with raw accessors.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_uncore.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncor
From: Tvrtko Ursulin
Rather than blindly waking up all forcewake domains on command
submission, we can teach each engine what is (or are) the correct
one to take.
On platforms with multiple forcewake domains like VLV, CHV, SKL
and BXT, this has the potential of lowering the GPU and CPU
power use
On Thu, Apr 07, 2016 at 04:18:16PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 07, 2016 at 01:59:44PM +0100, Chris Wilson wrote:
> > Can we set that bit ourselves? That puts the overflow into the 1 hour
> > mark. Thanks,
>
> I don't know if it's safe to frob the bit. I worry that something
> outside
On Thu, 07 Apr 2016, Chris Wilson wrote:
> On Thu, Apr 07, 2016 at 12:48:17PM +0300, Jani Nikula wrote:
>> Sudden realization:
>>
>> $ grep -ho "INTEL_INFO([^)]*)->[a-zA-Z0-9_]*" *.[ch] | sed 's/.*->//' |\
>> sort | uniq -c | sort -rn | head -5
>> 446 gen
>>24 num_pipes
>>10 ring_mask
On Thu, 07 Apr 2016, Ramalingam C wrote:
> At BXT DSI, PIPE registers are inactive. So we can't get the
> PIPE's mode parameters from them. The possible option is
> retriving them from the PORT registers.
>
> The required changes are added for BXT in intel_dsi_get_config
> (encoder->get_config).
>
On Thu, 07 Apr 2016, Ville Syrjälä wrote:
> On Tue, Apr 05, 2016 at 10:30:51PM +0300, Jani Nikula wrote:
>> The shorthand is easier. Also change the struct name. No functional
>> changes.
>>
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Ville Syrjälä
Pushed the first three to drm-intel-next-q
== Series Details ==
Series: drm/i915: add INTEL_GEN() helper shorthand for INTEL_INFO()->gen
URL : https://patchwork.freedesktop.org/series/5407/
State : failure
== Summary ==
Series 5407v1 drm/i915: add INTEL_GEN() helper shorthand for INTEL_INFO()->gen
http://patchwork.freedesktop.org/api/1
On Tue, Apr 05, 2016 at 10:30:53PM +0300, Jani Nikula wrote:
> Add support for CHV gpio programming in DSI gpio elements.
>
> v2: Overhaul macros according to Ville's review.
>
> [Rewritten by Jani, based on earlier work by Yogesh and Deepak.]
>
> Signed-off-by: Yogesh Mohan Marimuthu
> Signed-
On Thu, Apr 07, 2016 at 01:59:44PM +0100, Chris Wilson wrote:
> On Thu, Apr 07, 2016 at 03:49:01PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 07, 2016 at 01:37:35PM +0100, Chris Wilson wrote:
> > > On Thu, Apr 07, 2016 at 03:13:51PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Apr 07, 2016 at 12:24
== Series Details ==
Series: drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport (rev2)
URL : https://patchwork.freedesktop.org/series/5367/
State : failure
== Summary ==
Series 5367v2 drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport
http://patchwork.freedesktop.org/ap
On Thu, 07 Apr 2016, Ville Syrjälä wrote:
> On Tue, Apr 05, 2016 at 10:30:52PM +0300, Jani Nikula wrote:
>> Just put the iosf port in the gpio table. The table might include some
>> duplication, but this approach keeps the code the cleanest.
>>
>> v2: pack the struct better (Ville), use designate
On Tue, Apr 05, 2016 at 10:30:52PM +0300, Jani Nikula wrote:
> Just put the iosf port in the gpio table. The table might include some
> duplication, but this approach keeps the code the cleanest.
>
> v2: pack the struct better (Ville), use designated initializers, add
> debug logging for mismatchi
On Thursday 07 April 2016 15:58:12 Jani Nikula wrote:
>
> *sigh*, there's pretty much no way the patches could cause any of
> this. :(
>
> BR,
> Jani.
I'm guessing that the IGT randomized testing order is hiding problems ...
can't really reproduce easily. I kind of liked the old system better.
On Tue, Apr 05, 2016 at 10:30:51PM +0300, Jani Nikula wrote:
> The shorthand is easier. Also change the struct name. No functional
> changes.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 15 +--
> 1 file changed, 9
On Tue, Apr 05, 2016 at 10:30:50PM +0300, Jani Nikula wrote:
> Prepare for future. No functional changes.
>
> v2: Move earlier in the series. Use bool for gpio value.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 68
> +++---
> 1 fi
On Thu, Apr 07, 2016 at 03:49:01PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 07, 2016 at 01:37:35PM +0100, Chris Wilson wrote:
> > On Thu, Apr 07, 2016 at 03:13:51PM +0300, Ville Syrjälä wrote:
> > > On Thu, Apr 07, 2016 at 12:24:13PM +0100, Chris Wilson wrote:
> > > > +static unsigned long calc_ov
On Tue, Apr 05, 2016 at 10:30:49PM +0300, Jani Nikula wrote:
> Define and store the pad base offset in the array, and reference the
> pconf0 and padval registers through macros. Add VLV prefixes to
> macros. Use spec nomenclature for pconf0 and padval.
>
> v2: Address Ville's review comments, squa
On Thu, 07 Apr 2016, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915: Sharing the
> pixel_format_from_vbt to whole i915
> URL : https://patchwork.freedesktop.org/series/5405/
> State : failure
>
> == Summary ==
>
> Series 5405v1 Series without cover lette
On Thu, 07 Apr 2016, Ville Syrjälä wrote:
> On Thu, Apr 07, 2016 at 02:47:52PM +0300, Jani Nikula wrote:
>> Request the GPIO by index through the consumer API. For now, use a quick
>> hack to store the already requested ones, simply because I have no idea
>> whether this actually works or not, and
On Thu, Apr 07, 2016 at 01:37:35PM +0100, Chris Wilson wrote:
> On Thu, Apr 07, 2016 at 03:13:51PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 07, 2016 at 12:24:13PM +0100, Chris Wilson wrote:
> > > +static unsigned long calc_overflow_jiffies(struct drm_device *dev)
> > > {
> > > - struct drm_i915
On Thu, Apr 07, 2016 at 03:13:51PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 07, 2016 at 12:24:13PM +0100, Chris Wilson wrote:
> > +static unsigned long calc_overflow_jiffies(struct drm_device *dev)
> > {
> > - struct drm_i915_private *dev_priv = dev->dev_private;
> > + struct drm_i915_private
On to, 2016-04-07 at 14:55 +0300, Ville Syrjälä wrote:
> On Thu, Apr 07, 2016 at 12:57:22PM +0200, Takashi Iwai wrote:
> > From: Imre Deak
> >
> > User may pass nomodeset or i915.modeset=0 option to disable i915
> > KMS
> > explicitly. Although this itself works fine, it breaks the weak
> > depe
On Thu, Apr 07, 2016 at 02:47:52PM +0300, Jani Nikula wrote:
> Request the GPIO by index through the consumer API. For now, use a quick
> hack to store the already requested ones, simply because I have no idea
> whether this actually works or not, and I have no way to test it.
Would be cool if som
On 07/04/16 12:42, Shubhangi Shrivastava wrote:
Since commit 30d9aa4265fe ("drm/i915: Read sink_count dpcd always"),
the status of a DP connector depends on its sink count value.
However, some eDP panels don't set that value appropriately,
causing them to be reported as disconnected.
Fix this by
On Thu, Apr 07, 2016 at 12:24:13PM +0100, Chris Wilson wrote:
> RC6 residency counters are kept by the hardware in 32bit registers,
> which then overflow in a couple of hours. Ideally, we want a continuous
> count of the residency since boot and so we must maintain an overflow
> counter ourselves.
== Series Details ==
Series: series starting with [1/2] drm/i915: Sharing the pixel_format_from_vbt
to whole i915
URL : https://patchwork.freedesktop.org/series/5405/
State : failure
== Summary ==
Series 5405v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5405/r
On Thu, Apr 07, 2016 at 12:57:22PM +0200, Takashi Iwai wrote:
> From: Imre Deak
>
> User may pass nomodeset or i915.modeset=0 option to disable i915 KMS
> explicitly. Although this itself works fine, it breaks the weak
> dependency the HD-audio driver requires, and it's the reason the
> delayed
On Thu, 7 Apr 2016, Bjørn Mork wrote:
> > after updating to 4.6-rcX (where X is 1 or 2, doesn't really matter) on
> > thinkpad x200s notebook with
> >
> > 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
> > Chipset Integrated Graphics Controller (rev 07)
> >
> > closing
On to, 2016-04-07 at 11:31 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v4,1/3] drm/i915: Use i915_vm_to_ppgtt instead
> of manual container_of
> URL : https://patchwork.freedesktop.org/series/5403/
> State : failure
>
> == Summary ==
>
> Series 5403v1 Seri
Request the GPIO by index through the consumer API. For now, use a quick
hack to store the already requested ones, simply because I have no idea
whether this actually works or not, and I have no way to test it.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 28 ++
Since commit 30d9aa4265fe ("drm/i915: Read sink_count dpcd always"),
the status of a DP connector depends on its sink count value.
However, some eDP panels don't set that value appropriately,
causing them to be reported as disconnected.
Fix this by ignoring sink count for eDP.
Fixes: 30d9aa4265fe
== Series Details ==
Series: series starting with [v4,1/3] drm/i915: Use i915_vm_to_ppgtt instead of
manual container_of
URL : https://patchwork.freedesktop.org/series/5403/
State : failure
== Summary ==
Series 5403v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series
RC6 residency counters are kept by the hardware in 32bit registers,
which then overflow in a couple of hours. Ideally, we want a continuous
count of the residency since boot and so we must maintain an overflow
counter ourselves. Utilities such as powertop read these registers
through sysfs and the
On Thu, 2016-04-07 at 16:03 +0530, Shubhangi Shrivastava wrote:
> Sink count was read for eDP as well as DP. But in some cases
> the sink count for eDP is received as zero, as against the
> expected non zero value. This is seen in:
>
> commit 30d9aa4265fe4b2b28239934770b2c2d59858df3
> Author: Shub
Since i915 notifies its disabled state via the stub component binding,
we can bail out immediately once when the disabled flag is detected.
Based on the original patch by Imre Deak
Signed-off-by: Takashi Iwai
---
sound/hda/hdac_i915.c | 16 +---
1 file changed, 13 insertions(+), 3
From: Imre Deak
User may pass nomodeset or i915.modeset=0 option to disable i915 KMS
explicitly. Although this itself works fine, it breaks the weak
dependency the HD-audio driver requires, and it's the reason the
delayed component binding isn't implemented in HD-audio. Since i915
doesn't notif
Since we have the reliable way to detect the availability of i915
audio component, the HD-audio driver may wait for the binding safely.
This patch puts a simple completion call in the binding callback and
let snd_hdac_i915_init() waiting until the i915 component gets bound
or it notifies.
The wai
1 - 100 of 126 matches
Mail list logo
