Am 22.01.21 um 08:54 schrieb Thomas Zimmermann:
The more I look at it the more I think it should be 'Unknown' here.
BTW, can I try this out somehow? I do have an RPi3. Do I need a special
disk image?
Oh, I saw that wiki url now. I'll check this out.
Best regards
Thomas
break;
Hi John, Suren,
On Wed, 20 Jan 2021 at 02:15, John Stultz wrote:
>
> We shouldn't vunmap more then we vmap, but if we do, make
> sure we complain loudly.
I was checking the general usage of vunmap in the kernel, and I
couldn't find many instances where we need to WARN_ON for the vunmap
count
Hi
Am 21.01.21 um 19:07 schrieb Noralf Trønnes:
Den 21.01.2021 11.01, skrev Thomas Zimmermann:
Hi
Am 21.01.21 um 09:27 schrieb Daniel Vetter:
On Thu, Jan 21, 2021 at 8:45 AM Thomas Zimmermann
wrote:
Hi Noralf,
glad to hear from you! Welcome back!
Thanks Thomas!
Am 20.01.21 um
Hi Daniel,
On Fri, 22 Jan 2021 08:17:58 +0100 Daniel Vetter wrote:
>
> Hm that has been in drm-intel-gt-next for a few days, is that tree not
> in linux-next?
It is not.
These are the drm branches currently in linux-next:
drm-fixes git://git.freedesktop.org/git/drm/drm.git
On Fri, Jan 22, 2021 at 1:59 AM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> WARNING: unmet direct dependencies detected for DRM_I915_WERROR
> Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] &&
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #3 from kolAflash (kolafl...@kolahilft.de) ---
I searched through my journalctl log.
I set up the whole system in May 2020 with Linux-5.6.7.
(journalctl has everything back to that date)
The bug appeared as following since October
The pull request you sent on Fri, 22 Jan 2021 10:00:50 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-01-22
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/36ada25026357c855d5839166f78017509824b77
Thank you!
--
Deet-doot-dot, I am a bot.
Hi all,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
WARNING: unmet direct dependencies detected for DRM_I915_WERROR
Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] &&
!COMPILE_TEST [=y]
Selected by [m]:
- DRM_I915_DEBUG
Hi Linus,
Regular fixes pull, nothing too major in here, just some core fixes,
one vc4, bunch of i915 and a bunch of amdgpu.
Dave.
drm-fixes-2021-01-22:
drm fixes for 5.11-rc5
core:
- atomic: Release state on error
- syncobj: Fix use-after-free
- ttm: Don't use GFP_TRANSHUGE_LIGTH
-
Matthias Brugger 於 2021年1月21日 週四 下午4:19寫道：
>
> On Thu, Jan 21, 2021 at 07:46:44AM +0800, Chun-Kuang Hu wrote:
> > Hi, Matthias:
> >
> > Matthias Brugger 於 2021年1月21日 週四 上午2:27寫道：
> > >
> > > On Thu, Jan 07, 2021 at 07:17:27AM +0800, Chun-Kuang Hu wrote:
> > > > From: CK Hu
> > > >
> > > > mtk
Hi Maxime,
Thank you for the patch.
On Thu, Jan 21, 2021 at 05:35:34PM +0100, Maxime Ripard wrote:
> The current atomic helpers have either their object state being passed as
> an argument or the full atomic state.
>
> The former is the pattern that was done at first, before switching to the
>
On Thu, Jan 21, 2021 at 08:49:50AM +0100, Christoph Hellwig wrote:
> @@ -820,14 +796,25 @@ static int klp_init_object(struct klp_patch *patch,
> struct klp_object *obj)
> const char *name;
>
> obj->patched = false;
> - obj->mod = NULL;
Why was this line removed?
> if
Recently there was a fairly long thread about recoreable hardware page
faults, how they can deadlock, and what to do about that.
While the discussion is still fresh I figured good time to try and
document the conclusions a bit.
References:
On Thu, 14 Jan 2021 09:04:36 +0100
Mauro Carvalho Chehab wrote:
> 1) 10 remaining fixup patches from the series I sent back on Dec, 1st:
>
>parport: fix a kernel-doc markup
>rapidio: fix kernel-doc a markup
>fs: fix kernel-doc markups
>pstore/zone: fix a kernel-doc markup
>
On 2021-01-19 10:50 a.m., Aurabindo Pillai wrote:
[Why]
A seamless transition between modes can be performed if the new incoming
mode has the same timing parameters as the optimized mode on a display with a
variable vtotal min/max.
Smooth video playback usecases can be enabled with this
We haven't yet implemented support for backlights that need to be
enabled/disabled via PWM instead of AUX, which means we'll break things if
we enable DPCD backlight control on these machines. Luckily though since
most of these machines work fine just using the plain PWM backlight
controls anyway,
On Thu, Jan 21, 2021 at 5:36 PM Maxime Ripard wrote:
>
> Only planes' prepare_fb and cleanup_fb, and encoders' atomic_check and
> atomic_mode_set hooks remain with an object state and not the global
> drm_atomic_state.
>
> prepare_fb and cleanup_fb operate by design on a given state and
>
Den 21.01.2021 11.01, skrev Thomas Zimmermann:
> Hi
>
> Am 21.01.21 um 09:27 schrieb Daniel Vetter:
>> On Thu, Jan 21, 2021 at 8:45 AM Thomas Zimmermann
>> wrote:
>>>
>>> Hi Noralf,
>>>
>>> glad to hear from you! Welcome back!
Thanks Thomas!
>>>
>>> Am 20.01.21 um 18:42 schrieb Daniel
On 1/21/21 4:40 PM, Steven Price wrote:
On 21/01/2021 12:22, Carsten Haitzler wrote:
On 1/20/21 3:44 PM, Steven Price wrote:
On 18/01/2021 14:20, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is bueried inside the
NIT:
From: Sean Paul
The HDCP 1.4 spec does not require the QUERY_STREAM_ENCRYPTION_STATUS
check, it was always a nice-to-have. After deploying this across various
devices, we've determined that some MST bridge chips do not properly
support this call for HDCP 1.4 (namely Synaptics and Realtek).
I
Hi Dave & Daniel -
drm-intel-fixes-2021-01-21:
drm/i915 fixes for v5.11-rc5:
- HDCP fixes
- PMU wakeref fix
- Fix HWSP validity race
- Fix DP protocol converter accidental 4:4:4->4:2:0 conversion for RGB
BR,
Jani.
The following changes since commit 19c329f6808995b142b3966301f217c831e7cf31:
On 21/01/2021 12:22, Carsten Haitzler wrote:
On 1/20/21 3:44 PM, Steven Price wrote:
On 18/01/2021 14:20, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is bueried inside the
NIT: s/bueried/buried/
Yup. typo not spotted by me.
On Thu, Jan 21, 2021 at 02:21:53PM +0100, Maxime Ripard wrote:
> Hi Daniel,
>
> On Thu, Jan 21, 2021 at 12:29:19PM +0100, Daniel Vetter wrote:
> > Interrnship season is starting, let's review this. One thing that's
>
> ^ internship
>
> > pending is Maxime's work to roll out drm_atomic_state
Hi Dave, Daniel,
Fixes for 5.11.
The following changes since commit c8f6364f35f32786dd40336cfa35b9166d91b8ab:
Merge branch '04.00-ampere-lite-fixes' of git://github.com/skeggsb/linux into
drm-fixes (2021-01-15 13:26:44 +1000)
are available in the Git repository at:
Ends right after hw_done(), totally standard case.
Acked-by: Jyri Sarha
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_kms.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_kms.c
Again ends just after drm_atomic_helper_commit_hw_done(), but with the
twist that we need to make sure we're only annotate the custom
version. And not the other clause which just calls
drm_atomic_helper_commit_tail_rpm(), which is already annotated.
Signed-off-by: Daniel Vetter
Cc: Thierry
Ends right after drm_atomic_helper_commit_hw_done(), absolutely
nothing fancy going on here.
Signed-off-by: Daniel Vetter
Cc: Laurent Pinchart
Cc: Kieran Bingham
Cc: linux-renesas-...@vger.kernel.org
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Nothing special, just put the end right after hw_done(). Note that in
one path there's a wait for the flip/update to complete. But as far as
I understand from comments and code that's only relevant for modesets,
and skipped if there wasn't a modeset done on a given crtc.
For a bit more clarity
Like the helpers, nothing special. Well except not, because we the
critical section extends until after hw_done(), since that's the last
thing which could hold up a subsequent atomic commit. That means the
wait_for_flip_done is included, but that's not a problem, we're
allowed to call
drm_atomic_helper_commit_hw_done() is the last thing (no plane cleanup
apparrently), so it's the entire function. And a nice comment
explaining why thw wait_for_flip_done is ahead, unlike the usual
sequence.
Aside, I think since the atomic helpers do track plane disabling now
separately this
One of these drivers that predates the nonblocking support in helpers,
and hand-rolled its own thing. Entirely not anything specific here, we
can just delete it all and replace it with the helper version.
Could also perhaps use the drm_mode_config_helper_suspend/resume
stuff, for another few
Again needs to be put right after the call to
drm_atomic_helper_commit_hw_done(), since that's the last thing which
can hold up a subsequent atomic commit.
No surprises here.
Acked-by: Liviu Dudau
Signed-off-by: Daniel Vetter
Cc: "James (Qian) Wang"
Cc: Liviu Dudau
Cc: Mihail Atanassov
---
This is rather overkill since currently all drivers call this from
hardirq (or at least timers). But maybe in the future we're going to
have thread irq handlers and what not, doesn't hurt to be prepared.
Plus this is an easy start for sprinkling these fence annotations into
shared code.
Cc:
This is a bit disappointing since we need to split the annotations
over all the different parts.
I was considering just leaking the critical section into the
->atomic_commit_tail callback of each driver. But that would mean we
need to pass the fence_cookie into each driver (there's a total of 13
This is needed to signal the fences from page flips, annotate it
accordingly. We need to annotate entire timer callback since if we get
stuck anywhere in there, then the timer stops, and hence fences stop.
Just annotating the top part that does the vblank handling isn't
enough.
Tested-by: Melissa
Hi all,
Finally gotten around to refreshing all the various fence anntotions I've
hast last summer. Or well parts of it:
- entire amdgpu and drm/scheduler annotations postponed for now, because
there's way too many splats in there that need some work
- in recent patches I've seen quite a few
Hi Dave & Daniel,
Here is the final PR for v5.12.
One more fix for the clear residuals security mitigation.
Per-engine reset for Gen7 to avoid collateral damage when some
workloads misbehave, flip priority boosting when using explicit
fences (sync_file), improving suspend/freeze speed and
(cc'ing dri-devel)
Hi,
thanks for reporting the bug.
Am 21.01.21 um 15:35 schrieb Chuck Lever:
Hi Thomas-
I was not able to find an appropriate mailing list entry in MAINTAINERS,
That would be dri-devel@lists.freedesktop.org
so I'm mailing you directly as committer of record for:
On Thu, Jan 21, 2021 at 3:31 PM Thomas Zimmermann wrote:
>
> Hi
>
> we talked about making dma_resv the default lock for GEM objects. Could
> you add an entry for this? Some interns might feel adventurous. :)
Level: Too hard for Daniel
Not sure that's a great internship tasks :-P
But yeah I'll
Hi
we talked about making dma_resv the default lock for GEM objects. Could
you add an entry for this? Some interns might feel adventurous. :)
Best regards
Thomas
Am 21.01.21 um 12:29 schrieb Daniel Vetter:
Interrnship season is starting, let's review this. One thing that's
pending is
Hi Oleksij,
On Thu, Jan 21, 2021 at 3:12 AM Oleksij Rempel wrote:
>
> At some point PWM cell count was changed, but it didn't triggered any
It changed in this commit:
commit fa28d8212ede9c533ae87a737571a9d3b3eebb29
Author: Uwe Kleine-König
Date: Fri Jul 10 07:19:37 2020 +0200
ARM: dts:
On 20/01/2021 20:09, Luben Tuikov wrote:
This patch does not change current behaviour.
The driver's job timeout handler now returns
status indicating back to the DRM layer whether
the device (GPU) is no longer available, such as
after it's been unplugged, or whether all is
normal, i.e. current
Hi Veera,
On Wed, 20 Jan 2021 at 02:00, John Stultz wrote:
>
> On Fri, Jan 15, 2021 at 4:31 PM Veera Sundaram Sankaran
> wrote:
> >
> > Some drivers have hardware capability to get the precise HW timestamp
> > of certain events based on which the fences are triggered. The delta
> > between the
Hi John,
On Wed, 20 Jan 2021 at 02:15, John Stultz wrote:
>
> Every heap needs to create a dmabuf and then export it to a fd
> via dma_buf_fd(), so to consolidate things a bit, have the heaps
> just return a struct dmabuf * and let the top level
> dma_heap_buffer_alloc() call handle creating the
Hi John,
On Wed, 20 Jan 2021 at 02:15, John Stultz wrote:
>
> If we abort from the allocation due to a fatal_signal_pending(),
> be sure we report an error so any return code paths don't trip
> over the fact that the allocation didn't succeed.
Thanks for the patch; LGTM, will push into
I still have no idea what's going on here.
The KASAN messages from the DC code are completely unrelated.
Please add the full dmesg to your bug report.
Christian.
Am 20.01.21 um 01:59 schrieb Mikhail Gavrilov:
On Fri, 15 Jan 2021 at 03:43, Mikhail Gavrilov
wrote:
In rc4, the number of
On Thu, 21 Jan 2021, Fabio Estevam wrote:
> On Thu, Jan 21, 2021 at 9:10 AM Jani Nikula wrote:
>
>> Kinda catch-22 because next has dropped current drm-intel-next because
>> it doesn't build because of the issue this patch fixes. ;)
>
> Ok, so I built drm-intel-next and I was able to reproduce
On Wed, Jan 20, 2021 at 4:22 AM Christian König
wrote:
>
> Am 19.01.21 um 23:57 schrieb Hridya Valsaraju:
> > This patch allows statistics to be enabled for each DMA-BUF in
> > sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS.
> >
> > The following stats will be exposed by the interface:
>
On Wed, Jan 20, 2021 at 4:42 AM Daniel Vetter wrote:
>
> On Wed, Jan 20, 2021 at 1:22 PM Christian König
> wrote:
> >
> > Am 19.01.21 um 23:57 schrieb Hridya Valsaraju:
> > > This patch allows statistics to be enabled for each DMA-BUF in
> > > sysfs by enabling the config
On Thu, Jan 21, 2021 at 9:10 AM Jani Nikula wrote:
> Kinda catch-22 because next has dropped current drm-intel-next because
> it doesn't build because of the issue this patch fixes. ;)
Ok, so I built drm-intel-next and I was able to reproduce the buid
error as reported by Stephen.
Applied this
The OneGX1 Pro has a fairly unique combination of generic strings,
but we additionally match on the BIOS date just to be safe.
Signed-off-by: Jared Baldridge
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 14 ++
1 file changed, 14 insertions(+)
diff --git
On Wed, Jan 20, 2021 at 1:11 AM Daniel Vetter wrote:
>
> On Tue, Jan 19, 2021 at 11:08:12AM -0800, Yiwei Zhang wrote:
> > On Mon, Jan 18, 2021 at 11:03 PM Daniel Vetter wrote:
> > >
> > > On Tue, Jan 19, 2021 at 12:41 AM Yiwei Zhang wrote:
> > > >
> > > > On the success of
On Mon, Jan 18, 2021 at 11:03 PM Daniel Vetter wrote:
>
> On Tue, Jan 19, 2021 at 12:41 AM Yiwei Zhang wrote:
> >
> > On the success of virtio_gpu_object_create, add size of newly allocated
> > bo to the tracled total_mem. In drm_gem_object_funcs.free, after the gem
> > bo lost its last
This patch allows statistics to be enabled for each DMA-BUF in
sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS.
The following stats will be exposed by the interface:
/sys/kernel/dmabuf/buffers//exporter_name
/sys/kernel/dmabuf/buffers//size
/sys/kernel/dmabuf/buffers//attachments//device
On 1/20/21 3:44 PM, Steven Price wrote:
On 18/01/2021 14:20, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is bueried inside the
NIT: s/bueried/buried/
Yup. typo not spotted by me. Thanks. Also - i spotted an accidental
On Thu, 21 Jan 2021, Fabio Estevam wrote:
> On Thu, Jan 21, 2021 at 8:41 AM Jani Nikula wrote:
>
>> On top of what? Current drm-tip?
>
> It was on top of next-20210121.
Kinda catch-22 because next has dropped current drm-intel-next because
it doesn't build because of the issu
Rename ttm_bo_device to ttm_device.
Rename ttm_bo_driver to ttm_device_funcs.
Rename ttm_bo_global to ttm_global.
Move global and device related functions to ttm_device.[ch].
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
Hi Dmitry,
W dniu 17.01.2021 o 01:23, Dmitry Baryshkov pisze:
> drm hotplug handling code (drm_client_dev_hotplug()) can wait on mutex,
> thus delaying further lt9611uxc IRQ events processing. It was observed
> occasionally during bootups, when drm_client_modeset_probe() was waiting
> for EDID
On Thu, Jan 21, 2021 at 8:41 AM Jani Nikula wrote:
> On top of what? Current drm-tip?
It was on top of next-20210121.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, 21 Jan 2021, Fabio Estevam wrote:
> Hi Jani,
>
> On Thu, Jan 21, 2021 at 8:22 AM Jani Nikula wrote:
>
>> Sean, Rob, or anyone with an arm toolchain for msm available, could I
>> trouble you to build test this please?
>
> I tried to build after applying your patch:
On top of what?
Hi Jani,
On Thu, Jan 21, 2021 at 8:22 AM Jani Nikula wrote:
> Sean, Rob, or anyone with an arm toolchain for msm available, could I
> trouble you to build test this please?
I tried to build after applying your patch:
CC drivers/gpu/drm/msm/dp/dp_ctrl.o
drivers/gpu/drm/msm/dp/dp_ctrl.c:
Interrnship season is starting, let's review this. One thing that's
pending is Maxime's work to roll out drm_atomic_state pointers to all
callbacks, he said he'll remove that entry once it's all done.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
On Thu, Jan 21, 2021 at 4:09 AM ZhiJie.Zhang wrote:
>
> From: zhangzhijie
>
> this callback was used by drm_kms_helper_hotplug_event()
>
> V2: (Thanks for Daniel's suggestions)
> - remove the FIXME below.since with the drm_client
> - infrastructure and the generic fbdev emulation we've
> -
On Wed, 20 Jan 2021, Lyude Paul wrote:
> Reviewed-by: Lyude Paul
Thanks for the review.
Sean, Rob, or anyone with an arm toolchain for msm available, could I
trouble you to build test this please?
BR,
Jani.
>
> On Wed, 2021-01-20 at 13:07 +0200, Jani Nikula wrote:
>> Commit 7c553f8b5a7d
В Вс, 13/12/2020 в 12:58 -0800, Thomas Hebb пишет:
> When we first enable the DSI encoder, we currently program some per-chip
> configuration that we look up in rk3399_chip_data based on the device
> tree compatible we match. This data configures various parameters of the
> MIPI lanes, including
On Wed, Jan 20, 2021 at 8:16 PM Andrey Grodzovsky
wrote:
>
>
> On 1/20/21 3:38 AM, Daniel Vetter wrote:
> > On Wed, Jan 20, 2021 at 5:21 AM Andrey Grodzovsky
> > wrote:
> >>
> >> On 1/19/21 5:01 PM, Daniel Vetter wrote:
> >>> On Tue, Jan 19, 2021 at 10:22 PM Andrey Grodzovsky
> >>> wrote:
>
Am 20.01.21 um 21:09 schrieb Luben Tuikov:
This patch does not change current behaviour.
The driver's job timeout handler now returns
status indicating back to the DRM layer whether
the device (GPU) is no longer available, such as
after it's been unplugged, or whether all is
normal, i.e.
Am 20.01.21 um 20:38 schrieb Andrey Grodzovsky:
Ping
Andrey
On 1/20/21 12:01 AM, Andrey Grodzovsky wrote:
On 1/19/21 3:48 AM, Christian König wrote:
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
Handle all DMA IOMMU gropup related dependencies before the
group is removed.
Signed-off-by:
On Thursday, January 21st, 2021 at 10:59 AM, Thomas Zimmermann
wrote:
> Well, I'd strongly ask to not call it "generic", because it isn't. We
> have other USB drivers and anyone can make a USB display with these
> protocols as well. That doesn't make them generic. A USB-standardized
> protocol
Hi
Am 21.01.21 um 09:27 schrieb Daniel Vetter:
On Thu, Jan 21, 2021 at 8:45 AM Thomas Zimmermann wrote:
Hi Noralf,
glad to hear from you! Welcome back!
Am 20.01.21 um 18:42 schrieb Daniel Vetter:
On Wed, Jan 20, 2021 at 6:10 PM Noralf Trønnes wrote:
Add a connector type for USB
Hi
Am 20.01.21 um 18:00 schrieb Noralf Trønnes:
Hi,
A while back I had the idea to turn a Raspberry Pi Zero into a $5
USB to HDMI/SDTV/DSI/DPI display adapter.
The reason for calling it 'Generic' is so anyone can make a USB
display/adapter against this driver, all that's needed is to add a
On Wed, Jan 20, 2021 at 10:52:11AM -0800, Yiwei Zhang wrote:
> On Wed, Jan 20, 2021 at 5:33 AM Gerd Hoffmann wrote:
> >
> > Hi,
> >
> > > > > > > + select TRACE_GPU_MEM
> >
> > > > > > > +#ifdef CONFIG_TRACE_GPU_MEM
> >
> > That doesn't make sense btw.
>
> Do you recommend we just select
01.01.2021 19:55, Yangtao Li пишет:
> Use devm_pm_opp_* API to simplify code.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/memory/tegra/tegra20-emc.c | 29 +
> 1 file changed, 9 insertions(+), 20 deletions(-)
There are also tegra30-emc.c and tegra124-emc.c with a
Le mer. 20 janv. 2021 à 15:04, Daniel Vetter a
écrit :
On Wed, Jan 20, 2021 at 2:21 PM Paul Cercueil
wrote:
Le mer. 20 janv. 2021 à 14:01, Daniel Vetter a
écrit :
> On Wed, Jan 20, 2021 at 1:36 PM Paul Cercueil
> wrote:
>>
>> Since the encoders have been devm-allocated, they
At some point PWM cell count was changed, but it didn't triggered any
error, since this DT was overwriting "#pwm-cells".
To make sure, we are in sync with the kernel driver, remove this
property and fix the pwm consumer.
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-prtvt7.dts | 3
Le mer. 20 janv. 2021 à 14:01, Daniel Vetter a
écrit :
On Wed, Jan 20, 2021 at 1:36 PM Paul Cercueil
wrote:
Since the encoders have been devm-allocated, they will be freed way
before drm_mode_config_cleanup() is called. To avoid use-after-free
conditions, we then must ensure that
The backlight power is controlled through the reg_bl_12v0 regulator.
Co-Developed-by: Robin van der Gracht
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-prtvt7.dts | 9 -
1 file changed, 9 deletions(-)
diff --git
Add binding for the Innolux G070Y2-T02 panel. It is 7" WVGA (800x480)
TFT LCD panel with TTL interface and a backlight unit.
Signed-off-by: Oleksij Rempel
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
Add touchscreen support to the Protonic VT7 board.
Co-Developed-by: Robin van der Gracht
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-prtvt7.dts | 20
1 file changed, 20 insertions(+)
diff --git
Artificially use 'plane' and 'old_plane_state' to avoid 'not used' warning.
The precedent has already been set by other macros in the same file.
Acked-by: Daniel Vetter
Signed-off-by: Liu Ying
---
v5->v6:
* Fix commit message typo - s/Artifically/Artificially/
v4->v5:
* No change.
v3->v4:
*
This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Channel.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v5->v6:
* No change.
v4->v5:
* No change.
v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.
v2->v3:
* No
On Wed, 2021-01-20 at 20:38 +0100, Matthias Brugger wrote:
> On Tue, Jan 05, 2021 at 11:06:26AM +0800, Yongqiang Niu wrote:
> > move register operation into mmsys path select function
>
> Why do you want to do that. It seems the register access pattern is the
> same for all SoCs so far supported,
Add Innolux G070Y2-T02 panel to the Protonic VT7 board.
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-prtvt7.dts | 47 +
1 file changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl-prtvt7.dts
Le mer. 20 janv. 2021 à 17:03, Daniel Vetter a
écrit :
On Wed, Jan 20, 2021 at 1:35 PM Paul Cercueil
wrote:
If we don't call drm_connector_cleanup() manually in
panel_bridge_detach(), the connector will be cleaned up with the
other
DRM objects in the call to
Add Innolux G070Y2-T02 panel to the Protonic VT7 board.
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/imx6dl-prtvt7.dts | 47 +
1 file changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl-prtvt7.dts
01.01.2021 19:54, Yangtao Li пишет:
> Add devres wrapper for dev_pm_opp_set_regulators()
> dev_pm_opp_put_regulators () to simplify driver code.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/opp/core.c | 50 ++
> include/linux/pm_opp.h | 9
>
01.01.2021 19:54, Yangtao Li пишет:
> Add devres wrapper for dev_pm_opp_of_add_table() to simplify driver
> code.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/opp/of.c | 36
> include/linux/pm_opp.h | 6 ++
> 2 files changed, 42 insertions(+)
This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Gasket.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
v5->v6:
* No change.
v4->v5:
* No change.
v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.
v2->v3:
* No change.
Add binding for the Innolux G070Y2-T02 panel. It is 7" WVGA (800x480)
TFT LCD panel with TTL interface and a backlight unit.
Signed-off-by: Oleksij Rempel
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
Add compatible and timings for the Innolux G070Y2-T02 panel. It is 7"
WVGA (800x480) TFT LCD panel with TTL interface and a backlight unit.
Co-Developed-by: Robin van der Gracht
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
drivers/gpu/drm/panel/panel-simple.c | 16
If we don't call drm_connector_cleanup() manually in
panel_bridge_detach(), the connector will be cleaned up with the other
DRM objects in the call to drm_mode_config_cleanup(). However, since our
drm_connector is devm-allocated, by the time drm_mode_config_cleanup()
will be called, our connector
changes v2:
- imx6dl-prtvt7: remove touchscreen-inverted-*
Oleksij Rempel (7):
dt-bindings: display: simple: add Innolux G070Y2-T02 panel
drm: panel-simple: Add support for the Innolux G070Y2-T02 panel
ARM: dts: imx6dl-prtvt7: Add display and panel nodes
ARM: dts: imx6dl-prtvt7: add
Remove touchscreen-size-* properties. This values are not correct, event if it
works with ts_test tool, it fails to work properly with weston.
And the real range of values reported by the driver (or measured by the
controller) is close to max values and may change with time on resistive
panels.
Panfrost hunks
Acked-by: Alyssa Rosenzweig
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Add compatible and timings for the Innolux G070Y2-T02 panel. It is 7"
WVGA (800x480) TFT LCD panel with TTL interface and a backlight unit.
Co-Developed-by: Robin van der Gracht
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
drivers/gpu/drm/panel/panel-simple.c | 16
On Wed, 2021-01-20 at 11:27 +0200, Laurentiu Palcu wrote:
> Hi Liu Ying,
>
> On Wed, Jan 20, 2021 at 04:42:50PM +0800, Liu Ying wrote:
> > Hi Laurentiu,
> >
> > On Fri, 2021-01-15 at 19:27 +0200, Laurentiu Palcu wrote:
> > > Hi Liu Ying,
> > >
> > > I promised I would have a second, more
Put DRM device on initialization failure path rather than directly
return error code.
Fixes: a67d5088ceb8 ("drm/imx: drop explicit drm_mode_config_cleanup")
Signed-off-by: Pan Bian
---
drivers/gpu/drm/imx/imx-drm-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Since the encoders have been devm-allocated, they will be freed way
before drm_mode_config_cleanup() is called. To avoid use-after-free
conditions, we then must ensure that drm_encoder_cleanup() is called
before the encoders are freed.
v2: Use the new __drmm_simple_encoder_alloc() function
The meta-schema recently gained a definition for the common -supply$
property, which denotes that maxItems is not a valid property. Drop this
to clear up the binding validation error.
Fixes: a46c112512de ("dt-bindings: dp-connector: add binding for DisplayPort
connector")
Signed-off-by: Bjorn
Hi,
This is the v6 series to introduce i.MX8qm/qxp Display Processing Unit(DPU)
DRM support.
DPU is comprised of a blit engine for 2D graphics, a display controller
and a command sequencer. Outside of DPU, optional prefetch engines can
fetch data from memory prior to some DPU fetchunits of
1 - 100 of 128 matches
Mail list logo
