Add support for Innolux TV123WAM, which is a 12.3" eDP
display panel with 2160x1440 resolution.
Changes in v1:
- Add the compatibility string, display_mode and panel_desc
structures in alphabetical order (Sean Paul).
Signed-off-by: Sandeep Panda
Reviewed-by: Sean Paul
---
drivers/gpu/drm/p
On 06/13/2018 03:52 PM, Fabio Estevam wrote:
> On Wed, Jun 13, 2018 at 9:38 AM, Stefan Agner wrote:
>
>> It seems to me a rather extreme measure though, given we could fix the
>> situation rather easily.
>
> There are dtb's using the fbdev mxsfb driver like for example:
> arch/arm/boot/dts/imx28
On 06/13/2018 02:26 AM, Oleksandr Andrushchenko wrote:
On 06/13/2018 03:47 AM, Boris Ostrovsky wrote:
On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
diff --git a/include/xen/mem-reservation.h
b/include/xen/mem-reservation.h
new file mode 100644
ind
Hi,
Dne sreda, 13. junij 2018 ob 09:34:56 CEST je Maxime Ripard napisal(a):
> Hi,
>
> Thanks for working on this!
>
> On Tue, Jun 12, 2018 at 10:00:13PM +0200, Jernej Skrabec wrote:
> > TCON TOP main purpose is to configure whole display pipeline. It
> > determines relationships between mixers a
On 06/13/2018 06:14 AM, Boris Ostrovsky wrote:
On 06/12/2018 09:42 AM, Oleksandr Andrushchenko wrote:
int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32 fd)
{
- return -EINVAL;
+ struct gntdev_dmabuf *gntdev_dmabuf;
+ struct dma_buf_attachment *attach;
+ struct
On 2018-06-12 05:05, Stephen Boyd wrote:
Quoting Sandeep Panda (2018-06-04 22:40:15)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
new file mode 100644
index 000..add6e0f
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -0,0 +1,666 @@
On 2018-06-12 14:01, Stephen Boyd wrote:
Quoting spa...@codeaurora.org (2018-06-05 21:50:16)
On 2018-06-05 20:50, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 11:10:16AM +0530, Sandeep Panda wrote:
>> Document the bindings used for the sn65dsi86 DSI to eDP bridge.
[...]
>> and
>> +
Innolux TV123WAM is a 12.3" eDP display panel with
2160x1440 resolution, which can be supported by simple
panel driver.
Changes in v1:
- Make use of simple panel driver instead of creating
a new driver for this panel (Sean Paul).
- Combine dt-binding and driver changes into one patch
as do
On 2018-06-13 11:06, Ard Biesheuvel wrote:
On 13 June 2018 at 16:22, Sinan Kaya wrote:
Hi Ard,
On 5/18/2018 10:17 AM, Sinan Kaya wrote:
A host bridge is allowed to remap BAR addresses using _TRA attribute
in
_CRS windows.
pci_bus :00: root bus resource [mem 0x8010010-0x8011fff
On 06/13/2018 04:49 AM, Boris Ostrovsky wrote:
On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index a09db23e9663..e82660d81d7e 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -48,6 +48,9 @@
#include
#inclu
On 13 June 2018 at 17:17, wrote:
> On 2018-06-13 11:06, Ard Biesheuvel wrote:
>>
>> On 13 June 2018 at 16:22, Sinan Kaya wrote:
>>>
>>> Hi Ard,
>>>
>>> On 5/18/2018 10:17 AM, Sinan Kaya wrote:
A host bridge is allowed to remap BAR addresses using _TRA attribute in
_CRS windows.
>>
On 2018-06-13 11:22, Ard Biesheuvel wrote:
On 13 June 2018 at 17:17, wrote:
On 2018-06-13 11:06, Ard Biesheuvel wrote:
On 13 June 2018 at 16:22, Sinan Kaya wrote:
Hi Ard,
On 5/18/2018 10:17 AM, Sinan Kaya wrote:
A host bridge is allowed to remap BAR addresses using _TRA
attribute in
Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.
This chip can be controlled via either i2c interface or
dsi interface. Currently in driver all the control registers
are being accessed through i2c i
Dne sreda, 13. junij 2018 ob 09:36:05 CEST je Maxime Ripard napisal(a):
> On Tue, Jun 12, 2018 at 10:00:33PM +0200, Jernej Skrabec wrote:
> > Function is useful when drm_of_find_possible_crtcs() can't be used and
> > custom parsing is needed. This can happen for example when there is a
> > node wit
On 06/13/2018 05:58 AM, Boris Ostrovsky wrote:
On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by providing GNTDEV_D
Dne sreda, 13. junij 2018 ob 10:04:20 CEST je Chen-Yu Tsai napisal(a):
> On Wed, Jun 13, 2018 at 3:46 PM, Maxime Ripard
>
> wrote:
> > On Tue, Jun 12, 2018 at 10:00:23PM +0200, Jernej Skrabec wrote:
> >> TV TCONs are always connected to TV or HDMI encoder, so it doesn't make
> >> sense to check i
On 06/14/2018 01:19 AM, Boris Ostrovsky wrote:
On 06/13/2018 07:57 AM, Oleksandr Andrushchenko wrote:
On 06/13/2018 05:58 AM, Boris Ostrovsky wrote:
On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:
+
+static struct gntdev_dmabuf *
+dmabuf_exp_wait_obj_get_by_fd(struct gntdev_dmabuf_priv
Changes in current patchset:
- Remove dsi register/attach from bridge probe, since dsi dev register
completion also waits for any panel or bridge to get added. This creates
deadlock situation when bridge driver calls dsi dev register and
attach before bridge add, in its probe function.
-
Hi, Boris!
It seems that I have resolved all the issues now which
were mainly cleanup and code movement and 5 of 9 patches
already have r-b's. Do you, as the primary reviewer of the
series, think I can push (hopefully) the final version
of the patches? Just in case you want to look at v4 it is at
On 2018-06-05 20:50, Rob Herring wrote:
On Tue, Jun 05, 2018 at 11:10:16AM +0530, Sandeep Panda wrote:
Document the bindings used for the sn65dsi86 DSI to eDP bridge.
Changes in v1:
- Rephrase the dt-binding descriptions to be more inline with
existing
bindings (Andrzej Hajda).
- Add mis
On 2018-06-13 11:45, Ard Biesheuvel wrote:
On 18 May 2018 at 16:17, Sinan Kaya wrote:
A host bridge is allowed to remap BAR addresses using _TRA attribute
in
_CRS windows.
pci_bus :00: root bus resource [mem 0x8010010-0x8011fff
window] (bus address [0x0010-0x1fff])
pci 0
On 06/13/2018 03:02 PM, Boris Ostrovsky wrote:
On 06/13/2018 02:26 AM, Oleksandr Andrushchenko wrote:
On 06/13/2018 03:47 AM, Boris Ostrovsky wrote:
On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
diff --git a/include/xen/mem-reservation.h
b/include
Hi Ard,
On 5/18/2018 10:17 AM, Sinan Kaya wrote:
> A host bridge is allowed to remap BAR addresses using _TRA attribute in
> _CRS windows.
>
> pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window]
> (bus address [0x0010-0x1fff])
> pci :02:00.0: reg 0x10: [mem 0x
On 06/13/2018 03:03 PM, Oleksandr Andrushchenko wrote:
On 06/13/2018 03:02 PM, Boris Ostrovsky wrote:
On 06/13/2018 02:26 AM, Oleksandr Andrushchenko wrote:
On 06/13/2018 03:47 AM, Boris Ostrovsky wrote:
On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
On 12/06/18 14:20, Heiko Stuebner wrote:
> From: Sandy Huang
>
> The vop irq is shared between vop and iommu and irq probing in the
> iommu driver moved to the probe function recently. This can in some
> cases lead to a stall if the irq is triggered while the vop driver
> still has it disabled, b
Quoting Rob Herring (2018-06-13 08:03:53)
> On Wed, Jun 13, 2018 at 5:08 AM, Sandeep Panda wrote:
> > +Optional properties:
> > +- interrupts: Specifier for the SN65DSI86 interrupt line.
> > +
> > +- ddc-i2c-bus: phandle of the I2C controller used for DDC EDID probing
> > +
> > +- gpio-controller:
Hello,
sorry for my ignorance.
I don't know the right patch workflow in the case of "revert commit".
When I fix this bug, should I have to re-submit the previous patch
entire plus bug-fix?
Or do I have to submit patch with bug-fix only?
Thanks in advance to everybody
--
Giulio Benetti
CTO
MI
On 2018-06-06 04:29, Sean Paul wrote:
On Tue, Jun 05, 2018 at 11:10:15AM +0530, Sandeep Panda wrote:
Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.
This chip can be controlled via either i2c in
Hi Andrzej,
On 06/08/2018 08:04 AM, Andrzej Hajda wrote:
> There is no need to flip reset pin twice. Also delays can be changed to
> values present in vendor's code.
>
> Signed-off-by: Andrzej Hajda
Reviewed-by: Maciej Purski
> ---
> Hi,
>
> This is v2 of forgotten patch, awaiting reviewers,
On 18 May 2018 at 16:17, Sinan Kaya wrote:
> A host bridge is allowed to remap BAR addresses using _TRA attribute in
> _CRS windows.
>
> pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window]
> (bus address [0x0010-0x1fff])
> pci :02:00.0: reg 0x10: [mem 0x8011e00
Hi Linus,
I was planning to apply this and observed few things.
On 28/05/18 13:26, Linus Walleij wrote:
> The Versatile Express was submitted with the actual display
> bridges unconnected (but defined in the device tree) and
> mock "panels" encoded in the device tree node of the PL111
> controlle
On 06/13/2018 07:57 AM, Oleksandr Andrushchenko wrote:
> On 06/13/2018 05:58 AM, Boris Ostrovsky wrote:
>>
>>
>> On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote:
>>>
>>> +
>>> +static struct gntdev_dmabuf *
>>> +dmabuf_exp_wait_obj_get_by_fd(struct gntdev_dmabuf_priv *priv, int fd)
>>
>>
>> T
On 18 May 2018 at 16:17, Sinan Kaya wrote:
> Get rid of base and size variables in favor of a struct resource.
> The conditional for checking window can be replaced with
> resource_contains().
>
> Signed-off-by: Sinan Kaya
Reviewed-by: Ard Biesheuvel
> ---
> drivers/video/fbdev/efifb.c | 17 +
On 13 June 2018 at 16:22, Sinan Kaya wrote:
> Hi Ard,
>
> On 5/18/2018 10:17 AM, Sinan Kaya wrote:
>> A host bridge is allowed to remap BAR addresses using _TRA attribute in
>> _CRS windows.
>>
>> pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window]
>> (bus address [0x00100
Hi Andrzej,
On 01/15/2018 06:33 PM, Andrzej Hajda wrote:
> Function should constantly check if cable is connected and finish
> in finite time.
>
> Signed-off-by: Andrzej Hajda
Looks fine to me.
Reviewed-by: Maciej Purski
> ---
> drivers/gpu/drm/bridge/sil-sii8620.c | 31 +++
On 06/13/2018 05:04 AM, Oleksandr Andrushchenko wrote:
> On 06/13/2018 06:14 AM, Boris Ostrovsky wrote:
>>
>>
>> On 06/12/2018 09:42 AM, Oleksandr Andrushchenko wrote:
>>
>>> int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32
>>> fd)
>>> {
>>> - return -EINVAL;
>>> + struc
On 06/14/2018 01:03 AM, Boris Ostrovsky wrote:
On 06/13/2018 05:04 AM, Oleksandr Andrushchenko wrote:
On 06/13/2018 06:14 AM, Boris Ostrovsky wrote:
On 06/12/2018 09:42 AM, Oleksandr Andrushchenko wrote:
int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32
fd)
{
- retu
Document the bindings used for the sn65dsi86 DSI to eDP bridge.
Changes in v1:
- Rephrase the dt-binding descriptions to be more inline with existing
bindings (Andrzej Hajda).
- Add missing dt-binding that are parsed by corresponding driver
(Andrzej Hajda).
Changes in v2:
- Remove edp pa
https://bugs.freedesktop.org/show_bug.cgi?id=81678
Michel Dänzer changed:
What|Removed |Added
Product|DRI |xorg
QA Contact|
Hi,
On Wed, 2018-06-13 at 23:52 +0200, Giulio Benetti wrote:
> Hello,
>
> sorry for my ignorance.
> I don't know the right patch workflow in the case of "revert commit".
> When I fix this bug, should I have to re-submit the previous patch
> entire plus bug-fix?
>
> Or do I have to submit patch w
This is a small fallout from a work to allow batching WW mutex locks and
unlocks.
Our Wound-Wait mutexes actually don't use the Wound-Wait algorithm but
the Wait-Die algorithm. One could perhaps rename those mutexes tree-wide to
"Wait-Die mutexes" or "Deadlock Avoidance mutexes". Another approach
For modeset locks we don't expect a high number of contending
transactions so change algorithm from Wait-Die to Wound-Wait.
Signed-off-by: Thomas Hellstrom
---
v2: Update to API change.
---
drivers/gpu/drm/drm_modeset_lock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dr
The current Wound-Wait mutex algorithm is actually not Wound-Wait but
Wait-Die. Implement also Wound-Wait as a per-ww-class choice. Wound-Wait
is, contrary to Wait-Die a preemptive algorithm and is known to generate
fewer backoffs. Testing reveals that this is true if the
number of simultaneous con
https://bugs.freedesktop.org/show_bug.cgi?id=10
Christian König changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #22 from Christian König (christian.koe...@amd.com) ---
Your debugging efforts are better than mine.
Please provide the output of "sudo setpci -s 65:00.0 ECAP15.l ECAP15+4.l
ECAP15+8.l" once before suspend and once after suspend witho
On Wed, Jun 13, 2018 at 11:57:25AM +0100, Sudeep Holla wrote:
> Hi Linus,
>
> I was planning to apply this and observed few things.
>
> On 28/05/18 13:26, Linus Walleij wrote:
> > The Versatile Express was submitted with the actual display
> > bridges unconnected (but defined in the device tree)
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #23 from Alexander Mezin (mezin.alexan...@gmail.com) ---
(In reply to Christian König from comment #22)
> Your debugging efforts are better than mine.
>
> Please provide the output of "sudo setpci -s 65:00.0 ECAP15.l ECAP15+4.l
> ECAP
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #24 from Christian König (christian.koe...@amd.com) ---
Created attachment 276547
--> https://bugzilla.kernel.org/attachment.cgi?id=276547&action=edit
Possible fix
In this case please try the attached patch and see if it helps.
--
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #25 from Alexander Mezin (mezin.alexan...@gmail.com) ---
Yes, it works
dmesg:
[ 34.330683] amdgpu :65:00.0: Test 0 from 8 to 13
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Wed, Jun 13, 2018 at 04:05:43PM +0200, Thomas Hellstrom wrote:
> In short, with Wait-Die (before the patch) it's the process _taking_ the
> contended lock that backs off if necessary. No preemption required. With
> Wound-Wait, it's the process _holding_ the contended lock that gets wounded
> (pr
Hi Linus,
Please pull fbdev changes for v4.18. There is nothing really major
here, few small fixes, some cleanups and dead drivers removal (please
see the signed tag description for details).
Test merge revealed a small merge conflict, the resolution is trivial:
diff --cc drivers/video/fbdev/mm
On 06/14/2018 12:38 PM, Andrea Parri wrote:
Hi Thomas,
On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
The current Wound-Wait mutex algorithm is actually not Wound-Wait but
Wait-Die. Implement also Wound-Wait as a per-ww-class choice. Wound-Wait
is, contrary to Wait-Die a pree
On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
> __ww_mutex_wakeup_for_backoff(struct mutex *lock, struct ww_acquire_ctx
> *ww_ctx)
> {
> struct mutex_waiter *cur;
> + unsigned int is_wait_die = ww_ctx->ww_class->is_wait_die;
>
> lockdep_assert_held(&lock->w
On 06/14/2018 12:51 PM, Peter Zijlstra wrote:
On Wed, Jun 13, 2018 at 04:05:43PM +0200, Thomas Hellstrom wrote:
In short, with Wait-Die (before the patch) it's the process _taking_ the
contended lock that backs off if necessary. No preemption required. With
Wound-Wait, it's the process _holding_
On 06/14/2018 01:36 PM, Peter Zijlstra wrote:
On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
__ww_mutex_wakeup_for_backoff(struct mutex *lock, struct ww_acquire_ctx
*ww_ctx)
{
struct mutex_waiter *cur;
+ unsigned int is_wait_die = ww_ctx->ww_class->is_wait_
On 06/14/2018 01:49 PM, Andrea Parri wrote:
[...]
+ /*
+* wake_up_process() paired with set_current_state() inserts
+* sufficient barriers to make sure @owner either sees it's
+* wounded or has a wakeup pending to re-read the wounded
Resending hopefully better formatted..
On 06/14/2018 01:49 PM, Andrea Parri wrote:
[...]
+ /*
+* wake_up_process() paired with set_current_state() inserts
+* sufficient barriers to make sure @owner either sees it's
+* wounded or ha
On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
> +static bool __ww_mutex_wound(struct mutex *lock,
> + struct ww_acquire_ctx *ww_ctx,
> + struct ww_acquire_ctx *hold_ctx)
> +{
> + struct task_struct *owner = __mutex_owner(lock
On 24.05.2018 11:32, Inki Dae wrote:
> This patch makes RC_CORE to be selected with this driver.
>
> sil_sii8620 driver calls remote controller interfaces directly
> so RC_CORE should be enabled mandatorily.
>
> And some boards not using remote controller device don't really
> need to know that RC_
https://bugzilla.kernel.org/show_bug.cgi?id=199025
--- Comment #37 from Alex Tucker (a...@floop.org.uk) ---
Thanks Samuel, updating to kernel-4.16.14-300.fc28.x86_64 and moving back to
Nouveau rather than the workaround with the NVIDIA driver, suspend and resume
now works again for me too.
Would
Hi, Peter,
On 06/14/2018 02:41 PM, Peter Zijlstra wrote:
On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
+static bool __ww_mutex_wound(struct mutex *lock,
+struct ww_acquire_ctx *ww_ctx,
+struct ww_acquire_ctx *hold_ctx)
Am Mittwoch, 14. März 2018, 13:02:13 CEST schrieb Emil Velikov:
> Hi Lin,
>
> On 14 March 2018 at 09:12, Lin Huang wrote:
> > From: huang lin
> >
> > Refactor Innolux P079ZCA panel driver, let it support
> > multi panel.
> >
> > Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2
> > Signed-off
On Tue, Jun 12, 2018 at 04:01:31AM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
> >Alexandru-Cosmin Gheorghe
> >Sent: Monday, June 11, 2018 3:47 PM
> >To: Shankar, Uma
> >Cc: dcasta...@chromium.org;
https://bugzilla.kernel.org/show_bug.cgi?id=200045
--- Comment #7 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Wolfram Sang from comment #5)
> Sure. But reading the original description above, I think the default use
> case is to not use hw_i2c. It was just added to try to work aroun
On 06/14/2018 02:48 PM, Thomas Hellstrom wrote:
Hi, Peter,
On 06/14/2018 02:41 PM, Peter Zijlstra wrote:
On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
+static bool __ww_mutex_wound(struct mutex *lock,
+ struct ww_acquire_ctx *ww_ctx,
+ struct
On 06/14/2018 03:29 PM, Matthew Wilcox wrote:
On Thu, Jun 14, 2018 at 01:54:15PM +0200, Thomas Hellstrom wrote:
On 06/14/2018 01:36 PM, Peter Zijlstra wrote:
Currently you don't allow mixing WD and WW contexts (which is not
immediately obvious from the above code), and the above hard relies on
https://bugzilla.kernel.org/show_bug.cgi?id=200045
--- Comment #8 from cerg2010cerg2...@mail.ru ---
Ok, I tested the patches, but they did not fix the problem. Nothing changed,
and the log is empty. I tried to apply them separately and both at the same
time. Note that second one seems to depend on
https://bugs.freedesktop.org/show_bug.cgi?id=106418
davep changed:
What|Removed |Added
CC||david.panar...@amd.com
--- Comment #5 from dave
Hi Dave,
Fixes for 4.18. Highlights:
- Fixes for gfxoff on Raven
- Remove an ATPX quirk now that the root cause is fixed
- Runtime PM fixes
- Vega20 register header update
- Wattman fixes
- Misc bug fixes
The following changes since commit 7ba01f9e12bb3f088f617cf69b589ea37bd5d6ed:
drm/amdgpu:
https://bugs.freedesktop.org/show_bug.cgi?id=100687
MirceaKitsune changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=106919
Bug ID: 106919
Summary: Stuttering when trying to decode stream encoded with
omx
Product: Mesa
Version: 18.0
Hardware: Other
OS: All
Status: NE
Hello YoungJun Cho,
The patch 7e3d88f9cce3: "drm/prime: replace NULL with error value in
drm_prime_pages_to_sg" from Jun 24, 2013, leads to the following
static checker warning:
drivers/gpu/drm/drm_prime.c:317 drm_gem_map_dma_buf()
warn: 'sgt' can also be NULL
drivers/gpu/drm/drm
https://bugs.freedesktop.org/show_bug.cgi?id=106919
--- Comment #1 from Ricardo Ribalda ---
Created attachment 140154
--> https://bugs.freedesktop.org/attachment.cgi?id=140154&action=edit
Original file encoded with omx (one keyframe per second)
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=106919
--- Comment #2 from Ricardo Ribalda ---
Created attachment 140156
--> https://bugs.freedesktop.org/attachment.cgi?id=140156&action=edit
Sluttering (how do I see the video with omx decode)
--
You are receiving this mail because:
You are the a
On Thu, Jun 14, 2018 at 01:48:39PM +0200, Thomas Hellstrom wrote:
> The literature makes a distinction between "killed" and "wounded". In our
> context, "Killed" is when a transaction actually receives an -EDEADLK and
> needs to back off. "Wounded" is when someone (typically another transaction)
>
On Thu, Jun 14, 2018 at 03:43:04PM +0200, Thomas Hellstrom wrote:
> It's intended to be enforced by storing the algorithm choice in the
> WW_MUTEX_CLASS which must be common for an acquire context and the
> ww_mutexes it acquires. However, I don't think there is a check that that
> holds. I guess w
Hello,
Please pull the generic drm_writeback patches into drm-misc-next. They
have been reviewed on the mailing lists for a while, and we have the
userspace and individual kernel driver's implementations using it.
The following changes since commit 33ce21d6a2491ef9adb8dc395e3f5bbbfcdc95b5:
Mer
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #20 from sam.ps...@gmail.com ---
Created attachment 140158
--> https://bugs.freedesktop.org/attachment.cgi?id=140158&action=edit
dmesg w/mesa 18.0.2-1.fc28
I am still suffering from this issue, even with latest firmware from commen
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #21 from sam.ps...@gmail.com ---
Created attachment 140159
--> https://bugs.freedesktop.org/attachment.cgi?id=140159&action=edit
dmesg w/mesa 18.2.0-0.11.git41dabdc.fc28
--
You are receiving this mail because:
You are the assignee
On Mon, Jun 11, 2018 at 02:13:17PM -0700, Jeykumar Sankaran wrote:
> Submitting a series of patches to further clean up DPU driver by stripping
> down a list of custom properties supporting proprietary features. It
> removes the property installers/handlers and cleans up relevant files of
> of som
On Tue, Jun 12, 2018 at 05:49:03PM -0700, Abhinav Kumar wrote:
> Seamless modes are ones which do not require a display
> to be turned OFF/ON between mode switches.
>
> Remove support for seamless modes from DPU for now.
>
> This will be added later based on additional requirements.
>
> This cha
https://bugzilla.kernel.org/show_bug.cgi?id=200045
--- Comment #9 from Wolfram Sang (w...@the-dreams.de) ---
Created attachment 276551
--> https://bugzilla.kernel.org/attachment.cgi?id=276551&action=edit
print initial states to allow further debug
Thanks for testing the patches, pity it didn't
On Tue, May 15, 2018 at 11:18:50AM +0100, Alexandru Gheorghe wrote:
> Status register contains a lot of bits for reporting internal errors
> inside Mali DP. Currently, we just silently ignore all of the errors,
> that doesn't help when we are investigating different bugs, especially
> on the FPGA m
On Wed, Jun 13, 2018 at 12:01:21PM -0700, Jeykumar Sankaran wrote:
> On 2018-06-13 09:44, Jordan Crouse wrote:
> > On Tue, Jun 12, 2018 at 06:17:47PM -0700, Jeykumar Sankaran wrote:
> > > Switch to state based resource management. This patch
> > > overhauls the resource manager and HW allocation me
On Tue, Jun 12, 2018 at 06:17:43PM -0700, Jeykumar Sankaran wrote:
> This patchset introduces drm private object in KMS to manage HW
> resource management. It modifies the resource manager by
> introducing API's to do per DRM object resource allocation/cleanups.
>
> The patchset is based on: https
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #22 from Michel Dänzer ---
(In reply to sam.psylo from comment #20)
> I am still suffering from this issue, even with latest firmware from comment
> 15.
Please file your own report. This report is resolved.
> Firmware: 20180525-85
https://bugs.freedesktop.org/show_bug.cgi?id=106872
Michel Dänzer changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|dri-devel@l
https://bugzilla.kernel.org/show_bug.cgi?id=200045
--- Comment #10 from cerg2010cerg2...@mail.ru ---
Here is the output:
[ 23.056329] (null): initial SCL state 1
[ 23.056330] (null): initial SDA state 1
[ 23.056532] (null): initial SCL state 1
[ 23.056534] (null): initial SDA state 1
On Tue, Jun 12, 2018 at 06:17:47PM -0700, Jeykumar Sankaran wrote:
> Switch to state based resource management. This patch
> overhauls the resource manager and HW allocation methods by
> maintaining the global resource pool and allocated hw
> blocks in respective drm component states.
>
> Global r
If the user has created a read-only object, they should not be allowed
to circumvent the write protection by using a GGTT mmapping. Deny it.
Also most machines do not support read-only GGTT PTEs, so again we have
to reject attempted writes. Fortunately, this is known a priori, so we
can at least r
On Thu, Jun 14, 2018 at 12:30:35PM +0530, Vivek Gautam wrote:
> Hi Jordan,
>
> On Mon, Jun 11, 2018 at 11:56 PM, Jordan Crouse
> wrote:
> > Now that the IOMMU is the master of it's own power we don't need to bring
> > up the GPU to do IOMMU operations. This is good because bringing up a6xx
> > r
The script:
./scripts/documentation-file-ref-check --fix-rst
Gives multiple hints for broken references on some files.
Manually use the one that applies for some files.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/obsolete/sysfs-gpio | 2 +-
.../devicet
As we move stuff around, some doc references are broken. Fix some of
them via this script:
./scripts/documentation-file-ref-check --fix
Manually checked that produced results are valid.
Signed-off-by: Mauro Carvalho Chehab
---
.../devicetree/bindings/clock/st/st,clkgen.txt | 8
As we move stuff around, some doc references are broken. Fix some of
them via this script:
./scripts/documentation-file-ref-check --fix
Manually checked if the produced result is valid, removing a few
false-positives.
Acked-by: Takashi Iwai
Acked-by: Masami Hiramatsu
Acked-by: Stephen B
>-Original Message-
>From: Alexandru-Cosmin Gheorghe [mailto:Alexandru-
>cosmin.gheor...@arm.com]
>Sent: Thursday, June 14, 2018 6:21 PM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org;
>emil.l.veli...@gmail.com; dri-devel@lists.freedesktop.org; Syrjala, Vi
On Thu, 2018-06-14 at 13:09 -0300, Mauro Carvalho Chehab wrote:
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix
>
> Manually checked that produced results are valid.
>
> Signed-off-by: Mauro Carv
On Thu, 14 Jun 2018 13:08:49 -0300
Mauro Carvalho Chehab wrote:
> +++ b/Documentation/trace/events.rst
> @@ -8,7 +8,7 @@ Event Tracing
> 1. Introduction
> ===
>
> -Tracepoints (see Documentation/trace/tracepoints.txt) can be used
> +Tracepoints (see Documentation/trace/tracepoints
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #23 from sam.ps...@gmail.com ---
(In reply to Michel Dänzer from comment #22)
> (In reply to sam.psylo from comment #20)
> > I am still suffering from this issue, even with latest firmware from comment
> > 15.
>
> Please file your ow
On Thu, 14 Jun 2018 18:09:01 +0200,
Mauro Carvalho Chehab wrote:
>
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix
>
> Manually checked that produced results are valid.
>
> Signed-off-by: Mauro Ca
> -Original Message-
> From: Chris Wilson
> Sent: Thursday, June 14, 2018 9:07 AM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Chris Wilson ;
> Bloomfield, Jon ; Joonas Lahtinen
> ; Matthew Auld
> ; David Herrmann
>
> Subject: [PATCH v2] drm/i915: Prevent w
1 - 100 of 171 matches
Mail list logo
