On Wed, Oct 26, 2016 at 06:59:59PM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Once sw_sync_ioctl_create_fence() returns we no longer have the
> *pt pointer to the fence base object thus we need to put the reference
> we have from the fence creation to keep a correct reference accou
he
> ID, even for future non-oa streams. That might mean potentially redundantly
> pinning state for the sake of tracking the ID for streams that don't end up
> needing it.
>
I started to try out moving the specific_ctx_id and vma pointer (new) to
the stream, and also looked at initializing them together with the
stream->ctx reference, but I'm not really happy with how it's looking.
The specific_ctx_id and pinning are only for the render context, since the
OA unit is only well integrated with the render engine, which makes me more
inclined to consider them OA stream specific, not something we want/need
for all streams (considering that Sourab enables multiple streams in his
series).
Btw, for reference, my patches for gen8+ can also end up making use of the
INVALID_CTX_ID define (when overwriting the undefined ctx_id field in HW
reports when the report's ctx-id is flagged as invalid by the OA unit.) so
we maybe don't want to worry to much about removing the need for it here.
- Robert
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161026/1eabdc8e/attachment.html>
On Wed, Oct 26, 2016 at 11:31:55AM -0700, Carlos Santa wrote:
> On Wed, 2016-10-26 at 02:05 -0700, 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
On Wed, Oct 26, 2016 at 8:47 PM, Stefan Lengfeld
wrote:
>
> On Tue, Oct 25, 2016 at 04:57:37PM +0200, Daniel Vetter wrote:
>> On Thu, Sep 29, 2016 at 10:48:40PM +0200, Stefan Christ wrote:
>> > Cc: Dave Airlie
>> > Signed-off-by: Stefan Christ
>> > ---
>> > drivers/gpu/drm/ast/ast_fb.c | 6 +---
Hi Daniel,
On Tue, Oct 25, 2016 at 04:57:37PM +0200, Daniel Vetter wrote:
> On Thu, Sep 29, 2016 at 10:48:40PM +0200, Stefan Christ wrote:
> > Cc: Dave Airlie
> > Signed-off-by: Stefan Christ
> > ---
> > drivers/gpu/drm/ast/ast_fb.c | 6 +-
> > 1 file changed, 1 insertion(+), 5 deletions(-)
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161026/916db7d3/attachment.html>
will inform you.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161026/cc24c2ad/attachment.html>
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:
> > > >
> > >
ays it's just not something developers are
very
> > interesting in working on.
> >
> > I'm a sell out and just use Gmail... sorry. I can't really see myself
> > changing, though I do wish Google weren't so pedantic about forcing
> > wrapping without any option to change that behaviour. I suspect you
> > wouldn't be happy with me sending html emails, which has been Google's
> > default response to this complaint afik.
> >
> > Maybe it's gmail users causing trouble on the Mesa list too.
> >
> > - Robert
> >
> > P.S please don't think lesser of me due to my misguided MUA choices.
>
> I think I'll just reserve the right to ignore any mail with bad quoting.
Okey, fwiw, at least my patches sent out via git send-email should be fine,
so maybe just ignore my replies to feedback - which I promise not to
exploit to achieve 'consensus' through silence.
- Robert
--
Sent from Gmail on Android, in a spare moment at a VR for Immersive Theatre
meet up.
>
> --
> Ville Syrjälä
> Intel OTC
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161026/92ecba19/attachment-0001.html>
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 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()
While we're at it, let's simplify that track_pfn_insert() thing:
---
>From 6feb0b253e1fcccbcbc8ab3e8838db
2016-10-26 Brian Starkey :
> 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 chan
2016-10-26 Brian Starkey :
> 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_m
2016-10-26 Brian Starkey :
> 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
Create the driver for the da8xx master peripheral priority
configuration and implement support for writing to the three
Master Priority registers on da850 SoCs.
Signed-off-by: Bartosz Golaszewski
---
.../devicetree/bindings/bus/ti,da850-mstpri.txt| 20 ++
drivers/bus/Kconfig
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 +
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
2016-10-26 Brian Starkey :
> 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 chan
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
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
From: Gustavo Padovan
Signed-off-by: Gustavo Padovan
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e60e0a1..10f1bc0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3913,8 +3913,10 @@ R: Gustavo Padovan
S: Mainta
From: Gustavo Padovan
Once sw_sync_ioctl_create_fence() returns we no longer have the
*pt pointer to the fence base object thus we need to put the reference
we have from the fence creation to keep a correct reference accounting.
Signed-off-by: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c | 2
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:
> > > >
> > >
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 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:
> > >
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
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 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
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161026/20346fc7/attachment.html>
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161026/13db3d93/attachment.html>
minimal set, tied to
this machine only) as built-in.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161026/d7d1e
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:
> 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>
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
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
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: Rongrong Zou
>
> Small drive-by comment below.
>
>> diff --git a/drivers/gpu/drm/hisil
So, not quite sure if this is the *correct* solution, but it is at least
*a* solution to a problem with android wallpaper vs mesa that I've been
debugging. Basically, what happens is:
EGLSurface tmpSurface = mEgl.eglCreatePbufferSurface(mEglDisplay,
mEglConfig, attribs);
mEgl.eglMakeCurren
On Thu, Oct 20, 2016 at 11:43:37AM +0800, Chen-Yu Tsai wrote:
> Some rgb-to-vga bridges have an enable GPIO, either directly tied to
> an enable pin on the bridge IC, or indirectly controlling a power
> switch.
>
> Add support for it.
>
> Signed-off-by: Chen-Yu Tsai
> ---
> .../bindings/display
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
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 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 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
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 19, 2016 at 05:25:36PM +0300, Laurent Pinchart wrote:
> The LVDS encoder driver is a DRM bridge driver that supports the
> parallel to LVDS encoders that don't require any configuration. The
> driver thus doesn't interact with the device, but creates an LVDS
> connector for the panel 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
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
This defines a helper function to set the property value.
This will be used to set the link status to Bad in case
of link training failures.
Cc: dri-devel at lists.freedesktop.org
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
Cc: Chris Wilson
Signed-off-by: Manasi Navare
---
drivers/gp
A new default 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 not good, then userspace should fire off a new modeset at the current
mode even if there have not been any changes in
This work struct will be used to schedule a uevent on a separate
thread. This will be scheduled after a link train failure during modeset
to indicate a modeset retry request. It will get executed after the
current modeset is complete and all locks are released. This was
required to avoid deadlock.
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, 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
>>
>> 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
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: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
while Sourab
later relaxes that to a per-engine stream and that could be relaxed further
with non-oa metric stream types.
With multiple streams we'll still only be able to programmer a single ctx
id in oacontol.
Conceptually to me, other stream types could be associated with different
contexts (if they don't depend on the OA unit) so to me stream->ctx isn't
necessarily OA unit state.
It probably could be played around with, but right now we don't track OA
specific state in the stream. For the ID it's just semantics to say it's OA
state, and we could consider that it's maybe generally useful to track the
ID, even for future non-oa streams. That might mean potentially redundantly
pinning state for the sake of tracking the ID for streams that don't end up
needing it.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161026/22bf9802/attachment.html>
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
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:29 PM, 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, so users
On Wed, Oct 26, 2016 at 4:57 AM, Arnd Bergmann wrote:
> 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:2
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>
From: Paulo Zanoni
commit be5c571b2ff3a164d2e14ccc100cb5b2b3d3fb7c upstream
We were previously adding all the planes owned by the CRTC even when
the ddb partitioning didn't change for them. As a consequence, a lot
of functions were being called when we were just moving the cursor
around the scre
commit ccebc23b57c313229526dc76383ce82f5e0b9001 upstream
i915 sometimes needs to disable planes in the middle of an atomic
commit, and then reenable them later in the same commit. Because of
this, we can't make the assumption that the state of the plane actually
changed. Since the state of the pla
commit 27082493e9c6371b05370a619ab9d2877c5f4726 upstream
Now that we can hook into update_crtcs and control the order in which we
update CRTCs at each modeset, we can finish the final step of fixing
Skylake's watermark handling by performing DDB updates at the same time
as plane updates and waterm
commit 896e5bb022bce64e29ce2e1b2fc2a7476d311a15 upstream
Since we have to write ddb allocations at the same time as we do other
plane updates, we're going to need to be able to control the order in
which we execute modesets on each pipe. The easiest way to do this is to
just factor this section of
commit c145d3be1c313184be71d2629fd575561b7e38d4 upstream
Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.
On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values writ
Now that these have finally made it into 4.9, it's time to finally backport
these fixes. Skylake has been a mess in multi-monitor setups for a while now
because up until recently we've been updating the watermarks on Skylake just
like we would for previous generations of Intel GPUs. This means upda
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
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 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 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 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 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 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
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
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: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
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 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
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 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
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
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/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
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 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
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 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: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, 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
https://bugzilla.kernel.org/show_bug.cgi?id=117181
Jani Nikula changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 that intel_hpd_poll_init() gets called in late
suspend causing
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,
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
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
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
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ä
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
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
1 - 100 of 148 matches
Mail list logo