Some Poco F1 phones from Xiaomi have an nt36672a video mode panel; add support
for the same.
Most of the panel data is taken from downstream panel dts, and is converted to
drm-panel based driver by me.
It has been validated with v5.8-rc5 on Poco F1 phone; my tree with other
dependent patches is
The nt36672a panel from Tianma is a FHD+ panel with a resolution of 1080x2246
and 6.18 inches size. It is found in some of the Poco F1 phones.
Signed-off-by: Sumit Semwal
Change-Id: I401dfbfe23ff2d806c956002f45e349cb9688c16
---
v2: remove ports node, making port@0 directly under panel@0 node.
Some Poco F1 phones have an LCD panel from Tianma, model nt36672a,
with a resolution of 1080x2246 that operates in DSI video mode.
Add the drm panel driver for it.
During testing, Benni Steini helped us fix
the reset sequence timing (from 10ms to 20ms), to get the bootanimation
to work on
Hi all,
Today's linux-next merge of the devicetree tree got a conflict in:
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
between commit:
5a2e9b658cdc ("dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml")
from the drm tree and commit:
382646090f7f ("dt-bindings:
On Tue, Jul 21, 2020 at 4:46 PM Christian König
wrote:
>
> Am 21.07.20 um 11:24 schrieb dan...@ffwll.ch:
> > On Tue, Jul 21, 2020 at 09:32:40AM +0200, Christian König wrote:
> >> The driver doesn't expose any not-mapable memory resources.
> >>
> >> Signed-off-by: Christian König
> >> ---
> >>
On Tue, Jul 21, 2020 at 11:24 PM Andrew Morton
wrote:
>
> On Tue, 21 Jul 2020 21:02:44 + "Ruhl, Michael J"
> wrote:
>
> > >--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
> > >+++ a/include/linux/io-mapping.h
> > >@@ -107,9 +107,12 @@ io_mapping_init_wc(struct
Hi all,
[I can't find a previous email about this, sorry ...]
There is a semantic conflict between Linus' tree and the amdgpu tree
between commit
d7a6634a4cfb ("drm/amdgpu/atomfirmware: fix vram_info fetching for renoir")
from Linus' tree and commts
fe098a5d6443 ("drm/amdgpu/atomfirmware:
Hi Bernard,
On Tue, Jul 21, 2020 at 08:24:05PM +0800, Bernard wrote:
>
> Hi:
>
> The function "int drm_panel_add(struct drm_panel *panel)" always returns
> true, this return value is meaningless.
> So I am planning to optimize this function to a non-return implementation,
> "void
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #82 from mn...@protonmail.com ---
(In reply to Kees Cook from comment #81)
> I assume this is the change, BTW:
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
>
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #81 from Kees Cook (k...@outflux.net) ---
I assume this is the change, BTW:
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index d61186ff411d..2b8da2b17a5d 100644
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #80 from Kees Cook (k...@outflux.net) ---
(In reply to mnrzk from comment #79)
> I wonder if there's any way to set a watchpoint to see where exactly the
> dm_atomic_state gets filled with garbage data.
mm/slub.c set_freepointer()
+Christian who added DMABUF_MOVE_NOTIFY which added the relevant blurb:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/dma-buf/Kconfig#n46
Currently, the user seems to amdgpu for P2P dma-buf and it seems to plumb
ttm (*move_notify) callback to dma-buf. We're not
On Fri, Jun 26, 2020 at 7:11 PM Manasi Navare wrote:
>
> From: Bhanuprakash Modem
>
> v3:
> * Rebase (Manasi)
> v2:
> * Rebase (Manasi)
>
> As both VRR min and max are already part of drm_display_info,
> drm can expose this VRR range for each connector.
>
> Hence this logic should move to core
On Tue, 21 Jul 2020 at 18:47, Thomas Hellström (Intel)
wrote:
>
>
> On 7/21/20 9:45 AM, Christian König wrote:
> > Am 21.07.20 um 09:41 schrieb Daniel Vetter:
> >> On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel)
> >> wrote:
> >>> Hi,
> >>>
> >>> On 7/9/20 2:33 PM, Daniel Vetter
>
> >> That's also why I'm not positive on the "no hw preemption, only
> >> scheduler" case: You still have a dma_fence for the batch itself,
> >> which means still no userspace controlled synchronization or other
> >> form of indefinite batches allowed. So not getting us any closer to
> >>
On Tue, 21 Jul 2020 21:02:44 + "Ruhl, Michael J"
wrote:
> >--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
> >+++ a/include/linux/io-mapping.h
> >@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io
> >resource_size_t base,
> >
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #79 from mn...@protonmail.com ---
(In reply to Kees Cook from comment #78)
> (In reply to mnrzk from comment #76)
> > If my understanding is correct, base would have previously been filled with
> > the freelist pointer (since it's the
>-Original Message-
>From: Andrew Morton
>Sent: Tuesday, July 21, 2020 4:57 PM
>To: Ruhl, Michael J
>Cc: dri-devel@lists.freedesktop.org; Mike Rapoport ;
>Andy Shevchenko ; Chris Wilson
>; sta...@vger.kernel.org
>Subject: Re: [PATCH v2] io-mapping: Indicate mapping failure
>
>On Tue, 21
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #78 from Kees Cook (k...@outflux.net) ---
(In reply to mnrzk from comment #76)
> If my understanding is correct, base would have previously been filled with
> the freelist pointer (since it's the first 8 bytes). Now since the freelist
On Tue, 21 Jul 2020 13:19:36 -0400 "Michael J. Ruhl"
wrote:
> The !ATOMIC_IOMAP version of io_maping_init_wc will always return
> success, even when the ioremap fails.
>
> Since the ATOMIC_IOMAP version returns NULL when the init fails, and
> callers check for a NULL return on error this is
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #77 from Kees Cook (k...@outflux.net) ---
(Midair collision... you saw the same about the structure layout as I did.
Here's my comment...)
(In reply to mnrzk from comment #30)
> I've been looking at this bug for a while now and I'll
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #76 from mn...@protonmail.com ---
(In reply to Kees Cook from comment #75)
> Hi!
>
> First, let me say sorry for all the work my patch has caused! It seems like
> it might be tickling another (previously dormant) bug in the gpu
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 7173949df4548299ee6c63736f76247d3f288cd4
commit: f6668a70defec83ec0c837e052dd5490b66068d3 [1133/1153] drm/amdgpu: add
timeout flush mechanism to update wptr for self interrupt
config: alpha-allmodconfig (attached
Hi list,
virtio-gpu is moving in the direction where BO pages are pinned for
the lifetime for simplicity. I am wondering if that is considered a
security issue in general, especially after running into the
description of the new DMABUF_MOVE_NOTIFY config option.
Most drivers do not have a
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #75 from Kees Cook (k...@outflux.net) ---
Hi!
First, let me say sorry for all the work my patch has caused! It seems like it
might be tickling another (previously dormant) bug in the gpu driver.
(In reply to mnrzk from comment #30)
On Mon, Jul 20, 2020 at 05:40:10PM -0700, Almahallawy, Khaled wrote:
> On Mon, 2020-07-20 at 17:07 -0700, Manasi Navare wrote:
> > On Mon, Jul 20, 2020 at 04:41:25PM -0700, Khaled Almahallawy wrote:
> > > Add the missing CP2520 pattern 2 and 3 phy compliance patterns
> > >
> > > Signed-off-by:
Hi Lucas,
Thank you for following up on this. Some things have slowed down,
given the world pandemic we've been experiencing this year.
I've had the design ready and half of it implemented and committed
into a branch. Just as per what I wrote earlier this year on this thread.
I need to finish
On Tue, 2020-07-21 at 12:00 -0400, Lyude Paul wrote:
> On Tue, 2020-07-21 at 18:27 +0300, Mika Westerberg wrote:
> > On Tue, Jul 21, 2020 at 11:01:55AM -0400, Lyude Paul wrote:
> > > Sure thing. Also, feel free to let me know if you'd like access to one
> > > of
> > > the
> > > systems we saw
On Tue, Jul 21, 2020 at 7:46 PM Thomas Hellström (Intel)
wrote:
>
>
> On 2020-07-21 15:59, Christian König wrote:
> > Am 21.07.20 um 12:47 schrieb Thomas Hellström (Intel):
> ...
> >> Yes, we can't do magic. As soon as an indefinite batch makes it to
> >> such hardware we've lost. But since we
On 2020-07-21 15:59, Christian König wrote:
Am 21.07.20 um 12:47 schrieb Thomas Hellström (Intel):
...
Yes, we can't do magic. As soon as an indefinite batch makes it to
such hardware we've lost. But since we can break out while the batch
is stuck in the scheduler waiting, what I believe we
The !ATOMIC_IOMAP version of io_maping_init_wc will always return
success, even when the ioremap fails.
Since the ATOMIC_IOMAP version returns NULL when the init fails, and
callers check for a NULL return on error this is unexpected.
During a device probe, where the ioremap failed, a crash can
Applied. Thanks!
Alex
On Fri, Jul 17, 2020 at 8:23 AM Qiu Wenbo wrote:
>
> Avoid kernel crash when vddci_control is SMU7_VOLTAGE_CONTROL_NONE and
> vddci_voltage_table is empty. It has been tested on Intel Hades Canyon
> (i7-8809G).
>
> Bug: https://bugzilla.kernel.org/show_bug.cgi?id=208489
>
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #74 from Paul Menzel (pmenzel+bugzilla.kernel@molgen.mpg.de) ---
I sent a message to the LKML and amd-gfx list [1], asking Kees and Andrew on
how to proceed.
[1]: https://lkml.org/lkml/2020/7/21/729
"[Regression] hangs
This matches some of the other headers in the file.
Fixes the following W=1 kernel build warning(s):
drivers/scsi/csiostor/csio_lnode.c:2079: warning: Function parameter or member
'hw' not described in 'csio_lnode_init'
drivers/scsi/csiostor/csio_lnode.c:2079: warning: Function parameter or
Fixes the following W=1 kernel build warning(s):
drivers/scsi/lpfc/lpfc_sli.c: In function ‘lpfc_wq_create’:
drivers/scsi/lpfc/lpfc_sli.c:15810:16: warning: variable ‘pg_addr’ set but not
used [-Wunused-but-set-variable]
15810 | unsigned long pg_addr;
| ^~~
Cc: James Smart
Cc: Dick
'pg_addr' is only used when CONFIG_X86 is defined. So only declare it
if CONFIG_X86 is defined.
Fixes the following W=1 kernel build warning(s):
drivers/scsi/lpfc/lpfc_sli.c: In function ‘lpfc_wq_create’:
drivers/scsi/lpfc/lpfc_sli.c:15813:16: warning: unused variable ‘pg_addr’
Fixes the following W=1 kernel build warning(s):
drivers/scsi/lpfc/lpfc_mem.c:85: warning: Function parameter or member 'align'
not described in 'lpfc_mem_alloc'
Cc: James Smart
Cc: Dick Kennedy
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/scsi/lpfc/lpfc_sli.c:257: warning: Function parameter or member 'mqe'
not described in 'lpfc_sli4_mq_put'
drivers/scsi/lpfc/lpfc_sli.c:257: warning: Excess function parameter 'wqe'
description in 'lpfc_sli4_mq_put'
https://bugzilla.kernel.org/show_bug.cgi?id=207383
Jeremy Kescher (jer...@kescher.at) changed:
What|Removed |Added
CC||jer...@kescher.at
On Sun, 19 Jul 2020 19:44:57 +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't
On Sun, 19 Jul 2020 19:24:38 +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't
On Thu, Jul 16, 2020 at 08:27:21PM +0900, Tetsuo Handa wrote:
> On 2020/07/16 19:00, Daniel Vetter wrote:
> > On Thu, Jul 16, 2020 at 12:29:00AM +0900, Tetsuo Handa wrote:
> >> On 2020/07/16 0:12, Dan Carpenter wrote:
> >>> I've complained about integer overflows in fbdev for a long time...
> >>>
On Sun, Jul 19, 2020 at 12:10:08PM +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If
On Tue, 2020-07-21 at 18:27 +0300, Mika Westerberg wrote:
> On Tue, Jul 21, 2020 at 11:01:55AM -0400, Lyude Paul wrote:
> > Sure thing. Also, feel free to let me know if you'd like access to one of
> > the
> > systems we saw breaking with this patch - I'm fairly sure I've got one of
> > them
> >
Reviewed-by: Lyude Paul
Thanks!
On Tue, 2020-07-21 at 15:17 +, Wei Yongjun wrote:
> When using single_open() for opening, single_release() should be
> used instead of seq_release(), otherwise there is a memory leak.
>
> Fixes: 12885ecbfe62 ("drm/nouveau/kms/nvd9-: Add CRC support")
>
On Fri, Jul 3, 2020 at 5:47 AM Ondrej Jirman wrote:
>
> This patchset fixes warnings in the example in display/bridge/nwl-dsi.yaml
> revealed during port of display/panel/rocktech,jh057n00900.yaml to
> yaml.
>
> Please take a look.
>
> thank you and regards,
> Ondrej Jirman
>
> Ondrej Jirman
The !ATOMIC_IOMAP version of io_maping_init_wc will always return
success, even when the ioremap fails.
Since the ATOMIC_IOMAP version returns NULL when the init fails, and
callers check for a NULL return on error this is unexpected.
Return NULL on ioremap failure.
Fixes: cafaf14a5d8f
I found this when my system crashed long after the mapping failure.
The expected behavior should have been driver exit.
Since this is almost exclusively used for drm, I am posting to
the dri mailing list. Should this go to another list as well?
Thanks,
Mike
Cc: Mike Rapoport
Cc: Andy
https://bugzilla.kernel.org/show_bug.cgi?id=208647
--- Comment #5 from Jay Foad (jay.f...@gmail.com) ---
Created attachment 290439
--> https://bugzilla.kernel.org/attachment.cgi?id=290439=edit
output of journalctl -b-5 -k
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=208647
--- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) ---
Please attach your full dmesg output and xorg log (if using X).
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=208647
Nicolai Hähnle (nhaeh...@gmail.com) changed:
What|Removed |Added
CC||nhaeh...@gmail.com
https://bugzilla.kernel.org/show_bug.cgi?id=208647
--- Comment #2 from Jay Foad (jay.f...@gmail.com) ---
Wouldn't there normally be a useful pid in the first line if it came from
userspace?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=208647
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
Sure thing. Also, feel free to let me know if you'd like access to one of the
systems we saw breaking with this patch - I'm fairly sure I've got one of them
locally at my apartment and don't mind setting up AMT/KVM/SSH
On Tue, 2020-07-21 at 15:22 +0300, Mika Westerberg wrote:
> Hi,
>
> [Sorry
>-Original Message-
>From: Andy Shevchenko
>Sent: Tuesday, July 21, 2020 10:47 AM
>To: Ruhl, Michael J
>Cc: dri-devel@lists.freedesktop.org; Andrew Morton foundation.org>; Mike Rapoport ; Chris Wilson
>; sta...@vger.kernel.org
>Subject: Re: [PATCH] io-mapping: Indicate mapping failure
>
On Tue, 21 Jul 2020, Wei Yongjun wrote:
> Gcc report unused-variable warning as follows:
>
> drivers/video/backlight/cr_bllcd.c:62:6: warning:
> unused variable 'intensity' [-Wunused-variable]
>62 | int intensity = bd->props.brightness;
> | ^
>
> After commit
Am 21.07.20 um 11:24 schrieb dan...@ffwll.ch:
On Tue, Jul 21, 2020 at 09:32:40AM +0200, Christian König wrote:
The driver doesn't expose any not-mapable memory resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 13 -
1 file changed, 4
https://bugzilla.kernel.org/show_bug.cgi?id=208647
Bug ID: 208647
Summary: persistent amdgpu: [mmhub] page faults
Product: Drivers
Version: 2.5
Kernel Version: 5.4.0-42-generic
Hardware: All
OS: Linux
Tree:
Am 21.07.20 um 11:28 schrieb dan...@ffwll.ch:
On Tue, Jul 21, 2020 at 09:32:42AM +0200, Christian König wrote:
The driver does support some not-mapable resources, but
those are already handled correctly in the switch/case
statement in the code.
Signed-off-by: Christian König
---
On Mon, Jul 20, 2020 at 8:24 PM Viresh Kumar wrote:
>
> On 20-07-20, 08:03, Rob Clark wrote:
> > On Mon, Jul 20, 2020 at 3:01 AM Viresh Kumar
> > wrote:
> > >
> > > On 15-07-20, 08:36, Rob Clark wrote:
> > > > I can take the first two into msm-next, the 3rd will need to wait
> > > > until
Hi Philipp,
On Tue, Jul 21, 2020 at 02:43:28PM +0200, Philipp Zabel wrote:
> Hi Laurentiu,
>
> On Tue, 2020-07-21 at 13:20 +0300, Laurentiu Palcu wrote:
> > From: Laurentiu Palcu
> >
> > This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS).
> > Some of its capabilities
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.7.9, v5.4.52, v4.19.133, v4.14.188,
v4.9.230, v4.4.230.
v5.4.52: Failed to
Sometimes it is good to know when your mapping failed.
Fixes: cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata about
the io-mapping"
Cc: Andrew Morton
Cc: Mike Rapoport
Cc: Andy Shevchenko
Cc: Chris Wilson
Cc: sta...@vger.kernel.org
Signed-off-by: Michael J. Ruhl
---
I found this when my system crashed long after the mapping failure.
The expected behavior should have been driver exit.
Since this is almost exclusively used for drm, I am posting to
the dri mailing list. Should this go to another list as well?
Thanks,
Mike
Am 21.07.20 um 12:47 schrieb Thomas Hellström (Intel):
On 7/21/20 11:50 AM, Daniel Vetter wrote:
On Tue, Jul 21, 2020 at 11:38 AM Thomas Hellström (Intel)
wrote:
On 7/21/20 10:55 AM, Christian König wrote:
Am 21.07.20 um 10:47 schrieb Thomas Hellström (Intel):
On 7/21/20 9:45 AM,
On Tue, Jul 21, 2020 at 3:23 AM Maxime Ripard wrote:
>
> On Mon, Jul 20, 2020 at 08:10:26PM -0600, Rob Herring wrote:
> > On Tue, Jul 14, 2020 at 03:13:01PM +0800, Chen-Yu Tsai wrote:
> > > From: Chen-Yu Tsai
> > >
> > > Some LCD panels do not support 24-bit true color, or 8bits per channel
> >
On Tue, Jul 21, 2020 at 2:59 PM Melissa Wen wrote:
>
> Hi all,
>
> I traced the subtests' execution to figure out what happens (or not) in
> a clean run and a blocked run, and this led me to suspect the
> vkms_crtc_atomic_flush function. Examining the code and considering the
> DRM doc, it seemed
On Tue, Jul 21, 2020 at 08:39:19AM +0100, Lee Jones wrote:
> Fixes the following kernel build warning:
>
> drivers/video/backlight/cr_bllcd.c: In function ‘cr_backlight_set_intensity’:
> drivers/video/backlight/cr_bllcd.c:62:6: warning: unused variable
> ‘intensity’ [-Wunused-variable]
> 62 |
Christian, I would want this very much but unfortunately I am on a strict
schedule for an internal project currently and hence will not be able to
actively participate. I will do my best to answer any questions Luben might have
about current implementation.
Andrey
On 7/21/20 9:39 AM,
Luben had a good idea how to tackle the whole job handling.
Andrey/Lucas can you work with Luben to get this cleaned up because
there are a lot of requirements on this which not only come from AMD.
Thanks,
Christian.
Am 21.07.20 um 15:36 schrieb Andrey Grodzovsky:
Lucas, Luben picked the
Lucas, Luben picked the work on this a few month ago as I was diverted to a
different project.
Luben, can you update Lucas please ?
Andrey
On 7/21/20 7:03 AM, Lucas Stach wrote:
It seems we all dropped the ball on this one. I believe this is still
an open issue. Has there been any progress
On 7/21/20 2:55 PM, dillon min wrote:
Hi, Alexandre,
On Tue, Jul 21, 2020 at 7:54 PM Alexandre Torgue
wrote:
On 7/21/20 12:39 PM, dillon min wrote:
Hi Alexandre,
On Tue, Jul 21, 2020 at 5:19 PM Alexandre Torgue
wrote:
Hi Dillon
On 5/25/20 5:40 AM, dillon.min...@gmail.com wrote:
Hi, Alexandre,
On Tue, Jul 21, 2020 at 7:54 PM Alexandre Torgue
wrote:
>
>
>
> On 7/21/20 12:39 PM, dillon min wrote:
> > Hi Alexandre,
> >
> > On Tue, Jul 21, 2020 at 5:19 PM Alexandre Torgue
> > wrote:
> >>
> >> Hi Dillon
> >>
> >> On 5/25/20 5:40 AM, dillon.min...@gmail.com wrote:
> >>>
On Fri, Jul 17, 2020 at 09:52:09PM +0200, Lukas Wunner wrote:
> On Fri, Jul 17, 2020 at 03:04:10PM -0400, Lyude Paul wrote:
> > Isn't it possible to tell whether a PCI device is connected through
> > thunderbolt or not? We could probably get away with just defaulting
> > to 100ms for thunderbolt
Hi:
The function "int drm_panel_add(struct drm_panel *panel)" always returns true,
this return value is meaningless.
So I am planning to optimize this function to a non-return implementation,
"void drm_panel_add(struct drm_panel *panel)".
In order to achieve this optimization, I need to
On 2020-07-20 20:53, Rob Clark wrote:
On Mon, Jul 20, 2020 at 5:53 AM wrote:
On 2020-07-16 03:49, Rob Clark wrote:
> From: Rob Clark
>
> If split-lm is used (for ex, on sdm845), we can have multiple ping-
> pongs, but only a single phys encoder. We need to configure dithering
> on each of
Hi,
[Sorry for the delay, I was on vacation]
On Fri, Jul 17, 2020 at 01:32:10PM +0200, Karol Herbst wrote:
> Filed at https://bugzilla.kernel.org/show_bug.cgi?id=208597
Thanks for reporting.
I'll check your logs and try to figure if there is something we can do
to make both nouveau and TBT
On 7/21/20 12:39 PM, dillon min wrote:
Hi Alexandre,
On Tue, Jul 21, 2020 at 5:19 PM Alexandre Torgue
wrote:
Hi Dillon
On 5/25/20 5:40 AM, dillon.min...@gmail.com wrote:
From: dillon min
V5's update based on Mark Brown's suggestion, use 'SPI_MASTER_MUST_RX'
for SPI_SIMPLEX_RX mode on
This is the same code and comment that is already shared by imx-ldb,
imx-tve, and parallel-display in imx_drm_encoder_parse_of().
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/dw_hdmi-imx.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git
The drm_panel_attach/detach() functions are empty since
commit aa6c43644bc5 ("drm/panel: drop drm_device from drm_panel"),
remove them.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/imx-ldb.c | 10 --
drivers/gpu/drm/imx/parallel-display.c | 6 --
2 files changed,
ipu_mbus_code_to_colorspace, ipu_stride_to_bytes, and
ipu_pixelformat_is_planar are unused. Remove them.
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-common.c | 67 -
include/video/imx-ipu-v3.h | 3 --
2 files changed, 70 deletions(-)
diff --git
Hi all,
I traced the subtests' execution to figure out what happens (or not) in
a clean run and a blocked run, and this led me to suspect the
vkms_crtc_atomic_flush function. Examining the code and considering the
DRM doc, it seemed to me that a drm_crtc_vblank_get call was missing a
Hi Laurentiu,
On Tue, 2020-07-21 at 13:20 +0300, Laurentiu Palcu wrote:
> From: Laurentiu Palcu
>
> This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS).
> Some of its capabilities include:
> * 4K@60fps;
> * HDR10;
> * one graphics and 2 video pipelines;
> * on-the-fly
Hello Rob,
Thanks for the review!
On Tue, 21 Jul 2020 at 09:03, Rob Herring wrote:
>
> On Thu, Jul 16, 2020 at 09:08:57PM +0530, Sumit Semwal wrote:
> > The nt36672a panel from Tianma is a FHD+ panel with a resolution of
> > 1080x2246
> > and 6.18 inches size. It is found in some of the Poco F1
On Mon, Jul 20, 2020 at 10:35:05PM +0200, Linus Walleij wrote:
> This adds device tree bindings for the Kinetic KTD253
> white LED backlight driver.
>
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Linus Walleij
> ---
> .../leds/backlight/kinetic,ktd253.yaml| 48 +++
>
On Mon, Jul 20, 2020 at 08:10:26PM -0600, Rob Herring wrote:
> On Tue, Jul 14, 2020 at 03:13:01PM +0800, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai
> >
> > Some LCD panels do not support 24-bit true color, or 8bits per channel
> > RGB. Many low end ones only support up to 6 bits per channel
Hi Alexandre,
On Tue, Jul 21, 2020 at 5:19 PM Alexandre Torgue
wrote:
>
> Hi Dillon
>
> On 5/25/20 5:40 AM, dillon.min...@gmail.com wrote:
> > From: dillon min
> >
> > V5's update based on Mark Brown's suggestion, use 'SPI_MASTER_MUST_RX'
> > for SPI_SIMPLEX_RX mode on stm32 spi controller.
> >
Hi Dillon
On 5/25/20 5:40 AM, dillon.min...@gmail.com wrote:
From: dillon min
V5's update based on Mark Brown's suggestion, use 'SPI_MASTER_MUST_RX'
for SPI_SIMPLEX_RX mode on stm32 spi controller.
V5:
1 instead of add send dummy data out under SIMPLEX_RX mode,
add flags
From: Qi Liu
We should put the reference count of the fence after calling
virtio_gpu_cmd_submit(). So add the missing dma_fence_put().
Fixes: 2cd7b6f08bc4 ("drm/virtio: add in/out fence support for explicit
synchronization")
Co-developed-by: Xin He
Signed-off-by: Xin He
Signed-off-by: Qi Liu
Hi Andrey,
Am Mittwoch, den 12.02.2020, 11:33 -0500 schrieb Andrey Grodzovsky:
> On 2/11/20 7:53 PM, Luben Tuikov wrote:
> > On 2020-02-11 4:27 p.m., Andrey Grodzovsky wrote:
> > > On 2/11/20 10:55 AM, Andrey Grodzovsky wrote:
> > > > On 2/10/20 4:50 PM, Luben Tuikov wrote:
> > > > > Hi Lucas,
>
On 7/21/20 11:50 AM, Daniel Vetter wrote:
On Tue, Jul 21, 2020 at 11:38 AM Thomas Hellström (Intel)
wrote:
On 7/21/20 10:55 AM, Christian König wrote:
Am 21.07.20 um 10:47 schrieb Thomas Hellström (Intel):
On 7/21/20 9:45 AM, Christian König wrote:
Am 21.07.20 um 09:41 schrieb Daniel
From: Laurentiu Palcu
Add bindings for iMX8MQ Display Controller Subsystem.
Signed-off-by: Laurentiu Palcu
Reviewed-by: Rob Herring
---
.../bindings/display/imx/nxp,imx8mq-dcss.yaml | 104 ++
1 file changed, 104 insertions(+)
create mode 100644
From: Laurentiu Palcu
This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS).
Some of its capabilities include:
* 4K@60fps;
* HDR10;
* one graphics and 2 video pipelines;
* on-the-fly decompression of compressed video and graphics;
The reference manual can be found here:
From: Laurentiu Palcu
The driver is part of DRM subsystem and is located in drivers/gpu/drm/imx/dcss.
Signed-off-by: Laurentiu Palcu
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index dad5a62d21a7..200c5985b41f 100644
--- a/MAINTAINERS
From: Laurentiu Palcu
Make use of drm_bridge_connector API to have the connector initialized by the
display controller.
Signed-off-by: Laurentiu Palcu
CC: Sam Ravnborg
CC: Laurent Pinchart
---
drivers/gpu/drm/imx/dcss/dcss-dev.c | 17 +---
drivers/gpu/drm/imx/dcss/dcss-kms.c |
From: Laurentiu Palcu
Currently the drm/imx/ directory is compiled only if DRM_IMX is set. Adding a
new IMX related IP in the same directory would need DRM_IMX to be set, which
would
bring in also IPUv3 core driver...
The current patch would allow adding new IPs in the imx/ directory without
From: Laurentiu Palcu
Hi,
This patchset adds initial DCSS support for iMX8MQ chip. Initial support
includes only graphics plane support (no video planes), no HDR10 capabilities,
no graphics decompression (only linear, tiled and super-tiled buffers allowed).
Support for the rest of the features
g-TTM/20200721-153530
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.
On Tue, Jul 21, 2020 at 11:38 AM Thomas Hellström (Intel)
wrote:
>
>
> On 7/21/20 10:55 AM, Christian König wrote:
> > Am 21.07.20 um 10:47 schrieb Thomas Hellström (Intel):
> >>
> >> On 7/21/20 9:45 AM, Christian König wrote:
> >>> Am 21.07.20 um 09:41 schrieb Daniel Vetter:
> On Mon, Jul
[AMD Public Use]
-Original Message-
From: dan...@ffwll.ch
Sent: Tuesday, July 21, 2020 2:58 PM
Cc: dri-devel@lists.freedesktop.org; Chauhan, Madhav ;
michael.j.r...@intel.com; tzimmerm...@suse.de
Subject: Re: [PATCH 08/11] drm/amdgpu: stop using TTM_MEMTYPE_FLAG_MAPPABLE
On Tue, Jul
1 - 100 of 167 matches
Mail list logo
