On Tue, Nov 02, 2021 at 08:58:55AM -0700, Chia-I Wu wrote:
> On Tue, Nov 2, 2021 at 6:07 AM Gerd Hoffmann wrote:
> >
> > On Tue, Nov 02, 2021 at 12:31:39PM +0100, Maksym Wezdecki wrote:
> > > From: mwezdeck
> > >
> > > The idea behind the commit:
> > > 1. not pin the pages during resource_creat
Ping, Alex do you have a moment for that one here?
Am 28.10.21 um 15:26 schrieb Christian König:
Don't touch the exclusive fence manually here, but rather use the
general dma_resv function. We did that for better hw reset handling but
this doesn't necessary work correctly.
Signed-off-by: Christ
On 11/3/21 8:48 AM, Jiasheng Jiang wrote:
As we see in the drm_connector_list_iter_next(), it could return
NULL. In order to avoid the use of the NULL pointer, it may be
better to check the return value.
Fixes: c42001e ("drm: mxsfb: Use drm_panel_bridge")
Signed-off-by: Jiasheng Jiang
---
dri
As we see in the drm_connector_list_iter_next(), it could return
NULL. In order to avoid the use of the NULL pointer, it may be
better to check the return value.
Fixes: c42001e ("drm: mxsfb: Use drm_panel_bridge")
Signed-off-by: Jiasheng Jiang
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 ++
1 file
Hi
Am 03.11.21 um 01:12 schrieb Anand K. Mistry:
Any movement on merging this patch? Not urgent on my end (we have this
patch in our tree), but I think other amd users might run into this
UAF.
Thanks for reminding. I've merged your patch into drm-misc-fixes.
Best regards
Thomas
On Thu, 30
On 02/11/2021 15:59, Maxime Ripard wrote:
> A lot of drivers open-code the HDMI 1.4 maximum pixel rate in their
> driver to test whether the resolutions are supported or if the
> scrambling needs to be enabled.
>
> Let's create a common define for everyone to use it.
>
> Cc: Alex Deucher
> Cc: a
https://bugzilla.kernel.org/show_bug.cgi?id=214029
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resol
[AMD Official Use Only]
Hi Jani:
> -Original Message-
> From: Jani Nikula
> Sent: Tuesday, November 2, 2021 4:40 PM
> To: Yuan, Perry ; Maarten Lankhorst
> ; Maxime Ripard ;
> Thomas Zimmermann ; David Airlie ;
> Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.ker
On Tue, Nov 02, 2021 at 03:59:32PM +0100, Maxime Ripard wrote:
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4966,7 +4966,7 @@ static void drm_parse_hdmi_forum_vsdb(struct
> drm_connector *connector,
> u32 max_tmds_clock = hf_vsdb[5] * 5000;
>
This patch series introduces failsafe migration blits.
The reason for this seemingly strange concept is that if the initial
clearing or readback of LMEM fails for some reason[1], and we then set up
either GPU- or CPU ptes to the allocated LMEM, we can expose old
contents from other clients.
So aft
We are about to introduce failsafe- and asynchronous migration and
ttm moves.
This will add complexity and code to the TTM move code so it makes sense
to split it out to a separate file to make the i915 TTM code easer to
digest.
Split the i915 TTM move code out and since we will have to change the
If the initial fill blit or copy blit of an object fails, the old
content of the data might be exposed and read as soon as either CPU- or
GPU PTEs are set up to point at the pages.
Intercept the blit fence with an async callback that checks the
blit fence for errors and if there are errors perform
From: mwezdeck
Pinning pages happens in virtio_gpu_object_shmem_init()
function.
This ioctl allows to pin pages if it was not done earlier.
Signed-off-by: mwezdeck
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 5 +++-
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 11
drivers/gpu/drm/vir
First patch implements new ioctl. If there are no pages pinned
to bo object, then pin it.
Second patch implements concepts of lazy pin. Userspace
must opt-in for not pinning pages.
I would like to record this work here and investigate another
possibility.
Mainly, problem statement for this two
From: mwezdeck
Userspace can opt-in to not pin pages during resource
create ioctl.
In transfer_*_host and map ioctls check if memory is pinned.
If pages are not pinned, pin it. Otherwise, do nothing.
This change is transparent to userspace.
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 9
On Wed, 03 Nov 2021, "Yuan, Perry" wrote:
> [AMD Official Use Only]
>
> Hi Jani:
>
>> -Original Message-
>> From: Jani Nikula
>> Sent: Tuesday, November 2, 2021 4:40 PM
>> To: Yuan, Perry ; Maarten Lankhorst
>> ; Maxime Ripard ;
>> Thomas Zimmermann ; David Airlie ;
>> Daniel Vetter
>> C
On 01/11/2021 05:20, Bert Schiettecatte wrote:
> Hi John
>
>> Coincidentally, I've been looking at Panfrost on RK3288 this week as
>> well! I'm testing it with a project that has been using the binary blob
>> driver for several years and unfortunately Panfrost seems to use ~15%
>> more CPU.
>> L
The comment mentions that the KMS is enabled by default unless either the
i915.modeset module parameter or vga_text_mode_force boot option are used.
But the latter does not exist and instead the nomodeset option was meant.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/i915/i915_m
[ resend with all relevant people as Cc now, sorry to others for the spam ]
There is a lot of historical baggage on this parameter. It's defined in
the vgacon driver as a "nomodeset" parameter, but it's handler function is
called text_mode() that sets a variable named vgacon_text_mode_force whose
This function is used by some DRM drivers to determine if the "nomodeset"
kernel command line parameter was set and prevent these drivers to probe.
But the function name is quite confusing and does not reflect what really
the drivers are testing when calling it. Use a better naming now that it
is
Em ter., 2 de nov. de 2021 às 05:39, Geert Uytterhoeven
escreveu:
>
> Hi Maíra,
>
> On Sat, Oct 30, 2021 at 3:35 PM Maíra Canal wrote:
> > Remove legacy PWM interface (pwm_config, pwm_enable, pwm_disable) and
> > replace it for the atomic PWM API.
> >
> > Signed-off-by: Maíra Canal
>
> Thanks fo
DRM drivers can use this to determine whether they can be enabled or not.
For now it's just a wrapper around drm_modeset_disabled() but having the
indirection level will allow to add other conditions besides "nomodeset".
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
--
The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
but the exported vgacon_text_force() symbol is only used by DRM drivers.
It makes much more sense for the parameter logic to be in the subsystem
of the drivers that are making use of it. Let's move that to DRM.
Suggested-by:
Hi
Am 03.11.21 um 13:28 schrieb Javier Martinez Canillas:
The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
but the exported vgacon_text_force() symbol is only used by DRM drivers.
It makes much more sense for the parameter logic to be in the subsystem
of the drivers that
On Wed, 03 Nov 2021, Javier Martinez Canillas wrote:
> The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
> but the exported vgacon_text_force() symbol is only used by DRM drivers.
>
> It makes much more sense for the parameter logic to be in the subsystem
> of the drivers th
Hi
Am 03.11.21 um 13:28 schrieb Javier Martinez Canillas:
This function is used by some DRM drivers to determine if the "nomodeset"
kernel command line parameter was set and prevent these drivers to probe.
But the function name is quite confusing and does not reflect what really
the drivers are
Hi
Am 03.11.21 um 13:28 schrieb Javier Martinez Canillas:
[ resend with all relevant people as Cc now, sorry to others for the spam ]
There is a lot of historical baggage on this parameter. It's defined in
the vgacon driver as a "nomodeset" parameter, but it's handler function is
called text_mo
Hello Thomas,
On 11/3/21 13:41, Thomas Zimmermann wrote:
> Hi
>
> Am 03.11.21 um 13:28 schrieb Javier Martinez Canillas:
>> The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
>> but the exported vgacon_text_force() symbol is only used by DRM drivers.
>>
>> It makes much more
Hello Jani,
On 11/3/21 13:56, Jani Nikula wrote:
[snip]
>>
>> +obj-y += drm_nomodeset.o
>
> This is a subtle functional change. With this, you'll always have
> __setup("nomodeset", text_mode) builtin and the parameter available. And
> using nomodeset will print out the pr_warn() splat from te
On Wed, 03 Nov 2021, Javier Martinez Canillas wrote:
> The comment mentions that the KMS is enabled by default unless either the
> i915.modeset module parameter or vga_text_mode_force boot option are used.
>
> But the latter does not exist and instead the nomodeset option was meant.
>
> Signed-off
On Wed, 03 Nov 2021, Javier Martinez Canillas wrote:
> DRM drivers can use this to determine whether they can be enabled or not.
>
> For now it's just a wrapper around drm_modeset_disabled() but having the
> indirection level will allow to add other conditions besides "nomodeset".
>
> Suggested-by
Hi
Am 03.11.21 um 14:41 schrieb Jani Nikula:
On Wed, 03 Nov 2021, Javier Martinez Canillas wrote:
DRM drivers can use this to determine whether they can be enabled or not.
For now it's just a wrapper around drm_modeset_disabled() but having the
indirection level will allow to add other condit
This is a super awkward way to resend a patch series. Next time, just
start a new thread and put [PATCH RESEND] in the subject.
I am sorry that no one responded to your thread. :/
regards,
dan carpenter
On 11/3/21 13:57, Thomas Zimmermann wrote:
[snip]
>>
>> -if (vgacon_text_force()) {
>> +if (drm_modeset_disabled()) {
>> DRM_ERROR("amdgpu kernel modesetting disabled.\n");
>
> Please remove all such error messages from drivers.
> drm_modeset_disabled() should print a un
https://bugzilla.kernel.org/show_bug.cgi?id=214859
--- Comment #6 from James Zhu (jam...@amd.com) ---
Created attachment 299437
--> https://bugzilla.kernel.org/attachment.cgi?id=299437&action=edit
analysis for this issue
Linux 5.14.15 + afd1818 can fix the issue.
Linux 5.15rc7 re-apply "init
On 2021-07-23 10:22, Christian König wrote:
> Am 23.07.21 um 10:19 schrieb Michel Dänzer:
>> On 2021-07-23 10:04 a.m., Christian König wrote:
>>> Am 23.07.21 um 09:58 schrieb Michel Dänzer:
From: Michel Dänzer
This makes sure we don't hit the
BUG_ON(dmabuf->cb_in.acti
[ Adding dri-devel ]
On 2021-11-01 16:00, Wang, Chao-kai (Stylon) wrote:
>
> The problem with -ERESTARTSYS is the same half-baked atomic state with
> modifications we made in the interrupted atomic check, is reused in the next
> retry and fails the atomic check. What we expect in the next ret
Hello Thomas,
On 11/3/21 14:01, Thomas Zimmermann wrote:
[snip]
>>
>>
>> Javier Martinez Canillas (5):
>>drm/i915: Fix comment about modeset parameters
>>drm: Move nomodeset kernel parameter handler to the DRM subsystem
>>drm: Rename vgacon_text_force() function to drm_modeset_disabl
Hi Leandro,
On 10/28/21 6:38 PM, Leandro Ribeiro wrote:
Hi,
On 10/26/21 08:34, Igor Torrente wrote:
Add a helper function to validate the connector configuration receive in
the encoder atomic_check by the drivers.
So the drivers don't need do these common validations themselves.
Signed-off-b
Hey Xin,
This series does not apply on drm-misc-next. Please fix this and
resend. Make sure that checkpatch --strict passes as well.
On Wed, 3 Nov 2021 at 15:20, Dan Carpenter wrote:
>
> This is a super awkward way to resend a patch series. Next time, just
> start a new thread and put [PATCH RE
https://bugzilla.kernel.org/show_bug.cgi?id=214029
Jan Steffens (jan.steff...@gmail.com) changed:
What|Removed |Added
CC||jan.steff...@gmail
On 2021-09-06 17:38, Uma Shankar wrote:
> Existing LUT precision structure is having only 16 bit
> precision. This is not enough for upcoming enhanced hardwares
> and advance usecases like HDR processing. Hence added a new
> structure with 32 bit precision values.
>
> This also defines a new st
On 2021-09-06 17:38, Uma Shankar wrote:
> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> planes have different capabilities, implemented respective
> structure for the HDR planes.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 52 ++
Hi,
On 11/3/21 12:03, Igor Torrente wrote:
> Hi Leandro,
>
> On 10/28/21 6:38 PM, Leandro Ribeiro wrote:
>> Hi,
>>
>> On 10/26/21 08:34, Igor Torrente wrote:
>>> Add a helper function to validate the connector configuration receive in
>>> the encoder atomic_check by the drivers.
>>>
>>> So the dr
Le mercredi 03 novembre 2021 à 11:37 +0800, Yunfei Dong a écrit :
> Width and height need to 64 bytes aligned when setting the format.
> Need to make sure all is 64 bytes align when use width and height to
> calculate buffer size.
>
> Signed-off-by: Yunfei Dong
> Change-Id: I39886b1a6b433c92565dd
Hi
Am 03.11.21 um 16:11 schrieb Leandro Ribeiro:
Hi,
On 11/3/21 12:03, Igor Torrente wrote:
Hi Leandro,
On 10/28/21 6:38 PM, Leandro Ribeiro wrote:
Hi,
On 10/26/21 08:34, Igor Torrente wrote:
Add a helper function to validate the connector configuration receive in
the encoder atomic_check
Hi
Am 26.10.21 um 13:34 schrieb Igor Torrente:
The `map` vector at `vkms_composer` uses a hardcoded value to define its
size.
If someday the maximum number of planes increases, this hardcoded value
can be a problem.
This value is being replaced with the DRM_FORMAT_MAX_PLANES macro.
Signed-off
Hi
Am 26.10.21 um 13:34 schrieb Igor Torrente:
This commit is the groundwork to introduce new formats to the planes and
writeback buffer. As part of it, a new buffer metadata field is added to
`vkms_writeback_job`, this metadata is represented by the `vkms_composer`
struct.
This will allow us,
On 10/27/21 12:36 AM, Jim Cromie wrote:
> Use new macro to create a sysfs control bitmap knob to control
> print-to-trace in: /sys/module/drm/parameters/trace
>
> todo: reconsider this api, ie a single macro expecting both debug &
> trace terms (2 each), followed by a single description and the
Acked-by: Nirmoy Das
On 10/28/2021 3:26 PM, Christian König wrote:
Don't touch the exclusive fence manually here, but rather use the
general dma_resv function. We did that for better hw reset handling but
this doesn't necessary work correctly.
Signed-off-by: Christian König
---
drivers/gpu/
On Tue, Nov 02, 2021 at 11:55:04PM +0100, Hans de Goede wrote:
> The Xiaomi Mi Pad 2 tablet uses an ACPI enumerated LP8556 backlight
> controller for its LCD-panel, with a Xiaomi specific ACPI HID of
> "XMCC0001", add support for this.
>
> Note the new "if (id)" check also fixes a NULL pointer der
Hi,
On 11/3/21 18:17, Daniel Thompson wrote:
> On Tue, Nov 02, 2021 at 11:55:04PM +0100, Hans de Goede wrote:
>> The Xiaomi Mi Pad 2 tablet uses an ACPI enumerated LP8556 backlight
>> controller for its LCD-panel, with a Xiaomi specific ACPI HID of
>> "XMCC0001", add support for this.
>>
>> Note t
On Wed, Nov 03, 2021 at 06:28:15PM +0100, Hans de Goede wrote:
> Hi,
>
> On 11/3/21 18:17, Daniel Thompson wrote:
> > On Tue, Nov 02, 2021 at 11:55:04PM +0100, Hans de Goede wrote:
> >> The Xiaomi Mi Pad 2 tablet uses an ACPI enumerated LP8556 backlight
> >> controller for its LCD-panel, with a Xi
Hi,
On 11/3/21 18:31, Daniel Thompson wrote:
> On Wed, Nov 03, 2021 at 06:28:15PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 11/3/21 18:17, Daniel Thompson wrote:
>>> On Tue, Nov 02, 2021 at 11:55:04PM +0100, Hans de Goede wrote:
The Xiaomi Mi Pad 2 tablet uses an ACPI enumerated LP8556 back
Remove legacy PWM interface (pwm_config, pwm_enable, pwm_disable) and
replace it for the atomic PWM API.
Signed-off-by: Maíra Canal
---
V1 -> V2: Initialize variable and simplify conditional loop
V2 -> V3: Fix assignment of NULL variable
V3 -> V4: Replace division for pwm_set_relative_duty_cycle
https://bugzilla.kernel.org/show_bug.cgi?id=214029
--- Comment #25 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Jan Steffens from comment #24)
> Looks like this was mistakenly picked into LTS 5.10, which does not contain
> d02117f8efaa5fbc37437df1ae955a147a2a424a.
As Christian wrote in c
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #6 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Lang Yu from comment #5)
> Created attachment 299383 [details]
> fix a potential dma-buf release warning
>
> Please have a try with attached patch. Thanks!
Thanks! Applied the
On Wed, Nov 03, 2021 at 01:02:11PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 02, 2021 at 03:59:32PM +0100, Maxime Ripard wrote:
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -4966,7 +4966,7 @@ static void drm_parse_hdmi_forum_vsdb(struct
> > drm_connector *connec
Hi Thomas,
On 11/3/21 12:37 PM, Thomas Zimmermann wrote:
Hi
Am 03.11.21 um 16:11 schrieb Leandro Ribeiro:
Hi,
On 11/3/21 12:03, Igor Torrente wrote:
Hi Leandro,
On 10/28/21 6:38 PM, Leandro Ribeiro wrote:
Hi,
On 10/26/21 08:34, Igor Torrente wrote:
Add a helper function to validate the c
On 25/10/2021 14:00, Arunpravin wrote:
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
the requested power-of-two block comply with range limitations
- Moved order computation a
On 25/10/2021 14:00, Arunpravin wrote:
Implemented a function which walk through the order list,
compares the offset and returns the maximum offset block,
this method is unpredictable in obtaining the high range
address blocks which depends on allocation and deallocation.
for instance, if driver
On 25/10/2021 14:00, Arunpravin wrote:
On contiguous allocation, we round up the size
to the *next* power of 2, implement a function
to free the unused pages after the newly allocate block.
Signed-off-by: Arunpravin
Ideally this gets added with some user, so we can see it in action?
Maybe sq
On 25/10/2021 14:00, Arunpravin wrote:
add drm_buddy_free_unused_pages() support on
contiguous allocation
Signed-off-by: Arunpravin
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/d
Hi Thomas,
On 11/3/21 12:45 PM, Thomas Zimmermann wrote:
Hi
Am 26.10.21 um 13:34 schrieb Igor Torrente:
This commit is the groundwork to introduce new formats to the planes and
writeback buffer. As part of it, a new buffer metadata field is added to
`vkms_writeback_job`, this metadata is repre
On 25/10/2021 14:00, Arunpravin wrote:
- Remove drm_mm references and replace with drm buddy functionalities
- Add res cursor support for drm buddy
Signed-off-by: Arunpravin
+ spin_lock(&mgr->lock);
+ r = drm_buddy_alloc(mm, (uint64_t)place->fpfn << PAGE_SHIFT,
On Fri, Oct 29, 2021 at 04:50:55PM -0700, Brian Norris wrote:
> Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"),
> "PSR exit" used non-blocking analogix_dp_send_psr_spd(). The refactor
> started using the blocking variant, for a variety of reasons -- quoting
> Sean Paul's pot
Quoting Kuogee Hsieh (2021-11-02 15:13:44)
> Current display mode_set, enable and disable functions are implemented
> as function called directly from drm encoder. This patch have display
> mode_set, enable and disable be implemented as callback function of drm
> bridge.
Why is it important? Pleas
Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"),
"PSR exit" used non-blocking analogix_dp_send_psr_spd(). The refactor
started using the blocking variant, for a variety of reasons -- quoting
Sean Paul's potentially-faulty memory:
"""
- To avoid racing a subsequent PSR entry
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
index 47b3cf2df230..b24e5475cafb 100644
--- a/drivers/g
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
index b24e5475cafb..427c55002f4d 100
From: Rob Clark
Cancel the timer when the GPU is idle, but also remember to restart it
in the recover path if we've re-submitted submits following the one that
hung.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drive
> -Original Message-
> From: Roper, Matthew D
> Sent: Tuesday, November 2, 2021 3:25 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Roper, Matthew D
> ; Srivatsa, Anusha
>
> Subject: [PATCH 2/3] drm/i915/dg2: Add initial gt/ctx/engine workarounds
>
> B
John Harrison writes:
> On 11/1/2021 08:39, Jordan Justen wrote:
>> writes:
>>
>>> From: Rodrigo Vivi
>>>
>>> GuC contains a consolidated table with a bunch of information about the
>>> current device.
>>>
>>> Previously, this information was spread and hardcoded to all the components
>>> inclu
In commit 142639a52a01 ("drm/msm/a6xx: fix crashstate capture for
A650") we changed a6xx_get_gmu_registers() to read 3 sets of
registers. Unfortunately, we didn't change the memory allocation for
the array. That leads to a KASAN warning (this was on the chromeos-5.4
kernel, which has the problemati
On 11/3/2021 14:38, Jordan Justen wrote:
John Harrison writes:
On 11/1/2021 08:39, Jordan Justen wrote:
writes:
From: Rodrigo Vivi
GuC contains a consolidated table with a bunch of information about the
current device.
Previously, this information was spread and hardcoded to all the com
This reverts commit f4b34faa08428d813fc3629f882c503487f94a12.
Since commit f4b34faa0842 ("drm/imx: Annotate dma-fence critical section in
commit path") the following possible circular dependency is detected:
[5.001811] ==
[5.001817] WARN
On Mon, 01 Nov 2021 18:26:06 -0700, Vinay Belgaumkar wrote:
>
> Define helpers and struct members required to record boost info.
> Boost frequency is initialized to RP0 at SLPC init. Also define num_waiters
> which can track the pending boost requests.
>
> Boost will be done by scheduling a worker
On Mon, 01 Nov 2021 18:26:07 -0700, Vinay Belgaumkar wrote:
>
> Add helper in RPS code for handling SLPC and non-SLPC paths.
> When boost is requested in the SLPC path, we can ask GuC to ramp
> up the frequency req by setting the minimum frequency to boost freq.
> Reset freq back to the min softlim
The "vdd" regulator was used by the mdp5 driver only on downstream
kernels, where the GDSC is represented as a regulator. On all current
kernels the MDSS_GDSC is implemented as the power domain, removing the
need for this regulator. Remove it from the mdp5 driver.
Signed-off-by: Dmitry Baryshkov
On Mon, 01 Nov 2021 13:28:14 -0700, Dixit, Ashutosh wrote:
>
> On Sun, 31 Oct 2021 21:39:37 -0700, Belgaumkar, Vinay wrote:
> >
> > +static int set_boost_freq(struct intel_rps *rps, u32 val)
>
> Since this is legacy rps code path maybe change function name to
> rps_set_boost_freq?
Not being able t
On Mon, 01 Nov 2021 18:26:08 -0700, Vinay Belgaumkar wrote:
>
> Add a helper to sort through the SLPC/RPS paths of get/set methods.
> Boost frequency will be modified as long as it is within the constraints
> of RP0 and if it is different from the existing one. We will set min
> freq to boost only
On Wed, Nov 03, 2021 at 05:20:03PM +0300, Dan Carpenter wrote:
> This is a super awkward way to resend a patch series. Next time, just
> start a new thread and put [PATCH RESEND] in the subject.
OK, thanks!
Xin
>
> I am sorry that no one responded to your thread. :/
>
> regards,
> dan carpenter
On Wed, Nov 03, 2021 at 04:04:00PM +0100, Robert Foss wrote:
> Hey Xin,
>
> This series does not apply on drm-misc-next. Please fix this and
> resend. Make sure that checkpatch --strict passes as well.
OK, I'll apply on drm-misc-next, thanks!
Xin
>
> On Wed, 3 Nov 2021 at 15:20, Dan Carpenter wr
Hi Dave, Daniel,
Fixes for 5.16.
The following changes since commit d9bd054177fbd2c4762546aec40fc3071bfe4cc0:
Merge tag 'amd-drm-next-5.16-2021-10-29' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-11-02 12:40:58
+1000)
are available in the Git repository at:
https://g
Hi all, this patch series implement MIPI rx DPI feature. Please help to review.
This is the v12 version, rebase all patches on the drm-misc-next.
Any mistakes, please let me know, I'll fix it in the next series.
Change history:
v12: Fix Robert Foss comment
- Apply code on drm-misc-next branch
v
Add 'bus-type' and 'data-lanes' define for port0. Add DP tx lane0,
lane1 swing register setting array, and audio enable flag.
The device which cannot pass DP tx PHY CTS caused by long PCB trace or
embedded MUX, adjusting ANX7625 PHY parameters can pass the CTS test. The
adjusting type include Pre-
At some time, the original code may return non zero value, force return 0
if operation finished.
Reviewed-by: Robert Foss
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/a
Hi sirs
Pls help to review this change.
Best Regards
Jitao.
On Tue, 2021-10-05 at 07:53 +0800, Chun-Kuang Hu wrote:
> Hi, Jitao:
>
> Jitao Shi 於 2021年9月16日 週四 上午6:31寫道：
> >
> > Some DSI devices reqire the hs packet starting and ending
> > at same time on all dsi lanes. So use a flag to those
The basic anx7625 driver only support MIPI DSI rx signal input.
This patch add MIPI DPI rx input configuration support, after apply
this patch, the driver can support DSI rx or DPI rx by adding
'bus-type' in DT.
Reviewed-by: Robert Foss
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/
Add audio HDMI codec function support, enable it through device true
flag "analogix,audio-enable".
Reviewed-by: Robert Foss
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 226 ++
drivers/gpu/drm/bridge/analogix/anx7625.h | 5 +
2 files changed, 231 i
On Wed, Nov 3, 2021 at 9:58 AM Jason Baron wrote:
>
>
>
> On 10/27/21 12:36 AM, Jim Cromie wrote:
> > Use new macro to create a sysfs control bitmap knob to control
> > print-to-trace in: /sys/module/drm/parameters/trace
> >
> > todo: reconsider this api, ie a single macro expecting both debug &
>
On Wed, Nov 03, 2021 at 02:38:05PM -0300, Maíra Canal wrote:
> Remove legacy PWM interface (pwm_config, pwm_enable, pwm_disable) and
> replace it for the atomic PWM API.
>
> Signed-off-by: Maíra Canal
> ---
> V1 -> V2: Initialize variable and simplify conditional loop
> V2 -> V3: Fix assignment o
92 matches
Mail list logo
