Re: [PATCH 2/8] drm/panfrost: Fix a race in panfrost_ioctl_madvise()
On Thu, 5 Dec 2019 17:08:02 -0600
Rob Herring wrote:
> On Fri, Nov 29, 2019 at 8:33 AM Boris Brezillon
> wrote:
> >
> > On Fri, 29 Nov 2019 14:24:48 +
> > Steven Price wrote:
> >
> > > On 29/11/2019 13:59, Boris Brezillon wrote:
> > > > If 2 threads change the MADVISE property of the same BO in parallel we
> > > > might end up with an shmem->madv value that's inconsistent with the
> > > > presence of the BO in the shrinker list.
> > >
> > > I'm a bit worried from the point of view of user space sanity that you
> > > observed this - but clearly the kernel should be robust!
> >
> > It's not something I observed, just found the race by inspecting the
> > code, and I thought it was worth fixing it.
>
> I'm not so sure there's a race.
I'm pretty sure there's one:
T0 T1
lock(pages)
madv = 1
unlock(pages)
lock(pages)
madv = 0
unlock(pages)
lock(shrinker)
remove_from_list(bo)
unlock(shrinker)
lock(shrinker)
add_to_list(bo)
unlock(shrinker)
You end up with madv = 0 and the BO is added to the list.
> If there is, we still check madv value
> when purging, so it would be harmless even if the state is
> inconsistent.
Indeed. Note that you could also have this other situation where the BO
is marked purgeable but not present in the list. In that case it will
never be purged, but it's kinda user space fault anyway. I agree, none
of this problems are critical, and I'm fine leaving it unfixed as long
as it's documented somewhere that the race exist and is harmless.
>
> > > > The easiest solution to fix that is to protect the
> > > > drm_gem_shmem_madvise() call with the shrinker lock.
> > > >
> > > > Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support")
> > > > Cc:
> > > > Signed-off-by: Boris Brezillon
> > >
> > > Reviewed-by: Steven Price
> >
> > Thanks.
> >
> > >
> > > > ---
> > > > drivers/gpu/drm/panfrost/panfrost_drv.c | 9 -
> > > > 1 file changed, 4 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> > > > b/drivers/gpu/drm/panfrost/panfrost_drv.c
> > > > index f21bc8a7ee3a..efc0a24d1f4c 100644
> > > > --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> > > > +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> > > > @@ -347,20 +347,19 @@ static int panfrost_ioctl_madvise(struct
> > > > drm_device *dev, void *data,
> > > > return -ENOENT;
> > > > }
> > > >
> > > > + mutex_lock(&pfdev->shrinker_lock);
> > > > args->retained = drm_gem_shmem_madvise(gem_obj, args->madv);
>
> This means we now hold the shrinker_lock while we take the pages_lock.
> Is lockdep happy with this change? I suspect not given all the fun I
> had getting lockdep happy.
I have tested with lockdep enabled and it's all good from lockdep PoV
because the locks are taken in the same order in the madvise() and
schinker_scan() path (first the shrinker lock, then the pages lock).
Note that patch 7 introduces a deadlock in the shrinker path, but this
is unrelated to this shrinker lock being taken earlier in madvise
(drm_gem_put_pages() is called while the pages lock is already held).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/mgag200: Add workaround for HW that does not support 'startadd'
Hi
Am 06.12.19 um 07:50 schrieb David Airlie:
> On Fri, Dec 6, 2019 at 4:14 PM Thomas Zimmermann wrote:
>>
>> Hi
>>
>> Am 04.12.19 um 10:36 schrieb Dave Airlie:
>>> On Wed, 4 Dec 2019 at 17:30, Thomas Zimmermann wrote:
Hi John
Am 03.12.19 um 18:55 schrieb John Donnelly:
> Hi ,
>
> See below ,
>
>
>> On Nov 26, 2019, at 3:50 AM, Thomas Zimmermann
>> wrote:
>>
>> Hi
>>
>> Am 26.11.19 um 10:37 schrieb Daniel Vetter:
>>> On Tue, Nov 26, 2019 at 08:25:44AM +0100, Thomas Zimmermann wrote:
There's at least one system that does not interpret the value of
the device's 'startadd' field correctly, which leads to incorrectly
displayed scanout buffers. Always placing the active scanout buffer
at offset 0 works around the problem.
Signed-off-by: Thomas Zimmermann
Reported-by: John Donnelly
Link: https://gitlab.freedesktop.org/drm/misc/issues/7
>>>
>>> Tested-by: John Donnelly
>>>
>>> (Not quite this patch, but pretty much the logic, so counts).
>>>
>>> Fixes: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system() with
>>> kunmap + unpin")
>>> Cc: # v5.3+
>>>
>>> Also you need the stable line on both prep patches too. For next time
>>> around,
>>>
>>> $ dim fixes 81da87f63a1e
>>>
>>> will generate all the stuff you need, including a good set of suggested
>>> Cc: you should have.
>>>
>>> On the first 3 patches, with all that stuff added:
>>>
>>> Reviewed-by: Daniel Vetter
>>
>> Thanks for the review.
>>
>> Sorry for leaving out some of the tags. I wanted to wait for feedback
>> before adding tested-by, fixes, stable. I'll split off patch 4 from the
>> series and get 1 to 3 merged ASAP.
>>
>> Best regards
>> Thomas
>>
>>>
>>> Please push these to drm-misc-next-fixes so they get backported as
>>> quickly
>>> as possible.
>>> -Daniel
>>>
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 36 ++-
drivers/gpu/drm/mgag200/mgag200_drv.h | 3 +++
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index 397f8b0a9af8..d43951caeea0 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -30,6 +30,8 @@ module_param_named(modeset, mgag200_modeset, int,
0400);
static struct drm_driver driver;
static const struct pci_device_id pciidlist[] = {
+ { PCI_VENDOR_ID_MATROX, 0x522, PCI_VENDOR_ID_SUN, 0x4852, 0, 0,
+ G200_SE_A | MGAG200_FLAG_HW_BUG_NO_STARTADD},
>
>
>
> I will have an additional list of vendor IDs (0x4852) I will provide in
> a follow up patch shortly . This fixes only 1 flavor of server.
Thank you for all the testing you do. We can add these ids as necessary.
Before, I posted a patch at [1] that prints an internal unique id. The
id of your original test machine was 0x2 IIRC.
My guess is that the problem might be related to the chip's revision. If
you have the option of booting your own kernels on all these machines,
could you apply the patch and look for a pattern in these ids? Maybe
only revision 0x2 is affected.
>>>
>>> I've got an old bug I never got around to that has a comment from Matrox
>>>
>>> "The issue is reproducible with G200e chip. The device ID is 0x0522."
>>>
>>> so it might be a broader problem than we think.
>>
>> Did they tell you a subvendor id? John reported that the internal
>> revision id differs among affected machines. I'm thinking about flagging
>> either Sun devices or all 0x0522 devices as broken.
>
> Well it was from Matrox themselves, so they are the vendor ID, it
> didn't sounds like subvendor mattered, though I expect the problem is
> the BMC firmware anyways, not sure if we can even know what ths is.
OK, thanks. I'll prepare a patch to flag all 0x0522 machines.
Best regards
Thomas
>
> Dave.
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/mgag200: Add workaround for HW that does not support 'startadd'
On Fri, Dec 6, 2019 at 4:14 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 04.12.19 um 10:36 schrieb Dave Airlie:
> > On Wed, 4 Dec 2019 at 17:30, Thomas Zimmermann wrote:
> >>
> >> Hi John
> >>
> >> Am 03.12.19 um 18:55 schrieb John Donnelly:
> >>> Hi ,
> >>>
> >>> See below ,
> >>>
> >>>
> On Nov 26, 2019, at 3:50 AM, Thomas Zimmermann
> wrote:
>
> Hi
>
> Am 26.11.19 um 10:37 schrieb Daniel Vetter:
> > On Tue, Nov 26, 2019 at 08:25:44AM +0100, Thomas Zimmermann wrote:
> >> There's at least one system that does not interpret the value of
> >> the device's 'startadd' field correctly, which leads to incorrectly
> >> displayed scanout buffers. Always placing the active scanout buffer
> >> at offset 0 works around the problem.
> >>
> >> Signed-off-by: Thomas Zimmermann
> >> Reported-by: John Donnelly
> >> Link: https://gitlab.freedesktop.org/drm/misc/issues/7
> >
> > Tested-by: John Donnelly
> >
> > (Not quite this patch, but pretty much the logic, so counts).
> >
> > Fixes: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system() with
> > kunmap + unpin")
> > Cc: # v5.3+
> >
> > Also you need the stable line on both prep patches too. For next time
> > around,
> >
> > $ dim fixes 81da87f63a1e
> >
> > will generate all the stuff you need, including a good set of suggested
> > Cc: you should have.
> >
> > On the first 3 patches, with all that stuff added:
> >
> > Reviewed-by: Daniel Vetter
>
> Thanks for the review.
>
> Sorry for leaving out some of the tags. I wanted to wait for feedback
> before adding tested-by, fixes, stable. I'll split off patch 4 from the
> series and get 1 to 3 merged ASAP.
>
> Best regards
> Thomas
>
> >
> > Please push these to drm-misc-next-fixes so they get backported as
> > quickly
> > as possible.
> > -Daniel
> >
> >> ---
> >> drivers/gpu/drm/mgag200/mgag200_drv.c | 36 ++-
> >> drivers/gpu/drm/mgag200/mgag200_drv.h | 3 +++
> >> 2 files changed, 38 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
> >> b/drivers/gpu/drm/mgag200/mgag200_drv.c
> >> index 397f8b0a9af8..d43951caeea0 100644
> >> --- a/drivers/gpu/drm/mgag200/mgag200_drv.c
> >> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
> >> @@ -30,6 +30,8 @@ module_param_named(modeset, mgag200_modeset, int,
> >> 0400);
> >> static struct drm_driver driver;
> >>
> >> static const struct pci_device_id pciidlist[] = {
> >> + { PCI_VENDOR_ID_MATROX, 0x522, PCI_VENDOR_ID_SUN, 0x4852, 0, 0,
> >> + G200_SE_A | MGAG200_FLAG_HW_BUG_NO_STARTADD},
> >>>
> >>>
> >>>
> >>> I will have an additional list of vendor IDs (0x4852) I will provide in
> >>> a follow up patch shortly . This fixes only 1 flavor of server.
> >>
> >> Thank you for all the testing you do. We can add these ids as necessary.
> >>
> >> Before, I posted a patch at [1] that prints an internal unique id. The
> >> id of your original test machine was 0x2 IIRC.
> >>
> >> My guess is that the problem might be related to the chip's revision. If
> >> you have the option of booting your own kernels on all these machines,
> >> could you apply the patch and look for a pattern in these ids? Maybe
> >> only revision 0x2 is affected.
> >>
> >
> > I've got an old bug I never got around to that has a comment from Matrox
> >
> > "The issue is reproducible with G200e chip. The device ID is 0x0522."
> >
> > so it might be a broader problem than we think.
>
> Did they tell you a subvendor id? John reported that the internal
> revision id differs among affected machines. I'm thinking about flagging
> either Sun devices or all 0x0522 devices as broken.
Well it was from Matrox themselves, so they are the vendor ID, it
didn't sounds like subvendor mattered, though I expect the problem is
the BMC firmware anyways, not sure if we can even know what ths is.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/mgag200: Add workaround for HW that does not support 'startadd'
Hi
Am 04.12.19 um 10:36 schrieb Dave Airlie:
> On Wed, 4 Dec 2019 at 17:30, Thomas Zimmermann wrote:
>>
>> Hi John
>>
>> Am 03.12.19 um 18:55 schrieb John Donnelly:
>>> Hi ,
>>>
>>> See below ,
>>>
>>>
On Nov 26, 2019, at 3:50 AM, Thomas Zimmermann wrote:
Hi
Am 26.11.19 um 10:37 schrieb Daniel Vetter:
> On Tue, Nov 26, 2019 at 08:25:44AM +0100, Thomas Zimmermann wrote:
>> There's at least one system that does not interpret the value of
>> the device's 'startadd' field correctly, which leads to incorrectly
>> displayed scanout buffers. Always placing the active scanout buffer
>> at offset 0 works around the problem.
>>
>> Signed-off-by: Thomas Zimmermann
>> Reported-by: John Donnelly
>> Link: https://gitlab.freedesktop.org/drm/misc/issues/7
>
> Tested-by: John Donnelly
>
> (Not quite this patch, but pretty much the logic, so counts).
>
> Fixes: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system() with
> kunmap + unpin")
> Cc: # v5.3+
>
> Also you need the stable line on both prep patches too. For next time
> around,
>
> $ dim fixes 81da87f63a1e
>
> will generate all the stuff you need, including a good set of suggested
> Cc: you should have.
>
> On the first 3 patches, with all that stuff added:
>
> Reviewed-by: Daniel Vetter
Thanks for the review.
Sorry for leaving out some of the tags. I wanted to wait for feedback
before adding tested-by, fixes, stable. I'll split off patch 4 from the
series and get 1 to 3 merged ASAP.
Best regards
Thomas
>
> Please push these to drm-misc-next-fixes so they get backported as quickly
> as possible.
> -Daniel
>
>> ---
>> drivers/gpu/drm/mgag200/mgag200_drv.c | 36 ++-
>> drivers/gpu/drm/mgag200/mgag200_drv.h | 3 +++
>> 2 files changed, 38 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
>> b/drivers/gpu/drm/mgag200/mgag200_drv.c
>> index 397f8b0a9af8..d43951caeea0 100644
>> --- a/drivers/gpu/drm/mgag200/mgag200_drv.c
>> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
>> @@ -30,6 +30,8 @@ module_param_named(modeset, mgag200_modeset, int,
>> 0400);
>> static struct drm_driver driver;
>>
>> static const struct pci_device_id pciidlist[] = {
>> + { PCI_VENDOR_ID_MATROX, 0x522, PCI_VENDOR_ID_SUN, 0x4852, 0, 0,
>> + G200_SE_A | MGAG200_FLAG_HW_BUG_NO_STARTADD},
>>>
>>>
>>>
>>> I will have an additional list of vendor IDs (0x4852) I will provide in a
>>> follow up patch shortly . This fixes only 1 flavor of server.
>>
>> Thank you for all the testing you do. We can add these ids as necessary.
>>
>> Before, I posted a patch at [1] that prints an internal unique id. The
>> id of your original test machine was 0x2 IIRC.
>>
>> My guess is that the problem might be related to the chip's revision. If
>> you have the option of booting your own kernels on all these machines,
>> could you apply the patch and look for a pattern in these ids? Maybe
>> only revision 0x2 is affected.
>>
>
> I've got an old bug I never got around to that has a comment from Matrox
>
> "The issue is reproducible with G200e chip. The device ID is 0x0522."
>
> so it might be a broader problem than we think.
Did they tell you a subvendor id? John reported that the internal
revision id differs among affected machines. I'm thinking about flagging
either Sun devices or all 0x0522 devices as broken.
Best regards
Thomas
>
> Dave.
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: FAILED - [PATCH v2 3/3] drm/mgag200: Add workaround for HW that does not support 'startadd'
Hi
Am 06.12.19 um 01:48 schrieb John Donnelly:
>
>
>> On Dec 3, 2019, at 11:30 AM, John Donnelly
>> wrote:
>>
>>
>> Hello Sasha and Thomas ,
>>
>>
>> This particular patch has failed on one class of servers that has a slightly
>> different Sun Vendor. ID for the BMC video device:
>>
>> I will follow up with additional details in the review comments for the
>> original message,.
>>
>>
>>
>>
>>> On Nov 28, 2019, at 8:23 AM, Sasha Levin wrote:
>>>
>>> Hi,
>>>
>>> [This is an automated email]
>>>
>>> This commit has been processed because it contains a "Fixes:" tag,
>>> fixing commit: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system()
>>> with kunmap + unpin").
>>>
>>> The bot has tested the following trees: v5.3.13.
>>>
>>> v5.3.13: Build failed! Errors:
>>> drivers/gpu/drm/mgag200/mgag200_drv.c:104:18: error:
>>> ‘drm_vram_mm_debugfs_init’ undeclared here (not in a function); did you
>>> mean ‘drm_client_debugfs_init’?
>>>
>
>
>I had this same issue and removed that from my local 5.4.0-rc8 build
The bot used the wrong tree. The patch has been written against drm-tip.
Best regards
Thomas
>
>
>
>
>>>
>>> NOTE: The patch will not be queued to stable trees until it is upstream.
>>>
>>> How should we proceed with this patch?
>>>
>>> --
>>> Thanks,
>>> Sasha
>>> ___
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=vxMDOLV77rRe2ekdNFH9IxMSBQrTccltZd8A1H6xYCc&s=efHs2lc_RQYvzLC82c-D3wa8MpX5DCU_YsIo6XruAQg&e=
>>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #44 from MasterCATZ (masterc...@hotmail.com) --- aio@aio:~$ ls /sys/class/drm/card1/device/hwmon/hwmon1 device freq1_input namepwm1 temp1_crit_hyst fan1_enable freq1_label power pwm1_enable temp1_input fan1_input freq2_input power1_average pwm1_max temp1_label fan1_max freq2_label power1_cap pwm1_min uevent fan1_min in0_inputpower1_cap_max subsystem fan1_target in0_labelpower1_cap_min temp1_crit aio@aio:~$ cat /sys/class/drm/card1/device/hwmon/hwmon1/pwm1 68 aio@aio:~$ cat /sys/class/drm/card1/device/hwmon/hwmon1/pwm1_enable 2 aio@aio:~$ cat /sys/class/drm/card1/device/hwmon/hwmon1/temp1_input 54000 aio@aio:~$ -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #43 from MasterCATZ (masterc...@hotmail.com) --- the file is correct .. and you can tell that because its reading the temp "current pwm: 76" error is because NOTHING is being allowed to edit pwm1_enable it is stuck on auto so nothing can manually change pwm1 but if their is an error in my adjustments let me know # hwmon paths, hardcoded for one amdgpu card, adjust as needed HWMON=$(ls /sys/class/drm/card1/device/hwmon/hwmon1) FILE_PWM=$(echo /sys/class/drm/card1/device/hwmon/hwmon1/pwm1) FILE_FANMODE=$(echo /sys/class/drm/card1/device/hwmon/hwmon1/pwm1_enable) FILE_TEMP=$(echo /sys/class/drm/card1/device/hwmon/hwmon1/temp1_input) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #42 from muncrief (rmuncr...@humanavance.com) --- (In reply to MasterCATZ from comment #41) > aio@aio:/usr/local/bin$ sudo systemctl status amdgpu-fancontrol > ● amdgpu-fancontrol.service - amdgpu-fancontrol >Loaded: loaded (/etc/systemd/system/amdgpu-fancontrol.service; enabled; > vendor preset: enabled) >Active: active (running) since Fri 2019-12-06 14:45:07 AEST; 3s ago > Main PID: 23922 (amdgpu-fancontr) > Tasks: 2 (limit: 4915) >Memory: 3.3M >CGroup: /system.slice/amdgpu-fancontrol.service >├─23922 /bin/bash /usr/local/bin/amdgpu-fancontrol >└─23979 sleep 1 > > Dec 06 14:45:08 aio amdgpu-fancontrol[23922]: changing pwm to 175 > Dec 06 14:45:08 aio amdgpu-fancontrol[23922]: > /usr/local/bin/amdgpu-fancontrol: line 65: echo: write error: Invalid > argument > Dec 06 14:45:09 aio amdgpu-fancontrol[23922]: current temp: 62000 > Dec 06 14:45:09 aio amdgpu-fancontrol[23922]: interpolated pwm value for > temperature 62000 is: 175 > Dec 06 14:45:09 aio amdgpu-fancontrol[23922]: current pwm: 104, requested to > set pwm to 175 > Dec 06 14:45:09 aio amdgpu-fancontrol[23922]: Fanmode not set to manual. > Dec 06 14:45:09 aio amdgpu-fancontrol[23922]: setting fan mode to 1 > Dec 06 14:45:09 aio amdgpu-fancontrol[23922]: temp at last change was 62000 > Dec 06 14:45:09 aio amdgpu-fancontrol[23922]: changing pwm to 175 > Dec 06 14:45:09 aio amdgpu-fancontrol[23922]: > /usr/local/bin/amdgpu-fancontrol: line 65: echo: write error: Invalid > argument I was about to call it a day when I got your email notifications. The line it's talking about is: echo "$NEW_PWM" > "$FILE_PWM" So it looks like the "$FILE_PWM" variable is not valid. Remember, you have to change the variables under the comment "hwmon paths, hardcoded for one amdgpu card, adjust as needed" to whatever your system requires. To debug the variables I would execute the 4 lines that set HWMON, FILE_PWM, FILE_FANMODE, and FILE_TEMP from terminal and see where things are going wrong. I have to go now but I'll try to help you more tomorrow if you're still having problems. But once you have those variables set correctly the script should work. Here's what the service status output looks like on my system: Loaded: loaded (/etc/systemd/system/amdgpu-fancontrol.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2019-12-05 18:16:27 PST; 2h 28min ago Main PID: 836 (amdgpu-fancontr) Tasks: 2 (limit: 4915) Memory: 7.7M CGroup: /system.slice/amdgpu-fancontrol.service ├─ 836 /bin/bash /usr/local/bin/amdgpu-fancontrol └─14235 sleep 1 Dec 05 20:44:46 Entropod amdgpu-fancontrol[836]: changing pwm to 80 Dec 05 20:44:47 Entropod amdgpu-fancontrol[836]: current temp: 49000 Dec 05 20:44:47 Entropod amdgpu-fancontrol[836]: interpolated pwm value for temperature 49000 is: 90 Dec 05 20:44:47 Entropod amdgpu-fancontrol[836]: current pwm: 76, requested to set pwm to 90 Dec 05 20:44:47 Entropod amdgpu-fancontrol[836]: temp at last change was 48000 Dec 05 20:44:47 Entropod amdgpu-fancontrol[836]: changing pwm to 90 Dec 05 20:44:48 Entropod amdgpu-fancontrol[836]: current temp: 48000 Dec 05 20:44:48 Entropod amdgpu-fancontrol[836]: interpolated pwm value for temperature 48000 is: 80 Dec 05 20:44:48 Entropod amdgpu-fancontrol[836]: current pwm: 86, requested to set pwm to 80 Dec 05 20:44:48 Entropod amdgpu-fancontrol[836]: not changing pwm, we just did at 49000, next change when below 43000 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #41 from MasterCATZ (masterc...@hotmail.com) --- aio@aio:/usr/local/bin$ sudo systemctl status amdgpu-fancontrol ● amdgpu-fancontrol.service - amdgpu-fancontrol Loaded: loaded (/etc/systemd/system/amdgpu-fancontrol.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2019-12-06 14:45:07 AEST; 3s ago Main PID: 23922 (amdgpu-fancontr) Tasks: 2 (limit: 4915) Memory: 3.3M CGroup: /system.slice/amdgpu-fancontrol.service ├─23922 /bin/bash /usr/local/bin/amdgpu-fancontrol └─23979 sleep 1 Dec 06 14:45:08 aio amdgpu-fancontrol[23922]: changing pwm to 175 Dec 06 14:45:08 aio amdgpu-fancontrol[23922]: /usr/local/bin/amdgpu-fancontrol: line 65: echo: write error: Invalid argument Dec 06 14:45:09 aio amdgpu-fancontrol[23922]: current temp: 62000 Dec 06 14:45:09 aio amdgpu-fancontrol[23922]: interpolated pwm value for temperature 62000 is: 175 Dec 06 14:45:09 aio amdgpu-fancontrol[23922]: current pwm: 104, requested to set pwm to 175 Dec 06 14:45:09 aio amdgpu-fancontrol[23922]: Fanmode not set to manual. Dec 06 14:45:09 aio amdgpu-fancontrol[23922]: setting fan mode to 1 Dec 06 14:45:09 aio amdgpu-fancontrol[23922]: temp at last change was 62000 Dec 06 14:45:09 aio amdgpu-fancontrol[23922]: changing pwm to 175 Dec 06 14:45:09 aio amdgpu-fancontrol[23922]: /usr/local/bin/amdgpu-fancontrol: line 65: echo: write error: Invalid argument -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #40 from MasterCATZ (masterc...@hotmail.com) --- aio@aio:~$ sudo pwmconfig [sudo] password for aio: # pwmconfig revision $Revision$ ($Date$) This program will search your sensors for pulse width modulation (pwm) controls, and test each one to see if it controls a fan on your motherboard. Note that many motherboards do not have pwm circuitry installed, even if your sensor chip supports pwm. We will attempt to briefly stop each fan using the pwm controls. The program will attempt to restore each fan to full speed after testing. However, it is ** very important ** that you physically verify that the fans have been to full speed after the program has completed. Found the following devices: hwmon0 is acpitz hwmon1 is amdgpu hwmon2 is coretemp hwmon3 is it8620 hwmon4 is it8792 Found the following PWM controls: hwmon1/pwm1 current value: 104 hwmon1/pwm1 is currently setup for automatic speed control. In general, automatic mode is preferred over manual mode, as it is more efficient and it reacts faster. Are you sure that you want to setup this output for manual control? (n) y hwmon1/pwm1_enable stuck to 2 Manual control mode not supported, skipping hwmon1/pwm1. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #39 from MasterCATZ (masterc...@hotmail.com) --- will not work , /sys/class/drm/card1/device/hwmon/hwmon1/pwm1_enable is locked to Auto [28455.094113] manual fan speed control should be enabled first [28473.077182] manual fan speed control should be enabled first [28480.086754] manual fan speed control should be enabled first [28498.073701] manual fan speed control should be enabled first [28499.095753] manual fan speed control should be enabled first [28512.086404] manual fan speed control should be enabled first [28525.077255] manual fan speed control should be enabled first [28529.080955] manual fan speed control should be enabled first [28530.070058] manual fan speed control should be enabled first [28839.107591] manual fan speed control should be enabled first [28840.099633] manual fan speed control should be enabled first [28842.083214] manual fan speed control should be enabled first [28890.089742] manual fan speed control should be enabled first [28896.099884] manual fan speed control should be enabled first [28902.081972] manual fan speed control should be enabled first [28909.093220] manual fan speed control should be enabled first [28927.107978] manual fan speed control should be enabled first [28950.085450] manual fan speed control should be enabled first [28979.116690] manual fan speed control should be enabled first [28982.086568] manual fan speed control should be enabled first [29004.103327] manual fan speed control should be enabled first [29040.104962] manual fan speed control should be enabled first [29066.095979] manual fan speed control should be enabled first [29077.113080] manual fan speed control should be enabled first [29086.091060] manual fan speed control should be enabled first [29096.113497] manual fan speed control should be enabled first [29111.123447] manual fan speed control should be enabled first [29123.117578] manual fan speed control should be enabled first [29126.092675] manual fan speed control should be enabled first [29148.109806] manual fan speed control should be enabled first [29155.119475] manual fan speed control should be enabled first [29168.59] manual fan speed control should be enabled first [29170.094539] manual fan speed control should be enabled first [29187.119961] manual fan speed control should be enabled first [29196.113113] manual fan speed control should be enabled first [29199.119590] manual fan speed control should be enabled first [29211.126157] manual fan speed control should be enabled first [29214.098257] manual fan speed control should be enabled first [29217.107755] manual fan speed control should be enabled first [29229.115177] manual fan speed control should be enabled first [29242.097319] manual fan speed control should be enabled first [29325.114063] manual fan speed control should be enabled first [29333.108686] manual fan speed control should be enabled first [29449.116469] manual fan speed control should be enabled first [29455.132518] manual fan speed control should be enabled first [29471.129284] manual fan speed control should be enabled first [29480.121633] manual fan speed control should be enabled first [29640.125839] manual fan speed control should be enabled first [29981.128248] manual fan speed control should be enabled first [30199.151363] manual fan speed control should be enabled first [30204.143080] manual fan speed control should be enabled first [30211.154484] manual fan speed control should be enabled first [30226.128368] manual fan speed control should be enabled first [30228.145612] manual fan speed control should be enabled first [30236.144778] manual fan speed control should be enabled first [30243.149198] manual fan speed control should be enabled first [30245.134568] manual fan speed control should be enabled first [30248.140668] manual fan speed control should be enabled first [30362.126900] manual fan speed control should be enabled first [30909.144940] manual fan speed control should be enabled first [30910.137533] manual fan speed control should be enabled first [30920.163730] manual fan speed control should be enabled first [30931.161975] manual fan speed control should be enabled first [30932.158340] manual fan speed control should be enabled first [30933.147783] manual fan speed control should be enabled first [30944.159956] manual fan speed control should be enabled first [30958.138767] manual fan speed control should be enabled first [30977.151665] manual fan speed control should be enabled first [30996.157518] manual fan speed control should be enabled first [31025.147100] manual fan speed control should be enabled first [31029.149391] manual fan speed control should be enabled first [31030.148760] manual fan speed control should be enabled first and the echo 0 > /sys/class/drm/card1/device/hwmon/hwmon1/pwm1_enable to 100% only works in low power state as soon as core speeds go up fan speeds drop ... -- You are receiving t
Re: [PATCH v8 04/17] drm/dp_mst: Fill branch->num_ports
On 2019-12-03 9:35 a.m., mikita.lip...@amd.com wrote:
> From: David Francis
>
> This field on drm_dp_mst_branch was never filled
>
> It is initialized to zero when the port is kzallocced.
> When a port is added to the list, increment num_ports,
> and when a port is removed from the list, decrement num_ports.
>
> v2: remember to decrement on port removal
> v3: don't explicitly init to 0
>
> Reviewed-by: Lyude Paul
> Reviewed-by: Harry Wentland
> Signed-off-by: David Francis
> Signed-off-by: Mikita Lipski
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 06aae9b52e8a..d74b767d0fe1 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2129,6 +2129,7 @@ drm_dp_mst_port_add_connector(struct drm_dp_mst_branch
> *mstb,
> build_mst_prop_path(mstb, port->port_num, proppath, sizeof(proppath));
> port->connector = mgr->cbs->add_connector(mgr, port, proppath);
> if (!port->connector) {
> + mstb->num_ports--;
> ret = -ENOMEM;
> goto error;
> }
> @@ -2256,6 +2257,7 @@ drm_dp_mst_handle_link_address_port(struct
> drm_dp_mst_branch *mstb,
> mutex_lock(&mgr->lock);
> drm_dp_mst_topology_get_port(port);
> list_add(&port->next, &mstb->ports);
> + mstb->num_ports++;
> mutex_unlock(&mgr->lock);
> }
>
Did you drop the num_ports-- when we do list_del() by accident?
See https://patchwork.freedesktop.org/patch/325600/
Harry
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm msm-next and fixes
Hey Linus, Rob pointed out I missed his pull request for msm-next, it's been in next for a while outside of my tree so shouldn't cause any unexpected issues, it has some OCMEM support in drivers/soc that is acked by other maintainers as it's outside my tree. Otherwise it's a usual fixes pull, i915, amdgpu, the main ones, with some tegra, omap, mgag200 and one core fix. Dave. drm-next-2019-12-06: drm msm + fixes for 5.5-rc1 msm-next: - OCMEM support for a3xx and a4xx GPUs. - a510 support + display support core: - mst payload deletion fix i915: - uapi alignment fix - fix for power usage regression due to security fixes - change default preemption timeout to 640ms from 100ms - EHL voltage level display fixes - TGL DGL PHY fix - gvt - MI_ATOMIC cmd parser fix, CFL non-priv warning - CI spotted deadlock fix - EHL port D programming fix amdgpu: - VRAM lost fixes on BACO for CI/VI - navi14 DC fixes - misc SR-IOV, gfx10 fixes - XGMI fixes for arcturus - SRIOV fixes amdkfd: - KFD on ppc64le enabled - page table optimisations radeon: - fix for r1xx/2xx register checker. tegra: - displayport regression fixes - DMA API regression fixes mgag200: - fix devices that can't scanout except at 0 addr omap: - fix dma_addr refcounting The following changes since commit acc61b8929365e63a3e8c8c8913177795aa45594: Merge tag 'drm-next-5.5-2019-11-22' of git://people.freedesktop.org/~agd5f/linux into drm-next (2019-11-26 08:40:23 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-next-2019-12-06 for you to fetch changes up to 9c1867d730a6e1dc23dd633392d102860578c047: Merge tag 'drm-intel-next-fixes-2019-12-05' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2019-12-06 13:10:52 +1000) drm msm + fixes for 5.5-rc1 msm-next: - OCMEM support for a3xx and a4xx GPUs. - a510 support + display support core: - mst payload deletion fix i915: - uapi alignment fix - fix for power usage regression due to security fixes - change default preemption timeout to 640ms from 100ms - EHL voltage level display fixes - TGL DGL PHY fix - gvt - MI_ATOMIC cmd parser fix, CFL non-priv warning - CI spotted deadlock fix - EHL port D programming fix amdgpu: - VRAM lost fixes on BACO for CI/VI - navi14 DC fixes - misc SR-IOV, gfx10 fixes - XGMI fixes for arcturus - SRIOV fixes amdkfd: - KFD on ppc64le enabled - page table optimisations radeon: - fix for r1xx/2xx register checker. tegra: - displayport regression fixes - DMA API regression fixes mgag200: - fix devices that can't scanout except at 0 addr omap: - fix dma_addr refcounting Alex Deucher (5): drm/amd/display: add default clocks if not able to fetch them MAINTAINERS: Drop Rex Zhu for amdgpu powerplay drm/amdgpu: flag vram lost on baco reset for VI/CIK drm/amd/display: re-enable wait in pipelock, but add timeout drm/radeon: fix r1xx/r2xx register checker for POT textures AngeloGioacchino Del Regno (6): drm/msm/mdp5: Add optional TBU and TBU_RT clocks dt-bindings: msm/mdp5: Document optional TBU and TBU_RT clocks drm/msm/mdp5: Add configuration for msm8x76 drm/msm/dsi: Add configuration for 28nm PLL on family B drm/msm/dsi: Add configuration for 8x76 drm/msm/adreno: Add support for Adreno 510 GPU Arnd Bergmann (1): drm/msm: include linux/sched/task.h Ben Dooks (2): drm/msm: make a5xx_show and a5xx_gpu_state_put static drm/msm/mdp5: make config variables static Brian Masney (6): dt-bindings: soc: qcom: add On Chip MEMory (OCMEM) bindings dt-bindings: display: msm: gmu: add optional ocmem property soc: qcom: add OCMEM driver drm/msm/gpu: add ocmem init/cleanup functions soc: qcom: ocmem: add missing includes drm/msm/hdmi: silence -EPROBE_DEFER warning Chris Wilson (13): drm/i915/gt: Fixup config ifdeffery for pm_suspend_target_state drm/i915: Wait until the intel_wakeref idle callback is complete drm/i915: Mark up the calling context for intel_wakeref_put() drm/i915/gt: Close race between engine_park and intel_gt_retire_requests drm/i915/gt: Unlock engine-pm after queuing the kernel context switch drm/i915/gt: Mark the execlists->active as the primary volatile access drm/i915/execlists: Fixup cancel_port_requests() drm/i915/gt: Adapt engine_park synchronisation rules for engine_retire drm/i915/gt: Schedule request retirement when timeline idles drm/i915/gt: Make intel_ring_unpin() safe for concurrent pint drm/i915: Default to a more lenient forced preemption timeout drm/i915: Reduce nested prepare_remote_context() to a trylock drm/i915/gem: Take timeline->mutex to walk list-of-requests Corentin Labbe (5): agp: remove unused variable size in agp_generic_create_gatt_table agp: move
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #38 from muncrief (rmuncr...@humanavance.com) ---
(In reply to MasterCATZ from comment #37)
> well its neither of those modules
> I should have looked at the files after I scanned for files containing 104000
>
>
> I can not even force run the cards in performance mode anymore with 100% fan
> speed stuck on
>
> if i could just find the setting to tell amdgpu / hwmon / powerplay what
> temp I call hot this would be solved
Here is a slightly modified version of a fan control script, along with the
service to run it, from the Arch Wiki. I don't know what distribution you use
but hopefully this will at least get you started. Unfortunately it doesn't seem
like the kernel devs are interested in fixing this, so after a long time I just
had to use this kludgey solution.
1. Create a file with the following contents named "amdgpu-fancontrol" in
"/usr/local/bin" and make it executable.
--- Start amdgpu-fancontrol ---
#!/bin/bash
HYSTERESIS=6000 # in mK
SLEEP_INTERVAL=1 # in s
DEBUG=true
# set temps (in degrees C * 1000) and corresponding pwm values in ascending
order and with the same amount of values
TEMPS=( 4 5 65000 75000 8 9 )
PWMS=( 0 100 140 190 200 255 )
# hwmon paths, hardcoded for one amdgpu card, adjust as needed
HWMON=$(ls /sys/class/drm/card0/device/hwmon)
FILE_PWM=$(echo /sys/class/drm/card0/device/hwmon/$HWMON/pwm1)
FILE_FANMODE=$(echo /sys/class/drm/card0/device/hwmon/$HWMON/pwm1_enable)
FILE_TEMP=$(echo /sys/class/drm/card0/device/hwmon/$HWMON/temp1_input)
# might want to use this later
#FILE_TEMP_CRIT=$(echo /sys/class/hwmon/hwmon?/temp1_crit_hyst)
[[ -f "$FILE_PWM" && -f "$FILE_FANMODE" && -f "$FILE_TEMP" ]] || { echo
"invalid hwmon files" ; exit 1; }
# load configuration file if present
[ -f /etc/amdgpu-fancontrol.cfg ] && . /etc/amdgpu-fancontrol.cfg
# check if amount of temps and pwm values match
if [ "${#TEMPS[@]}" -ne "${#PWMS[@]}" ]
then
echo "Amount of temperature and pwm values does not match"
exit 1
fi
# checking for privileges
if [ $UID -ne 0 ]
then
echo "Writing to sysfs requires privileges, relaunch as root"
exit 1
fi
function debug {
if $DEBUG; then
echo $1
fi
}
# set fan mode to max(0), manual(1) or auto(2)
function set_fanmode {
echo "setting fan mode to $1"
echo "$1" > "$FILE_FANMODE"
}
function set_pwm {
NEW_PWM=$1
OLD_PWM=$(cat $FILE_PWM)
echo "current pwm: $OLD_PWM, requested to set pwm to $NEW_PWM"
debug "current pwm: $OLD_PWM, requested to set pwm to $NEW_PWM"
if [ $(cat ${FILE_FANMODE}) -ne 1 ]
then
echo "Fanmode not set to manual."
set_fanmode 1
fi
if [ "$NEW_PWM" -gt "$OLD_PWM" ] || [ -z "$TEMP_AT_LAST_PWM_CHANGE" ] || [
$(($(cat $FILE_TEMP) + HYSTERESIS)) -le "$TEMP_AT_LAST_PWM_CHANGE" ]; then
$DEBUG || echo "current temp: $TEMP"
echo "temp at last change was $TEMP_AT_LAST_PWM_CHANGE"
echo "changing pwm to $NEW_PWM"
echo "$NEW_PWM" > "$FILE_PWM"
TEMP_AT_LAST_PWM_CHANGE=$(cat $FILE_TEMP)
else
debug "not changing pwm, we just did at $TEMP_AT_LAST_PWM_CHANGE, next
change when below $((TEMP_AT_LAST_PWM_CHANGE - HYSTERESIS))"
fi
}
function interpolate_pwm {
i=0
TEMP=$(cat $FILE_TEMP)
debug "current temp: $TEMP"
if [[ $TEMP -le ${TEMPS[0]} ]]; then
# below first point in list, set to min speed
set_pwm "${PWMS[i]}"
return
fi
for i in "${!TEMPS[@]}"; do
if [[ $i -eq $((${#TEMPS[@]}-1)) ]]; then
# hit last point in list, set to max speed
set_pwm "${PWMS[i]}"
return
elif [[ $TEMP -gt ${TEMPS[$i]} ]]; then
continue
fi
# interpolate linearly
LOWERTEMP=${TEMPS[i-1]}
HIGHERTEMP=${TEMPS[i]}
LOWERPWM=${PWMS[i-1]}
HIGHERPWM=${PWMS[i]}
PWM=$(echo "( ( $TEMP - $LOWERTEMP ) * ( $HIGHERPWM - $LOWERPWM ) / (
$HIGHERTEMP - $LOWERTEMP ) ) + $LOWERPWM" | bc)
debug "interpolated pwm value for temperature $TEMP is: $PWM"
set_pwm "$PWM"
return
done
}
function reset_on_fail {
echo "exiting, resetting fan to auto control..."
set_fanmode 2
exit 1
}
# always try to reset fans on exit
trap "reset_on_fail" SIGINT SIGTERM
function run_daemon {
while :; do
interpolate_pwm
debug
sleep $SLEEP_INTERVAL
done
}
# set fan control to manual
set_fanmode 1
# finally start the loop
run_daemon
--- End amdgpu-fancontrol ---
2. Create a file with the following contents named "amdgpu-fancontrol.service"
in /etc/systemd/system.
--- Start amdgpu-fancontrol.service ---
[Unit]
Description=amdgpu-fancontrol
[Service]
Type=simple
ExecStart=/usr/local/bin/amdgpu-fancontrol
[Install]
WantedBy=multi-user.target
--- End amdgpu-fancontrol.service ---
3. Here's how to enable, disable, and get the status of the fan control
service:
sudo systemctl enable amdgpu-fancontrol
sudo systemctl start amdgpu-fancontrol
sudo sy
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #37 from MasterCATZ (masterc...@hotmail.com) --- well its neither of those modules I should have looked at the files after I scanned for files containing 104000 I can not even force run the cards in performance mode anymore with 100% fan speed stuck on if i could just find the setting to tell amdgpu / hwmon / powerplay what temp I call hot this would be solved -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #36 from MasterCATZ (masterc...@hotmail.com) --- after having good fan control for a few weeks 5.4.2-050402-generic is now having a melt down back to trying to run the cards @ (crit = +104000.0°C, hyst = -273.1°C) and this is whats got me stumped , it seems to go auto when it hits high temp ~ 70 then starts dropping the fan speed I can exit a game set a high fan speed it will sit their @ 60 deg for a good 20 mins with ~ 60% , decide to go back into game .. hits 70 .. fan speeds keep dropping until its 20% and blipping 100% @ 95 deg I am very close to going back to liquid cooling ... or connecting the fan to a manual speed controller ( if someone knows of a way I can still have the fan connected dor driver control and monitoring with a manual device override for PWM I am all ears , would it be safe for me to just use a thermostat to just send voltage to the fan ? ie) 2x input power sources my guess base or asic is what its reading now about to hack away at those modules and try again /home/aio/Programs/linux/drivers/gpu/drm/i915/oa/i915_oa_tgl.c /home/aio/Programs/linux/drivers/gpu/drm/amd/include/asic_reg/vce/vce_4_0_default.h /home/aio/Programs/linux/drivers/gpu/drm/nouveau/nvkm/engine/ce/gf100.c /home/aio/Programs/linux/drivers/gpu/drm/nouveau/nvkm/engine/ce/gt215.c /home/aio/Programs/linux/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 7/7] drm/mediatek: apply CMDQ control flow
Hi, Bibby:
On Thu, 2019-12-05 at 17:27 +0800, Bibby Hsieh wrote:
> Unlike other SoCs, MT8183 does not have "shadow"
> registers for performaing an atomic video mode
> set or page flip at vblank/vsync.
>
> The CMDQ (Commend Queue) in MT8183 is used to help
> update all relevant display controller registers
> with critical time limation.
Reviewed-by: CK Hu
>
> Signed-off-by: YT Shen
> Signed-off-by: CK Hu
> Signed-off-by: Philipp Zabel
> Signed-off-by: Bibby Hsieh
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 56 +
> 1 file changed, 49 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 8c6231ed6f55..496dffe962af 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -12,6 +12,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "mtk_drm_drv.h"
> #include "mtk_drm_crtc.h"
> @@ -43,6 +45,9 @@ struct mtk_drm_crtc {
> boolpending_planes;
> boolpending_async_planes;
>
> + struct cmdq_client *cmdq_client;
> + u32 cmdq_event;
> +
> void __iomem*config_regs;
> const struct mtk_mmsys_reg_data *mmsys_reg_data;
> struct mtk_disp_mutex *mutex;
> @@ -234,6 +239,13 @@ struct mtk_ddp_comp *mtk_drm_ddp_comp_for_plane(struct
> drm_crtc *crtc,
> return NULL;
> }
>
> +#ifdef CONFIG_MTK_CMDQ
> +static void ddp_cmdq_cb(struct cmdq_cb_data data)
> +{
> + cmdq_pkt_destroy(data.data);
> +}
> +#endif
> +
> static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
> {
> struct drm_crtc *crtc = &mtk_crtc->base;
> @@ -378,7 +390,8 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
> *mtk_crtc)
> }
> }
>
> -static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> +static void mtk_crtc_ddp_config(struct drm_crtc *crtc,
> + struct cmdq_pkt *cmdq_handle)
> {
> struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
> @@ -394,7 +407,8 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> if (state->pending_config) {
> mtk_ddp_comp_config(comp, state->pending_width,
> state->pending_height,
> - state->pending_vrefresh, 0, NULL);
> + state->pending_vrefresh, 0,
> + cmdq_handle);
>
> state->pending_config = false;
> }
> @@ -414,7 +428,8 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
>
> if (comp)
> mtk_ddp_comp_layer_config(comp, local_layer,
> - plane_state, NULL);
> + plane_state,
> + cmdq_handle);
> plane_state->pending.config = false;
> }
> mtk_crtc->pending_planes = false;
> @@ -435,7 +450,8 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
>
> if (comp)
> mtk_ddp_comp_layer_config(comp, local_layer,
> - plane_state, NULL);
> + plane_state,
> + cmdq_handle);
> plane_state->pending.async_config = false;
> }
> mtk_crtc->pending_async_planes = false;
> @@ -444,6 +460,7 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
>
> static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
> {
> + struct cmdq_pkt *cmdq_handle;
> struct drm_crtc *crtc = &mtk_crtc->base;
> struct mtk_drm_private *priv = crtc->dev->dev_private;
> unsigned int pending_planes = 0, pending_async_planes = 0;
> @@ -472,9 +489,18 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc
> *mtk_crtc)
>
> if (priv->data->shadow_register) {
> mtk_disp_mutex_acquire(mtk_crtc->mutex);
> - mtk_crtc_ddp_config(crtc);
> + mtk_crtc_ddp_config(crtc, NULL);
> mtk_disp_mutex_release(mtk_crtc->mutex);
> }
> +#ifdef CONFIG_MTK_CMDQ
> + if (mtk_crtc->cmdq_client) {
> + cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
> + cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
> + cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
> + mtk_crtc_ddp_config(crtc, cmdq_handle);
> + cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
>
Re: [PATCH v4 6/7] drm/mediatek: support CMDQ interface in ddp component
Hi, Bibby:
On Thu, 2019-12-05 at 17:27 +0800, Bibby Hsieh wrote:
> The CMDQ (Command Queue) in MT8183 is used to help
> update all relevant display controller registers
> with critical time limation.
> This patch add cmdq interface in ddp_comp interface,
> let all ddp_comp interface can support cpu/cmdq function
> at the same time.
Reviewed-by: CK Hu
>
> Signed-off-by: YT Shen
> Signed-off-by: CK Hu
> Signed-off-by: Philipp Zabel
> Signed-off-by: Bibby Hsieh
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 7 +-
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 65 +-
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 43 ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 10 +-
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 132 +++-
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 31 +++--
> 6 files changed, 194 insertions(+), 94 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
> b/drivers/gpu/drm/mediatek/mtk_disp_color.c
> index 59de2a46aa49..6fb0d6983a4a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
>
> #include "mtk_drm_crtc.h"
> #include "mtk_drm_ddp_comp.h"
> @@ -45,12 +46,12 @@ static inline struct mtk_disp_color *comp_to_color(struct
> mtk_ddp_comp *comp)
>
> static void mtk_color_config(struct mtk_ddp_comp *comp, unsigned int w,
>unsigned int h, unsigned int vrefresh,
> - unsigned int bpc)
> + unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> {
> struct mtk_disp_color *color = comp_to_color(comp);
>
> - writel(w, comp->regs + DISP_COLOR_WIDTH(color));
> - writel(h, comp->regs + DISP_COLOR_HEIGHT(color));
> + mtk_ddp_write(cmdq_pkt, w, comp, DISP_COLOR_WIDTH(color));
> + mtk_ddp_write(cmdq_pkt, h, comp, DISP_COLOR_HEIGHT(color));
> }
>
> static void mtk_color_start(struct mtk_ddp_comp *comp)
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 8a32248671c3..649e371dd9b7 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
>
> #include "mtk_drm_crtc.h"
> #include "mtk_drm_ddp_comp.h"
> @@ -125,14 +126,15 @@ static void mtk_ovl_stop(struct mtk_ddp_comp *comp)
>
> static void mtk_ovl_config(struct mtk_ddp_comp *comp, unsigned int w,
> unsigned int h, unsigned int vrefresh,
> -unsigned int bpc)
> +unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> {
> if (w != 0 && h != 0)
> - writel_relaxed(h << 16 | w, comp->regs + DISP_REG_OVL_ROI_SIZE);
> - writel_relaxed(0x0, comp->regs + DISP_REG_OVL_ROI_BGCLR);
> + mtk_ddp_write_relaxed(cmdq_pkt, h << 16 | w, comp,
> + DISP_REG_OVL_ROI_SIZE);
> + mtk_ddp_write_relaxed(cmdq_pkt, 0x0, comp, DISP_REG_OVL_ROI_BGCLR);
>
> - writel(0x1, comp->regs + DISP_REG_OVL_RST);
> - writel(0x0, comp->regs + DISP_REG_OVL_RST);
> + mtk_ddp_write(cmdq_pkt, 0x1, comp, DISP_REG_OVL_RST);
> + mtk_ddp_write(cmdq_pkt, 0x0, comp, DISP_REG_OVL_RST);
> }
>
> static unsigned int mtk_ovl_layer_nr(struct mtk_ddp_comp *comp)
> @@ -176,16 +178,16 @@ static int mtk_ovl_layer_check(struct mtk_ddp_comp
> *comp, unsigned int idx,
> return 0;
> }
>
> -static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp, unsigned int idx)
> +static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp, unsigned int idx,
> + struct cmdq_pkt *cmdq_pkt)
> {
> - unsigned int reg;
> unsigned int gmc_thrshd_l;
> unsigned int gmc_thrshd_h;
> unsigned int gmc_value;
> struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
>
> - writel(0x1, comp->regs + DISP_REG_OVL_RDMA_CTRL(idx));
> -
> + mtk_ddp_write(cmdq_pkt, 0x1, comp,
> + DISP_REG_OVL_RDMA_CTRL(idx));
> gmc_thrshd_l = GMC_THRESHOLD_LOW >>
> (GMC_THRESHOLD_BITS - ovl->data->gmc_bits);
> gmc_thrshd_h = GMC_THRESHOLD_HIGH >>
> @@ -195,22 +197,19 @@ static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp,
> unsigned int idx)
> else
> gmc_value = gmc_thrshd_l | gmc_thrshd_l << 8 |
> gmc_thrshd_h << 16 | gmc_thrshd_h << 24;
> - writel(gmc_value, comp->regs + DISP_REG_OVL_RDMA_GMC(idx));
> -
> - reg = readl(comp->regs + DISP_REG_OVL_SRC_CON);
> - reg = reg | BIT(idx);
> - writel(reg, comp->regs + DISP_REG_OVL_SRC_CON);
> + mtk_ddp_write(cmdq_pkt, gmc_value,
> + comp, DISP_REG_OVL_RDMA_GMC(idx));
> + mtk_ddp_write_mask(cmdq_pkt, BIT(idx), comp,
> +DISP_REG_OVL_SRC_CON, BIT(i
Re: [PATCH v4 4/7] drm/mediatek: disable all the planes in atomic_disable
On Thu, 2019-12-05 at 17:27 +0800, Bibby Hsieh wrote: > Under shadow register case, we do not disable all the plane before > disable all the hardwares. Fix it. Except the 'Fixes' tag, I could add it, Reviewed-by: CK Hu > > Signed-off-by: Bibby Hsieh > --- > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c > index e887a6877bcd..e40c8cf7d74f 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c > @@ -550,6 +550,7 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc > *crtc, > } > mtk_crtc->pending_planes = true; > > + mtk_drm_crtc_hw_config(mtk_crtc); > /* Wait for planes to be disabled */ > drm_crtc_wait_one_vblank(crtc); > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/7] drm/mediatek: update cursors by using async atomic update
Hi, Bibby:
On Thu, 2019-12-05 at 17:27 +0800, Bibby Hsieh wrote:
> Support to async updates of cursors by using the new atomic
> interface for that.
>
Reviewed-by: CK Hu
> Signed-off-by: Bibby Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 98 +++-
> drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 +
> drivers/gpu/drm/mediatek/mtk_drm_plane.c | 47
> drivers/gpu/drm/mediatek/mtk_drm_plane.h | 2 +
> 4 files changed, 128 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 4bc52346093d..e887a6877bcd 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -41,12 +41,16 @@ struct mtk_drm_crtc {
> struct drm_plane*planes;
> unsigned intlayer_nr;
> boolpending_planes;
> + boolpending_async_planes;
>
> void __iomem*config_regs;
> const struct mtk_mmsys_reg_data *mmsys_reg_data;
> struct mtk_disp_mutex *mutex;
> unsigned intddp_comp_nr;
> struct mtk_ddp_comp **ddp_comp;
> +
> + /* lock for display hardware access */
> + struct mutexhw_lock;
> };
>
> struct mtk_crtc_state {
> @@ -415,6 +419,63 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> }
> mtk_crtc->pending_planes = false;
> }
> +
> + if (mtk_crtc->pending_async_planes) {
> + for (i = 0; i < mtk_crtc->layer_nr; i++) {
> + struct drm_plane *plane = &mtk_crtc->planes[i];
> + struct mtk_plane_state *plane_state;
> +
> + plane_state = to_mtk_plane_state(plane->state);
> +
> + if (!plane_state->pending.async_config)
> + continue;
> +
> + comp = mtk_drm_ddp_comp_for_plane(crtc, plane,
> + &local_layer);
> +
> + if (comp)
> + mtk_ddp_comp_layer_config(comp, local_layer,
> + plane_state);
> + plane_state->pending.async_config = false;
> + }
> + mtk_crtc->pending_async_planes = false;
> + }
> +}
> +
> +static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
> +{
> + struct drm_crtc *crtc = &mtk_crtc->base;
> + struct mtk_drm_private *priv = crtc->dev->dev_private;
> + unsigned int pending_planes = 0, pending_async_planes = 0;
> + int i;
> +
> + mutex_lock(&mtk_crtc->hw_lock);
> + for (i = 0; i < mtk_crtc->layer_nr; i++) {
> + struct drm_plane *plane = &mtk_crtc->planes[i];
> + struct mtk_plane_state *plane_state;
> +
> + plane_state = to_mtk_plane_state(plane->state);
> + if (plane_state->pending.dirty) {
> + plane_state->pending.config = true;
> + plane_state->pending.dirty = false;
> + pending_planes |= BIT(i);
> + } else if (plane_state->pending.async_dirty) {
> + plane_state->pending.async_config = true;
> + plane_state->pending.async_dirty = false;
> + pending_async_planes |= BIT(i);
> + }
> + }
> + if (pending_planes)
> + mtk_crtc->pending_planes = true;
> + if (pending_async_planes)
> + mtk_crtc->pending_async_planes = true;
> +
> + if (priv->data->shadow_register) {
> + mtk_disp_mutex_acquire(mtk_crtc->mutex);
> + mtk_crtc_ddp_config(crtc);
> + mtk_disp_mutex_release(mtk_crtc->mutex);
> + }
> + mutex_unlock(&mtk_crtc->hw_lock);
> }
>
> int mtk_drm_crtc_plane_check(struct drm_crtc *crtc, struct drm_plane *plane,
> @@ -429,6 +490,20 @@ int mtk_drm_crtc_plane_check(struct drm_crtc *crtc,
> struct drm_plane *plane,
> return 0;
> }
>
> +void mtk_drm_crtc_async_update(struct drm_crtc *crtc, struct drm_plane
> *plane,
> +struct drm_plane_state *new_state)
> +{
> + struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> + const struct drm_plane_helper_funcs *plane_helper_funcs =
> + plane->helper_private;
> +
> + if (!mtk_crtc->enabled)
> + return;
> +
> + plane_helper_funcs->atomic_update(plane, new_state);
> + mtk_drm_crtc_hw_config(mtk_crtc);
> +}
> +
> static void mtk_drm_crtc_atomic_enable(struct drm_crtc *crtc,
> struct drm_crtc_state *old_state)
> {
> @@ -510,34 +585,14 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc
> *crtc,
> struct drm_crtc_state *old_crtc_state)
> {
>
Re: FAILED - [PATCH v2 3/3] drm/mgag200: Add workaround for HW that does not support 'startadd'
> On Dec 3, 2019, at 11:30 AM, John Donnelly wrote:
>
>
> Hello Sasha and Thomas ,
>
>
> This particular patch has failed on one class of servers that has a slightly
> different Sun Vendor. ID for the BMC video device:
>
> I will follow up with additional details in the review comments for the
> original message,.
>
>
>
>
>> On Nov 28, 2019, at 8:23 AM, Sasha Levin wrote:
>>
>> Hi,
>>
>> [This is an automated email]
>>
>> This commit has been processed because it contains a "Fixes:" tag,
>> fixing commit: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system()
>> with kunmap + unpin").
>>
>> The bot has tested the following trees: v5.3.13.
>>
>> v5.3.13: Build failed! Errors:
>> drivers/gpu/drm/mgag200/mgag200_drv.c:104:18: error:
>> ‘drm_vram_mm_debugfs_init’ undeclared here (not in a function); did you mean
>> ‘drm_client_debugfs_init’?
>>
I had this same issue and removed that from my local 5.4.0-rc8 build
>>
>> NOTE: The patch will not be queued to stable trees until it is upstream.
>>
>> How should we proceed with this patch?
>>
>> --
>> Thanks,
>> Sasha
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc&m=vxMDOLV77rRe2ekdNFH9IxMSBQrTccltZd8A1H6xYCc&s=efHs2lc_RQYvzLC82c-D3wa8MpX5DCU_YsIo6XruAQg&e=
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 01/17] drm/dp_mst: Add PBN calculation for DSC modes
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on next-20191203]
[cannot apply to drm-intel/for-linux-next linus/master v5.4-rc8
drm-exynos/exynos-drm-next v5.4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/mikita-lipski-amd-com/DSC-MST-support-for-DRM-and-AMDGPU/20191204-020604
base:1ab75b2e415a29dba9aec94f203c6f88dbfc0ba0
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-91-g817270f-dirty
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c:28:43: sparse: sparse:
>> not enough arguments for function drm_dp_calc_pbn_mode
vim +28 drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
7cbce45d624322 Lyude Paul 2019-09-03 13
7cbce45d624322 Lyude Paul 2019-09-03 14 int igt_dp_mst_calc_pbn_mode(void
*ignored)
7cbce45d624322 Lyude Paul 2019-09-03 15 {
7cbce45d624322 Lyude Paul 2019-09-03 16int pbn, i;
7cbce45d624322 Lyude Paul 2019-09-03 17const struct {
7cbce45d624322 Lyude Paul 2019-09-03 18int rate;
7cbce45d624322 Lyude Paul 2019-09-03 19int bpp;
7cbce45d624322 Lyude Paul 2019-09-03 20int expected;
7cbce45d624322 Lyude Paul 2019-09-03 21} test_params[] = {
7cbce45d624322 Lyude Paul 2019-09-03 22{ 154000, 30, 689 },
7cbce45d624322 Lyude Paul 2019-09-03 23{ 234000, 30, 1047 },
7cbce45d624322 Lyude Paul 2019-09-03 24{ 297000, 24, 1063 },
7cbce45d624322 Lyude Paul 2019-09-03 25};
7cbce45d624322 Lyude Paul 2019-09-03 26
7cbce45d624322 Lyude Paul 2019-09-03 27for (i = 0; i <
ARRAY_SIZE(test_params); i++) {
7cbce45d624322 Lyude Paul 2019-09-03 @28pbn =
drm_dp_calc_pbn_mode(test_params[i].rate,
7cbce45d624322 Lyude Paul 2019-09-03 29
test_params[i].bpp);
7cbce45d624322 Lyude Paul 2019-09-03 30FAIL(pbn !=
test_params[i].expected,
7cbce45d624322 Lyude Paul 2019-09-03 31 "Expected PBN %d
for clock %d bpp %d, got %d\n",
7cbce45d624322 Lyude Paul 2019-09-03 32
test_params[i].expected, test_params[i].rate,
7cbce45d624322 Lyude Paul 2019-09-03 33
test_params[i].bpp, pbn);
7cbce45d624322 Lyude Paul 2019-09-03 34}
7cbce45d624322 Lyude Paul 2019-09-03 35
7cbce45d624322 Lyude Paul 2019-09-03 36return 0;
7cbce45d624322 Lyude Paul 2019-09-03 37 }
2f015ec6eab693 Lyude Paul 2019-09-03 38
:: The code at line 28 was first introduced by commit
:: 7cbce45d6243225914b5c967b4ee927a2327842a drm/dp_mst: Move
test_calc_pbn_mode() into an actual selftest
:: TO: Lyude Paul
:: CC: Lyude Paul
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/8] drm/panfrost: Fix a race in panfrost_ioctl_madvise()
On Fri, Nov 29, 2019 at 8:33 AM Boris Brezillon
wrote:
>
> On Fri, 29 Nov 2019 14:24:48 +
> Steven Price wrote:
>
> > On 29/11/2019 13:59, Boris Brezillon wrote:
> > > If 2 threads change the MADVISE property of the same BO in parallel we
> > > might end up with an shmem->madv value that's inconsistent with the
> > > presence of the BO in the shrinker list.
> >
> > I'm a bit worried from the point of view of user space sanity that you
> > observed this - but clearly the kernel should be robust!
>
> It's not something I observed, just found the race by inspecting the
> code, and I thought it was worth fixing it.
I'm not so sure there's a race. If there is, we still check madv value
when purging, so it would be harmless even if the state is
inconsistent.
> > > The easiest solution to fix that is to protect the
> > > drm_gem_shmem_madvise() call with the shrinker lock.
> > >
> > > Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support")
> > > Cc:
> > > Signed-off-by: Boris Brezillon
> >
> > Reviewed-by: Steven Price
>
> Thanks.
>
> >
> > > ---
> > > drivers/gpu/drm/panfrost/panfrost_drv.c | 9 -
> > > 1 file changed, 4 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> > > b/drivers/gpu/drm/panfrost/panfrost_drv.c
> > > index f21bc8a7ee3a..efc0a24d1f4c 100644
> > > --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> > > +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> > > @@ -347,20 +347,19 @@ static int panfrost_ioctl_madvise(struct drm_device
> > > *dev, void *data,
> > > return -ENOENT;
> > > }
> > >
> > > + mutex_lock(&pfdev->shrinker_lock);
> > > args->retained = drm_gem_shmem_madvise(gem_obj, args->madv);
This means we now hold the shrinker_lock while we take the pages_lock.
Is lockdep happy with this change? I suspect not given all the fun I
had getting lockdep happy.
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] Please pull hmm changes
On 12/2/19 6:42 PM, Jason Gunthorpe wrote: ... > Regarding the ugly names.. Naming has been really hard here because > currently everything is a 'mmu notifier' and the natural abberviations > from there are crummy. Here is the basic summary: > > struct mmu_notifier_mm (ie the mm->mmu_notifier_mm) >-> mmn_mm > struct mm_struct >-> mm > struct mmu_notifier (ie the user subscription to the mm_struct) >-> mn > struct mmu_interval_notifier (the other kind of user subscription) >-> mni > struct mmu_notifier_range (ie the args to invalidate_range) >-> range > > I can send a patch to switch mmn_mm to mmu_notifier_mm, which is the > only pre-existing name for this value. But IIRC, it is a somewhat ugly > with long line wrapping. 'mni' is a pain, I have to reflect on that. > (honesly, I dislike mmu_notififer_mm quite a lot too) > > I think it would be overall nicer with better names for the original > structs. Perhaps: > > mmn_* - MMU notifier prefix > mmn_state <- struct mmu_notifier_mm > mmn_subscription (mmn_sub) <- struct mmu_notifier > mmn_range_subscription (mmn_range_sub) <- struct mmu_interval_notifier > mmn_invalidate_desc <- struct mmu_notifier_range > > At least this is how I describe them in my mind.. This is a lot of > churn, and spreads through many drivers. This is why I kept the names > as-is and we ended up with the also quite bad 'mmu_interval_notifier' > > Maybe just switch mmu_notifier_mm for mmn_state and leave the drivers > alone? > > Anyone on the CC list have advice? > > Jason No advice, just a naming idea similar in spirit to Jerome's suggestion (use a longer descriptive word, and don't try to capture the entire phrase): use "notif" in place of the unloved "mmn". So partially, approximately like this: notif_*<- MMU notifier prefix notif_state<- struct mmu_notifier_mm notif_subscription (notif_sub) <- struct mmu_notifier notif_invalidate_desc <- struct mmu_notifier_range* notif_range_subscription (notif_range_sub) <- struct mmu_interval_notifier thanks, -- John Hubbard NVIDIA ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] drm: call drm_gem_object_funcs.mmap with fake offset
On Thu, Nov 28, 2019 at 12:39:30PM +0100, Gerd Hoffmann wrote:
> On Wed, Nov 27, 2019 at 10:25:22AM +0100, Gerd Hoffmann wrote:
> > The fake offset is going to stay, so change the calling convention for
> > drm_gem_object_funcs.mmap to include the fake offset. Update all users
> > accordingly.
> >
> > Note that this reverts 83b8a6f242ea ("drm/gem: Fix mmap fake offset
> > handling for drm_gem_object_funcs.mmap") and on top then adds the fake
> > offset to drm_gem_prime_mmap to make sure all paths leading to
> > obj->funcs->mmap are consistent.
> >
> > v3: move fake-offset tweak in drm_gem_prime_mmap() so we have this code
> > only once in the function (Rob Herring).
>
> Now this series fails in Intel CI. Can't see why though. The
> difference between v2 and v3 is just the place where vma->vm_pgoff gets
> updated, and no code between the v2 and v3 location touches vma ...
Looks like unrelated flukes, this happens occasionally. If you're paranoid
hit the retest button on patchwork to double-check.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
modeset with DRM_FBDEV_EMULATION after drm client exits
Hello,
I have an i.MX6 (i.e. etnaviv) device here with a legacy qt4 application
that I cannot discuss away (sorry!) that needs framebuffer emulation.
For this machine I wrote a program that is started as pid1, shows a
splash screen using drm, forks to keep the drm device open, and execs
/sbin/init in the parent.
Then the application initializes /dev/fb0 and kills the splash process,
resulting in closing the drm device and the display falls back to show
the content of /dev/fb0.
This fallback however comes with a short flicker because in the kernel
first the drm device is completely closed (by the call of
drm_close_helper(filp);
in drm_release()) and only then the framebuffer takes over (by
drm_lastclose(dev) -> drm_client_dev_restore(dev) also in
drm_release()).
The flickering goes away for me here with the following change:
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index ea34bc991858..567983c1d137 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -440,11 +440,11 @@ int drm_release(struct inode *inode, struct file
*filp)
DRM_DEBUG("open_count = %d\n", dev->open_count);
- drm_close_helper(filp);
-
if (!--dev->open_count)
drm_lastclose(dev);
+ drm_close_helper(filp);
+
mutex_unlock(&drm_global_mutex);
drm_minor_release(minor);
. I wonder if that could be done in general, or if this only works
because my setup is special (so for example the etnaviv driver doesn't
have a lastclose callback and also DRIVER_LEGACY isn't complicating
things for me).
If I'm not mistaken the fbdev emulation is the only driver implementing
a restore handler, so here are not so many options that must be cared
for and tested.
What do you think?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/11] drm/i915: Change toggle_signalling() argument to connector
On Tue, Dec 03, 2019 at 12:36:28PM -0500, Sean Paul wrote:
> From: Sean Paul
>
> HDCP over MST requires us to toggle ddi signalling. Since we'll want to
> toggle signalling on the pipe associated with the fake encoder as
> opposed to the digital port's base, we need to get it from connector.
I think what you want is the cpu_transcoder, which we've already stuffed
into the hdcp thing when we enabled hdcp.
>
> This patch converts all existing callers and implementations to use
> connector instead of digital port.
>
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/i915/display/intel_display_types.h | 2 +-
> drivers/gpu/drm/i915/display/intel_dp.c| 2 +-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 10 --
> drivers/gpu/drm/i915/display/intel_hdmi.c | 8
> 4 files changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 4341bd66a418..bbd44772b9b0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -300,7 +300,7 @@ struct intel_hdcp_shim {
>int i, u32 *part);
>
> /* Enables HDCP signalling on the port */
> - int (*toggle_signalling)(struct intel_digital_port *intel_dig_port,
> + int (*toggle_signalling)(struct intel_connector *connector,
>bool enable);
>
> /* Ensures the link is still protected */
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 7a407c651fb2..e26fb26b1909 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6038,7 +6038,7 @@ int intel_dp_hdcp_read_v_prime_part(struct
> intel_digital_port *intel_dig_port,
> }
>
> static
> -int intel_dp_hdcp_toggle_signalling(struct intel_digital_port
> *intel_dig_port,
> +int intel_dp_hdcp_toggle_signalling(struct intel_connector *connector,
> bool enable)
> {
> /* Not used for single stream DisplayPort setups */
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 8325bf9501e4..0966a8ec47d2 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -693,7 +693,7 @@ static int intel_hdcp_auth(struct intel_connector
> *connector)
> intel_hdcp_get_repeater_ctl(dev_priv, cpu_transcoder,
> port));
>
> - ret = shim->toggle_signalling(intel_dig_port, true);
> + ret = shim->toggle_signalling(connector, true);
> if (ret)
> return ret;
>
> @@ -787,7 +787,7 @@ static int _intel_hdcp_disable(struct intel_connector
> *connector)
> return -ETIMEDOUT;
> }
>
> - ret = hdcp->shim->toggle_signalling(intel_dig_port, false);
> + ret = hdcp->shim->toggle_signalling(connector, false);
> if (ret) {
> DRM_ERROR("Failed to disable HDCP signalling\n");
> return ret;
> @@ -1537,7 +1537,6 @@ static int hdcp2_authenticate_sink(struct
> intel_connector *connector)
>
> static int hdcp2_enable_encryption(struct intel_connector *connector)
> {
> - struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> struct intel_hdcp *hdcp = &connector->hdcp;
> enum port port = connector->encoder->port;
> @@ -1547,7 +1546,7 @@ static int hdcp2_enable_encryption(struct
> intel_connector *connector)
> WARN_ON(I915_READ(HDCP2_STATUS(dev_priv, cpu_transcoder, port)) &
> LINK_ENCRYPTION_STATUS);
> if (hdcp->shim->toggle_signalling) {
> - ret = hdcp->shim->toggle_signalling(intel_dig_port, true);
> + ret = hdcp->shim->toggle_signalling(connector, true);
> if (ret) {
> DRM_ERROR("Failed to enable HDCP signalling. %d\n",
> ret);
> @@ -1575,7 +1574,6 @@ static int hdcp2_enable_encryption(struct
> intel_connector *connector)
>
> static int hdcp2_disable_encryption(struct intel_connector *connector)
> {
> - struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> struct intel_hdcp *hdcp = &connector->hdcp;
> enum port port = connector->encoder->port;
> @@ -1598,7 +1596,7 @@ static int hdcp2_disable_encryption(struct
> intel_connector *connector)
> DRM_DEBUG_KMS("Disable Encryption Timedout");
>
> if (hdcp->shim->toggle_signalling) {
> - ret = hdcp->shim->toggle_signalling(intel_dig_port, false);
> + ret = hdcp->shim->toggle_signalling(connector, false)
Re: [PATCH 04/11] drm/i915: Don't WARN on HDCP toggle if get_hw_state returns false
On Tue, Dec 03, 2019 at 12:36:27PM -0500, Sean Paul wrote:
> From: Sean Paul
>
> Now that we can rely on transcoder disable to toggle signalling off,
> it's less of a catastrophe if get_hw_state() returns false.
>
> Once we enable MST, this will be a valid exit path and we want to make
> sure we're not spamming the logs needlessly.
>
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index e8ac98a8ee7f..ca28913a4c9f 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1983,7 +1983,7 @@ int intel_ddi_toggle_hdcp_signalling(struct
> intel_encoder *intel_encoder,
> if (WARN_ON(!wakeref))
> return -ENXIO;
>
> - if (WARN_ON(!intel_encoder->get_hw_state(intel_encoder, &pipe))) {
> + if (!intel_encoder->get_hw_state(intel_encoder, &pipe)) {
How can this get called when the encoder is not enabled?
Feels like this whole thing is trying to paper over some
bigger bug in the hdcp code.
> ret = -EIO;
> goto out;
> }
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 03/11] drm/i915: Disable HDCP signalling on transcoder disable
On Tue, Dec 03, 2019 at 12:36:26PM -0500, Sean Paul wrote:
> From: Sean Paul
>
> Currently we rely on intel_hdcp_disable() to disable HDCP signalling in
> the DDI Function Control register. This patch adds a safety net by also
> clearing the bit when we disable the transcoder.
>
> Once we have HDCP over MST and disappearing connectors, we want to make
> sure that the signalling is truly disabled even if HDCP teardown doesn't
> go as planned.
Why wouldn't it go as planned?
>
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index b51f244ad7a5..e8ac98a8ee7f 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1952,13 +1952,12 @@ void intel_ddi_disable_transcoder_func(const struct
> intel_crtc_state *crtc_state
> i915_reg_t reg = TRANS_DDI_FUNC_CTL(cpu_transcoder);
> u32 val = I915_READ(reg);
>
> - if (INTEL_GEN(dev_priv) >= 12) {
> - val &= ~(TRANS_DDI_FUNC_ENABLE | TGL_TRANS_DDI_PORT_MASK |
> - TRANS_DDI_DP_VC_PAYLOAD_ALLOC);
> - } else {
> - val &= ~(TRANS_DDI_FUNC_ENABLE | TRANS_DDI_PORT_MASK |
> - TRANS_DDI_DP_VC_PAYLOAD_ALLOC);
> - }
> + val &= ~(TRANS_DDI_FUNC_ENABLE | TRANS_DDI_DP_VC_PAYLOAD_ALLOC |
> + TRANS_DDI_HDCP_SIGNALLING);
> + if (INTEL_GEN(dev_priv) >= 12)
> + val &= ~TGL_TRANS_DDI_PORT_MASK;
> + else
> + val &= ~TRANS_DDI_PORT_MASK;
> I915_WRITE(reg, val);
>
> if (dev_priv->quirks & QUIRK_INCREASE_DDI_DISABLED_TIME &&
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 02/11] drm/i915: Intercept Aksv writes in the aux hooks
On Tue, Dec 03, 2019 at 12:36:25PM -0500, Sean Paul wrote:
> From: Sean Paul
>
> Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
> aux messages and add the aksv flag in the aux transfer hook.
>
> IIRC, this was the original implementation and folks wanted this hack to
> be isolated to the hdcp code, which makes sense.
>
> However in testing an LG monitor on my desk, I noticed it was passing
> back a DEFER reply. This wasn't handled in our hand-rolled code and HDCP
> auth was failing as a result. Instead of copy/pasting all of the retry
> logic and delays from drm dp helpers, let's just use the helpers and hide
> the aksv select as best as we can.
>
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 64 -
> 1 file changed, 31 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d958e789ab96..7a407c651fb2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1515,12 +1515,29 @@ intel_dp_aux_header(u8 txbuf[HEADER_SIZE],
> txbuf[3] = msg->size - 1;
> }
>
> +static u32 intel_dp_aux_generate_xfer_flags(struct drm_dp_aux_msg *msg)
^
const
"_generate_" seems a bit redundant.
> +{
> + if ((msg->request & ~DP_AUX_I2C_MOT) != DP_AUX_NATIVE_WRITE)
> + return 0;
> +
> + /*
> + * If we're trying to send the HDCP Aksv, we need to set a the Aksv
> + * select bit to inform the hardware to send the Aksv after our header
> + * since we can't access that data from software.
> + */
> + if (msg->address == DP_AUX_HDCP_AKSV)
> + return DP_AUX_CH_CTL_AUX_AKSV_SELECT;
if (DP_AUX_NATIVE_WRITE &&
DP_AUX_HDCP_AKSV)
return ...;
would be a little more clear to me since the two things are related here.
> +
> + return 0;
> +}
> +
> static ssize_t
> intel_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
> {
> struct intel_dp *intel_dp = container_of(aux, struct intel_dp, aux);
> u8 txbuf[20], rxbuf[20];
> size_t txsize, rxsize;
> + u32 flags = intel_dp_aux_generate_xfer_flags(msg);
> int ret;
>
> intel_dp_aux_header(txbuf, msg);
> @@ -1541,7 +1558,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
> drm_dp_aux_msg *msg)
> memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
>
> ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
> - rxbuf, rxsize, 0);
> + rxbuf, rxsize, flags);
> if (ret > 0) {
> msg->reply = rxbuf[0] >> 4;
>
> @@ -1564,7 +1581,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
> drm_dp_aux_msg *msg)
> return -E2BIG;
>
> ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
> - rxbuf, rxsize, 0);
> + rxbuf, rxsize, flags);
> if (ret > 0) {
> msg->reply = rxbuf[0] >> 4;
> /*
> @@ -5858,17 +5875,9 @@ static
> int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
> u8 *an)
> {
> - struct intel_dp *intel_dp = enc_to_intel_dp(&intel_dig_port->base.base);
> - static const struct drm_dp_aux_msg msg = {
> - .request = DP_AUX_NATIVE_WRITE,
> - .address = DP_AUX_HDCP_AKSV,
> - .size = DRM_HDCP_KSV_LEN,
> - };
> - u8 txbuf[HEADER_SIZE + DRM_HDCP_KSV_LEN] = {}, rxbuf[2], reply = 0;
> + u8 txbuf[DRM_HDCP_KSV_LEN] = {};
s/txbuf/ksv/ or something maybe?
Looks reasonable to me
Reviewed-by: Ville Syrjälä
> ssize_t dpcd_ret;
> - int ret;
>
> - /* Output An first, that's easy */
> dpcd_ret = drm_dp_dpcd_write(&intel_dig_port->dp.aux, DP_AUX_HDCP_AN,
>an, DRM_HDCP_AN_LEN);
> if (dpcd_ret != DRM_HDCP_AN_LEN) {
> @@ -5878,29 +5887,18 @@ int intel_dp_hdcp_write_an_aksv(struct
> intel_digital_port *intel_dig_port,
> }
>
> /*
> - * Since Aksv is Oh-So-Secret, we can't access it in software. So in
> - * order to get it on the wire, we need to create the AUX header as if
> - * we were writing the data, and then tickle the hardware to output the
> - * data once the header is sent out.
> + * Since Aksv is Oh-So-Secret, we can't access it in software. So we
> + * send an empty buffer of the correct length through the DP helpers. On
> + * the other side, in the transfer hook, we'll generate a flag based on
> + * the destination address which will tickle the hardware to output the
> + * Aksv on our behalf after the header is sent.
>*/
> -
Re: [PATCH v8 12/17] drm/dp_mst: Add branch bandwidth validation to MST atomic check
On 2019-12-03 9:35 a.m., mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> Adding PBN attribute to drm_dp_vcpi_allocation structure to
> keep track of how much bandwidth each Port requires.
> Adding drm_dp_mst_atomic_check_bw_limit to verify that
> state's bandwidth needs doesn't exceed available bandwidth.
> The funtion is called in drm_dp_mst_atomic_check after
> drm_dp_mst_atomic_check_topology_state to fully verify that
> the proposed topology is supported.
>
> Cc: Jerry Zuo
> Cc: Harry Wentland
> Cc: Lyude Paul
> Signed-off-by: Mikita Lipski
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 67 ++-
> include/drm/drm_dp_mst_helper.h | 1 +
> 2 files changed, 66 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 5e549f48ffb8..76bcbb4cd8b4 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4052,7 +4052,7 @@ int drm_dp_atomic_find_vcpi_slots(struct
> drm_atomic_state *state,
> {
> struct drm_dp_mst_topology_state *topology_state;
> struct drm_dp_vcpi_allocation *pos, *vcpi = NULL;
> - int prev_slots, req_slots;
> + int prev_slots, prev_bw, req_slots, ret;
>
'ret' is unused here.
Harry
> topology_state = drm_atomic_get_mst_topology_state(state, mgr);
> if (IS_ERR(topology_state))
> @@ -4063,6 +4063,7 @@ int drm_dp_atomic_find_vcpi_slots(struct
> drm_atomic_state *state,
> if (pos->port == port) {
> vcpi = pos;
> prev_slots = vcpi->vcpi;
> + prev_bw = vcpi->pbn;
>
> /*
>* This should never happen, unless the driver tries
> @@ -4078,8 +4079,10 @@ int drm_dp_atomic_find_vcpi_slots(struct
> drm_atomic_state *state,
> break;
> }
> }
> - if (!vcpi)
> + if (!vcpi) {
> prev_slots = 0;
> + prev_bw = 0;
> + }
>
> if (pbn_div <= 0)
> pbn_div = mgr->pbn_div;
> @@ -4089,6 +4092,9 @@ int drm_dp_atomic_find_vcpi_slots(struct
> drm_atomic_state *state,
> DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] [MST PORT:%p] VCPI %d -> %d\n",
>port->connector->base.id, port->connector->name,
>port, prev_slots, req_slots);
> + DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] [MST PORT:%p] PBN %d -> %d\n",
> + port->connector->base.id, port->connector->name,
> + port, prev_bw, pbn);
>
> /* Add the new allocation to the state */
> if (!vcpi) {
> @@ -4101,6 +4107,7 @@ int drm_dp_atomic_find_vcpi_slots(struct
> drm_atomic_state *state,
> list_add(&vcpi->next, &topology_state->vcpis);
> }
> vcpi->vcpi = req_slots;
> + vcpi->pbn = pbn;
>
> return req_slots;
> }
> @@ -4703,6 +4710,59 @@ static void drm_dp_mst_destroy_state(struct
> drm_private_obj *obj,
> kfree(mst_state);
> }
>
> +static bool drm_dp_mst_port_downstream_of_branch(struct drm_dp_mst_port
> *port,
> + struct drm_dp_mst_branch
> *branch)
> +{
> + while (port->parent) {
> + if (port->parent == branch)
> + return true;
> +
> + if (port->parent->port_parent)
> + port = port->parent->port_parent;
> + else
> + break;
> + }
> + return false;
> +}
> +
> +static inline
> +int drm_dp_mst_atomic_check_bw_limit(struct drm_dp_mst_branch *branch,
> + struct drm_dp_mst_topology_state
> *mst_state)
> +{
> + struct drm_dp_mst_port *port;
> + struct drm_dp_vcpi_allocation *vcpi;
> + int pbn_limit = 0, pbn_used = 0;
> +
> + list_for_each_entry(port, &branch->ports, next) {
> + if (port->mstb) {
> + if (drm_dp_mst_atomic_check_bw_limit(port->mstb,
> mst_state))
> + return -EINVAL;
> + }
> + if (port->available_pbn > 0)
> + pbn_limit = port->available_pbn;
> + }
> + DRM_DEBUG_ATOMIC("[MST BRANCH:%p] branch has %d PBN available\n",
> + branch,
> + pbn_limit);
> +
> + list_for_each_entry(vcpi, &mst_state->vcpis, next) {
> + if (!vcpi->pbn)
> + continue;
> +
> + if (drm_dp_mst_port_downstream_of_branch(vcpi->port, branch))
> + pbn_used += vcpi->pbn;
> + }
> + DRM_DEBUG_ATOMIC("[MST BRANCH:%p] branch used %d PBN\n",
> + branch,
> + pbn_used);
> + if (pbn_used > pbn_limit) {
> + DRM_DEBUG_ATOMIC("[MST BRANCH:%p] No available bandwidth\n",
> + branch);
> + return -EI
Re: [PATCH v3 3/4] drm/mgag200: Add vblank support
On Thu, 5 Dec 2019 at 18:28, Thomas Zimmermann wrote: > >> +/* Interrupt fields */ > >> +#define MGA_VLINEPEN(0x01 << 5) > >> +#define MGA_VLINECLR(0x01 << 5) > >> +#define MGA_VLINEIEN(0x01 << 5) > > Use BIT(5)? > > The bitfield name could be more readable if they included the register > > name. > > Example: > > #define MGA_STATUS_VLINEPEN BIT(5) > > #define MGA_ICLEAR_VLINECLR BIT(5) > > #define MGA_IEN_VLINEIEN BIT(5) > > Oh, good point. I wasn't aware of this macro. > While at it, please keep bitfields close to the respective registers. Don't know much about the driver to review this, for 1&2 Reviewed-by: Emil Velikov I'll look at 4/4 first thing tomorrow. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/dp_mst: Clear all payload id tables downstream when initializing
On Wed, Aug 28, 2019 at 08:09:44PM -0400, Lyude Paul wrote:
> From: Sean Paul
>
> It seems that on certain MST hubs, namely the CableMatters USB-C 2x DP
> hub, using the DP_PAYLOAD_ALLOCATE_SET and DP_PAYLOAD_TABLE_UPDATE_STATUS
> register ranges to clear any pre-existing payload allocations on the hub isn't
> always enough to reset things if the source device has been reset
> unexpectedly.
>
> Or at least, that's the current running theory. The precise behavior appears
> to
> be that when the source device gets reset unexpectedly, the hub begins
> reporting
> an available_pbn value of 0 for all of its ports. This is a bit inconsistent
> with the our theory, since this seems to happen even if previously set PBN
> allocations should have resulted in a non-zero available_pbn value. So, it's
> possible that something else may be going on here.
>
> Strangely though, sending a CLEAR_PAYLOAD_ID_TABLE broadcast request when
> initializing the MST topology seems to bring things into working order and
> make
> available_pbn work again. Since this is a pretty safe solution, let's go ahead
> and implement it.
>
> Changes since v1:
> * Change indenting on drm_dp_send_clear_payload_id_table() prototype
> * Remove some braces in drm_dp_send_clear_payload_id_table()
> * Reorganize some variable declarations in
> drm_dp_send_clear_payload_id_table()
> * Don't forget to handle DP_CLEAR_PAYLOAD_ID_TABLE in
> drm_dp_sideband_parse_reply()
> * Move drm_dp_send_clear_payload_id_table() call into
> drm_dp_mst_link_probe_work(), since we can't send sideband messages
> while under lock in drm_dp_mst_topology_mgr_set_mst()
> * Change commit message
>
> Change-Id: I2c763e8dae3844eca76033a41f264080052fbbfc
> Signed-off-by: Sean Paul
> Signed-off-by: Lyude Paul
Pushed to drm-misc-next without that nasty Change-Id and with danvet's IRC
Acked-by to appease almighty dim.
Thanks, Lyude, for polishing this up :-)
Sean
> ---
>
> A heads up to anyone looking at this patch: it's quite possible this
> won't be the final solution that we go with. Me and Sean would like to
> do a bit more investigation to try to figure out what exactly is
> happening here before we go ahead and push it, and hopefully figure out
> why available_pbn is being set to 0 instead of some other leftover
> non-zero allocation.
>
> drivers/gpu/drm/drm_dp_mst_topology.c | 63 +--
> include/drm/drm_dp_mst_helper.h | 16 +--
> 2 files changed, 72 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 82add736e17d..969e43b7eb4c 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -64,6 +64,11 @@ static int drm_dp_send_dpcd_write(struct
> drm_dp_mst_topology_mgr *mgr,
>
> static void drm_dp_send_link_address(struct drm_dp_mst_topology_mgr *mgr,
>struct drm_dp_mst_branch *mstb);
> +
> +static void
> +drm_dp_send_clear_payload_id_table(struct drm_dp_mst_topology_mgr *mgr,
> +struct drm_dp_mst_branch *mstb);
> +
> static int drm_dp_send_enum_path_resources(struct drm_dp_mst_topology_mgr
> *mgr,
> struct drm_dp_mst_branch *mstb,
> struct drm_dp_mst_port *port);
> @@ -657,6 +662,8 @@ static bool drm_dp_sideband_parse_reply(struct
> drm_dp_sideband_msg_rx *raw,
> case DP_POWER_DOWN_PHY:
> case DP_POWER_UP_PHY:
> return drm_dp_sideband_parse_power_updown_phy_ack(raw, msg);
> + case DP_CLEAR_PAYLOAD_ID_TABLE:
> + return true; /* since there's nothing to parse */
> default:
> DRM_ERROR("Got unknown reply 0x%02x (%s)\n", msg->req_type,
> drm_dp_mst_req_type_str(msg->req_type));
> @@ -755,6 +762,15 @@ static int build_link_address(struct
> drm_dp_sideband_msg_tx *msg)
> return 0;
> }
>
> +static int build_clear_payload_id_table(struct drm_dp_sideband_msg_tx *msg)
> +{
> + struct drm_dp_sideband_msg_req_body req;
> +
> + req.req_type = DP_CLEAR_PAYLOAD_ID_TABLE;
> + drm_dp_encode_sideband_req(&req, msg);
> + return 0;
> +}
> +
> static int build_enum_path_resources(struct drm_dp_sideband_msg_tx *msg, int
> port_num)
> {
> struct drm_dp_sideband_msg_req_body req;
> @@ -1877,8 +1893,12 @@ static void drm_dp_mst_link_probe_work(struct
> work_struct *work)
> struct drm_dp_mst_topology_mgr *mgr = container_of(work, struct
> drm_dp_mst_topology_mgr, work);
> struct drm_dp_mst_branch *mstb;
> int ret;
> + bool clear_payload_id_table;
>
> mutex_lock(&mgr->lock);
> + clear_payload_id_table = !mgr->payload_id_table_cleared;
> + mgr->payload_id_table_cleared = true;
> +
> mstb = mgr->mst_primary;
> if (mstb) {
> ret = drm_dp_mst_topology_try_get_mstb(mstb);
> @@ -1886,10
Re: [PATCH] drm: Rename drm_bridge->dev to drm
Hi Mihail. On Thu, Dec 05, 2019 at 04:30:45PM +, Mihail Atanassov wrote: > The 'dev' name causes some confusion with 'struct device' [1][2], so use > 'drm' instead since this seems to be the prevalent name for 'struct > drm_device' members. Thanks for doing this - it helps readability. checkpatch complained: -:107: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #107: FILE: drivers/gpu/drm/bridge/nxp-ptn3460.c:251: + ret = drm_connector_init(bridge->drm, &ptn_bridge->connector, &ptn3460_connector_funcs, DRM_MODE_CONNECTOR_LVDS); -:133: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #133: FILE: drivers/gpu/drm/bridge/parade-ps8622.c:491: + ret = drm_connector_init(bridge->drm, &ps8622->connector, &ps8622_connector_funcs, DRM_MODE_CONNECTOR_LVDS); But this seems unrelated to your changes - so should be ignored. Browsed the patch and throw it after my build check script. All looked good. Acked-by: Sam Ravnborg Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/4] drm/mgag200: Add vblank support
Hi
Am 05.12.19 um 18:25 schrieb Sam Ravnborg:
> Hi Thomas.
>
> Some nits you can address when applying, if you think they shall be
> addressed.
>
> Sam
>
> On Thu, Dec 05, 2019 at 05:01:41PM +0100, Thomas Zimmermann wrote:
>> There's no VBLANK interrupt on Matrox chipsets. The workaround that is
>> being used here and in other free Matrox drivers is to program
>> to the value of + 1 and enable the VLINE interrupt. This
>> triggers an interrupt at the time when VBLANK begins.
>>
>> VLINE uses separate registers for enabling and clearing pending interrupts.
>> No extra syncihronization between irq handler and the rest of the driver is
> s/syncihronization/synchronization/
Oh.
>
>> required.
>>
>> ((vsyncstart & 0x100) >> 6) |
>> ((vdisplay & 0x100) >> 5) |
>> - ((vdisplay & 0x100) >> 4) | /* linecomp */
>> + ((linecomp & 0x100) >> 4) |
>> ((vtotal & 0x200) >> 4)|
>> ((vdisplay & 0x200) >> 3) |
>> ((vsyncstart & 0x200) >> 2));
>> WREG_CRT(9, ((vdisplay & 0x200) >> 4) |
>> - ((vdisplay & 0x200) >> 3));
>> + ((linecomp & 0x200) >> 3));
>> WREG_CRT(10, 0);
>> WREG_CRT(11, 0);
>> WREG_CRT(12, 0);
>> @@ -1083,7 +1093,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
>> WREG_CRT(21, vdisplay & 0xFF);
>> WREG_CRT(22, (vtotal + 1) & 0xFF);
>> WREG_CRT(23, 0xc3);
>> -WREG_CRT(24, vdisplay & 0xFF);
>> +WREG_CRT(24, linecomp & 0xff);
> Use 0xFF like other code nearby?
The code in this file is a mixture of numbers in upper and lower case. I
used lower case here as I found if more pleasant to read. Hopefully the
other constants can be switched when the code is converted to atomic
modesetting.
>
>>
>> ext_vga[0] = 0;
>> ext_vga[5] = 0;
>> @@ -1099,7 +1109,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
>> ((vdisplay & 0x400) >> 8) |
>> ((vdisplay & 0xc00) >> 7) |
>> ((vsyncstart & 0xc00) >> 5) |
>> -((vdisplay & 0x400) >> 3);
>> +((linecomp & 0x400) >> 3);
>> if (fb->format->cpp[0] * 8 == 24)
>> ext_vga[3] = (((1 << bppshift) * 3) - 1) | 0x80;
>> else
>> @@ -1411,6 +1421,34 @@ static void mga_crtc_disable(struct drm_crtc *crtc)
>> crtc->primary->fb = NULL;
>> }
>>
>> +static int mga_crtc_enable_vblank(struct drm_crtc *crtc)
>> +{
>> +struct drm_device *dev = crtc->dev;
>> +struct mga_device *mdev = dev->dev_private;
>> +u32 iclear, ien;
>> +
>> +iclear = RREG32(MGAREG_ICLEAR);
>> +iclear |= MGA_VLINECLR;
>> +WREG32(MGAREG_ICLEAR, iclear);
>> +
>> +ien = RREG32(MGAREG_IEN);
>> +ien |= MGA_VLINEIEN;
>> +WREG32(MGAREG_IEN, ien);
>> +
>> +return 0;
>> +}
>> +
>> +static void mga_crtc_disable_vblank(struct drm_crtc *crtc)
>> +{
>> +struct drm_device *dev = crtc->dev;
>> +struct mga_device *mdev = dev->dev_private;
>> +u32 ien;
>> +
>> +ien = RREG32(MGAREG_IEN);
>> +ien &= ~(MGA_VLINEIEN);
>> +WREG32(MGAREG_IEN, ien);
>> +}
>> +
>> /* These provide the minimum set of functions required to handle a CRTC */
>> static const struct drm_crtc_funcs mga_crtc_funcs = {
>> .cursor_set = mgag200_crtc_cursor_set,
>> @@ -1418,6 +1456,8 @@ static const struct drm_crtc_funcs mga_crtc_funcs = {
>> .gamma_set = mga_crtc_gamma_set,
>> .set_config = drm_crtc_helper_set_config,
>> .destroy = mga_crtc_destroy,
>> +.enable_vblank = mga_crtc_enable_vblank,
>> +.disable_vblank = mga_crtc_disable_vblank,
>> };
>>
>> static const struct drm_crtc_helper_funcs mga_helper_funcs = {
>> diff --git a/drivers/gpu/drm/mgag200/mgag200_reg.h
>> b/drivers/gpu/drm/mgag200/mgag200_reg.h
>> index 6c460d9a2143..44db1d8279fa 100644
>> --- a/drivers/gpu/drm/mgag200/mgag200_reg.h
>> +++ b/drivers/gpu/drm/mgag200/mgag200_reg.h
>> @@ -122,6 +122,11 @@
>>
>> #define MGAREG_MEMCTL 0x2e08
>>
>> +/* Interrupt fields */
>> +#define MGA_VLINEPEN(0x01 << 5)
>> +#define MGA_VLINECLR(0x01 << 5)
>> +#define MGA_VLINEIEN(0x01 << 5)
> Use BIT(5)?
> The bitfield name could be more readable if they included the register
> name.
> Example:
> #define MGA_STATUS_VLINEPEN BIT(5)
> #define MGA_ICLEAR_VLINECLR BIT(5)
> #define MGA_IEN_VLINEIEN BIT(5)
Oh, good point. I wasn't aware of this macro.
Best regards
Thomas
>
> Sam
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedes
Re: [PATCH] drm: Rename drm_bridge->dev to drm
Hi
Am 05.12.19 um 17:30 schrieb Mihail Atanassov:
> The 'dev' name causes some confusion with 'struct device' [1][2], so use
> 'drm' instead since this seems to be the prevalent name for 'struct
> drm_device' members.
>
> [1] https://patchwork.freedesktop.org/patch/342472/?series=70039&rev=1
> [2] https://patchwork.freedesktop.org/patch/343643/?series=70432&rev=1
I read through the provided links, but can't see why is it called 'drm'.
That sounds like a reference to a DRM driver structure to me.
What about attached_dev or consumer_dev or encoder_dev?
Best regards
Thomas
>
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Signed-off-by: Mihail Atanassov
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 2 +-
> drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 2 +-
> drivers/gpu/drm/bridge/cdns-dsi.c| 2 +-
> drivers/gpu/drm/bridge/dumb-vga-dac.c| 2 +-
> .../gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 2 +-
> drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +-
> drivers/gpu/drm/bridge/panel.c | 2 +-
> drivers/gpu/drm/bridge/parade-ps8622.c | 2 +-
> drivers/gpu/drm/bridge/sii902x.c | 6 +++---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c| 6 +++---
> drivers/gpu/drm/bridge/tc358764.c| 4 ++--
> drivers/gpu/drm/bridge/tc358767.c| 6 +++---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c| 2 +-
> drivers/gpu/drm/bridge/ti-tfp410.c | 6 +++---
> drivers/gpu/drm/drm_bridge.c | 12 ++--
> drivers/gpu/drm/i2c/tda998x_drv.c| 2 +-
> drivers/gpu/drm/mcde/mcde_dsi.c | 2 +-
> drivers/gpu/drm/msm/edp/edp_bridge.c | 2 +-
> drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 4 ++--
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +-
> include/drm/drm_bridge.h | 4 ++--
> 22 files changed, 38 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index 9e13e466e72c..db7d01cb0923 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -863,7 +863,7 @@ static int adv7511_bridge_attach(struct drm_bridge
> *bridge)
> adv->connector.polled = DRM_CONNECTOR_POLL_CONNECT |
> DRM_CONNECTOR_POLL_DISCONNECT;
>
> - ret = drm_connector_init(bridge->dev, &adv->connector,
> + ret = drm_connector_init(bridge->drm, &adv->connector,
>&adv7511_connector_funcs,
>DRM_MODE_CONNECTOR_HDMIA);
> if (ret) {
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index b4f3a923a52a..0e3508aeaa6c 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -541,7 +541,7 @@ static int anx6345_bridge_attach(struct drm_bridge
> *bridge)
> return err;
> }
>
> - err = drm_connector_init(bridge->dev, &anx6345->connector,
> + err = drm_connector_init(bridge->drm, &anx6345->connector,
>&anx6345_connector_funcs,
>DRM_MODE_CONNECTOR_eDP);
> if (err) {
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> index 41867be03751..d5722bc28933 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> @@ -908,7 +908,7 @@ static int anx78xx_bridge_attach(struct drm_bridge
> *bridge)
> return err;
> }
>
> - err = drm_connector_init(bridge->dev, &anx78xx->connector,
> + err = drm_connector_init(bridge->drm, &anx78xx->connector,
>&anx78xx_connector_funcs,
>DRM_MODE_CONNECTOR_DisplayPort);
> if (err) {
> diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
> b/drivers/gpu/drm/bridge/cdns-dsi.c
> index 3a5bd4e7fd1e..f6d7e97de66e 100644
> --- a/drivers/gpu/drm/bridge/cdns-dsi.c
> +++ b/drivers/gpu/drm/bridge/cdns-dsi.c
> @@ -651,7 +651,7 @@ static int cdns_dsi_bridge_attach(struct drm_bridge
> *bridge)
> struct cdns_dsi *dsi = input_to_dsi(input);
> struct cdns_dsi_output *output = &dsi->output;
>
> - if (!drm_core_check_feature(bridge->dev, DRIVER_ATOMIC)) {
> + if (!drm_core_check_feature(bridge->drm, DRIVER_ATOMIC)) {
> dev_err(dsi->base.dev,
> "cdns-dsi driver is only compatible with DRM devices
> supporting atomic updates");
> return -ENO
Re: [PATCH 1/4] dt-bindings: msm:disp: add sc7180 DPU variant
On Mon, 25 Nov 2019 17:29:26 +0530, Kalyan Thota wrote: > Add a compatible string to support sc7180 dpu version. > > Signed-off-by: Kalyan Thota > --- > Documentation/devicetree/bindings/display/msm/dpu.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/4] Rate-limit shadow-FB-to-console-update to screen refresh
Hi Thomas. On Thu, Dec 05, 2019 at 05:01:38PM +0100, Thomas Zimmermann wrote: > A full-screen memcpy() moves the console's shadow buffer to hardware; with > possibly significant runtime overhead. [1] Synchronizing the screen update > with VBLANK events can hopefully reduce the number of screen updates. > > The patchset first adds vblank support to mgag200 as the problem was > initially reported for Matrox hardware. > > The console's dirty worker now waits for the vblank to rate limit the > output frequency. Screen output can pile up while waiting and there's a > chance that multiple screen updates can be handled with a single memcpy(). > Note that this has no effect on tearing: while the dirty worker updates > the hardware buffer, new data can still arrive in the shadow buffer. This > can create a tearing effcet, even though console output is synchronized > to vblank. > > In version 2 of this patchset, fbdev emulation missed the first vblank > event because mgag200 initialized the fbdev console before the irq. > Initializing fbdev last fixes this problem. If other drivers now start > reporting a missed vblank during boot, this might be the reason. > > The patchset was tested by running fbdev emulation and Gnome (X11) on > mgag200 HW. > > v3: > * fbdev: hold helper->mutex > * fbdev: acquire DRM master so other masters cannot interfere > * mgag200: init fbdev after irq avoids missing first vblank > * mgag200: trigger irq at + 1 matches vblank > v2: > * remove locking from fbdev patch > * use constants for mgag200 register names and fields > * double-check that VLINE irq is active on mgag200 > * only signal vblank on CRTC 0 of mgag200 > * coding-style fixes > > [1] https://lists.freedesktop.org/archives/dri-devel/2019-July/228663.html > > Thomas Zimmermann (4): > drm/mgag200: Create fbdev console after registering device > drm/mgag200: Rename constant MGAREG_Status to MGAREG_STATUS > drm/mgag200: Add vblank support > drm/fb-helper: Synchronize dirty worker with vblank Whole series is: Acked-by: Sam Ravnborg The code all looked good, but I am not familiar enough with the code to say I reviewed it all. A few nits in one patch sent in a separate mail. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/4] drm/mgag200: Add vblank support
Hi Thomas.
Some nits you can address when applying, if you think they shall be
addressed.
Sam
On Thu, Dec 05, 2019 at 05:01:41PM +0100, Thomas Zimmermann wrote:
> There's no VBLANK interrupt on Matrox chipsets. The workaround that is
> being used here and in other free Matrox drivers is to program
> to the value of + 1 and enable the VLINE interrupt. This
> triggers an interrupt at the time when VBLANK begins.
>
> VLINE uses separate registers for enabling and clearing pending interrupts.
> No extra syncihronization between irq handler and the rest of the driver is
s/syncihronization/synchronization/
> required.
>
>((vsyncstart & 0x100) >> 6) |
>((vdisplay & 0x100) >> 5) |
> - ((vdisplay & 0x100) >> 4) | /* linecomp */
> + ((linecomp & 0x100) >> 4) |
>((vtotal & 0x200) >> 4)|
>((vdisplay & 0x200) >> 3) |
>((vsyncstart & 0x200) >> 2));
> WREG_CRT(9, ((vdisplay & 0x200) >> 4) |
> - ((vdisplay & 0x200) >> 3));
> + ((linecomp & 0x200) >> 3));
> WREG_CRT(10, 0);
> WREG_CRT(11, 0);
> WREG_CRT(12, 0);
> @@ -1083,7 +1093,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
> WREG_CRT(21, vdisplay & 0xFF);
> WREG_CRT(22, (vtotal + 1) & 0xFF);
> WREG_CRT(23, 0xc3);
> - WREG_CRT(24, vdisplay & 0xFF);
> + WREG_CRT(24, linecomp & 0xff);
Use 0xFF like other code nearby?
>
> ext_vga[0] = 0;
> ext_vga[5] = 0;
> @@ -1099,7 +1109,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
> ((vdisplay & 0x400) >> 8) |
> ((vdisplay & 0xc00) >> 7) |
> ((vsyncstart & 0xc00) >> 5) |
> - ((vdisplay & 0x400) >> 3);
> + ((linecomp & 0x400) >> 3);
> if (fb->format->cpp[0] * 8 == 24)
> ext_vga[3] = (((1 << bppshift) * 3) - 1) | 0x80;
> else
> @@ -1411,6 +1421,34 @@ static void mga_crtc_disable(struct drm_crtc *crtc)
> crtc->primary->fb = NULL;
> }
>
> +static int mga_crtc_enable_vblank(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct mga_device *mdev = dev->dev_private;
> + u32 iclear, ien;
> +
> + iclear = RREG32(MGAREG_ICLEAR);
> + iclear |= MGA_VLINECLR;
> + WREG32(MGAREG_ICLEAR, iclear);
> +
> + ien = RREG32(MGAREG_IEN);
> + ien |= MGA_VLINEIEN;
> + WREG32(MGAREG_IEN, ien);
> +
> + return 0;
> +}
> +
> +static void mga_crtc_disable_vblank(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct mga_device *mdev = dev->dev_private;
> + u32 ien;
> +
> + ien = RREG32(MGAREG_IEN);
> + ien &= ~(MGA_VLINEIEN);
> + WREG32(MGAREG_IEN, ien);
> +}
> +
> /* These provide the minimum set of functions required to handle a CRTC */
> static const struct drm_crtc_funcs mga_crtc_funcs = {
> .cursor_set = mgag200_crtc_cursor_set,
> @@ -1418,6 +1456,8 @@ static const struct drm_crtc_funcs mga_crtc_funcs = {
> .gamma_set = mga_crtc_gamma_set,
> .set_config = drm_crtc_helper_set_config,
> .destroy = mga_crtc_destroy,
> + .enable_vblank = mga_crtc_enable_vblank,
> + .disable_vblank = mga_crtc_disable_vblank,
> };
>
> static const struct drm_crtc_helper_funcs mga_helper_funcs = {
> diff --git a/drivers/gpu/drm/mgag200/mgag200_reg.h
> b/drivers/gpu/drm/mgag200/mgag200_reg.h
> index 6c460d9a2143..44db1d8279fa 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_reg.h
> +++ b/drivers/gpu/drm/mgag200/mgag200_reg.h
> @@ -122,6 +122,11 @@
>
> #define MGAREG_MEMCTL 0x2e08
>
> +/* Interrupt fields */
> +#define MGA_VLINEPEN (0x01 << 5)
> +#define MGA_VLINECLR (0x01 << 5)
> +#define MGA_VLINEIEN (0x01 << 5)
Use BIT(5)?
The bitfield name could be more readable if they included the register
name.
Example:
#define MGA_STATUS_VLINEPEN BIT(5)
#define MGA_ICLEAR_VLINECLR BIT(5)
#define MGA_IEN_VLINEIENBIT(5)
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/atomic: Spell CRTC consistently
Both patches:
Reviewed-by: Thomas Zimmermann
Am 05.12.19 um 17:49 schrieb Thierry Reding:
> From: Thierry Reding
>
> CRTC is an abbreviation and should be all caps in prose. Update all
> kerneldoc comments to use a consistent spelling.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/drm_atomic.c| 20 -
> drivers/gpu/drm/drm_atomic_helper.c | 68 ++---
> drivers/gpu/drm/drm_atomic_uapi.c | 16 +++
> include/drm/drm_atomic.h| 30 ++---
> include/drm/drm_atomic_helper.h | 8 ++--
> 5 files changed, 71 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index ab4508f25986..d33691512a8e 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -251,7 +251,7 @@ EXPORT_SYMBOL(drm_atomic_state_clear);
> * @ref: This atomic state to deallocate
> *
> * This frees all memory associated with an atomic state, including all the
> - * per-object state for planes, crtcs and connectors.
> + * per-object state for planes, CRTCs and connectors.
> */
> void __drm_atomic_state_free(struct kref *ref)
> {
> @@ -272,12 +272,12 @@ void __drm_atomic_state_free(struct kref *ref)
> EXPORT_SYMBOL(__drm_atomic_state_free);
>
> /**
> - * drm_atomic_get_crtc_state - get crtc state
> + * drm_atomic_get_crtc_state - get CRTC state
> * @state: global atomic state object
> - * @crtc: crtc to get state object for
> + * @crtc: CRTC to get state object for
> *
> - * This function returns the crtc state for the given crtc, allocating it if
> - * needed. It will also grab the relevant crtc lock to make sure that the
> state
> + * This function returns the CRTC state for the given CRTC, allocating it if
> + * needed. It will also grab the relevant CRTC lock to make sure that the
> state
> * is consistent.
> *
> * Returns:
> @@ -1018,14 +1018,14 @@ static void drm_atomic_connector_print_state(struct
> drm_printer *p,
> }
>
> /**
> - * drm_atomic_add_affected_connectors - add connectors for crtc
> + * drm_atomic_add_affected_connectors - add connectors for CRTC
> * @state: atomic state
> - * @crtc: DRM crtc
> + * @crtc: DRM CRTC
> *
> * This function walks the current configuration and adds all connectors
> * currently using @crtc to the atomic configuration @state. Note that this
> * function must acquire the connection mutex. This can potentially cause
> - * unneeded seralization if the update is just for the planes on one crtc.
> Hence
> + * unneeded seralization if the update is just for the planes on one CRTC.
> Hence
> * drivers and helpers should only call this when really needed (e.g. when a
> * full modeset needs to happen due to some change).
> *
> @@ -1078,9 +1078,9 @@ drm_atomic_add_affected_connectors(struct
> drm_atomic_state *state,
> EXPORT_SYMBOL(drm_atomic_add_affected_connectors);
>
> /**
> - * drm_atomic_add_affected_planes - add planes for crtc
> + * drm_atomic_add_affected_planes - add planes for CRTC
> * @state: atomic state
> - * @crtc: DRM crtc
> + * @crtc: DRM CRTC
> *
> * This function walks the current configuration and adds all planes
> * currently used by @crtc to the atomic configuration @state. This is useful
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 7bf245aa2d05..c00fcfc2406c 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -150,8 +150,8 @@ static int handle_conflicting_encoders(struct
> drm_atomic_state *state,
>* is not set, an error is returned. Userspace can provide a solution
>* through the atomic ioctl.
>*
> - * If the flag is set conflicting connectors are removed from the crtc
> - * and the crtc is disabled if no encoder is left. This preserves
> + * If the flag is set conflicting connectors are removed from the CRTC
> + * and the CRTC is disabled if no encoder is left. This preserves
>* compatibility with the legacy set_config behavior.
>*/
> drm_connector_list_iter_begin(state->dev, &conn_iter);
> @@ -556,27 +556,27 @@ mode_valid(struct drm_atomic_state *state)
> * @state: the driver state object
> *
> * Check the state object to see if the requested state is physically
> possible.
> - * This does all the crtc and connector related computations for an atomic
> + * This does all the CRTC and connector related computations for an atomic
> * update and adds any additional connectors needed for full modesets. It
> calls
> * the various per-object callbacks in the follow order:
> *
> * 1. &drm_connector_helper_funcs.atomic_best_encoder for determining the
> new encoder.
> * 2. &drm_connector_helper_funcs.atomic_check to validate the connector
> state.
> * 3. If it's determined a modeset is needed then all connectors on the
> affected
> - *crtc are added and &drm_connector_helper_
[PATCH 1/2] drm: add dp helper to initialize remote aux channel.
[why]
We need to minimally initialize the remote aux channel, e.g. the
crc work struct of remote aux to dump the sink's DPRX CRCs in MST
setup.
[how]
Add helper that only initializes the crc work struct of the remote
aux, hooke crc work queue to 'drm_dp_aux_crc_work'. Then call this
helper in DP MST port initialization.
Cc: Leo Li
Cc: Harry Wentland
Signed-off-by: David (Dingchen) Zhang
---
drivers/gpu/drm/drm_dp_helper.c | 13 +
drivers/gpu/drm/drm_dp_mst_topology.c | 3 +++
include/drm/drm_dp_helper.h | 1 +
3 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index fc39323e7d52..37312593dd0a 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1091,6 +1091,19 @@ static void drm_dp_aux_crc_work(struct work_struct *work)
}
}
+/**
+ * drm_dp_remote_aux_init() - minimally initialise a remote aux channel
+ * @aux: DisplayPort AUX channel
+ *
+ * Used for remote aux channel in general. Merely initialize the crc work
+ * struct.
+ */
+void drm_dp_remote_aux_init(struct drm_dp_aux *aux)
+{
+ INIT_WORK(&aux->crc_work, drm_dp_aux_crc_work);
+}
+EXPORT_SYMBOL(drm_dp_remote_aux_init);
+
/**
* drm_dp_aux_init() - minimally initialise an aux channel
* @aux: DisplayPort AUX channel
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index d5df02315e14..4308316fe211 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1642,6 +1642,9 @@ static void drm_dp_add_port(struct drm_dp_mst_branch
*mstb,
port->aux.dev = dev->dev;
port->aux.is_remote = true;
+ /* initialize the MST downstream port's AUX crc work queue */
+ drm_dp_remote_aux_init(&port->aux);
+
/*
* Make sure the memory allocation for our parent branch stays
* around until our own memory allocation is released
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 61ef351c5fca..da0a69f10e38 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1403,6 +1403,7 @@ int drm_dp_downstream_id(struct drm_dp_aux *aux, char
id[6]);
void drm_dp_downstream_debug(struct seq_file *m, const u8
dpcd[DP_RECEIVER_CAP_SIZE],
const u8 port_cap[4], struct drm_dp_aux *aux);
+void drm_dp_remote_aux_init(struct drm_dp_aux *aux);
void drm_dp_aux_init(struct drm_dp_aux *aux);
int drm_dp_aux_register(struct drm_dp_aux *aux);
void drm_dp_aux_unregister(struct drm_dp_aux *aux);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/8] dt-bindings: add img,pvrsgx.yaml for Imagination GPUs
On Sun, Nov 24, 2019 at 12:40:21PM +0100, H. Nikolaus Schaller wrote:
> The Imagination PVR/SGX GPU is part of several SoC from
> multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo
> and others.
>
> With this binding, we describe how the SGX processor is
> interfaced to the SoC (registers, interrupt etc.).
>
> In most cases, Clock, Reset and power management is handled
> by a parent node or elsewhere.
>
> Tested by make dt_binding_check dtbs_check
>
> Signed-off-by: H. Nikolaus Schaller
> ---
> .../devicetree/bindings/gpu/img,pvrsgx.yaml | 83 +++
> 1 file changed, 83 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml
>
> diff --git a/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml
> b/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml
> new file mode 100644
> index ..fe206a53cbe1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml
> @@ -0,0 +1,83 @@
> +# SPDX-License-Identifier: GPL-2.0
Dual license new bindings: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpu/img,pvrsgx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Imagination PVR/SGX GPU
> +
> +maintainers:
> + - H. Nikolaus Schaller
> +
> +description: |+
> + This binding describes the Imagination SGX5 series of 3D accelerators which
> + are found in several different SoC like TI OMAP, Sitara, Ingenic JZ4780,
> + Allwinner A83, and Intel Poulsbo and CedarView and more.
> +
> + For an almost complete list see:
> https://en.wikipedia.org/wiki/PowerVR#Implementations
> +
> + Only the Imagination SGX530, SGX540 and SGX544 GPUs are currently covered
> by
> + this binding but the extension of the pattern is straightforward.
> +
> + The SGX node is usually a child node of some DT node belonging to the SoC
> + which handles clocks, reset and general address space mapping of the SGX
> + register area.
> +
> +properties:
> + compatible:
> +enum:
> +# BeagleBoard ABC, OpenPandora 600MHz
I'd expect compatibles to be per SoC, not per board.
> + - ti,omap3-sgx530-121, img,sgx530-121, img,sgx530, img,sgx5
4 compatibles is probably a bit much. Are there not any version or
feature registers that some of this could be detected? If there are, I'd
assume the middle 2 strings could be dropped. If not, drop the last one
and just match on the 3rd string. It's not a long list.
> +# BeagleBoard XM, GTA04, OpenPandora 1GHz
> + - ti,omap3-sgx530-125, img,sgx530-125, img,sgx530, img,sgx5
> +# BeagleBone Black
> + - ti,am3352-sgx530-125, img,sgx530-125, img,sgx530, img,sgx5
> +# Pandaboard, Pandaboard ES
> + - ti,omap4-sgx540-120, img,sgx540-120, img,sgx540, img,sgx5
> + - ti,omap4-sgx544-112, img,sgx544-112, img,sgx544, img,sgx5
> +# OMAP5 UEVM, Pyra Handheld
> + - ti,omap5-sgx544-116, img,sgx544-116, img,sgx544, img,sgx5
> + - ti,dra7-sgx544-116, img,sgx544-116, img,sgx544, img,sgx5
> +# CI20
> + - ingenic,jz4780-sgx540-120, img,sgx540-120, img,sgx540, img,sgx5
> +# the following entries are not validated with real hardware
> +# more TI
> + - ti,am3517-sgx530-125, img,sgx530-125, img,sgx530, img,sgx5
> + - ti,am4-sgx530-125, img,sgx530-125, img,sgx530, img,sgx5
> + - ti,ti81xx-sgx530-125, img,sgx530-125, img,sgx530, img,sgx5
> +# Banana-Pi-M3 (Allwinner A83T)
> + - allwinner,sun8i-a83t-sgx544-116, img,sgx544-116, img,sgx544, img,sgx5
> +# Atom Z5xx
> + - intel,poulsbo-gma500-sgx535, img,sgx535-116, img,sgx535, img,sgx5
> +# Atom Z24xx
> + - intel,medfield-gma-sgx540, img,sgx540-116, img,sgx540, img,sgx5
> +# Atom N2600, D2500
> + - intel,cedarview-gma3600-sgx545, img,sgx545-116, img,sgx545, img,sgx5
> +
> + reg:
> +maxItems: 1
> +description: physical base address and length of the register area
No need to give a generic description of a standard property.
> +
> + interrupts:
> +maxItems: 1
> +description: interrupt line from SGX subsystem to core processor
Same here.
> +
> + clocks:
> +description: optional clocks
Need to define how many and what they are. Or drop until you know.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
Add:
additionalProperties: false
> +
> +examples:
> + - |+
> +#include
> +
> +gpu@fe00 {
> + compatible = "ti,omap-omap5-sgx544-116", "img,sgx544-116",
> "img,sgx544", "img,sgx5";
> + reg = <0xfe00 0x200>;
> + interrupts = ;
> +};
> +
> +...
> --
> 2.23.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 Michael (lkb...@deegan.id.au) changed: What|Removed |Added CC||lkb...@deegan.id.au --- Comment #35 from Michael (lkb...@deegan.id.au) --- I discovered a workaround that works for my R9-290 and Debian 5.3.0 kernel: root@joyola:~# echo "2" >>/sys/class/drm/card0/device/hwmon/hwmon3/pwm1_enable root@joyola:~# echo "0" >>/sys/class/drm/card0/device/hwmon/hwmon3/pwm1_enable pwm1_enable will still be 2 afterwards, but (after spinning the fans at max for a bit) automatic fan control works for me. I also have to do the same pwm1_enable prodding after resuming from suspend. (If it matters, I boot with radeon.cik_support=0 amdgpu.cik_support=1 radeon.si_support=0 amdgpu.si_support=1 amdgpu.dc_log=1 amdgpu.gpu_recovery=1) I still have the same brokenness as reported in comment 14 though. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/atomic: Spell CRTC consistently
From: Thierry Reding
CRTC is an abbreviation and should be all caps in prose. Update all
kerneldoc comments to use a consistent spelling.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_atomic.c| 20 -
drivers/gpu/drm/drm_atomic_helper.c | 68 ++---
drivers/gpu/drm/drm_atomic_uapi.c | 16 +++
include/drm/drm_atomic.h| 30 ++---
include/drm/drm_atomic_helper.h | 8 ++--
5 files changed, 71 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index ab4508f25986..d33691512a8e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -251,7 +251,7 @@ EXPORT_SYMBOL(drm_atomic_state_clear);
* @ref: This atomic state to deallocate
*
* This frees all memory associated with an atomic state, including all the
- * per-object state for planes, crtcs and connectors.
+ * per-object state for planes, CRTCs and connectors.
*/
void __drm_atomic_state_free(struct kref *ref)
{
@@ -272,12 +272,12 @@ void __drm_atomic_state_free(struct kref *ref)
EXPORT_SYMBOL(__drm_atomic_state_free);
/**
- * drm_atomic_get_crtc_state - get crtc state
+ * drm_atomic_get_crtc_state - get CRTC state
* @state: global atomic state object
- * @crtc: crtc to get state object for
+ * @crtc: CRTC to get state object for
*
- * This function returns the crtc state for the given crtc, allocating it if
- * needed. It will also grab the relevant crtc lock to make sure that the state
+ * This function returns the CRTC state for the given CRTC, allocating it if
+ * needed. It will also grab the relevant CRTC lock to make sure that the state
* is consistent.
*
* Returns:
@@ -1018,14 +1018,14 @@ static void drm_atomic_connector_print_state(struct
drm_printer *p,
}
/**
- * drm_atomic_add_affected_connectors - add connectors for crtc
+ * drm_atomic_add_affected_connectors - add connectors for CRTC
* @state: atomic state
- * @crtc: DRM crtc
+ * @crtc: DRM CRTC
*
* This function walks the current configuration and adds all connectors
* currently using @crtc to the atomic configuration @state. Note that this
* function must acquire the connection mutex. This can potentially cause
- * unneeded seralization if the update is just for the planes on one crtc.
Hence
+ * unneeded seralization if the update is just for the planes on one CRTC.
Hence
* drivers and helpers should only call this when really needed (e.g. when a
* full modeset needs to happen due to some change).
*
@@ -1078,9 +1078,9 @@ drm_atomic_add_affected_connectors(struct
drm_atomic_state *state,
EXPORT_SYMBOL(drm_atomic_add_affected_connectors);
/**
- * drm_atomic_add_affected_planes - add planes for crtc
+ * drm_atomic_add_affected_planes - add planes for CRTC
* @state: atomic state
- * @crtc: DRM crtc
+ * @crtc: DRM CRTC
*
* This function walks the current configuration and adds all planes
* currently used by @crtc to the atomic configuration @state. This is useful
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 7bf245aa2d05..c00fcfc2406c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -150,8 +150,8 @@ static int handle_conflicting_encoders(struct
drm_atomic_state *state,
* is not set, an error is returned. Userspace can provide a solution
* through the atomic ioctl.
*
-* If the flag is set conflicting connectors are removed from the crtc
-* and the crtc is disabled if no encoder is left. This preserves
+* If the flag is set conflicting connectors are removed from the CRTC
+* and the CRTC is disabled if no encoder is left. This preserves
* compatibility with the legacy set_config behavior.
*/
drm_connector_list_iter_begin(state->dev, &conn_iter);
@@ -556,27 +556,27 @@ mode_valid(struct drm_atomic_state *state)
* @state: the driver state object
*
* Check the state object to see if the requested state is physically possible.
- * This does all the crtc and connector related computations for an atomic
+ * This does all the CRTC and connector related computations for an atomic
* update and adds any additional connectors needed for full modesets. It calls
* the various per-object callbacks in the follow order:
*
* 1. &drm_connector_helper_funcs.atomic_best_encoder for determining the new
encoder.
* 2. &drm_connector_helper_funcs.atomic_check to validate the connector state.
* 3. If it's determined a modeset is needed then all connectors on the
affected
- *crtc are added and &drm_connector_helper_funcs.atomic_check is run on
them.
+ *CRTC are added and &drm_connector_helper_funcs.atomic_check is run on
them.
* 4. &drm_encoder_helper_funcs.mode_valid, &drm_bridge_funcs.mode_valid and
*&drm_crtc_helper_funcs.mode_valid are called on the affected components.
* 5. &drm_bridge_funcs.mode_
[PATCH 1/2] drm: Fix a couple of typos, punctation and whitespace issues
From: Thierry Reding
These are just a couple of things that I came across as I was reading
through the code and comments.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_atomic_helper.c | 10 +-
drivers/gpu/drm/drm_edid.c | 2 +-
include/drm/drm_atomic.h| 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 76289fe642f1..7bf245aa2d05 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -220,7 +220,7 @@ set_best_encoder(struct drm_atomic_state *state,
crtc = conn_state->connector->state->crtc;
/* A NULL crtc is an error here because we should have
-* duplicated a NULL best_encoder when crtc was NULL.
+* duplicated a NULL best_encoder when crtc was NULL.
* As an exception restoring duplicated atomic state
* during resume is allowed, so don't warn when
* best_encoder is equal to encoder we intend to set.
@@ -562,7 +562,7 @@ mode_valid(struct drm_atomic_state *state)
*
* 1. &drm_connector_helper_funcs.atomic_best_encoder for determining the new
encoder.
* 2. &drm_connector_helper_funcs.atomic_check to validate the connector state.
- * 3. If it's determined a modeset is needed then all connectors on the
affected crtc
+ * 3. If it's determined a modeset is needed then all connectors on the
affected
*crtc are added and &drm_connector_helper_funcs.atomic_check is run on
them.
* 4. &drm_encoder_helper_funcs.mode_valid, &drm_bridge_funcs.mode_valid and
*&drm_crtc_helper_funcs.mode_valid are called on the affected components.
@@ -1407,7 +1407,7 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_fences);
* @dev: DRM device
* @old_state: atomic state object with old state structures
*
- * Helper to, after atomic commit, wait for vblanks on all effected
+ * Helper to, after atomic commit, wait for vblanks on all affected
* crtcs (ie. before cleaning up old framebuffers using
* drm_atomic_helper_cleanup_planes()). It will only wait on CRTCs where the
* framebuffers have actually changed to optimize for the legacy cursor and
@@ -1467,10 +1467,10 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_vblanks);
* @dev: DRM device
* @old_state: atomic state object with old state structures
*
- * Helper to, after atomic commit, wait for page flips on all effected
+ * Helper to, after atomic commit, wait for page flips on all affected
* crtcs (ie. before cleaning up old framebuffers using
* drm_atomic_helper_cleanup_planes()). Compared to
- * drm_atomic_helper_wait_for_vblanks() this waits for the completion of on all
+ * drm_atomic_helper_wait_for_vblanks() this waits for the completion on all
* CRTCs, assuming that cursors-only updates are signalling their completion
* immediately (or using a different path).
*
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 474ac04d5600..f3d3925bab84 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4573,7 +4573,7 @@ static void drm_parse_hdmi_forum_vsdb(struct
drm_connector *connector,
if (scdc->supported) {
scdc->scrambling.supported = true;
- /* Few sinks support scrambling for cloks < 340M */
+ /* Few sinks support scrambling for clocks < 340M */
if ((hf_vsdb[6] & 0x8))
scdc->scrambling.low_rates = true;
}
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 9115079974b0..1c10e0d667e6 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -35,7 +35,7 @@
* struct drm_crtc_commit - track modeset commits on a CRTC
*
* This structure is used to track pending modeset changes and atomic commit on
- * a per-CRTC basis. Since updating the list should never block this structure
+ * a per-CRTC basis. Since updating the list should never block, this structure
* is reference counted to allow waiters to safely wait on an event to
complete,
* without holding any locks.
*
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Rename drm_bridge->dev to drm
The 'dev' name causes some confusion with 'struct device' [1][2], so use
'drm' instead since this seems to be the prevalent name for 'struct
drm_device' members.
[1] https://patchwork.freedesktop.org/patch/342472/?series=70039&rev=1
[2] https://patchwork.freedesktop.org/patch/343643/?series=70432&rev=1
Cc: Daniel Vetter
Cc: Laurent Pinchart
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 2 +-
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 2 +-
drivers/gpu/drm/bridge/cdns-dsi.c| 2 +-
drivers/gpu/drm/bridge/dumb-vga-dac.c| 2 +-
.../gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 2 +-
drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +-
drivers/gpu/drm/bridge/panel.c | 2 +-
drivers/gpu/drm/bridge/parade-ps8622.c | 2 +-
drivers/gpu/drm/bridge/sii902x.c | 6 +++---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c| 6 +++---
drivers/gpu/drm/bridge/tc358764.c| 4 ++--
drivers/gpu/drm/bridge/tc358767.c| 6 +++---
drivers/gpu/drm/bridge/ti-sn65dsi86.c| 2 +-
drivers/gpu/drm/bridge/ti-tfp410.c | 6 +++---
drivers/gpu/drm/drm_bridge.c | 12 ++--
drivers/gpu/drm/i2c/tda998x_drv.c| 2 +-
drivers/gpu/drm/mcde/mcde_dsi.c | 2 +-
drivers/gpu/drm/msm/edp/edp_bridge.c | 2 +-
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 4 ++--
drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +-
include/drm/drm_bridge.h | 4 ++--
22 files changed, 38 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 9e13e466e72c..db7d01cb0923 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -863,7 +863,7 @@ static int adv7511_bridge_attach(struct drm_bridge *bridge)
adv->connector.polled = DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT;
- ret = drm_connector_init(bridge->dev, &adv->connector,
+ ret = drm_connector_init(bridge->drm, &adv->connector,
&adv7511_connector_funcs,
DRM_MODE_CONNECTOR_HDMIA);
if (ret) {
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
index b4f3a923a52a..0e3508aeaa6c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -541,7 +541,7 @@ static int anx6345_bridge_attach(struct drm_bridge *bridge)
return err;
}
- err = drm_connector_init(bridge->dev, &anx6345->connector,
+ err = drm_connector_init(bridge->drm, &anx6345->connector,
&anx6345_connector_funcs,
DRM_MODE_CONNECTOR_eDP);
if (err) {
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
index 41867be03751..d5722bc28933 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
@@ -908,7 +908,7 @@ static int anx78xx_bridge_attach(struct drm_bridge *bridge)
return err;
}
- err = drm_connector_init(bridge->dev, &anx78xx->connector,
+ err = drm_connector_init(bridge->drm, &anx78xx->connector,
&anx78xx_connector_funcs,
DRM_MODE_CONNECTOR_DisplayPort);
if (err) {
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
b/drivers/gpu/drm/bridge/cdns-dsi.c
index 3a5bd4e7fd1e..f6d7e97de66e 100644
--- a/drivers/gpu/drm/bridge/cdns-dsi.c
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -651,7 +651,7 @@ static int cdns_dsi_bridge_attach(struct drm_bridge *bridge)
struct cdns_dsi *dsi = input_to_dsi(input);
struct cdns_dsi_output *output = &dsi->output;
- if (!drm_core_check_feature(bridge->dev, DRIVER_ATOMIC)) {
+ if (!drm_core_check_feature(bridge->drm, DRIVER_ATOMIC)) {
dev_err(dsi->base.dev,
"cdns-dsi driver is only compatible with DRM devices
supporting atomic updates");
return -ENOTSUPP;
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index cc33dc411b9e..30b5e54df381 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -112,7 +112,7 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
drm_connector_helper_add(&vga->connector,
&dumb_vga_con_helper
Re: [PATCH] drm/doc: Drop :c:func: markup
On Wed, Dec 04, 2019 at 11:19:33AM +0100, Daniel Vetter wrote: > Kernel sphinx has learned how to do that in > > commit d74b0d31dddeac2b44c715588d53d9a1e5b1158e > Author: Jonathan Corbet > Date: Thu Apr 25 07:55:07 2019 -0600 > > Docs: An initial automarkup extension for sphinx > > Unfortunately it hasn't learned that yet for structures, so we're > stuck with the :c:type: noise for now still. > > Cc: Jonathan Corbet > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/drm-internals.rst | 4 +- > Documentation/gpu/drm-kms.rst | 7 ++- > Documentation/gpu/drm-mm.rst| 68 + > 3 files changed, 36 insertions(+), 43 deletions(-) Reviewed-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] Please pull hmm changes
On Tue, Dec 03, 2019 at 02:42:12AM +, Jason Gunthorpe wrote: > On Sat, Nov 30, 2019 at 10:23:31AM -0800, Linus Torvalds wrote: > > On Sat, Nov 30, 2019 at 10:03 AM Linus Torvalds > > wrote: > > > > > > I'll try to figure the code out, but my initial reaction was "yeah, > > > not in my VM". > > > > Why is it ok to sometimes do > > > > WRITE_ONCE(mni->invalidate_seq, cur_seq); > > > > (to pair with the unlocked READ_ONCE), and sometimes then do > > > > mni->invalidate_seq = mmn_mm->invalidate_seq; > > > > My initial guess was that latter is only done at initialization time, > > but at least in one case it's done *after* the mni has been added to > > the mmn_mm (oh, how I despise those names - I can only repeat: WTF?). > > Yes, the only occurrences are in the notifier_insert, under the > spinlock. The one case where it is out of the natural order was to > make the manipulation of seq a bit saner, but in all cases since the > spinlock is held there is no way for another thread to get the pointer > to the 'mmu_interval_notifier *' to do the unlocked read. > > Regarding the ugly names.. Naming has been really hard here because > currently everything is a 'mmu notifier' and the natural abberviations > from there are crummy. Here is the basic summary: > > struct mmu_notifier_mm (ie the mm->mmu_notifier_mm) >-> mmn_mm > struct mm_struct >-> mm > struct mmu_notifier (ie the user subscription to the mm_struct) >-> mn > struct mmu_interval_notifier (the other kind of user subscription) >-> mni What about "interval" the context should already tell people it is related to mmu notifier and thus a notifier. I would just remove the notifier suffix, this would match the below range. > struct mmu_notifier_range (ie the args to invalidate_range) >-> range Yeah range as context should tell you it is related to mmu notifier. > > I can send a patch to switch mmn_mm to mmu_notifier_mm, which is the > only pre-existing name for this value. But IIRC, it is a somewhat ugly > with long line wrapping. 'mni' is a pain, I have to reflect on that. > (honesly, I dislike mmu_notififer_mm quite a lot too) > > I think it would be overall nicer with better names for the original > structs. Perhaps: > > mmn_* - MMU notifier prefix > mmn_state <- struct mmu_notifier_mm > mmn_subscription (mmn_sub) <- struct mmu_notifier > mmn_range_subscription (mmn_range_sub) <- struct mmu_interval_notifier > mmn_invalidate_desc <- struct mmu_notifier_range This looks good. > > At least this is how I describe them in my mind.. This is a lot of > churn, and spreads through many drivers. This is why I kept the names > as-is and we ended up with the also quite bad 'mmu_interval_notifier' > > Maybe just switch mmu_notifier_mm for mmn_state and leave the drivers > alone? > > Anyone on the CC list have advice? Maybe we can do a semantic patch to do convertion and then Linus can easily apply the patch by just re-running the coccinelle. Cheers, Jérôme ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomc: Update docs around locking and commit sequencing
On Wed, Dec 04, 2019 at 11:00:11AM +0100, Daniel Vetter wrote: > Both locking and especially sequencing of nonblocking commits have > evolved a lot. The details are all there, but I noticed that the big > picture and connections have fallen behind a bit. Apply polish. > > Motivated by some review discussions with Thierry. > > Cc: Thierry Reding > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/drm-kms.rst | 11 ++- > drivers/gpu/drm/drm_atomic.c| 10 --- > drivers/gpu/drm/drm_atomic_helper.c | 46 ++--- > include/drm/drm_atomic.h| 13 ++-- > 4 files changed, 56 insertions(+), 24 deletions(-) Hi Daniel, "drm/atomic" in the subject. A couple more minor things I noticed below. > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > index c68588ce4090..b9330343d1bc 100644 > --- a/Documentation/gpu/drm-kms.rst > +++ b/Documentation/gpu/drm-kms.rst > @@ -260,7 +260,8 @@ Taken all together there's two consequences for the > atomic design: >drm_connector_state ` for connectors. These are the > only >objects with userspace-visible and settable state. For internal state > drivers >can subclass these structures through embeddeding, or add entirely new > state > - structures for their globally shared hardware functions. > + structures for their globally shared hardware functions, see > :c:type:`struct > + drm_private_state`. > > - An atomic update is assembled and validated as an entirely free-standing > pile >of structures within the :c:type:`drm_atomic_state ` > @@ -269,6 +270,14 @@ Taken all together there's two consequences for the > atomic design: >to the driver and modeset objects. This way rolling back an update boils > down >to releasing memory and unreferencing objects like framebuffers. > > +Locking of atomic state structures is internally using :c:type:`struct > +drm_modeset_lock `. As a general rule the locking > shouldn't be > +exposed to drivers, instead the right locks should be automatically acquired > by > +any function that duplicates or peeks into a state, like e.g. > +:c:func:`drm_atomic_get_crtc_state()`. Locking only protects the software > data > +structure, ordering of committing state changes to hardware is sequenced > using > +:c:type:`struct drm_crtc_commit `. > + > Read on in this chapter, and also in :ref:`drm_atomic_helper` for more > detailed > coverage of specific topics. > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > index a351a9a39530..5b4787e33f0d 100644 > --- a/drivers/gpu/drm/drm_atomic.c > +++ b/drivers/gpu/drm/drm_atomic.c > @@ -688,10 +688,12 @@ static void drm_atomic_plane_print_state(struct > drm_printer *p, > * associated state struct &drm_private_state. > * > * Similar to userspace-exposed objects, private state structures can be > - * acquired by calling drm_atomic_get_private_obj_state(). Since this > function > - * does not take care of locking, drivers should wrap it for each type of > - * private state object they have with the required call to > drm_modeset_lock() > - * for the corresponding &drm_modeset_lock. > + * acquired by calling drm_atomic_get_private_obj_state(). This also takes > care > + * of locking, hence drivers should not have a need to call > drm_modeset_lock() > + * directly. Sequence of the actual hardware state commit is not handled, > + * drivers might need to keep track of struct drm_crtc_commit within > subclassed > + * structure of &drm_private_state as necessary, e.g. similar to > + * &drm_plane_state.commit. See also &drm_atomic_state.fake_commit. > * > * All private state structures contained in a &drm_atomic_state update can > be > * iterated using for_each_oldnew_private_obj_in_state(), > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c > index 711801b9d4f1..10d62f726b22 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1827,17 +1827,21 @@ EXPORT_SYMBOL(drm_atomic_helper_commit); > /** > * DOC: implementing nonblocking commit > * > - * Nonblocking atomic commits have to be implemented in the following > sequence: > + * Nonblocking atomic commits should use struct &drm_crtc_commit to sequence > + * different operations against each another. Locks, especially struct > + * &drm_modeset_lock, should not be held in worker threads or any other > + * asynchronous context used to commit the hardware state. > * > - * 1. Run drm_atomic_helper_prepare_planes() first. This is the only function > - * which commit needs to call which can fail, so we want to run it first and > + * drm_atomic_helper_commit() implements the recommended sequence for > + * nonblocking commits, using drm_atomic_helper_setup_commit() internally: > + * > + * 1. Run drm_atomic_helper_prepare_planes(). Since this can fail and we > + * need to propagate out of memory/VRAM errors to use
[PATCH v3 0/4] Rate-limit shadow-FB-to-console-update to screen refresh
A full-screen memcpy() moves the console's shadow buffer to hardware; with possibly significant runtime overhead. [1] Synchronizing the screen update with VBLANK events can hopefully reduce the number of screen updates. The patchset first adds vblank support to mgag200 as the problem was initially reported for Matrox hardware. The console's dirty worker now waits for the vblank to rate limit the output frequency. Screen output can pile up while waiting and there's a chance that multiple screen updates can be handled with a single memcpy(). Note that this has no effect on tearing: while the dirty worker updates the hardware buffer, new data can still arrive in the shadow buffer. This can create a tearing effcet, even though console output is synchronized to vblank. In version 2 of this patchset, fbdev emulation missed the first vblank event because mgag200 initialized the fbdev console before the irq. Initializing fbdev last fixes this problem. If other drivers now start reporting a missed vblank during boot, this might be the reason. The patchset was tested by running fbdev emulation and Gnome (X11) on mgag200 HW. v3: * fbdev: hold helper->mutex * fbdev: acquire DRM master so other masters cannot interfere * mgag200: init fbdev after irq avoids missing first vblank * mgag200: trigger irq at + 1 matches vblank v2: * remove locking from fbdev patch * use constants for mgag200 register names and fields * double-check that VLINE irq is active on mgag200 * only signal vblank on CRTC 0 of mgag200 * coding-style fixes [1] https://lists.freedesktop.org/archives/dri-devel/2019-July/228663.html Thomas Zimmermann (4): drm/mgag200: Create fbdev console after registering device drm/mgag200: Rename constant MGAREG_Status to MGAREG_STATUS drm/mgag200: Add vblank support drm/fb-helper: Synchronize dirty worker with vblank drivers/gpu/drm/drm_fb_helper.c| 21 ++ drivers/gpu/drm/mgag200/mgag200_drv.c | 7 drivers/gpu/drm/mgag200/mgag200_drv.h | 1 + drivers/gpu/drm/mgag200/mgag200_main.c | 38 +- drivers/gpu/drm/mgag200/mgag200_mode.c | 54 ++ drivers/gpu/drm/mgag200/mgag200_reg.h | 7 +++- 6 files changed, 119 insertions(+), 9 deletions(-) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/4] drm/mgag200: Rename constant MGAREG_Status to MGAREG_STATUS
Register constants are upper case. Fix MGAREG_Status accordingly.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Gerd Hoffmann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 6 +++---
drivers/gpu/drm/mgag200/mgag200_reg.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 62a8e9ccb16d..9c4440d7b7b4 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -79,12 +79,12 @@ static inline void mga_wait_vsync(struct mga_device *mdev)
unsigned int status = 0;
do {
- status = RREG32(MGAREG_Status);
+ status = RREG32(MGAREG_STATUS);
} while ((status & 0x08) && time_before(jiffies, timeout));
timeout = jiffies + HZ/10;
status = 0;
do {
- status = RREG32(MGAREG_Status);
+ status = RREG32(MGAREG_STATUS);
} while (!(status & 0x08) && time_before(jiffies, timeout));
}
@@ -93,7 +93,7 @@ static inline void mga_wait_busy(struct mga_device *mdev)
unsigned long timeout = jiffies + HZ;
unsigned int status = 0;
do {
- status = RREG8(MGAREG_Status + 2);
+ status = RREG8(MGAREG_STATUS + 2);
} while ((status & 0x01) && time_before(jiffies, timeout));
}
diff --git a/drivers/gpu/drm/mgag200/mgag200_reg.h
b/drivers/gpu/drm/mgag200/mgag200_reg.h
index c096a9d6bcbc..6c460d9a2143 100644
--- a/drivers/gpu/drm/mgag200/mgag200_reg.h
+++ b/drivers/gpu/drm/mgag200/mgag200_reg.h
@@ -101,7 +101,7 @@
#define MGAREG_EXEC0x0100
#defineMGAREG_FIFOSTATUS 0x1e10
-#defineMGAREG_Status 0x1e14
+#defineMGAREG_STATUS 0x1e14
#define MGAREG_CACHEFLUSH 0x1fff
#defineMGAREG_ICLEAR 0x1e18
#defineMGAREG_IEN 0x1e1c
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/4] drm/mgag200: Add vblank support
There's no VBLANK interrupt on Matrox chipsets. The workaround that is
being used here and in other free Matrox drivers is to program
to the value of + 1 and enable the VLINE interrupt. This
triggers an interrupt at the time when VBLANK begins.
VLINE uses separate registers for enabling and clearing pending interrupts.
No extra syncihronization between irq handler and the rest of the driver is
required.
v3:
* set to + 1 to trigger at VBLANK
* expand comment on linecomp
v2:
* only signal vblank on CRTC 0
* use constants for registers and fields
* set VLINECLR before enabling interrupt
* test against STATUS and IEN in irq handler
* coding-style fixes
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 1 +
drivers/gpu/drm/mgag200/mgag200_drv.h | 1 +
drivers/gpu/drm/mgag200/mgag200_main.c | 40 +
drivers/gpu/drm/mgag200/mgag200_mode.c | 48 +++---
drivers/gpu/drm/mgag200/mgag200_reg.h | 5 +++
5 files changed, 91 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index 8e641b29eb01..15cb39c08989 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -133,6 +133,7 @@ int mgag200_driver_dumb_create(struct drm_file *file,
static struct drm_driver driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET,
+ .irq_handler = mgag200_irq_handler,
.fops = &mgag200_driver_fops,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index aa32aad222c2..8af57dfe0d09 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -206,6 +206,7 @@ void mgag200_modeset_fini(struct mga_device *mdev);
/* mgag200_main.c */
int mgag200_driver_load(struct drm_device *dev, unsigned long flags);
void mgag200_driver_unload(struct drm_device *dev);
+irqreturn_t mgag200_irq_handler(int irq, void *arg);
/* mgag200_i2c.c */
struct mga_i2c_chan *mgag200_i2c_create(struct drm_device *dev);
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index b680cf47cbb9..72ebcd015fba 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -12,6 +12,8 @@
#include
#include
+#include
+#include
#include "mgag200_drv.h"
@@ -181,6 +183,14 @@ int mgag200_driver_load(struct drm_device *dev, unsigned
long flags)
dev_warn(&dev->pdev->dev,
"Could not initialize cursors. Not doing hardware
cursors.\n");
+ r = drm_vblank_init(dev, 1);
+ if (r)
+ goto err_modeset;
+
+ r = drm_irq_install(dev, dev->pdev->irq);
+ if (r)
+ goto err_modeset;
+
return 0;
err_modeset:
@@ -199,9 +209,39 @@ void mgag200_driver_unload(struct drm_device *dev)
if (mdev == NULL)
return;
+ drm_irq_uninstall(dev);
mgag200_modeset_fini(mdev);
drm_mode_config_cleanup(dev);
mgag200_cursor_fini(mdev);
mgag200_mm_fini(mdev);
dev->dev_private = NULL;
}
+
+irqreturn_t mgag200_irq_handler(int irq, void *arg)
+{
+ struct drm_device *dev = arg;
+ struct mga_device *mdev = dev->dev_private;
+ struct drm_crtc *crtc;
+ u32 status, ien, iclear;
+
+ status = RREG32(MGAREG_STATUS);
+
+ if (status & MGA_VLINEPEN) {
+ ien = RREG32(MGAREG_IEN);
+ if (!(ien & MGA_VLINEIEN))
+ goto out;
+
+ crtc = drm_crtc_from_index(dev, 0);
+ if (WARN_ON_ONCE(!crtc))
+ goto out;
+ drm_crtc_handle_vblank(crtc);
+
+ iclear = RREG32(MGAREG_ICLEAR);
+ iclear |= MGA_VLINECLR;
+ WREG32(MGAREG_ICLEAR, iclear);
+ return IRQ_HANDLED;
+ }
+
+out:
+ return IRQ_NONE;
+};
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 9c4440d7b7b4..4d0b9e497149 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -905,6 +905,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
const struct drm_framebuffer *fb = crtc->primary->fb;
int hdisplay, hsyncstart, hsyncend, htotal;
int vdisplay, vsyncstart, vsyncend, vtotal;
+ int linecomp;
int pitch;
int option = 0, option2 = 0;
int i;
@@ -1042,6 +1043,15 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
vsyncend = mode->vsync_end - 1;
vtotal = mode->vtotal - 2;
+ /*
+* There's no VBLANK interrupt on Matrox chipsets, so we use
+* the VLIN
[PATCH v3 4/4] drm/fb-helper: Synchronize dirty worker with vblank
Before updating the display from the console's shadow buffer, the dirty
worker now waits for a vblank. This allows several screen updates to pile
up and acts as a rate limiter. If a DRM master is present, it could
interfere with the vblank. Don't wait in this case.
v3:
* add back helper->lock
* acquire DRM master status while waiting for vblank
v2:
* don't hold helper->lock while waiting for vblank
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index fb9bff0f4581..ba20ad92fb90 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -404,8 +404,29 @@ static void drm_fb_helper_dirty_work(struct work_struct
*work)
dirty_work);
struct drm_clip_rect *clip = &helper->dirty_clip;
struct drm_clip_rect clip_copy;
+ struct drm_crtc *crtc;
unsigned long flags;
void *vaddr;
+ int ret;
+
+ /*
+* Rate-limit update frequency to vblank. If there's a DRM master
+* present, it could interfere while we're waiting for the vblank
+* event. Don't wait in this case.
+*/
+ mutex_lock(&helper->lock);
+ if (!drm_master_internal_acquire(helper->dev)) {
+ goto unlock;
+ }
+ crtc = helper->client.modesets[0].crtc;
+ ret = drm_crtc_vblank_get(crtc);
+ if (!ret) {
+ drm_crtc_wait_one_vblank(crtc);
+ drm_crtc_vblank_put(crtc);
+ }
+ drm_master_internal_release(helper->dev);
+unlock:
+ mutex_unlock(&helper->lock);
spin_lock_irqsave(&helper->dirty_lock, flags);
clip_copy = *clip;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] drm/mgag200: Create fbdev console after registering device
Generic fbdev console emulation is a DRM client. For consistency with other clients, it should be created after registering the DRM device. Hence move the fbdev code to the appropriate place. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/mgag200/mgag200_drv.c | 6 ++ drivers/gpu/drm/mgag200/mgag200_main.c | 4 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c b/drivers/gpu/drm/mgag200/mgag200_drv.c index 30b3b827adf8..8e641b29eb01 100644 --- a/drivers/gpu/drm/mgag200/mgag200_drv.c +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c @@ -74,8 +74,14 @@ static int mga_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) if (ret) goto err_mgag200_driver_unload; + ret = drm_fbdev_generic_setup(dev, 0); + if (ret) + goto err_mgag200_driver_unregister; + return 0; +err_mgag200_driver_unregister: + drm_dev_unregister(dev); err_mgag200_driver_unload: mgag200_driver_unload(dev); err_drm_dev_put: diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c b/drivers/gpu/drm/mgag200/mgag200_main.c index e278b6a547bd..b680cf47cbb9 100644 --- a/drivers/gpu/drm/mgag200/mgag200_main.c +++ b/drivers/gpu/drm/mgag200/mgag200_main.c @@ -181,10 +181,6 @@ int mgag200_driver_load(struct drm_device *dev, unsigned long flags) dev_warn(&dev->pdev->dev, "Could not initialize cursors. Not doing hardware cursors.\n"); - r = drm_fbdev_generic_setup(mdev->dev, 0); - if (r) - goto err_modeset; - return 0; err_modeset: -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: Match on dma_buf|fence|resv anywhere
On Wed, Dec 04, 2019 at 10:51:05PM +0100, Daniel Vetter wrote: > I've spent a bit too much time reviewing all kinds of users all over > the kernel for this buffer sharing infrastructure. And some of it is > at least questionable. > > Make sure we at least see when this stuff flies by. > > Acked-by: Dave Airlie > Signed-off-by: Daniel Vetter > Cc: Sumit Semwal > Cc: Mauro Carvalho Chehab > Cc: Greg Kroah-Hartman > Cc: Rob Herring > Cc: linux-me...@vger.kernel.org > Cc: linaro-mm-...@lists.linaro.org > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 4/4] arm64: dts: zynqmp: zcu106-revA: Wire up the DisplayPort subsystem
Hi Michal,
On Fri, Nov 15, 2019 at 09:30:10AM +0100, Michal Simek wrote:
> On 08. 11. 19 18:59, Laurent Pinchart wrote:
> > Enable the dpsub device and wire it up to the PS-GTR PHY lanes routed to
> > the DisplayPort connector.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > .../arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
> > b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
> > index 93ce7eb81498..4656f25b6b04 100644
> > --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
> > +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
> > @@ -13,6 +13,7 @@
> > #include "zynqmp-clk.dtsi"
> > #include
> > #include
> > +#include
> >
> > / {
> > model = "ZynqMP ZCU106 RevA";
> > @@ -69,6 +70,17 @@
> > status = "okay";
> > };
> >
> > +&dpdma {
> > + status = "okay";
> > +};
> > +
> > +&dpsub {
> > + status = "okay";
> > + phy-names = "dp-phy0", "dp-phy1";
> > + phys = <&lane1 PHY_TYPE_DP 0 3 2700>,
> > + <&lane0 PHY_TYPE_DP 1 3 2700>;
>
> It is aligned with stuff in Xilinx tree.
> I think that putting any clock value here is wrong.
> It should really be pointing to &clk whatever it is.
> Then you can support more cases where clock doesn't need to be fixed and
> it is also aligned with clock binding.
OK, I'll check that when working on the PHY driver.
> > +};
> > +
> > /* fpd_dma clk 667MHz, lpd_dma 500MHz */
> > &fpd_dma_chan1 {
> > status = "okay";
> > @@ -503,6 +515,10 @@
> > no-1-8-v;
> > };
> >
> > +&serdes {
> > + status = "okay";
> > +};
> > +
> > &uart0 {
> > status = "okay";
> > };
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 12/28] gpu: drm: bridge: sii9234: Use drm_bridge_init()
Hi Neil, On Thursday, 5 December 2019 12:10:37 GMT Neil Armstrong wrote: > Hi, > > On 04/12/2019 12:48, Mihail Atanassov wrote: > > No functional change. > > > > Why this particular one has "gpu: drm: bridge" unlike the other patches of > the serie ? > I took the "look at the file's git log" approach to determining the prefix. I can change it if you prefer a "drm/bridge: sii9234" prefix instead. > Neil > > > Signed-off-by: Mihail Atanassov > > --- > > drivers/gpu/drm/bridge/sii9234.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/bridge/sii9234.c > > b/drivers/gpu/drm/bridge/sii9234.c > > index f81f81b7051f..bfd3832baa1a 100644 > > --- a/drivers/gpu/drm/bridge/sii9234.c > > +++ b/drivers/gpu/drm/bridge/sii9234.c > > @@ -925,8 +925,7 @@ static int sii9234_probe(struct i2c_client *client, > > > > i2c_set_clientdata(client, ctx); > > > > - ctx->bridge.funcs = &sii9234_bridge_funcs; > > - ctx->bridge.of_node = dev->of_node; > > + drm_bridge_init(&ctx->bridge, dev, &sii9234_bridge_funcs, NULL, NULL); > > drm_bridge_add(&ctx->bridge); > > > > sii9234_cable_in(ctx); > > > > -- Mihail ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/28] drm: Introduce drm_bridge_init()
Hi Laurent,
On Thursday, 5 December 2019 12:40:22 GMT Laurent Pinchart wrote:
> Hi Mihail,
>
> Thank you for the patch.
Thanks for the quick reviews :).
>
> On Wed, Dec 04, 2019 at 11:48:02AM +, Mihail Atanassov wrote:
> > A simple convenience function to initialize the struct drm_bridge. The
> > goal is to standardize initialization for any bridge registered with
> > drm_bridge_add() so that we can later add device links for consumers of
> > those bridges.
> >
> > v2:
> > - s/WARN_ON(!funcs)/WARN_ON(!funcs || !dev)/ as suggested by Daniel
> > - expand on some kerneldoc comments as suggested by Daniel
> > - update commit message as suggested by Daniel
> >
> > Signed-off-by: Mihail Atanassov
> > ---
> > drivers/gpu/drm/drm_bridge.c | 34 +-
> > include/drm/drm_bridge.h | 15 ++-
> > 2 files changed, 47 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index cba537c99e43..50e1c1b46e20 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -64,7 +64,10 @@ static DEFINE_MUTEX(bridge_lock);
> > static LIST_HEAD(bridge_list);
> >
> > /**
> > - * drm_bridge_add - add the given bridge to the global bridge list
> > + * drm_bridge_add - add the given bridge to the global bridge list.
>
> You add a final period here and in the documentation of struct
> drm_bridge, but the new function you're adding doesn't have one :-) I'd
> drop the period here and for drm_bridge to be consistent with the rest
> of the code.
>
> > + *
> > + * Drivers should call drm_bridge_init() prior adding it to the list.
>
> s/should/shall/
> s/prior adding it/prior to adding the bridge/
>
> > + * Drivers should call drm_bridge_remove() to clean up the bridge list.
>
> I'd replace this sentence with "Before deleting a bridge (usually when
> the driver is unbound from the device), drivers shall call
> drm_bridge_remove() to remove it from the global list."
>
> > *
> > * @bridge: bridge control structure
> > */
> > @@ -89,6 +92,35 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> > }
> > EXPORT_SYMBOL(drm_bridge_remove);
> >
> > +/**
> > + * drm_bridge_init - initialise a drm_bridge structure
>
> initialise or initialize ? :-)
I have absolutely no clue :). Judging by the question I'm guessing the
correct answer for the kernel is US spelling.
>
> > + *
> > + * @bridge: bridge control structure
> > + * @funcs: control functions
> > + * @dev: device associated with this drm_bridge
>
> dev goes before funcs
>
> > + * @timings: timing specification for the bridge; optional (may be NULL)
> > + * @driver_private: pointer to the bridge driver internal context (may be
> > NULL)
>
> I'm not too sure about the last two parameters. Having NULL, NULL in
> most callers is confusing, and having a void * as one of the parameters
> means that the compiler won't catch errors if the two parameters are
> reversed. I think this is quite error prone.
>
> There are very few drivers using driver_private (I count 6 of them, with
> 2 additional drivers that set driver_private but never use it). How
> about embedding the bridge structure in those 6 drivers and getting rid
> of the field altogether ? This could be part of a separate series, but
> in any case I'd drop driver_private from drm_bridge_init().
Ok, I'll do that first before refreshing this series.
>
> > + */
> > +void drm_bridge_init(struct drm_bridge *bridge, struct device *dev,
> > +const struct drm_bridge_funcs *funcs,
> > +const struct drm_bridge_timings *timings,
> > +void *driver_private)
> > +{
> > + WARN_ON(!funcs || !dev);
> > +
> > + bridge->dev = NULL;
>
> NULL ? Shouldn't this be dev ?
Hehe, Daniel got caught on that one, too :). This is the drm_device pointer
for the bound consumer, not the struct device that the bridge's lifetime
is tied to. I was planning to rename them with my (eventual) device_links
addition (some discussion around it here:
https://patchwork.freedesktop.org/patch/342472/?series=70039&rev=1).
I guess if I do the drm_device part of the rename first, this patch will
look less confusing, so I'll do that too.
>
> > + bridge->encoder = NULL;
> > + bridge->next = NULL;
> > +
> > +#ifdef CONFIG_OF
> > + bridge->of_node = dev->of_node;
> > +#endif
> > + bridge->timings = timings;
> > + bridge->funcs = funcs;
> > + bridge->driver_private = driver_private;
> > +}
> > +EXPORT_SYMBOL(drm_bridge_init);
> > +
> > /**
> > * drm_bridge_attach - attach the bridge to an encoder's chain
> > *
> > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > index c0a2286a81e9..949e4f401a53 100644
> > --- a/include/drm/drm_bridge.h
> > +++ b/include/drm/drm_bridge.h
> > @@ -373,7 +373,16 @@ struct drm_bridge_timings {
> > };
> >
> > /**
> > - * struct drm_bridge - central DRM bridge control structure
> > + * struct d
Re: [PATCH libdrm v4] modetest: Use floating vrefresh while dumping mode
On Thu, Dec 05, 2019 at 01:16:32PM +, Eric Engestrom wrote: > On Tuesday, 2019-12-03 06:37:36 -0800, Devarsh Thakkar wrote: > > Add function to derive floating value of vertical > > refresh rate from drm mode using pixel clock, > > horizontal total size and vertical total size. > > > > Use this function to find suitable mode having vrefresh > > value which is matching with user provided vrefresh value. > > > > If user doesn't provide any vrefresh value in args then > > update vertical refresh rate value in pipe args using this > > function. > > > > Also use this function for printing floating vrefresh while > > dumping all available modes. > > > > This will give more accurate picture to user for available modes > > differentiated by floating vertical refresh rate and help user > > select more appropriate mode using suitable refresh rate value. > > Any chance you could use the merge requests infra instead of patches on > the mailing list? :) > https://gitlab.freedesktop.org/mesa/drm/merge_requests Yuck. I'll not use that at least. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: INFO: task hung in fb_open
On Thu, Dec 5, 2019 at 2:38 PM syzbot
wrote:
>
> syzbot has bisected this bug to:
>
> commit 979c11ef39cee79d6f556091a357890962be2580
> Author: Ayan Kumar Halder
> Date: Tue Jul 17 17:13:46 2018 +
>
> drm/sun4i: Substitute sun4i_backend_format_is_yuv() with format->is_yuv
Pretty sure your GCD machine is not using the sun4i driver. It's also
very far away from the code that's blowing up. bisect gone wrong?
-Daniel
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15d2f97ee0
> start commit: 596cf45c Merge branch 'akpm' (patches from Andrew)
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13d2f97ee0
> kernel config: https://syzkaller.appspot.com/x/.config?x=7d8ab2e0e09c2a82
> dashboard link: https://syzkaller.appspot.com/bug?extid=a4ae1442ccc637162dc1
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14273edae0
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15e7677ae0
>
> Reported-by: syzbot+a4ae1442ccc637162...@syzkaller.appspotmail.com
> Fixes: 979c11ef39ce ("drm/sun4i: Substitute sun4i_backend_format_is_yuv()
> with format->is_yuv")
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: Switch to full GPIO descriptor
On Thu, 05 Dec 2019, Bartosz Golaszewski wrote: > czw., 5 gru 2019 o 09:11 Linus Walleij napisał(a): > > > > The PWM backlight still supports passing a enable GPIO line as > > platform data using the legacy API. > > > > It turns out that ever board using this mechanism except one > > is pass .enable_gpio = -1. So we drop all these cargo-culted -1's > > from all instances of this platform data in the kernel. > > > > The remaning board, Palm TC, is converted to pass a machine > > descriptior table with the "enable" GPIO instead, and delete the > > platform data entry for enable_gpio and the code handling it > > and things should work smoothly with the new API. > > > > Cc: Krzysztof Kozlowski > > Cc: Robert Jarzmik > > Cc: Guan Xuetao > > Cc: Bartosz Golaszewski > > Signed-off-by: Linus Walleij > > --- > > arch/arm/mach-pxa/cm-x300.c | 1 - > > arch/arm/mach-pxa/colibri-pxa270-income.c | 1 - > > arch/arm/mach-pxa/ezx.c | 1 - > > arch/arm/mach-pxa/hx4700.c| 1 - > > arch/arm/mach-pxa/lpd270.c| 1 - > > arch/arm/mach-pxa/magician.c | 1 - > > arch/arm/mach-pxa/mainstone.c | 1 - > > arch/arm/mach-pxa/mioa701.c | 1 - > > arch/arm/mach-pxa/palm27x.c | 1 - > > arch/arm/mach-pxa/palmtc.c| 10 ++ > > arch/arm/mach-pxa/palmte2.c | 1 - > > arch/arm/mach-pxa/pcm990-baseboard.c | 1 - > > arch/arm/mach-pxa/tavorevb.c | 2 -- > > arch/arm/mach-pxa/viper.c | 1 - > > arch/arm/mach-pxa/z2.c| 2 -- > > arch/arm/mach-pxa/zylonite.c | 1 - > > arch/arm/mach-s3c24xx/mach-h1940.c| 1 - > > arch/arm/mach-s3c24xx/mach-rx1950.c | 1 - > > arch/arm/mach-s3c64xx/dev-backlight.c | 3 --- > > arch/arm/mach-s3c64xx/mach-crag6410.c | 1 - > > arch/arm/mach-s3c64xx/mach-hmt.c | 1 - > > arch/arm/mach-s3c64xx/mach-smartq.c | 1 - > > arch/arm/mach-s3c64xx/mach-smdk6410.c | 2 +- > > arch/unicore32/kernel/puv3-nb0916.c | 1 - > > drivers/video/backlight/pwm_bl.c | 19 --- > > include/linux/pwm_backlight.h | 2 -- > > 26 files changed, 11 insertions(+), 48 deletions(-) > > Reviewed-by: Bartosz Golaszewski Please could you snip your responses. There is a lot of cruft to get through before we find your reply. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 27/28] drm/sti: Use drm_bridge_init()
Le mer. 4 déc. 2019 à 12:48, Mihail Atanassov a écrit : > > No functional change. > > v2: > - Also apply drm_bridge_init() in sti_hdmi.c and sti_hda.c (Sam, >Benjamin) > > Signed-off-by: Mihail Atanassov Reviewed-by: Benjamin Gaignard > --- > drivers/gpu/drm/sti/sti_dvo.c | 4 +--- > drivers/gpu/drm/sti/sti_hda.c | 3 +-- > drivers/gpu/drm/sti/sti_hdmi.c | 3 +-- > 3 files changed, 3 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c > index 68289b0b063a..20a3956b33bc 100644 > --- a/drivers/gpu/drm/sti/sti_dvo.c > +++ b/drivers/gpu/drm/sti/sti_dvo.c > @@ -462,9 +462,7 @@ static int sti_dvo_bind(struct device *dev, struct device > *master, void *data) > if (!bridge) > return -ENOMEM; > > - bridge->driver_private = dvo; > - bridge->funcs = &sti_dvo_bridge_funcs; > - bridge->of_node = dvo->dev.of_node; > + drm_bridge_init(bridge, &dvo->dev, &sti_dvo_bridge_funcs, NULL, dvo); > drm_bridge_add(bridge); > > err = drm_bridge_attach(encoder, bridge, NULL); > diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c > index 8f7bf33815fd..c7296e354a34 100644 > --- a/drivers/gpu/drm/sti/sti_hda.c > +++ b/drivers/gpu/drm/sti/sti_hda.c > @@ -699,8 +699,7 @@ static int sti_hda_bind(struct device *dev, struct device > *master, void *data) > if (!bridge) > return -ENOMEM; > > - bridge->driver_private = hda; > - bridge->funcs = &sti_hda_bridge_funcs; > + drm_bridge_init(bridge, dev, &sti_hda_bridge_funcs, NULL, hda); > drm_bridge_attach(encoder, bridge, NULL); > > connector->encoder = encoder; > diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c > index 814560ead4e1..c9ae3e18fa5d 100644 > --- a/drivers/gpu/drm/sti/sti_hdmi.c > +++ b/drivers/gpu/drm/sti/sti_hdmi.c > @@ -1279,8 +1279,7 @@ static int sti_hdmi_bind(struct device *dev, struct > device *master, void *data) > if (!bridge) > return -EINVAL; > > - bridge->driver_private = hdmi; > - bridge->funcs = &sti_hdmi_bridge_funcs; > + drm_bridge_init(bridge, dev, &sti_hdmi_bridge_funcs, NULL, hdmi); > drm_bridge_attach(encoder, bridge, NULL); > > connector->encoder = encoder; > -- > 2.23.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/28] drm/bridge: Consolidate initialization
Hi Mihail, Thank you for the patches. On Wed, Dec 04, 2019 at 11:48:01AM +, Mihail Atanassov wrote: > Hi all, > > I've dropped the fun parts of this series since they need more work, but > figured drm_bridge_init() as a concept is still valuable on its own (and > I think I'll need it to roll out device links for registered bridges), > so here goes. > > v2: > - expanded commit messages and added some extra bridge-related >documentation (Daniel) > - dropped v1 patches 29 and 30: 29 needs more work, and 30 depends on >it > - added all remaining drm_bridge implementers, found by searching for >drm_bridge_funcs which is mandatory for any bridge; new uses in >patches 3, 27, and 28 (Sam) > - due to the above, I've decided to squash all analogix changes into >one patch For patches 02, 04 to 11 and 13 to 17, 19 to 24, and 27 to 28, Reviewed-by: Laurent Pinchart > --- > v1 [https://patchwork.freedesktop.org/series/70039/] cover text below: > > This series adds device links support to drm_bridge. The motivation > behind it is that a drm_bridge in a module could get removed under the > feet of the bridge user without warning, so we need a way to remove and > reprobe the client as needed to avoid peering into the void. > > 1: Add a drm_bridge_init() function which wraps all initialisation of > the structure prior to calling drm_bridge_add(). > > 2-26,28: Apply the drm_bridge_init() refactor to every bridge that uses > drm_bridge_add(). > > 27: Minor cleanup in rcar-du. > > 29: Add of_drm_find_bridge_devlink() which functions the same as > of_drm_find_bridge() plus adds a device device link from the owning > drm_device to the bridge device. > > 30: As a motivating example, convert komeda to exclusively use > drm_bridge for its pipe outputs; this isn't a regression in usability > any more since device links bring the same automatic remove/reprobe > feature as components. > > Mihail Atanassov (28): > drm: Introduce drm_bridge_init() > drm/bridge: adv7511: Use drm_bridge_init() > drm/bridge/analogix: Use drm_bridge_init() > drm/bridge: cdns: Use drm_bridge_init() > drm/bridge: dumb-vga-dac: Use drm_bridge_init() > drm/bridge: lvds-encoder: Use drm_bridge_init() > drm/bridge: megachips-stdp-ge-b850v3-fw: Use drm_bridge_init() > drm/bridge: nxp-ptn3460: Use drm_bridge_init() > drm/bridge: panel: Use drm_bridge_init() > drm/bridge: ps8622: Use drm_bridge_init() > drm/bridge: sii902x: Use drm_bridge_init() > gpu: drm: bridge: sii9234: Use drm_bridge_init() > drm/bridge: sil_sii8620: Use drm_bridge_init() > drm/bridge: dw-hdmi: Use drm_bridge_init() > drm/bridge/synopsys: dsi: Use drm_bridge_init() > drm/bridge: tc358764: Use drm_bridge_init() > drm/bridge: tc358767: Use drm_bridge_init() > drm/bridge: thc63: Use drm_bridge_init() > drm/bridge: ti-sn65dsi86: Use drm_bridge_init() > drm/bridge: ti-tfp410: Use drm_bridge_init() > drm/exynos: mic: Use drm_bridge_init() > drm/i2c: tda998x: Use drm_bridge_init() > drm/mcde: dsi: Use drm_bridge_init() > drm/mediatek: hdmi: Use drm_bridge_init() > drm: rcar-du: lvds: Use drm_bridge_init() > drm: rcar-du: lvds: Don't set drm_bridge private pointer > drm/sti: Use drm_bridge_init() > drm/msm: Use drm_bridge_init() > > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 5 ++- > .../drm/bridge/analogix/analogix-anx6345.c| 5 ++- > .../drm/bridge/analogix/analogix-anx78xx.c| 8 ++--- > .../drm/bridge/analogix/analogix_dp_core.c| 5 ++- > drivers/gpu/drm/bridge/cdns-dsi.c | 4 +-- > drivers/gpu/drm/bridge/dumb-vga-dac.c | 6 ++-- > drivers/gpu/drm/bridge/lvds-encoder.c | 7 ++-- > .../bridge/megachips-stdp-ge-b850v3-fw.c | 4 +-- > drivers/gpu/drm/bridge/nxp-ptn3460.c | 4 +-- > drivers/gpu/drm/bridge/panel.c| 7 ++-- > drivers/gpu/drm/bridge/parade-ps8622.c| 3 +- > drivers/gpu/drm/bridge/sii902x.c | 5 ++- > drivers/gpu/drm/bridge/sii9234.c | 3 +- > drivers/gpu/drm/bridge/sil-sii8620.c | 3 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 7 ++-- > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 7 ++-- > drivers/gpu/drm/bridge/tc358764.c | 4 +-- > drivers/gpu/drm/bridge/tc358767.c | 3 +- > drivers/gpu/drm/bridge/thc63lvd1024.c | 7 ++-- > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 5 ++- > drivers/gpu/drm/bridge/ti-tfp410.c| 5 ++- > drivers/gpu/drm/drm_bridge.c | 34 ++- > drivers/gpu/drm/exynos/exynos_drm_mic.c | 8 + > drivers/gpu/drm/i2c/tda998x_drv.c | 6 +--- > drivers/gpu/drm/mcde/mcde_dsi.c | 3 +- > drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 +-- > drivers/gpu/drm/msm/dsi/dsi_manager.c | 4 +-- > drivers/gpu/drm/msm/edp/edp_bridge.c | 3 +- > drivers/gpu/drm/msm/hdmi/hdmi_bridge.c| 4 +--
Re: [PATCH v2 18/28] drm/bridge: thc63: Use drm_bridge_init()
Hi Mihail, Thank you for the patch. On Wed, Dec 04, 2019 at 11:48:18AM +, Mihail Atanassov wrote: > No functional change. > > Signed-off-by: Mihail Atanassov > --- > drivers/gpu/drm/bridge/thc63lvd1024.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c > b/drivers/gpu/drm/bridge/thc63lvd1024.c > index 3d74129b2995..abe806db5f4d 100644 > --- a/drivers/gpu/drm/bridge/thc63lvd1024.c > +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c > @@ -218,11 +218,8 @@ static int thc63_probe(struct platform_device *pdev) > if (ret) > return ret; > > - thc63->bridge.driver_private = thc63; > - thc63->bridge.of_node = pdev->dev.of_node; > - thc63->bridge.funcs = &thc63_bridge_func; > - thc63->bridge.timings = &thc63->timings; > - > + drm_bridge_init(&thc63->bridge, &pdev->dev, &thc63_bridge_func, > + &thc63->timings, thc63); I think driver_private is unused, so the last argument can be NULL. > drm_bridge_add(&thc63->bridge); > > return 0; -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/7] drm/udl: Prepare damage handler for simple-pipe KMS
On Wed, 4 Dec 2019 at 13:24, Thomas Zimmermann wrote: > > Udl's damage-handling code requires clean up before switching the driver > to simple-pipe helpers. Patches 1, 2 and 7 remove unused state variables > and statistics. Patches 3 to 5 reorganizes the damage handler to be more > readable. Patch 6 moves dma-buf begin/end calls into the damage handler, > so it will run during page-flip andmodeset operations. > > The patchset has been tested by running fbdev console emulation, X11, and > Weston with a DisplayLink adapter. > > Thomas Zimmermann (7): > drm/udl: Remove unused statistics counters > drm/udl: Don't track number of identical and sent pixels per line > drm/udl: Vmap framebuffer after all tests succeeded in damage handling > drm/udl: Move clip-rectangle code out of udl_handle_damage() > drm/udl: Move log-cpp code out of udl_damage_handler() > drm/udl: Begin/end access to imported buffers in damage-handler > drm/udl: Remove field lost_pixels from struct udl_device > There's a bugfix request in 6/7. Regardless if you squash it in or choose to keep it separate, the series is: Reviewed-by: Emil Velikov Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 25/28] drm: rcar-du: lvds: Use drm_bridge_init()
Hi Mihail, Thank you for the patch. On Wed, Dec 04, 2019 at 11:48:23AM +, Mihail Atanassov wrote: > No functional change. > > Signed-off-by: Mihail Atanassov If you squash this with 26/28, Reviewed-by: Laurent Pinchart > --- > drivers/gpu/drm/rcar-du/rcar_lvds.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c > b/drivers/gpu/drm/rcar-du/rcar_lvds.c > index 8c6c172bbf2e..ac1f29bacfcb 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c > +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c > @@ -881,9 +881,8 @@ static int rcar_lvds_probe(struct platform_device *pdev) > if (ret < 0) > return ret; > > - lvds->bridge.driver_private = lvds; > - lvds->bridge.funcs = &rcar_lvds_bridge_ops; > - lvds->bridge.of_node = pdev->dev.of_node; > + drm_bridge_init(&lvds->bridge, &pdev->dev, &rcar_lvds_bridge_ops, > + NULL, lvds); > > mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); > lvds->mmio = devm_ioremap_resource(&pdev->dev, mem); -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 26/28] drm: rcar-du: lvds: Don't set drm_bridge private pointer
Hi Mihail, Thank you for the patch. On Wed, Dec 04, 2019 at 11:48:24AM +, Mihail Atanassov wrote: > No functional change: it's not used anywhere. > > Signed-off-by: Mihail Atanassov > --- > drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c > b/drivers/gpu/drm/rcar-du/rcar_lvds.c > index ac1f29bacfcb..168a718cbcbd 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c > +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c > @@ -882,7 +882,7 @@ static int rcar_lvds_probe(struct platform_device *pdev) > return ret; > > drm_bridge_init(&lvds->bridge, &pdev->dev, &rcar_lvds_bridge_ops, > - NULL, lvds); > + NULL, NULL); You can squash this with 25/28. > > mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); > lvds->mmio = devm_ioremap_resource(&pdev->dev, mem); -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/28] drm/bridge/analogix: Use drm_bridge_init()
On Wed, Dec 04, 2019 at 11:48:04AM +, Mihail Atanassov wrote:
> No functional change.
>
> The setting of bridge->of_node by drm_bridge_init() in
> analogix_dp_core.c is safe, since ->of_node isn't used directly and the
> bridge isn't published with drm_bridge_add().
Still, it's not the right device, is it ? And if we later extend the
usage of dev in drm_bridge_init() it could cause issues. I think you
should use the right device pointer.
>
> Signed-off-by: Mihail Atanassov
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 5 ++---
> drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 8 ++--
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 5 ++---
> 3 files changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index b4f3a923a52a..130d5c3a07ef 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -696,8 +696,6 @@ static int anx6345_i2c_probe(struct i2c_client *client,
>
> mutex_init(&anx6345->lock);
>
> - anx6345->bridge.of_node = client->dev.of_node;
> -
> anx6345->client = client;
> i2c_set_clientdata(client, anx6345);
>
> @@ -760,7 +758,8 @@ static int anx6345_i2c_probe(struct i2c_client *client,
> /* Look for supported chip ID */
> anx6345_poweron(anx6345);
> if (anx6345_get_chip_id(anx6345)) {
> - anx6345->bridge.funcs = &anx6345_bridge_funcs;
> + drm_bridge_init(&anx6345->bridge, &client->dev,
> + &anx6345_bridge_funcs, NULL, NULL);
> drm_bridge_add(&anx6345->bridge);
>
> return 0;
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> index 41867be03751..e37892cdc9cf 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> @@ -1214,10 +1214,6 @@ static int anx78xx_i2c_probe(struct i2c_client *client,
>
> mutex_init(&anx78xx->lock);
>
> -#if IS_ENABLED(CONFIG_OF)
> - anx78xx->bridge.of_node = client->dev.of_node;
> -#endif
> -
> anx78xx->client = client;
> i2c_set_clientdata(client, anx78xx);
>
> @@ -1321,8 +1317,8 @@ static int anx78xx_i2c_probe(struct i2c_client *client,
> goto err_poweroff;
> }
>
> - anx78xx->bridge.funcs = &anx78xx_bridge_funcs;
> -
> + drm_bridge_init(&anx78xx->bridge, &client->dev, &anx78xx_bridge_funcs,
> + NULL, NULL);
> drm_bridge_add(&anx78xx->bridge);
>
> /* If cable is pulled out, just poweroff and wait for HPD event */
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index bb411fe52ae8..4042ba9a98d8 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1585,9 +1585,8 @@ static int analogix_dp_create_bridge(struct drm_device
> *drm_dev,
>
> dp->bridge = bridge;
>
> - bridge->driver_private = dp;
> - bridge->funcs = &analogix_dp_bridge_funcs;
> -
> + drm_bridge_init(bridge, drm_dev->dev, &analogix_dp_bridge_funcs,
> + NULL, dp);
> ret = drm_bridge_attach(dp->encoder, bridge, NULL);
> if (ret) {
> DRM_ERROR("failed to attach drm bridge\n");
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/7] drm/udl: Begin/end access to imported buffers in damage-handler
On Wed, 4 Dec 2019 at 13:24, Thomas Zimmermann wrote:
>
> The damage-handler code now invokes dma_buf_{begin,end}_access()
> for imported buffers. These calls were missing from the page-flip
> and modesetting code paths.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/udl/udl_fb.c | 38 ++--
> 1 file changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
> index 482786eeea6c..7d184ff96a1f 100644
> --- a/drivers/gpu/drm/udl/udl_fb.c
> +++ b/drivers/gpu/drm/udl/udl_fb.c
> @@ -92,6 +92,7 @@ int udl_handle_damage(struct drm_framebuffer *fb, int x,
> int y,
> {
> struct drm_device *dev = fb->dev;
> struct udl_device *udl = to_udl(dev);
> + struct dma_buf_attachment *import_attach = fb->obj[0]->import_attach;
> int i, ret;
> char *cmd;
> struct urb *urb;
> @@ -117,15 +118,22 @@ int udl_handle_damage(struct drm_framebuffer *fb, int
> x, int y,
> else if ((clip.x2 > fb->width) || (clip.y2 > fb->height))
> return -EINVAL;
>
> + if (import_attach) {
> + ret = dma_buf_begin_cpu_access(import_attach->dmabuf,
> + DMA_FROM_DEVICE);
> + if (ret)
> + return ret;
> + }
> +
> vaddr = drm_gem_shmem_vmap(fb->obj[0]);
> if (IS_ERR(vaddr)) {
> DRM_ERROR("failed to vmap fb\n");
> - return 0;
> + goto out_dma_buf_end_cpu_access;
> }
>
> urb = udl_get_urb(dev);
> if (!urb)
> - goto out;
> + goto out_drm_gem_shmem_vunmap;
> cmd = urb->transfer_buffer;
>
> for (i = clip.y1; i < clip.y2; i++) {
> @@ -136,7 +144,7 @@ int udl_handle_damage(struct drm_framebuffer *fb, int x,
> int y,
> if (udl_render_hline(dev, log_bpp, &urb, (char *)vaddr,
> &cmd, byte_offset, dev_byte_offset,
> byte_width))
> - goto out;
> + goto out_drm_gem_shmem_vunmap;
> }
>
> if (cmd > (char *) urb->transfer_buffer) {
> @@ -149,10 +157,16 @@ int udl_handle_damage(struct drm_framebuffer *fb, int
> x, int y,
> } else
> udl_urb_completion(urb);
>
> -out:
> + ret = 0;
> +
> +out_drm_gem_shmem_vunmap:
> drm_gem_shmem_vunmap(fb->obj[0], vaddr);
> +out_dma_buf_end_cpu_access:
> + if (import_attach)
> + ret = dma_buf_end_cpu_access(import_attach->dmabuf,
> +DMA_FROM_DEVICE);
>
> - return 0;
> + return ret;
Since you're touching the end_cpu_access call, we might as well
address the following bug. Namely:
Even though we get a failure from udl_render_hline() or otherwise, the
function return "OK" when end_cpu_access() is successful.
If you really want to, one can keep it separate (+ CC stable),
although it's fine to squash it here with a small note in the commit
message.
HTH
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm v4] modetest: Use floating vrefresh while dumping mode
On Tuesday, 2019-12-03 06:37:36 -0800, Devarsh Thakkar wrote:
> Add function to derive floating value of vertical
> refresh rate from drm mode using pixel clock,
> horizontal total size and vertical total size.
>
> Use this function to find suitable mode having vrefresh
> value which is matching with user provided vrefresh value.
>
> If user doesn't provide any vrefresh value in args then
> update vertical refresh rate value in pipe args using this
> function.
>
> Also use this function for printing floating vrefresh while
> dumping all available modes.
>
> This will give more accurate picture to user for available modes
> differentiated by floating vertical refresh rate and help user
> select more appropriate mode using suitable refresh rate value.
Any chance you could use the merge requests infra instead of patches on
the mailing list? :)
https://gitlab.freedesktop.org/mesa/drm/merge_requests
This will allow much easier reviews of the patch's revisions and
build-test your changes automatically.
Can I also suggest you split the unrelated changes into individual
commits?
>
> V4:
> 1) While setting mode, print mode name and vrefresh using struct
>drmModeModeInfo instead of struct pipe_args.
> 2) Revert back to using a float value instead of float *
>for vrefresh arg in connector_find_mode().
>
> V3:
> 1) Change name of function used to derive refresh rate.
>
> V2:
> 1) Don't use inline function for deriving refresh rate from mode.
> 2) If requested mode not found, print refresh rate only
>if user had provided it in args.
>
> Signed-off-by: Devarsh Thakkar
> Reviewed-by: Neil Armstrong
> ---
> tests/modetest/modetest.c | 35 +++
> 1 file changed, 23 insertions(+), 12 deletions(-)
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index b4edfcb..e998e8e 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -133,6 +133,12 @@ static inline int64_t U642I64(uint64_t val)
> return (int64_t)*((int64_t *)&val);
> }
>
> +static float mode_vrefresh(drmModeModeInfo *mode)
> +{
> + return mode->clock * 1000.00
> + / (mode->htotal * mode->vtotal);
> +}
> +
> #define bit_name_fn(res) \
> const char * res##_str(int type) { \
> unsigned int i; \
> @@ -210,9 +216,9 @@ static void dump_encoders(struct device *dev)
>
> static void dump_mode(drmModeModeInfo *mode)
> {
> - printf(" %s %d %d %d %d %d %d %d %d %d %d",
> + printf(" %s %.2f %d %d %d %d %d %d %d %d %d",
> mode->name,
> -mode->vrefresh,
> +mode_vrefresh(mode),
> mode->hdisplay,
> mode->hsync_start,
> mode->hsync_end,
> @@ -828,7 +834,6 @@ connector_find_mode(struct device *dev, uint32_t con_id,
> const char *mode_str,
> drmModeConnector *connector;
> drmModeModeInfo *mode;
> int i;
> - float mode_vrefresh;
>
> connector = get_connector_by_id(dev, con_id);
> if (!connector || !connector->count_modes)
> @@ -837,15 +842,14 @@ connector_find_mode(struct device *dev, uint32_t
> con_id, const char *mode_str,
> for (i = 0; i < connector->count_modes; i++) {
> mode = &connector->modes[i];
> if (!strcmp(mode->name, mode_str)) {
> - /* If the vertical refresh frequency is not specified
> then return the
> - * first mode that match with the name. Else, return
> the mode that match
> - * the name and the specified vertical refresh
> frequency.
> + /* If the vertical refresh frequency is not specified
> + * then return the first mode that match with the name.
> + * Else, return the mode that match the name and
> + * the specified vertical refresh frequency.
>*/
> - mode_vrefresh = mode->clock * 1000.00
> - / (mode->htotal * mode->vtotal);
> if (vrefresh == 0)
> return mode;
> - else if (fabs(mode_vrefresh - vrefresh) < 0.005)
> + else if (fabs(mode_vrefresh(mode) - vrefresh) < 0.005)
> return mode;
> }
> }
> @@ -911,7 +915,13 @@ static int pipe_find_crtc_and_mode(struct device *dev,
> struct pipe_arg *pipe)
> mode = connector_find_mode(dev, pipe->con_ids[i],
> pipe->mode_str, pipe->vrefresh);
> if (mode == NULL) {
> - fprintf(stderr,
> + if (pipe->vrefresh)
> + fprintf(stderr,
> + "failed to find mode "
> + "\"%s-%.2fHz\"
Re: [PATCH] backlight: pwm_bl: Switch to full GPIO descriptor
On Thu, Dec 05, 2019 at 09:11:16AM +0100, Linus Walleij wrote:
> The PWM backlight still supports passing a enable GPIO line as
> platform data using the legacy API.
>
> It turns out that ever board using this mechanism except one
> is pass .enable_gpio = -1. So we drop all these cargo-culted -1's
> from all instances of this platform data in the kernel.
>
> The remaning board, Palm TC, is converted to pass a machine
> descriptior table with the "enable" GPIO instead, and delete the
> platform data entry for enable_gpio and the code handling it
> and things should work smoothly with the new API.
>
> Cc: Krzysztof Kozlowski
> Cc: Robert Jarzmik
> Cc: Guan Xuetao
> Cc: Bartosz Golaszewski
> Signed-off-by: Linus Walleij
Looks good but...
> diff --git a/arch/arm/mach-pxa/palmtc.c b/arch/arm/mach-pxa/palmtc.c
> index f52bd155e825..3813118435bf 100644
> --- a/arch/arm/mach-pxa/palmtc.c
> +++ b/arch/arm/mach-pxa/palmtc.c
> @@ -175,6 +175,15 @@ static inline void palmtc_keys_init(void) {}
> * Backlight
>
> **/
> #if defined(CONFIG_BACKLIGHT_PWM) || defined(CONFIG_BACKLIGHT_PWM_MODULE)
> +
> +static struct gpiod_lookup_table palmtc_pwm_bl_gpio_table = {
> + .dev_id = "pwm-backlight.0",
> + .table = {
> + GPIO_LOOKUP("gpio-pxa", GPIO_NR_PALMTC_BL_POWER,
> + "enable", GPIO_ACTIVE_HIGH),
> + },
> +};
> +
... I cannot find the corresponding removal of the
`.enable_gpio = GPIO_NR_PALMTC_BL_POWER` meaning that ...
> diff --git a/include/linux/pwm_backlight.h b/include/linux/pwm_backlight.h
> index 8ea265a022fd..06086cb93b6f 100644
> --- a/include/linux/pwm_backlight.h
> +++ b/include/linux/pwm_backlight.h
> @@ -16,8 +16,6 @@ struct platform_pwm_backlight_data {
> unsigned int *levels;
> unsigned int post_pwm_on_delay;
> unsigned int pwm_off_delay;
> - /* TODO remove once all users are switched to gpiod_* API */
> - int enable_gpio;
... I worry that palmtc.c is no longer compilable for some configs.
Daniel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gma500: Call psb_driver_{load,unload}() before registering device
On Wed, Dec 4, 2019 at 7:46 PM Thomas Zimmermann wrote:
>
> The load/unload callbacks in struct drm_driver are deprecated. Remove
> them and call functions explicitly.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Patrik Jakobsson
Thanks for the patch.
-Patrik
> ---
> drivers/gpu/drm/gma500/psb_drv.c | 43 +++-
> 1 file changed, 37 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/psb_drv.c
> b/drivers/gpu/drm/gma500/psb_drv.c
> index 192a39e52617..52591416f8fe 100644
> --- a/drivers/gpu/drm/gma500/psb_drv.c
> +++ b/drivers/gpu/drm/gma500/psb_drv.c
> @@ -23,7 +23,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
>
> @@ -427,14 +426,48 @@ static long psb_unlocked_ioctl(struct file *filp,
> unsigned int cmd,
>
> static int psb_pci_probe(struct pci_dev *pdev, const struct pci_device_id
> *ent)
> {
> - return drm_get_pci_dev(pdev, ent, &driver);
> -}
> + struct drm_device *dev;
> + int ret;
> +
> + ret = pci_enable_device(pdev);
> + if (ret)
> + return ret;
> +
> + dev = drm_dev_alloc(&driver, &pdev->dev);
> + if (IS_ERR(dev)) {
> + ret = PTR_ERR(dev);
> + goto err_pci_disable_device;
> + }
> +
> + dev->pdev = pdev;
> + pci_set_drvdata(pdev, dev);
> +
> + ret = psb_driver_load(dev, ent->driver_data);
> + if (ret)
> + goto err_drm_dev_put;
>
> + ret = drm_dev_register(dev, ent->driver_data);
> + if (ret)
> + goto err_psb_driver_unload;
> +
> + return 0;
> +
> +err_psb_driver_unload:
> + psb_driver_unload(dev);
> +err_drm_dev_put:
> + drm_dev_put(dev);
> +err_pci_disable_device:
> + pci_disable_device(pdev);
> + return ret;
> +}
>
> static void psb_pci_remove(struct pci_dev *pdev)
> {
> struct drm_device *dev = pci_get_drvdata(pdev);
> - drm_put_dev(dev);
> +
> + drm_dev_unregister(dev);
> + psb_driver_unload(dev);
> + drm_dev_put(dev);
> }
>
> static const struct dev_pm_ops psb_pm_ops = {
> @@ -467,8 +500,6 @@ static const struct file_operations psb_gem_fops = {
>
> static struct drm_driver driver = {
> .driver_features = DRIVER_MODESET | DRIVER_GEM,
> - .load = psb_driver_load,
> - .unload = psb_driver_unload,
> .lastclose = drm_fb_helper_lastclose,
>
> .num_ioctls = ARRAY_SIZE(psb_ioctls),
> --
> 2.23.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: corgi: Convert to use GPIO descriptors
On Tue, Dec 03, 2019 at 01:31:43PM +0100, Linus Walleij wrote:
> The code in the Corgi backlight driver can be considerably
> simplified by moving to GPIO descriptors and lookup tables
> from the board files instead of passing GPIO numbers using
> the old API.
>
> Make sure to encode inversion semantics for the Akita and
> Spitz platforms inside the GPIO lookup table and drop the
> custom inversion semantics from the driver.
>
> All in-tree users are converted in this patch.
>
> Cc: Andrea Adami
> Cc: Robert Jarzmik
> Signed-off-by: Linus Walleij
Reviewed-by: Daniel Thompson
> ---
> arch/arm/mach-pxa/corgi.c | 12 -
> arch/arm/mach-pxa/spitz.c | 34 +++
> drivers/video/backlight/corgi_lcd.c | 68 -
> include/linux/spi/corgi_lcd.h | 3 --
> 4 files changed, 54 insertions(+), 63 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/corgi.c b/arch/arm/mach-pxa/corgi.c
> index f2d73289230f..c9625dcae27c 100644
> --- a/arch/arm/mach-pxa/corgi.c
> +++ b/arch/arm/mach-pxa/corgi.c
> @@ -563,13 +563,20 @@ static void corgi_bl_kick_battery(void)
> }
> }
>
> +static struct gpiod_lookup_table corgi_lcdcon_gpio_table = {
> + .dev_id = "spi0.1",
> + .table = {
> + GPIO_LOOKUP("gpio-pxa", CORGI_GPIO_BACKLIGHT_CONT,
> + "BL_CONT", GPIO_ACTIVE_HIGH),
> + { },
> + },
> +};
> +
> static struct corgi_lcd_platform_data corgi_lcdcon_info = {
> .init_mode = CORGI_LCD_MODE_VGA,
> .max_intensity = 0x2f,
> .default_intensity = 0x1f,
> .limit_mask = 0x0b,
> - .gpio_backlight_cont= CORGI_GPIO_BACKLIGHT_CONT,
> - .gpio_backlight_on = -1,
> .kick_battery = corgi_bl_kick_battery,
> };
>
> @@ -609,6 +616,7 @@ static struct spi_board_info corgi_spi_devices[] = {
> static void __init corgi_init_spi(void)
> {
> pxa2xx_set_spi_info(1, &corgi_spi_info);
> + gpiod_add_lookup_table(&corgi_lcdcon_gpio_table);
> spi_register_board_info(ARRAY_AND_SIZE(corgi_spi_devices));
> }
> #else
> diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
> index a4fdc399d152..82e80a257c0f 100644
> --- a/arch/arm/mach-pxa/spitz.c
> +++ b/arch/arm/mach-pxa/spitz.c
> @@ -525,13 +525,33 @@ static void spitz_bl_kick_battery(void)
> }
> }
>
> +static struct gpiod_lookup_table spitz_lcdcon_gpio_table = {
> + .dev_id = "spi0.1",
> + .table = {
> + GPIO_LOOKUP("gpio-pxa", SPITZ_GPIO_BACKLIGHT_CONT,
> + "BL_CONT", GPIO_ACTIVE_LOW),
> + GPIO_LOOKUP("gpio-pxa", SPITZ_GPIO_BACKLIGHT_ON,
> + "BL_ON", GPIO_ACTIVE_HIGH),
> + { },
> + },
> +};
> +
> +static struct gpiod_lookup_table akita_lcdcon_gpio_table = {
> + .dev_id = "spi0.1",
> + .table = {
> + GPIO_LOOKUP("gpio-pxa", AKITA_GPIO_BACKLIGHT_CONT,
> + "BL_CONT", GPIO_ACTIVE_LOW),
> + GPIO_LOOKUP("gpio-pxa", AKITA_GPIO_BACKLIGHT_ON,
> + "BL_ON", GPIO_ACTIVE_HIGH),
> + { },
> + },
> +};
> +
> static struct corgi_lcd_platform_data spitz_lcdcon_info = {
> .init_mode = CORGI_LCD_MODE_VGA,
> .max_intensity = 0x2f,
> .default_intensity = 0x1f,
> .limit_mask = 0x0b,
> - .gpio_backlight_cont= SPITZ_GPIO_BACKLIGHT_CONT,
> - .gpio_backlight_on = SPITZ_GPIO_BACKLIGHT_ON,
> .kick_battery = spitz_bl_kick_battery,
> };
>
> @@ -574,12 +594,10 @@ static struct pxa2xx_spi_controller spitz_spi_info = {
>
> static void __init spitz_spi_init(void)
> {
> - struct corgi_lcd_platform_data *lcd_data = &spitz_lcdcon_info;
> -
> - if (machine_is_akita()) {
> - lcd_data->gpio_backlight_cont = AKITA_GPIO_BACKLIGHT_CONT;
> - lcd_data->gpio_backlight_on = AKITA_GPIO_BACKLIGHT_ON;
> - }
> + if (machine_is_akita())
> + gpiod_add_lookup_table(&akita_lcdcon_gpio_table);
> + else
> + gpiod_add_lookup_table(&spitz_lcdcon_gpio_table);
>
> pxa2xx_set_spi_info(2, &spitz_spi_info);
> spi_register_board_info(ARRAY_AND_SIZE(spitz_spi_devices));
> diff --git a/drivers/video/backlight/corgi_lcd.c
> b/drivers/video/backlight/corgi_lcd.c
> index 68f7592c5060..25ef0cbd7583 100644
> --- a/drivers/video/backlight/corgi_lcd.c
> +++ b/drivers/video/backlight/corgi_lcd.c
> @@ -15,7 +15,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> @@ -90,9 +90,8 @@ struct corgi_lcd {
> int mode;
> charbuf[2];
>
> - int gpio_backlight_on;
> - int gpio_backlight_cont;
> - int gpio_backlight_cont_inverted;
> + struct gpio_desc *backlight_on;
> + struct gpio_desc *backlight_cont;
>
> void (*kick_battery)(void);
> };
>
Re: [PATCH v2 01/28] drm: Introduce drm_bridge_init()
Hi Mihail,
Thank you for the patch.
On Wed, Dec 04, 2019 at 11:48:02AM +, Mihail Atanassov wrote:
> A simple convenience function to initialize the struct drm_bridge. The
> goal is to standardize initialization for any bridge registered with
> drm_bridge_add() so that we can later add device links for consumers of
> those bridges.
>
> v2:
> - s/WARN_ON(!funcs)/WARN_ON(!funcs || !dev)/ as suggested by Daniel
> - expand on some kerneldoc comments as suggested by Daniel
> - update commit message as suggested by Daniel
>
> Signed-off-by: Mihail Atanassov
> ---
> drivers/gpu/drm/drm_bridge.c | 34 +-
> include/drm/drm_bridge.h | 15 ++-
> 2 files changed, 47 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index cba537c99e43..50e1c1b46e20 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -64,7 +64,10 @@ static DEFINE_MUTEX(bridge_lock);
> static LIST_HEAD(bridge_list);
>
> /**
> - * drm_bridge_add - add the given bridge to the global bridge list
> + * drm_bridge_add - add the given bridge to the global bridge list.
You add a final period here and in the documentation of struct
drm_bridge, but the new function you're adding doesn't have one :-) I'd
drop the period here and for drm_bridge to be consistent with the rest
of the code.
> + *
> + * Drivers should call drm_bridge_init() prior adding it to the list.
s/should/shall/
s/prior adding it/prior to adding the bridge/
> + * Drivers should call drm_bridge_remove() to clean up the bridge list.
I'd replace this sentence with "Before deleting a bridge (usually when
the driver is unbound from the device), drivers shall call
drm_bridge_remove() to remove it from the global list."
> *
> * @bridge: bridge control structure
> */
> @@ -89,6 +92,35 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> }
> EXPORT_SYMBOL(drm_bridge_remove);
>
> +/**
> + * drm_bridge_init - initialise a drm_bridge structure
initialise or initialize ? :-)
> + *
> + * @bridge: bridge control structure
> + * @funcs: control functions
> + * @dev: device associated with this drm_bridge
dev goes before funcs
> + * @timings: timing specification for the bridge; optional (may be NULL)
> + * @driver_private: pointer to the bridge driver internal context (may be
> NULL)
I'm not too sure about the last two parameters. Having NULL, NULL in
most callers is confusing, and having a void * as one of the parameters
means that the compiler won't catch errors if the two parameters are
reversed. I think this is quite error prone.
There are very few drivers using driver_private (I count 6 of them, with
2 additional drivers that set driver_private but never use it). How
about embedding the bridge structure in those 6 drivers and getting rid
of the field altogether ? This could be part of a separate series, but
in any case I'd drop driver_private from drm_bridge_init().
> + */
> +void drm_bridge_init(struct drm_bridge *bridge, struct device *dev,
> + const struct drm_bridge_funcs *funcs,
> + const struct drm_bridge_timings *timings,
> + void *driver_private)
> +{
> + WARN_ON(!funcs || !dev);
> +
> + bridge->dev = NULL;
NULL ? Shouldn't this be dev ?
> + bridge->encoder = NULL;
> + bridge->next = NULL;
> +
> +#ifdef CONFIG_OF
> + bridge->of_node = dev->of_node;
> +#endif
> + bridge->timings = timings;
> + bridge->funcs = funcs;
> + bridge->driver_private = driver_private;
> +}
> +EXPORT_SYMBOL(drm_bridge_init);
> +
> /**
> * drm_bridge_attach - attach the bridge to an encoder's chain
> *
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index c0a2286a81e9..949e4f401a53 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -373,7 +373,16 @@ struct drm_bridge_timings {
> };
>
> /**
> - * struct drm_bridge - central DRM bridge control structure
> + * struct drm_bridge - central DRM bridge control structure.
> + *
> + * Bridge drivers should call drm_bridge_init() to initialize a bridge
> + * driver, and then register it with drm_bridge_add().
s/bridge driver/bridge structure/ (or drm_bridge structure)
> + *
> + * Users of bridges link a bridge driver into their overall display output
> + * pipeline by calling drm_bridge_attach().
> + *
> + * Modular drivers in OF systems can query the list of registered bridges
> + * with of_drm_find_bridge().
> */
> struct drm_bridge {
> /** @dev: DRM device this bridge belongs to */
> @@ -402,6 +411,10 @@ struct drm_bridge {
>
> void drm_bridge_add(struct drm_bridge *bridge);
> void drm_bridge_remove(struct drm_bridge *bridge);
> +void drm_bridge_init(struct drm_bridge *bridge, struct device *dev,
> + const struct drm_bridge_funcs *funcs,
> + const struct drm_bridge_timings *timings,
> + void *driver
Re: [PATCH v2 12/28] gpu: drm: bridge: sii9234: Use drm_bridge_init()
Hi, On 04/12/2019 12:48, Mihail Atanassov wrote: > No functional change. > Why this particular one has "gpu: drm: bridge" unlike the other patches of the serie ? Neil > Signed-off-by: Mihail Atanassov > --- > drivers/gpu/drm/bridge/sii9234.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/sii9234.c > b/drivers/gpu/drm/bridge/sii9234.c > index f81f81b7051f..bfd3832baa1a 100644 > --- a/drivers/gpu/drm/bridge/sii9234.c > +++ b/drivers/gpu/drm/bridge/sii9234.c > @@ -925,8 +925,7 @@ static int sii9234_probe(struct i2c_client *client, > > i2c_set_clientdata(client, ctx); > > - ctx->bridge.funcs = &sii9234_bridge_funcs; > - ctx->bridge.of_node = dev->of_node; > + drm_bridge_init(&ctx->bridge, dev, &sii9234_bridge_funcs, NULL, NULL); > drm_bridge_add(&ctx->bridge); > > sii9234_cable_in(ctx); > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [EXT] [PATCH v8 2/2] drm/bridge: Add NWL MIPI DSI host controller support
Hi Robert,
On Wed, Dec 04, 2019 at 12:24:39PM +, Robert Chiras wrote:
> On Mi, 2019-12-04 at 13:06 +0100, Guido Günther wrote:
> > Hi Robert,
> > On Tue, Dec 03, 2019 at 09:50:03AM +, Robert Chiras wrote:
> > >
> > > Hi Guido,
> > >
> > > Since your last revision sent, I've done more tests here and found
> > > a
> > > few more improvements that could be added to this driver.
> > > See inline.
> > >
> > > On Lu, 2019-12-02 at 20:35 +0100, Guido Günther wrote:
> > > >
> > > > Caution: EXT Email
> > > >
> > > > This adds initial support for the NWL MIPI DSI Host controller
> > > > found
> > > > on
> > > > i.MX8 SoCs.
> > > >
> > > > It adds support for the i.MX8MQ but the same IP can be found on
> > > > e.g. the i.MX8QXP.
> > > >
> > > > It has been tested on the Librem 5 devkit using mxsfb.
> > > >
> > > > Signed-off-by: Guido Günther
> > > > Co-developed-by: Robert Chiras
> > > > Signed-off-by: Robert Chiras
> > > > Tested-by: Robert Chiras
> > > > ---
> > > > drivers/gpu/drm/bridge/Kconfig | 16 +
> > > > drivers/gpu/drm/bridge/Makefile |3 +
> > > > drivers/gpu/drm/bridge/nwl-dsi.c | 1230
> > > > ++
> > > > drivers/gpu/drm/bridge/nwl-dsi.h | 144
> > > > 4 files changed, 1393 insertions(+)
> > > > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi.c
> > > > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi.h
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > > > b/drivers/gpu/drm/bridge/Kconfig
> > > > index 34362976cd6f..6fb534f55d22 100644
> > > > --- a/drivers/gpu/drm/bridge/Kconfig
> > > > +++ b/drivers/gpu/drm/bridge/Kconfig
> > > > @@ -65,6 +65,22 @@ config DRM_MEGACHIPS_STDP_GE_B850V3_FW
> > > > to DP++. This is used with the i.MX6 imx-ldb
> > > > driver. You are likely to say N here.
> > > >
> > > > +config DRM_NWL_MIPI_DSI
> > > > + tristate "Northwest Logic MIPI DSI Host controller"
> > > > + depends on DRM
> > > > + depends on COMMON_CLK
> > > > + depends on OF && HAS_IOMEM
> > > > + select DRM_KMS_HELPER
> > > > + select DRM_MIPI_DSI
> > > > + select DRM_PANEL_BRIDGE
> > > > + select GENERIC_PHY_MIPI_DPHY
> > > > + select MFD_SYSCON
> > > > + select MULTIPLEXER
> > > > + select REGMAP_MMIO
> > > > + help
> > > > + This enables the Northwest Logic MIPI DSI Host
> > > > controller
> > > > as
> > > > + for example found on NXP's i.MX8 Processors.
> > > > +
> > > > config DRM_NXP_PTN3460
> > > > tristate "NXP PTN3460 DP/LVDS bridge"
> > > > depends on OF
> > > > diff --git a/drivers/gpu/drm/bridge/Makefile
> > > > b/drivers/gpu/drm/bridge/Makefile
> > > > index 4934fcf5a6f8..c3f3a43e9b8f 100644
> > > > --- a/drivers/gpu/drm/bridge/Makefile
> > > > +++ b/drivers/gpu/drm/bridge/Makefile
> > > > @@ -16,4 +16,7 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> > > > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> > > > obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
> > > > obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> > > > +obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
> > > > obj-y += synopsys/
> > > > +
> > > > +header-test-y += nwl-dsi.h
> > > > diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> > > > b/drivers/gpu/drm/bridge/nwl-dsi.c
> > > > new file mode 100644
> > > > index ..023191894fe4
> > > > --- /dev/null
> > > > +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> > > > @@ -0,0 +1,1230 @@
> > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > +/*
> > > > + * i.MX8 NWL MIPI DSI host driver
> > > > + *
> > > > + * Copyright (C) 2017 NXP
> > > > + * Copyright (C) 2019 Purism SPC
> > > > + */
> > > > +
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +
> > > > +#include
> > > > +#include
> > > > +
> > > > +#include "nwl-dsi.h"
> > > > +
> > > > +#define DRV_NAME "nwl-dsi"
> > > > +
> > > > +/* i.MX8 NWL quirks */
> > > > +/* i.MX8MQ errata E11418 */
> > > > +#define E11418_HS_MODE_QUIRK BIT(0)
> > > > +
> > > > +#define NWL_DSI_MIPI_FIFO_TIMEOUT msecs_to_jiffies(500)
> > > > +
> > > > +enum transfer_direction {
> > > > + DSI_PACKET_SEND,
> > > > + DSI_PACKET_RECEIVE,
> > > > +};
> > > > +
> > > > +/* Possible platform specific clocks */
> > > > +#define NWL_DSI_CLK_CORE "core"
> > > > +#define NWL_DSI_MAX_PLATFORM_CLOCKS 1
> > > > +
> > > > +#define NWL_DSI_ENDPOINT_LCDIF 0
> > > > +#define NWL_DSI_ENDPOINT_DCSS 1
> > > > +
> > > > +struct nwl_dsi_plat_clk_config {
> > > > + const char *id;
> > > > + struct clk *clk;
> > > > + bool present;
> > > > +};
> > > > +
> > > > +struct nwl_dsi_
Re: [PATCH v2 2/2] drm/komeda: Enable new product D32 support
On Thursday, 5 December 2019 08:53:02 GMT james qian wang (Arm Technology
China) wrote:
> On Tue, Dec 03, 2019 at 09:59:57AM +, Mihail Atanassov wrote:
> > On Tuesday, 3 December 2019 06:46:06 GMT james qian wang (Arm Technology
> > China) wrote:
> > > On Mon, Dec 02, 2019 at 11:07:52AM +, Mihail Atanassov wrote:
> > > > On Thursday, 21 November 2019 08:17:45 GMT james qian wang (Arm
> > > > Technology China) wrote:
> > > > > D32 is simple version of D71, the difference is:
> > > > > - Only has one pipeline
> > > > > - Drop the periph block and merge it to GCU
> > > > >
> > > > > v2: Rebase.
> > > > >
> > > > > Signed-off-by: James Qian Wang (Arm Technology China)
> > > > >
> > > > > ---
> > > > > .../drm/arm/display/include/malidp_product.h | 3 +-
> > > > > .../arm/display/komeda/d71/d71_component.c| 2 +-
> > > > > .../gpu/drm/arm/display/komeda/d71/d71_dev.c | 43
> > > > > ---
> > > > > .../gpu/drm/arm/display/komeda/d71/d71_regs.h | 13 ++
> > > > > .../gpu/drm/arm/display/komeda/komeda_drv.c | 1 +
> > > > > 5 files changed, 44 insertions(+), 18 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/arm/display/include/malidp_product.h
> > > > > b/drivers/gpu/drm/arm/display/include/malidp_product.h
> > > > > index 96e2e4016250..dbd3d4765065 100644
> > > > > --- a/drivers/gpu/drm/arm/display/include/malidp_product.h
> > > > > +++ b/drivers/gpu/drm/arm/display/include/malidp_product.h
> > > > > @@ -18,7 +18,8 @@
> > > > > #define MALIDP_CORE_ID_STATUS(__core_id) (((__u32)(__core_id)) &
> > > > > 0xFF)
> > > > >
> > > > > /* Mali-display product IDs */
> > > > > -#define MALIDP_D71_PRODUCT_ID 0x0071
> > > > > +#define MALIDP_D71_PRODUCT_ID0x0071
> > > > > +#define MALIDP_D32_PRODUCT_ID0x0032
> > > > >
> > > > > union komeda_config_id {
> > > > > struct {
> > > > > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > > > b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > > > index 6dadf4413ef3..c7f7e9c545c7 100644
> > > > > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > > > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > > > @@ -1274,7 +1274,7 @@ static int d71_timing_ctrlr_init(struct d71_dev
> > > > > *d71,
> > > > >
> > > > > ctrlr = to_ctrlr(c);
> > > > >
> > > > > - ctrlr->supports_dual_link = true;
> > > > > + ctrlr->supports_dual_link = d71->supports_dual_link;
> > > > >
> > > > > return 0;
> > > > > }
> > > > > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > > > b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > > > index 9b3bf353b6cc..2d429e310e5b 100644
> > > > > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > > > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > > > @@ -371,23 +371,33 @@ static int d71_enum_resources(struct komeda_dev
> > > > > *mdev)
> > > > > goto err_cleanup;
> > > > > }
> > > > >
> > > > > - /* probe PERIPH */
> > > > > + /* Only the legacy HW has the periph block, the newer merges
> > > > > the periph
> > > > > + * into GCU
> > > > > + */
> > > > > value = malidp_read32(d71->periph_addr, BLK_BLOCK_INFO);
> > > > > - if (BLOCK_INFO_BLK_TYPE(value) != D71_BLK_TYPE_PERIPH) {
> > > > > - DRM_ERROR("access blk periph but got blk: %d.\n",
> > > > > - BLOCK_INFO_BLK_TYPE(value));
> > > > > - err = -EINVAL;
> > > > > - goto err_cleanup;
> > > > > + if (BLOCK_INFO_BLK_TYPE(value) != D71_BLK_TYPE_PERIPH)
> > > > > + d71->periph_addr = NULL;
> > > > > +
> > > > > + if (d71->periph_addr) {
> > > > > + /* probe PERIPHERAL in legacy HW */
> > > > > + value = malidp_read32(d71->periph_addr,
> > > > > PERIPH_CONFIGURATION_ID);
> > > > > +
> > > > > + d71->max_line_size = value & PERIPH_MAX_LINE_SIZE
> > > > > ? 4096 : 2048;
> > > > > + d71->max_vsize = 4096;
> > > > > + d71->num_rich_layers= value &
> > > > > PERIPH_NUM_RICH_LAYERS ? 2 : 1;
> > > > > + d71->supports_dual_link = !!(value & PERIPH_SPLIT_EN);
> > > > > + d71->integrates_tbu = !!(value & PERIPH_TBU_EN);
> > > > > + } else {
> > > > > + value = malidp_read32(d71->gcu_addr,
> > > > > GCU_CONFIGURATION_ID0);
> > > > > + d71->max_line_size = GCU_MAX_LINE_SIZE(value);
> > > > > + d71->max_vsize = GCU_MAX_NUM_LINES(value);
> > > > > +
> > > > > + value = malidp_read32(d71->gcu_addr,
> > > > > GCU_CONFIGURATION_ID1);
> > > > > + d71->num_rich_layers= GCU_NUM_RICH_LAYERS(value);
> > > > > + d71->supports_dual_link = GCU_DISPLAY_SPLIT_EN(value);
> > > > > + d71->integrates_tbu = GCU_DISPLAY_TBU_EN(value);
> > > > > }
> > > > >
> > > > > -
Re: KASAN: slab-out-of-bounds Read in fbcon_get_font
On 05/12/19 12:27, Dmitry Vyukov wrote: > Oh, you mean the final bisection crash. Indeed it contains a kvm frame > and it turns out to be a bug in syzkaller code that indeed > misattributed it to kvm instead of netfilter. > Should be fixed now, you may read the commit message for details: > https://github.com/google/syzkaller/commit/4fb74474cf0af2126be3a8989d770c3947ae9478 > > Overall this "making sense out of kernel output" task is the ultimate > insanity, you may skim through this file to get a taste of amount of > hardcoding and special corner cases that need to be handled: > https://github.com/google/syzkaller/blob/master/pkg/report/linux.go > And this is never done, such "exception from exception corner case" > things pop up every week. There is always something to shuffle and > tune. It only keeps functioning due to 500+ test cases for all > possible insane kernel outputs: > https://github.com/google/syzkaller/tree/master/pkg/report/testdata/linux/report > https://github.com/google/syzkaller/tree/master/pkg/report/testdata/linux/guilty > > So thanks for persisting and questioning! We are getting better with > each new test. Thanks to you! I "complain" because I know you're so responsive. :) Paolo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mgag200: Call mgag200_driver_{load,unload}() before registering device
On Thu, Dec 5, 2019 at 10:02 AM Thomas Zimmermann wrote:
>
> The load/unload callbacks in struct drm_driver are deprecated. Remove
> them and call functions explicitly.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
The even fancier version of this would be to embed the drm_device and
switch over to drm_dev_init().
-Daniel
> ---
> drivers/gpu/drm/mgag200/mgag200_drv.c | 44 +++
> 1 file changed, 38 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
> b/drivers/gpu/drm/mgag200/mgag200_drv.c
> index d43951caeea0..30b3b827adf8 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_drv.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
> @@ -6,13 +6,13 @@
> * Dave Airlie
> */
>
> -#include
> #include
> +#include
> +#include
>
> #include
> #include
> #include
> -#include
> #include
>
> #include "mgag200_drv.h"
> @@ -48,16 +48,50 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
>
> static int mga_pci_probe(struct pci_dev *pdev, const struct pci_device_id
> *ent)
> {
> + struct drm_device *dev;
> + int ret;
> +
> drm_fb_helper_remove_conflicting_pci_framebuffers(pdev,
> "mgag200drmfb");
>
> - return drm_get_pci_dev(pdev, ent, &driver);
> + ret = pci_enable_device(pdev);
> + if (ret)
> + return ret;
> +
> + dev = drm_dev_alloc(&driver, &pdev->dev);
> + if (IS_ERR(dev)) {
> + ret = PTR_ERR(dev);
> + goto err_pci_disable_device;
> + }
> +
> + dev->pdev = pdev;
> + pci_set_drvdata(pdev, dev);
> +
> + ret = mgag200_driver_load(dev, ent->driver_data);
> + if (ret)
> + goto err_drm_dev_put;
> +
> + ret = drm_dev_register(dev, ent->driver_data);
> + if (ret)
> + goto err_mgag200_driver_unload;
> +
> + return 0;
> +
> +err_mgag200_driver_unload:
> + mgag200_driver_unload(dev);
> +err_drm_dev_put:
> + drm_dev_put(dev);
> +err_pci_disable_device:
> + pci_disable_device(pdev);
> + return ret;
> }
>
> static void mga_pci_remove(struct pci_dev *pdev)
> {
> struct drm_device *dev = pci_get_drvdata(pdev);
>
> - drm_put_dev(dev);
> + drm_dev_unregister(dev);
> + mgag200_driver_unload(dev);
> + drm_dev_put(dev);
> }
>
> DEFINE_DRM_GEM_FOPS(mgag200_driver_fops);
> @@ -93,8 +127,6 @@ int mgag200_driver_dumb_create(struct drm_file *file,
>
> static struct drm_driver driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET,
> - .load = mgag200_driver_load,
> - .unload = mgag200_driver_unload,
> .fops = &mgag200_driver_fops,
> .name = DRIVER_NAME,
> .desc = DRIVER_DESC,
> --
> 2.23.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KASAN: slab-out-of-bounds Read in fbcon_get_font
On 05/12/19 11:31, Dmitry Vyukov wrote: >> Ah, and because the machine is a KVM guest, kvm_wait appears in a lot of >> backtrace and I get to share syzkaller's joy every time. :) > I don't see any mention of "kvm" in the crash report. It's there in the stack trace, not sure if this is what triggered my Cc: [] kvm_wait+0xca/0xe0 arch/x86/kernel/kvm.c:612 Paolo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: baseline power consumtion kernel > 5.3.10
On Do, 2019-12-05 at 08:52 +0100, Guido Riedel wrote:
> Hi,
>
> Since Kernel 5.3.11 I got a significant increased baseline Power
> consumption. I tried up to 5.4.1 on arch linux. Powertop shows an
> increase from 3.6W on 5.3.10 to 5.x W on higher Kernels. My laptop fan
> spins a lot more.
>
> I read that a lot of Intel stuff has entered the Kernel in 5.3.11, could
> this cause it? Will it stay like this in the next Versions? Can I maybe
> switch something off etc. to get a lower baseline power?
>
> I hope I write to the right address, otherwise sorry.
7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX corruption WA"), which has
been backported to 5.3.11 causes a major power regression due to Intel
GPUs not being able to enter rc6 anymore.
Fixes for this are -next, but I don't know what the plans for landing
and maybe backporting are.
Regards,
Lucas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KASAN: slab-out-of-bounds Read in fbcon_get_font
On 05/12/19 11:16, Dmitry Vyukov wrote:
> On Thu, Dec 5, 2019 at 11:13 AM Paolo Bonzini wrote:
>>
>> On 04/12/19 22:41, syzbot wrote:
>>> syzbot has bisected this bug to:
>>>
>>> commit 2de50e9674fc4ca3c6174b04477f69eb26b4ee31
>>> Author: Russell Currey
>>> Date: Mon Feb 8 04:08:20 2016 +
>>>
>>> powerpc/powernv: Remove support for p5ioc2
>>>
>>> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=127a042ae0
>>> start commit: 76bb8b05 Merge tag 'kbuild-v5.5' of
>>> git://git.kernel.org/p..
>>> git tree: upstream
>>> final crash:https://syzkaller.appspot.com/x/report.txt?x=117a042ae0
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=167a042ae0
>>> kernel config: https://syzkaller.appspot.com/x/.config?x=dd226651cb0f364b
>>> dashboard link:
>>> https://syzkaller.appspot.com/bug?extid=4455ca3b3291de891abc
>>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11181edae0
>>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=105cbb7ae0
>>>
>>> Reported-by: syzbot+4455ca3b3291de891...@syzkaller.appspotmail.com
>>> Fixes: 2de50e9674fc ("powerpc/powernv: Remove support for p5ioc2")
>>>
>>> For information about bisection process see:
>>> https://goo.gl/tpsmEJ#bisection
>>>
>>
>> Why is everybody being CC'd, even if the bug has nothing to do with the
>> person's subsystem?
>
> The To list should be intersection of 2 groups of emails: result of
> get_maintainers.pl on the file identified as culprit in the crash
> message + emails extracted from the bisected to commit.
Ah, and because the machine is a KVM guest, kvm_wait appears in a lot of
backtrace and I get to share syzkaller's joy every time. :)
This bisect result is bogus, though Tetsuo found the bug anyway.
Perhaps you can exclude commits that only touch architectures other than
x86?
Paolo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KASAN: slab-out-of-bounds Read in fbcon_get_font
On 04/12/19 22:41, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit 2de50e9674fc4ca3c6174b04477f69eb26b4ee31
> Author: Russell Currey
> Date: Mon Feb 8 04:08:20 2016 +
>
> powerpc/powernv: Remove support for p5ioc2
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=127a042ae0
> start commit: 76bb8b05 Merge tag 'kbuild-v5.5' of
> git://git.kernel.org/p..
> git tree: upstream
> final crash: https://syzkaller.appspot.com/x/report.txt?x=117a042ae0
> console output: https://syzkaller.appspot.com/x/log.txt?x=167a042ae0
> kernel config: https://syzkaller.appspot.com/x/.config?x=dd226651cb0f364b
> dashboard link:
> https://syzkaller.appspot.com/bug?extid=4455ca3b3291de891abc
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11181edae0
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=105cbb7ae0
>
> Reported-by: syzbot+4455ca3b3291de891...@syzkaller.appspotmail.com
> Fixes: 2de50e9674fc ("powerpc/powernv: Remove support for p5ioc2")
>
> For information about bisection process see:
> https://goo.gl/tpsmEJ#bisection
>
Why is everybody being CC'd, even if the bug has nothing to do with the
person's subsystem?
Thanks,
Paolo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/modes: remove unused variables
On Wed, 04 Dec 2019, Benjamin GAIGNARD wrote: > On 12/4/19 10:35 AM, Thomas Zimmermann wrote: >> Hi >> >> Am 19.11.19 um 14:47 schrieb Benjamin Gaignard: >>> When compiling with W=1 few warnings about unused variables show up. >>> This patch removes all the involved variables. >>> >>> Signed-off-by: Benjamin Gaignard >>> --- >>> drivers/gpu/drm/drm_modes.c | 22 +++--- >>> 1 file changed, 3 insertions(+), 19 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c >>> index 88232698d7a0..aca901aff042 100644 >>> --- a/drivers/gpu/drm/drm_modes.c >>> +++ b/drivers/gpu/drm/drm_modes.c >>> @@ -233,7 +233,7 @@ struct drm_display_mode *drm_cvt_mode(struct drm_device >>> *dev, int hdisplay, >>> /* 3) Nominal HSync width (% of line period) - default 8 */ >>> #define CVT_HSYNC_PERCENTAGE 8 >>> unsigned int hblank_percentage; >>> - int vsyncandback_porch, vback_porch, hblank; >>> + int vsyncandback_porch, hblank; >>> >>> /* estimated the horizontal period */ >>> tmp1 = HV_FACTOR * 100 - >>> @@ -249,7 +249,6 @@ struct drm_display_mode *drm_cvt_mode(struct drm_device >>> *dev, int hdisplay, >>> else >>> vsyncandback_porch = tmp1; >>> /* 10. Find number of lines in back porch */ >>> - vback_porch = vsyncandback_porch - vsync; >>> drm_mode->vtotal = vdisplay_rnd + 2 * vmargin + >>> vsyncandback_porch + CVT_MIN_V_PORCH; >>> /* 5) Definition of Horizontal blanking time limitation */ >>> @@ -386,9 +385,8 @@ drm_gtf_mode_complex(struct drm_device *dev, int >>> hdisplay, int vdisplay, >>> int top_margin, bottom_margin; >>> int interlace; >>> unsigned int hfreq_est; >>> - int vsync_plus_bp, vback_porch; >>> - unsigned int vtotal_lines, vfieldrate_est, hperiod; >>> - unsigned int vfield_rate, vframe_rate; >>> + int vsync_plus_bp; >>> + unsigned int vtotal_lines; >>> int left_margin, right_margin; >>> unsigned int total_active_pixels, ideal_duty_cycle; >>> unsigned int hblank, total_pixels, pixel_freq; >>> @@ -451,23 +449,9 @@ drm_gtf_mode_complex(struct drm_device *dev, int >>> hdisplay, int vdisplay, >>> /* [V SYNC+BP] = RINT(([MIN VSYNC+BP] * hfreq_est / 100)) */ >>> vsync_plus_bp = MIN_VSYNC_PLUS_BP * hfreq_est / 1000; >>> vsync_plus_bp = (vsync_plus_bp + 500) / 1000; >>> - /* 9. Find the number of lines in V back porch alone: */ >>> - vback_porch = vsync_plus_bp - V_SYNC_RQD; >>> /* 10. Find the total number of lines in Vertical field period: */ >>> vtotal_lines = vdisplay_rnd + top_margin + bottom_margin + >>> vsync_plus_bp + GTF_MIN_V_PORCH; >>> - /* 11. Estimate the Vertical field frequency: */ >>> - vfieldrate_est = hfreq_est / vtotal_lines; >>> - /* 12. Find the actual horizontal period: */ >>> - hperiod = 100 / (vfieldrate_rqd * vtotal_lines); >>> - >>> - /* 13. Find the actual Vertical field frequency: */ >>> - vfield_rate = hfreq_est / vtotal_lines; >>> - /* 14. Find the Vertical frame frequency: */ >>> - if (interlaced) >>> - vframe_rate = vfield_rate / 2; >>> - else >>> - vframe_rate = vfield_rate; >> The amount of unused code is quite large, which makes me wonder if >> there's something missing below where these variables are supposed to be >> used. >> >> If these variables can be removed, comments should mention that steps 9 >> and 11 to 14 are being left out. After all, the function is fairly >> explicit about implementing the GTF algorithm step by step. >> >> Best regards >> Thomas > > If the goal is to keep all the steps then I could prefix all problematic > variables with __maybe_unused macro. The effect is the same; it hides a potential bug that should be analyzed and fixed. If you have the time, please look at the code and figure out what it's supposed to do, and why isn't it using the information. Look at git blame and log, was it always so, or did something change? The warnings are about potential bugs. The objective or end goal is to fix the bugs, not to silence the warnings. BR, Jani. > > Benjamin > >> >>> /* 15. Find number of pixels in left margin: */ >>> if (margins) >>> left_margin = (hdisplay_rnd * GTF_MARGIN_PERCENTAGE + 500) / >>> > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 10/12] media: constify fb ops across all drivers
On Wed, 04 Dec 2019, Sakari Ailus wrote: > On Tue, Dec 03, 2019 at 06:38:52PM +0200, Jani Nikula wrote: >> Now that the fbops member of struct fb_info is const, we can start >> making the ops const as well. >> >> Remove the redundant fbops assignments while at it. >> >> v2: >> - actually add const in vivid >> - fix typo (Christophe de Dinechin) >> >> Cc: Hans Verkuil >> Cc: Andy Walls >> Cc: linux-me...@vger.kernel.org >> Cc: ivtv-de...@ivtvdriver.org >> Reviewed-by: Daniel Vetter >> Signed-off-by: Jani Nikula > > Reviewed-by: Sakari Ailus Thanks for the review! Andy, Hans, may I have your ack to merge this through drm-misc please? BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/14] HID: picoLCD: constify fb ops
On Mon, 02 Dec 2019, Bruno Prémont wrote:
> Hi Jani,
>
> On Fri, 29 Nov 2019 12:29:41 Jani Nikula wrote:
>> Now that the fbops member of struct fb_info is const, we can start
>> making the ops const as well.
>>
>> v2: fix typo (Christophe de Dinechin)
>
> Fine with me.
> I don't think going through drm-misc would trigger any conflict, but
> adding Jiri to CC for the case there was any preference.
>
> Acked-by: Bruno Prémont
No response, may I proceed with merging this through drm-misc please?
BR,
Jani.
>
>> Cc: Bruno Prémont
>> Cc: linux-in...@vger.kernel.org
>> Reviewed-by: Daniel Vetter
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/hid/hid-picolcd_fb.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/hid/hid-picolcd_fb.c b/drivers/hid/hid-picolcd_fb.c
>> index e162a668fb7e..a549c42e8c90 100644
>> --- a/drivers/hid/hid-picolcd_fb.c
>> +++ b/drivers/hid/hid-picolcd_fb.c
>> @@ -417,8 +417,7 @@ static int picolcd_set_par(struct fb_info *info)
>> return 0;
>> }
>>
>> -/* Note this can't be const because of struct fb_info definition */
>> -static struct fb_ops picolcdfb_ops = {
>> +static const struct fb_ops picolcdfb_ops = {
>> .owner= THIS_MODULE,
>> .fb_destroy = picolcd_fb_destroy,
>> .fb_read = fb_sys_read,
>
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v3 08/12] video: constify fb ops across all drivers
On Tue, 03 Dec 2019, Jani Nikula wrote: > Now that the fbops member of struct fb_info is const, we can start > making the ops const as well. > > This does not cover all drivers; some actually modify the fbops struct, > for example to adjust for different configurations, and others do more > involved things that I'd rather not touch in practically obsolete > drivers. Mostly this is the low hanging fruit where we can add "const" > and be done with it. > > v3: > - un-constify atyfb, mb862xx, nvidia and uvesabf (0day) > > v2: > - fix typo (Christophe de Dinechin) > - use "static const" instead of "const static" in mx3fb.c > - also constify smscufx.c > > Cc: linux-fb...@vger.kernel.org > Reviewed-by: Daniel Vetter > Signed-off-by: Jani Nikula Pushed up to and including this patch to drm-misc-next, thanks for the reviews and acks. BR, Jani. > --- > drivers/video/fbdev/68328fb.c | 2 +- > drivers/video/fbdev/acornfb.c | 2 +- > drivers/video/fbdev/amba-clcd.c| 2 +- > drivers/video/fbdev/amifb.c| 2 +- > drivers/video/fbdev/arcfb.c| 2 +- > drivers/video/fbdev/arkfb.c| 2 +- > drivers/video/fbdev/asiliantfb.c | 2 +- > drivers/video/fbdev/atmel_lcdfb.c | 2 +- > drivers/video/fbdev/aty/aty128fb.c | 2 +- > drivers/video/fbdev/aty/radeon_base.c | 2 +- > drivers/video/fbdev/au1100fb.c | 2 +- > drivers/video/fbdev/au1200fb.c | 2 +- > drivers/video/fbdev/broadsheetfb.c | 2 +- > drivers/video/fbdev/bw2.c | 2 +- > drivers/video/fbdev/carminefb.c| 2 +- > drivers/video/fbdev/cg14.c | 2 +- > drivers/video/fbdev/cg3.c | 2 +- > drivers/video/fbdev/cg6.c | 2 +- > drivers/video/fbdev/chipsfb.c | 2 +- > drivers/video/fbdev/cirrusfb.c | 2 +- > drivers/video/fbdev/clps711x-fb.c | 2 +- > drivers/video/fbdev/cobalt_lcdfb.c | 2 +- > drivers/video/fbdev/controlfb.c| 2 +- > drivers/video/fbdev/cyber2000fb.c | 2 +- > drivers/video/fbdev/da8xx-fb.c | 2 +- > drivers/video/fbdev/dnfb.c | 2 +- > drivers/video/fbdev/efifb.c| 2 +- > drivers/video/fbdev/ep93xx-fb.c| 2 +- > drivers/video/fbdev/fb-puv3.c | 2 +- > drivers/video/fbdev/ffb.c | 2 +- > drivers/video/fbdev/fm2fb.c| 2 +- > drivers/video/fbdev/fsl-diu-fb.c | 2 +- > drivers/video/fbdev/g364fb.c | 2 +- > drivers/video/fbdev/gbefb.c| 2 +- > drivers/video/fbdev/geode/gx1fb_core.c | 2 +- > drivers/video/fbdev/geode/gxfb_core.c | 2 +- > drivers/video/fbdev/geode/lxfb_core.c | 2 +- > drivers/video/fbdev/goldfishfb.c | 2 +- > drivers/video/fbdev/grvga.c| 2 +- > drivers/video/fbdev/gxt4500.c | 2 +- > drivers/video/fbdev/hecubafb.c | 2 +- > drivers/video/fbdev/hgafb.c| 2 +- > drivers/video/fbdev/hitfb.c| 2 +- > drivers/video/fbdev/hpfb.c | 2 +- > drivers/video/fbdev/hyperv_fb.c| 2 +- > drivers/video/fbdev/i740fb.c | 2 +- > drivers/video/fbdev/imsttfb.c | 2 +- > drivers/video/fbdev/imxfb.c| 2 +- > drivers/video/fbdev/intelfb/intelfbdrv.c | 2 +- > drivers/video/fbdev/kyro/fbdev.c | 2 +- > drivers/video/fbdev/leo.c | 2 +- > drivers/video/fbdev/macfb.c| 2 +- > drivers/video/fbdev/matrox/matroxfb_crtc2.c| 2 +- > drivers/video/fbdev/maxinefb.c | 2 +- > drivers/video/fbdev/mbx/mbxfb.c| 2 +- > drivers/video/fbdev/metronomefb.c | 2 +- > drivers/video/fbdev/mmp/fb/mmpfb.c | 2 +- > drivers/video/fbdev/mx3fb.c| 5 +++-- > drivers/video/fbdev/neofb.c| 2 +- > drivers/video/fbdev/ocfb.c | 2 +- > drivers/video/fbdev/offb.c | 2 +- > drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 2 +- > drivers/video/fbdev/p9100.c| 2 +- > drivers/video/fbdev/platinumfb.c | 2 +- > drivers/video/fbdev/pm2fb.c| 2 +- > drivers/video/fbdev/pm3fb.c| 2 +- > drivers/video/fbdev/pmag-aa-fb.c | 2 +- > drivers/video/fbdev/pmag-ba-fb.c | 2 +- > drivers/video/fbdev/pmagb-b-fb.c | 2 +- > drivers/video/fbdev/ps3fb.c| 2 +- > drivers/video/fbdev/pvr2fb.c | 2 +- > drivers/video/fbdev/pxa168fb.c | 2 +- > drivers/video/fbdev/pxafb.c
[PATCH v4 6/7] drm/mediatek: support CMDQ interface in ddp component
The CMDQ (Command Queue) in MT8183 is used to help
update all relevant display controller registers
with critical time limation.
This patch add cmdq interface in ddp_comp interface,
let all ddp_comp interface can support cpu/cmdq function
at the same time.
Signed-off-by: YT Shen
Signed-off-by: CK Hu
Signed-off-by: Philipp Zabel
Signed-off-by: Bibby Hsieh
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_disp_color.c | 7 +-
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 65 +-
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 43 ---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 10 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 132 +++-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 31 +++--
6 files changed, 194 insertions(+), 94 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c
b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index 59de2a46aa49..6fb0d6983a4a 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include "mtk_drm_crtc.h"
#include "mtk_drm_ddp_comp.h"
@@ -45,12 +46,12 @@ static inline struct mtk_disp_color *comp_to_color(struct
mtk_ddp_comp *comp)
static void mtk_color_config(struct mtk_ddp_comp *comp, unsigned int w,
unsigned int h, unsigned int vrefresh,
-unsigned int bpc)
+unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
{
struct mtk_disp_color *color = comp_to_color(comp);
- writel(w, comp->regs + DISP_COLOR_WIDTH(color));
- writel(h, comp->regs + DISP_COLOR_HEIGHT(color));
+ mtk_ddp_write(cmdq_pkt, w, comp, DISP_COLOR_WIDTH(color));
+ mtk_ddp_write(cmdq_pkt, h, comp, DISP_COLOR_HEIGHT(color));
}
static void mtk_color_start(struct mtk_ddp_comp *comp)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 8a32248671c3..649e371dd9b7 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "mtk_drm_crtc.h"
#include "mtk_drm_ddp_comp.h"
@@ -125,14 +126,15 @@ static void mtk_ovl_stop(struct mtk_ddp_comp *comp)
static void mtk_ovl_config(struct mtk_ddp_comp *comp, unsigned int w,
unsigned int h, unsigned int vrefresh,
- unsigned int bpc)
+ unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
{
if (w != 0 && h != 0)
- writel_relaxed(h << 16 | w, comp->regs + DISP_REG_OVL_ROI_SIZE);
- writel_relaxed(0x0, comp->regs + DISP_REG_OVL_ROI_BGCLR);
+ mtk_ddp_write_relaxed(cmdq_pkt, h << 16 | w, comp,
+ DISP_REG_OVL_ROI_SIZE);
+ mtk_ddp_write_relaxed(cmdq_pkt, 0x0, comp, DISP_REG_OVL_ROI_BGCLR);
- writel(0x1, comp->regs + DISP_REG_OVL_RST);
- writel(0x0, comp->regs + DISP_REG_OVL_RST);
+ mtk_ddp_write(cmdq_pkt, 0x1, comp, DISP_REG_OVL_RST);
+ mtk_ddp_write(cmdq_pkt, 0x0, comp, DISP_REG_OVL_RST);
}
static unsigned int mtk_ovl_layer_nr(struct mtk_ddp_comp *comp)
@@ -176,16 +178,16 @@ static int mtk_ovl_layer_check(struct mtk_ddp_comp *comp,
unsigned int idx,
return 0;
}
-static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp, unsigned int idx)
+static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp, unsigned int idx,
+struct cmdq_pkt *cmdq_pkt)
{
- unsigned int reg;
unsigned int gmc_thrshd_l;
unsigned int gmc_thrshd_h;
unsigned int gmc_value;
struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
- writel(0x1, comp->regs + DISP_REG_OVL_RDMA_CTRL(idx));
-
+ mtk_ddp_write(cmdq_pkt, 0x1, comp,
+ DISP_REG_OVL_RDMA_CTRL(idx));
gmc_thrshd_l = GMC_THRESHOLD_LOW >>
(GMC_THRESHOLD_BITS - ovl->data->gmc_bits);
gmc_thrshd_h = GMC_THRESHOLD_HIGH >>
@@ -195,22 +197,19 @@ static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp,
unsigned int idx)
else
gmc_value = gmc_thrshd_l | gmc_thrshd_l << 8 |
gmc_thrshd_h << 16 | gmc_thrshd_h << 24;
- writel(gmc_value, comp->regs + DISP_REG_OVL_RDMA_GMC(idx));
-
- reg = readl(comp->regs + DISP_REG_OVL_SRC_CON);
- reg = reg | BIT(idx);
- writel(reg, comp->regs + DISP_REG_OVL_SRC_CON);
+ mtk_ddp_write(cmdq_pkt, gmc_value,
+ comp, DISP_REG_OVL_RDMA_GMC(idx));
+ mtk_ddp_write_mask(cmdq_pkt, BIT(idx), comp,
+ DISP_REG_OVL_SRC_CON, BIT(idx));
}
-static void mtk_ovl_layer_off(struct mtk_ddp_comp *comp, unsigned int idx)
+static void mtk_ovl_layer_off(struct mtk_ddp_comp *comp, unsigned int idx,
+ struct cmdq_pkt *cmdq_pkt)
{
- unsigned
[PATCH v4 2/7] drm/mediatek: handle events when enabling/disabling crtc
The driver currently handles vblank events only when updating planes on
an already enabled CRTC. The atomic update API however allows requesting
an event when enabling or disabling a CRTC. This currently leads to
event objects being leaked in the kernel and to events not being sent
out. Fix it.
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index f5eeb0eebf76..4bc52346093d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -338,6 +338,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc)
static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
{
struct drm_device *drm = mtk_crtc->base.dev;
+ struct drm_crtc *crtc = &mtk_crtc->base;
int i;
DRM_DEBUG_DRIVER("%s\n", __func__);
@@ -364,6 +365,13 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
*mtk_crtc)
mtk_ddp_comp_unprepare(mtk_crtc->ddp_comp[i]);
pm_runtime_put(drm->dev);
+
+ if (crtc->state->event && !crtc->state->active) {
+ spin_lock_irq(&crtc->dev->event_lock);
+ drm_crtc_send_vblank_event(crtc, crtc->state->event);
+ crtc->state->event = NULL;
+ spin_unlock_irq(&crtc->dev->event_lock);
+ }
}
static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/7] drm/mediatek: fix cursor issue and apply CMDQ in MTK DRM
The CMDQ (Command Queue) in MT8183 is used to help update all relevant display controller registers with critical time limation. This patch add cmdq interface in ddp_comp interface, let all ddp_comp interface can support cpu/cmdq function at the same time. These patches also can fixup cursor moving is not smooth when heavy load in webgl. This patch depends on ptach: add drm support for MT8183 (https://patchwork.kernel.org/cover/11121519/) support gce on mt8183 platform (https://patchwork.kernel.org/cover/11255147) drm/mediatek: Refactor plane init/check and support rotation (https://pw-emeril.freedesktop.org/series/69015/) drm/mediatek: Check return value of mtk_drm_ddp_comp_for_plane (https://lore.kernel.org/patchwork/patch/1154517/) Changes since v3: - remove redundant code and variable Changes since v2: - move some changes to another patch - disable layer in atomic_disable() Changes since v1: - remove redundant code - merge the duplicate code - use async instead of cursor Changes since v0: - remove redundant code - remove patch "drm/mediatek: fix atomic_state reference counting" After remove this patch, the issue we met before is gone. So I do not add any extra code to do something. Bibby Hsieh (7): drm/mediatek: use DRM core's atomic commit helper drm/mediatek: handle events when enabling/disabling crtc drm/mediatek: update cursors by using async atomic update drm/mediatek: disable all the planes in atomic_disable drm/mediatek: remove unused external function drm/mediatek: support CMDQ interface in ddp component drm/mediatek: apply CMDQ control flow drivers/gpu/drm/mediatek/mtk_disp_color.c | 7 +- drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 67 drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 43 ++--- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 165 drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 132 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 47 +++--- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 86 +- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 - drivers/gpu/drm/mediatek/mtk_drm_plane.c| 47 ++ drivers/gpu/drm/mediatek/mtk_drm_plane.h| 2 + 11 files changed, 381 insertions(+), 224 deletions(-) -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 7/7] drm/mediatek: apply CMDQ control flow
Unlike other SoCs, MT8183 does not have "shadow"
registers for performaing an atomic video mode
set or page flip at vblank/vsync.
The CMDQ (Commend Queue) in MT8183 is used to help
update all relevant display controller registers
with critical time limation.
Signed-off-by: YT Shen
Signed-off-by: CK Hu
Signed-off-by: Philipp Zabel
Signed-off-by: Bibby Hsieh
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 56 +
1 file changed, 49 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 8c6231ed6f55..496dffe962af 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -12,6 +12,8 @@
#include
#include
#include
+#include
+#include
#include "mtk_drm_drv.h"
#include "mtk_drm_crtc.h"
@@ -43,6 +45,9 @@ struct mtk_drm_crtc {
boolpending_planes;
boolpending_async_planes;
+ struct cmdq_client *cmdq_client;
+ u32 cmdq_event;
+
void __iomem*config_regs;
const struct mtk_mmsys_reg_data *mmsys_reg_data;
struct mtk_disp_mutex *mutex;
@@ -234,6 +239,13 @@ struct mtk_ddp_comp *mtk_drm_ddp_comp_for_plane(struct
drm_crtc *crtc,
return NULL;
}
+#ifdef CONFIG_MTK_CMDQ
+static void ddp_cmdq_cb(struct cmdq_cb_data data)
+{
+ cmdq_pkt_destroy(data.data);
+}
+#endif
+
static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
{
struct drm_crtc *crtc = &mtk_crtc->base;
@@ -378,7 +390,8 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
*mtk_crtc)
}
}
-static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
+static void mtk_crtc_ddp_config(struct drm_crtc *crtc,
+ struct cmdq_pkt *cmdq_handle)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
@@ -394,7 +407,8 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
if (state->pending_config) {
mtk_ddp_comp_config(comp, state->pending_width,
state->pending_height,
- state->pending_vrefresh, 0, NULL);
+ state->pending_vrefresh, 0,
+ cmdq_handle);
state->pending_config = false;
}
@@ -414,7 +428,8 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
if (comp)
mtk_ddp_comp_layer_config(comp, local_layer,
- plane_state, NULL);
+ plane_state,
+ cmdq_handle);
plane_state->pending.config = false;
}
mtk_crtc->pending_planes = false;
@@ -435,7 +450,8 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
if (comp)
mtk_ddp_comp_layer_config(comp, local_layer,
- plane_state, NULL);
+ plane_state,
+ cmdq_handle);
plane_state->pending.async_config = false;
}
mtk_crtc->pending_async_planes = false;
@@ -444,6 +460,7 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
{
+ struct cmdq_pkt *cmdq_handle;
struct drm_crtc *crtc = &mtk_crtc->base;
struct mtk_drm_private *priv = crtc->dev->dev_private;
unsigned int pending_planes = 0, pending_async_planes = 0;
@@ -472,9 +489,18 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc
*mtk_crtc)
if (priv->data->shadow_register) {
mtk_disp_mutex_acquire(mtk_crtc->mutex);
- mtk_crtc_ddp_config(crtc);
+ mtk_crtc_ddp_config(crtc, NULL);
mtk_disp_mutex_release(mtk_crtc->mutex);
}
+#ifdef CONFIG_MTK_CMDQ
+ if (mtk_crtc->cmdq_client) {
+ cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
+ cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
+ cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
+ mtk_crtc_ddp_config(crtc, cmdq_handle);
+ cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
+ }
+#endif
mutex_unlock(&mtk_crtc->hw_lock);
}
@@ -643,8 +669,8 @@ void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct
mtk_ddp_comp *comp)
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
[PATCH v4 5/7] drm/mediatek: remove unused external function
layer_on and layer_off both are unused external function,
remove them from mtk_ddp_comp_funcs structure.
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 2 --
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 16
2 files changed, 18 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 722a5adb79dc..8a32248671c3 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -314,8 +314,6 @@ static const struct mtk_ddp_comp_funcs mtk_disp_ovl_funcs =
{
.disable_vblank = mtk_ovl_disable_vblank,
.supported_rotations = mtk_ovl_supported_rotations,
.layer_nr = mtk_ovl_layer_nr,
- .layer_on = mtk_ovl_layer_on,
- .layer_off = mtk_ovl_layer_off,
.layer_check = mtk_ovl_layer_check,
.layer_config = mtk_ovl_layer_config,
.bgclr_in_on = mtk_ovl_bgclr_in_on,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 19a955ab0748..dbfb90e9b9cf 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -81,8 +81,6 @@ struct mtk_ddp_comp_funcs {
void (*unprepare)(struct mtk_ddp_comp *comp);
unsigned int (*supported_rotations)(struct mtk_ddp_comp *comp);
unsigned int (*layer_nr)(struct mtk_ddp_comp *comp);
- void (*layer_on)(struct mtk_ddp_comp *comp, unsigned int idx);
- void (*layer_off)(struct mtk_ddp_comp *comp, unsigned int idx);
int (*layer_check)(struct mtk_ddp_comp *comp,
unsigned int idx,
struct mtk_plane_state *state);
@@ -165,20 +163,6 @@ static inline unsigned int mtk_ddp_comp_layer_nr(struct
mtk_ddp_comp *comp)
return 0;
}
-static inline void mtk_ddp_comp_layer_on(struct mtk_ddp_comp *comp,
-unsigned int idx)
-{
- if (comp->funcs && comp->funcs->layer_on)
- comp->funcs->layer_on(comp, idx);
-}
-
-static inline void mtk_ddp_comp_layer_off(struct mtk_ddp_comp *comp,
- unsigned int idx)
-{
- if (comp->funcs && comp->funcs->layer_off)
- comp->funcs->layer_off(comp, idx);
-}
-
static inline int mtk_ddp_comp_layer_check(struct mtk_ddp_comp *comp,
unsigned int idx,
struct mtk_plane_state *state)
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/7] drm/mediatek: disable all the planes in atomic_disable
Under shadow register case, we do not disable all the plane before disable all the hardwares. Fix it. Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c index e887a6877bcd..e40c8cf7d74f 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c @@ -550,6 +550,7 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc *crtc, } mtk_crtc->pending_planes = true; + mtk_drm_crtc_hw_config(mtk_crtc); /* Wait for planes to be disabled */ drm_crtc_wait_one_vblank(crtc); -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/7] drm/mediatek: use DRM core's atomic commit helper
The DRM core atomic helper now supports asynchronous commits natively.
The custom drm implementation isn't needed anymore, remove it.
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 86 ++
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 ---
2 files changed, 5 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 6588dc6dd5e3..16e5771d182e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -36,89 +36,14 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
-static void mtk_atomic_schedule(struct mtk_drm_private *private,
- struct drm_atomic_state *state)
-{
- private->commit.state = state;
- schedule_work(&private->commit.work);
-}
-
-static void mtk_atomic_complete(struct mtk_drm_private *private,
- struct drm_atomic_state *state)
-{
- struct drm_device *drm = private->drm;
-
- drm_atomic_helper_wait_for_fences(drm, state, false);
-
- /*
-* Mediatek drm supports runtime PM, so plane registers cannot be
-* written when their crtc is disabled.
-*
-* The comment for drm_atomic_helper_commit states:
-* For drivers supporting runtime PM the recommended sequence is
-*
-* drm_atomic_helper_commit_modeset_disables(dev, state);
-* drm_atomic_helper_commit_modeset_enables(dev, state);
-* drm_atomic_helper_commit_planes(dev, state,
-* DRM_PLANE_COMMIT_ACTIVE_ONLY);
-*
-* See the kerneldoc entries for these three functions for more details.
-*/
- drm_atomic_helper_commit_modeset_disables(drm, state);
- drm_atomic_helper_commit_modeset_enables(drm, state);
- drm_atomic_helper_commit_planes(drm, state,
- DRM_PLANE_COMMIT_ACTIVE_ONLY);
-
- drm_atomic_helper_wait_for_vblanks(drm, state);
-
- drm_atomic_helper_cleanup_planes(drm, state);
- drm_atomic_state_put(state);
-}
-
-static void mtk_atomic_work(struct work_struct *work)
-{
- struct mtk_drm_private *private = container_of(work,
- struct mtk_drm_private, commit.work);
-
- mtk_atomic_complete(private, private->commit.state);
-}
-
-static int mtk_atomic_commit(struct drm_device *drm,
-struct drm_atomic_state *state,
-bool async)
-{
- struct mtk_drm_private *private = drm->dev_private;
- int ret;
-
- ret = drm_atomic_helper_prepare_planes(drm, state);
- if (ret)
- return ret;
-
- mutex_lock(&private->commit.lock);
- flush_work(&private->commit.work);
-
- ret = drm_atomic_helper_swap_state(state, true);
- if (ret) {
- mutex_unlock(&private->commit.lock);
- drm_atomic_helper_cleanup_planes(drm, state);
- return ret;
- }
-
- drm_atomic_state_get(state);
- if (async)
- mtk_atomic_schedule(private, state);
- else
- mtk_atomic_complete(private, state);
-
- mutex_unlock(&private->commit.lock);
-
- return 0;
-}
+static const struct drm_mode_config_helper_funcs mtk_drm_mode_config_helpers =
{
+ .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
+};
static const struct drm_mode_config_funcs mtk_drm_mode_config_funcs = {
.fb_create = mtk_drm_mode_fb_create,
.atomic_check = drm_atomic_helper_check,
- .atomic_commit = mtk_atomic_commit,
+ .atomic_commit = drm_atomic_helper_commit,
};
static const enum mtk_ddp_comp_id mt2701_mtk_ddp_main[] = {
@@ -265,6 +190,7 @@ static int mtk_drm_kms_init(struct drm_device *drm)
drm->mode_config.max_width = 4096;
drm->mode_config.max_height = 4096;
drm->mode_config.funcs = &mtk_drm_mode_config_funcs;
+ drm->mode_config.helper_private = &mtk_drm_mode_config_helpers;
ret = component_bind_all(drm->dev, drm);
if (ret)
@@ -540,8 +466,6 @@ static int mtk_drm_probe(struct platform_device *pdev)
if (!private)
return -ENOMEM;
- mutex_init(&private->commit.lock);
- INIT_WORK(&private->commit.work, mtk_atomic_work);
private->data = of_device_get_match_data(dev);
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index b6a82728d563..9f4ce60174f6 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -46,13 +46,6 @@ struct mtk_drm_private {
struct device_node *comp_node[DDP_COMPONENT_ID_MAX];
struct mtk_ddp_comp *ddp_comp[DDP_COMPONENT_ID_MAX];
const struct mtk_mmsys_driver_data *data;
-
-
[PATCH v4 3/7] drm/mediatek: update cursors by using async atomic update
Support to async updates of cursors by using the new atomic
interface for that.
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 98 +++-
drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 +
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 47
drivers/gpu/drm/mediatek/mtk_drm_plane.h | 2 +
4 files changed, 128 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 4bc52346093d..e887a6877bcd 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -41,12 +41,16 @@ struct mtk_drm_crtc {
struct drm_plane*planes;
unsigned intlayer_nr;
boolpending_planes;
+ boolpending_async_planes;
void __iomem*config_regs;
const struct mtk_mmsys_reg_data *mmsys_reg_data;
struct mtk_disp_mutex *mutex;
unsigned intddp_comp_nr;
struct mtk_ddp_comp **ddp_comp;
+
+ /* lock for display hardware access */
+ struct mutexhw_lock;
};
struct mtk_crtc_state {
@@ -415,6 +419,63 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
}
mtk_crtc->pending_planes = false;
}
+
+ if (mtk_crtc->pending_async_planes) {
+ for (i = 0; i < mtk_crtc->layer_nr; i++) {
+ struct drm_plane *plane = &mtk_crtc->planes[i];
+ struct mtk_plane_state *plane_state;
+
+ plane_state = to_mtk_plane_state(plane->state);
+
+ if (!plane_state->pending.async_config)
+ continue;
+
+ comp = mtk_drm_ddp_comp_for_plane(crtc, plane,
+ &local_layer);
+
+ if (comp)
+ mtk_ddp_comp_layer_config(comp, local_layer,
+ plane_state);
+ plane_state->pending.async_config = false;
+ }
+ mtk_crtc->pending_async_planes = false;
+ }
+}
+
+static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
+{
+ struct drm_crtc *crtc = &mtk_crtc->base;
+ struct mtk_drm_private *priv = crtc->dev->dev_private;
+ unsigned int pending_planes = 0, pending_async_planes = 0;
+ int i;
+
+ mutex_lock(&mtk_crtc->hw_lock);
+ for (i = 0; i < mtk_crtc->layer_nr; i++) {
+ struct drm_plane *plane = &mtk_crtc->planes[i];
+ struct mtk_plane_state *plane_state;
+
+ plane_state = to_mtk_plane_state(plane->state);
+ if (plane_state->pending.dirty) {
+ plane_state->pending.config = true;
+ plane_state->pending.dirty = false;
+ pending_planes |= BIT(i);
+ } else if (plane_state->pending.async_dirty) {
+ plane_state->pending.async_config = true;
+ plane_state->pending.async_dirty = false;
+ pending_async_planes |= BIT(i);
+ }
+ }
+ if (pending_planes)
+ mtk_crtc->pending_planes = true;
+ if (pending_async_planes)
+ mtk_crtc->pending_async_planes = true;
+
+ if (priv->data->shadow_register) {
+ mtk_disp_mutex_acquire(mtk_crtc->mutex);
+ mtk_crtc_ddp_config(crtc);
+ mtk_disp_mutex_release(mtk_crtc->mutex);
+ }
+ mutex_unlock(&mtk_crtc->hw_lock);
}
int mtk_drm_crtc_plane_check(struct drm_crtc *crtc, struct drm_plane *plane,
@@ -429,6 +490,20 @@ int mtk_drm_crtc_plane_check(struct drm_crtc *crtc, struct
drm_plane *plane,
return 0;
}
+void mtk_drm_crtc_async_update(struct drm_crtc *crtc, struct drm_plane *plane,
+ struct drm_plane_state *new_state)
+{
+ struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+ const struct drm_plane_helper_funcs *plane_helper_funcs =
+ plane->helper_private;
+
+ if (!mtk_crtc->enabled)
+ return;
+
+ plane_helper_funcs->atomic_update(plane, new_state);
+ mtk_drm_crtc_hw_config(mtk_crtc);
+}
+
static void mtk_drm_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
@@ -510,34 +585,14 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc
*crtc,
struct drm_crtc_state *old_crtc_state)
{
struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
- struct mtk_drm_private *priv = crtc->dev->dev_private;
- unsigned int pending_planes = 0;
int i;
if (mtk_crtc-
[PULL] drm-intel-next-fixes
Hi Dave & Daniel, Final one for 5.5-rc1. A fix for EHL port D programming (DDI-D) and a couple of CI fixes for GEM contexts. This includes the GVT fixes PR with one command parser fix and one WARN splat fix. Regards, Joonas *** drm-intel-next-fixes-2019-12-05: - Includes gvt-next-fixes-2019-12-02 pull - Fixes for CI spotted eadlock and a race condition in GEM contexts - Fix for EHL port D programming The following changes since commit 3cc44feb9861d2f5267af9b962ae92c5ea1b48fd: drm/i915: Reduce nested prepare_remote_context() to a trylock (2019-11-27 10:12:19 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2019-12-05 for you to fetch changes up to 01bb630319337be15fc50c211126180198d4e157: drm/i915/ehl: Make icp_digital_port_connected() use phy instead of port (2019-12-03 13:06:05 +0200) - Includes gvt-next-fixes-2019-12-02 pull - Fixes for CI spotted eadlock and a race condition in GEM contexts - Fix for EHL port D programming Chris Wilson (1): drm/i915/gem: Take timeline->mutex to walk list-of-requests Gao, Fred (2): drm/i915/gvt: Refine non privilege register address calucation drm/i915/gvt: Update force-to-nonpriv register whitelist Joonas Lahtinen (1): Merge tag 'gvt-next-fixes-2019-12-02' of https://github.com/intel/gvt-linux into drm-intel-next-fixes Matt Roper (1): drm/i915/ehl: Make icp_digital_port_connected() use phy instead of port Zhenyu Wang (1): drm/i915/gvt: Fix cmd length check for MI_ATOMIC drivers/gpu/drm/i915/display/intel_dp.c | 12 +--- drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++-- drivers/gpu/drm/i915/gvt/cmd_parser.c | 6 +++--- drivers/gpu/drm/i915/gvt/handlers.c | 5 +++-- 4 files changed, 13 insertions(+), 14 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dt-bindings: display: Add obsolete note to "ti,tilcdc,panel" binding
On 05/12/2019 10:46, Laurent Pinchart wrote: > Hi Jyri, > > Thank you for the patch. > > On Wed, Dec 04, 2019 at 07:53:11PM +0200, Jyri Sarha wrote: >> The "ti,tilcdc,panel" binding should not be used anymore, since tilcdc >> is fully capable of using generic drm panels like panel-simple and >> panel-common binding. However, the obsolete binding is still widely >> used in many mainline supported platforms that I do not have access to >> and who knows how many custom platforms. So I am afraid we have to >> keep the old bundled tilcdc panel driver around. >> >> Signed-off-by: Jyri Sarha >> --- >> Documentation/devicetree/bindings/display/tilcdc/panel.txt | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/display/tilcdc/panel.txt >> b/Documentation/devicetree/bindings/display/tilcdc/panel.txt >> index 808216310ea2..54963f9173cc 100644 >> --- a/Documentation/devicetree/bindings/display/tilcdc/panel.txt >> +++ b/Documentation/devicetree/bindings/display/tilcdc/panel.txt >> @@ -1,5 +1,11 @@ >> Device-Tree bindings for tilcdc DRM generic panel output driver >> >> +NOTE: This binding (and the related driver) is obsolete and should not >> + be used anymore. Please refer to drm panel-common binding (and >> + to a generic drm panel driver like panel-simple). >> + Documentation/devicetree/bindings/display/panel/panel-common.yaml >> + (drivers/gpu/drm/panel/panel-simple.c) >> + > > How about adding a WARN_ON() in the code when this binding is used ? > This could help getting those platforms converted. > I don't see why not, I'll add that. Thanks Jyro >> Required properties: >> - compatible: value should be "ti,tilcdc,panel". >> - panel-info: configuration info to configure LCDC correctly for the panel > -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mgag200: Call mgag200_driver_{load, unload}() before registering device
The load/unload callbacks in struct drm_driver are deprecated. Remove
them and call functions explicitly.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 44 +++
1 file changed, 38 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index d43951caeea0..30b3b827adf8 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -6,13 +6,13 @@
* Dave Airlie
*/
-#include
#include
+#include
+#include
#include
#include
#include
-#include
#include
#include "mgag200_drv.h"
@@ -48,16 +48,50 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
static int mga_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
{
+ struct drm_device *dev;
+ int ret;
+
drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, "mgag200drmfb");
- return drm_get_pci_dev(pdev, ent, &driver);
+ ret = pci_enable_device(pdev);
+ if (ret)
+ return ret;
+
+ dev = drm_dev_alloc(&driver, &pdev->dev);
+ if (IS_ERR(dev)) {
+ ret = PTR_ERR(dev);
+ goto err_pci_disable_device;
+ }
+
+ dev->pdev = pdev;
+ pci_set_drvdata(pdev, dev);
+
+ ret = mgag200_driver_load(dev, ent->driver_data);
+ if (ret)
+ goto err_drm_dev_put;
+
+ ret = drm_dev_register(dev, ent->driver_data);
+ if (ret)
+ goto err_mgag200_driver_unload;
+
+ return 0;
+
+err_mgag200_driver_unload:
+ mgag200_driver_unload(dev);
+err_drm_dev_put:
+ drm_dev_put(dev);
+err_pci_disable_device:
+ pci_disable_device(pdev);
+ return ret;
}
static void mga_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
- drm_put_dev(dev);
+ drm_dev_unregister(dev);
+ mgag200_driver_unload(dev);
+ drm_dev_put(dev);
}
DEFINE_DRM_GEM_FOPS(mgag200_driver_fops);
@@ -93,8 +127,6 @@ int mgag200_driver_dumb_create(struct drm_file *file,
static struct drm_driver driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET,
- .load = mgag200_driver_load,
- .unload = mgag200_driver_unload,
.fops = &mgag200_driver_fops,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/dp_mst: Remove VCPI while disabling topology mgr
[Why]
This patch is trying to address the issue observed when hotplug DP
daisy chain monitors.
e.g.
src-mstb-mstb-sst -> src (unplug) mstb-mstb-sst -> src-mstb-mstb-sst
(plug in again)
Once unplug a DP MST capable device, driver will call
drm_dp_mst_topology_mgr_set_mst() to disable MST. In this function,
it cleans data of topology manager while disabling mst_state. However,
it doesn't clean up the proposed_vcpis of topology manager.
If proposed_vcpi is not reset, once plug in MST daisy chain monitors
later, code will fail at checking port validation while trying to
allocate payloads.
When MST capable device is plugged in again and try to allocate
payloads by calling drm_dp_update_payload_part1(), this
function will iterate over all proposed virtual channels to see if
any proposed VCPI's num_slots is greater than 0. If any proposed
VCPI's num_slots is greater than 0 and the port which the
specific virtual channel directed to is not in the topology, code then
fails at the port validation. Since there are stale VCPI allocations
from the previous topology enablement in proposed_vcpi[], code will fail
at port validation and reurn EINVAL.
[How]
Clean up the data of stale proposed_vcpi[] and reset mgr->proposed_vcpis
to NULL while disabling mst in drm_dp_mst_topology_mgr_set_mst().
Changes since v1:
*Add on more details in commit message to describe the issue which the
patch is trying to fix
Signed-off-by: Wayne Lin
---
drivers/gpu/drm/drm_dp_mst_topology.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index ae5809a1f19a..bf4f745a4edb 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3386,6 +3386,7 @@ static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8
dp_link_count)
int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool
mst_state)
{
int ret = 0;
+ int i = 0;
struct drm_dp_mst_branch *mstb = NULL;
mutex_lock(&mgr->lock);
@@ -3446,10 +3447,21 @@ int drm_dp_mst_topology_mgr_set_mst(struct
drm_dp_mst_topology_mgr *mgr, bool ms
/* this can fail if the device is gone */
drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL, 0);
ret = 0;
+ mutex_lock(&mgr->payload_lock);
memset(mgr->payloads, 0, mgr->max_payloads * sizeof(struct
drm_dp_payload));
mgr->payload_mask = 0;
set_bit(0, &mgr->payload_mask);
+ for (i = 0; i < mgr->max_payloads; i++) {
+ struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
+
+ if (vcpi) {
+ vcpi->vcpi = 0;
+ vcpi->num_slots = 0;
+ }
+ mgr->proposed_vcpis[i] = NULL;
+ }
mgr->vcpi_mask = 0;
+ mutex_unlock(&mgr->payload_lock);
}
out_unlock:
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/komeda: Enable new product D32 support
On Tue, Dec 03, 2019 at 09:59:57AM +, Mihail Atanassov wrote:
> On Tuesday, 3 December 2019 06:46:06 GMT james qian wang (Arm Technology
> China) wrote:
> > On Mon, Dec 02, 2019 at 11:07:52AM +, Mihail Atanassov wrote:
> > > On Thursday, 21 November 2019 08:17:45 GMT james qian wang (Arm
> > > Technology China) wrote:
> > > > D32 is simple version of D71, the difference is:
> > > > - Only has one pipeline
> > > > - Drop the periph block and merge it to GCU
> > > >
> > > > v2: Rebase.
> > > >
> > > > Signed-off-by: James Qian Wang (Arm Technology China)
> > > >
> > > > ---
> > > > .../drm/arm/display/include/malidp_product.h | 3 +-
> > > > .../arm/display/komeda/d71/d71_component.c| 2 +-
> > > > .../gpu/drm/arm/display/komeda/d71/d71_dev.c | 43 ---
> > > > .../gpu/drm/arm/display/komeda/d71/d71_regs.h | 13 ++
> > > > .../gpu/drm/arm/display/komeda/komeda_drv.c | 1 +
> > > > 5 files changed, 44 insertions(+), 18 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/arm/display/include/malidp_product.h
> > > > b/drivers/gpu/drm/arm/display/include/malidp_product.h
> > > > index 96e2e4016250..dbd3d4765065 100644
> > > > --- a/drivers/gpu/drm/arm/display/include/malidp_product.h
> > > > +++ b/drivers/gpu/drm/arm/display/include/malidp_product.h
> > > > @@ -18,7 +18,8 @@
> > > > #define MALIDP_CORE_ID_STATUS(__core_id) (((__u32)(__core_id)) &
> > > > 0xFF)
> > > >
> > > > /* Mali-display product IDs */
> > > > -#define MALIDP_D71_PRODUCT_ID 0x0071
> > > > +#define MALIDP_D71_PRODUCT_ID 0x0071
> > > > +#define MALIDP_D32_PRODUCT_ID 0x0032
> > > >
> > > > union komeda_config_id {
> > > > struct {
> > > > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > > b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > > index 6dadf4413ef3..c7f7e9c545c7 100644
> > > > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > > > @@ -1274,7 +1274,7 @@ static int d71_timing_ctrlr_init(struct d71_dev
> > > > *d71,
> > > >
> > > > ctrlr = to_ctrlr(c);
> > > >
> > > > - ctrlr->supports_dual_link = true;
> > > > + ctrlr->supports_dual_link = d71->supports_dual_link;
> > > >
> > > > return 0;
> > > > }
> > > > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > > b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > > index 9b3bf353b6cc..2d429e310e5b 100644
> > > > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > > > @@ -371,23 +371,33 @@ static int d71_enum_resources(struct komeda_dev
> > > > *mdev)
> > > > goto err_cleanup;
> > > > }
> > > >
> > > > - /* probe PERIPH */
> > > > + /* Only the legacy HW has the periph block, the newer merges
> > > > the periph
> > > > +* into GCU
> > > > +*/
> > > > value = malidp_read32(d71->periph_addr, BLK_BLOCK_INFO);
> > > > - if (BLOCK_INFO_BLK_TYPE(value) != D71_BLK_TYPE_PERIPH) {
> > > > - DRM_ERROR("access blk periph but got blk: %d.\n",
> > > > - BLOCK_INFO_BLK_TYPE(value));
> > > > - err = -EINVAL;
> > > > - goto err_cleanup;
> > > > + if (BLOCK_INFO_BLK_TYPE(value) != D71_BLK_TYPE_PERIPH)
> > > > + d71->periph_addr = NULL;
> > > > +
> > > > + if (d71->periph_addr) {
> > > > + /* probe PERIPHERAL in legacy HW */
> > > > + value = malidp_read32(d71->periph_addr,
> > > > PERIPH_CONFIGURATION_ID);
> > > > +
> > > > + d71->max_line_size = value & PERIPH_MAX_LINE_SIZE
> > > > ? 4096 : 2048;
> > > > + d71->max_vsize = 4096;
> > > > + d71->num_rich_layers= value &
> > > > PERIPH_NUM_RICH_LAYERS ? 2 : 1;
> > > > + d71->supports_dual_link = !!(value & PERIPH_SPLIT_EN);
> > > > + d71->integrates_tbu = !!(value & PERIPH_TBU_EN);
> > > > + } else {
> > > > + value = malidp_read32(d71->gcu_addr,
> > > > GCU_CONFIGURATION_ID0);
> > > > + d71->max_line_size = GCU_MAX_LINE_SIZE(value);
> > > > + d71->max_vsize = GCU_MAX_NUM_LINES(value);
> > > > +
> > > > + value = malidp_read32(d71->gcu_addr,
> > > > GCU_CONFIGURATION_ID1);
> > > > + d71->num_rich_layers= GCU_NUM_RICH_LAYERS(value);
> > > > + d71->supports_dual_link = GCU_DISPLAY_SPLIT_EN(value);
> > > > + d71->integrates_tbu = GCU_DISPLAY_TBU_EN(value);
> > > > }
> > > >
> > > > - value = malidp_read32(d71->periph_addr,
> > > > PERIPH_CONFIGURATION_ID);
> > > > -
> > > > - d71->max_line_size = value & PERIPH_MAX_LINE_SIZE ? 4096 :
> > > > 2048;
> > > > - d71->max_vsize = 4096;
> > > > -
