On Wed, 23 Oct 2013, Ben Widawsky wrote:
> All our registers which are written through the MCHBAR are defined
> descriptively as an offset to the MCHBAR. We had 3 outliers here.
> Convert these as well so all registers which are offsets are MCHBAR can
> be easily identified/found within the code.
On Mon, Oct 21, 2013 at 11:56:09AM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The audio driver uses the power well provided by our driver, so on
> Haswell we can't "rmmod i915" if we don't "rmmod snd_hda_intel" first.
>
> The problem with removing snd_hda_intel is that we also need to k
On Mon, Oct 21, 2013 at 09:10:33AM +0100, Chris Wilson wrote:
> The current output looks like:
>
> Num Pipes: 2
> Pipe [0]:
> SRC: 027f01df
> Plane [0]:
> CNTR: d900
> STRIDE: 1400
> SIZE: 031f04ff
> POS:
> ADDR: 0002
> Cursor [0]:
> CNTR:
> POS: 0
All our registers which are written through the MCHBAR are defined
descriptively as an offset to the MCHBAR. We had 3 outliers here.
Convert these as well so all registers which are offsets are MCHBAR can
be easily identified/found within the code.
With this, convert DCLK to also follow this forma
Dave Airlie just implemented some Xv support as below, although not fully
support all functions.
But currently, we haven't enable it in Intel's driver side.
commit bad96d415525b12add517b09a26b52c2c36979f7
Author: Dave Airlie
Date: Mon Sep 23 06:42:24 2013 +0100
glamor: add initial Xv suppo
I don't think glamor support xmvc now.
However port those xmvc code to glamor is doable.
Thanks
Zou Nanhai
-Original Message-
From: intel-gfx-bounces+nanhai.zou=intel@lists.freedesktop.org
[mailto:intel-gfx-bounces+nanhai.zou=intel@lists.freedesktop.org] On Behalf
Of Chris Wilso
2013/10/18 Jesse Barnes :
> On Wed, 16 Oct 2013 17:25:52 +0300
> Imre Deak wrote:
>
>> So far the modeset code enabled all power domains if it needed any. It
>> wasn't a problem since HW generations so far only had one always-on
>> power well and one dynamic power well that can be enabled/disabled
From: Paulo Zanoni
The code to enable/disable PC8 already takes care of saving and
restoring all the registers we need to save/restore, so do a put()
call when we enable PC8 and a get() call when we disable it.
Ideally, in order to make it easier to add runtime PM support to other
platforms, we
From: Paulo Zanoni
If I add code to enable runtime PM on my Haswell machine, start a
desktop environment, then enable runtime PM, these functions will
complain that they're trying to read/write registers while the
graphics card is suspended.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915
From: Paulo Zanoni
And leave it off by default. We have way too many driver entry points,
we can't assume this will work without regressions without tons of
testing first. This option allows people to test and fix the problems.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_dma.c |
From: Paulo Zanoni
These are needed when we cat the debugfs and sysfs files.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debugfs.c | 46 ++---
drivers/gpu/drm/i915/i915_sysfs.c | 14 +--
drivers/gpu/drm/i915/intel_dp.c | 11 +++--
From: Paulo Zanoni
This patch adds the initial infrastructure to allow a Runtime PM
implementation that sets the device to its D3 state. The patch just
adds the necessary callbacks and the initial infrastructure.
We still don't have any platform that actually uses this
infrastructure, we still d
From: Paulo Zanoni
Now that we are actually setting the device to the D3 state, we should
issue the notification.
Jani originally wrote a similar patch for PC8, but then we discovered
that we were not really changing the PCI D states when
enabling/disabling PC8, so we had to postpone his patch.
From: Paulo Zanoni
Hi
This RFC series adds runtime PM support on Haswell. The current implementation
puts the device in the PCI D3cold state when we decide to sleep. It uses the
same refcount+timeout idea from the PC8 code, but now through the Kernel runtime
PM infrastructure.
I saw Jesse and I
Currently we make sure that all power domains are enabled during driver
init and turn off unneded ones only after the first modeset. Similarly
during suspend we enable all power domains, which will remain on through
the following resume until the first modeset.
This logic is supported by intel_set
In the future we'll need to support multiple power wells, so prepare for
that here. Create a new power domains struct which contains all
power domain/well specific fields. Since we'll have one lock protecting
all power wells, move power_well->lock to the new struct too.
No functional change.
Sign
On Tue, Oct 22, 2013 at 03:33:16PM -0200, Rodrigo Vivi wrote:
> I still think state_default is working, enough and simpler...
> or do you really want me to use config and max_config instead?
I think keeping the hw config separate from the requested config helps a
lot when reviewing the code in 6 m
On Tue, Oct 22, 2013 at 5:47 AM, Chris Wilson wrote:
> On Mon, Oct 21, 2013 at 07:00:18PM -0200, Rodrigo Vivi wrote:
>> static int
>> +i915_legacy_userspace_busy(struct drm_device *dev,
>> +struct intel_ring_buffer *ring)
>
> s/i915_legacy_userspace_busy/gt_legacy_userspac
Today's linux-next merge of the drm tree got conflicts in
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/i915_drv.c
drivers/gpu/drm/i915/intel_ddi.c
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_dp.c
drivers/gpu/drm/i915/intel
On Tue, Oct 22, 2013 at 03:24:18PM +0200, Thomas Richter wrote:
> Am 22.10.2013 14:03, schrieb Chris Wilson:
> >Ah, /var/log/Xorg.0.log has greater verbosity than stdout/stderr. I am
> >just curious where we reject the -intel driver and hence fail to init
> >the screen.
>
> /var/logXorg.0.log is z
Am 22.10.2013 14:03, schrieb Chris Wilson:
Ah, /var/log/Xorg.0.log has greater verbosity than stdout/stderr. I am
just curious where we reject the -intel driver and hence fail to init
the screen.
/var/logXorg.0.log is zero bytes long at this point. I wouldn't call
this "greater". (-;
Let it b
We expect this bit to be always set when possible, but some BIOSes are
lazy and don't do this. The result is a pile of WARNs and unhappy fdi
link training code ...
v2: It's actually the inverse: The BIOS sets this bit when it's not
strictly needed. This should be cleaned up in the
global_modeset_r
On Tue, Oct 22, 2013 at 01:15:32PM +0100, Chris Wilson wrote:
> On Tue, Oct 22, 2013 at 12:04:17PM +, Siluvery, Arun wrote:
> > From: "Siluvery, Arun"
> >
> > When a mapping is requested and if there is no space the mapping fails
> > and the region is not physically backed. This results in
>
On Tue, Oct 22, 2013 at 12:04:17PM +, Siluvery, Arun wrote:
> From: "Siluvery, Arun"
>
> When a mapping is requested and if there is no space the mapping fails
> and the region is not physically backed. This results in
> signal 7(SIGBUS), code 2 (BUS_ADRERR) when it is actually accessed.
> Th
From: "Siluvery, Arun"
When a mapping is requested and if there is no space the mapping fails
and the region is not physically backed. This results in
signal 7(SIGBUS), code 2 (BUS_ADRERR) when it is actually accessed.
This patch handles this error, continues to wait and retries to find space.
S
On Tue, Oct 22, 2013 at 12:18:54PM +0200, Thomas Richter wrote:
> Hi Chris, hi Daniel,
> >A full drm.debug=6 dmesg, Xorg.0.log and xrandr --verbose would be
> >useful starting point to distangling what is going on. Is this an 830gm
> >or an 845g? google says 830gm, so there should be 2 crtcs availa
On Tue, 22 Oct 2013, Shobhit Kumar wrote:
> On 10/21/2013 6:57 PM, Jani Nikula wrote:
>>
>> Hi Shobhit -
>>
>> On Mon, 21 Oct 2013, Shobhit Kumar wrote:
>>> Also add new fields in intel_dsi to have all dphy related parameters.
>>> These will be useful even when we go for pure generic MIPI design
On Tue, Oct 22, 2013 at 02:36:18PM +0530, Shobhit Kumar wrote:
> On 10/21/2013 6:53 PM, Ville Syrjälä wrote:
> > On Mon, Oct 21, 2013 at 05:51:07PM +0530, Shobhit Kumar wrote:
> >> Has been tested on couple of panels now.
> >
> > While it's nice to get patches, I can't say I'm very happy about the
On 10/21/2013 6:57 PM, Jani Nikula wrote:
Hi Shobhit -
On Mon, 21 Oct 2013, Shobhit Kumar wrote:
Also add new fields in intel_dsi to have all dphy related parameters.
These will be useful even when we go for pure generic MIPI design
I feel like we have a different idea of what the ideal gen
On Tue, Oct 22, 2013 at 10:15 AM, Ville Syrjälä
wrote:
> FLIP_DONE etc. interrupts already depend on the crtc being there. Not
> sure why this is different.
I'd say we've simply lucked out thus far. E.g. on vlv the
init_clock_gating flushes the primary plane and so casues a flip done
interrupt. B
On 10/21/2013 7:14 PM, Jani Nikula wrote:
On Mon, 21 Oct 2013, Shobhit Kumar wrote:
Minor modification to m_n_p calculations as well
That should probably be a separate patch, unless it's a requirement for
what the main subject of this patch is. The commit message does not say.
Will do the n
On 10/21/2013 6:58 PM, Ville Syrjälä wrote:
On Mon, Oct 21, 2013 at 05:51:06PM +0530, Shobhit Kumar wrote:
Minor modification to m_n_p calculations as well
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 75 --
1 file changed, 63 ins
On 10/21/2013 6:53 PM, Ville Syrjälä wrote:
On Mon, Oct 21, 2013 at 05:51:07PM +0530, Shobhit Kumar wrote:
Has been tested on couple of panels now.
While it's nice to get patches, I can't say I'm very happy about the
shape of this one.
The patch contains several changes in one patch. It shoul
On Mon, Oct 21, 2013 at 10:54:16PM +0200, Daniel Vetter wrote:
> On Mon, Oct 21, 2013 at 10:47 PM, Damien Lespiau
> wrote:
> > On Mon, Oct 21, 2013 at 09:10:20PM +0200, Daniel Vetter wrote:
> >> Adding stuff to the bottom of struct drm_i915_driver_private is
> >> nowadays considered uncool.
> >>
>
On Tue, Oct 22, 2013 at 01:02:22AM -0700, Grant wrote:
> > With the exception of not having Xv (or XvMC) support enabled for glamor
> > in -intel, you can, at your own risk, enable glamor during configure
>
> Are you saying that glamor depends on xvmc?
-intel needs to explicitly enable Xv support
>> How can I find out if I should enable glamor and xvmc on my Dell XPS
>> 13 (1st gen) laptop?
>
> Should? No. If it was essential, we would do so automatically and put up
> big flashing neon warning signs if it failed.
I see, so glamor is an alternative to sna and uxa. I'll give it a try.
> Wi
On Mon, Oct 21, 2013 at 07:00:18PM -0200, Rodrigo Vivi wrote:
> static int
> +i915_legacy_userspace_busy(struct drm_device *dev,
> +struct intel_ring_buffer *ring)
s/i915_legacy_userspace_busy/gt_legacy_userspace_busy/
As that is a bit more distinctive.
> +{
> + drm_
37 matches
Mail list logo
