From: Thierry Reding
Fix up a couple of checkpatch warnings, such as whitespace or coding
style issues.
Tested-by: John Stultz
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c | 54 -
1 file changed, 32 insertions(+), 22 deletions
From: Thierry Reding
An unlocked version of the drm_fb_helper_add_one_connector() function
will be added in a subsequent patch. Reshuffle the code separately to
make the diff more readable later on.
Tested-by: John Stultz
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c | 59
From: Thierry Reding
This set of patches adds support for deferring FB helper setup, which is
useful to obtain a sane configuration even when no outputs are available
during probe.
One example is HDMI, where fbdev will currently fallback to a 1024x786
resolution if no monitor is connected, and
From: Thierry Reding
Move the modeset locking from drivers into FB helpers.
Tested-by: John Stultz
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c| 39 --
drivers/gpu/drm/i915/intel_dp_mst.c| 3 ---
drivers/gpu/drm/radeon
From: Thierry Reding
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
From: Thierry Reding
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 --
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 --
2 files changed, 4 inser
From: Thierry Reding
The expression &private->fbdev_helper can never be NULL, so the check is
completely unnecessary.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/r
From: Thierry Reding
Add a couple of temporary variables and use shorter names for existing
variables in drm_fb_helper_add_one_connector() for better readability.
Tested-by: John Stultz
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c | 25 -
1 file
From: Thierry Reding
FB helper code falls back to a 1024x768 mode if no outputs are connected
or don't report back any modes upon initialization. This can be annoying
because outputs that are added to FB helper later on can't be used with
FB helper if they don't support a matc
From: Thierry Reding
drm_fbdev_cma_hotplug_event() already checks for NULL pointers before
dereferencing, so callers don't need to do that.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --
From: Thierry Reding
Introduce a new top-level lock for the FB helper code. This will allow
better locking granularity and avoid the need to abuse modeset locking
for this purpose instead.
Tested-by: John Stultz
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c | 27
On Tue, Mar 21, 2017 at 11:42:21AM +0100, Andrzej Hajda wrote:
> On 21.03.2017 11:20, Daniel Vetter wrote:
> > On Tue, Mar 21, 2017 at 10:58:43AM +0100, Andrzej Hajda wrote:
> >> On 21.03.2017 09:13, Thierry Reding wrote:
> >>> From: Thierry Reding
> >>
On Tue, Mar 21, 2017 at 11:27:04AM +0100, Daniel Vetter wrote:
> On Tue, Mar 21, 2017 at 09:13:58AM +0100, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > The expression &private->fbdev_helper can never be NULL, so the check is
> > completely unnecessar
On Tue, Mar 21, 2017 at 12:13:26PM +0100, Andrzej Hajda wrote:
> On 21.03.2017 11:53, Thierry Reding wrote:
> > On Tue, Mar 21, 2017 at 11:42:21AM +0100, Andrzej Hajda wrote:
> >> On 21.03.2017 11:20, Daniel Vetter wrote:
> >>> On Tue, Mar 21, 2017 at 10:58:4
On Tue, Mar 21, 2017 at 11:10:22AM +0100, Daniel Vetter wrote:
> On Tue, Mar 21, 2017 at 09:13:54AM +0100, Thierry Reding wrote:
[...]
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
[...]
> > @@ -2437,11 +247
From: Thierry Reding
Introduce a new top-level lock for the FB helper code. This will allow
better locking granularity and avoid the need to abuse modeset locking
for this purpose instead.
Tested-by: John Stultz
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm
From: Thierry Reding
Fix up a couple of checkpatch warnings, such as whitespace or coding
style issues.
Tested-by: John Stultz
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c | 54 -
1 file changed, 32
From: Thierry Reding
This set of patches adds support for deferring FB helper setup, which is
useful to obtain a sane configuration even when no outputs are available
during probe.
One example is HDMI, where fbdev will currently fallback to a 1024x786
resolution if no monitor is connected, and
From: Thierry Reding
An unlocked version of the drm_fb_helper_add_one_connector() function
will be added in a subsequent patch. Reshuffle the code separately to
make the diff more readable later on.
Tested-by: John Stultz
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers
From: Thierry Reding
The existing drm_fb_helper_hotplug_event() function needs to take the
top-level fb-helper lock. However, the function can also be called from
code that has already taken this lock. Introduce an unlocked variant of
this function that can be used in the latter case.
This
From: Thierry Reding
The expression &private->fbdev_helper can never be NULL, so the check is
completely unnecessary.
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff
From: Thierry Reding
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 21 +++--
1 file changed, 11 inser
From: Thierry Reding
drm_fbdev_cma_hotplug_event() already checks for NULL pointers before
dereferencing, so callers don't need to do that.
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 3 +--
1 file changed, 1 insertion(
From: Thierry Reding
Add a couple of temporary variables and use shorter names for existing
variables in drm_fb_helper_add_one_connector() for better readability.
Tested-by: John Stultz
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c | 25
From: Thierry Reding
Move the modeset locking from drivers into FB helpers.
Tested-by: John Stultz
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c| 40 +-
drivers/gpu/drm/i915/intel_dp_mst.c| 3
From: Thierry Reding
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 --
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 23 ---
2
From: Thierry Reding
FB helper code falls back to a 1024x768 mode if no outputs are connected
or don't report back any modes upon initialization. This can be annoying
because outputs that are added to FB helper later on can't be used with
FB helper if they don't support a matc
On Wed, Mar 29, 2017 at 04:43:56PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> The existing drm_fb_helper_hotplug_event() function needs to take the
> top-level fb-helper lock. However, the function can also be called from
> code that has already taken this loc
On Thu, Jan 19, 2017 at 06:58:30PM +0100, Hans de Goede wrote:
> The primary consumer of the lpss pwm is the i915 kms driver,
> the i915 driver does not support get_pwm returning -EPROBE_DEFER and
> its init is very complex making this is almost impossible to fix.
>
> This commit changes the PWM_L
On Fri, Jan 20, 2017 at 08:03:33AM +0100, Thierry Reding wrote:
> On Thu, Jan 19, 2017 at 06:58:30PM +0100, Hans de Goede wrote:
> > The primary consumer of the lpss pwm is the i915 kms driver,
> > the i915 driver does not support get_pwm returning -EPROBE_DEFER and
> > its
On Fri, Jan 20, 2017 at 10:02:50AM +0200, Jani Nikula wrote:
> On Fri, 20 Jan 2017, Thierry Reding wrote:
> > On Thu, Jan 19, 2017 at 06:58:30PM +0100, Hans de Goede wrote:
> >> The primary consumer of the lpss pwm is the i915 kms driver,
> >> the i915 driver does no
On Fri, Jan 20, 2017 at 10:48:52AM +0100, Hans de Goede wrote:
> Hi,
>
> On 20-01-17 09:56, Thierry Reding wrote:
> > On Fri, Jan 20, 2017 at 10:02:50AM +0200, Jani Nikula wrote:
> > > On Fri, 20 Jan 2017, Thierry Reding wrote:
> > > > On Thu, Jan 19, 201
On Fri, Jan 20, 2017 at 11:18:29AM +0100, Hans de Goede wrote:
> Hi,
>
> On 20-01-17 10:55, Andy Shevchenko wrote:
> > On Fri, 2017-01-20 at 10:48 +0100, Hans de Goede wrote:
> > > I'm fine with doing a v3 with a comment, how about putting that
> > > comment
> > > right at all the module* stuff an
rmann
> Cc: Javier Martinez Canillas
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Deepak Rawat
> Cc: Neil Armstrong
> Cc: Kevin Hilman
> Cc: Jerome Brunet
> Cc: Martin Blumenstingl
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: Emma Anholt
> Cc: Helge
pers directly within each DRM fbdev emulation,
> we can eventually remove DRM's wrapper functions entirely.
>
> v4:
> * use initializer macros for struct fb_ops
> v2:
> * use FB_SYS_HELPERS option
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Sam Ra
On Sat, Nov 18, 2023 at 04:16:17PM +, Sean Young wrote:
> In order to introduce a pwm api which can be used from atomic context,
> we will need two functions for applying pwm changes:
>
> int pwm_apply_cansleep(struct pwm *, struct pwm_state *);
> int pwm_apply_atomic(struct pwm *,
On Thu, Sep 01, 2022 at 03:47:06PM +0300, Jani Nikula wrote:
> Prefer the parsed results for is_hdmi in display info over calling
> drm_detect_hdmi_monitor().
>
> Cc: Thierry Reding
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Jani Nikula
> ---
> drivers/
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> Cc: Thierry Reding
> Cc: Emma Anholt
> Cc: Maxime Ripard
> Cc: intel-gfx@lists.freedesktop.org
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Ville Syrj
On Wed, Aug 14, 2013 at 06:19:08PM +0100, Damien Lespiau wrote:
> To set the active aspect ratio value in the AVI infoframe today, you not
> only have to set the active_aspect field, but also the active_info_valid
> bit. Out of the 1 user of this API, we had 100% misuse, forgetting the
> _valid bit
On Wed, Aug 14, 2013 at 06:19:09PM +0100, Damien Lespiau wrote:
> Just like:
>
> Author: Damien Lespiau
> Date: Mon Aug 12 11:53:24 2013 +0100
>
> video/hdmi: Don't let the user of this API create invalid infoframes
>
> But this time for the horizontal/vertical bar data present bits
On Wed, Aug 14, 2013 at 06:19:10PM +0100, Damien Lespiau wrote:
[...]
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index ac84215..59c4748 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -286,6 +286,94 @@ ssize_t hdmi_audio_infoframe_pack(struct
> hdmi_audio_in
On Wed, Aug 14, 2013 at 06:19:12PM +0100, Damien Lespiau wrote:
[...]
> +#define HDMI_IDENTIFIER 0x000c03
HDMI_IDENTIFIER sounds really generic. Perhaps HDMI_INFOFRAME_OUI_HDMI?
Thierry
pgpsLkgvKVXmx.pgp
Description: PGP signature
___
Intel-gfx mailin
On Wed, Aug 14, 2013 at 06:19:13PM +0100, Damien Lespiau wrote:
[...]
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
[...]
> +union hdmi_vendor_infoframe {
> + struct {
> + enum hdmi_infoframe_type type;
> + unsigned char version;
> + unsigned cha
On Mon, Aug 19, 2013 at 02:49:50PM +0100, Damien Lespiau wrote:
> On Thu, Aug 15, 2013 at 05:12:00PM +0200, Thierry Reding wrote:
> > On Wed, Aug 14, 2013 at 06:19:12PM +0100, Damien Lespiau wrote:
> > [...]
> > > +#define HDMI_IDENTIFIER 0x000c03
> >
> > H
s the hotplug event for an external hdmi screen,
> but also reliably boots to quickly for the hpd pin to be asserted when
> the fb helper calls into the hdmi ->detect function.
>
> Cc: Thierry Reding
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_helper.c |
On Tue, Apr 22, 2014 at 10:26:37AM +0200, Daniel Vetter wrote:
> On Thu, Apr 17, 2014 at 10:38:17AM +0200, Thierry Reding wrote:
> > On Wed, Apr 16, 2014 at 04:45:21PM +0200, Daniel Vetter wrote:
> > > Some drivers need to be able to have a perfect race-free fbcon setup.
> >
On Tue, Apr 22, 2014 at 10:26:37AM +0200, Daniel Vetter wrote:
> On Thu, Apr 17, 2014 at 10:38:17AM +0200, Thierry Reding wrote:
> > On Wed, Apr 16, 2014 at 04:45:21PM +0200, Daniel Vetter wrote:
> > > Some drivers need to be able to have a perfect race-free fbcon setup.
> >
From: Thierry Reding
To implement hotplug detection in a race-free manner, drivers must call
drm_kms_helper_poll_init() before hotplug events can be triggered. Such
events can be triggered right after any of the encoders or connectors
are initialized. At the same time, if the
oof of concept.
Feature requested by Thierry since his tegra driver atm reliably boots
slowly enough to misses the hotplug event for an external hdmi screen,
but also reliably boots to quickly for the hpd pin to be asserted when
the fb helper calls into the hdmi ->detect function.
Cc: Thierry
From: Thierry Reding
A race condition currently exists on Tegra, where it can happen that a
monitor attached via HDMI isn't detected during the initial FB helper
setup, but the hotplug event happens too early to be processed by the
poll helpers because they haven't been initialized
From: Thierry Reding
There's no need for this to be modifiable. Make it const so that it can
be put into the .rodata section.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
drivers/gpu/drm/ast/ast_fb.c | 2 +-
drivers/gpu/drm/
On Tue, Apr 22, 2014 at 05:54:06PM +0200, Daniel Vetter wrote:
> On Tue, Apr 22, 2014 at 04:42:20PM +0200, Thierry Reding wrote:
[...]
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
[...]
> > @@ -502,6 +503,33 @@ static void drm_fb_he
On Wed, Apr 23, 2014 at 09:35:48AM +0200, Daniel Vetter wrote:
> On Wed, Apr 23, 2014 at 09:14:41AM +0200, Thierry Reding wrote:
> > On Tue, Apr 22, 2014 at 05:54:06PM +0200, Daniel Vetter wrote:
> > > On Tue, Apr 22, 2014 at 04:42:20PM +0200, Thierry Reding wrote:
> > [.
On Mon, May 12, 2014 at 10:03:55AM +0200, Daniel Vetter wrote:
> On Mon, May 12, 2014 at 11:37:53AM +0530, Sagar Arun Kamble wrote:
> > I support approach using docbook to start since there are not lot of
> > properties. Laurent has ack'ed this one. Can we go ahead with this?
> > http://lists.freed
On Mon, May 12, 2014 at 04:46:42PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This property will be used by the MST code to provide userspace
> with a path to parse so it can recognise connectors around hotplugs.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_crtc.c | 26 +++
On Mon, May 12, 2014 at 04:46:41PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This can be called to update things after dynamic connectors/encoders
> are created/deleted.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_crtc.c | 9 +
> include/drm/drm_crtc.h | 1 +
On Mon, May 12, 2014 at 04:46:47PM +1000, Dave Airlie wrote:
[...]
> @@ -3813,6 +3838,7 @@ static const struct drm_info_list i915_debugfs_list[] =
> {
> {"i915_pc8_status", i915_pc8_status, 0},
> {"i915_power_domain_info", i915_power_domain_info, 0},
> {"i915_display_info", i915_
On Tue, May 13, 2014 at 09:34:45AM +0200, Daniel Vetter wrote:
> On Tue, May 13, 2014 at 9:17 AM, Thierry Reding
> wrote:
> > On Mon, May 12, 2014 at 10:03:55AM +0200, Daniel Vetter wrote:
> >> On Mon, May 12, 2014 at 11:37:53AM +0530, Sagar Arun Kamble wrote:
> >&
On Tue, May 13, 2014 at 12:18:35PM +0200, Daniel Vetter wrote:
> On Tue, May 13, 2014 at 10:33:27AM +0200, Thierry Reding wrote:
> > On Mon, May 12, 2014 at 04:46:47PM +1000, Dave Airlie wrote:
> > [...]
> > > @@ -3813,6 +3838,7 @@ static const struct drm_info_list
On Tue, May 13, 2014 at 09:18:45AM +0530, Sharma, Shashank wrote:
> Daniel,
> Please find my comments inline.
>
> Regards
> Shashank
> On 5/12/2014 8:58 PM, Daniel Vetter wrote:
> >On Mon, May 12, 2014 at 05:35:13PM +0530, Sharma, Shashank wrote:
> >>Thanks for your time and the comments David.
>
On Thu, May 15, 2014 at 10:52:38AM +0530, Sharma, Shashank wrote:
[...]
> Please note that the color correction methods changes per platform and
> what's valid for one Intel platform may not be valid for other. So the
> atomic modeset should have a clear idea of what is supported on which
> platfor
On Wed, May 14, 2014 at 08:51:09PM +0200, Daniel Vetter wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
[...]
> index dd786d84daab..5ff986bd4de4 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1,6 +1,5 @@
> -/**
> - * \file drm_irq.
or the reverse lookup.
I'd still prefer to have i915 changes in a separate commit, but
otherwise:
Reviewed-by: Thierry Reding
pgpk7N3wuAH7q.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, May 15, 2014 at 12:10:16PM +0200, Daniel Vetter wrote:
> On Thu, May 15, 2014 at 9:34 AM, Thierry Reding
> wrote:
> > This seems slightly backwards. Since drm_vblank_get() is what's being
> > deprecated here, wouldn't it make more sense to write
> >
On Tue, May 20, 2014 at 12:04:38PM +0200, Daniel Vetter wrote:
> Also adding dri-devel and linux-media. Please don't forget these lists for
> the next round.
> -Daniel
>
> On Tue, May 20, 2014 at 12:02:04PM +0200, Daniel Vetter wrote:
> > Adding Greg just as an fyi since we've chatted briefly abou
On Tue, May 20, 2014 at 04:45:56PM +0200, Daniel Vetter wrote:
> On Tue, May 20, 2014 at 4:29 PM, Imre Deak wrote:
> > On Tue, 2014-05-20 at 05:52 +0300, Lin, Mengdong wrote:
> >> This RFC is based on previous discussion to set up a generic
> >> communication channel between display and audio driv
On Tue, May 20, 2014 at 05:07:51PM +0200, Daniel Vetter wrote:
> On 20/05/2014 16:57, Thierry Reding wrote:
> >On Tue, May 20, 2014 at 04:45:56PM +0200, Daniel Vetter wrote:
> >>>On Tue, May 20, 2014 at 4:29 PM, Imre Deak wrote:
> >>>> >On Tue, 2014-05
; ---
> drivers/gpu/drm/drm_irq.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Reviewed-by: Thierry Reding
pgpk47T2UOhHK.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesk
ked before, why do we even need this timer? Why
not simply disable interrupts when the last vblank reference goes away?
Generally, though:
Reviewed-by: Thierry Reding
pgp_M10LG3SwK.pgp
Description: PGP signature
___
Intel-gfx mailing list
On Wed, May 14, 2014 at 08:51:05PM +0200, Daniel Vetter wrote:
> From: Ville Syrjälä
>
> If there's a blocking vblank wait in progress while the vblank interrupt
> gets disabled, the current code will just let the vblank wait time out.
> Instead make it return immediately when vblank interrupts g
On Wed, May 21, 2014 at 01:20:55PM +0200, Thierry Reding wrote:
> On Wed, May 14, 2014 at 08:51:05PM +0200, Daniel Vetter wrote:
> > From: Ville Syrjälä
> >
> > If there's a blocking vblank wait in progress while the vblank interrupt
> > gets disabled, the curre
On Wed, May 14, 2014 at 08:51:06PM +0200, Daniel Vetter wrote:
> From: Ville Syrjälä
>
> drm_vblank_off() will turn off vblank interrupts, but as long as the
> refcount is elevated drm_vblank_get() will not re-enable them. This
> is a problem is someone is holding a vblank reference while a modes
On Wed, May 14, 2014 at 08:51:07PM +0200, Daniel Vetter wrote:
> Originally these functions have been for user modesetting drivers to
> ensure vblank processing doesn't fall over completely around modeset
> changes. This has been carried over ever since then.
>
> Now that Ville cleaned our vblank
On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrjälä wrote:
> On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
> > Now that we unconditionally dtrt when disabling/enabling crtcs we
> > don't need any hacks any longer to keep the vblank logic sane when
> > all the registers go poof.
errupts and hence also not vblank waits.
>
> Just return early on such drivers.
>
> Note that with pageflips drivers are free to implement them however
> they wish to.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_irq.c | 6 ++
> 1 file change
On Wed, May 14, 2014 at 08:51:16PM +0200, Daniel Vetter wrote:
> If we want to use this functionality in generic helpers to make
> sure that all drivers have somewhat sane vblank handling across
> modesets/dpms, we need to make it work for all drivers. But some
> don't support interrupts and hence
On Wed, May 21, 2014 at 10:35:59AM +0200, Daniel Vetter wrote:
> On Wed, May 21, 2014 at 11:26:55AM +0300, Ville Syrjälä wrote:
> > For everything but the reset_vblank_counter() thing:
> > Reviewed-by: Ville Syrjälä
> >
> > And another caveat: I only glanced at the crtc_helper stuff. It looks
> >
On Thu, May 22, 2014 at 04:50:48PM +0530, Vandana Kannan wrote:
> Added a property to enable user space to set aspect ratio.
> This patch contains declaration of the property and code to create the
> property.
>
> Signed-off-by: Vandana Kannan
> Cc: dri-de...@lists.freedesktop.org
> ---
> driver
On Thu, May 22, 2014 at 04:50:49PM +0530, Vandana Kannan wrote:
> In case user has specified an input for aspect ratio through the property,
> then the user space value for PAR would take preference over the value from
> CEA mode list.
>
> Signed-off-by: Vandana Kannan
> Cc: dri-de...@lists.freed
t; - Modified the comment "Populate..." as per review comments
>
> Signed-off-by: Vandana Kannan
> Cc: Thierry Reding
> Cc: Daniel Vetter
>
> ---
> drivers/gpu/drm/drm_edid.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff
struct drm_property *dirty_info_property;
This seems rather randomly inserted into the list. I think either the
list should be sorted alphabetically or you should append new entries.
But that's somewhat bikesheddy, so feel free to ignore.
With my first comment addressed:
Reviewed-by:
t; - Modified the comment "Populate..." as per review comments
>
> v3: Thierry's review comments.
> - Modified the comment to block comment format.
>
> Signed-off-by: Vandana Kannan
> Cc: Thierry Reding
> ---
> drivers/gpu/drm/drm_edid.c |
On Thu, Jun 05, 2014 at 02:40:08PM +0530, Vandana Kannan wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
[...]
> /**
> + * drm_mode_create_aspect_ratio_property - create aspect ratio property
> + * @dev: DRM device
> + *
> + * Called by a driver the first time i
On Tue, Jun 10, 2014 at 02:00:37PM +0530, Vandana Kannan wrote:
> On Jun-05-2014 2:58 PM, Thierry Reding wrote:
> > On Thu, Jun 05, 2014 at 02:40:08PM +0530, Vandana Kannan wrote:
> > [...]
> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/dr
From: Thierry Reding
Add a helper to probe a DP link (read out the supported DPCD revision,
maximum rate, link count and capabilities) as well as power up the DP
link and configure it accordingly.
Reviewed-by: Alex Deucher
Reviewed-by: Jani Nikula
Signed-off-by: Thierry Reding
---
Changes in
From: Thierry Reding
This is a superset of the current i2c_dp_aux bus functionality and can
be used to transfer native AUX in addition to I2C-over-AUX messages.
Helpers are provided to read and write the DPCD, either blockwise or
byte-wise. Many of the existing helpers for DisplayPort take a
From: Thierry Reding
The function reads the link status (6 bytes starting at offset 0x202)
from the DPCD so that it can be conveniently passed to other DPCD
helpers.
Reviewed-by: Alex Deucher
Reviewed-by: Jani Nikula
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 16
From: Thierry Reding
Implements an I2C-over-AUX I2C adapter on top of the generic drm_dp_aux
infrastructure. It extracts the retry logic from existing drivers, which
should help in porting those drivers to this new helper.
Reviewed-by: Alex Deucher
Reviewed-by: Jani Nikula
Signed-off-by
From: Thierry Reding
Hi,
This small series introduces some infrastructure to support AUX channels
in a generic way. Drivers make use of it by embedding and filling in a
struct drm_dp_aux. Various helpers can then be used to for example read
from or write to the DPCD.
Patch 1 adds the basic
On Wed, Jan 22, 2014 at 02:14:07PM -0700, Stephen Warren wrote:
> On 01/21/2014 12:24 PM, Thierry Reding wrote:
[...]
> > +static void tegra_dpaux_write_fifo(struct tegra_dpaux *dpaux, const u8
> > *buffer,
>
> Is that anything like writesl(); similar for
> tegra_dpaux_
On Tue, Feb 18, 2014 at 03:13:33PM +0200, Ville Syrjälä wrote:
[...]
> Once we have drm_planes for cursors, I was thinking we might add some kind
> of enum property that lists all the supported sizes for the plane.
This comment was intriguing, so I was wondering whether you could
elaborate a littl
On Fri, Feb 21, 2014 at 10:41:14AM -0500, Alex Deucher wrote:
> On Fri, Feb 21, 2014 at 9:46 AM, Ville Syrjälä
> wrote:
> > On Fri, Feb 21, 2014 at 02:20:24PM +, Sharma, Shashank wrote:
> >> Hi Ville,
> >>
> >> Thanks for your time and comments.
> >> I can understand two basic problems what yo
t; + * NULL, dev_name() of .dev will be used.
> + *
Nit: That new paragraph sticks out because it's wider than the rest,
even though it still fits into 80 characters.
I don't feel all that strongly about either of the above, so:
Reviewed-by: Thierry Reding
pgpZN07uvRcGA.pgp
D
adding locking
> WARNs as part of the recent kerneldoc abi polishing done in
Tested-by: Thierry Reding
pgptSZEMMOr8y.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
and nouveau in drm_fb_helper_initial_config.
Fixes any of the WARNINGs remaining after patch 1/2 for me on Tegra as
well, so:
Tested-by: Thierry Reding
pgp9xXBCMW7V6.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.
trying to disable things harder is a bit a bug. Caught by Thierry
> since it resulted in some mode_config.mutex locking backtraces.
>
> Cc: Thierry Reding
> Cc: Matt Roper
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_plane_helper.c | 1 -
> 1 file changed,
string and va_list can be properly
verified for correctness.
I guess we leave it up to the compiler to do that verification using the
__printf() annotation, so I think it should be fine to use it here:
Reviewed-by: Thierry Reding
pgpb1iR3mjIM2.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Fri, Nov 15, 2013 at 03:01:50PM +0200, Jani Nikula wrote:
> Preparing for the future eDP panels.
>
> Signed-off-by: Jani Nikula
> ---
> include/drm/drm_dp_helper.h | 29 +
> 1 file changed, 29 insertions(+)
Reviewed-by: Thierry Reding
t's a matter of time. Give
> ourselves a reminder when we need to fix this for real.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dp.c | 14 ++
> 1 file changed, 14 insertions(+)
I have a few general comments below, but this patch itself
On Mon, Nov 18, 2013 at 10:09:56AM -0500, Alex Deucher wrote:
> On Mon, Nov 18, 2013 at 9:27 AM, Thierry Reding
> wrote:
> > On Fri, Nov 15, 2013 at 03:01:51PM +0200, Jani Nikula wrote:
> >> Debug print the capabilities, and flag an error if the panel does not
> >&g
201 - 300 of 431 matches
Mail list logo
