Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
> Add enable/disable flip done functions and the flip done handler
> function which handles the flip done interrupt.
>
> Enable the flip done interrupt in IER.
>
> Enable flip done function is called before writing the
> surface address
Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
> Set the Async Address Update Enable bit in plane ctl
> when async flip is requested.
>
> v2: -Move the Async flip enablement to individual patch (Paulo)
>
> v3: -Rebased.
>
> v4: -Add separate plane hook for async flip case (Ville)
>
>
Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
> Without async flip support in the kernel, fullscreen apps where game
> resolution is equal to the screen resolution, must perform an extra blit
> per frame prior to flipping.
>
> Asynchronous page flips will also boost the FPS of Mesa
niLake until a solution is found.
> >
> > Buglink: https://bugs.freedesktop.org/show_bug.cgi?id=108085
> > Signed-off-by: Daniel Drake
> > Signed-off-by: Jian-Hong Pan
>
> Fixes: fd7d6c5c8f3e ("drm/i915: enable FBC on gen9+ too") ?
> Cc: Paulo Zanoni
> Cc: Danie
Em Qua, 2018-09-12 às 09:31 -0500, Gustavo A. R. Silva escreveu:
> Function intel_port_to_tc() returns PORT_TC_NONE on error, which is
> a negative value -1. In case PORT_TC_NONE is returned, there is an
> undefined behavior when shifting by a negative number of bits in
> both
"(an unmatched left parenthesis
creates an unresolved tension
that will stay with you all day."
-- Randall Munroe
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/drm_dp_helper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drive
Em Qua, 2018-04-25 às 17:29 -0700, Michel Thierry escreveu:
> On 04/25/2018 05:09 PM, Paulo Zanoni wrote:
> > Add the PCI IDs and the basic code to enable ICL. This is the
> > current
> > PCI ID list in our documentation.
> >
> > Kernel commit: d55cb4fa2cf0 (&
according to bspec
and keep them in the same order and rebase (Lucas)
Cc: Michel Thierry <michel.thie...@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zan...@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
Signed-off-by: Lucas De Marchi <lucas
Em Qua, 2017-01-04 Ã s 20:42 +0200, ville.syrjala at linux.intel.com
escreveu:
> From: Ville Syrjälä
>
> SKL+ display engine can scan out certain kinds of compressed surfaces
> produced by the render engine. This involved telling the display
> engine
> the location of the color control surfae
Em Qui, 2016-11-03 às 18:49 +0200, Ville Syrjälä escreveu:
> On Mon, Oct 17, 2016 at 02:37:16PM +0200, Maarten Lankhorst wrote:
> >
> > Signed-off-by: Maarten Lankhorst > >
> > ---
> > Â drivers/gpu/drm/i915/intel_pm.c | 12 ++--
> > Â 1 file changed, 6 insertions(+), 6 deletions(-)
>
Em Qui, 2016-11-03 às 18:45 +0200, Ville Syrjälä escreveu:
> On Mon, Oct 17, 2016 at 02:37:15PM +0200, Maarten Lankhorst wrote:
> >
> > Signed-off-by: Maarten Lankhorst > >
> > ---
> > Â drivers/gpu/drm/i915/intel_fbc.c | 6 +++---
> > Â 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> >
need this function to be reusable for the next patch.
>
> Changes since v1:
> - Fix accidental behavior change in the code that Paulo pointed out
Reviewed-by: Paulo Zanoni
I just submitted v4 of patch 5 solving the conflicts I created. With
that + this review, we can merge this series. If you
Em Qui, 2016-10-13 Ã s 18:15 -0300, Paulo Zanoni escreveu:
> Em Sex, 2016-10-07 Ã s 20:11 -0400, Lyude escreveu:
> >
> > Thanks to Paulo Zanoni for indirectly pointing this out.
> >
> > Looks like we never actually added any code for checking whether or
> > no
Em Sex, 2016-10-07 Ã s 20:11 -0400, Lyude escreveu:
Bikesheding: it would be nice to write a commit message explaining why,
even if the message just tells the user to read
Documentation/CodingStyle.
Reviewed-by: Paulo Zanoni
> Signed-off-by: Lyude
> Cc: Maarten Lankhorst
> Cc: Ville
Em Sex, 2016-10-07 Ã s 20:11 -0400, Lyude escreveu:
> Thanks to Paulo Zanoni for indirectly pointing this out.
>
> Looks like we never actually added any code for checking whether or
> not
> we actually wrote watermark levels properly. Let's fix that.
Thanks for doing this!
Rev
Em Sex, 2016-10-07 Ã s 20:11 -0400, Lyude escreveu:
> Helper we're going to be using for implementing verification of the
> wm
> levels in skl_verify_wm_level().
>
> Signed-off-by: Lyude
Reviewed-by: Paulo Zanoni
> Cc: Maarten Lankhorst
> Cc: Ville Syrjälä
> Cc:
need this function to be reusable for the next patch.
>
> Signed-off-by: Lyude
> Cc: Maarten Lankhorst
> Cc: Ville Syrjälä
> Cc: Paulo Zanoni
> ---
> Â drivers/gpu/drm/i915/intel_drv.h |Â Â 2 ++
>  drivers/gpu/drm/i915/intel_pm.c  | 27 +--
> Â 2
> Cc: Ville Syrjälä
> Cc: Paulo Zanoni
> ---
> Â drivers/gpu/drm/i915/intel_pm.c | 57
> +
> Â 1 file changed, 57 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 5
Em Qui, 2016-10-13 Ã s 17:04 -0300, Paulo Zanoni escreveu:
> Em Qui, 2016-10-13 Ã s 15:39 +0200, Maarten Lankhorst escreveu:
> >
> > Op 08-10-16 om 02:11 schreef Lyude:
> > >
> > >
> > > Now that we've make skl_wm_levels make a little more sense, we
&
nce v1:
> > - Fixup skl_write_wm_level()
> > - Fixup skl_wm_level_from_reg_val()
> > - Don't forget to copy *active to intel_crtc->wm.active.skl
> >
> > Signed-off-by: Lyude
> > Reviewed-by: Maarten Lankhorst
> > Cc: Ville Syrjälä
> > Cc: Paulo Za
ing more meaningful.
Reviewed-by: Paulo Zanoni
>
> (adding Maarten's reviewed-by since this is just a split-up version
> of one
> of the previous patches)
>
> Signed-off-by: Lyude
> Reviewed-by: Maarten Lankhorst
> Cc: Ville Syrjälä
> Cc: Paulo Zanoni
down on all of the copy paste code in here.
>
> Changes since v1:
> - Style nitpicks
> - Fix accidental usage of i vs. PLANE_CURSOR
> - Split out skl_pipe_wm_active_state simplification into separate
> patch
>
> Signed-off-by: Lyude
Reviewed-by: Paulo Zanoni
> Revi
ocations active on hardware into intel_crtc.
>
> Changes since v1:
> - Don't replace alloc->start = alloc->end = 0;
>
> Signed-off-by: Lyude
Reviewed-by: Paulo Zanoni
> Reviewed-by: Maarten Lankhorst
> Cc: Ville Syrjälä
> Cc: Paulo Zanoni
> ---
> Â driv
Em Qua, 2016-10-05 Ã s 11:33 -0400, Lyude escreveu:
> Now that we've make skl_wm_levels make a little more sense, we can
> remove all of the redundant wm information. Up until now we'd been
> storing two copies of all of the skl watermarks: one being the
> skl_pipe_wm structs, the other being the
Em Qua, 2016-10-05 Ã s 11:33 -0400, Lyude escreveu:
> Having skl_wm_level contain all of the watermarks for each plane is
> annoying since it prevents us from having any sort of object to
> represent a single watermark level, something we take advantage of in
> the next commit to cut down on all
Em Qua, 2016-10-05 Ã s 11:33 -0400, Lyude escreveu:
> Next part of cleaning up the watermark code for skl. This is easy,
> since
> it seems that we never actually needed to keep track of the linetime
> in
> the skl_wm_values struct anyway.
Reviewed-by: Paulo Zanoni
>
>
Em Qua, 2016-10-05 Ã s 11:33 -0400, Lyude escreveu:
> First part of cleaning up all of the skl watermark code. This moves
> the
> structures for storing the ddb allocations of each pipe into
> intel_crtc_state, along with moving the structures for storing the
> current ddb allocations active on
Em Qua, 2016-10-05 Ã s 11:33 -0400, Lyude escreveu:
> This option allows us to manually control the SAGV at module load
> time.
> This can be useful in situations such as trying to debug watermark
> changes, since enabled SAGV + incorrect watermarks = total GPU
> annihilation.
I'm not a huge fan
ilosophy in mind.
> Reviewed-by: Emil Velikov
>
> -Emil
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Paulo Zanoni
2015-11-19 18:06 GMT-02:00 Ville Syrjälä :
> On Thu, Nov 19, 2015 at 05:44:51PM -0200, Paulo Zanoni wrote:
>> 2014-05-26 11:26 GMT-03:00 :
>> > From: Ville Syrjälä
>> >
>> > Now that the vblank races are plugged, we can opt out of using
>> >
v->driver->get_vblank_timestamp = i915_get_vblank_timestamp;
> dev->driver->get_scanout_position = i915_get_crtc_scanoutpos;
> --
> 1.8.5.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
gt; - Updated commit message
>> V10:
>> - Updated for versioning and patch swizzle
>> - Revised the title to more accurately reflect the nature and contents of
>> the patch
>> - Fixed formatting/whitespace problems
>> - Added set flag when computed checksum is invalid
ic
> V5:
> - Updated the for-loop to add the number of i2c defers to the retry
> counter such that the correct number of retry attempts will be
> made
>
> Signed-off-by: Todd Previte
> Cc: dri-devel at lists.freedesktop.org
Reviewed-by: Paulo Zanoni
(although
ance testing - * Displayport Link CTS Core 1.2 rev1.1 4.2.2.6
> +*/
> + bool edid_header_corrupt;
> +
> struct dentry *debugfs_entry;
>
> struct drm_connector_state *state;
> @@ -1443,7 +1448,8 @@ extern void drm_set_preferred_mode(struct drm_connector
> *connector,
>int hpref, int vpref);
>
> extern int drm_edid_header_is_valid(const u8 *raw_edid);
> -extern bool drm_edid_block_valid(u8 *raw_edid, int block, bool
> print_bad_edid);
> +extern bool drm_edid_block_valid(u8 *raw_edid, int block, bool
> print_bad_edid,
> +bool *header_corrupt);
> extern bool drm_edid_is_valid(struct edid *edid);
>
> extern struct drm_tile_group *drm_mode_create_tile_group(struct drm_device
> *dev,
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Paulo Zanoni
ayport Link CTS Core 1.2 rev1.1 4.2.2.6
> +*/
> + bool edid_header_corrupt;
> +
> struct dentry *debugfs_entry;
>
> struct drm_connector_state *state;
> @@ -1443,7 +1448,8 @@ extern void drm_set_preferred_mode(struct drm_connector
> *connector,
>int hpref, int vpref);
>
> extern int drm_edid_header_is_valid(const u8 *raw_edid);
> -extern bool drm_edid_block_valid(u8 *raw_edid, int block, bool
> print_bad_edid);
> +extern bool drm_edid_block_valid(u8 *raw_edid, int block, bool
> print_bad_edid,
> +bool *header_corrupt);
> extern bool drm_edid_is_valid(struct edid *edid);
>
> extern struct drm_tile_group *drm_mode_create_tile_group(struct drm_device
> *dev,
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
dentry *debugfs_entry;
>
> struct drm_connector_state *state;
> @@ -1436,7 +1441,8 @@ extern void drm_set_preferred_mode(struct drm_connector
> *connector,
>int hpref, int vpref);
>
> extern int drm_edid_header_is_valid(const u8 *raw_edid);
> -extern bool drm_edid_block_valid(u8 *raw_edid, int block, bool
> print_bad_edid);
> +extern bool drm_edid_block_valid(u8 *raw_edid, int block, bool
> print_bad_edid, bool *header_corrupt);
> +
> extern bool drm_edid_is_valid(struct edid *edid);
>
> extern struct drm_tile_group *drm_mode_create_tile_group(struct drm_device
> *dev,
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Paulo Zanoni
2015-04-08 18:43 GMT-03:00 Todd Previte :
>
>
> On 4/8/2015 9:51 AM, Paulo Zanoni wrote:
>>
>> 2015-03-31 14:15 GMT-03:00 Todd Previte :
>>>
>>> Displayport compliance test 4.2.2.6 requires that a source device be
>>> capable of detecting
>>>
clude/drm/drm_edid.h
> @@ -388,4 +388,9 @@ struct edid *drm_do_get_edid(struct drm_connector
> *connector,
> size_t len),
> void *data);
>
> +/* Check for corruption in raw EDID header - Displayport compliance
> + * Displayport Link CTS Core 1.2 rev1.1 - 4.2.2.6
> + */
> +bool drm_raw_edid_header_corrupt(void);
> +
> #endif /* __DRM_EDID_H__ */
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
gt; + retry--;
> usleep_range(400, 500);
> continue;
>
> --
> 1.9.1
>
> _______
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Paulo Zanoni
Shouldn't we count each error in separate? Or maybe
just loop up to 14 times, in case that doesn't violate any spec (I
didn't check)?
> usleep_range(400, 500);
> continue;
>
> --
> 1.9.1
>
> _
eedesktop.org
Why in some logs there is in fact a newline, such as here:
https://bugs.freedesktop.org/attachment.cgi?id=110049 ?
Anyway, it looks correct, so:
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/drm_dp_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
2014-12-08 12:17 GMT-02:00 Daniel Vetter :
> On Mon, Dec 08, 2014 at 10:32:49AM -0200, Paulo Zanoni wrote:
>> 2014-12-08 6:42 GMT-02:00 Daniel Vetter :
>> > On Sun, Dec 07, 2014 at 07:29:17PM +0100, Rickard Strandqvist wrote:
>> >> Remove the function intel_output_na
..
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
From: Paulo Zanoni <paulo.r.zan...@intel.com>
This way, the Kernel users will be able to fully control the lifetime
of struct drm_vblank_wait_item, and they will also be able to wrap it
to store their own information. As a result, one less memory
allocation will happen, and the Kernel co
From: Paulo Zanoni <paulo.r.zan...@intel.com>
Which means the list doesn't really need to know if the event is from
user space or kernel space.
The only place here where we have to break the abstraction is at
drm_fops, when we're releasing all the events associated with a
file_priv. H
From: Paulo Zanoni <paulo.r.zan...@intel.com>
Now that we have created drm_vblank_wait_item, let's use it as the
type passed. In the future, callers will have to use container_of to
find our their original allocated structure, just like we're doing
with the send_vblank_event() callback.
From: Paulo Zanoni <paulo.r.zan...@intel.com>
Store the wanted sequence in the wait_item instead of storing it in
the event structure that is eventually going to be sent to user space.
The plan is to make Kernel vblank wait items not have the user space
event, so we need to store the
From: Paulo Zanoni <paulo.r.zan...@intel.com>
It's supposed to contain all the information that is required for both
kernel and user space vblank wait items, but not hold any information
required by just one of them.
For now, we just moved the struct members from one place to a
From: Paulo Zanoni <paulo.r.zan...@intel.com>
This is going to be needed by i915.ko, and I guess other drivers could
use it too.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/drm_irq.c | 46 -
drivers/gpu/drm/i915/i915_debugfs.
From: Paulo Zanoni <paulo.r.zan...@intel.com>
The i915.ko driver needs a way to schedule certain functions to run
after some amount of vblanks. There are many different pieces of the
driver which could benefit from that.
Since what we want is essentially the vblank ioctl, this patc
From: Paulo Zanoni <paulo.r.zan...@intel.com>
The drivers need a way to schedule functions to be ran after a certain
number of vblanks. The i915.ko driver has plenty of examples where
this could be used, such as for unpinning buffers after a modeset.
Since the vblank wait IOCTL does bas
From: Paulo Zanoni <paulo.r.zan...@intel.com>
Hi
---
TL;DR summary:
I wrote patches. Help me choose the best implementation and interface.
---
So the i915.ko driver could use some mechanism to run functions after a given
number of vblanks. Implementations for this mechanism were a
urn 0;
> }
>
> static int
> @@ -1339,7 +1351,12 @@ intel_update_plane(struct drm_plane *plane, struct
> drm_crtc *crtc,
> if (ret)
> return ret;
>
> - return intel_commit_sprite_plane(plane, );
> + ret = intel_prepare_sprite_plane(plane, );
> + if (ret)
> + return ret;
> +
> + intel_commit_sprite_plane(plane, );
> + return 0;
> }
>
> static int
> --
> 1.9.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
et,
> --
> 1.9.1
>
> _______
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
2014-09-24 16:55 GMT-03:00 Daniel Vetter :
> Paulo Zanoni reported a lockdep splat with a locking inversion between
> fpriv->fbs_lock and the modeset locks. This issue was introduced in
>
> commit f2b50c1161590c3bcdbf3455fe4c575f1c1bd293
> Author: Daniel Vetter
> Date: Fri
2014-06-05 1:01 GMT-03:00 Dave Airlie :
> From: Dave Airlie
>
> This adds DP 1.2 MST support on Haswell systems.
Hi
It looks like drm-intel-nightly now includes this patch. It actually
includes v7, but I couldn't find it on my mail dirs.
Just by booting the machine with this patch, I get:
[
; --
> keith.packard at intel.com
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
--
Paulo Zanoni
From: Paulo Zanoni <paulo.r.zan...@intel.com>
Sometimes we want to disable all the screens on a system, because that
will allow the graphics card to be put into low-power states. The
problem is that, for example, while all screens are disabled, if we
get a hotplug interrupt, fbcon will
d investigating this problem yesterday and reached the same
conclusion. The connector path can be easily reproduced on i915.ko:
get a machine that has an eDP panel, physically disconnect the panel,
boot the machine, "modprobe i915" and watch the segfault.
Reviewed-by: Paulo Zanoni
Te
2013/10/1 Ville Syrjälä ville.syrj...@linux.intel.com:
On Thu, Sep 26, 2013 at 08:06:00PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
The consoles who need to do something when unbinding or binding can
optionally implement these functions.
The current problem I'm
From: Paulo Zanoni paulo.r.zan...@intel.com
Hi
These patches allow us to run the module_reload script from intel-gpu-tools on
Haswell. The script basically just removes i915.ko and loads it again.
There's a memory corruption fix and also the fix for fd.o #67813. Notice that
the first patch
From: Paulo Zanoni paulo.r.zan...@intel.com
VGA whack-a-mole!
We need VGA to be disabled whenever our driver is working. So even
without reproducible bugs this patch makes sense, but we do have a bug
solved by this patch.
If you boot a Haswell machine with eDP+HDMI, then kill your display
From: Paulo Zanoni paulo.r.zan...@intel.com
For some reason, every single time I try to run module_reload
something tries to read the connector sysfs files. This happens
after we destroy the encoders and before we destroy the connectors, so
when the sysfs read triggers the connector detect
From: Paulo Zanoni paulo.r.zan...@intel.com
The consoles who need to do something when unbinding or binding can
optionally implement these functions.
The current problem I'm trying to solve is that when i915+fbcon is
loaded on Haswell, if we disable the power well (to save power) the
VGA
From: Paulo Zanoni paulo.r.zan...@intel.com
And create fb_bind and fb_unbind fb_ops that the drivers can
implement.
The current problem I'm trying to solve is that when i915+fbcon is
loaded on Haswell, if we disable the power well (to save power) the
VGA interface gets completely disabled, so
From: Paulo Zanoni paulo.r.zan...@intel.com
If we run the following command on Haswell when the power well is
disabled:
echo 0 /sys/class/vtconsole/vtcon1/bind
then we'll get thousands of consecutive interrupts because something
is trying to touch registers that are on the disabled power
pu/drm/i915/intel_display.c
> index e0069f4..1c6a3d2 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9579,6 +9579,7 @@ static void intel_init_display(struct drm_device *dev)
>
> if (HAS_DDI(dev)) {
> dev_priv->display.get_pipe_config = haswell_get_pipe_config;
> + dev_priv->display.get_clock = ironlake_crtc_clock_get;
> dev_priv->display.crtc_mode_set = haswell_crtc_mode_set;
> dev_priv->display.crtc_enable = haswell_crtc_enable;
> dev_priv->display.crtc_disable = haswell_crtc_disable;
> --
> 1.8.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Paulo Zanoni
://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Paulo Zanoni
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
abling whenever panel is disabled/enabled.
> v5: make it last patch to avoid breaking whenever bisecting. So calling for
> update and force exit came to this patch along with enable/disable calls.
>
> CC: Paulo Zanoni
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/
whenever panel is disabled/enabled.
v5: make it last patch to avoid breaking whenever bisecting. So calling for
update and force exit came to this patch along with enable/disable calls.
CC: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
GB quantization range in automatic mode
Everything looks correct, but I really didn't test anything. If you
apply my comments from patch 2, then you have "Reviewed-by: Paulo
Zanoni " for all the 4 patches.
Optional bikeshedding: you could add a follow-up patch fixing the
comments i
_mode *mode2);
> extern int drm_mode_width(const struct drm_display_mode *mode);
> extern int drm_mode_height(const struct drm_display_mode *mode);
>
> --
> 1.8.1.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Paulo Zanoni
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Paulo Zanoni
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
RGB quantization range in automatic mode
Everything looks correct, but I really didn't test anything. If you
apply my comments from patch 2, then you have Reviewed-by: Paulo
Zanoni paulo.r.zan...@intel.com for all the 4 patches.
Optional bikeshedding: you could add a follow-up patch fixing
ged, 569 insertions(+), 125 deletions(-)
>
> --
> 1.8.1.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
_
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
(2<<29)
The 4 lines above are wrong. It's (x<<26).
> +#define EDP_PSR_STATUS_MAX_SLEEP_TIMER_SHIFT 20
> +#define EDP_PSR_STATUS_MAX_SLEEP_TIMER_MASK 0x1f
> +#define EDP_PSR_STATUS_COUNT_SHIFT 16
> +#define EDP_PSR_STATUS_COUNT_MASK0xf
> +#define EDP_PSR_STATUS_AUX_ERROR (1<<15)
> +#define EDP_PSR_STATUS_AUX_SENDING (1<<12)
> +#define EDP_PSR_STATUS_SENDING_IDLE (1<<9)
> +#define EDP_PSR_STATUS_SENDING_TP2_TP3 (1<<8)
> +#define EDP_PSR_STATUS_SENDING_TP1 (1<<4)
> +#define EDP_PSR_STATUS_IDLE_MASK 0xf
> +
> +#define EDP_PSR_PERF_CNT 0x64844
> +#define EDP_PSR_PERF_CNT_MASK0xff
>
> #define EDP_PSR_DEBUG_CTL 0x64860
> #define EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
> --
> 1.8.1.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
Hi
2013/2/28 Sedat Dilek :
> On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek wrote:
>> On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni wrote:
>>> Hi
>>>
>>> 2013/2/28 Chris Wilson :
>>>> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote:
>
le_psr(struct intel_dp* intel_dp)
>> +{
>> + struct drm_device *dev = intel_dp_to_dev(intel_dp);
>> + struct drm_i915_private *dev_priv = dev->dev_private;
>> + struct intel_crtc *intel_crtc =
>> to_intel_crtc(intel_dp_to_crtc(intel_dp));
>> + uint32_t reg = HSW_TVIDEO_DIP_CTL(intel_crtc->cpu_transcoder);
>> + uint32_t val;
>> +
>> + if (!intel_edp_is_psr_enabled(intel_dp))
>> + return;
>> +
>> + val = I915_READ(EDP_PSR_CTL);
>> + I915_WRITE(EDP_PSR_CTL, val & ~EDP_PSR_ENABLE);
>> +
>> + /* Wait till PSR is idle */
>> + if (_wait_for((I915_READ(EDP_PSR_STATUS_CTL) &
>> +EDP_PSR_STATUS_STATE_MASK) == 0, 2000, 10))
>> + DRM_ERROR("Timed out waiting for PSR Idle State\n");
>> +
>> + intel_wait_for_vblank(dev, intel_crtc->pipe);
>> +
>> + val = I915_READ(reg);
>> + I915_WRITE(reg, val & ~VIDEO_DIP_ENABLE_VSC_HSW);
>> +}
>> +
>> static void intel_enable_dp(struct intel_encoder *encoder)
>> {
>> struct intel_dp *intel_dp = enc_to_intel_dp(>base);
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index 865ede6..cfda739 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -696,4 +696,7 @@ extern bool
>> intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector);
>> extern void intel_ddi_fdi_disable(struct drm_crtc *crtc);
>>
>> +extern void intel_edp_enable_psr(struct intel_dp* intel_dp);
>> +extern void intel_edp_disable_psr(struct intel_dp* intel_dp);
>> +
>> #endif /* __INTEL_DRV_H__ */
>> --
>> 1.8.1.2
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrj?l?
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
l_wait_for_vblank(dev, intel_crtc->pipe);
> +
> + val = I915_READ(reg);
> + I915_WRITE(reg, val & ~VIDEO_DIP_ENABLE_VSC_HSW);
So, based on this and on the spec, it means the HW will automagically
do the link training for us if it's needed?
> +}
> +
> static void intel_enable_dp(struct intel_encoder *encoder)
> {
> struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 865ede6..cfda739 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -696,4 +696,7 @@ extern bool
> intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector);
> extern void intel_ddi_fdi_disable(struct drm_crtc *crtc);
>
> +extern void intel_edp_enable_psr(struct intel_dp* intel_dp);
> +extern void intel_edp_disable_psr(struct intel_dp* intel_dp);
> +
> #endif /* __INTEL_DRV_H__ */
> --
> 1.8.1.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Paulo Zanoni
x44008) and
I915_READ(0xC4008).
If you conclude that the value of 0x44008 is 0x0 while the value of
0xC4008 is not, then this patch should help:
https://patchwork.kernel.org/patch/2177841/
>
> That second '{' is the source of the compile error.
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
-devel
--
Paulo Zanoni
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
Hi
2013/2/28 Sedat Dilek sedat.di...@gmail.com:
On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni przan...@gmail.com wrote:
Hi
2013/2/28 Chris Wilson ch...@chris-wilson.co.uk:
On Thu, Feb 28, 2013 at 12:06:28AM +0100
EDP_PSR_DEBUG_MASK_MEMUP (126)
--
1.8.1.2
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
dri-devel mailing list
dri
/listinfo/intel-gfx
--
Paulo Zanoni
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Paulo Zanoni
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
_((packed));
And here some more defines to access the individual byte fields would
be cool, like:
#define EDP_VSC_PSR_STATE_ACTIVE 1
#define EDP_VSC_PSR_RFB_UPDATE (1 << 1)
etc.
> +
> static inline int
> drm_dp_max_link_rate(u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
> --
> 1.8
r DP, specially for TRANSCODER_EDP.
>
> v2: Adding HSW_TVIDEO_DIP_VSC_DATA to transmit vsc to eDP.
>
> Signed-off-by: Rodrigo Vivi
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_reg.h | 18 ++
> drivers/gpu/drm/i915/intel_hdmi.c | 13 +++--
>
for TRANSCODER_EDP.
v2: Adding HSW_TVIDEO_DIP_VSC_DATA to transmit vsc to eDP.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 18 ++
drivers/gpu/drm/i915/intel_hdmi.c | 13
://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Paulo Zanoni <paulo.r.zan...@intel.com>
If bit 0 of the features byte (0x18) is set to 0, then, according to
the EDID spec, "the display is non-continuous frequency (multi-mode)
and is only specified to accept the video timing formats that are
listed in Base EDID and certai
From: Paulo Zanoni paulo.r.zan...@intel.com
If bit 0 of the features byte (0x18) is set to 0, then, according to
the EDID spec, the display is non-continuous frequency (multi-mode)
and is only specified to accept the video timing formats that are
listed in Base EDID and certain Extension Blocks
+* case we have to do this later at some point
> +*/
> +
> + /* Disable VSC DIP */
> + val = I915_READ(VIDEO_DIP_CTL_EDP);
> + I915_WRITE(VIDEO_DIP_CTL_EDP, val & ~VIDEOP_DIP_VSC);
> +#endif
I'd vote to disable and also try to reuse the functions inside
intel_hdmi.c for this.
> +}
> +
> static void intel_enable_dp(struct intel_encoder *encoder)
> {
> struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 3fa2dd0..2f48e5c 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -692,4 +692,7 @@ extern bool
> intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector);
> extern void intel_ddi_fdi_disable(struct drm_crtc *crtc);
>
> +extern void intel_edp_enable_psr(struct intel_dp* intel_dp);
> +extern void intel_edp_disable_psr(struct intel_dp* intel_dp);
> +
> #endif /* __INTEL_DRV_H__ */
> --
> 1.7.11.7
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Paulo Zanoni
915/intel_drv.h
> index d4b3bac..3fa2dd0 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -383,6 +383,7 @@ struct intel_dp {
> int backlight_on_delay;
> int backlight_off_delay;
> struct delayed_work panel_vdd_work;
> + uint8_t psr_setup;
bool psr_setup_done ?
> bool want_panel_vdd;
> struct intel_connector *attached_connector;
> };
> --
> 1.7.11.7
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Paulo Zanoni
ruct drm_i915_private *dev_priv = encoder->dev->dev_private;
>> struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
>> struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
>> - u32 reg = HSW_TVIDEO_DIP_CTL(intel_crtc->pipe);
>> + u32 reg = HSW_TVIDEO_DIP_CTL(intel_crtc->cpu_transcoder);
>> u32 val = I915_READ(reg);
>>
>> assert_hdmi_port_disabled(intel_hdmi);
>> --
>> 1.7.11.7
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Paulo Zanoni
mplaint about this patch (besides the sentence above) would
be due to using more than 80 columns, both on the commit message and
coding :)
Reviewed-by: Paulo Zanoni
>
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_reg.h | 16
>
about this patch (besides the sentence above) would
be due to using more than 80 columns, both on the commit message and
coding :)
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_reg.h | 16
intel_connector *attached_connector;
};
--
1.7.11.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Paulo Zanoni
___
dri-devel mailing list
1 - 100 of 267 matches
Mail list logo
