On Wed, Sep 25, 2013 at 07:53:13PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, September 24, 2013 05:47:31 PM Aaron Lu wrote:
> > According to Matthew Garrett, "Windows 8 leaves backlight control up
> > to individual graphics drivers rather than making ACPI calls itself.
> > There's plenty of evi
On Wed, Sep 25, 2013 at 04:58:39PM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 24 Sep 2013, Aaron Lu wrote:
> > locate handle for ACPI video by HID, the problem is, ACPI video node
> > doesn't really have HID defined(i.e. no _HID control method is defined
>
> ACPI video is supposed to atta
On Thu, Sep 26, 2013 at 12:49:37AM +0100, Chris Wilson wrote:
> On Wed, Sep 25, 2013 at 04:35:32PM -0700, Ben Widawsky wrote:
> > This allows us to keep track of the values being set if we want to tweak
> > this code.
> >
> > Signed-off-by: Ben Widawsky
> > ---
> > drivers/gpu/drm/i915/intel_pm.
On Wed, Sep 25, 2013 at 04:35:33PM -0700, Ben Widawsky wrote:
> The policy's max frequency is not equal to the CPU's max frequency. The
> ring frequency is derived from the CPU frequency, and not the policy
> frequency.
>
> One example of how this may differ through sysfs. If the sysfs max
> frequ
On Wed, Sep 25, 2013 at 04:35:32PM -0700, Ben Widawsky wrote:
> This allows us to keep track of the values being set if we want to tweak
> this code.
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/intel_pm.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gp
The policy's max frequency is not equal to the CPU's max frequency. The
ring frequency is derived from the CPU frequency, and not the policy
frequency.
One example of how this may differ through sysfs. If the sysfs max
frequency is modified, that will be used for the max ring frequency
calculation
This allows us to keep track of the values being set if we want to tweak
this code.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_pm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d27eda6..31cf188 1
On Wed, Sep 25, 2013 at 02:00:02PM +0200, Daniel Vetter wrote:
> In
>
> commit 81e49f811404f428a9d9a63295a0c267e802fa12
> Author: Glauber Costa
> Date: Wed Aug 28 10:18:13 2013 +1000
>
> i915: bail out earlier when shrinker cannot acquire mutex
>
> SHRINK_STOP was added to tell the core s
On Wed, Sep 25, 2013 at 11:00:20PM +0200, Daniel Vetter wrote:
> On Wed, Sep 25, 2013 at 10:38:33AM -0700, Jesse Barnes wrote:
> > On Mon, 23 Sep 2013 21:01:44 +0300
> > Ville Syrjälä wrote:
> >
> > > On Fri, Sep 20, 2013 at 11:29:32AM -0700, Jesse Barnes wrote:
> > > > Calculation is a little di
On Wed, Sep 25, 2013 at 02:24:01PM -0700, Jesse Barnes wrote:
> From: Chris Wilson
>
> With some divider values we end up with the wrong result. So remove the
> intermediates (like Ville suggested in the first place) to get the right
> answer.
>
> Signed-off-by: Chris Wilson
> Signed-off-by: J
On Wed, Sep 25, 2013 at 10:59 PM, Rodrigo Vivi wrote:
> Please consider to accept this for -fixes, otherwise PSR will never
> work on Haswell on 3.12.
You know the drill: A feature regressed and no one noticed, which
means we are lacking a fully automated testcase. I guess we need to
expose in de
From: Chris Wilson
With some divider values we end up with the wrong result. So remove the
intermediates (like Ville suggested in the first place) to get the right
answer.
Signed-off-by: Chris Wilson
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 8 +++-
1 file ch
Still digging up the actual VBT info for this, but wanted to get this
out there for testing, or in case others are also bugged by this.
This can happen if you boot with an external display connected. In that
case, the attached eDP backlight modulation frequency may not be
programmed, so we need t
On Wed, Sep 25, 2013 at 10:38:33AM -0700, Jesse Barnes wrote:
> On Mon, 23 Sep 2013 21:01:44 +0300
> Ville Syrjälä wrote:
>
> > On Fri, Sep 20, 2013 at 11:29:32AM -0700, Jesse Barnes wrote:
> > > Calculation is a little different than other platforms.
> > >
> > > v2: update to use port_clock ins
Hi Daniel,
Please consider to accept this for -fixes, otherwise PSR will never
work on Haswell on 3.12.
Thanks,
Rodrigo.
On Wed, Sep 25, 2013 at 5:51 PM, Rodrigo Vivi wrote:
> Power Well in use forces constantly PSR to exit.
> On recent Kernel I noticed that PSR Performance Counter was always 0
Power Well in use forces constantly PSR to exit.
On recent Kernel I noticed that PSR Performance Counter was always 0
indicating that PSR was never really achieved.
By masking LPSP, PSR can work normally and save power on Haswell.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c |
On Wed, Sep 25, 2013 at 07:55:26PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The old style frame counter increments at the start of active video.
> However for i915_get_vblank_counter() we want a counter that increments
> at the start of vblank.
>
> Fortunately the lo
On Wed, Sep 25, 2013 at 08:18:39PM +0300, Jani Nikula wrote:
> On Wed, 25 Sep 2013, Jesse Barnes wrote:
> > Still digging up the actual VBT info for this, but wanted to get this
> > out there for testing, or in case others are also bugged by this.
>
> I had a look at this a few weeks back. The VB
On Wed, 25 Sep 2013 20:18:39 +0300
Jani Nikula wrote:
> On Wed, 25 Sep 2013, Jesse Barnes wrote:
> > Still digging up the actual VBT info for this, but wanted to get this
> > out there for testing, or in case others are also bugged by this.
>
> I had a look at this a few weeks back. The VBT val
On Tuesday, September 24, 2013 05:47:31 PM Aaron Lu wrote:
> According to Matthew Garrett, "Windows 8 leaves backlight control up
> to individual graphics drivers rather than making ACPI calls itself.
> There's plenty of evidence to suggest that the Intel driver for
> Windows [8] doesn't use the AC
On Mon, 23 Sep 2013 21:01:44 +0300
Ville Syrjälä wrote:
> On Fri, Sep 20, 2013 at 11:29:32AM -0700, Jesse Barnes wrote:
> > Calculation is a little different than other platforms.
> >
> > v2: update to use port_clock instead
> > rebase on top of Ville's changes
> > v3: update to new port_clo
On Wed, 25 Sep 2013 20:18:39 +0300
Jani Nikula wrote:
> On Wed, 25 Sep 2013, Jesse Barnes wrote:
> > Still digging up the actual VBT info for this, but wanted to get this
> > out there for testing, or in case others are also bugged by this.
>
> I had a look at this a few weeks back. The VBT val
On Wed, 25 Sep 2013, Jesse Barnes wrote:
> Still digging up the actual VBT info for this, but wanted to get this
> out there for testing, or in case others are also bugged by this.
I had a look at this a few weeks back. The VBT value for max backlight
is in Hz (as is the value you get through opr
On Wed, Sep 25, 2013 at 01:42:21PM +0200, Daniel Vetter wrote:
> On Tue, Sep 24, 2013 at 09:58:00AM -0700, Ben Widawsky wrote:
> > From: Ben Widawsky
> >
> > Building on the last patch which created the new function pointers in
> > the VM for bind/unbind, here we actually put those new function p
On Wed, Sep 25, 2013 at 10:11:35AM -0700, Ben Widawsky wrote:
> On Wed, Sep 25, 2013 at 05:05:15PM +0200, Daniel Vetter wrote:
> > Otherwise we can die in a fire of not-yet-allocated lazy requests when
> > we expect them to be there:
>
> And Chris accuses me of violating Rusty's rules. This is an
When we switched to always using a timeout in conjunction with
wait_seqno, we lost the ability to detect missed interrupts. Since, we
have had issues with interrupts on a number of generations, and they are
required to be delivered in a timely fashion for a smooth UX, it is
important that we do log
After applying wait-boost we often find ourselves stuck at higher clocks
than required. The current threshold value requires the GPU to be
continuously and completely idle for 313ms before it is dropped by one
bin. Conversely, we require the GPU to be busy for an average of 90% over
a 84ms period b
On Wed, Sep 25, 2013 at 05:05:15PM +0200, Daniel Vetter wrote:
> Otherwise we can die in a fire of not-yet-allocated lazy requests when
> we expect them to be there:
And Chris accuses me of violating Rusty's rules. This is an extremely
ugly caveat to put in an interface given that active tracking
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do n
From: Ville Syrjälä
The old style frame counter increments at the start of active video.
However for i915_get_vblank_counter() we want a counter that increments
at the start of vblank.
Fortunately the low frame counter register also contains the pixel
counter for the current frame. We can can co
Hi,
So this series looks like a good candidate to be merged in one tree.
Beside the new 3d flags added to the mode structure, the other new API
is the SET_CLIENT_CAP ioctl. It seems that this new ioctl could already
be potentially useful for user space to tell us they want the "primary"
plane exp
Still digging up the actual VBT info for this, but wanted to get this
out there for testing, or in case others are also bugged by this.
This can happen if you boot with an external display connected. In that
case, the attached eDP backlight modulation frequency may not be
programmed, so we need t
On Wed, 25 Sep 2013, Jörg Otte wrote:
> 2013/9/25 Jani Nikula :
>> On Wed, 25 Sep 2013, Aaron Lu wrote:
>>> On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote:
Backlight can't be modified with this patch set - neither with
function keys nor with the gui. It is a step backward to
2013/9/25 Jani Nikula :
> On Wed, 25 Sep 2013, Aaron Lu wrote:
>> On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote:
>>> Backlight can't be modified with this patch set - neither with
>>> function keys nor with the gui. It is a step backward to v3.11-rc1
>
> So both hotkeys and GUI work in
Now that we ask to adjust the crtc timings for stereo modes, the correct
pipe_src_w and pipe_src_h can be found in crtc_vdisplay and crtc_hdisplay.
v2: Add comment about why pipe_src_w/h need to be set afert
set_crtcinfo() (Daniel Vetter)
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lesp
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_hdmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1a57758..6004f9c 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/dr
struct drm_mode_display now has a separate crtc_ version of the clock to
be used when we're talking about the timings given to the harwadre (was
far as the mode is concerned).
This commit is really the result of a git grep adjusted_mode.*clock and
replacing those by adjusted_mode.crtc_clock. No fu
When scanning out big stereo buffers that are actually bigger that their
natural 2D counterpart, we need to blow up the crtc timings as well.
Not that this is only done for frame packing as this is the only stereo
mode currently exposed needing this kind of ajdustements.
Reviewed-by: Ville Syrjäl
When using the frame packing and a single big framebuffer, some hardware
requires that we do everything like if we were scanning out the big
buffer itself. Let's instrument drm_mode_set_crtcinfo() to be able to do
this adjustement if the driver is asking for it.
v2: Use crtc_vtotal and multiply th
We want to dump the parameters given to the hardware, so let's use
crtc_clock here.
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drive
Just like the various timings, make it possible to have a clock field
what we can tweak before giving it to hardware.
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_modes.c | 1 +
include/drm/drm_crtc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a
This field was only accessed by the nouveau driver, but never set. So
concluded we can rid of this one.
Acked-by: Ben Skeggs
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 2 --
include/drm/drm_crtc.h | 1 -
2 files chang
Some stereo modes, like frame packing, need a larger CRTC viewport than
the "natural" underlying 2D mode and thus drm_crtc_check_viewport()
needs to query the adjusted mode to use the correct h/vdisplay.
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc.c | 8
Both setcrtc and page_flip are checking that the framebuffer is big
enough for the defined crtc viewport (x, y, hdisplay, vdisplay). Factor
that code out in a single function.
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc.c | 70 --
This field is unused. Garbage collect it.
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
include/drm/drm_crtc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 011baaa..8e9716e 100644
--- a/include/drm/drm_crtc.h
+++ b/inclu
This allows to expose the alternate clock versions of the stereo modes.
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 48f1746..c24af1d 1
Just like with interlaced or double scan modes, make stereo modes a
per-connector opt-in to give a chance to driver authors to make it work
before enabling it.
Suggested-by: Daniel Vetter
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc_helper.c | 8 +++
When scanning out a 3D mode on HDMI, we need to send an HDMI infoframe
with the corresponding layout to the sink.
v2: Make s3d_structure_from_display_mode() less subtle (Ville Syrjälä)
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 40
When scanning out a stereo mode, the AVI infoframe vic field has to be
the underlyng 2D VIC. Before that commit, we weren't matching the CEA
mode because of the extra stereo flag and then were setting the VIC
field in the AVI infoframe to 0.
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespia
When setting a stereo 3D mode, there can be only one bit set describing
the layout of the frambuffer(s). So reject invalid modes early.
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm
For now, let's just look at the 3D_present flag of the CEA HDMI vendor
block to detect if the sink supports a small list of then mandatory 3D
formats.
See the HDMI 1.4a 3D extraction for detail:
http://www.hdmi.org/manufacturer/specification.aspx
v2: Rename freq to vrefresh, make the mandatory
So we respect a nice design of having similar functions at the same
level, in this case:
do_hdmi_vsdb_modes()
- add_hdmi_mandatory_stereo_modes()
- add_hdmi_mode()
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 36 +
This capability allows user space to control the delivery of modes with
the 3D flags set. This is to not play games with current user space
users not knowing anything about stereo 3D flags and that could try
to set a mode with one or several of those bits set.
So, the plan is to remove the stereo
HDMI 1.4a defines a few layouts that we'd like to expose. This commits
add new modeinfo flags that can be used to list the supported stereo
layouts (when querying the list of modes) and to set a given stereo 3D
mode (when setting a mode).
v2: Add a drm_mode_is_stereo() helper
Reviewed-by: Ville S
This ioctl can be used to turn some knobs in a DRM driver. The client
can ask the DRM core for an alternate view of the reality: it can be
useful to be able to instruct the core that the DRM client can handle
new functionnality that would otherwise break current ABI.
v2: Rename to ioctl from SET_C
It's a tiny bit more logical to find the different capabilities you can
use with the GET_CAP ioctl next to the structure rather than putting
them at the end of the file.
v2: Tab align the litterals (David Herrmann)
v3: Make it clearer that DRM_PRIME_CAP_EXPORT/IMPORT are flags of
DRM_CAP_PRIME
v5 was:
http://lists.freedesktop.org/archives/dri-devel/2013-September/045576.html
Changes from v5:
- Added a size check on frame packing fbs
- Addressed the various reviews
- All the patches now have r-b tags
--
Damien
___
Intel-gfx mailing l
On Wed, 25 Sep 2013 10:49:36 +0300
Ville Syrjälä wrote:
> The preempt_disable/enable is not needed. The spinlock serves the same
> purpose already.
As stated, that was only for the -rt patch, as spin_lock_irqsave does
not disable preemption nor does it even disable interrupts.
But I agree, th
Sorry for the late reply, I was at Linux Plumbers, and had a bunch of
stuff to catch up on when I returned.
On Sat, 21 Sep 2013 00:07:36 +0200
Mario Kleiner wrote:
> Steven, would it then be acceptable to convert that "faster" lock into a
> raw_spinlock_t or is this unacceptable? If so, the
On Wed, 25 Sep 2013 06:32:10 +0200
Mario Kleiner wrote:
> But given the new situation, your proposal is great! If we push the
> clock readouts into the get_scanoutpos routine, we can make this robust
> without causing grief for the rt people and without the need for a new
> separate lock for
On Wed, 25 Sep 2013 06:32:10 +0200
Mario Kleiner wrote:
> I assume if a spin_lock_irqsave doesn't really disable interrupts on a
> RT kernel with normal spinlocks then local_irq_disable won't really
> disable interrupts either?
>
That is incorrect. On PREEMPT_RT, you are right about
spin_loc
Backlight can't be modified with this patch set - neither with function
keys nor
with the gui. It is a step backward to v3.11-rc1
Video driver: i915
FUJITSU LIFEBOOK AH532/FJNBB1C, BIOS Version 1.09 05/22/2012
acpi_backlight=video works.
Jörg
2013/9/24 Igor Gnatenko
> On Tue, 2013-09-24 at
Otherwise we can die in a fire of not-yet-allocated lazy requests when
we expect them to be there:
[ 4405.463113] [ cut here ]
[ 4405.464769] kernel BUG at
/home/user/src/linux/drivers/gpu/drm/i915/intel_ringbuffer.h:268!
[ 4405.466392] invalid opcode: [#1] PREEMPT SM
Otherwise we can die in a fire of not-yet-allocated lazy requests when
we expect them to be there:
[ 4405.463113] [ cut here ]
[ 4405.464769] kernel BUG at
/home/user/src/linux/drivers/gpu/drm/i915/intel_ringbuffer.h:268!
[ 4405.466392] invalid opcode: [#1] PREEMPT SM
In
commit 81e49f811404f428a9d9a63295a0c267e802fa12
Author: Glauber Costa
Date: Wed Aug 28 10:18:13 2013 +1000
i915: bail out earlier when shrinker cannot acquire mutex
SHRINK_STOP was added to tell the core shrinker code to bail out and
go to the next shrinker since the i915 shrinker coul
On Tue, Sep 24, 2013 at 09:58:00AM -0700, Ben Widawsky wrote:
> From: Ben Widawsky
>
> Building on the last patch which created the new function pointers in
> the VM for bind/unbind, here we actually put those new function pointers
> to use.
>
> Split out as a separate patch to aid in review. I'
On Wed, Sep 25, 2013 at 02:29:34PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 25, 2013 at 11:43:28AM +0100, Chris Wilson wrote:
> > So that we can find the callers who introduce a ring stall. A single
> > ring stall is not too unwelcome, the right issue becomes when they start
> > to interlock and p
On Wed, Sep 25, 2013 at 11:43:28AM +0100, Chris Wilson wrote:
> So that we can find the callers who introduce a ring stall. A single
> ring stall is not too unwelcome, the right issue becomes when they start
> to interlock and prevent any concurrent work. That, however, is a little
> tricker to det
So that we can find the callers who introduce a ring stall. A single
ring stall is not too unwelcome, the right issue becomes when they start
to interlock and prevent any concurrent work. That, however, is a little
tricker to detect with a mere tracepoint!
v2: Rebrand it as a ring event, rather th
On Wed, 25 Sep 2013, Aaron Lu wrote:
> On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote:
>> Backlight can't be modified with this patch set - neither with
>> function keys nor with the gui. It is a step backward to v3.11-rc1
So both hotkeys and GUI work in v3.11-rc1? And v3.12-rc2?
> Th
On Wed, Sep 25, 2013 at 12:14:44PM +0200, Daniel Vetter wrote:
> On Wed, Sep 25, 2013 at 10:23:19AM +0100, Chris Wilson wrote:
> > Add the missing cache-level to the describe_obj() function for debug and
> > error reporting.
> >
> > Signed-off-by: Chris Wilson
>
> Merged to dinq ...
>
> > ---
>
On Wed, Sep 25, 2013 at 10:23:19AM +0100, Chris Wilson wrote:
> Add the missing cache-level to the describe_obj() function for debug and
> error reporting.
>
> Signed-off-by: Chris Wilson
Merged to dinq ...
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/i915_gpu_e
On Wed, Sep 25, 2013 at 12:34:37PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 23, 2013 at 05:33:26PM -0300, Rodrigo Vivi wrote:
> > From: Chris Wilson
> >
> > So that we can find the callers who introduce a ring stall. A single
> > ring stall is not too unwelcome, the right issue becomes when they
Add the missing cache-level to the describe_obj() function for debug and
error reporting.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/
On Mon, Sep 23, 2013 at 05:33:26PM -0300, Rodrigo Vivi wrote:
> From: Chris Wilson
>
> So that we can find the callers who introduce a ring stall. A single
> ring stall is not too unwelcome, the right issue becomes when they start
> to interlock and prevent any concurrent work. That, however, is
On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote:
> Backlight can't be modified with this patch set - neither with function
> keys nor
> with the gui. It is a step backward to v3.11-rc1
Thanks for the test.
Please check /sys/class/backlight, is there only one link file
intel_backlight?
On Wed, Sep 25, 2013 at 11:11:30AM +0300, Ville Syrjälä wrote:
> On Wed, Sep 25, 2013 at 05:12:54AM +0200, Mario Kleiner wrote:
> > This one i don't know. I think i can't follow the logic, but i don't
> > know enough about the way the intel hw counts.
> >
> > Do you mean the counter increments wh
Hi,
Is it okay to integrate this patch at first?
We can check whether vblank wait can be removed safely later
Thanks
Mengdong
> -Original Message-
> From: Lin, Mengdong
> Sent: Tuesday, September 24, 2013 1:01 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Arora, MukeshX; Lin, Mengdong
Hi Daniel,
Thanks for your advice!
Would you help working on this patch? Or can I continue after a few days, I
have some Android support task these days.
Regards
Mengdong
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Tuesda
On Wed, Sep 25, 2013 at 03:47:51PM +0800, Chon Ming Lee wrote:
> Fix the typo in previous commit for DP 1.62 divisor.
> drm/i915: Move Valleyview DP DPLL divisor calc to intel_dp_set_clock v2
>
> v2: sigh, the m1 div is 3.
>
> Reported-by: Jesse Barnes
> Signed-off-by: Chon Ming Lee
Ok, I'll
On Wed, Sep 25, 2013 at 09:56:52AM +0200, Daniel Vetter wrote:
> On Wed, Sep 25, 2013 at 01:17:52PM +1000, Dave Airlie wrote:
> > On Mon, Sep 23, 2013 at 12:14 AM, Michael S. Tsirkin
> > wrote:
> > > On Mon, Aug 26, 2013 at 04:05:11PM +0300, Michael S. Tsirkin wrote:
> > >> On Wed, Aug 21, 2013 a
On Wed, Sep 25, 2013 at 04:35:56AM +0200, Mario Kleiner wrote:
> On 23.09.13 13:48, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We have all the information we need in the mode structure, so going and
> > reading it from the hardware is pointless, and slower.
> >
> > We nev
On Wed, Sep 25, 2013 at 05:12:54AM +0200, Mario Kleiner wrote:
>
>
> On 23.09.13 12:02, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The DSL register increments at the start of horizontal sync, so it
> > manages to miss the entire active portion of the current line.
> >
>
On Wed, Sep 25, 2013 at 03:36:52PM +0800, Chon Ming Lee wrote:
> Fix the typo in previous commit for DP 1.62 divisor.
>
> drm/i915: Move Valleyview DP DPLL divisor calc to intel_dp_set_clock v2
>
> Reported-by: Jesse Barnes
> Signed-off-by: Chon Ming Lee
Ville just submitted the same patch so
On Wed, Sep 25, 2013 at 01:17:52PM +1000, Dave Airlie wrote:
> On Mon, Sep 23, 2013 at 12:14 AM, Michael S. Tsirkin wrote:
> > On Mon, Aug 26, 2013 at 04:05:11PM +0300, Michael S. Tsirkin wrote:
> >> On Wed, Aug 21, 2013 at 11:22:58AM +0200, Sedat Dilek wrote:
> >> > [ Re: [Intel-gfx] i915 produci
On Wed, Sep 25, 2013 at 6:45 AM, Mario Kleiner
wrote:
>
>> Mario, can you please take a look at these patches and ack them? I'd like
>> to slurp them in for -next.
>
>
> Done in the other e-mails, with some comments. However, i'd like to test
> these a bit and it might take a week or two before i
On Wed, Sep 25, 2013 at 06:32:10AM +0200, Mario Kleiner wrote:
> On 23.09.13 10:38, Ville Syrjälä wrote:
> > On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote:
> >> On 09/17/2013 10:55 PM, Daniel Vetter wrote:
> >>> On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley
> >>> wrote:
> On
Fix the typo in previous commit for DP 1.62 divisor.
drm/i915: Move Valleyview DP DPLL divisor calc to intel_dp_set_clock v2
v2: sigh, the m1 div is 3.
Reported-by: Jesse Barnes
Signed-off-by: Chon Ming Lee
---
drivers/gpu/drm/i915/intel_dp.c |2 +-
1 files changed, 1 insertions(+), 1 del
From: Ville Syrjälä
Use the recommended PLL dividers from
VLV2_DPLL_mphy_hsdpll_frequency_table_ww6_rev1p1.xlsm. The previous
values were really bogus. The 2.7 values look good however.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 d
Fix the typo in previous commit for DP 1.62 divisor.
drm/i915: Move Valleyview DP DPLL divisor calc to intel_dp_set_clock v2
Reported-by: Jesse Barnes
Signed-off-by: Chon Ming Lee
---
drivers/gpu/drm/i915/intel_dp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/dri
On Wed, Sep 25, 2013 at 07:14:34AM +0800, Lee, Chon Ming wrote:
> On 09/24 18:18, Ville Syrjälä wrote:
> > On Tue, Sep 24, 2013 at 03:14:27PM +0800, Chon Ming Lee wrote:
> > > Without the DPIO cmnreset, the PLL fail to lock. This should have
> > > done by BIOS.
> > >
> > > v2: Move this to intel_
91 matches
Mail list logo
