On Mon, 29 Jul 2013, Felipe Contreras wrote:
> I don't notice any difference with your patch.
Ok, thanks for trying it out.
BR,
Jani.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hey,
so I put a patch into intel driver a while ago to avoid doing a bo
flush using map/unmap for output slave device if the kernel has vmap
flushing
However on reflection I realised this only works for CPU accessing
devices like UDL but doesn't work for GPU accessing devices like
nouveau/radeon,
>> > I do agree that QA is really important for a fastpaced process, but
>> > it's also not the only peace to get something in. Review (both of the
>> > patch itself but also of the test coverage) catches a lot of issues,
>> > and in many cases not the same ones as QA would. Especially if the
>> >
On 07/30/2013 03:36 AM, * SAMÍ * wrote:
> Hi Rafael,
>
>
> did you commit a full revert?
> Because I am experiencing quite weird things in rc3.
> Do we have a bug opened to discuss about it?
Yes we have:
https://bugzilla.kernel.org/show_bug.cgi?id=52951
I'll look into this issue.
Thanks,
Aaron
On Mon, Jul 29, 2013 at 05:48:22PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> This patch allows PC8+ states on Haswell. These states can only be
> reached when all the display outputs are disabled, and they allow some
> more power savings.
This explanation needs to be kept in the code s
On Sat, 27 Jul 2013 09:13:38 +1000
Dave Airlie wrote:
> >
> > Hey, overall it's actually quite a bit of fun.
> >
> > I do agree that QA is really important for a fastpaced process, but
> > it's also not the only peace to get something in. Review (both of the
> > patch itself but also of the test
On Monday, July 29, 2013 11:53:59 PM * SAMÍ * wrote:
> When I make acpi_video_backlight_quirks() return false:
> - the Fn+x keys are not working anymore (remember that they didn't work
> in 3.10 nor 3.9)
> - At least the backlight remains on at boot.
> - Gnome brightness settings do not work anymo
On Mon, Jul 29, 2013 at 05:48:22PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> This patch allows PC8+ states on Haswell. These states can only be
> reached when all the display outputs are disabled, and they allow some
> more power savings.
>
> The fact that the graphics device is allowi
From: Paulo Zanoni
This test chekcs our code that enables Package C8+. The environment
requirements for this test are quite complicated:
- The machine needs to be properly configured to reach PC8+ when
possible, which means all the power management policies and device
drivers must be pr
From: Paulo Zanoni
Things should be working, so enable it by default.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6df516b..8f6e685
From: Paulo Zanoni
For now it just prints the value of the forbid_refcount and allowing
variables.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debugfs.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/d
From: Paulo Zanoni
This message is not really useful since it's very easy to check which
mode is used for each port, and if you allow/disallow PC8+ many times
it will eat your dmesg buffers.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 4
1 file changed, 4 deletions(
From: Paulo Zanoni
If we're already allowing PC8, just don't use the IRQs, so we won't
need to wake from PC8. Waking up from PC8 is a slow thing, so avoid it
when we can.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_i2c.c | 75 ++--
1 file chan
From: Paulo Zanoni
If we're already allowing PC8, just don't use the IRQs, so we won't
need to wake from PC8. Waking up from PC8 is a slow thing, so avoid it
when we can.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_dp.c | 26 +++---
1 file changed, 23 inserti
From: Paulo Zanoni
This patch allows PC8+ states on Haswell. These states can only be
reached when all the display outputs are disabled, and they allow some
more power savings.
The fact that the graphics device is allowing PC8+ doesn't mean that
the machine will actually enter PC8+: all the othe
From: Paulo Zanoni
If the error interrupts are already disabled, don't disable and
reenable them. This is going to be needed when we're in PC8+, where
all the interrupts are disabled so we won't risk re-enabling
DE_ERR_INT_IVB.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c |
From: Paulo Zanoni
We already have code to disable LCPLL and switch to FCLK, so we need this too.
We still don't call the code to disable LCPLL, but we'll call it when we add
support for Package C8+.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 9 ++---
1 file changed
From: Paulo Zanoni
Hi
Some time ago I sent the first versions of patches to allow PC8+ and received
some feedback from Daniel. Based on his feedback and subsequent conversations,
we agreed that the right way to go would be to modify our "irq_uninstall"
function so it would allow uninstalling "ev
On Monday, July 29, 2013 09:36:31 PM * SAMÍ * wrote:
> Hi Rafael,
>
>
> did you commit a full revert?
Yes, but I left acpi_video_backlight_quirks() (in drivers/acpi/video_detect.c)
that is used to decide what to do with _DOS.
Can you please check if making that function always return 'false' ma
On Mon, Jul 29, 2013 at 04:20:28PM +0300, Jani Nikula wrote:
> On Fri, 26 Jul 2013, Chris Wilson wrote:
> > Otherwise we get flooded by the kernel warning us that we are doing
> > long sequences of IO without serialisation. For example,
> >
> > WARNING: CPU: 0 PID: 11136 at drivers/gpu/drm/i915/i
On Fri, 26 Jul 2013, Chris Wilson wrote:
> Otherwise we get flooded by the kernel warning us that we are doing
> long sequences of IO without serialisation. For example,
>
> WARNING: CPU: 0 PID: 11136 at drivers/gpu/drm/i915/intel_sideband.c:40
> vlv_sideband_rw+0x48/0x1ef()
> Modules linked in
On Wed, Jul 24, 2013 at 11:14:57AM -0300, Paulo Zanoni wrote:
> 2013/7/24 Chris Wilson :
> > On Tue, Jul 23, 2013 at 07:33:43PM -0300, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> The problem here is that we have the PIPESTAT registers between IER
> >> and IIR, so when we use intel_irq_re
Hi Dave,
On Mon, 29 Jul 2013 16:29:04 +1000 Dave Airlie wrote:
>
> Okay should all be back in place now.
Excellent, thanks.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp98zYRdc1W4.pgp
Description: PGP signature
___
Intel-
On Mon, Jul 29, 2013 at 10:26 AM, Stephen Rothwell
wrote:
> Hi Dave,
>
> On Mon, 29 Jul 2013 10:15:50 +1000 Dave Airlie wrote:
>>
>> > Trying to fetch the drm-intel-fixes tree
>> > (git://people.freedesktop.org/~danvet/drm-intel#drm-intel-fixes) this
>> > morning produced this error:
>>
>> There
24 matches
Mail list logo
