On Tue, Oct 25, 2016 at 12:19:29AM +0100, Robert Bragg wrote:
> +static int claim_specific_ctx(struct i915_perf_stream *stream)
> +{
> + struct drm_i915_private *dev_priv = stream->dev_priv;
> + struct i915_vma *vma;
> + int ret;
> +
> + ret = i915_mutex_lock_interruptible(&dev_priv
On Wed, Oct 26, 2016 at 12:05:44AM +0100, Chris Wilson wrote:
> On Tue, Oct 25, 2016 at 12:19:29AM +0100, Robert Bragg wrote:
> > + /* So that we don't have to worry about updating the context ID
> > +* in OACONTOL on the fly we make sure to pin the context
> > +* upfront for the lifetime
gt; > + vma = stream->ctx->engine[RCS].state;
> > + ret = i915_vma_pin(vma, 0, stream->ctx->ggtt_alignment,
> > + PIN_GLOBAL | PIN_HIGH);
> > + if (ret)
> > + return ret;
> > +
> > + dev_priv->perf.oa.specific_ctx_id = i915_ggtt_offset(vma);
> > +
> > + mutex_unlock(&dev_priv->drm.struct_mutex);
> > +
> > + return 0;
> > +}
>
I'll also follow up on the other notes; thanks!
- Robert
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161026/1e6cbaf7/attachment.html>
On 25/10/16 15:14, Jean-Francois Moine wrote:
> On Mon, 24 Oct 2016 16:04:19 +0200
> Maxime Ripard wrote:
>
>> Hi,
>
> Hi Maxime,
>
>> On Fri, Oct 21, 2016 at 09:26:18AM +0200, Jean-Francois Moine wrote:
>>> Allwinner's recent SoCs, as A64, A83T and H3, contain a new display
>>> engine, DE2.
>>
https://bugzilla.kernel.org/show_bug.cgi?id=178281
--- Comment #11 from fin4478 at hotmail.com ---
I made TF2 gaming stable by disabling kernel debugging and setting cpu timer
to 300Hz.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hi Christian,
On 25 October 2016 at 17:55, Christian König
wrote:
> Hi Sumit,
>
> sending this once more with all the patches in once set, cause the last one
> turned out to be a bit chaotic because I send from the wrong branch.
>
> The following patch set fixes the handling in the fence and r
From: Magnus Damm
For the DU to operate on R-Car Gen3 hardware a combination of DU
and VSP devices are required. Since the DU driver also supports
earlier generations hardware the VSP portion is enabled via Kconfig.
The arm64 defconfig is as of v4.9-rc1 having the DU driver enabled
as a module,
On Tue, Oct 25, 2016 at 07:31:29PM +0200, Luis R. Rodriguez wrote:
> On Mon, Oct 24, 2016 at 04:31:45PM +1000, Dave Airlie wrote:
> > A recent change to the mm code in:
> > 87744ab3832b83ba71b931f86f9cfdb000d07da5
> > mm: fix cache mode tracking in vm_insert_mixed()
> >
> > started enforcing check
On Tue, Oct 25, 2016 at 06:16:34PM -0700, Manasi Navare wrote:
> A new optional connector property is added for keeping
> track of whether the link is good (link training passed) or
> link is bad (link training failed). If the link status property
> is Bad, then userspace should fire off a new mod
On Wed, Oct 26, 2016 at 10:37:00AM +0800, Rongrong Zou wrote:
> Add support for fbdev and kms fb management.
>
> Signed-off-by: Rongrong Zou
Small drive-by comment below.
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> index
Hi Andrzej,
On 10/10/2016 01:09 PM, Andrzej Hajda wrote:
> SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
> It is controlled via I2C bus. Its interaction with other
> devices in video pipeline is performed mainly on HW level.
> The only interaction it does on device driver level is
> f
>>
>> Is anything on a driver to be able to tell when this is actually needed ?
>> How will driver developers know? Can you add a bit of documentation to
>> the API? If its transitive towards a secondary solution indicating so
>> would help driver developers.
>
> I'll plug the io-mapping stuff agai
Hi Archit,
On 26.10.2016 08:01, Archit Taneja wrote:
> Hi Andrzej,
>
> On 10/10/2016 01:09 PM, Andrzej Hajda wrote:
>> SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
>> It is controlled via I2C bus. Its interaction with other
>> devices in video pipeline is performed mainly on HW level
Hi, Jitao:
On Tue, 2016-10-25 at 13:40 +0800, Jitao Shi wrote:
> Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
> Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
> signal will cause h-time larger than normal and reduce FPS.
> Need to multiply
Hi Linus,
This is a standalone pull request for the fix for a regression introduced
in -rc1 by a change to vm_insert_mixed to start using the PAT range tracking
to validate page protections. With this fix in place, all the VRAM mappings
for GPU drivers ended up at UC instead of WC.
There are prob
On Wed, Oct 26, 2016 at 8:12 AM, Dave Airlie wrote:
>>> Is anything on a driver to be able to tell when this is actually needed ?
>>> How will driver developers know? Can you add a bit of documentation to
>>> the API? If its transitive towards a secondary solution indicating so
>>> would help driv
On Wed, Oct 26, 2016 at 5:31 AM, Magnus Damm wrote:
> From: Magnus Damm
>
> For the DU to operate on R-Car Gen3 hardware a combination of DU
> and VSP devices are required. Since the DU driver also supports
> earlier generations hardware the VSP portion is enabled via Kconfig.
>
> The arm64 defco
On Wed, Oct 26, 2016 at 5:31 AM, Magnus Damm wrote:
> The arm64 defconfig is as of v4.9-rc1 having the DU driver enabled
> as a module, however this is not enough to support R-Car Gen3. In
Nope, arm64 defconfig on v4.9-rc1:
# CONFIG_DRM_RCAR_DU is not set
Gr{oetje,eeting}s,
On 10/26/2016 01:58 AM, Stephen Boyd wrote:
> On 10/25, Archit Taneja wrote:
>> The DSI/HDMI PLLs in MSM require resources like interface clocks, power
>> domains to be enabled before we can access their registers.
>>
>> The clock framework doesn't have a mechanism at the moment where we can
>> t
On Tue, Oct 25, 2016 at 10:28:08PM +0100, Chris Wilson wrote:
> From: Felix Monninger
>
> drm_property_lookup_blob() returns a reference to the returned blob, and
> drm_atomic_replace_property_blob() takes a references to the blob it
> stores, so afterwards we are left owning a reference to the n
On 10/07/2016 12:32 PM, Andrzej Hajda wrote:
> This header adds definitions specific to MHL protocol.
queued to drm-misc.
Thanks,
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
On 10/07/2016 12:32 PM, Andrzej Hajda wrote:
> SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0. It is controlled
> via I2C bus.
queued to drm-misc.
Thanks,
Archit
>
> Signed-off-by: Andrzej Hajda
> Acked-by: Rob Herring
> ---
> .../bindings/video/bridge/sil-sii8620.txt |
On 10/10/2016 01:09 PM, Andrzej Hajda wrote:
> SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
> It is controlled via I2C bus. Its interaction with other
> devices in video pipeline is performed mainly on HW level.
> The only interaction it does on device driver level is
> filtering-ou
https://bugzilla.kernel.org/show_bug.cgi?id=176311
--- Comment #4 from Michel Dänzer ---
Does this still happen with current xf86-video-ati Git, or at least the 7.7.1
release?
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Wed, Oct 26, 2016 at 10:48:07AM +0300, Ville Syrjälä wrote:
> On Tue, Oct 25, 2016 at 10:28:08PM +0100, Chris Wilson wrote:
> > From: Felix Monninger
> >
> > drm_property_lookup_blob() returns a reference to the returned blob, and
> > drm_atomic_replace_property_blob() takes a references to
On Tue, Oct 25, 2016 at 10:17:47AM +0200, Takashi Iwai wrote:
> On Tue, 25 Oct 2016 10:09:30 +0200,
> Daniel Vetter wrote:
> >
> > On Tue, Oct 25, 2016 at 08:46:28AM +0200, Takashi Iwai wrote:
> > > On Fri, 21 Oct 2016 14:52:07 +0200,
> > > Ville Syrjälä wrote:
> > > >
> > > > On Thu, Oct 20, 2
On Tue, Oct 25, 2016 at 02:25:08PM +0200, Christian König wrote:
> From: Christian König
>
> Kernel functions taking a timeout usually return 1 on success even
> when they get a zero timeout.
Which? The canonical example of schedule_timeout() doesn't behave like
this.
> Signen-off-by: Christi
On Wed, Oct 26, 2016 at 12:51:58AM +0100, Robert Bragg wrote:
>On Tue, Oct 25, 2016 at 10:35 PM, Matthew Auld
><[1]matthew.william.auld at gmail.com> wrote:
>
> On 25 October 2016 at 00:19, Robert Bragg <[2]robert at sixbynine.org>
> wrote:
>
>Â
>
> > diff --git a/dri
Hi,
This is an updated RFC series introducing a new connector type:
DRM_MODE_CONNECTOR_WRITEBACK
See v1 here: [1]
Writeback connectors are used to expose the memory writeback engines
found in some display controllers, which can write a CRTC's
composition result to a memory buffer.
This is useful
It's possible for CVAL to get set whilst we are in config mode. If this
happens, afer we leave config mode the HW will latch whatever
configuration is in the registers at the next vsync. Most likely this
will be a partial configuration, as we'll be racing against the ongoing
atomic_commit.
To avoi
We're going to use the same format list for output formats, so rename
everything related to input formats to avoid confusion.
Signed-off-by: Brian Starkey
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_hw.c | 24
drivers/gpu/drm/arm/malidp_hw.h |8
Writeback connectors represent writeback engines which can write the
CRTC output to a memory framebuffer. Add a writeback connector type and
related support functions.
Drivers should initialize a writeback connector with
drm_writeback_connector_init() which takes care of setting up all the
writeba
Add a layer bit for the SE memory-write, and add it to the pixel format
matrix for DP550/DP650.
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/arm/malidp_hw.c | 28 ++--
drivers/gpu/drm/arm/malidp_hw.h |1 +
2 files changed, 15 insertions(+), 14 deletions(-)
diff
Add the OUT_FENCE_PTR property to writeback connectors, to enable
userspace to get a fence which will signal once the writeback is
complete.
A timeline is added to drm_connector for use by the writeback
out-fences. It is up to drivers to check for a fence in the
connector_state and signal the it a
Mali-DP has a memory writeback engine which can be used to write the
composition result to a memory buffer.
Expose this functionality as a DRM writeback connector on supported
hardware.
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/arm/Makefile |1 +
drivers/gpu/drm/arm/malidp_crtc.c
From: Liviu Dudau
Mali-DP display processors are able to write the composition result to a
memory buffer via the SE.
Add entry points in the HAL for enabling/disabling this feature, and
implement support for it on DP650 and DP550. DP500 acts differently and
so is omitted from this change.
Signe
Some parts of setting up the CRTC out-fence can be re-used for
writeback out-fences. Factor this out into a separate function.
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/drm_atomic.c | 64 +++---
1 file changed, 42 insertions(+), 22 deletions(-)
diff
If userspace has asked for an out-fence for the writeback, we add a
fence to malidp_mw_job, to be signaled when the writeback job has
completed.
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/arm/malidp_hw.c |5 -
drivers/gpu/drm/arm/malidp_mw.c | 18 +-
drivers/gpu/d
The newly added drm_of_component_match_add helper is defined as
'static' in a header when CONFIG_OF is disabled, causing a warning
each time the header is included:
In file included from /git/arm-soc/drivers/gpu/drm/bridge/dw-hdmi.c:23:0:
include/drm/drm_of.h:33:13: error: 'drm_of_component_match_
From: Ville Syrjälä
This series would appear to be enough to avoid kernel oopses when trying
to restore the fbdev setup after a MST device has been yanked.
Apparently we still have some problems left in actually reacting properly
to the changed situation, but at least the kernel no longer expl
From: Ville Syrjälä
We need to drop the connector references already taken when we
abort in the middle of drm_fb_helper_single_add_all_connectors()
Cc: stable at vger.kernel.org
Cc: Carlos Santa
Cc: Kirill A. Shutemov
Tested-by: Carlos Santa
Tested-by: Kirill A. Shutemov
Signed-off-by: Vil
From: Ville Syrjälä
The fbdev helper code keeps around two lists of connectors. One is the
list of all connectors it could use, and that list already holds
references for all the connectors. However the other list, or rather
lists, is the one actively being used. That list is tracked per-crtc
a
From: Ville Syrjälä
The i2c adapter is only relevant for some peer device types, so
let's clear the pdt if it's still the same as the old_pdt when we
tear down the i2c adapter.
I don't really like this design pattern of updating port->whatever
before doing the accompanying changes and passing
From: Ville Syrjälä
Only certain types of pdts have the DDC bus registered, so check for
that before we attempt the EDID read. Othwewise we risk playing around
with an i2c adapter that doesn't actually exist.
Cc: stable at vger.kernel.org
Cc: Carlos Santa
Cc: Kirill A. Shutemov
Tested-by: Ca
On Wed, 2016-10-26 at 14:41 +0800, CK Hu wrote:
> Hi, Jitao:
>
> On Tue, 2016-10-25 at 13:40 +0800, Jitao Shi wrote:
> > Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
> > Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
> > signal will cause
Hi Geert,
On Wed, Oct 26, 2016 at 4:31 PM, Geert Uytterhoeven
wrote:
> On Wed, Oct 26, 2016 at 5:31 AM, Magnus Damm wrote:
>> From: Magnus Damm
>>
>> For the DU to operate on R-Car Gen3 hardware a combination of DU
>> and VSP devices are required. Since the DU driver also supports
>> earlier ge
On Tue, Oct 25, 2016 at 06:19:47PM -0700, Manasi Navare wrote:
> Chris,
>
> Would you be able to make the necessary changes in the suerspace
> driver so I can do some testing tomorrow?
>
> Manasi
>
> On Tue, Oct 25, 2016 at 06:16:34PM -0700, Manasi Navare wrote:
> > A new optional connector prop
Hi, Jitao:
On Wed, 2016-10-26 at 16:59 +0800, Jitao Shi wrote:
> Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
> Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
> signal will cause h-time larger than normal and reduce FPS.
> Need to multiply
On Wed, Oct 26, 2016 at 07:52:26AM +0200, Daniel Vetter wrote:
> I'd go further and just always create this as one of the standard
> properties (and always attach it to the connector, like edid), and only
> expose helpers to set the link status to good or bad.
One of the sketches for this idea was
On Wed, Oct 26, 2016 at 12:05:52PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> We need to drop the connector references already taken when we
> abort in the middle of drm_fb_helper_single_add_all_connectors()
>
> Cc: stable at vger.kernel.org
> Cc: Carlos Santa
>
On Wed, 26 Oct 2016, Chris Wilson wrote:
> On Wed, Oct 26, 2016 at 07:52:26AM +0200, Daniel Vetter wrote:
>> I'd go further and just always create this as one of the standard
>> properties (and always attach it to the connector, like edid), and only
>> expose helpers to set the link status to good
On Wed, Oct 26, 2016 at 12:05:53PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> The fbdev helper code keeps around two lists of connectors. One is the
> list of all connectors it could use, and that list already holds
> references for all the connectors. However the
es/dri-devel/attachments/20161026/402b84f9/attachment.html>
On Wed, Oct 26, 2016 at 09:55:00AM +0100, Brian Starkey wrote:
> Writeback connectors represent writeback engines which can write the
> CRTC output to a memory framebuffer. Add a writeback connector type and
> related support functions.
>
> Drivers should initialize a writeback connector with
> dr
On Wed, Oct 26, 2016 at 09:55:06AM +0100, Brian Starkey wrote:
> Some parts of setting up the CRTC out-fence can be re-used for
> writeback out-fences. Factor this out into a separate function.
>
> Signed-off-by: Brian Starkey
Cc: Gustavo here pls, probably best if he reviews this one.
-Daniel
On Wed, Oct 26, 2016 at 09:55:07AM +0100, Brian Starkey wrote:
> Add the OUT_FENCE_PTR property to writeback connectors, to enable
> userspace to get a fence which will signal once the writeback is
> complete.
>
> A timeline is added to drm_connector for use by the writeback
> out-fences. It is up
Hi Gustavo,
As Daniel rightly pointed out you would likely be interested in this
patch.
This is on-top of your v5 patch-set, with the bug-fixes I mentioned
before. I haven't dropped the fence_get(), as I figured you're
probably going to rebase your patches on top of the fence_get() in
sync_file_c
There is no reason to not free the notify data if the NTFY_DEL ioctl
failed. As nvif_notify_fini() is also called from the cleanup path of
nvif_notify_init(), the notifier may not have been successfully created
at that point. But it should also be the right thing to just free the
data in the regula
On Wed, Oct 26, 2016 at 12:51:41PM +0300, Jani Nikula wrote:
> On Wed, 26 Oct 2016, Chris Wilson wrote:
> > On Wed, Oct 26, 2016 at 07:52:26AM +0200, Daniel Vetter wrote:
> >> I'd go further and just always create this as one of the standard
> >> properties (and always attach it to the connector,
On Wed, Oct 26, 2016 at 10:52:24AM +0100, Chris Wilson wrote:
> On Wed, Oct 26, 2016 at 12:05:53PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrjälä
> >
> > The fbdev helper code keeps around two lists of connectors. One is the
> > list of all connectors it could use, an
https://bugzilla.kernel.org/show_bug.cgi?id=117181
Jani Nikula changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Wed, Oct 26, 2016 at 01:00:21PM +0200, Daniel Vetter wrote:
>On Wed, Oct 26, 2016 at 09:55:00AM +0100, Brian Starkey wrote:
>> Writeback connectors represent writeback engines which can write the
>> CRTC output to a memory framebuffer. Add a writeback connector type and
>> related support functi
Hi Gustavo,
It would be great if you could cast your eye over this one as-well.
My intention was to be as similar to the CRTC out-fences as possible.
Thanks,
Brian
On Wed, Oct 26, 2016 at 09:55:07AM +0100, Brian Starkey wrote:
>Add the OUT_FENCE_PTR property to writeback connectors, to enable
>u
On Wed, Oct 26, 2016 at 12:05:55PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Only certain types of pdts have the DDC bus registered, so check for
> that before we attempt the EDID read. Othwewise we risk playing around
> with an i2c adapter that doesn't actually
On Wed, Oct 26, 2016 at 05:19:31PM +0800, Rongrong Zou wrote:
> Hi Daniel,
>
> Thansk for reviewing!
>
> å¨ 2016/10/26 13:56, Daniel Vetter åé:
> > On Wed, Oct 26, 2016 at 10:37:00AM +0800, Rongrong Zou wrote:
> > > Add support for fbdev and kms fb management.
> > >
> > > Signed-off-by: Ron
On Wed, Oct 26, 2016 at 02:53:01PM +0200, Daniel Vetter wrote:
> On Wed, Oct 26, 2016 at 12:05:54PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrjälä
> >
> > The i2c adapter is only relevant for some peer device types, so
> > let's clear the pdt if it's still the same as
On Wed, Oct 26, 2016 at 12:05:54PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> The i2c adapter is only relevant for some peer device types, so
> let's clear the pdt if it's still the same as the old_pdt when we
> tear down the i2c adapter.
>
> I don't really like
On Wed, Oct 26, 2016 at 01:42:42PM +0100, Brian Starkey wrote:
> On Wed, Oct 26, 2016 at 01:00:21PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 26, 2016 at 09:55:00AM +0100, Brian Starkey wrote:
> > > diff --git a/drivers/gpu/drm/drm_writeback.c
> > > b/drivers/gpu/drm/drm_writeback.c
> > > new fi
On Wed, Oct 26, 2016 at 02:55:14PM +0200, Daniel Vetter wrote:
> On Wed, Oct 26, 2016 at 12:05:55PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrjälä
> >
> > Only certain types of pdts have the DDC bus registered, so check for
> > that before we attempt the EDID read. Ot
On Wed, Oct 26, 2016 at 02:17:16PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 26, 2016 at 12:51:41PM +0300, Jani Nikula wrote:
> > On Wed, 26 Oct 2016, Chris Wilson wrote:
> > > On Wed, Oct 26, 2016 at 07:52:26AM +0200, Daniel Vetter wrote:
> > >> I'd go further and just always create this as one
On Wed, Oct 26, 2016 at 02:11:00PM +0100, Chris Wilson wrote:
> On Wed, Oct 26, 2016 at 02:17:16PM +0300, Ville Syrjälä wrote:
> > On Wed, Oct 26, 2016 at 12:51:41PM +0300, Jani Nikula wrote:
> > > On Wed, 26 Oct 2016, Chris Wilson wrote:
> > > > On Wed, Oct 26, 2016 at 07:52:26AM +0200, Daniel
Am 26.10.2016 um 10:49 schrieb Chris Wilson:
> On Tue, Oct 25, 2016 at 02:25:08PM +0200, Christian König wrote:
>> From: Christian König
>>
>> Kernel functions taking a timeout usually return 1 on success even
>> when they get a zero timeout.
> Which? The canonical example of schedule_timeout()
On Wed, Oct 26, 2016 at 04:15:39PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 26, 2016 at 02:11:00PM +0100, Chris Wilson wrote:
> > On Wed, Oct 26, 2016 at 02:17:16PM +0300, Ville Syrjälä wrote:
> > > On Wed, Oct 26, 2016 at 12:51:41PM +0300, Jani Nikula wrote:
> > > > On Wed, 26 Oct 2016, Chris
From: Ville Syrjälä
The i2c adapter is only relevant for some peer device types, so
let's clear the pdt if it's still the same as the old_pdt when we
tear down the i2c adapter.
I don't really like this design pattern of updating port->whatever
before doing the accompanying changes and passing
From: Ville Syrjälä
The fbdev helper code keeps around two lists of connectors. One is the
list of all connectors it could use, and that list already holds
references for all the connectors. However the other list, or rather
lists, is the one actively being used. That list is tracked per-crtc
a
On Wed, Oct 26, 2016 at 04:30:33PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> The i2c adapter is only relevant for some peer device types, so
> let's clear the pdt if it's still the same as the old_pdt when we
> tear down the i2c adapter.
>
> I don't really like
On Wed, Oct 26, 2016 at 12:05:51PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> This series would appear to be enough to avoid kernel oopses when trying
> to restore the fbdev setup after a MST device has been yanked.
>
> Apparently we still have some problems left
Use core helpers to generate infoframes and generate vendor frame if necessary.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 141 ++-
drivers/gpu/drm/exynos/regs-hdmi.h | 2 +
2 files changed, 42 insertions(+), 101 deletions(-)
diff
On Wed, Oct 26, 2016 at 04:31:20PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> The fbdev helper code keeps around two lists of connectors. One is the
> list of all connectors it could use, and that list already holds
> references for all the connectors. However the
On Wed, Oct 26, 2016 at 04:35:50PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 26, 2016 at 04:30:33PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrjälä
> >
> > The i2c adapter is only relevant for some peer device types, so
> > let's clear the pdt if it's still the same
I have just tested it on my board, no regression :-)
Acked-by: Benjamin Gaignard
2016-10-25 22:53 GMT+02:00 Sean Paul :
> On Tue, Oct 25, 2016 at 10:43 AM, Ville Syrjälä
> wrote:
>> On Mon, Oct 10, 2016 at 03:19:47PM +0300, ville.syrjala at linux.intel.com
>> wrote:
>>> From: Ville Syrjälä
On Wed, Oct 26, 2016 at 02:54:45PM +0100, Chris Wilson wrote:
> On Wed, Oct 26, 2016 at 04:31:20PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrjälä
> >
> > The fbdev helper code keeps around two lists of connectors. One is the
> > list of all connectors it could use, an
From: Ville Syrjälä
The fbdev helper code keeps around two lists of connectors. One is the
list of all connectors it could use, and that list already holds
references for all the connectors. However the other list, or rather
lists, is the one actively being used. That list is tracked per-crtc
a
There's at least one LSPCON device that occasionally returns an unexpected
adaptor ID which leads to a failed detect. Print some debug info to help
debugging this and future cases. Also print an error for an unexpected
adaptor ID, so users can report it.
Cc: dri-devel at lists.freedesktop.org
Cc:
On Wed, Oct 26, 2016 at 05:50:08PM +0300, Imre Deak wrote:
> There's at least one LSPCON device that occasionally returns an unexpected
> adaptor ID which leads to a failed detect. Print some debug info to help
> debugging this and future cases. Also print an error for an unexpected
> adaptor ID, s
h setting stream->ctx, keeping
the state together under the stream. It's going to potentially mean
redundantly pinning the ctx for the sake of the ID in the future for
streams that don't really need it, but I think it's probably not worth
worrying about that.
- Robert
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161026/74d1f24a/attachment.html>
On Wed, 2016-10-26 at 18:10 +0300, Ville Syrjälä wrote:
> On Wed, Oct 26, 2016 at 05:50:08PM +0300, Imre Deak wrote:
> > There's at least one LSPCON device that occasionally returns an unexpected
> > adaptor ID which leads to a failed detect. Print some debug info to help
> > debugging this and f
On Wed, Oct 26, 2016 at 04:17:45PM +0100, Robert Bragg wrote:
> On 26 Oct 2016 9:54 a.m., "Chris Wilson" wrote:
> >
> > On Wed, Oct 26, 2016 at 12:51:58AM +0100, Robert Bragg wrote:
> > >On Tue, Oct 25, 2016 at 10:35 PM, Matthew Auld
> > ><[1]matthew.william.auld at gmail.com> wrote:
> > >
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161026/b4f61d99/attachment.html>
On Sun, Oct 16, 2016 at 2:54 PM, Chris Wilson
wrote:
> On Sun, Oct 16, 2016 at 02:29:51PM -0400, Rob Clark wrote:
>> On Sun, Oct 16, 2016 at 1:49 PM, Chris Wilson
>> wrote:
>> > On Sun, Oct 16, 2016 at 12:39:35PM -0400, Rob Clark wrote:
>> >> This is the alternative approach for solving a deadl
In practice, none of the i915 developers Cc dri-devel for strictly i915
specific patches. Make MAINTAINERS reflect reality, and reduce random
i915 specific noise on dri-devel.
Also, we have a fairly large crowd reading and responding on intel-gfx,
and we're pretty good at involving dri-devel when
There's at least one LSPCON device that occasionally returns an unexpected
adaptor ID which leads to a failed detect. Print some debug info to help
debugging this and future cases. Also print an error for an unexpected
adaptor ID, so users can report it.
v2:
- s/adapter/adaptor/ and add code comme
> leaks.)
> >
> > Keeping our own pointer to the pinned vma could be a clarification.
> >
> > Considering Matt's comments too, I'm thinking I'll put the pinning and
> > specific_ctx_id initialization together with setting stream->ctx, keeping
> > the state together under the stream. It's going to potentially mean
> > redundantly pinning the ctx for the sake of the ID in the future for
> > streams that don't really need it, but I think it's probably not worth
> > worrying about that.
> >
> > - Robert
> >
> > > -Chris
> > >
> > > --
> > > Chris Wilson, Intel Open Source Technology Centre
>
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
> --
> Ville Syrjälä
> Intel OTC
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161026/da381dcd/attachment-0001.html>
On Wed, Oct 26, 2016 at 04:09:00PM +0200, Benjamin Gaignard wrote:
> I have just tested it on my board, no regression :-)
>
> Acked-by: Benjamin Gaignard
>
> 2016-10-25 22:53 GMT+02:00 Sean Paul :
> > On Tue, Oct 25, 2016 at 10:43 AM, Ville Syrjälä
> > wrote:
> >> On Mon, Oct 10, 2016 at 03:1
On Wed, Oct 26, 2016 at 12:36:09PM -0400, Lyude wrote:
> One of the CI machines began to run into issues with the hpd poller
> suddenly waking up in the midst of the late suspend phase. It looks like
> this is getting caused by the fact we now deinitialize power wells in
> late suspend, which means
On Wed, Oct 26, 2016 at 05:42:23PM +0100, Robert Bragg wrote:
> On Wed, Oct 26, 2016 at 4:37 PM, Ville Syrjälä <
> ville.syrjala at linux.intel.com> wrote:
>
> > On Wed, Oct 26, 2016 at 04:17:45PM +0100, Robert Bragg wrote:
> > > On 26 Oct 2016 9:54 a.m., "Chris Wilson"
> > wrote:
> > > >
> > >
On Wed, Oct 26, 2016 at 04:02:57PM +0200, Daniel Vetter wrote:
> On Wed, Oct 26, 2016 at 04:35:50PM +0300, Ville Syrjälä wrote:
> > On Wed, Oct 26, 2016 at 04:30:33PM +0300, ville.syrjala at linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > The i2c adapter is only relevant for
On Wed, Oct 26, 2016 at 05:42:23PM +0100, Robert Bragg wrote:
> On Wed, Oct 26, 2016 at 4:37 PM, Ville Syrjälä <
> ville.syrjala at linux.intel.com> wrote:
>
> > On Wed, Oct 26, 2016 at 04:17:45PM +0100, Robert Bragg wrote:
> > > On 26 Oct 2016 9:54 a.m., "Chris Wilson"
> > wrote:
> > > >
> > >
This series adds two new drivers in order to better support the LCDC
rev1 present on the da850 boards.
The first patch adds a new memory driver which allows to write to the
DDR2/mDDR memory controller present on the da8xx SoCs. Since the
memory controller region is not mapped by anyone else, I wen
Create a new driver for the da8xx DDR2/mDDR controller and implement
support for writing to the Peripheral Bus Burst Priority Register.
Signed-off-by: Bartosz Golaszewski
---
.../memory-controllers/ti-da8xx-ddrctl.txt | 20 +++
drivers/memory/Kconfig | 8 +
1 - 100 of 148 matches
Mail list logo
