On Mon, Nov 18, 2013 at 05:20:54PM +0100, Daniel Vetter wrote:
> On Mon, Nov 18, 2013 at 04:26:17PM +0100, Thierry Reding wrote:
> > 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:
> &g
On Mon, Nov 18, 2013 at 05:38:18PM +0100, Daniel Vetter wrote:
> On Mon, Nov 18, 2013 at 5:31 PM, Thierry Reding
> wrote:
> >> Note that there's already a bit of abstraction for i2c over dp aux, but
> >> imo that's at the wrong level. At least reading through
On Thu, Nov 28, 2013 at 04:49:52PM +0100, Daniel Vetter wrote:
> On Thu, Nov 28, 2013 at 03:29:18PM +, Damien Lespiau wrote:
> > We had some mode_valid() vfuncs returning an int, others the enum. Let's
> > use the latter everywhere.
> >
> > Signed-off-by: Damien Lespiau
>
> Yeah, makes sense
Replace an open-coded occurrence by a call to the new drm_crtc_mask()
helper.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/i915/intel_display.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915
hierry
Russell King (1):
drm: provide a helper for the encoder possible_crtcs mask
Thierry Reding (1):
drm/i915: Use drm_crtc_mask() helper
drivers/gpu/drm/drm_crtc.c | 38
drivers/gpu/drm/drm_crtc_helper.c| 16 +++
drive
, expose
the code which already exists for calculating the appropriate mask bit
for a CRTC.
Signed-off-by: Russell King
Reviewed-by: David Herrmann
[tred...@nvidia.com: add drm_crtc_index(), move to core]
Signed-off-by: Thierry Reding
---
Changes in v2:
- further extract a new drm_crtc_index
The intel_encoder_crtc_ok() is a duplicate of the drm_encoder_crtc_ok()
function that used to be only available in the DRM CRTC helpers. It has
recently been moved to the core, so the duplicate can now be dropped.
Acked-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
Changes in v3
, expose
the code which already exists for calculating the appropriate mask bit
for a CRTC.
Signed-off-by: Russell King
Reviewed-by: David Herrmann
Reviewed-by: Jani Nikula
[tred...@nvidia.com: add drm_crtc_index(), move to core]
Signed-off-by: Thierry Reding
---
Changes in v3:
- move
for the encoder possible_crtcs mask
Thierry Reding (2):
drm: Move drm_encoder_crtc_ok() to core
drm/i915: Use drm_encoder_crtc_ok()
drivers/gpu/drm/drm_crtc.c | 23 +++
drivers/gpu/drm/drm_crtc_helper.c| 29 -
drivers/gpu/drm/i915
Using the new drm_crtc_mask() function, drm_encoder_crtc_ok() can now be
written in a significantly shorter way, so it can be moved to a header
file and be made static inline.
Signed-off-by: Thierry Reding
---
Changes in v3:
- new patch
drivers/gpu/drm/drm_crtc_helper.c | 13
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.
Signed-off-by: Thierry Reding
---
Changes in v3:
- split into drm_dp_link_power_up() and drm_dp_link_configure()
- do
DPCD and operate on that, without a way to write data
back to the DPCD (e.g. for configuration of the link).
Subsequent patches will build upon this infrastructure to provide common
functionality in a generic way.
Signed-off-by: Thierry Reding
---
Changes in v3:
- reorder drm_dp_dpcd_writeb
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.
Signed-off-by: Thierry Reding
---
Changes in v3:
- add back DRM_DEBUG_KMS and DRM_ERROR
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.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 16
include/drm/drm_dp_helper.h | 3 +++
2 files changed, 19
codes
Changes in v2:
- reimplement I2C-over-AUX functionality to get rid of the additional
layer
- extract retry logic from existing drivers
- add more kerneldoc comments
Thierry
Thierry Reding (4):
drm/dp: Add AUX channel infrastructure
drm/dp: Add drm_dp_dpcd_read_link_status()
drm/dp
On Tue, Jan 14, 2014 at 10:52:55AM -0500, Alex Deucher wrote:
> On Tue, Jan 14, 2014 at 9:55 AM, Thierry Reding
> wrote:
[...]
> > +/**
> > + * drm_dp_link_configure() - configure a DisplayPort link
> > + * @aux: DisplayPort AUX cahnnel
> > + * @link: pointer to a
- add more kerneldoc comments
Thierry
Thierry Reding (5):
drm/dp: Add AUX channel infrastructure
drm/dp: Add drm_dp_dpcd_read_link_status()
drm/dp: Add DisplayPort link helpers
drm/dp: Allow registering AUX channels as I2C busses
drm/tegra: Add eDP support
.../bindings/gpu/nvidia,tegra20
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
include
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: Thierry Reding
---
Changes
On Fri, Jan 17, 2014 at 03:22:08PM +0200, Jani Nikula wrote:
> On Tue, 14 Jan 2014, Thierry Reding wrote:
[...]
> > +int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link)
> > +{
> > + u8 values[3];
> > + int err;
> > +
>
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 v4:
- fix a couple of
DPCD and operate on that, without a way to write data
back to the DPCD (e.g. for configuration of the link).
Subsequent patches will build upon this infrastructure to provide common
functionality in a generic way.
Reviewed-by: Alex Deucher
Reviewed-by: Jani Nikula
Signed-off-by: Thierry Reding
On Mon, Aug 19, 2013 at 04:58:54PM +0100, Damien Lespiau wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
[...]
> +static int
> +do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
> +{
[...]
> + u8 vic;
> +
> + vic =
_hdmi_infoframe to hdmi_vendor_infoframe (by, in turn,
> renaming the hdmi_vendor_infoframe enum to hdmi_vendor_any_infoframe)
> - Renamed HDMI_IDENTIFIER to HDMI_IEEE_OUI
The series looks good to me. Thanks for doing this Damien!
Reviewed-by: Thierry Reding
pgpRPMU_SMnVH.pgp
De
Today's linux-next merge of the drm-intel tree got conflicts in
drivers/gpu/drm/i915/intel_display.c
I fixed it up (see below). Please check if the resolution looks correct.
Thanks,
Thierry
---
diff --cc drivers/gpu/drm/i915/intel_display.c
index e5822e7,cbbdab6..76870f0
--- a/drivers/gp
Today's linux-next merge of the drm-intel tree got conflicts in:
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/intel_dp.c
drivers/gpu/drm/i915/intel_drv.h
caused by commits e1264eb (Revert "drm/i915: Delay disabling of VGA memory
until vgacon->fbcon handoff is done"
Today's linux-next merge of the drm tree got conflicts in
drivers/gpu/drm/i915/intel_drv.h
caused by commits e1264eb (Revert "drm/i915: Delay disabling of VGA memory
until vgacon->fbcon handoff is done"), 20ddf66 (drm/i915: Make
intel_crtc_active() available outside intel_pm.c), 18442d0 (
Today's linux-next merge of the drm tree got conflicts in
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/i915_drv.c
drivers/gpu/drm/i915/intel_ddi.c
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_dp.c
drivers/gpu/drm/i915/intel
ridge support now comming in and will in future
> > migrate from sub-encoder design to drm_bridge.
>
> Just a quick aside: Thierry Reding from nvidia is also working on a DSI
> design for the tegra driver. Atm he seems to aim for a full-blown DSI bus
> based on his drm_panel
= NULL;
> plane->crtc = crtc;
> plane->fb = fb;
> + fb = NULL;
> }
> drm_modeset_unlock_all(dev);
>
Ugh... and again I sent the same patch because I didn't look properly
and missed yours.
Reviewed-by: Thierry Redi
e correct VIC number when sending AVI InfoFrames. We add a generic
> drm function to calculate the VIC number and then call it from the
> i915 driver.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50371
> Cc: Thierry Reding
> Signed-off-by: Paulo Zanoni
> ---
>
On Wed, Nov 21, 2012 at 05:08:12PM +0100, Daniel Vetter wrote:
> On Wed, Nov 21, 2012 at 4:47 PM, Thierry Reding
> wrote:
> > Oh great, so I copied that table for nothing. Thanks for Cc'ing, I can
> > reuse that in the HDMI infoframe series.
>
> Wrt the infoframe se
On Wed, Nov 21, 2012 at 05:09:31PM +0100, Daniel Vetter wrote:
> On Wed, Nov 21, 2012 at 5:08 PM, Daniel Vetter wrote:
> > On Wed, Nov 21, 2012 at 4:47 PM, Thierry Reding
> > wrote:
> >> Oh great, so I copied that table for nothing. Thanks for Cc'ing, I can
> >
e correct VIC number when sending AVI InfoFrames. We add a generic
> drm function to calculate the VIC number and then call it from the
> i915 driver.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50371
> Cc: Thierry Reding
> Signed-off-by: Paulo Zanoni
> ---
>
On Thu, Nov 22, 2012 at 09:00:24AM +0100, Rafał Miłecki wrote:
> 2012/11/22 Thierry Reding :
> > On Wed, Nov 21, 2012 at 05:08:12PM +0100, Daniel Vetter wrote:
> >> On Wed, Nov 21, 2012 at 4:47 PM, Thierry Reding
> >> wrote:
> >> > Oh great, so I copied th
On Fri, Nov 23, 2012 at 11:46:10AM -0200, Paulo Zanoni wrote:
> Hi
>
> 2012/11/22 Thierry Reding :
> > On Wed, Nov 21, 2012 at 01:39:48PM -0200, Paulo Zanoni wrote:
[...]
> >> + * @mode: mode
> >> + *
> >> + * RETURNS:
> >> +
On Fri, Nov 23, 2012 at 12:09:26PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> This function returns the VIC of the mode. This value can be used when
> creating AVI InfoFrames.
>
> Cc: Thierry Reding
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50371
&
On Mon, Mar 16, 2015 at 09:15:22AM +1000, Dave Airlie wrote:
> On 16 March 2015 at 05:31, Chris Wilson wrote:
> > On Sun, Mar 15, 2015 at 08:22:36PM +0100, Krzysztof Kolasa wrote:
> >> Problem solved and tested:
> >>
> >> [PATCH] drm/mm: Fix support 4 GiB and larger ranges
> >>
> >> bad argument i
On Fri, Mar 13, 2015 at 07:28:02PM +0530, Shobhit Kumar wrote:
> Some chips instead of using period_ns and duty_ns can be configured
> using the clock divisor and duty percent. Adds an alternative
> configuration method for such chips
I don't see a need to introduce this alternative configuration
iz
> Cc: Linus Walleij
> Cc: Alexandre Courbot
> Cc: Thierry Reding
> Signed-off-by: Shobhit Kumar
> ---
> drivers/mfd/intel_soc_pmic_core.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/mfd/intel_soc_pmic_core.c
> b/drivers/mfd/i
On Fri, Mar 13, 2015 at 04:30:43PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 12, 2015 at 10:01:33PM +0530, Shobhit Kumar wrote:
> > CC: Samuel Ortiz
> > Cc: Linus Walleij
> > Cc: Alexandre Courbot
> > Cc: Thierry Reding
> > Signed-off-by: Shobhit Kumar
From: Thierry Reding
Instead of going through the DMA mapping API for cache maintenance, use
the drm_clflush_*() family of functions to achieve the same effect.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/Kconfig | 1 +
drivers/gpu/drm/tegra/gem.c | 42
From: Thierry Reding
Irrespective of whether or not the DRM core is built as a module, build
the cache flush functions into the kernel. This is required because the
implementation may require functions that shouldn't be exported to most
drivers. DRM is somewhat of a special case here becau
From: Thierry Reding
Instead of going through the DMA mapping API for cache maintenance, use
the drm_clflush_*() family of functions to achieve the same effect.
Cc: Russell King
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/armada/Kconfig | 1 +
drivers/gpu/drm/armada/armada_gem.c
From: Thierry Reding
Add implementations for drm_clflush_*() on ARM by borrowing code from
the DMA mapping API implementation. Unfortunately ARM doesn't export an
API to flush caches on a page by page basis, so this replicates most of
the code.
Reviewed-by: Rob Clark
Tested-by: Rob
From: Thierry Reding
Add implementations for drm_clflush_*() on 64-bit ARM. This shares a lot
of code with the 32-bit ARM implementation.
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_cache.c | 15 +--
1 file changed, 13 insertions
From: Thierry Reding
Instead of going through the DMA mapping API for cache maintenance, use
the drm_clflush_*() family of functions to achieve the same effect.
Cc: Rob Clark
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/msm_gem.c | 9 +
2
On Tue, Oct 14, 2014 at 08:50:35AM -0700, Sean V Kelley wrote:
> On Tue, Oct 14, 2014 at 4:53 AM, Thierry Reding
> wrote:
> > On Mon, Oct 13, 2014 at 08:15:00PM +0800, Yao Cheng wrote:
> >> drm/ipvr is a new GEM driver for baytrail's vxd392, which accelerates VP8
>
On Wed, Oct 22, 2014 at 11:45:23AM +0530, sonika.jin...@intel.com wrote:
> From: Sonika Jindal
>
> v2: Reading DP_EDP_REV, only when DISPLAY_CONTROL_CAPABLE field is set
> (Satheesh)
>
> v3: Moving the utility function to drm_dp_helper (Daniel)
>
> Signed-off-by: Sonika Jindal
> ---
> driver
ately.
v2: Fix adjacent spelling error Sean noticed.
Reviewed-by: Sean Paul
Cc: Sean Paul
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 4
include/drm/drm_crtc.h | 28 ++--
2 files changed, 18 insertions(+), 14 deletions(-)
Reviewed-by:
On Fri, Oct 31, 2014 at 05:06:39PM +0100, Daniel Vetter wrote:
> On Wed, Oct 29, 2014 at 02:42:29PM +0100, Thierry Reding wrote:
> > On Wed, Oct 22, 2014 at 11:45:23AM +0530, sonika.jin...@intel.com wrote:
> > > From: Sonika Jindal
> > >
> > &g
--
> include/drm/drm_modeset_lock.h | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Thierry Reding
pgppBCD1OCi7y.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Sun, Nov 02, 2014 at 02:19:18PM +0100, Daniel Vetter wrote:
[...]
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index a68e02be7e37..9847009ad451 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -224,6 +224,25 @@ struct drm_encoder;
> struct drm_pendin
On Mon, Nov 03, 2014 at 12:07:02AM +0100, Daniel Vetter wrote:
[...]
> diff --git a/include/drm/drm_modeset_lock.h b/include/drm/drm_modeset_lock.h
> index 28931a23d96c..70595ff565ba 100644
> --- a/include/drm/drm_modeset_lock.h
> +++ b/include/drm/drm_modeset_lock.h
> @@ -127,11 +127,13 @@ void dr
On Wed, Nov 19, 2014 at 06:38:08PM +0100, Daniel Vetter wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
[...]
> @@ -304,6 +306,21 @@ drm_atomic_get_connector_state(struct drm_atomic_state
> *state,
>
> index = drm_connector_index(connector);
>
> +
DRM_DEBUG_KMS("Hot-added connector would overflow state array,
> restarting\n");
> - return -EAGAIN;
> + return ERR_PTR(-EAGAIN);
> }
>
> if (state->connector_states[index])
=)
Reviewed-by: Thierry Reding
pgpBDfnarHPdO.pgp
Description: PG
On Sat, Nov 22, 2014 at 03:10:01AM +0800, Yao Cheng wrote:
> on vlv, if ipvr is installed, it need be manually unloaded before
> i915, otherwise user might run into use-after-free issue.
Huh? That doesn't sound right. What exactly is it that's going wrong?
You should never have to do this. If you
On Fri, Nov 21, 2014 at 09:36:33PM +0100, Daniel Vetter wrote:
> On Fri, Nov 21, 2014 at 09:27:04PM +0100, Thierry Reding wrote:
> > On Sat, Nov 22, 2014 at 03:10:01AM +0800, Yao Cheng wrote:
> > > on vlv, if ipvr is installed, it need be manually unloaded before
> > >
On Mon, Dec 15, 2014 at 03:45:34PM +0100, Daniel Vetter wrote:
> On Fri, Dec 12, 2014 at 07:06:24PM +0200, Ville Syrjälä wrote:
> > On Fri, Dec 12, 2014 at 05:57:38PM +0200, Imre Deak wrote:
> > > After
> > >
> > > commit a18c0af171bfb875012da26f23df0510
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
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
There's no need for this to be modifiable. Make it const so that it can
be put into the .rodata section.
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
drivers/gpu/drm/ast/ast_fb.c
enum generic instead of HDMI/CEA specfic
> - Removed usage of temporary aspect_ratio variable
>
> v3: Thierry's review comments.
> - Fixed indentation
>
> v4: Thierry's review comments.
> - Return ENOMEM when property creation fails
&g
On Wed, Jul 30, 2014 at 05:32:28PM +0900, Michel Dänzer wrote:
> On 30.07.2014 17:22, Daniel Vetter wrote:
> > On Wed, Jul 30, 2014 at 11:59:33AM +0900, Michel Dänzer wrote:
> >> On 30.07.2014 06:32, Daniel Vetter wrote:
> >>> + * due to lack of driver support or because the crtc is off.
> >>> + */
On Tue, Jul 29, 2014 at 11:32:22PM +0200, Daniel Vetter wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
[...]
> + ret = wait_event_timeout(dev->vblank[crtc].queue,
> + C, msecs_to_jiffies(100));
100 milliseconds looks like a very a
On Wed, Jul 30, 2014 at 05:06:38PM +0200, Daniel Vetter wrote:
> On Wed, Jul 30, 2014 at 04:24:06PM +0200, Thierry Reding wrote:
> > On Tue, Jul 29, 2014 at 11:32:22PM +0200, Daniel Vetter wrote:
> > [...]
> > > diff --git a/drivers/gpu/drm/drm_irq.c b/d
On Wed, Jul 30, 2014 at 05:36:21PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 30, 2014 at 04:20:25PM +0200, Thierry Reding wrote:
> > On Wed, Jul 30, 2014 at 05:32:28PM +0900, Michel Dänzer wrote:
> > > On 30.07.2014 17:22, Daniel Vetter wrote:
> > > > On Wed, Ju
for an address-only I2C_WRITE_STATUS_UPDATE.
>
> Cc: Thierry Reding
> Cc: "Terje Bergström"
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/tegra/dpaux.c | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Thierry Reding
signature.asc
Description: PGP signature
__
ether a plane gets a new CRTC assigned while
> still in active use out of this patch.
>
> v4: Rebase over exynos changes.
>
> Cc: Maarten Lankhorst
> Cc: Thierry Reding
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic_he
On Mon, Sep 14, 2015 at 10:43:42PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Finish the recent replacement of 'int pipe' with 'unsigned int pipe'
>
> Cc: Thierry Reding
> Signed-off-by: Ville Syrjälä
> ---
> drivers/
On Mon, Sep 14, 2015 at 10:43:51PM +0300, ville.syrj...@linux.intel.com wrote:
[...]
> @@ -167,7 +238,7 @@ static void drm_update_vblank_count(struct drm_device
> *dev, unsigned int pipe,
> if (!rc)
> t_vblank = (struct timeval) {0, 0};
>
> - store_vblank(dev, pipe, diff,
On Tue, May 05, 2015 at 03:08:36PM +0530, Shobhit Kumar wrote:
> The Crystalcove PMIC controls PWM signals and this driver exports that
You say signal_s_ here, but you only expose a single PWM device. Does
the PMIC really control more than one? If it isn't, this should probably
become: "controls a
subject line (Lee jones)
>
> CC: Samuel Ortiz
> Cc: Linus Walleij
> Cc: Alexandre Courbot
> Cc: Thierry Reding
> Signed-off-by: Shobhit Kumar
> ---
> drivers/pwm/core.c | 17 +
> include/linux/pwm.h | 5 +
> 2 files changed, 22 insertions(+
27;s a
> bunch of discussions going on about how exactly the additional aux
> planes for render compression should be specified.
>
> So let's first make sure that the values in those additional fields
> can be indeed used.
>
> Cc: Thierry Reding
> Testcase: igt/kms_addfb
From: Thierry Reding
None of the drivers use this in legacy mode, so it can be converted to
use struct drm_crtc * directly. While at it, also make the sole user of
the callback, drm_calc_vbltimestamp_from_scanoutpos(), pass through the
CRTC directly.
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Ben
On Mon, Nov 24, 2014 at 02:14:48PM +0100, Daniel Vetter wrote:
> On Mon, Nov 24, 2014 at 10:55:46AM +0100, Thierry Reding wrote:
> > On Fri, Nov 21, 2014 at 09:36:33PM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 21, 2014 at 09:27:04PM +0100, Thierry Reding wrote:
> > >
On Mon, Dec 01, 2014 at 03:06:08AM +, Cheng, Yao wrote:
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Monday, November 24, 2014 21:15
> > To: Thierry Reding
> > Cc:
On Thu, Dec 18, 2014 at 05:44:37AM +, Cheng, Yao wrote:
> > -Original Message-
> > From: Thierry Reding [mailto:thierry.red...@gmail.com]
> > Sent: Wednesday, December 17, 2014 16:13
> > To: Cheng, Yao
> > Cc: Daniel Vetter; intel-gfx@list
On Tue, Jan 13, 2015 at 12:08:11AM +0100, Daniel Vetter wrote:
> On Fri, Jan 9, 2015 at 1:50 PM, Jani Nikula wrote:
> > I have a slightly uneasy feeling about handing out drm_panel pointers
> > (both from here and of_drm_find_panel) without refcounting. If the panel
> > driver gets removed, whoeve
* struct struct drm_atomic_state - the global state object for atomic
> updates
> * @dev: parent DRM device
> * @allow_modeset: allow full modeset
> + * @allow_modeset: hint to enforce legacy cursor ioctl semantics
This should be legacy_cursor_update. With that fixed
y on success, NULL on failure.
> + */
> +struct drm_property *drm_property_create_bool(struct drm_device *dev, int
> flags,
I find that int is a strange type for flags. unsigned long is a little
more idiomatic in my opinion. But again all other functions seem to do
the sa
On Thu, Jan 22, 2015 at 08:04:33AM +0100, Daniel Vetter wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
[...]
> @@ -1391,6 +1395,12 @@ static int drm_mode_create_standard_properties(struct
> drm_device *dev)
> return -ENOMEM;
> dev->mode_conf
From: Thierry Reding
The current implementation is limited by the number of addresses that
fit into an unsigned long. This causes problems on 32-bit Tegra where
unsigned long is 32-bit but drm_mm is used to manage an IOVA space of
4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB
On Tue, Jan 27, 2015 at 07:07:44AM +0100, Thomas Hellstrom wrote:
> On 01/26/2015 11:51 PM, Dave Airlie wrote:
> > On 23 January 2015 at 18:05, Thierry Reding
> > wrote:
> >> From: Thierry Reding
> >>
> >> The current implementation is limited by the
nel, &panel_list, list) {
> + if (strcmp(panel->name, name) == 0) {
> + mutex_unlock(&panel_lock);
> + return panel;
> + }
> + }
> +
> + mutex_unlock(&panel_lock);
> + return NULL;
> +}
> +EXPORT
On Wed, Jan 21, 2015 at 04:48:11PM +0530, Shobhit Kumar wrote:
> On BYT-T configuration, panel enable/disable signals are routed through
> PMIC. Add a cell device for the same.
>
> Signed-off-by: Shobhit Kumar
> ---
> drivers/mfd/intel_soc_pmic_crc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
On Wed, Jan 21, 2015 at 04:48:12PM +0530, Shobhit Kumar wrote:
> This driver provides support for the "crystal_cove_panel" cell device.
> On BYT-T pmic has to be used to enable/disable panel.
>
> v2: Addressed Jani's comments
> - Moved inside i915
> - Correct licensing
> - Remove unuse
ed
> + * below. The lower 56 bits are assigned as vendor sees fit.
> + */
> +
> +/* Vendor Ids: */
> +#define DRM_FORMAT_MOD_NONE 0
> +#define DRM_FORMAT_MOD_VENDOR_INTEL 0x01
> +#define DRM_FORMAT_MOD_VENDOR_AMD 0x02
> +#define DRM_FORMAT_MOD_VENDOR_NV 0x03
I think this should be NVIDIA for consistency with other naming in the
kernel, at least on Tegra.
Otherwise:
Reviewed-by: Thierry Reding
pgp7xmWLHJAyV.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, Jul 15, 2015 at 06:39:26PM +0530, Kausal Malladi wrote:
[...]
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 57ca8cc..408d39a 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1178,6 +1178,12 @@ struct drm_mode_config {
> struct drm_pro
On Thu, Jul 23, 2015 at 09:38:46AM +0200, Daniel Vetter wrote:
[...]
> On Thu, Jul 23, 2015 at 9:31 AM, Daniel Vetter wrote:
[...]
> > Shobhit Kumar (8):
[...]
> > pwm: crc: Add Crystalcove (CRC) PWM driver
Would you mind removing this from your branch? I ended up manually
applying a couple
On Thu, Jul 23, 2015 at 04:34:58PM -0700, Rodrigo Vivi wrote:
> By Vesa's DP 1.2 Spec this counter has 4 bits [3:0].
>
> This mask is wrong since when the counter was introduced by myself
> on commit ad9dc91b6e21266bfc6f466db4b95e10211f31ee
> Author: Rodrigo Vivi
> Date: Tue Sep 16 19:18:12 201
On Mon, Jul 27, 2015 at 03:09:54PM +0200, Daniel Vetter wrote:
> On Mon, Jul 27, 2015 at 01:21:01PM +0200, Thierry Reding wrote:
> > On Thu, Jul 23, 2015 at 09:38:46AM +0200, Daniel Vetter wrote:
> > [...]
> > > On Thu, Jul 23, 2015 at 9:31 AM, Dan
DRM_DEBUG_KMS("failed to dpcd write %d %d\n", tosend,
> ret);
> - WARN(1, "fail\n");
>
> return -EIO;
> }
Reviewed-by: Thierry Reding
signature.asc
Description: PGP signature
easy. Perhaps a more verbose description could be provided in
done in the DRM DocBook, along with other documentation about atomic
mode-setting.
Irrespective of that, this makes sense, so:
Acked-by: Thierry Reding
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
crtc_state->mode_changed = true;
> - }
> + crtc_state = state->crtc_states[idx];
> + crtc_state->mode_changed = true;
>
> DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on
> [CRTC:%d]\n",
>
>
> Cc: Michel Dänzer
> Reported-by: Michel Dänzer
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_irq.c | 2 +-
> include/drm/drmP.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Thierry Reding
signature.asc
Description: PG
ed
> variant (since the drm core still cares).
>
> While at it also fix a leak when this ioctl is called on an imported
> buffer.
I don't see where the leak's fixed, but other than that this looks good
to me. Shall I pick this up into the drm/tegra tree?
Thierry
>
files changed, 2 insertions(+), 16 deletions(-)
Reviewed-by: Thierry Reding
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, Jul 09, 2015 at 11:32:35PM +0200, Daniel Vetter wrote:
> BUG_ON kills the driver, WARN_ON is much friendly. And usually nothing
> bad happens when the locking is lightly busted.
s/much friendly/much friendlier/, s/lightly/slightly/?
Otherwise:
Reviewed-by: Thierry
301 - 400 of 431 matches
Mail list logo
