[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=51381 --- Comment #56 from Luca T. (luca.trom...@gmail.com) --- (In reply to Alex Deucher from comment #32) > Created attachment 138641 [details] > testing patch > > Does this patch help? Note, this will probably break regular > suspend/resume, so just test it for switcheroo. Hello Alex, this bug is still present also in kernel 5.12.1, can you please help me to understand how to fix this issue? Thanks in advance, Luca -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 1/1] drm/nouveau: fix error return code in nouveau_backlight_init()
Hello Zhen,
There was a similar patch sent in last month, though which does not seem to
have been merged yet; see
https://lists.freedesktop.org/archives/nouveau/2021-April/038451.html.
Whether `ret` should be `-ENOSPC` or `-ENOMEM` is hard to say as
`nouveau_get_backlight_name()` could fail due to either.
I will propose an alternative fix which modifies `nouveau_get_backlight_name()`
to return an int so the actual error code can be propagated back instead of
guessed, as well as fix an ida ID leak which I just spotted.
Best,
Pierre
On 2021-05-08 — 11:48, Zhen Lei wrote:
> Fix to return a negative error code from the error handling case instead
> of 0, as done elsewhere in this function.
>
> Fixes: db1a0ae21461 ("drm/nouveau/bl: Assign different names to interfaces")
> Reported-by: Hulk Robot
> Signed-off-by: Zhen Lei
> ---
> drivers/gpu/drm/nouveau/nouveau_backlight.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index 72f35a2babcb..097ca344a086 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -273,6 +273,7 @@ nouveau_backlight_init(struct drm_connector *connector)
> return -ENOMEM;
>
> if (!nouveau_get_backlight_name(backlight_name, bl)) {
> + ret = -ENOSPC;
> NV_ERROR(drm, "Failed to retrieve a unique name for the
> backlight interface\n");
> goto fail_alloc;
> }
> --
> 2.25.1
>
>
[PATCH] component: Move host device to end of device lists on binding
The device lists are poorly ordered when the component device code is
used. This is because component_master_add_with_match() returns 0
regardless of component devices calling component_add() first. It can
really only fail if an allocation fails, in which case everything is
going bad and we're out of memory. The host device (called master_dev in
the code), can succeed at probe and be put on the device lists before
any of the component devices are probed and put on the lists.
Within the component device framework this usually isn't that bad
because the real driver work is done at bind time via
component{,master}_ops::bind(). It becomes a problem when the driver
core, or host driver, wants to operate on the component device outside
of the bind/unbind functions, e.g. via 'remove' or 'shutdown'. The
driver core doesn't understand the relationship between the host device
and the component devices and could possibly try to operate on component
devices when they're already removed from the system or shut down.
Normally, device links or probe defer would reorder the lists and put
devices that depend on other devices in the lists at the correct
location, but with component devices this doesn't happen because this
information isn't expressed anywhere. Drivers simply succeed at
registering their component or host with the component framework and
wait for their bind() callback to be called once the other components
are ready. We could make various device links between 'master_dev' and
'component->dev' but it's not necessary. Let's simply move the hosting
device to the end of the device lists when the component device fully
binds. This way we know that all components are present and have probed
properly and now the host device has really probed so it's safe to
assume the host driver ops can operate on any component device.
This fixes the msm display driver shutdown path when the DSI controller
is connected to a DSI bridge that is controlled via i2c. In this case,
the msm display driver wants to tear down the display pipeline on
shutdown at msm_pdev_shutdown() by calling drm_atomic_helper_shutdown(),
and it can't do that unless the whole display chain is still probed and
active in the system. When a display bridge is on i2c, the i2c device
for the bridge will be created whenever the i2c controller probes, which
could be before or after the msm display driver probes. If the i2c
controller probes after the display driver, then the i2c controller will
be shutdown before the display controller during system wide shutdown
and thus i2c transactions will stop working before the display pipeline
is shut down. This means we'll have the display bridge trying to access
an i2c bus that's shut down because drm_atomic_helper_shutdown() is
trying to disable the bridge after the bridge is off.
Moving the host device to the end of the lists at bind time moves the
drm_atomic_helper_shutdown() call before the i2c bus is shutdown.
This fixes the immediate problem, but we could improve it a bit by
modeling device links from the component devices to the host device
indicating that they supply something, although it is slightly different
because the consumer doesn't need the suppliers to probe to succeed.
Cc: "Rafael J. Wysocki"
Cc: Daniel Vetter
Cc: Russell King
Cc: Rob Clark
Cc:
Signed-off-by: Stephen Boyd
---
drivers/base/component.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index dcfbe7251dc4..de645420bae2 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -15,6 +15,8 @@
#include
#include
+#include "base.h"
+
/**
* DOC: overview
*
@@ -657,6 +659,14 @@ int component_bind_all(struct device *master_dev, void
*data)
c = master->match->compare[i - 1].component;
component_unbind(c, master, data);
}
+ } else {
+ /*
+* Move to the tail of the list so that master_dev driver ops
+* like 'shutdown' or 'remove' are called before any of the
+* dependencies that the components have are shutdown or
+* removed.
+*/
+ device_pm_move_to_tail(master_dev);
}
return ret;
base-commit: 9f4ad9e425a1d3b6a34617b8ea226d56a119a717
--
https://chromeos.dev
Re: [PATCH 1/1] drm/msm/dpu: Fix error return code in dpu_mdss_init()
On 2021/5/8 14:09, Stephen Boyd wrote:
> Quoting Zhen Lei (2021-05-07 19:42:54)
>> Fix to return a negative error code from the error handling case instead
>> of 0, as done elsewhere in this function.
>>
>> Fixes: 070e64dc1bbc ("drm/msm/dpu: Convert to a chained irq chip")
>> Reported-by: Hulk Robot
>> Signed-off-by: Zhen Lei
>> ---
>> drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
>> index 06b56fec04e0..1b6c9fb500a1 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
>> @@ -253,8 +253,10 @@ int dpu_mdss_init(struct drm_device *dev)
>> goto irq_domain_error;
>>
>> irq = platform_get_irq(pdev, 0);
>> - if (irq < 0)
>> + if (irq < 0) {
>> + ret = irq;
>> goto irq_error;
>> + }
>
> It would be even better if ret wasn't assigned to 0 at the start of this
> function.
The returned error code is not unique.
>
>>
>> irq_set_chained_handler_and_data(irq, dpu_mdss_irq,
>> dpu_mdss);
>
> .
>
Re: [PATCH 1/1] drm/msm/dpu: Fix error return code in dpu_mdss_init()
Quoting Leizhen (ThunderTown) (2021-05-08 00:55:04)
>
>
> On 2021/5/8 14:09, Stephen Boyd wrote:
> > Quoting Zhen Lei (2021-05-07 19:42:54)
> >> Fix to return a negative error code from the error handling case instead
> >> of 0, as done elsewhere in this function.
> >>
> >> Fixes: 070e64dc1bbc ("drm/msm/dpu: Convert to a chained irq chip")
> >> Reported-by: Hulk Robot
> >> Signed-off-by: Zhen Lei
> >> ---
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 4 +++-
> >> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> >> index 06b56fec04e0..1b6c9fb500a1 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> >> @@ -253,8 +253,10 @@ int dpu_mdss_init(struct drm_device *dev)
> >> goto irq_domain_error;
> >>
> >> irq = platform_get_irq(pdev, 0);
> >> - if (irq < 0)
> >> + if (irq < 0) {
> >> + ret = irq;
> >> goto irq_error;
> >> + }
> >
> > It would be even better if ret wasn't assigned to 0 at the start of this
> > function.
>
> The returned error code is not unique.
>
What does it mean? I was saying this
8<
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
index cd4078807db1..0fcf190f6322 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
@@ -263,7 +263,7 @@ int dpu_mdss_init(struct drm_device *dev)
struct msm_drm_private *priv = dev->dev_private;
struct dpu_mdss *dpu_mdss;
struct dss_module_power *mp;
- int ret = 0;
+ int ret;
int irq;
dpu_mdss = devm_kzalloc(dev->dev, sizeof(*dpu_mdss), GFP_KERNEL);
@@ -297,8 +297,10 @@ int dpu_mdss_init(struct drm_device *dev)
goto irq_domain_error;
irq = platform_get_irq(pdev, 0);
- if (irq < 0)
+ if (irq < 0) {
+ ret = irq;
goto irq_error;
+ }
irq_set_chained_handler_and_data(irq, dpu_mdss_irq,
dpu_mdss);
@@ -309,7 +311,7 @@ int dpu_mdss_init(struct drm_device *dev)
dpu_mdss_icc_request_bw(priv->mdss);
- return ret;
+ return 0;
irq_error:
_dpu_mdss_irq_domain_fini(dpu_mdss);
Re: [PATCH 1/1] drm/msm/dpu: Fix error return code in dpu_mdss_init()
On 2021/5/8 15:58, Stephen Boyd wrote:
> Quoting Leizhen (ThunderTown) (2021-05-08 00:55:04)
>>
>>
>> On 2021/5/8 14:09, Stephen Boyd wrote:
>>> Quoting Zhen Lei (2021-05-07 19:42:54)
Fix to return a negative error code from the error handling case instead
of 0, as done elsewhere in this function.
Fixes: 070e64dc1bbc ("drm/msm/dpu: Convert to a chained irq chip")
Reported-by: Hulk Robot
Signed-off-by: Zhen Lei
---
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
index 06b56fec04e0..1b6c9fb500a1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
@@ -253,8 +253,10 @@ int dpu_mdss_init(struct drm_device *dev)
goto irq_domain_error;
irq = platform_get_irq(pdev, 0);
- if (irq < 0)
+ if (irq < 0) {
+ ret = irq;
goto irq_error;
+ }
>>>
>>> It would be even better if ret wasn't assigned to 0 at the start of this
>>> function.
>>
>> The returned error code is not unique.
>>
>
> What does it mean? I was saying this
Sorry, I misunderstood. I think your opinion is good.
>
> 8<
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> index cd4078807db1..0fcf190f6322 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> @@ -263,7 +263,7 @@ int dpu_mdss_init(struct drm_device *dev)
> struct msm_drm_private *priv = dev->dev_private;
> struct dpu_mdss *dpu_mdss;
> struct dss_module_power *mp;
> - int ret = 0;
> + int ret;
> int irq;
>
> dpu_mdss = devm_kzalloc(dev->dev, sizeof(*dpu_mdss), GFP_KERNEL);
> @@ -297,8 +297,10 @@ int dpu_mdss_init(struct drm_device *dev)
> goto irq_domain_error;
>
> irq = platform_get_irq(pdev, 0);
> - if (irq < 0)
> + if (irq < 0) {
> + ret = irq;
> goto irq_error;
> + }
>
> irq_set_chained_handler_and_data(irq, dpu_mdss_irq,
>dpu_mdss);
> @@ -309,7 +311,7 @@ int dpu_mdss_init(struct drm_device *dev)
>
> dpu_mdss_icc_request_bw(priv->mdss);
>
> - return ret;
> + return 0;
>
> irq_error:
> _dpu_mdss_irq_domain_fini(dpu_mdss);
>
> .
>
Re: [PATCH 1/1] drm/nouveau: fix error return code in nouveau_backlight_init()
On 2021/5/8 15:34, Pierre Moreau wrote:
> Hello Zhen,
>
> There was a similar patch sent in last month, though which does not seem to
> have been merged yet; see
> https://lists.freedesktop.org/archives/nouveau/2021-April/038451.html.
>
> Whether `ret` should be `-ENOSPC` or `-ENOMEM` is hard to say as
> `nouveau_get_backlight_name()` could fail due to either.
>
> I will propose an alternative fix which modifies
> `nouveau_get_backlight_name()`
> to return an int so the actual error code can be propagated back instead of
> guessed, as well as fix an ida ID leak which I just spotted.
It's a good idea.
>
> Best,
> Pierre
>
> On 2021-05-08 — 11:48, Zhen Lei wrote:
>> Fix to return a negative error code from the error handling case instead
>> of 0, as done elsewhere in this function.
>>
>> Fixes: db1a0ae21461 ("drm/nouveau/bl: Assign different names to interfaces")
>> Reported-by: Hulk Robot
>> Signed-off-by: Zhen Lei
>> ---
>> drivers/gpu/drm/nouveau/nouveau_backlight.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> index 72f35a2babcb..097ca344a086 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
>> @@ -273,6 +273,7 @@ nouveau_backlight_init(struct drm_connector *connector)
>> return -ENOMEM;
>>
>> if (!nouveau_get_backlight_name(backlight_name, bl)) {
>> +ret = -ENOSPC;
>> NV_ERROR(drm, "Failed to retrieve a unique name for the
>> backlight interface\n");
>> goto fail_alloc;
>> }
>> --
>> 2.25.1
>>
>>
>
> .
>
Re: [PATCH] drm/radeon/ttm: Fix memory leak userptr pages
Hi guys, On Wed, 7 Apr 2021 at 11:27, Christian König wrote: > Am 07.04.21 um 09:47 schrieb Daniel Gomez: > > On Tue, 6 Apr 2021 at 22:56, Alex Deucher wrote: > >> On Mon, Mar 22, 2021 at 6:34 AM Christian König > >> wrote: > >>> Hi Daniel, > >>> > >>> Am 22.03.21 um 10:38 schrieb Daniel Gomez: > On Fri, 19 Mar 2021 at 21:29, Felix Kuehling > wrote: > > This caused a regression in kfdtest in a large-buffer stress test > after > > memory allocation for user pages fails: > I'm sorry to hear that. BTW, I guess you meant amdgpu leak patch and > not this one. > Just some background for the mem leak patch if helps to understand > this: > The leak was introduce here: > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Fcommit%2F%3Fid%3D0b988ca1c7c4c73983b4ea96ef7c2af2263c87eb&data=04%7C01%7CChristian.Koenig%40amd.com%7C65d21b6f02da409ac7b508d8f9997367%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533784761980218%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FeOQf12NBkC3YGZ7QW66%2FT%2FpyM3DjEb9IMbqUvISMfo%3D&reserved=0 > where the bound status was introduced for all drm drivers including > radeon and amdgpu. So this patch just reverts the logic to the > original code but keeping the bound status. In my case, the binding > code allocates the user pages memory and returns without bounding (at > amdgpu_gtt_mgr_has_gart_addr). So, > when the unbinding happens, the memory needs to be cleared to prevent > the leak. > >>> Ah, now I understand what's happening here. Daniel your patch is not > >>> really correct. > >>> > >>> The problem is rather that we don't set the tt object to bound if it > >>> doesn't have a GTT address. > >>> > >>> Going to provide a patch for this. > >> Did this patch ever land? > > I don't think so but I might send a v2 following Christian's comment > > if you guys agree. > > Somebody else already provided a patch which I reviewed, but I'm not > sure if that landed either. > > > Also, the patch here is for radeon but the pagefault issue reported by > > Felix is affected by the amdgpu one: > > > > radeon patch: drm/radeon/ttm: Fix memory leak userptr pages > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fproject%2Fdri-devel%2Fpatch%2F20210318083236.43578-1-daniel%40qtec.com%2F&data=04%7C01%7CChristian.Koenig%40amd.com%7C65d21b6f02da409ac7b508d8f9997367%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533784761980218%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HSMK%2FqYz%2Bzz9qbKc%2FITUWluBDeaW9YrgyH8p0L640%2F0%3D&reserved=0 > > > > amdgpu patch: drm/amdgpu/ttm: Fix memory leak userptr pages > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fproject%2Fdri-devel%2Fpatch%2F20210317160840.36019-1-daniel%40qtec.com%2F&data=04%7C01%7CChristian.Koenig%40amd.com%7C65d21b6f02da409ac7b508d8f9997367%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637533784761980218%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UsUZ4YjCSjHmzlPB07oTaGrsntTrQSwlGk%2BxUjwDiag%3D&reserved=0 > > > > I assume both need to be fixed with the same approach. > > Yes correct. Let me double check where that fix went. This patch (actually, the memory leak fix for amdgpu not radeon) has landed in mainline and has been back-ported to the stable branches. I just want to verify with you if that’s okay and the NULL pointer issue reported by Felix is fixed by this other patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c?id=3c3dc654333f6389803cdcaf03912e94173ae510 Thanks, Daniel > > > Thanks, > Christian. > > > > > Daniel > >> Alex > >> > >>> Regards, > >>> Christian. > >>> > > [17359.536303] amdgpu: init_user_pages: Failed to get user pages: -16 > > [17359.543746] BUG: kernel NULL pointer dereference, address: > > > [17359.551494] #PF: supervisor read access in kernel mode > > [17359.557375] #PF: error_code(0x) - not-present page > > [17359.563247] PGD 0 P4D 0 > > [17359.566514] Oops: [#1] SMP PTI > > [17359.570728] CPU: 8 PID: 5944 Comm: kfdtest Not tainted > 5.11.0-kfd-fkuehlin #193 > > [17359.578760] Hardware name: ASUS All Series/X99-E WS/USB 3.1, BIOS > 3201 06/17/2016 > > [17359.586971] RIP: 0010:amdgpu_ttm_backend_unbind+0x52/0x110 > [amdgpu] > > [17359.594075] Code: 48 39 c6 74 1b 8b 53 0c 48 8d bd 80 a1 ff ff e8 > 24 62 00 00 85 c0 0f 85 ab 00 00 00 c6 43 54 00 5b 5d c3 48 8b 46 10 8b 4e > 50 <48> 8b 30 48 85 f6 74 ba 8b 50 0c 48 8b bf 80 a1 ff ff 83 e1 01 45 > > [17359.614340] RSP: 0018:a4764971fc98 EFLAGS: 00010206 > > [17359.620315] RAX: RBX:
[PATCH 1/1] drm/kmb: Remove several unneeded semicolons
The semicolon immediately following '}' is unneeded.
Signed-off-by: Zhen Lei
---
drivers/gpu/drm/kmb/kmb_dsi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/kmb/kmb_dsi.c b/drivers/gpu/drm/kmb/kmb_dsi.c
index 4b5d82af84b3014..231041b269f5395 100644
--- a/drivers/gpu/drm/kmb/kmb_dsi.c
+++ b/drivers/gpu/drm/kmb/kmb_dsi.c
@@ -281,7 +281,7 @@ static u32 mipi_get_datatype_params(u32 data_type, u32
data_mode,
default:
DRM_ERROR("DSI: Invalid data_mode %d\n", data_mode);
return -EINVAL;
- };
+ }
break;
case DSI_LP_DT_PPS_YCBCR422_16B:
data_type_param.size_constraint_pixels = 2;
@@ -301,7 +301,7 @@ static u32 mipi_get_datatype_params(u32 data_type, u32
data_mode,
default:
DRM_ERROR("DSI: Invalid data_mode %d\n", data_mode);
return -EINVAL;
- };
+ }
break;
case DSI_LP_DT_LPPS_YCBCR422_20B:
case DSI_LP_DT_PPS_YCBCR422_24B:
@@ -318,7 +318,7 @@ static u32 mipi_get_datatype_params(u32 data_type, u32
data_mode,
default:
DRM_ERROR("DSI: Invalid data_mode %d\n", data_mode);
return -EINVAL;
- };
+ }
break;
case DSI_LP_DT_PPS_RGB565_16B:
data_type_param.size_constraint_pixels = 1;
@@ -337,7 +337,7 @@ static u32 mipi_get_datatype_params(u32 data_type, u32
data_mode,
default:
DRM_ERROR("DSI: Invalid data_mode %d\n", data_mode);
return -EINVAL;
- };
+ }
break;
case DSI_LP_DT_PPS_RGB666_18B:
data_type_param.size_constraint_pixels = 4;
@@ -361,7 +361,7 @@ static u32 mipi_get_datatype_params(u32 data_type, u32
data_mode,
default:
DRM_ERROR("DSI: Invalid data_type %d\n", data_type);
return -EINVAL;
- };
+ }
*params = data_type_param;
return 0;
--
2.26.0.106.g9fadedd
[PATCH] drm: panel-orientation-quirks: Make the Lenovo Ideapad D330 quirk also match the 81MD version
The Lenovo Ideapad D330 has 2 versions, one with a DMI_PRODUCT_NAME of
"81H3" and one with "81MD". Testing has shown that the "81MD" also has
a 90 degree mounted panel with a resolution of 1200x1920.
Drop the DMI_PRODUCT_NAME from the existing quirk so that the existing
quirk matches both versions.
Link: https://github.com/systemd/systemd/pull/18884
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 58f5dc2f6dd5..3fadf4aade3a 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -207,7 +207,6 @@ static const struct dmi_system_id orientation_data[] = {
}, {/* Lenovo Ideapad D330 */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
- DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "81H3"),
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad
D330-10IGM"),
},
.driver_data = (void *)&lcd1200x1920_rightside_up,
--
2.31.1
Re: Radeon NI: GIT kernel with the nislands_smc commit doesn't boot on a Freescale P5040 board and P.A.Semi Nemo board
Hi Gustavo, Your patch works! Thanks a lot! I tested it with my Freescale P5040 board and P.A.Semi Nemo board with a connected AMD Radeon HD6970 NI graphics cards (Cayman XT) today. Have a nice day, Christian On 07 May 2021 at 08:43am, Christian Zigotzky wrote: Hi Gustavo, Great! I will test it. Many thanks for your help. Cheers, Christian On 7. May 2021, at 01:55, Gustavo A. R. Silva wrote: Hi Christian, On 4/30/21 06:59, Christian Zigotzky wrote: Hello, The Nemo board (A-EON AmigaOne X1000) [1] and the FSL P5040 Cyrus+ board (A-EON AmigaOne X5000) [2] with installed AMD Radeon HD6970 NI graphics cards (Cayman XT) [3] don't boot with the latest git kernel anymore after the commit "drm/radeon/nislands_smc.h: Replace one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE branch" [4]. This git kernel boots in a virtual e5500 QEMU machine with a VirtIO-GPU [5]. I bisected today [6]. Result: drm/radeon/nislands_smc.h: Replace one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE branch (434fb1e7444a2efc3a4ebd950c7f771ebfcffa31) [4] is the first bad commit. I have a fix ready for this bug: https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?h=testing/drm-nislands I wonder if you could help me to test it with your environment, please. It should be applied on top of mainline. Thank you! -- Gustavo I was able to revert this commit [7] and after a new compiling, the kernel boots without any problems on my AmigaOnes. After that I created a patch for reverting this commit for new git test kernels. [3] The kernel compiles and boots with this patch on my AmigaOnes. Please find attached the kernel config files. Please check the first bad commit. Thanks, Christian [1] https://en.wikipedia.org/wiki/AmigaOne_X1000 [2] http://wiki.amiga.org/index.php?title=X5000 [3] https://forum.hyperion-entertainment.com/viewtopic.php?f=35&t=4377 [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=434fb1e7444a2efc3a4ebd950c7f771ebfcffa31 [5] qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci -device usb-tablet -device virtio-keyboard-pci -smp 4 -vnc :1 [6] https://forum.hyperion-entertainment.com/viewtopic.php?p=53074#p53074 [7] git revert 434fb1e7444a2efc3a4ebd950c7f771ebfcffa3
[Bug 212957] [radeon] kernel NULL pointer dereference during system boot
https://bugzilla.kernel.org/show_bug.cgi?id=212957 Arvin (arvin.ke...@gmail.com) changed: What|Removed |Added CC||arvin.ke...@gmail.com --- Comment #2 from Arvin (arvin.ke...@gmail.com) --- I can confirm I have a similar issue on a laptop with AMD dual GPU (6520G + HD 6750M). The system boots to a graphical desktop (MATE + LightDM) and works fine until I open a program with the discrete graphics (DRI_PRIME=1). Going to bisect once I get the laptop later in the day. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PULL] topic/iomem-mmap-vs-gup
[ Daniel, please fix your broken email setup. You have this insane "Reply-to" list that just duplicates all the participants. Very broken, very annoying ] On Fri, May 7, 2021 at 8:53 AM Daniel Vetter wrote: > > So personally I think the entire thing should just be thrown out, it's all > levels of scary and we have zero-copy buffer sharing done properly with > dma-buf since years in v4l. So I've been looking at this more, and the more I look at it, the less I like this series. I think the proper fix is to just fix things. For example, I'm looking at the v4l users of follow_pfn(), and I find get_vaddr_frames(), which is just broken. Fine, we know users are broken, but look at what appears to be the main user of get_vaddr_frames(): vb2_dc_get_userptr(). What does that function do? Immediately after doing get_vaddr_frames(), it tries to turn those pfn's into page pointers, and then do sg_alloc_table_from_pages() on the end result. Yes, yes, it also has that "ok, that failed, let's try to see if it's some physically contiguous mapping" and do DMA directly to those physical pages, but the point there is that that only happens when they weren't normal pages to begin with. So thew *fix* for at least that path is to (a) just use the regular pin_user_pages() for normal pages (b) perhaps keep the follow_pfn() case, but then limit it to that "no page backing" and that physical pages case. And honestly, the "struct frame_vector" thing already *has* support for this, and the problem is simply that the v4l code has decided to have the callers ask for pfn's rather than have the callers just ask for a frame-vector that is either "pfn's with no paeg backing" _or_ "page list with proper page reference counting". So this series of yours that just disables follow_pfn() actually seems very wrong. I think follow_pfn() is ok for the actual "this is not a 'struct page' backed area", and disabling that case is wrong even going forward. End result, I think the proper model is: - keep follow_pfn(), but limit it to the "not vm_normal_page()" case, and return error for some real page mapping - make the get_vaddr_frames() first try "pin_user_pages()" (and create a page array) and fall back to "follow_pfn()" if that fails (or the other way around). Set the IOW, get_vaddr_frames() would just do vec->got_ref = is_pages; vec->is_pfns = !is_pages; and everything would just work out - the v4l code seems to already have all the support for "it's a ofn array" vs "it's properly refcounted pages". So the only case we should disallow is the mixed case, that the v4l code already seems to not be able to handle anyway (and honestly, it looks like "got_ref/is_pfns" should be just one flag - they always have to have the opposite values). So I think this "unsafe_follow_pfn()" halfway step is actively wrong. It doesn't move us forward. Quite the reverse. It just makes the proper fix harder. End result: not pulling it, unless somebody can explain to me in small words why I'm wrong and have the mental capacity of a damaged rodent. Linus
[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=51381 --- Comment #57 from luminoso (lumin...@gmail.com) --- For users still facing this issue, I workaround it with this: https://github.com/aelveborn/vgaswitcheroo-systemd Basically before suspending it restores the GPU powerstate and resumes it once coming from a suspend state. Never had problems again. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: New warnings with gcc-11
I have heard nothing about this, and it remains the only warning from
my allmodconfig build (I have another one for drm compiled with clang,
but there I at least heard back that a fix exists).
Since I am going to release rc1 tomorrow, and I don't want to release
it with an ugly compiler warning, I took it upon myself to just fix
the code:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fec4d42724a1bf3dcba52307e55375fdb967b852
HOWEVER.
That commit fixes the warning, and is at worst harmless. At best it
fixes an access to random stack memory. But it does smell like
somebody who actually knows how these arrays work should look at that
code.
IOW, maybe the code should actually have read 16 bytes from the Event
Status Indicator? Maybe offset 10 was wrong? Maybe
drm_dp_channel_eq_ok() should never have taken six bytes to begin
with?
It's a mystery, and I haven't heard anything otherwise, so there it is.
Linus
On Wed, Apr 28, 2021 at 12:27 AM Jani Nikula wrote:
>
> On Tue, 27 Apr 2021, Linus Torvalds wrote:
> > I've updated to Fedora 34 on one of my machines, and it causes a lot
> > of i915 warnings like
> >
> > drivers/gpu/drm/i915/intel_pm.c: In function ‘ilk_setup_wm_latency’:
> > drivers/gpu/drm/i915/intel_pm.c:3059:9: note: referencing argument 3
> > of type ‘const u16 *’ {aka ‘const short unsigned int *’}
> > drivers/gpu/drm/i915/intel_pm.c:2994:13: note: in a call to function
> > ‘intel_print_wm_latency’
> >
> > and the reason is that gcc now seems to look at the argument array
> > size more, and notices that
>
> Arnd Bergmann reported some of these a while back. I think we have some
> of them fixed in our -next already, but not all. Thanks for the
> reminder.
[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=51381 --- Comment #58 from Luca T. (luca.trom...@gmail.com) --- (In reply to luminoso from comment #57) > For users still facing this issue, I workaround it with this: > https://github.com/aelveborn/vgaswitcheroo-systemd > > Basically before suspending it restores the GPU powerstate and resumes it > once coming from a suspend state. > > Never had problems again. Hi Luminoso, Thanks a lot, I'll try it out and let you know. Thanks, Luca -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 0/2] drm: Fix atomic helper dirtyfb stalls
From: Rob Clark Someone on IRC once asked an innocent enough sounding question: Why with xf86-video-modesetting is es2gears limited at 120fps. So I broke out the perfetto tracing mesa MR and took a look. It turns out the problem was drm_atomic_helper_dirtyfb(), which would end up waiting for vblank.. es2gears would rapidly push two frames to Xorg, which would blit them to screen and in idle hook (I assume) call the DIRTYFB ioctl. Which in turn would do an atomic update to flush the dirty rects, which would stall until the next vblank. And then the whole process would repeat. But this is a bit silly, we only need dirtyfb for command mode DSI panels. So lets just skip it otherwise. Rob Clark (2): drm: Fix dirtyfb stalls drm/msm/dpu: Wire up needs_dirtyfb drivers/gpu/drm/drm_damage_helper.c | 8 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 14 ++ include/drm/drm_modeset_helper_vtables.h | 14 ++ 3 files changed, 36 insertions(+) -- 2.30.2
[PATCH 1/2] drm: Fix dirtyfb stalls
From: Rob Clark
drm_atomic_helper_dirtyfb() will end up stalling for vblank on "video
mode" type displays, which is pointless and unnecessary. Add an
optional helper vfunc to determine if a plane is attached to a CRTC
that actually needs dirtyfb, and skip over them.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_damage_helper.c | 8
include/drm/drm_modeset_helper_vtables.h | 14 ++
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_damage_helper.c
b/drivers/gpu/drm/drm_damage_helper.c
index 3a4126dc2520..a0bed1a2c2dc 100644
--- a/drivers/gpu/drm/drm_damage_helper.c
+++ b/drivers/gpu/drm/drm_damage_helper.c
@@ -211,6 +211,7 @@ int drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb,
retry:
drm_for_each_plane(plane, fb->dev) {
struct drm_plane_state *plane_state;
+ struct drm_crtc *crtc;
ret = drm_modeset_lock(&plane->mutex, state->acquire_ctx);
if (ret)
@@ -221,6 +222,13 @@ int drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb,
continue;
}
+ crtc = plane->state->crtc;
+ if (crtc->helper_private->needs_dirtyfb &&
+ !crtc->helper_private->needs_dirtyfb(crtc)) {
+ drm_modeset_unlock(&plane->mutex);
+ continue;
+ }
+
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {
ret = PTR_ERR(plane_state);
diff --git a/include/drm/drm_modeset_helper_vtables.h
b/include/drm/drm_modeset_helper_vtables.h
index eb706342861d..afa8ec5754e7 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -487,6 +487,20 @@ struct drm_crtc_helper_funcs {
bool in_vblank_irq, int *vpos, int *hpos,
ktime_t *stime, ktime_t *etime,
const struct drm_display_mode *mode);
+
+ /**
+* @needs_dirtyfb
+*
+* Optional callback used by damage helpers to determine if
fb_damage_clips
+* update is needed.
+*
+* Returns:
+*
+* True if fb_damage_clips update is needed to handle DIRTYFB, False
+* otherwise. If this callback is not implemented, then True is
+* assumed.
+*/
+ bool (*needs_dirtyfb)(struct drm_crtc *crtc);
};
/**
--
2.30.2
[PATCH 2/2] drm/msm/dpu: Wire up needs_dirtyfb
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 5a74f93e29da..868ee6136438 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -143,6 +143,19 @@ static bool dpu_crtc_get_scanout_position(struct drm_crtc
*crtc,
return true;
}
+static bool dpu_crtc_needs_dirtyfb(struct drm_crtc *crtc)
+{
+ struct drm_encoder *encoder;
+
+ drm_for_each_encoder_mask (encoder, crtc->dev,
crtc->state->encoder_mask) {
+ if (dpu_encoder_get_intf_mode(encoder) == INTF_MODE_CMD) {
+ return true;
+ }
+ }
+
+ return false;
+}
+
static void _dpu_crtc_setup_blend_cfg(struct dpu_crtc_mixer *mixer,
struct dpu_plane_state *pstate, struct dpu_format *format)
{
@@ -1343,6 +1356,7 @@ static const struct drm_crtc_helper_funcs
dpu_crtc_helper_funcs = {
.atomic_begin = dpu_crtc_atomic_begin,
.atomic_flush = dpu_crtc_atomic_flush,
.get_scanout_position = dpu_crtc_get_scanout_position,
+ .needs_dirtyfb = dpu_crtc_needs_dirtyfb,
};
/* initialize crtc */
--
2.30.2
nouveau timeout errors with kernel 5.12
Hi, Beginning with kernel 5.12 I started getting system hangs/freezes, particularly when starting the Chrome browser. At least some of these are logged as a timeout. My hardware is a NVIDIA Corporation GF116 [GeForce GTX 550 Ti] [10de:1244] (rev a1). I tried to bisect the error, but the error does not show immediately, and I have little confidence in the bisection. For reference, my last bad commit was 05fcc256 and my last good commit was 6fc90e18. A typical error splat is: : [ cut here ] : nouveau :01:00.0: timeout : WARNING: CPU: 3 PID: 1970 at drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogf100.c:90 gf100_fifo_gpfifo_engine_fini+0x168/0x1b0 [nouveau] : Modules linked in: af_packet vboxnetadp(O) vboxnetflt(O) vboxdrv(O) dmi_sysfs xfs raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq raid1 libcrc32c md_mod edac_mce_amd kvm_amd ccp hid_generic snd_hda_codec_realtek snd_hda_codec_generic kvm usbhid eeepc_wmi ledtrig_audio snd_hda_codec_hdmi snd_hda_intel irqbypass snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core asus_wmi snd_hwdep snd_pcm battery snd_timer sparse_keymap rfkill wmi_bmof pcspkr efi_pstore snd fam15h_power k10temp igb soundcore dca sp5100_tco i2c_piix4 acpi_cpufreq tiny_power_button nls_iso8859_1 nls_cp437 vfat fat nfsd auth_rpcgss nfs_acl lockd grace sunrpc nfs_ssc fuse configfs uas usb_storage nouveau ohci_pci video drm_ttm_helper ttm i2c_algo_bit drm_kms_helper crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel syscopyarea sysfillrect sysimgblt crypto_simd fb_sys_fops cryptd cec rc_core xhci_pci xhci_pci_renesas xhci_hcd drm ehci_pci ohci_hcd : ehci_hcd usbcore mxm_wmi sr_mod cdrom wmi button sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua msr efivarfs : CPU: 3 PID: 1970 Comm: gdbus Tainted: GW O 5.12.0-2-default #1 openSUSE Tumbleweed : Hardware name: To be filled by O.E.M. To be filled by O.E.M./970 PRO GAMING/AURA, BIOS 0901 11/07/2016 : RIP: 0010:gf100_fifo_gpfifo_engine_fini+0x168/0x1b0 [nouveau] : Code: 8b 40 10 48 8b 78 10 48 8b 6f 50 48 85 ed 75 03 48 8b 2f e8 ca f3 d6 e4 48 89 ea 48 c7 c7 1c b9 8a c0 48 89 c6 e8 f9 9b 05 e5 <0f> 0b 41 8b 46 38 85 c0 0f 85 53 8c 07 00 48 8b bb d0 01 00 00 41 : RSP: 0018:9fe282517a20 EFLAGS: 00010282 : RAX: RBX: 89c268a85400 RCX: 89c50ecda708 : RDX: ffd8 RSI: 0027 RDI: 89c50ecda700 : RBP: 89c20116f1d0 R08: 89c51ef567a8 R09: 00013ffb : R10: c000 R11: 3fff R12: : R13: 89c250c43de0 R14: 89c20835 R15: : FS: 7f376efb6640() GS:89c50ecc() knlGS: : CS: 0010 DS: ES: CR0: 80050033 : CR2: 5567fe52cfa8 CR3: 0001507c8000 CR4: 000406e0 : Call Trace: : nvkm_fifo_chan_child_fini+0x79/0xf0 [nouveau] : nvkm_oproxy_fini+0x2c/0x90 [nouveau] : nvkm_object_fini+0xbc/0x150 [nouveau] : nvkm_object_fini+0x73/0x150 [nouveau] : nvkm_ioctl_del+0x2f/0x50 [nouveau] : nvkm_ioctl+0xe1/0x180 [nouveau] : nvif_object_dtor+0x5a/0x80 [nouveau] : nouveau_channel_del+0xad/0x160 [nouveau] : nouveau_abi16_chan_fini.constprop.0+0x10b/0x190 [nouveau] : nouveau_abi16_fini+0x2e/0x60 [nouveau] : nouveau_drm_postclose+0x4c/0xd0 [nouveau] : drm_file_free.part.0+0x1c9/0x230 [drm] : drm_release+0x65/0x110 [drm] : __fput+0x94/0x240 : task_work_run+0x65/0xa0 : do_exit+0x362/0xa20 : do_group_exit+0x33/0xa0 : get_signal+0x161/0x8b0 : arch_do_signal_or_restart+0xef/0x830 : ? __x64_sys_futex+0x13d/0x1c0 : exit_to_user_mode_prepare+0xed/0x180 : syscall_exit_to_user_mode+0x18/0x40 : entry_SYSCALL_64_after_hwframe+0x44/0xae : RIP: 0033:0x7f377ed6d5cf : Code: Unable to access opcode bytes at RIP 0x7f377ed6d5a5. : RSP: 002b:7f376efb5a40 EFLAGS: 0293 ORIG_RAX: 0007 : RAX: fdfc RBX: 7f377eeae1e0 RCX: 7f377ed6d5cf : RDX: RSI: 0003 RDI: 55b2cd634480 : RBP: 55b2cd634480 R08: R09: 0004 : R10: 0030 R11: 0293 R12: 0003 : R13: 7f376efb5a84 R14: R15: 55b2cd634370 : ---[ end trace c85bfdc7ef3321c2 ]--- : nouveau :01:00.0: fifo: channel 7 [ibus-extension-[1940]] kick timeout : nouveau: ibus-extension-[1940]::906f: detach sw failed, -110 : nouveau :01:00.0: fifo: SCHED_ERROR 0d [] : nouveau :01:00.0: fifo: runlist update timeout : nouveau :01:00.0: ibus-x11[1942]: failed to idle channel 9 [ibus-x11[1942]] : nouveau :01:00.0: ibus-x11[1942]: failed to idle channel 9 [ibus-x11[1942]] : [ cut here ] I will be happy to provide any additional material that may be needed. Thanks, Larry
[PATCH V4 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on, but easy to add. The driver operates the chip via I2C bus. Currently the LVDS clock are always derived from DSI clock lane, which is the usual mode of operation. Support for clock from external oscillator is not implemented, but it is easy to add if ever needed. Only RGB888 pixel format is implemented, the LVDS666 is not supported, but could be added if needed. Reviewed-by: Linus Walleij Reviewed-by: Frieder Schrempf Tested-by: Frieder Schrempf Signed-off-by: Marek Vasut Cc: Douglas Anderson Cc: Jagan Teki Cc: Laurent Pinchart Cc: Linus Walleij Cc: Loic Poulain Cc: Philippe Schenker Cc: Sam Ravnborg Cc: Stephen Boyd Cc: Valentin Raevsky To: dri-devel@lists.freedesktop.org --- V2: - Use dev_err_probe() - Set REG_RC_RESET as volatile - Wait for PLL stabilization by polling REG_RC_LVDS_PLL - Use ctx->mode = *adj instead of *mode in sn65dsi83_mode_set - Add tested DSI84 support in dual-link mode - Correctly set VCOM - Fill in missing DSI CHB and LVDS CHB bits from DSI84 and DSI85 datasheets, with that all the reserved bits make far more sense as the DSI83 and DSI84 seems to be reduced version of DSI85 V3: - Handle the dual-link LVDS with two port panel or bridge V4: - Add RB from Linus Walleij - Rename REG_DSI_LANE_LVDS_LINK_CFG_DUAL to REG_DSI_LANE_DSI_CHANNEL_MODE_SINGLE and fill in the remaining DSI link options from DSI85 datasheet. DSI85 can do dual and 2x single DSI mode, but DSI85 is currently unsupported by the driver. Add a comment about DSI85, so that all the places which need to be adjusted for DSI85 are marked accordingly. - Add REG_DSI_LANE_LEFT_RIGHT_PIXELS bit for DSI - Add handling for JEIDA18/JEIDA24/SPWG24 LVDS formats. Use SPWG24 as fallback on output bridges until they are all fixed. - Patch DSI bus format to fixed RGB888_1X24 instead of passing through the LVDS bus format. --- drivers/gpu/drm/bridge/Kconfig| 10 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ti-sn65dsi83.c | 698 ++ 3 files changed, 709 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index e83b8ad0d71b..32204c5f25b7 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -278,6 +278,16 @@ config DRM_TI_TFP410 help Texas Instruments TFP410 DVI/HDMI Transmitter driver +config DRM_TI_SN65DSI83 + tristate "TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge" + depends on OF + select DRM_KMS_HELPER + select REGMAP_I2C + select DRM_PANEL + select DRM_MIPI_DSI + help + Texas Instruments SN65DSI83 and SN65DSI84 DSI to LVDS Bridge driver + config DRM_TI_SN65DSI86 tristate "TI SN65DSI86 DSI to eDP bridge" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index b00f3b2ad572..7bb4c9df0415 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -24,6 +24,7 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ +obj-$(CONFIG_DRM_TI_SN65DSI83) += ti-sn65dsi83.o obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c new file mode 100644 index ..1a0a71fbe91d --- /dev/null +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c @@ -0,0 +1,698 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * TI SN65DSI83,84,85 driver + * + * Currently supported: + * - SN65DSI83 + * = 1x Single-link DSI ~ 1x Single-link LVDS + * - Supported + * - Single-link LVDS mode tested + * - SN65DSI84 + * = 1x Single-link DSI ~ 2x Single-link or 1x Dual-link LVDS + * - Supported + * - Dual-link LVDS mode tested + * - 2x Single-link LVDS mode unsupported + * (should be easy to add by someone who has the HW) + * - SN65DSI85 + * = 2x Single-link or 1x Dual-link DSI ~ 2x Single-link or 1x Dual-link LVDS + * - Unsupported + * (should be easy to add by someone who has the HW) + * + * Copyright (C) 2021 Marek Vasut + * + * Based on previous work of: + * Valentin Raevsky + * Philippe Schenker + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +/* ID registers */ +#define REG_ID(n) (0x00 + (n)) +/* Reset and clock registers */ +#defin
[PATCH V4 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 bindings
Add DT binding document for TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge.
Reviewed-by: Linus Walleij
Signed-off-by: Marek Vasut
Cc: Douglas Anderson
Cc: Jagan Teki
Cc: Laurent Pinchart
Cc: Linus Walleij
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: Stephen Boyd
Cc: devicet...@vger.kernel.org
To: dri-devel@lists.freedesktop.org
---
V2: Add compatible string for SN65DSI84, since this is now tested on it
V3: - Add 0x2c as valid i2c address
- Switch to schemas/graph.yaml
- Constraint data-lanes to <1>, <1 2>, <1 2 3>, <1 2 3 4> only
- Indent example by 4 spaces
- Handle dual-link LVDS with two ports and describe the second DSI
channel-B port as well. Based on the register defaults of DSI83
and DSI84, it is likely that the LVDS-channel-B and DSI-channel-B
hardware is present in all the chips, so just reuse port@0 and 2
for DSI83, port@0,2,3 for DSI84 and all of 0,1,2,3 for DSI85 when
that is supported
V4: - Fix typo in port@3 description
- Add RB from Linus Walleij
- Replace oneOf: and const with enum:
- ref /schemas/media/video-interfaces.yaml#
- Drop empty endpoint: and properties:
---
.../bindings/display/bridge/ti,sn65dsi83.yaml | 159 ++
1 file changed, 159 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
new file mode 100644
index ..d101233ae17f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
@@ -0,0 +1,159 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi83.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SN65DSI83 and SN65DSI84 DSI to LVDS bridge chip
+
+maintainers:
+ - Marek Vasut
+
+description: |
+ Texas Instruments SN65DSI83 1x Single-link MIPI DSI
+ to 1x Single-link LVDS
+ https://www.ti.com/lit/gpn/sn65dsi83
+ Texas Instruments SN65DSI84 1x Single-link MIPI DSI
+ to 1x Dual-link or 2x Single-link LVDS
+ https://www.ti.com/lit/gpn/sn65dsi84
+
+properties:
+ compatible:
+enum:
+ - ti,sn65dsi83
+ - ti,sn65dsi84
+
+ reg:
+enum:
+ - 0x2c
+ - 0x2d
+
+ enable-gpios:
+maxItems: 1
+description: GPIO specifier for bridge_en pin (active high).
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for MIPI DSI Channel-A input
+
+properties:
+ endpoint:
+$ref: /schemas/media/video-interfaces.yaml#
+unevaluatedProperties: false
+
+properties:
+ data-lanes:
+description: array of physical DSI data lane indexes.
+minItems: 1
+maxItems: 4
+items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for MIPI DSI Channel-B input
+
+properties:
+ endpoint:
+$ref: /schemas/media/video-interfaces.yaml#
+unevaluatedProperties: false
+
+properties:
+ data-lanes:
+description: array of physical DSI data lane indexes.
+minItems: 1
+maxItems: 4
+items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
+ port@2:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for LVDS Channel-A output (panel or bridge).
+
+ port@3:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for LVDS Channel-B output (panel or bridge).
+
+required:
+ - port@0
+ - port@2
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - ports
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: ti,sn65dsi83
+then:
+ properties:
+ports:
+ properties:
+port@1: false
+port@3: false
+
+ - if:
+ properties:
+compatible:
+ contains:
+const: ti,sn65dsi84
+then:
+ properties:
+ports:
+ properties:
+port@1: false
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+bridge@2d {
+compatible = "ti,sn65dsi83";
+reg = <0x2d>;
+
+enable-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+
Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
On 5/7/21 2:48 PM, Dave Stevenson wrote:
[...]
+static void sn65dsi83_enable(struct drm_bridge *bridge)
+{
+ struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
+ unsigned int pval;
+ u16 val;
+ int ret;
+
+ /* Clear reset, disable PLL */
+ regmap_write(ctx->regmap, REG_RC_RESET, 0x00);
+ regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
Sorry, a further thread of discussion coming from the investigations
I've been involved with.
You've powered up in pre_enable, and are sending the I2C writes in enable.
From the docs for drm_bridge_funcs->enable[1]
* The bridge can assume that the display pipe (i.e. clocks and timing
* signals) feeding it is running when this callback is called. This
* callback must enable the display link feeding the next bridge in the
* chain if there is one.
So video is running when enable is called, and the DSI data lanes may
be HS. (Someone correct me if that is an incorrect reading of the
text).
The SN65DSI84 datasheet table 7-2 Initialization Sequence gives init
seq 8 as being "Change DSI data lanes to HS state and start DSI video
stream", AFTER all the I2C has been completed except reading back
registers and checking for errors.
With video running you don't fulfil the second part of init seq 2 "the
DSI data lanes MUST be driven to LP11 state"
My investigations have been over delaying starting the DSI video
stream until after enable, but reading the descriptive text for enable
I believe the Pi is correct to be sending video at that point.
I guess there is some ambiguity as to whether the clock lane is going
to be in HS mode during pre_enable. On the Pi the PHY and clocks will
be enabled prior to pre_enable to allow for sending DSI commands
during pre_enable, but it may not be true on other platforms.
You have to make sure the clock lane is running and in HS mode when
configuring the DSI83, otherwise the internal DSI83 state machine won't
be able to operate.
[...]
Re: [PATCH V3 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
On 5/7/21 11:17 AM, Dave Stevenson wrote: On Thu, 6 May 2021 at 21:51, Marek Vasut wrote: On 5/6/21 6:03 PM, Frieder Schrempf wrote: On 06.05.21 17:46, Marek Vasut wrote: On 5/6/21 5:38 PM, Frieder Schrempf wrote: [...] Works on i.MX8MM with SN65DSI84 and a single link LVDS display (1024x600) and from my perspective everything else also looks good. Thanks for your work! I have two remarks: 1. In my test I couldn't get it to work with four DSI lanes enabled (only with two) but I'm quite sure that the DSIM driver is to blame as everything on the bridge level looks good (also setting the DSI EQ register didn't help as you suggested, Marek). I suspect there is indeed something with the DSIM going on, I'll keep you posted if I find something out. 2. When I set MEDIA_BUS_FMT_RGB888_1X7X4_SPWG in the panel driver I get distorted colors. I need to use MEDIA_BUS_FMT_RGB888_1X24 to make it work, but this is not valid for LVDS. Again I don't think this driver is to blame as I can't see where it does anything wrong, but my experience here is very limited so I still want to mention it. Hmm, in that conversion supposed to happen in this bridge driver or should MXSFB handle the SPWG pixel format ? Or should the DSIM bridge do something about that ? As far as I understand it the conversion is already done by the DSI84 without any extra configuration necessary. The only thing that needs to be done is selecting the LVDS output format via CHx_24BPP_MODE and CHx_24BPP_FORMAT1 which the driver currently hardcodes to 24bpp aka MEDIA_BUS_FMT_RGB888_1X7X4_SPWG. I think the DSI input format is always 24bpp aka MEDIA_BUS_FMT_RGB888_1X24. The DSI is MEDIA_BUS_FMT_RGB888_1X24, yes. So maybe this bridge driver has to somehow deal with MEDIA_BUS_FMT_RGB888_1X7X4_SPWG ? Except I haven't seen such a thing implemented in other bridge drivers, so input would be welcome on this. I'm claiming no knowledge of whether this is the correct approach or not, but Toshiba TC358775 is also a DSI to LVDS bridge which appears to handle both formats. https://elixir.free-electrons.com/linux/latest/source/drivers/gpu/drm/bridge/tc358775.c#L457 That's what quick git grep points you to, yes. Except that driver does not patch the bus pixel format for the DSI in any way, it just passes whatever bus pixel format it got from the panel/output bridge through. You need something like drm_display_info_set_bus_formats() called somewhere. So I wonder where the format actually is evaluated. Could it be that it is passed down to the LCDIF and changes its output format which causes the data passed by DSIM to the DSI84 to already be in the SPWG format? If that's the case we maybe need a way to specify MEDIA_BUS_FMT_RGB888_1X24 as input bus format for the DSI84 so it doesn't pass on the panel's format? Only a wild guess, no idea if it really works like that. I _think_ the bridge must somehow handle the MEDIA_BUS_FMT_RGB888_1X7X4_SPWG <-> MEDIA_BUS_FMT_RGB888_1X24 conversion. I've not looked at where the interchange happens, but as you're setting the DSI format in struct mipi_dsi_device to MIPI_DSI_FMT_RGB888 doesn't that provide the configuration side to the DSI transmitter? Otherwise presumably it needs to support the atomic_get_input_bus_fmts and/or atomic_get_output_bus_fmts functions in drm_bridge_funcs. That doesn't work either, but see above, I think you need drm_display_info_set_bus_formats() .
[PATCH] video: fbdev: lcd_mipid: Fix a memory leak in an error handling path
If 'mipid_detect()' fails, we must free 'md' to avoid a memory leak.
While at it, modernize the function:
- remove a useless message in case of memory allocation failure
- change a '== NULL' into a '!'
Fixes: 66d2f99d0bb5 ("omapfb: add support for MIPI-DCS compatible LCDs")
Signed-off-by: Christophe JAILLET
---
drivers/video/fbdev/omap/lcd_mipid.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/omap/lcd_mipid.c
b/drivers/video/fbdev/omap/lcd_mipid.c
index a75ae0c9b14c..b4b93ff4b41a 100644
--- a/drivers/video/fbdev/omap/lcd_mipid.c
+++ b/drivers/video/fbdev/omap/lcd_mipid.c
@@ -551,10 +551,8 @@ static int mipid_spi_probe(struct spi_device *spi)
int r;
md = kzalloc(sizeof(*md), GFP_KERNEL);
- if (md == NULL) {
- dev_err(&spi->dev, "out of memory\n");
+ if (!md)
return -ENOMEM;
- }
spi->mode = SPI_MODE_0;
md->spi = spi;
@@ -563,11 +561,15 @@ static int mipid_spi_probe(struct spi_device *spi)
r = mipid_detect(md);
if (r < 0)
- return r;
+ goto free_md;
omapfb_register_panel(&md->panel);
return 0;
+
+free_md:
+ kfree(md);
+ return r;
}
static int mipid_spi_remove(struct spi_device *spi)
--
2.30.2
[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=51381 --- Comment #59 from Luca T. (luca.trom...@gmail.com) --- (In reply to luminoso from comment #57) > For users still facing this issue, I workaround it with this: > https://github.com/aelveborn/vgaswitcheroo-systemd > > Basically before suspending it restores the GPU powerstate and resumes it > once coming from a suspend state. > > Never had problems again. Hi Luminoso, it works greatly, thanks a lot!!! I read about this switch but I lost the patience to try and retry, but you saved my life! :) Thank you so much, Luca -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
