> > > Please resend with a patch changelog to account for my review
> comments.
> > > And Ville's. Plus cc us both. And if there's anything you didn't
> > > address, you must reply to the review and we need to further discuss this.
> > >
> >
> > Daniel, I see, thanks for the instruction.
> > Do you
On 10/22/2014 05:48 PM, Daniel Vetter wrote:
So on a very high level I don't understand this design. For the guest side
it's completely clear that we need a bunch of hooks over the driver to
make paravirtualization work.
But on the host side I expect the driver to be in full control of the
hardw
On Tue, Oct 07, 2014 at 08:43:46AM +, Jindal, Sonika wrote:
> Hi,
>
> Did anybody get a chance to look at this patch?
>
> Thanks,
> Sonika
Looks like we waited a bit too long and the codebase has evolved, so I
needed to make some tweaks to your patches to get them to apply cleanly
on the lat
On Wed, 2014-10-22 at 14:43 -0700, H. Peter Anvin wrote:
> On 10/22/2014 02:38 PM, Eric Paris wrote:
> >
> > It was sent, numerous times, to the x86 list for reviews, and lived in
> > -next for 2 complete devel cycles without a complaint. I'm trying to
> > get an i386 system to test a fix. But y
On 10/22/2014 02:38 PM, Eric Paris wrote:
>
> It was sent, numerous times, to the x86 list for reviews, and lived in
> -next for 2 complete devel cycles without a complaint. I'm trying to
> get an i386 system to test a fix. But yes, it's total crap.
>
You don't need an i386 system -- you can i
On Wed, Oct 22, 2014 at 06:59:52PM +0100, Arun Siluvery wrote:
> The number of DWords should be even when doing ring emits as
> command sequences require QWord alignment.
>
> v2: user LRI variant that can write multiple regs in one go (Damien).
> We can simply insert one NOP at the end instead of
On Wed, 2014-10-22 at 14:43 -0700, H. Peter Anvin wrote:
> On 10/22/2014 02:38 PM, Eric Paris wrote:
> >
> > It was sent, numerous times, to the x86 list for reviews, and lived in
> > -next for 2 complete devel cycles without a complaint. I'm trying to
> > get an i386 system to test a fix. But y
On Wed, 2014-10-22 at 23:36 +0200, Thomas Gleixner wrote:
> On Wed, 22 Oct 2014, Eric Paris wrote:
>
> > That's really serious. Looking now.
>
> Indeed its serious. And it's even more serious as this masterpiece of
> assembly wreckage was pulled in via your tree w/o having an acked-by
> one of t
On Wed, Oct 22, 2014 at 12:16 PM, Richard Guy Briggs wrote:
> On 14/10/22, Andy Lutomirski wrote:
>> On 10/22/2014 11:23 AM, Eric Paris wrote:
>> > That's really serious. Looking now.
>> >
>> > On Wed, 2014-10-22 at 16:08 -0200, Paulo Zanoni wrote:
>> >> Hi
>> >>
>> >> (Cc'ing everybody mentioned
On 14/10/22, Andy Lutomirski wrote:
> On 10/22/2014 11:23 AM, Eric Paris wrote:
> > That's really serious. Looking now.
> >
> > On Wed, 2014-10-22 at 16:08 -0200, Paulo Zanoni wrote:
> >> Hi
> >>
> >> (Cc'ing everybody mentioned in the original patch)
> >>
> >> I work for Intel, on our Linux Grap
On 10/22/2014 11:23 AM, Eric Paris wrote:
> That's really serious. Looking now.
>
> On Wed, 2014-10-22 at 16:08 -0200, Paulo Zanoni wrote:
>> Hi
>>
>> (Cc'ing everybody mentioned in the original patch)
>>
>> I work for Intel, on our Linux Graphics driver - aka i915.ko - and our
>> QA team recentl
2014-10-22 9:20 GMT-02:00 Imre Deak :
> On Tue, 2014-10-21 at 19:05 +0200, Daniel Vetter wrote:
>> On Mon, Oct 20, 2014 at 01:20:50PM +0300, Imre Deak wrote:
>> > On Fri, 2014-10-17 at 16:01 -0300, Paulo Zanoni wrote:
>> > > From: Paulo Zanoni
>> > >
>> > > As far as I understand, intel_uncore_ear
Hello
Sorry for the late reply.
On Thu, Sep 11, 2014 at 2:36 PM, Jesse Barnes
wrote:
> Your config looks ok, but it sounds like the i915 driver may be doing a
> full mode set.
The flickering suggested me it did.
> Doing a drm.debug=6 with fastboot enabled should give
> us clues about why in
On Tue, Oct 07, 2014 at 11:00:54PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 07, 2014 at 04:11:11PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > Only run it after we actually enable the power well. When we're
> > booting the machine there are cases where we run
> > hsw_power_well_pos
On Tue, 21 Oct 2014, Mika Kuoppala wrote:
> Regression from:
>
> commit be4710a541b517b5f8663448bffed5656d59b47b
> Author: Thomas Wood
> Date: Fri Oct 10 11:20:35 2014 +0100
>
> lib: add common min and max macros
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85218
> Tested-by:
That's really serious. Looking now.
On Wed, 2014-10-22 at 16:08 -0200, Paulo Zanoni wrote:
> Hi
>
> (Cc'ing everybody mentioned in the original patch)
>
> I work for Intel, on our Linux Graphics driver - aka i915.ko - and our
> QA team recently reported a regression on:
>
> commit b4f0d3755c5e
Hi
(Cc'ing everybody mentioned in the original patch)
I work for Intel, on our Linux Graphics driver - aka i915.ko - and our
QA team recently reported a regression on:
commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a
Author: Richard Guy Briggs
Date: Tue Mar 4 10:38:06 2014 -0500
audit: x86:
The number of DWords should be even when doing ring emits as
command sequences require QWord alignment.
v2: user LRI variant that can write multiple regs in one go (Damien).
We can simply insert one NOP at the end instead of one per register write.
Cc: Mika Kuoppala
Signed-off-by: Arun Siluvery
[snip]
On Tue, Oct 21, 2014 at 08:50:33AM -0700, Daniel Vetter wrote:
> On Thu, Oct 16, 2014 at 12:24:42PM -0700, bradley.d.vol...@intel.com wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 1a0611b..1ed5702 100644
> > --
On Tue, 21 Oct 2014 16:53:02 +0200
Daniel Vetter wrote:
> On Thu, Oct 09, 2014 at 12:57:45PM -0700, Jesse Barnes wrote:
> > From: Kristian Høgsberg
> >
> > The BIOS may set a native mode that doesn't quite match the preferred
> > mode timings. It should be ok to use however if it uses the same
On Wed, Oct 22, 2014 at 02:28:45PM +0100, daniele.ceraolospu...@intel.com wrote:
> From: Daniele Ceraolo Spurio
>
> These tracepoints are useful for observing the creation and
> destruction of Full PPGTTs.
>
> v4: add DOC information
>
> Signed-off-by: Daniele Ceraolo Spurio
> ---
> drivers/g
On Tue, Oct 21, 2014 at 08:26:05AM -0700, Daniel Vetter wrote:
> On Wed, Oct 15, 2014 at 02:52:41PM -0700, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > The size of the batch buffer passed to the kernel is significantly
> > larger than the size of the batch buffer passed to the
On 10/21/2014 7:41 AM, Daniel Vetter wrote:
On Fri, Oct 17, 2014 at 11:41:12AM -0700, Todd Previte wrote:
V2 changes:-+
- Moved the intel_dp_enable_port() call out of intel_dp_enable() and placed it
before the calls to intel_dp_enable() and vlv_wait_port_ready()
- Cleaned up a spacing issues
On 10/16/2014 11:27 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
There's no point in checking if the data lanes came out of reset after
link training. If the data lanes aren't ready link training will fail
anyway.
Suggested-by: Todd Previte
Cc: Todd Previte
Signed-off-by: Vi
On Thu, 09 Oct 2014, Todd Previte wrote:
> Link training for Displayport can fail in many ways and at multiple different
> points
> during the training process. Previously, errors were logged but no additional
> action
> was taken based on them. Consequently, training attempts could continue eve
On Tue, 21 Oct 2014, Daniel Vetter wrote:
> On Fri, Oct 17, 2014 at 09:08:28AM -0700, Todd Previte wrote:
>>
>> On 10/17/2014 1:43 AM, Ville Syrjälä wrote:
>> >On Thu, Oct 16, 2014 at 12:38:55PM -0700, Todd Previte wrote:
>> >>On 10/16/2014 10:46 AM, ville.syrj...@linux.intel.com wrote:
>> >>>Fro
On Fri, 17 Oct 2014, Jani Nikula wrote:
> On Thu, 16 Oct 2014, ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä
>>
>> vlv_cdclk_freq is in kHz but we need MHz for the GMBUSFREQ divider.
>>
>> This is a regression from:
>> commit f8bf63fdcb1f82459dae7a3f22ee5ce92f3ea727
>> Author: Vil
From: Daniele Ceraolo Spurio
These tracepoints are useful for observing the creation and
destruction of Full PPGTTs.
v4: add DOC information
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 +++
drivers/gpu/drm/i915/i915_trace.h | 58 +++
On 10/22/2014 12:40 AM, Daniel Vetter wrote:
On Thu, Oct 16, 2014 at 02:24:27PM +0800, Yu Zhang wrote:
In the virtualized environment, forcewake operations are not
necessory for the driver, because mmio accesses will be trapped
and emulated by the host side, and real forcewake operations are
a
[This is in reply to https://lkml.org/lkml/2014/10/3/415 - I just don't
have the message to reply to.]
Daniel, the bug you describe is likely [1]. We're on it.
Thanks,
Jani.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=86551
--
Jani Nikula, Intel Open Source Technology Center
On 10/22/2014 11:33 AM, Ville Syrjälä wrote:
On Tue, Oct 21, 2014 at 04:02:04PM +0300, Ander Conselvan de Oliveira wrote:
It is possible for a mode set to fail if there aren't shared DPLLS that
match the new configuration requirement or other errors in clock
computation. If that step is executed
On Wed, Oct 22, 2014 at 09:57:06AM +0300, Ville Syrjälä wrote:
> On Fri, Oct 17, 2014 at 08:05:08AM -0700, Rodrigo Vivi wrote:
> > Current chv spec teels we can only use either 16 or 32 bits as precision.
> >
> > Although in the past VLV went from 16/32 to 32/64 and spec might not be
> > updated,
On Tue, 2014-10-21 at 19:05 +0200, Daniel Vetter wrote:
> On Mon, Oct 20, 2014 at 01:20:50PM +0300, Imre Deak wrote:
> > On Fri, 2014-10-17 at 16:01 -0300, Paulo Zanoni wrote:
> > > From: Paulo Zanoni
> > >
> > > As far as I understand, intel_uncore_early_sanitize() was supposed to
> > > be ran b
On Wed, Oct 22, 2014 at 11:40:30AM +0100, Damien Lespiau wrote:
> On Wed, Oct 22, 2014 at 10:09:49AM +0100, Arun Siluvery wrote:
> > The number of DWords should be even when doing ring emits as
> > command sequences require QWord alignment.
>
> It looks like we could just pad at the end of the bat
On Wed, Oct 22, 2014 at 10:09:49AM +0100, Arun Siluvery wrote:
> The number of DWords should be even when doing ring emits as
> command sequences require QWord alignment.
It looks like we could just pad at the end of the batch instead of one
NOP per register write?
Also, It looks like we could us
On Wed, Oct 22, 2014 at 03:03:56PM +0800, Yu, Zhang wrote:
> On 10/22/2014 12:51 AM, Daniel Vetter wrote:
> >- Please pull all the new documentation together and integrate it into the
> > i915 section of the drm docbook. A good place is probably a new
> > subsection "Paravirtualized Guest Suppo
On Tue, Sep 30, 2014 at 06:05:30PM +0800, Jike Song wrote:
> Intel GVT-g (previously known as XenGT), is a complete GPU
> virtualization solution with mediated pass-through for 4th
> generation Intel Core processors - Haswell platform. This
> technology presents a virtual full-fledged GPU to each V
On Wed, Oct 22, 2014 at 11:23:03AM +0200, Daniel Vetter wrote:
> This reverts commit 8c50f10d73b50139dcfe48bc22f2c8c7822c1983.
>
> It's not yet solid and Dave objected to pulling the tree in its
> current state.
>
> Cc: Michel Thierry
> Cc: Dave Airlie
> Cc: Chris Wilson
> References:
> http:
This reverts commit 8c50f10d73b50139dcfe48bc22f2c8c7822c1983.
It's not yet solid and Dave objected to pulling the tree in its
current state.
Cc: Michel Thierry
Cc: Dave Airlie
Cc: Chris Wilson
References:
http://mid.mail-archive.com/CAPM=9ty2r1MLE=wzc-_vnsuzxvqayxiggocpsv9qop0gzpk...@mail.gma
The number of DWords should be even when doing ring emits as
command sequences require QWord alignment.
Cc: Mika Kuoppala
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_rin
On Wed, Oct 22, 2014 at 12:32:04PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Logical ports are never going to have EDID changes,
> they are used for the internal ports on MST monitors.
>
> We cache the EDIDs from these to save time at MST probe.
>
> Signed-off-by: Dave Airlie
> ---
>
On Wed, Oct 22, 2014 at 12:32:06PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This takes the tiling info from the connector and
> exposes it to userspace, as a blob object in a
> connector property.
>
> The contents of the blob is ABI.
>
> v2: add property + function documentation.
>
>
On 22/10/2014 08:35, Ville Syrjälä wrote:
On Tue, Oct 21, 2014 at 07:40:35PM +0200, Daniel Vetter wrote:
On Tue, Oct 21, 2014 at 02:58:08PM -0200, Paulo Zanoni wrote:
From: Paulo Zanoni
Otherwise, a simple "cat" to the debugfs file can make the machine use
much more power than needed, and pre
On Wed, Oct 22, 2014 at 06:37:16AM +, Cheng, Yao wrote:
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Tuesday, October 21, 2014 5:08 PM
> > To: Cheng, Yao
> > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.f
On Wed, Oct 22, 2014 at 07:11:21AM +, Cheng, Yao wrote:
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Tuesday, October 21, 2014 8:09 PM
> > To: Cheng, Yao
> > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.f
On Wed, Oct 22, 2014 at 12:23:30PM +1000, Dave Airlie wrote:
> > And kerneldoc for the non-exported functions please, preferrably with some
> > overview DOC: section to pull it all together.
>
> I'm posting v2, advice on kerneldoc required, so the functions end up
> in the right place, I don't rea
On Tue, Oct 21, 2014 at 04:02:04PM +0300, Ander Conselvan de Oliveira wrote:
> It is possible for a mode set to fail if there aren't shared DPLLS that
> match the new configuration requirement or other errors in clock
> computation. If that step is executed after disabling crtcs, in the
> failure c
On Wed, Oct 22, 2014 at 12:32:03PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> A tile group is an identifier shared by a single monitor,
> DisplayID topology has 8 bytes we can use for this, just
> use those for now until something else comes up in the
> future. We assign these to an idr an
On Tue, Oct 21, 2014 at 04:02:02PM +0300, Ander Conselvan de Oliveira wrote:
> This will be used in a follow up patch to properly release shared DPLLs
> without relying on the shared_dpll field in pipe_config.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
> drivers/gpu/drm/i915/i915_de
On Wed, Oct 22, 2014 at 12:11:24PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> These two didn't get documented properly, do so.
>
> Pointed out by Daniel.
>
> Signed-off-by: Dave Airlie
> ---
> Documentation/DocBook/drm.tmpl | 9 -
> drivers/gpu/drm/drm_crtc.c | 10
On 22 October 2014 17:05, Chris Wilson wrote:
> On Wed, Oct 22, 2014 at 09:09:43AM +1000, Dave Airlie wrote:
>> On 21 October 2014 23:38, Daniel Vetter wrote:
>> > Hi Dave,
>> >
>> > drm-intel-next-2014-10-03:
>> > - first batch of skl stage 1 enabling
>> > - fixes from Rodrigo to the PSR, fbc an
On Wed, Oct 22, 2014 at 07:09:11AM +, Cheng, Yao wrote:
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Tuesday, October 21, 2014 6:30 PM
> > To: Cheng, Yao
> > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> > Kel
On Tue, Oct 21, 2014 at 06:00:05PM +0200, Daniel Vetter wrote:
> On Fri, Oct 17, 2014 at 09:08:28AM -0700, Todd Previte wrote:
> >
> > On 10/17/2014 1:43 AM, Ville Syrjälä wrote:
> > >On Thu, Oct 16, 2014 at 12:38:55PM -0700, Todd Previte wrote:
> > >>On 10/16/2014 10:46 AM, ville.syrj...@linux.in
On 10/01/2014 12:26 AM, Tian, Kevin wrote:
From virtualization p.o.v, the ideal case is to run host i915 irq handler in
the
interrupt context, which meets all the assumption from original code. Using
tasklet or other manner still has some restriction. This is a major open we'd
like to hear more
On Tue, Oct 21, 2014 at 07:40:35PM +0200, Daniel Vetter wrote:
> On Tue, Oct 21, 2014 at 02:58:08PM -0200, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > Otherwise, a simple "cat" to the debugfs file can make the machine use
> > much more power than needed, and prevent it from runtime suspend
On Fri, Oct 17, 2014 at 11:41:13AM -0700, Todd Previte wrote:
> Reorder the function calls in chv/vlv_pre_enable_dp() such that link training
> is not initiated before the PHYs come up out of reset. Also check the status
> of vlv_wait_port_ready() and only attempt to train if the PHYs are actually
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Tuesday, October 21, 2014 8:09 PM
> To: Cheng, Yao
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Kelley,
> Sean V; Vetter, Daniel; Abel, Michael J; Jiang
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Tuesday, October 21, 2014 6:30 PM
> To: Cheng, Yao
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Kelley,
> Sean V; Vetter, Daniel; Abel, Michael J; Jiang, Fei; Rao, Ram R
> Su
On 10/22/2014 12:51 AM, Daniel Vetter wrote:
On Tue, Oct 21, 2014 at 06:16:26PM +0200, Daniel Vetter wrote:
On Fri, Oct 17, 2014 at 01:37:11PM +0800, Yu Zhang wrote:
Intel GVT-g (previously known as XenGT), is a complete GPU
virtualization solution with mediated pass-through for 4th
generatio
On Wed, Oct 22, 2014 at 09:09:43AM +1000, Dave Airlie wrote:
> On 21 October 2014 23:38, Daniel Vetter wrote:
> > Hi Dave,
> >
> > drm-intel-next-2014-10-03:
> > - first batch of skl stage 1 enabling
> > - fixes from Rodrigo to the PSR, fbc and sink crc code
> > - kerneldoc for the frontbuffer tra
Hi Daniel,
Thanks a lot for your reply. Indeed, I sent two v2 patches, because
the format of the first v2 patchset is incorrect - I forgot to add the
what changed part in those messages. :)
Yu
On 10/22/2014 12:16 AM, Daniel Vetter wrote:
On Fri, Oct 17, 2014 at 01:37:11PM +0800, Yu Zhang wro
61 matches
Mail list logo
