From: Philip Yang
[ Upstream commit 197ae17722e989942b36e33e044787877f158574 ]
Device manager releases device-specific resources when a driver
disconnects from a device, devm_memunmap_pages and
devm_release_mem_region calls in svm_migrate_fini are redundant.
It causes below warning trace after
From: Philip Yang
[ Upstream commit 7d6687200a939176847090bbde5cb79a82792a2f ]
If svm migration init failed to create pgmap for device memory, set
pgmap type to 0 to disable device SVM support capability.
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
Signed-off-by: Alex Deucher
Sign
On Tue, Sep 28, 2021 at 2:00 AM Brian Norris wrote:
>
> Fix some error handling here noticed in review of other changes.
>
> Reported-by: Chen-Yu Tsai
> Signed-off-by: Brian Norris
Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi
bridge driver")
Otherwise,
Reviewed-by: Chen
On Mon, 27 Sep 2021 18:44:21 +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: Rob Herrin
On 28/09/2021 04:33, abhin...@codeaurora.org wrote:
On 2021-09-27 18:29, Dmitry Baryshkov wrote:
On 28/09/2021 04:19, abhin...@codeaurora.org wrote:
On 2021-09-27 18:06, Dmitry Baryshkov wrote:
On Tue, 28 Sept 2021 at 03:22, wrote:
On 2021-09-25 12:43, Dmitry Baryshkov wrote:
> On 21/09/202
On 2021-09-27 18:29, Dmitry Baryshkov wrote:
On 28/09/2021 04:19, abhin...@codeaurora.org wrote:
On 2021-09-27 18:06, Dmitry Baryshkov wrote:
On Tue, 28 Sept 2021 at 03:22, wrote:
On 2021-09-25 12:43, Dmitry Baryshkov wrote:
> On 21/09/2021 23:52, abhin...@codeaurora.org wrote:
>> On 2021-09
On 28/09/2021 04:19, abhin...@codeaurora.org wrote:
On 2021-09-27 18:06, Dmitry Baryshkov wrote:
On Tue, 28 Sept 2021 at 03:22, wrote:
On 2021-09-25 12:43, Dmitry Baryshkov wrote:
> On 21/09/2021 23:52, abhin...@codeaurora.org wrote:
>> On 2021-09-21 10:47, Dmitry Baryshkov wrote:
>>> Hi,
>>>
On 2021-09-27 18:06, Dmitry Baryshkov wrote:
On Tue, 28 Sept 2021 at 03:22, wrote:
On 2021-09-25 12:43, Dmitry Baryshkov wrote:
> On 21/09/2021 23:52, abhin...@codeaurora.org wrote:
>> On 2021-09-21 10:47, Dmitry Baryshkov wrote:
>>> Hi,
>>>
>>> On Tue, 21 Sept 2021 at 20:01, wrote:
On Mon, Sep 27, 2021 at 03:57:34PM -0500, Rob Herring wrote:
> 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
On Tue, 28 Sept 2021 at 03:22, wrote:
>
> On 2021-09-25 12:43, Dmitry Baryshkov wrote:
> > On 21/09/2021 23:52, abhin...@codeaurora.org wrote:
> >> On 2021-09-21 10:47, Dmitry Baryshkov wrote:
> >>> Hi,
> >>>
> >>> On Tue, 21 Sept 2021 at 20:01, wrote:
>
> On 2021-09-21 09:22, Dmitry Ba
On 2021-09-25 12:43, Dmitry Baryshkov wrote:
On 21/09/2021 23:52, abhin...@codeaurora.org wrote:
On 2021-09-21 10:47, Dmitry Baryshkov wrote:
Hi,
On Tue, 21 Sept 2021 at 20:01, wrote:
On 2021-09-21 09:22, Dmitry Baryshkov wrote:
> The DSI host might be left in some state by the bootloader.
Hi,
On Mon, Sep 27, 2021 at 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' n
From: Rob Clark
Add a short delay before clamping to idle frequency on active->idle
transition. It takes ~0.5ms to increase the freq again on the next
idle->active transition, so this helps avoid extra freq transitions
on workloads that bounce between CPU and GPU.
Signed-off-by: Rob Clark
---
From: Rob Clark
Before open-coding this a 2nd time, add a helper.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_atomic.c | 21 ++---
drivers/gpu/drm/msm/msm_drv.c| 29 +
drivers/gpu/drm/msm/msm_drv.h| 22 ++
drivers
On Mon, Sep 27, 2021 at 10:59:42AM -0700, Brian Norris wrote:
> 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
On Mon, Sep 27, 2021 at 09:43:44PM +0200, Maxime Ripard wrote:
> 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,
Hi Dave, Daniel,
New stuff for 5.16.
The following changes since commit 8f0284f190e6a0aa09015090568c03f18288231a:
Merge tag 'amd-drm-next-5.15-2021-08-27' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-08-30 09:06:03
+1000)
are available in the Git repository at:
https
Quoting Arnd Bergmann (2021-09-27 04:36:23)
> 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 expr
Hi Yunfei,
> This patch dependents on : "media: mtk-vcodec: support for MT8183 decoder"[1]
> and
> "Mediatek MT8192 clock support"[2].
>
> 1: Multi hardware decode is based on stateless decoder, MT8183 is the first
> time
> to add stateless decoder. Otherwise it will cause conflict. This patch w
Hi Ezequiel,
Thank you for reviewing these series from Yunfei!
This series is one of the main obstacles for us at the moment for MTK
so please continue to help & support reviewing this series.
> > According to google's suggestion, it's better not to use v4l2 async
> > also.
>
> Hum? I haven't see
> > [1]https://patchwork.linuxtv.org/project/linux-media/list/?series=5826
> This link seems to be no longer available.
It is probably because the default state is "Action Required", and
this series was accepted recently afterwards.
I can see the series with the below link.
https://patchwork.linu
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
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 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 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, 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
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
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
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
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
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
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 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
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
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
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!
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
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
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
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
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
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/
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)
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
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
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
> 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
> 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
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
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:
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
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/
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: H. Nikolaus Schaller
---
arch/mips/boot/dts/ingenic/jz4780.dtsi |
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
- 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...
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
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
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: 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.
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: 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.
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
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
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 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
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
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
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
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
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'
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),
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 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
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
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
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
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
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
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
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
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
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
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
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 *'
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
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
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
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
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
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, 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
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
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
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
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 -
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
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
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
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
1 - 100 of 121 matches
Mail list logo
