As long as nobody objects I'm going to push this one here to
drm-misc-next with Rob's rb.
The other patches still need a bit more work, but being able to at least
compile test MSM on x86 is really helpful.
Christian.
Am 24.09.21 um 09:17 schrieb Christian König:
MSM is one of the few driver
Hi,
On Sat, Sep 25, 2021 at 7:24 AM Brian Norris wrote:
>
> In commit 59eb7193bef2, we moved most HW configuration to bind(), but we
> didn't move the runtime PM management. Therefore, depending on initial
> boot state, runtime-PM workqueue delays, and other timing factors, we
> may disable our p
On Sat, Sep 25, 2021 at 7:24 AM Brian Norris wrote:
>
> Our probe() function never enabled this clock, so we shouldn't disable
> it if we fail to probe the bridge.
>
> Noted by inspection.
>
> Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge
> driver")
> Signed-off-by: B
The error code is stored in "dev_priv", not "dev". The "dev" pointer
isn't initialized yet.
Fixes: c2f17e60cbe1 ("drm/gma500: Embed struct drm_device in struct
drm_psb_private")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/gma500/psb_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On Mon, Sep 27, 2021 at 10:16 AM Dan Carpenter wrote:
>
> The error code is stored in "dev_priv", not "dev". The "dev" pointer
> isn't initialized yet.
>
Hi Dan,
This is already addressed in:
https://patchwork.kernel.org/project/dri-devel/patch/20210924094040.3631675-1-yangyingli...@huawei.com/
Hi
Am 27.09.21 um 10:16 schrieb Dan Carpenter:
The error code is stored in "dev_priv", not "dev". The "dev" pointer
isn't initialized yet.
Fixes: c2f17e60cbe1 ("drm/gma500: Embed struct drm_device in struct
drm_psb_private")
Signed-off-by: Dan Carpenter
Thanks for the patch. There's alread
On Fri, 3 Sep 2021 11:47:59 -0700
Rob Clark wrote:
> From: Rob Clark
>
> The initial purpose is for igt tests, but this would also be useful for
> compositors that wait until close to vblank deadline to make decisions
> about which frame to show.
>
> Signed-off-by: Rob Clark
> ---
> drivers
Am 27.09.21 um 10:42 schrieb Pekka Paalanen:
On Fri, 3 Sep 2021 11:47:59 -0700
Rob Clark wrote:
From: Rob Clark
The initial purpose is for igt tests, but this would also be useful for
compositors that wait until close to vblank deadline to make decisions
about which frame to show.
Signed-o
From: Arnd Bergmann
Linking fails when dma-buf is disabled:
ld.lld: error: undefined symbol: dma_fence_release
>>> referenced by fence.c
>>> gpu/host1x/fence.o:(host1x_syncpt_fence_enable_signaling) in
>>> archive drivers/built-in.a
>>> referenced by fence.c
>>> gpu/
On Sat, Sep 25, 2021 at 7:41 PM Arnd Bergmann wrote:
> On Sat, Sep 25, 2021 at 3:47 PM Greg Kroah-Hartman
> wrote:
> > Only test-built on x86 allmodconfig, don't know what other arches will
> > pick up, will let 0-day run on it for a bit...
>
> I've added it to my build box doing arm32/arm64/x8
On Wed, Sep 22, 2021 at 04:10:14PM +0100, Mark Brown wrote:
> Currently autoloading for SPI devices does not use the DT ID table, it uses
> SPI modalises. Supporting OF modalises is going to be difficult if not
> impractical, an attempt was made but has been reverted, so ensure that
> module autolo
From: Arnd Bergmann
A conversion from 'bool' to 'enum odm_combine_mode' was incomplete,
and gcc warns about this with many instances of
display/dc/dml/dcn20/display_mode_vba_20.c:3899:44: warning: implicit
conversion from 'enum ' to 'enum
odm_combine_mode' [-Wenum-conversion]
3899 | locals
Am 25.09.21 um 15:47 schrieb Greg Kroah-Hartman:
In order to better track where in the kernel the dma-buf code is used,
put the symbols in the namespace DMA_BUF and modify all users of the
symbols to properly import the namespace to not break the build at the
same time.
Now the output of modinfo
On 9/27/21 12:36 PM, Arnd Bergmann wrote:
From: Arnd Bergmann
Linking fails when dma-buf is disabled:
ld.lld: error: undefined symbol: dma_fence_release
referenced by fence.c
gpu/host1x/fence.o:(host1x_syncpt_fence_enable_signaling) in
archive drivers/built-in.a
referenced by
Hello Greg,
Thanks for the patch!
On Sat, 25 Sept 2021 at 19:17, Greg Kroah-Hartman <
gre...@linuxfoundation.org> wrote:
> In order to better track where in the kernel the dma-buf code is used,
> put the symbols in the namespace DMA_BUF and modify all users of the
> symbols to properly import th
From: Arnd Bergmann
The overflow check does causes a warning from clang-14 when 'sz' is a type
that is smaller than size_t:
drivers/gpu/drm/msm/msm_gem_submit.c:217:10: error: result of comparison of
constant 18446744073709551615 with expression of type 'unsigned int' is always
false [-Werror,
In commit:
commit 58aa6622d32af7d2c08d45085f44c54554a16ed7
Author: Thomas Hellstrom
Date: Fri Jan 3 11:47:23 2014 +0100
drm/ttm: Correctly set page mapping and -index members
we started setting the page->mapping and page->index to point to the
virtual address space, if the pages were faul
In commit:
commit 09ac4fcb3f255e9225967c75f5893325c116cdbe
Author: Felix Kuehling
Date: Thu Jul 13 17:01:16 2017 -0400
drm/ttm: Implement vm_operations_struct.access v2
we added the vm_access hook, where we also directly call tt_swapin for
some reason. If something is swapped-out then the
Move it to inline kernel-doc, otherwise we can't add empty lines it
seems. Also drop the kernel-doc for pages_list, which doesn't seem to
exist.
v2(Christian):
- Add a note that FLAG_SWAPPED shouldn't need to be touched by drivers.
- Mention what FLAG_POPULATED does.
Signed-off-by: Matthew Au
Now that setting page->index shouldn't be needed anymore, we are just
left with setting page->mapping, and here it looks like amdgpu is the
only user, where pointing the page->mapping at the dev_mapping is used
to verify that the pages do indeed belong to the device, if userspace
later tries to tou
It covers more than just ttm_bo_type_sg usage, like with say dma-buf,
since one other user is userptr in amdgpu, and in the future we might
have some more. Hence EXTERNAL is likely a more suitable name.
v2(Christian):
- Rename these to TTM_TT_FLAGS_*
- Fix up all the holes in the flag values
No longer used it seems.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
Reviewed-by: Christian König
---
include/drm/ttm/ttm_tt.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h
index 89b15d673b22..842ce756213c 10064
From: Thomas Hellström
Break out some shmem backend utils for future reuse by the TTM backend:
shmem_alloc_st(), shmem_free_st() and __shmem_writeback() which we can
use to provide a shmem-backed TTM page pool for cached-only TTM
buffer objects.
Main functional change here is that we now compute
For cached objects we can allocate our pages directly in shmem. This
should make it possible(in a later patch) to utilise the existing
i915-gem shrinker code for such objects. For now this is still disabled.
v2(Thomas):
- Add optional try_to_writeback hook for objects. Importantly we need
to
In commit:
commit 667a50db0477d47fdff01c666f5ee1ce26b5264c
Author: Thomas Hellstrom
Date: Fri Jan 3 11:17:18 2014 +0100
drm/ttm: Refuse to fault (prime-) imported pages
we introduced the restriction that imported pages should not be directly
mappable through TTM(this also extends to userp
This should let us do an accelerated copy directly to the shmem pages
when temporarily moving lmem-only objects, where the i915-gem shrinker
can later kick in to swap out the pages, if needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 8 -
Drop the atomic shrink_pin stuff, and just have make_{un}shrinkable
update the shrinker visible lists immediately. This at least simplifies
the next patch, and does make the behaviour more obvious. The potential
downside is that make_unshrinkable now grabs a global lock even when the
object itself
We currently just evict lmem objects to system memory when under memory
pressure, and in the next patch we want to use the shmem backend even
for this case. For this case we lack the usual object mm.pages, which
effectively hides the pages from the i915-gem shrinker, until we
actually "attach" the
Turn on the shmem tt backend, and enable shrinking.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 46d57541c
On Mon, 06 Sep 2021, Kai Vehmanen wrote:
> Hi,
>
> On Mon, 6 Sep 2021, Kai-Heng Feng wrote:
>
>> Commit 989634fb49ad ("drm/i915/audio: set HDA link parameters in
>> driver") makes HDMI audio on Lenovo P350 disappear.
>>
>> So in addition to TGL, extend the logic to RKL to use BIOS provided
>> val
Any objections that I just push patches 1-7 to drm-misc-next?
Christian.
Am 27.09.21 um 13:41 schrieb Matthew Auld:
In commit:
commit 09ac4fcb3f255e9225967c75f5893325c116cdbe
Author: Felix Kuehling
Date: Thu Jul 13 17:01:16 2017 -0400
drm/ttm: Implement vm_operations_struct.access v2
On Mon, Sep 27, 2021 at 10:42:00AM +0100, Daniel Thompson wrote:
> Based on this I had expected to find spi_get_device_id() and a ->driver_data
> somewhere in this patch.
> Where will this .driver_data be consumed?
It will never be consumed unless someone writes a board file - the
runtime match
On Fri, Sep 24, 2021 at 04:37:43PM -0400, Eric Farman wrote:
> > @@ -528,6 +534,7 @@ static int __init vfio_ccw_sch_init(void)
> >
> > static void __exit vfio_ccw_sch_exit(void)
> > {
> > + mdev_unregister_driver(&vfio_ccw_mdev_driver);
>
> Wouldn't it be better to mirror the unwind-init cas
From: Arnd Bergmann
clang-14 points out that comparing an 'unsigned int' against a large
64-bit constantn is pointless:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1206:18: error: result of comparison
of constant 4294967296 with expression of type 'resource_size_t' (aka 'unsigned
int') is alway
From: Arnd Bergmann
The two AMD drivers have their own custom offsetof() implementation
that now triggers a warning with recent versions of clang:
drivers/gpu/drm/radeon/radeon_atombios.c:133:14: error: performing pointer
subtraction with a null pointer has undefined behavior
[-Werror,-Wnull-p
In general that change looks good. But what configuration is that?
Background is that it doesn't make much sense to compile the amdgpu
driver on systems where resource_size_t is only 32bit.
Christian.
Am 27.09.21 um 14:19 schrieb Arnd Bergmann:
From: Arnd Bergmann
clang-14 points out that
On Fri, Sep 24, 2021 at 04:45:02PM -0400, Eric Farman wrote:
> On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote:
> > Having a mdev pointer floating about in addition to a struct
> > vfio_device
> > is confusing. It is only used for three things:
> >
> > - Getting the mdev 'struct device *'
From: Arnd Bergmann
The overflow check in amdgpu_bo_list_create() causes a warning with
clang-14 on 64-bit architectures, since the limit can never be
exceeded.
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:74:18: error: result of comparison
of constant 256204778801521549 with expression of type
Am 27.09.21 um 14:58 schrieb Arnd Bergmann:
From: Arnd Bergmann
The overflow check in amdgpu_bo_list_create() causes a warning with
clang-14 on 64-bit architectures, since the limit can never be
exceeded.
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:74:18: error: result of comparison
of consta
On Mon, Sep 27, 2021 at 12:47:27PM +0100, Mark Brown wrote:
> On Mon, Sep 27, 2021 at 10:42:00AM +0100, Daniel Thompson wrote:
>
> > Based on this I had expected to find spi_get_device_id() and a ->driver_data
> > somewhere in this patch.
>
> > Where will this .driver_data be consumed?
>
> It w
On Mon, Sep 27, 2021 at 02:24:17PM +0100, Daniel Thompson wrote:
> In that case what is the point of including unconsumed driver data? Most
> DT centric drivers that included this for modalias reasons leave it
> NULL.
It's mainly there because it's generated fairly mechanically from the OF
ID tab
From: Arnd Bergmann
The meaning of the 'imply' keyword has changed recently, and neither the
old meaning (select the symbol if its dependencies are met) nor the new
meaning (enable it by default, but let the user set any other setting)
is what we want here.
Work around this by adding two more Kc
From: Arnd Bergmann
With CONFIG_FB=m and CONFIG_DRM=y, we get a link error in the fb helper:
aarch64-linux-ld: drivers/gpu/drm/drm_fb_helper.o: in function
`drm_fb_helper_alloc_fbi':
(.text+0x10cc): undefined reference to `framebuffer_alloc'
Tighten the dependency so it is only allowed in the
On Mon, Sep 27, 2021 at 1:42 AM Pekka Paalanen wrote:
>
> On Fri, 3 Sep 2021 11:47:59 -0700
> Rob Clark wrote:
>
> > From: Rob Clark
> >
> > The initial purpose is for igt tests, but this would also be useful for
> > compositors that wait until close to vblank deadline to make decisions
> > abo
Due to a simple typo (apparently I can't count. It goes 0, 1, 2 and
not 0, 2, 3) we were getting a kernel doc warning that looked like
this:
include/drm/drm_edid.h:530: warning:
Function parameter or member 'vend_chr_1' not described in
'drm_edid_encode_panel_id'
include/drm/drm_edid.h:530: war
Hi,
On Sun, Sep 26, 2021 at 10:44 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (htmldocs)
> produced these warnings:
>
> include/drm/drm_edid.h:530: warning: Function parameter or member
> 'vend_chr_1' not described in 'drm_edid_encode_pane
On Fri, Sep 24, 2021 at 04:23:45PM -0700, Brian Norris wrote:
> In commit 59eb7193bef2, we moved most HW configuration to bind(), but we
> didn't move the runtime PM management. Therefore, depending on initial
> boot state, runtime-PM workqueue delays, and other timing factors, we
> may disable our
On Mon, Sep 27, 2021 at 7:15 AM Sumit Semwal wrote:
>
> Hello Greg,
>
> Thanks for the patch!
>
> On Sat, 25 Sept 2021 at 19:17, Greg Kroah-Hartman
> wrote:
>>
>> In order to better track where in the kernel the dma-buf code is used,
>> put the symbols in the namespace DMA_BUF and modify all use
We may end up in i915_ttm_bo_destroy() in an error path before the
object is fully initialized. In that case it's not correct to call
__i915_gem_free_object(), because that function
a) Assumes the gem object refcount is 0, which it isn't.
b) frees the placements which are owned by the caller until
On Sun, Sep 26, 2021 at 12:36 PM Dmitry Baryshkov
wrote:
>
> On Sun, 26 Sept 2021 at 22:01, Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > If the device file was opened prior to fw being available (such as from
> > initrd before rootfs is mounted, when the initrd does not contain GPU
> > fw),
From: Arnd Bergmann
Now that SCM can be a loadable module, we have to add another
dependency to avoid link failures when ipa or adreno-gpu are
built-in:
aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe':
ipa_main.c:(.text+0xfc4): undefined reference to `qcom_scm_is_available'
From: Rob Clark
I've seen a few crashes like:
Internal error: synchronous external abort: 9610 [#1] PREEMPT SMP
Modules linked in: snd_seq_dummy snd_seq snd_seq_device bridge stp llc tun
nf_nat_tftp nf_conntrack_tftp nf_nat_ftp nf_conntrack_ftp esp6 ah6 ip6t_REJECT
ip6t_ipv6header
Include FEC, DSC, Link Training related headers.
Signed-off-by: Fangzhi Zuo
---
This patch is based on top of the other DP2.0 work in
"drm/dp: add LTTPR DP 2.0 DPCD addresses"
---
include/drm/drm_dp_helper.h | 20
1 file changed, 20 insertions(+)
diff --git a/include/drm/dr
Coverity complains of a possible buffer overflow. However,
given the 'static' scope of nvidia_setup_i2c_bus() it looks
like that can't happen after examiniing the call sites.
CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)
1. fixed_size_dest: You might overrun the 48-character f
There's some interactions between the SCDC setup and the disconnection /
reconnection of displays. Let's document it and a solution.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_scdc_helper.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_scdc_help
On Mon, 27 Sept 2021 at 12:47, Christian König wrote:
>
> Any objections that I just push patches 1-7 to drm-misc-next?
Please go ahead Christian. Thanks.
>
> Christian.
>
> Am 27.09.21 um 13:41 schrieb Matthew Auld:
> > In commit:
> >
> > commit 09ac4fcb3f255e9225967c75f5893325c116cdbe
> > Auth
Hi Paul,
> Am 25.09.2021 um 21:39 schrieb Paul Cercueil :
>
>
>
> Le sam., sept. 25 2021 at 21:26:42 +0200, H. Nikolaus Schaller
> a écrit :
>> Hi Paul,
>>> Am 25.09.2021 um 21:08 schrieb Paul Cercueil :
>>> Hi Paul & Nikolaus,
>>> If you spent some time debugging the issue
>> we did ...
>
>
On 9/27/21 7:41 AM, Douglas Anderson wrote:
Due to a simple typo (apparently I can't count. It goes 0, 1, 2 and
not 0, 2, 3) we were getting a kernel doc warning that looked like
this:
include/drm/drm_edid.h:530: warning:
Function parameter or member 'vend_chr_1' not described in
'drm_edid_e
On Mon, Sep 27, 2021 at 04:28:02PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> With CONFIG_FB=m and CONFIG_DRM=y, we get a link error in the fb helper:
>
> aarch64-linux-ld: drivers/gpu/drm/drm_fb_helper.o: in function
> `drm_fb_helper_alloc_fbi':
> (.text+0x10cc): undefined reference
From: Paul Boddie
Add support for the LCD controller present on JZ4780 SoCs.
This SoC uses 8-byte descriptors which extend the current
4-byte descriptors used for other Ingenic SoCs.
Tested on MIPS Creator CI20 board.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H.
From: Paul Boddie
If ingenic drm driver can not be registered, the IPU driver won't be
deregistered.
Code structure is chosen in preparation to add hdmi unregistration
in error case following the same pattern by a later patch.
Signed-off-by: Paul Boddie
Signed-off-by: H. Nikolaus Schaller
---
From: Sam Ravnborg
Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
Based on .txt binding from Zubair Lutfullah Kakakhel
Signed-off-by: Sam Ravnborg
Signed-off-by: H. Nikolaus Schaller
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
---
.../bindings/display/ingenic-jz4780-hdmi.
It appears that dw-hdmi plugin detection is not properly
propagated unless we call drm_kms_helper_hotplug_event().
Maybe drm_bridge_hpd_notify should have been setup to
call this.
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 ++
1 file changed, 2 inserti
From: Paul Boddie
We need to hook up
* HDMI connector
* HDMI power regulator
* DDC pinmux
* HDMI and LCDC endpoint connections
Signed-off-by: Paul Boddie
Signed-off-by: H. Nikolaus Schaller
---
arch/mips/boot/dts/ingenic/ci20.dts | 67 +
1 file changed, 67 insertio
From: Paul Boddie
The jz4780 has some features which need initialization
according to the vendor kernel.
Signed-off-by: Paul Boddie
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/dr
- fix setting output_port = 1 (issue found by p...@crapouillou.net)
- ci20.dts: convert to use hdmi-connector (by h...@goldelico.com)
- add a hdmi-regulator to control +5V power (by h...@goldelico.com)
- added a fix to dw-hdmi to call drm_kms_helper_hotplug_event on plugin event
detection (by h...
Enable CONFIG options as modules.
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
arch/mips/configs/ci20_defconfig | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index ab7ebb066834..9c9c649d385
From: Paul Boddie
A specialisation of the generic Synopsys HDMI driver is employed for JZ4780
HDMI support. This requires a new driver, plus device tree and configuration
modifications.
Signed-off-by: Paul Boddie
Signed-off-by: H. Nikolaus Schaller
---
arch/mips/boot/dts/ingenic/jz4780.dtsi |
From: Paul Boddie
The platform-specific configuration structure is augmented with
mode_fixup and timings members so that specialisations of the
Synopsys driver can introduce mode flags and bus flags.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
From: Paul Boddie
A specialisation of the generic Synopsys HDMI driver is employed for JZ4780
HDMI support. This requires a new driver, plus device tree and configuration
modifications.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/
Hi,
On Mon, Sep 27, 2021 at 06:44:23PM +0200, H. Nikolaus Schaller wrote:
> It appears that dw-hdmi plugin detection is not properly
> propagated unless we call drm_kms_helper_hotplug_event().
>
> Maybe drm_bridge_hpd_notify should have been setup to
> call this.
>
> Signed-off-by: H. Nikolaus S
Hi,
On Mon, Sep 27, 2021 at 06:44:21PM +0200, H. Nikolaus Schaller wrote:
> From: Sam Ravnborg
>
> Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
> Based on .txt binding from Zubair Lutfullah Kakakhel
>
> Signed-off-by: Sam Ravnborg
> Signed-off-by: H. Nikolaus Schaller
> Cc:
On Mon, Sep 27, 2021 at 06:44:24PM +0200, H. Nikolaus Schaller wrote:
> From: Paul Boddie
>
> A specialisation of the generic Synopsys HDMI driver is employed for JZ4780
> HDMI support. This requires a new driver, plus device tree and configuration
> modifications.
>
> Signed-off-by: Paul Boddie
> Am 27.09.2021 um 19:00 schrieb Maxime Ripard :
>
> Hi,
>
> On Mon, Sep 27, 2021 at 06:44:23PM +0200, H. Nikolaus Schaller wrote:
>> It appears that dw-hdmi plugin detection is not properly
>> propagated unless we call drm_kms_helper_hotplug_event().
>>
>> Maybe drm_bridge_hpd_notify should
> Am 27.09.2021 um 19:08 schrieb Maxime Ripard :
>
> On Mon, Sep 27, 2021 at 06:44:24PM +0200, H. Nikolaus Schaller wrote:
>> From: Paul Boddie
>>
>> A specialisation of the generic Synopsys HDMI driver is employed for JZ4780
>> HDMI support. This requires a new driver, plus device tree and co
From: Rob Clark
I've seen some crashes in our crash reporting that *look* like multiple
threads stomping on each other while communicating with GMU. So wrap
all those paths in a lock.
Signed-off-by: Rob Clark
---
Are we allowed to use c99/gnu99 yet?
drivers/gpu/drm/msm/Makefile | 2
The Rockchip DSI driver has had a number of bugs over time and has
usually only worked by chance. A number of users have noticed that
things regressed with commit 43c2de1002d2 ("drm/rockchip: dsi: move all
lane config except LCDC mux to bind()"), although it was fixing several
real issues of its ow
In commit 43c2de1002d2, we moved most HW configuration to bind(), but we
didn't move the runtime PM management. Therefore, depending on initial
boot state, runtime-PM workqueue delays, and other timing factors, we
may disable our power domain in between the hardware configuration
(bind()) and when
Our probe() function never enabled this clock, so we shouldn't disable
it if we fail to probe the bridge.
Noted by inspection.
Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge
driver")
Signed-off-by: Brian Norris
Reviewed-by: Chen-Yu Tsai
---
(no changes since v1)
Fix some error handling here noticed in review of other changes.
Reported-by: Chen-Yu Tsai
Signed-off-by: Brian Norris
---
Changes in v2:
- New
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/
On 09/07/2021 02:03, Dmitry Baryshkov wrote:
- set DRM_CONNECTOR_POLL_HPD as the connector will generate hotplug
events on its own
- do not call drm_kms_helper_hotplug_event() unless mode_config.funcs
pointer is not NULL to remove possible kernel oops.
Fixes: bc6fa8676ebb ("drm/bridge/lon
On Mon, Sep 27, 2021 at 12:10 AM Chen-Yu Tsai wrote:
> On Sat, Sep 25, 2021 at 7:24 AM Brian Norris wrote:
> > We should match the runtime PM to the lifetime of the bind()/unbind()
> > cycle.
>
> I'm not too familiar with MIPI DSI, but it seems that the subsystem expects
> the DSI link to be alwa
Reviewed-by: Thomas Hebb
Thank you for catching this, and sorry that my original fix broke things.
There had actually been a report of this breakage from my patch, but I
missed that email until it had already been merged and then didn't have
time to follow up on it. Totally my bad.
On Mon, Sep 2
Reviewed-by: Thomas Hebb
Thank you for catching this, and sorry that my original fix broke things.
There had actually been a report of this breakage from my patch, but I
missed that email until it had already been merged and then didn't have
time to follow up on it. Totally my bad.
[Resending be
Applied. Thanks!
On Mon, Sep 27, 2021 at 9:07 AM Christian König
wrote:
>
> Am 27.09.21 um 14:58 schrieb Arnd Bergmann:
> > From: Arnd Bergmann
> >
> > The overflow check in amdgpu_bo_list_create() causes a warning with
> > clang-14 on 64-bit architectures, since the limit can never be
> > exce
Include FEC, DSC, Link Training related headers.
Change since v2
- Align with the spec for DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT
Signed-off-by: Fangzhi Zuo
---
This patch is based on top of the other DP2.0 work in
"drm/dp: add LTTPR DP 2.0 DPCD addresses"
---
include/drm/drm_dp_helper.h | 20 +++
Applied. Thanks!
Alex
On Sun, Sep 26, 2021 at 3:10 PM Amos Jianjun Kong wrote:
>
> On Sun, Sep 26, 2021 at 3:17 PM Yang Li wrote:
>>
>> Use resource_size function on resource object
>> instead of explicit computation.
>>
>> Clean up coccicheck warning:
>> ./drivers/gpu/drm/amd/amdkfd/kfd_migra
Applied. Thanks!
Alex
On Mon, Sep 27, 2021 at 8:21 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> The two AMD drivers have their own custom offsetof() implementation
> that now triggers a warning with recent versions of clang:
>
> drivers/gpu/drm/radeon/radeon_atombios.c:133:14: error: pe
On Thu, Sep 23, 2021 at 03:29:37AM +0300, Laurent Pinchart wrote:
> Hi Maxime,
>
> Thank you for the patch.
>
> I know this has already been merged, but I have a question.
>
> On Fri, Sep 10, 2021 at 03:09:39PM +0200, Maxime Ripard wrote:
> > Display drivers so far need to have a lot of boilerpl
On Mon 27 Sep 08:22 PDT 2021, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Now that SCM can be a loadable module, we have to add another
> dependency to avoid link failures when ipa or adreno-gpu are
> built-in:
>
> aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe':
> ipa_
On Mon, Sep 27, 2021 at 12:18 PM Tom Hebb wrote:
> Reviewed-by: Thomas Hebb
Thanks!
> Thank you for catching this, and sorry that my original fix broke things.
> There had actually been a report of this breakage from my patch, but I
> missed that email until it had already been merged and then
When I originally moved all of the VESA backlight code in i915 into DRM
helpers, one of the things I didn't have the hardware or time for
testing was machines that used a combination of PWM and DPCD in order to
control their backlights. This has since then caused some breakages and
resulted in us d
This simply adds proper support for panel backlights that can be controlled
via VESA's backlight control protocol, but which also require that we
enable and disable the backlight via PWM instead of via the DPCD interface.
We also enable this by default, in order to fix some people's backlights
that
Now that we've added support to i915 for controlling panel backlights that
need PWM to be enabled/disabled, let's finalize this and add support for
controlling brightness levels via PWM as well. This should hopefully put us
towards the path of supporting _ALL_ backlights via VESA's DPCD interface
w
Hooray! We've managed to hit enough bugs upstream that I've been able to
come up with a pretty solid explanation for how backlight controls are
actually supposed to be detected and used these days. As well, having the
rest of the PWM bits in VESA's backlight interface implemented seems to
have fixe
On Mon, Sep 27, 2021 at 9:52 PM Bjorn Andersson
wrote:
> On Mon 27 Sep 08:22 PDT 2021, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > - To avoid a circular dependency chain involving RESET_CONTROLLER
> >and PINCTRL_SUNXI, change the 'depends on RESET_CONTROLLER' in
> >the latter on
On Mon 27 Sep 13:15 PDT 2021, Arnd Bergmann wrote:
> On Mon, Sep 27, 2021 at 9:52 PM Bjorn Andersson
> wrote:
> > On Mon 27 Sep 08:22 PDT 2021, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > - To avoid a circular dependency chain involving RESET_CONTROLLER
> > >and PINCTRL_SUNXI
On Mon, 2021-09-27 at 09:32 -0300, Jason Gunthorpe wrote:
> On Fri, Sep 24, 2021 at 04:45:02PM -0400, Eric Farman wrote:
> > On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote:
> > > Having a mdev pointer floating about in addition to a struct
> > > vfio_device
> > > is confusing. It is only
On Mon, Sep 27, 2021 at 10:42 PM Bjorn Andersson
wrote:
> On Mon 27 Sep 13:15 PDT 2021, Arnd Bergmann wrote:
> > On Mon, Sep 27, 2021 at 9:52 PM Bjorn Andersson
> > wrote:
> >
> > An easier option might be to find a way to build QCOM_SCM without
> > RESET_CONTROLLER for compile testing purposes.
On Thu, 23 Sep 2021 14:01:38 +0100, Kieran Bingham wrote:
> From: Kieran Bingham
>
> Extend the Renesas DU display bindings to support the r8a779a0 V3U.
>
> Reviewed-by: Laurent Pinchart
> Reviewed-by: Geert Uytterhoeven
> Signed-off-by: Kieran Bingham
>
> ---
> v2:
> - Collected Laurent's
1 - 100 of 121 matches
Mail list logo
