https://bugzilla.kernel.org/show_bug.cgi?id=208909
--- Comment #9 from ker...@890.at ---
Created attachment 292043
--> https://bugzilla.kernel.org/attachment.cgi?id=292043&action=edit
5.8.2 backtrace
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=208909
--- Comment #8 from ker...@890.at ---
just tried the 5.8.2 kernel same result, backtrace is attached
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mail
https://bugzilla.kernel.org/show_bug.cgi?id=208947
--- Comment #15 from Coleman Kane (ck...@colemankane.org) ---
Spoke too soon - that addition to the linux command line merely makes it work
intermittently. Sometimes I'll get the old behavior (max 1024x768), sometimes
I'll get the correct behavior
https://bugzilla.kernel.org/show_bug.cgi?id=208947
--- Comment #14 from Coleman Kane (ck...@colemankane.org) ---
So diving a bit further it looks like a contributor to this behavior might be
my misbehaving video hardware.
After some reading I did determine that I can add the following to my linux
Hi Linus,
Regular fixes pull for rc2. Usual rc2 doesn't seem too busy, mainly
i915 and amdgpu. I'd expect the usual uptick for rc3.
Dave.
drm-fixes-2020-08-21:
drm fixes for 5.9-rc2
amdgpu:
- Fix allocation size
- SR-IOV fixes
- Vega20 SMU feature state caching fix
- Fix custom pptable handling
[AMD Official Use Only - Internal Distribution Only]
Hi, Lukas,
Thanks for your fix. This issue was caused by that I modified these files
in windows system with Samba. I will take care in the future.
Best Regards
Dennis Li
-Original Message-
From: Lukas Bulwahn
Sent: Wednesday,
On 2020-08-20 21:16, Dmitry Osipenko wrote:
20.08.2020 18:08, Robin Murphy пишет:
Now that arch/arm is wired up for default domains and iommu-dma,
implement the corresponding driver-side support for DMA domains.
Signed-off-by: Robin Murphy
---
drivers/iommu/tegra-gart.c | 17
Hi Paul,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip linus/master v5.9-rc1 next-20200820]
[cannot apply to tegra-drm/drm/tegra/for-next drm/drm-next
drm-exynos/exynos-drm-next]
[If your patch is
On 2020-08-20 20:51, Dmitry Osipenko wrote:
20.08.2020 18:08, Robin Murphy пишет:
Now that arch/arm is wired up for default domains and iommu-dma, we no
longer need to work around the arch-private mapping.
Signed-off-by: Robin Murphy
---
drivers/staging/media/tegra-vde/iommu.c | 12 -
Hi, Yongqiang:
Yongqiang Niu 於 2020年8月20日 週四 下午2:18寫道：
>
> the shadow register for mt8192 ddp component is enable,
> we need disable it before enable ddp component
MT2701 has shadow register and use it. Why MT8192 have shadow register
but disable it? I would like to use shadow register like MT27
Hi, Yongqiang:
Yongqiang Niu 於 2020年8月20日 週四 下午2:18寫道：
>
> fix aal size config
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
>
Hi, Yongqiang:
Yongqiang Niu 於 2020年8月20日 週四 下午2:06寫道：
>
> It's possible that state->base.fb is null. Add a check before access its
> format.
Add a Fixes tag.
Regards,
Chun-Kuang.
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 2 +-
> 1 file changed, 1 ins
HI, Yongqiang:
Yongqiang Niu 於 2020年8月20日 週四 下午2:06寫道：
>
> enable OVL_LAYER_SMI_ID_EN for multi-layer usecase
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> b
Hi Kenneth,
> -Original Message-
> From: Kenneth Sloat
> Sent: Thursday, August 20, 2020 2:18 PM
> To: Hyun Kwon ; linux-arm-ker...@lists.infradead.org
> Cc: Michal Simek ; dri-devel@lists.freedesktop.org; linux-
> ker...@vger.kernel.org; laurent.pinch...@ideasonboard.com;
> devicet...@vg
Hi, Yongqiang:
Yongqiang Niu 於 2020年8月20日 週四 下午2:06寫道：
>
> there are 2 more clock need enable for display.
> parser these clock when mutex device probe,
> enable and disable when mutex on/off
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 49
> +++
Hi, Yongqiang:
Yongqiang Niu 於 2020年8月20日 週四 下午2:16寫道：
>
> add ovl mout on support
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/soc/mediatek/mmsys/mt8192-mmsys.c | 23 +++
> drivers/soc/mediatek/mtk-mmsys.c | 8
> include/linux/soc/mediatek/mtk-mmsys.h
Hi, Yongqiang:
Yongqiang Niu 於 2020年8月20日 週四 下午2:16寫道：
>
> add mt8192 mmsys support
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/soc/mediatek/mmsys/Makefile | 1 +
> drivers/soc/mediatek/mmsys/mt8192-mmsys.c | 159
> ++
> 2 files changed, 160 insertions(
Hi, Sam:
Sam Ravnborg 於 2020年8月20日 週四 上午12:04寫道：
>
> Hi Chun-Kuang
>
> Two small details below.
>
> Sam
>
> On Wed, Aug 19, 2020 at 11:44:20PM +0800, Chun-Kuang Hu wrote:
> > From: CK Hu
> >
> > mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
> > more suitable to pl
https://bugzilla.kernel.org/show_bug.cgi?id=208947
--- Comment #13 from Coleman Kane (ck...@colemankane.org) ---
Interestingly enough, the description of a problem attempting to be addressed
with this fix sounds similar to behavior I experience with this system:
Namely, the Radeon RX 580M connect
Hi, Randy:
Randy Dunlap 於 2020年8月20日 週四 上午12:00寫道：
>
> On 8/19/20 8:44 AM, Chun-Kuang Hu wrote:
> > diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
> > index dee757c957f2..10f0ec2d5b54 100644
> > --- a/drivers/phy/mediatek/Kconfig
> > +++ b/drivers/phy/mediatek/Kconfig
>
Hi, Randy:
Randy Dunlap 於 2020年8月19日 週三 下午11:58寫道：
>
> On 8/19/20 8:44 AM, Chun-Kuang Hu wrote:
> > diff --git a/drivers/gpu/drm/mediatek/Kconfig
> > b/drivers/gpu/drm/mediatek/Kconfig
> > index aa74aac3cbcc..ca3cd871a350 100644
> > --- a/drivers/gpu/drm/mediatek/Kconfig
> > +++ b/drivers/gpu/dr
Hi, Wang Hai:
Wang Hai 於 2020年8月19日 週三 上午11:00寫道：
>
> Remove mtk_drm_ddp.h which is included more than once
>
Reviewed-by: Chun-Kuang Hu
> Reported-by: Hulk Robot
> Signed-off-by: Wang Hai
> ---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a
https://bugzilla.kernel.org/show_bug.cgi?id=208947
--- Comment #12 from Coleman Kane (ck...@colemankane.org) ---
Ok I re-did the bisect and I think I found the actual commit that introduced
the regression. I have confirmed this by generating a reverse-patch and then
applying that to the latest sta
On 2020-08-20 20:55, Sakari Ailus wrote:
On Thu, Aug 20, 2020 at 06:25:19PM +0100, Robin Murphy wrote:
On 2020-08-20 17:53, Sakari Ailus wrote:
Hi Robin,
On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote:
Now that arch/arm is wired up for default domains and iommu-dma, devices
behi
On Wed, Aug 19, 2020 at 05:34:15PM -0400, Lyude Paul wrote:
> (adding Ville and Imre to the cc here, they might be interested to know about
> this, comments down below)
>
> On Wed, 2020-08-19 at 11:15 -0400, Sean Paul wrote:
> > On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote:
> > > We'
The TVE200 will occasionally print a bunch of lost interrupts
and similar dmesg messages, sometimes during boot and sometimes
after disabling and coming back to enablement. This is probably
because the hardware is left in an unknown state by the boot
loader that displays a logo.
This can be fixed
Hi Anitha.
Feedback on kmb_dsi.
The main feedback can be found after the kmb_dsi_init function.
The highligt of the feedback is that, in my opinion, the
best would be to use the drm_bridge abstraction for the kmb_dsi.
Maybe because I am biased - and this is just overhead.
But it just looks simple
On Thu, Aug 20, 2020 at 06:25:19PM +0100, Robin Murphy wrote:
> On 2020-08-20 17:53, Sakari Ailus wrote:
> > Hi Robin,
> >
> > On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote:
> > > Now that arch/arm is wired up for default domains and iommu-dma, devices
> > > behind IOMMUs will get m
https://bugzilla.kernel.org/show_bug.cgi?id=208981
--- Comment #3 from Florian La Roche (florian.laro...@gmail.com) ---
Created attachment 292039
--> https://bugzilla.kernel.org/attachment.cgi?id=292039&action=edit
dmesg output
Full dmesg output of the system.
--
You are receiving this mail b
https://bugzilla.kernel.org/show_bug.cgi?id=208981
--- Comment #2 from Florian La Roche (florian.laro...@gmail.com) ---
New system, so no regression for me. I'll try to check some older kernels
the next days and report back here.
Thanks a lot,
Florian La Roche
--
You are receiving this mail be
https://bugzilla.kernel.org/show_bug.cgi?id=208981
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugzilla.kernel.org/show_bug.cgi?id=208981
Bug ID: 208981
Summary: trace with B550I AORUS PRO AX and AMD Ryzen 5 PRO
4650G
Product: Drivers
Version: 2.5
Kernel Version: 5.8.2
Hardware: x86-64
OS:
And of course, we'll also need to read the sink count from other drivers
as well if we're checking whether or not it's supported. So, let's
extract the code for this into another helper.
v2:
* Fix drm_dp_dpcd_readb() ret check
* Add back comment and move back sink_count assignment in intel_dp_get_
This is another bit that we never implemented for nouveau: dongle
detection. When a "dongle", e.g. an active display adaptor, is hooked up
to the system and causes an HPD to be fired, we don't actually know
whether or not there's anything plugged into the dongle without checking
the sink count. As
Since other drivers are also going to need to be aware of the sink count
in order to do proper dongle detection, we might as well steal i915's
DP_SINK_COUNT helpers and move them into DRM helpers so that other
dirvers can use them as well.
Note that this also starts using intel_dp_has_sink_count()
Currently in nouveau_connector_ddc_detect() and
nouveau_connector_detect_lvds(), we start the connector probing process
by releasing the previous EDID and informing DRM of the change. However,
since commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector") drm_connector_update_edid_prop
Just a tiny drive-by cleanup, we can consolidate i915's code for
checking for MST support into a helper to be shared across drivers.
Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
---
drivers/gpu/drm/i915/display/intel_dp.c | 18 ++
include/drm/drm_dp_mst_helper.h | 22
Now that we've extracted i915's code for reading both the normal DPCD
caps and extended DPCD caps into a shared helper, let's start using this
in nouveau to enable us to start checking extended DPCD caps for free.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nou
Since DP 1.3, it's been possible for DP receivers to specify an
additional set of DPCD capabilities, which can take precedence over the
capabilities reported at DP_DPCD_REV.
Basically any device supporting DP is going to need to read these in an
identical manner, in particular nouveau, so let's go
Noticed this while going through our DP code - we use an open-coded
version of drm_dp_read_desc() instead of just using the helper, so
change that. This will also let us use quirks in the future if we end up
needing them.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nou
First some backstory here: Currently, we keep track of whether or not
we've enabled MST or not by trying to piggy-back off the MST helpers.
This means that in order to check whether MST is enabled or not, we
actually need to grab drm_dp_mst_topology_mgr.lock.
Back when I originally wrote this, I d
For whatever reason we currently unset the EDID for DP CEC support when
responding to the connector being unplugged, instead of just doing it in
nouveau_connector_detect() where we set the CEC EDID. This isn't really
needed and could even potentially cause us to forget to unset the EDID
if the conn
While the way we find the associated connector for an encoder is just
fine for legacy modesetting, it's not correct for nv50+ since that uses
atomic modesetting. For reference, see the drm_encoder kdocs.
Fix this by removing nouveau_encoder_connector_get(), and replacing it
with nv04_encoder_get_c
Just use drm_dp_dpcd_(readb|writeb)() so we get automatic DPCD logging
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers
Since this actually logs accesses, we should probably always be using
this imho…
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/dr
Since fa3cdf8d0b09 ("drm/nouveau: Reset MST branching unit before
enabling") we've been clearing DP_MST_CTRL before we start enabling MST.
Since then clearing DP_MST_CTRL in nv50_mstm_new() has been unnecessary
and redundant, so let's remove it.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
No functional changes.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8db9216d52c69..4030806
Currently we perform both short IRQ handling for DP, and connector
reprobing in the HPD IRQ handler. However since we need to grab
connection_mutex in order to reprobe a connector, in theory we could
accidentally block ourselves from handling any short IRQs until after a
modeset completes if a conn
We're going to be doing the same probing process in nouveau for
determining downstream DP port capabilities, so let's deduplicate the
work by moving i915's code for handling this into a shared helper:
drm_dp_downstream_read_info().
Note that when we do this, we also do make some functional changes
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8a0f7994e1aeb..ee778ddc95fae 100644
--- a/driv
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 032afc73e2a33..201c0b4335563 100644
To start off: this patch series is less work to review then it looks -
most (but not all) of the nouveau related work has already been reviewed
elsewhere. Most of the reason I'm asking for an RFC here is because this
code pulls a lot of code out of i915 and into shared DP helpers.
Anyway-nouveau's
This adds support for querying the maximum clock rate of a downstream
port on a DisplayPort connection. Generally, downstream ports refer to
active dongles which can have their own pixel clock limits.
Note as well, we also start marking the connector as disconnected if we
can't read the DPCD, sinc
Applied. Thanks!
Alex
On Thu, Aug 20, 2020 at 5:01 AM Christian König
wrote:
>
> Am 20.08.20 um 09:52 schrieb Furquan Shaikh:
> > In `amdgpu_dm_update_backlight_caps()`, there is a local
> > `amdgpu_dm_backlight_caps` object that is filled in by
> > `amdgpu_acpi_get_backlight_caps()`. However,
Applied. Thanks!
Alex
On Thu, Aug 20, 2020 at 1:59 PM Alex Dewar wrote:
>
> In init_powerplay_table_information() the value returned from kmalloc()
> is cast unnecessarily. Remove cast.
>
> Issue identified with Coccinelle.
>
> Signed-off-by: Alex Dewar
> ---
> drivers/gpu/drm/amd/pm/powerpla
Applied. Thanks!
Alex
On Wed, Aug 19, 2020 at 11:00 PM Quan, Evan wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
> Reviewed-by: Evan Quan
>
> -Original Message-
> From: Wang Hai
> Sent: Wednesday, August 19, 2020 7:34 PM
> To: Quan, Evan ; Deucher, Alexander
> ; Ko
Applied. Thanks!
Alex
On Wed, Aug 19, 2020 at 4:53 AM Christian König
wrote:
>
> Am 19.08.20 um 10:18 schrieb Lukas Bulwahn:
> > Besides the intended change, commit 4cc1178e166a ("drm/amdgpu: replace DRM
> > prefix with PCI device info for gfx/mmhub") also set the source files
> > mmhub_v1_0.c
On Thu, Aug 20, 2020 at 12:27:03PM +1000, Sam McNally wrote:
> > > [...]
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index 1ac874e4e7a1..73a2299c2faa 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/dr
Hi Anitha.
On Mon, Aug 10, 2020 at 02:53:38PM -0700, Anitha Chrisanthus wrote:
> This is a basic KMS atomic modesetting display driver for KeemBay family of
> SOCs. Driver has no 2D or 3D graphics.It calls into the ADV bridge
> driver at the connector level.
>
> Single CRTC with LCD controller->m
On 2020-08-20 17:53, Sakari Ailus wrote:
Hi Robin,
On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote:
Now that arch/arm is wired up for default domains and iommu-dma, devices
behind IOMMUs will get mappings set up automatically as appropriate, so
there is no need for drivers to do so
On Thu, 2020-08-20 at 10:46 +0200, Adam Miszczak wrote:
> Add DG1 and clean-up VLV PCI IDs.
>
> Align with kernel commits:
> f2bde2546b81 ("drm/i915: Remove dubious Valleyview PCI IDs")
> fd38cdb81105 ("drm/i915/dg1: Add DG1 PCI IDs")
>
Reviewed-by: José Roberto de Souza
But the current proces
On Thu, Aug 20, 2020 at 9:58 AM Robin Murphy wrote:
>
> On 2020-08-20 16:55, Rob Clark wrote:
> > Side note, I suspect we'll end up needing something like
> > 0e764a01015dfebff8a8ffd297d74663772e248a .. if someone can dig a 32b
> > device out of the closet and dust it off, the fix is easy enough.
Hi Robin,
On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote:
> Now that arch/arm is wired up for default domains and iommu-dma, devices
> behind IOMMUs will get mappings set up automatically as appropriate, so
> there is no need for drivers to do so manually.
>
> Signed-off-by: Robin M
On 2020-08-20 16:55, Rob Clark wrote:
Side note, I suspect we'll end up needing something like
0e764a01015dfebff8a8ffd297d74663772e248a .. if someone can dig a 32b
device out of the closet and dust it off, the fix is easy enough.
Just wanted to mention that here so anyone with a 32b device could
On Wed, 2020-08-19 at 11:29 -0400, Sean Paul wrote:
> On Tue, Aug 11, 2020 at 04:04:56PM -0400, Lyude Paul wrote:
> > Since DP 1.3, it's been possible for DP receivers to specify an
> > additional set of DPCD capabilities, which can take precedence over the
> > capabilities reported at DP_DPCD_REV.
On Wed, Aug 19, 2020 at 10:51:49PM +0200, Linus Walleij wrote:
> This adds device tree bindings for the Kinetic KTD253
> white LED backlight driver.
>
> Cc: devicet...@vger.kernel.org
> Cc: Sam Ravnborg
> Signed-off-by: Linus Walleij
Reviewed-by: Daniel Thompson
> ---
> ChangeLog v2->v3:
> -
On Wed, Aug 19, 2020 at 10:51:48PM +0200, Linus Walleij wrote:
> Let's use a common.yaml include for the backlight like we do with
> the LEDs. The LEDs are inherently incompatible so their bindings
> cannot be reused for backlight.
>
> Cc: devicet...@vger.kernel.org
> Suggested-by: Sam Ravnborg
>
On Wed, 2020-08-19 at 11:29 -0400, Sean Paul wrote:
> On Tue, Aug 11, 2020 at 04:04:56PM -0400, Lyude Paul wrote:
> > Since DP 1.3, it's been possible for DP receivers to specify an
> > additional set of DPCD capabilities, which can take precedence over the
> > capabilities reported at DP_DPCD_REV.
On Thu, Aug 06, 2020 at 08:19:32PM +0200, Krzysztof Kozlowski wrote:
> Hi All,
>
> Shortly
> ===
> This is a continuation of Arnd's work from 2019 [1]. The goal is to
> cleanup, merge and finally make the Samsung S3C24xx and S3C64xx
> architectures multiplatform. The multiplatform did not ha
Side note, I suspect we'll end up needing something like
0e764a01015dfebff8a8ffd297d74663772e248a .. if someone can dig a 32b
device out of the closet and dust it off, the fix is easy enough.
Just wanted to mention that here so anyone with a 32b device could
find what is needed.
BR,
-R
On Thu, Au
Hi Ezequiel,
On Thu, Aug 20, 2020 at 05:36:40AM -0300, Ezequiel Garcia wrote:
> Hi John,
>
> Thanks a ton for taking the time
> to go thru this.
>
> On Mon, 2020-08-17 at 21:13 -0700, John Stultz wrote:
> > On Sun, Aug 16, 2020 at 10:23 AM Ezequiel Garcia
> > wrote:
> > > This heap is basicall
On Thu, Aug 20, 2020 at 02:12:56PM +0200, Paul Cercueil wrote:
> There is already a 'struct device' pointer in the drm_panel structure,
> that we can access easily from our priv structure, so there's no need
> for a separate 'dev' field there.
>
> v2: Don't initialize drm_panel->dev manually, it i
On Thu, Aug 20, 2020 at 02:12:55PM +0200, Paul Cercueil wrote:
> The drm_panel_of_backlight() function must be called after
> drm_panel_init(), according to the function's documentation; otherwise
> the backlight won't be properly initialized.
>
> v2: New patch
>
> Signed-off-by: Paul Cercueil
R
Hi Mauro.
Quick feedback below.
Sam
On Thu, Aug 20, 2020 at 05:13:22PM +0200, Mauro Carvalho Chehab wrote:
> Em Thu, 20 Aug 2020 16:48:08 +0200
> Sam Ravnborg escreveu:
>
> > Hi Mauro.
> >
> > On Thu, Aug 20, 2020 at 04:06:49PM +0200, Mauro Carvalho Chehab wrote:
> > > Em Wed, 19 Aug
Please ignore this one, it's to hot here and I'm typing to fast :)
Christian.
Am 20.08.20 um 17:24 schrieb Christian König:
drm-next reverted the changes to ttm_tt_create() to do the
NULL check inside the function, but drm-misc-next adds new
users of this approach.
Re-apply the NULL check chan
From: Christian König
While working on TTM cleanups I've found that the io_reserve_lru used by
Nouveau is actually not working at all.
In general we should remove driver specific handling from the memory
management, so this patch moves the io_reserve_lru handling into Nouveau
instead.
The patch
drm-next reverted the changes to ttm_tt_create() to do the
NULL check inside the function, but drm-misc-next adds new
users of this approach.
Re-apply the NULL check change inside the function to fix this.
Signed-off-by: Christian König
Reviewed-by: Dave Airlie
Link: https://patchwork.freedeskt
Hi guys,
I already tried this a few month ago, but since I don't have NVidia hardware
its rather hard to test for me (need to get some ordered).
Dave brought up the topic that we should probably try to move the handling into
Nouveau once more, so I tried to fix the problem Ben reported and reba
Em Thu, 20 Aug 2020 16:48:08 +0200
Sam Ravnborg escreveu:
> Hi Mauro.
>
> On Thu, Aug 20, 2020 at 04:06:49PM +0200, Mauro Carvalho Chehab wrote:
> > Em Wed, 19 Aug 2020 19:35:58 +0200
> > Sam Ravnborg escreveu:
> >
> > I'm already handling the other comments from your review (I'll send a
> > m
Now that arch/arm is wired up for default domains and iommu-dma, remove
the add_device workaround.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
b/drivers/iommu/arm/arm-s
Now that arch/arm is wired up for default domains and iommu-dma,
implement the corresponding driver-side support for DMA domains.
Signed-off-by: Robin Murphy
---
drivers/iommu/msm_iommu.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/msm_iommu.c b/driver
Now that arch/arm is wired up for default domains and iommu-dma, we can
consolidate the shared mapping code onto the generic IOMMU API version,
and retire the arch-specific implementation.
Signed-off-by: Robin Murphy
---
This is a cheeky revert of 07dc3678bacc ("drm/exynos: Fix cleanup of
IOMMU
Now that arch/arm is wired up for default domains and iommu-dma, devices
behind IOMMUs will get mappings set up automatically as appropriate, so
there is no need for drivers to do so manually.
Signed-off-by: Robin Murphy
---
drivers/media/platform/omap3isp/isp.c | 68 ++-
With no users left and generic iommu-dma now doing all the work,
clean up the last traces of the arch-specific API, plus the temporary
workarounds that you'd forgotten about because you were thinking about
zebras instead.
Signed-off-by: Robin Murphy
---
arch/arm/common/dmabounce.c | 1 -
Now that arch/arm is wired up for default domains and iommu-dma,
implement the corresponding driver-side support for DMA domains.
Signed-off-by: Robin Murphy
---
drivers/iommu/omap-iommu.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/om
Now that arch/arm is wired up for default domains and iommu-dma,
implement the corresponding driver-side support for DMA domains.
Signed-off-by: Robin Murphy
---
drivers/iommu/tegra-gart.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/tegra-
Now that iommu-dma is wired up, we can let it work as normal
without the dma_iommu_mapping hacks if the IOMMU driver already
supports default domains.
Signed-off-by: Robin Murphy
---
arch/arm/mm/dma-mapping.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/
Now that arch/arm is wired up for default domains and iommu-dma,
implement the corresponding driver-side support for groups and DMA
domains to replace the shared mapping workaround.
Signed-off-by: Robin Murphy
---
drivers/iommu/mtk_iommu.h| 2 -
drivers/iommu/mtk_iommu_v1.c | 153 +
Now that arch/arm is wired up for default domains and iommu-dma, we no
longer need to work around the arch-private mapping.
Signed-off-by: Robin Murphy
---
drivers/staging/media/tegra-vde/iommu.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/staging/media/tegra-vde/iom
Now that arch/arm is wired up for default domains and iommu-dma, we no
longer need to work around the arch-private mapping.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau
Now that arch/arm is wired up for default domains and iommu-dma, remove
the shared mapping workaround and rely on groups there as well.
Signed-off-by: Robin Murphy
---
drivers/iommu/ipmmu-vmsa.c | 69 --
1 file changed, 69 deletions(-)
diff --git a/drivers/io
Now that arch/arm is wired up for default domains and iommu-dma,
implement the corresponding driver-side support for DMA domains.
Signed-off-by: Robin Murphy
---
drivers/iommu/tegra-smmu.c | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a
With the IOMMU ops now looking much the same shape as iommu_dma_ops,
switch them out in favour of the iommu-dma library, currently enhanced
with temporary workarounds that allow it to also sit underneath the
arch-specific API. With that in place, we can now start converting the
remaining IOMMU driv
In order to wrangle arch/arm over to iommu_dma_ops, we first need to
convert all its associated IOMMU drivers over to default domains, and
deal with users of its public dma_iommu_mappinng API. Since that can't
reasonably be done in a single patch, we've no choice but to go through
an ugly transitio
The dma_sync_* operations are now the only difference between the
coherent and non-coherent IOMMU ops. Some minor tweaks to make those
safe for coherent devices with minimal overhead, and we can condense
down to a single set of DMA ops.
Signed-off-by: Robin Murphy
---
arch/arm/mm/dma-mapping.c |
Merge the coherent and non-coherent callbacks down to a single
implementation each, relying on the generic dev->dma_coherent
flag at the points where the difference matters.
Signed-off-by: Robin Murphy
---
arch/arm/Kconfig | 4 +-
arch/arm/mm/dma-mapping.c | 281 +++---
When an IOMMU is present, we trust that it should be capable
of remapping any physical memory, and since the device masks
represent the input (virtual) addresses to the IOMMU it makes
no sense to validate them against physical PFNs anyway.
Signed-off-by: Robin Murphy
---
arch/arm/mm/dma-mapping.
Hi all,
After 5 years or so of intending to get round to this, finally the
time comes! The changes themselves actualy turn out to be relatively
mechanical; the bigger concern appears to be how to get everything
merged across about 5 diffferent trees given the dependencies.
I've lightly boot-teste
Hi Mauro.
On Thu, Aug 20, 2020 at 04:06:49PM +0200, Mauro Carvalho Chehab wrote:
> Em Wed, 19 Aug 2020 19:35:58 +0200
> Sam Ravnborg escreveu:
>
> I'm already handling the other comments from your review (I'll send a
> more complete comment about them after finishing),
If you get back only on th
Em Wed, 19 Aug 2020 19:35:58 +0200
Sam Ravnborg escreveu:
I'm already handling the other comments from your review (I'll send a
more complete comment about them after finishing), but I have a doubt
what you meant about this:
> +static int kirin_drm_bind(struct device *dev)
> > +{
> > + struct
1 - 100 of 207 matches
Mail list logo
