Commit fb24ea52f78e0d595852e ("drivers: Remove explicit invocations of
mmiowb()") remove all mmiowb() in drivers, but it says:
"NOTE: mmiowb() has only ever guaranteed ordering in conjunction with
spin_unlock(). However, pairing each mmiowb() removal in this patch with
the corresponding call to sp
On Mon, Feb 19, 2024 at 06:48:30PM +0100, Markus Elfring wrote:
> > The two device node references taken during allocation need to be
> > dropped when the auxiliary device is freed.
> …
> > +++ b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
> …
> > @@ -74,6 +75,8 @@ struct device *drm_dp_hpd_bridge_regi
On 2/16/2024 7:50 PM, Mitul Golani wrote:
Add the necessary structures and functions to handle reading and
unpacking Adaptive Sync Secondary Data Packets. Also add support
to write and pack AS SDP.
--v2:
- Correct use of REG_BIT and REG_GENMASK. [Jani]
- Use as_sdp instead of async. [Jani]
- R
On 2/16/2024 7:50 PM, Mitul Golani wrote:
Write/Read Adaptive sync SDP only when Sink and Source is enabled
for the same. Also along with write TRANS_VRR_VSYNC values.
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_ddi.c | 4
.../gpu/drm/i915/display/inte
El lun, 19-02-2024 a las 10:00 -0300, Maíra Canal escribió:
> Hi Iago,
>
> On 2/19/24 09:56, Iago Toral wrote:
> > Hi Maíra,
> >
> > El mié, 14-02-2024 a las 16:34 -0300, Maíra Canal escribió:
> > > Currently, the V3D driver uses PAGE_SHIFT over the assumption
> > > that
> > > PAGE_SHIFT = 12, as
On 2/16/2024 7:50 PM, Mitul Golani wrote:
Compute vrr_vsync_start/end which sets the position
for hardware to send the Vsync at a fixed position
relative to the end of the Vblank.
--v2:
- Update, VSYNC_START/END macros to VRR_VSYNC_START/END.(Ankit)
- Update bit fields of VRR_VSYNC_START/END.
On 2/16/2024 7:50 PM, Mitul Golani wrote:
Add necessary functions definitions to enable
and compute AS SDP data. The new `intel_dp_compute_as_sdp`
function computes AS SDP values based on the display
configuration, ensuring proper handling of Variable Refresh
Rate (VRR).
--v2:
- Add DP_SDP_ADA
On 2/16/2024 7:50 PM, Mitul Golani wrote:
Add the necessary structures and functions to handle reading and
unpacking Adaptive Sync Secondary Data Packets. Also add support
to write and pack AS SDP.
--v2:
- Correct use of REG_BIT and REG_GENMASK. [Jani]
- Use as_sdp instead of async. [Jani]
- R
Gentle reminder to consume this patchset.
On Tue, Feb 06, 2024 at 03:07:47PM +0100, Daniel Vetter wrote:
> On Thu, Feb 01, 2024 at 10:42:56PM -0800, Shradha Gupta wrote:
> > This patchset consists of sanity checks before enabling/disabling
> > output polling to make sure we do not call polling ena
On 2/16/2024 7:50 PM, Mitul Golani wrote:
Add structure representing Adaptive Sync Secondary Data
Packet (AS SDP). Also, add Adaptive Sync SDP logging in
drm_dp_helper.c to facilitate debugging.
--v2:
- Update logging. [Jani, Ankit]
- use as_sdp instead of async [Ankit]
- Correct define placeh
On Fri, Feb 09, 2024 at 08:53:25AM -0800, Yury Norov wrote:
On Wed, Feb 07, 2024 at 11:45:20PM -0800, Lucas De Marchi wrote:
Implement fixed-type BIT() to help drivers add stricter checks, like was
done for GENMASK.
Signed-off-by: Lucas De Marchi
Acked-by: Jani Nikula
So I get v1 from Jan.2
On Mon, Feb 19, 2024 at 06:59:02PM +0100, Christophe JAILLET wrote:
> Le 19/02/2024 à 09:37, Dan Carpenter a écrit :
> > On Sun, Feb 18, 2024 at 06:46:44PM +0100, Christophe JAILLET wrote:
> > > If 'list_limit' is set to a very high value, 'lsize' computation could
> > > overflow if 'head.count' is
Hi Krzysztof,
On 12/02/24 3:53 pm, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 08/02/2024 11:43, Lee Jones wrote:
>> On Fri, 02 Feb 2024 05:47:33 +0530, Dharma Balasubiramani wrote:
>>> Convert the atmel,hlcdc b
Add Cadence HDP-TX HDMI PHY driver for i.MX8MQ.
Cadence HDP-TX PHY could be put in either DP mode or
HDMI mode base on the configuration chosen.
HDMI PHY mode is configurated in the driver.
Signed-off-by: Sandor Yu
Tested-by: Alexander Stein
---
v13->v14:
*No change.
v12->v13:
- Fix build war
Add Cadence HDP-TX DisplayPort PHY driver for i.MX8MQ
Cadence HDP-TX PHY could be put in either DP mode or
HDMI mode base on the configuration chosen.
DisplayPort PHY mode is configurated in the driver.
Signed-off-by: Sandor Yu
---
v12->v14:
*No change.
v11->v12:
- Return error code to replace
Add bindings for Freescale iMX8MQ DP and HDMI PHY.
Signed-off-by: Sandor Yu
Reviewed-by: Rob Herring
---
v9->v14:
*No change.
.../bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml | 53 +++
1 file changed, 53 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/fsl
inary included respective specific firmware
is required.
Driver will check display connector type and
then load the corresponding driver.
Signed-off-by: Sandor Yu
Tested-by: Alexander Stein
---
v13->v14:
- Rebase to next-20240219, replace get_edid function by edid_read
function.
v12->v13:
-
Add bindings for Cadence MHDP8501 DisplayPort/HDMI bridge.
Signed-off-by: Sandor Yu
Reviewed-by: Krzysztof Kozlowski
---
v9->v14:
*No change.
.../display/bridge/cdns,mhdp8501.yaml | 104 ++
1 file changed, 104 insertions(+)
create mode 100644
Documentation/devicetree
Allow HDMI PHYs to be configured through the generic
functions through a custom structure added to the generic union.
The parameters added here are based on HDMI PHY
implementation practices. The current set of parameters
should cover the potential users.
Signed-off-by: Sandor Yu
Reviewed-by: D
MHDP8546 mailbox access functions will be share to other mhdp driver
and Cadence HDP-TX HDMI/DP PHY drivers.
Create a new mhdp helper driver and move all those functions into.
cdns_mhdp_reg_write() is renamed to cdns_mhdp_dp_reg_write(),
because it use the DPTX command ID DPTX_WRITE_REGISTER.
New
options
#5: dt-bindings: phy: Add Freescale iMX8MQ DP and HDMI PHY
#6: phy: freescale: Add DisplayPort PHY driver for i.MX8MQ
#7: phy: freescale: Add HDMI PHY driver for i.MX8MQ
v13->v14:
Patch #4:
- Rebase to next-20240219, replace get_edid function by edid_read
function as comm
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_r
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_r
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_r
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_r
Hi Rob
This is resend v2 of replace of_graph_get_next_endpoint()
We should get rid of or minimize of_graph_get_next_endpoint() in
its current form. In general, drivers should be asking for a specific
port number because their function is fixed in the binding.
https://lore.kernel.org/r
As per documentation "drivers are expected to use this function in their
update_status() operation to get the brightness value.".
With this we can also drop the manual backlight_is_blank() handling
since backlight_get_brightness() is already handling this correctly.
Signed-off-by: Luca Weiss
---
The backlight_properties struct should be initialized to zero before
using, otherwise there will be some random values in the struct.
Fixes: 0c2a665a648e ("backlight: add Backlight driver for lm3630 chip")
Signed-off-by: Luca Weiss
---
drivers/video/backlight/lm3630a_bl.c | 1 +
1 file changed,
| 29 ++
2 files changed, 16 insertions(+), 17 deletions(-)
---
base-commit: b401b621758e46812da61fa58a67c3fd8d91de0d
change-id: 20240219-lm3630a-fixups-8a9359e5a8ce
Best regards,
--
Luca Weiss
Connect the panel with the backlight nodes so that the backlight can be
turned off when the display is blanked.
Signed-off-by: Luca Weiss
---
arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qco
There's no need to set bl->props.brightness, the get_brightness function
is just supposed to return the current brightness and not touch the
struct.
With that done we can also remove the 'goto out' and just return the
value.
Fixes: 0c2a665a648e ("backlight: add Backlight driver for lm3630 chip")
On Mon, 19 Feb 2024 at 23:37, Konrad Dybcio wrote:
>
> On 19.02.2024 15:49, Dmitry Baryshkov wrote:
> > On Mon, 19 Feb 2024 at 15:36, Konrad Dybcio
> > wrote:
> >>
> >> Enable the A702 GPU (also marketed as "3D accelerator by qcom [1], lol).
> >
> > Is it not?
>
> Sure, every electronic device i
Hi Dave, Sima,
More new stuff for 6.9.
The following changes since commit d5597444032b2f5c8624918fb5b29be5bba78a3c:
drm/amdgpu: Fix HDP flush for VFs on nbio v7.9 (2024-02-07 12:26:24 -0500)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-dr
Hi all,
On Mon, 12 Feb 2024 15:15:54 +0200 Jani Nikula
wrote:
>
> On Tue, 06 Feb 2024, Stephen Rothwell wrote:
> >
> > After merging the drm-misc tree, today's linux-next build (i386 defconfig)
> > failed like this:
> >
> > In function 'i915_ttm_placement_from_obj',
> > inlined from 'i915_t
On 19.02.2024 15:49, Dmitry Baryshkov wrote:
> On Mon, 19 Feb 2024 at 15:36, Konrad Dybcio wrote:
>>
>> Enable the A702 GPU (also marketed as "3D accelerator by qcom [1], lol).
>
> Is it not?
Sure, every electronic device is also a heater, I suppose.. I found
this wording extremely funny though
On Mon, Feb 19, 2024 at 3:00 AM Matt Coster wrote:
>
> Hi Adam,
>
> On 18/02/2024 23:26, Adam Ford wrote:
> > On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard wrote:
> >>
> >> On Fri, Feb 16, 2024 at 09:13:14AM +, Biju Das wrote:
> >>> Hi Maxime Ripard,
> >>>
> -Original Message-
>
On 19/02/2024 17:25, Helen Koike wrote:
On 18/02/2024 01:12, Dmitry Baryshkov wrote:
The test kms_universal_plane@universal-plane-sanity fails on both SC7180
platforms. The drm/msm returns -ERANGE as it can not handle passet
scaling range, however the test is not ready to handle that. Mark
On 19/02/2024 17:26, Helen Koike wrote:
On 18/02/2024 01:12, Dmitry Baryshkov wrote:
Mark two tests as passing on the APQ8096 / db820c platform.
Signed-off-by: Dmitry Baryshkov
Acked-by: Helen Koike
Applied to drm-misc/drm-misc-next
Thanks
Helen
---
drivers/gpu/drm/ci/xfails/
On 19/02/2024 17:25, Helen Koike wrote:
On 19/02/2024 14:42, Dmitry Baryshkov wrote:
On Mon, 19 Feb 2024 at 18:48, Helen Koike
wrote:
On 19/02/2024 11:33, Dmitry Baryshkov wrote:
On Mon, 19 Feb 2024 at 15:21, Helen Koike
wrote:
Hi Dmitry,
On 18/02/2024 01:12, Dmitry Baryshkov wro
On Fri, Feb 16, 2024 at 10:38:41AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The above w/a is required for every platform that the i915 driver
> supports. It is fixed on the latest platforms but they are only
> supported by Xe instead of i915. So just remove the platform c
On 18/02/2024 01:12, Dmitry Baryshkov wrote:
Mark two tests as passing on the APQ8096 / db820c platform.
Signed-off-by: Dmitry Baryshkov
Acked-by: Helen Koike
---
drivers/gpu/drm/ci/xfails/msm-apq8096-fails.txt | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/ci/x
On 18/02/2024 01:12, Dmitry Baryshkov wrote:
The test kms_universal_plane@universal-plane-sanity fails on both SC7180
platforms. The drm/msm returns -ERANGE as it can not handle passet
scaling range, however the test is not ready to handle that. Mark the
test as failing until it is fixed.
ERR
On 19/02/2024 14:42, Dmitry Baryshkov wrote:
On Mon, 19 Feb 2024 at 18:48, Helen Koike wrote:
On 19/02/2024 11:33, Dmitry Baryshkov wrote:
On Mon, 19 Feb 2024 at 15:21, Helen Koike wrote:
Hi Dmitry,
On 18/02/2024 01:12, Dmitry Baryshkov wrote:
Since the addition of testlist.txt the
From: Mads Bligaard Nielsen
Moved IRQ registration down to end of adv7511_probe().
If an IRQ already is pending during adv7511_probe
(before adv7511_cec_init) then cec_received_msg_ts
could crash using uninitialized data:
Unable to handle kernel read from unreadable memory at virtual addres
From: Alvin Šipraga
In preparation for calling EDID helpers from the hotplug work, move the
hotplug work below the EDID helper section. No functional change.
Reviewed-by: Robert Foss
Signed-off-by: Alvin Šipraga
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 120 ++
From: Alvin Šipraga
The adv7511 driver is solely responsible for setting the physical
address of its CEC adapter. To do this, it must read the EDID. However,
EDID is only read when either the drm_bridge_funcs :: get_edid or
drm_connector_helper_funcs :: get_modes ops are called. Without loss of
g
This series fixes a small bug where the CEC adapter could have an
invalid CEC address even though we got a hotplug connect and could have
read it.
Signed-off-by: Alvin Šipraga
---
Changes in v3:
- rebase on latest drm-misc-fixes
- remove redundant NULL check before kfree()
- collect Robert's Revi
On Mon, Feb 19, 2024 at 01:50:47PM +0100, Nirmoy Das wrote:
> Error in mmu_interval_notifier_insert() can leave a NULL
> notifier.mm pointer. Catch that and return early.
>
> Cc: Andi Shyti
> Cc: Shawn Lee
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 3 +++
On Mon, Feb 19, 2024 at 01:14:23PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Request can be NULL if no guilty request was identified so simply use
> engine->i915 instead.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: d50892a9554c ("drm/i915: switch from drm_debug_printer() to device
;
---
base-commit: b401b621758e46812da61fa58a67c3fd8d91de0d
change-id: 20240219-device_cleanup-accel-a990dc3bfbc1
Best regards,
--
Ricardo B. Marliere
On Mon, Feb 19, 2024 at 11:02:01AM +0800, Andy Yan wrote:
> Hi Ondrej:
>
> On 2/18/24 23:17, Ondřej Jirman wrote:
> > Hi Andy,
> >
> > On Sun, Feb 18, 2024 at 07:14:56PM +0800, Andy Yan wrote:
> > > Hi,
> > >
> > > On 2/18/24 02:39, Ondřej Jirman wrote:
> > > > From: Ondrej Jirman
> > > >
> >
On 2/18/24 11:46, Christophe JAILLET wrote:
If 'list_limit' is set to a very high value, 'lsize' computation could
overflow if 'head.count' is big enough.
In such a case, udmabuf_create() would access to memory beyond 'list'.
Use memdup_array_user() which checks for overflow.
While at it, i
Kindly ping :)
On Fri, Jan 19, 2024 at 11:33 AM Tommy Chiang wrote:
>
> This patch tries to improve the display of the code listing
> on The Linux Kernel documentation website for dma-buf [1] .
>
> Originally, it appears that it was attempting to escape
> the '*' character, but looks like it's no
Le 19/02/2024 à 09:37, Dan Carpenter a écrit :
On Sun, Feb 18, 2024 at 06:46:44PM +0100, Christophe JAILLET wrote:
If 'list_limit' is set to a very high value, 'lsize' computation could
overflow if 'head.count' is big enough.
The "list_limit" is set via module parameter so if you set that hig
Hi DRM maintainers
Gentle ping for reviews on this one.
Since the dependent series is mostly complete, would like to get your
reviews on this one to land it.
Thanks
Abhinav
On 2/15/2024 11:15 AM, Abhinav Kumar wrote:
From: Paloma Arellano
YUV420 format is supported only in the VSC SDP pa
> The two device node references taken during allocation need to be
> dropped when the auxiliary device is freed.
…
> +++ b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
…
> @@ -74,6 +75,8 @@ struct device *drm_dp_hpd_bridge_register(struct device
> *parent,
>
> ret = auxiliary_device_init(adev);
On Mon, 19 Feb 2024 at 18:48, Helen Koike wrote:
>
>
>
> On 19/02/2024 11:33, Dmitry Baryshkov wrote:
> > On Mon, 19 Feb 2024 at 15:21, Helen Koike wrote:
> >>
> >> Hi Dmitry,
> >>
> >>
> >> On 18/02/2024 01:12, Dmitry Baryshkov wrote:
> >>> Since the addition of testlist.txt the IGT has changed
Hi Adam,
On 19/02/2024 16:38, Adam Ford wrote:
> On Mon, Feb 19, 2024 at 1:45 AM Biju Das wrote:
>>
>> Hi Adam,
>>
>>> -Original Message-
>>> From: Adam Ford
>>> Sent: Sunday, February 18, 2024 11:26 PM
>>> Subject: Re: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend
>>> on
On 19/02/2024 11:47, Vignesh Raman wrote:
On 17/02/24 02:26, Dmitry Baryshkov wrote:
The commit ea489a3d983b ("drm/ci: add sc7180-trogdor-kingoftown")
dropped the msm-sc7180-skips.txt file, which disabled suspend-to-RAM
tests. However testing shows that STR tests still can fail. Restore the
On Mon, Feb 19, 2024 at 10:38:12AM -0600, Adam Ford wrote:
> On Mon, Feb 19, 2024 at 1:45 AM Biju Das wrote:
> >
> > Hi Adam,
> >
> > > -Original Message-
> > > From: Adam Ford
> > > Sent: Sunday, February 18, 2024 11:26 PM
> > > Subject: Re: RE: RE: [PATCH v2] drm/imagination: DRM_POWERV
On 19/02/2024 11:33, Dmitry Baryshkov wrote:
On Mon, 19 Feb 2024 at 15:21, Helen Koike wrote:
Hi Dmitry,
On 18/02/2024 01:12, Dmitry Baryshkov wrote:
Since the addition of testlist.txt the IGT has changed some of test
names. Some test names were changed to use '-' instead of '_'. In othe
Hi
Am 19.02.24 um 15:19 schrieb Tony Lindgren:
Commit 95da53d63dcf ("drm/omapdrm: Use regular fbdev I/O helpers")
broke console because there is no damage handling in fb_sys_write()
unlike we have in drm_fb_helper_sys_write().
Let's fix the issue by using deferred ops with fb helpers for damage
On Mon, Feb 19, 2024 at 1:45 AM Biju Das wrote:
>
> Hi Adam,
>
> > -Original Message-
> > From: Adam Ford
> > Sent: Sunday, February 18, 2024 11:26 PM
> > Subject: Re: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend
> > on ARCH_K3
> >
> > On Fri, Feb 16, 2024 at 8:14 AM Maxi
On Mon Feb 19, 2024 at 3:18 AM CET, Mikko Perttunen wrote:
> On 2/16/24 19:02, Thierry Reding wrote:
> > On Wed Feb 14, 2024 at 12:40 PM CET, Mikko Perttunen wrote:
> >> From: Mikko Perttunen
> >>
> >> On Tegra186, other software components may rely on the kernel to
> >> keep Host1x operational ev
Hi
Am 19.02.24 um 15:19 schrieb Tony Lindgren:
The framebuffer console stopped updating with commit f231af498c29
("drm/fb-helper: Disconnect damage worker from update logic").
Let's fix the issue by implementing fb_dirty similar to what was done
with commit 039a72ce7e57 ("drm/i915/fbdev: Implem
On Mon, 19 Feb 2024 at 17:01, Konrad Dybcio wrote:
>
> On 19.02.2024 15:54, Andrew Halaney wrote:
> > On Mon, Feb 19, 2024 at 02:35:48PM +0100, Konrad Dybcio wrote:
> >> Commit 134b55b7e19f ("clk: qcom: support Huayra type Alpha PLL")
> >> introduced an entry to the alpha offsets array, but diving
On 19.02.2024 15:53, Dmitry Baryshkov wrote:
> On Mon, 19 Feb 2024 at 15:36, Konrad Dybcio wrote:
>>
>> Commit 134b55b7e19f ("clk: qcom: support Huayra type Alpha PLL")
>> introduced an entry to the alpha offsets array, but diving into QCM2290
>> downstream and some documentation, it turned out th
On Sat Feb 17, 2024 at 10:39 AM CET, Krzysztof Kozlowski wrote:
> The xlate callbacks are supposed to translate of_phandle_args to proper
> provider without modifying the of_phandle_args. Make the argument
> pointer to const for code safety and readability.
>
> Signed-off-by: Krzysztof Kozlowski
On Mon, Feb 19, 2024 at 10:19 AM Christian König
wrote:
>
> Am 16.02.24 um 19:37 schrieb Alex Deucher:
> > On Fri, Feb 16, 2024 at 10:42 AM Christian König
> > wrote:
> >> Am 16.02.24 um 16:12 schrieb Mario Limonciello:
> >>> On 2/16/2024 09:05, Harry Wentland wrote:
>
> On 2024-02-16 0
Am 16.02.24 um 19:37 schrieb Alex Deucher:
On Fri, Feb 16, 2024 at 10:42 AM Christian König
wrote:
Am 16.02.24 um 16:12 schrieb Mario Limonciello:
On 2/16/2024 09:05, Harry Wentland wrote:
On 2024-02-16 09:47, Christian König wrote:
Am 16.02.24 um 15:42 schrieb Mario Limonciello:
On 2/16/2
On Thu, 15 Feb 2024, Thomas Zimmermann wrote:
> Hi
>
> Am 15.02.24 um 13:13 schrieb Daniel Thompson:
> > On Mon, Feb 12, 2024 at 05:16:33PM +0100, Thomas Zimmermann wrote:
> > > Backlight drivers implement struct backlight_ops.check_fb, which
> > > uses struct fb_info in its interface. Replace th
On 19.02.2024 15:54, Andrew Halaney wrote:
> On Mon, Feb 19, 2024 at 02:35:48PM +0100, Konrad Dybcio wrote:
>> Commit 134b55b7e19f ("clk: qcom: support Huayra type Alpha PLL")
>> introduced an entry to the alpha offsets array, but diving into QCM2290
>> downstream and some documentation, it turned
On Mon, 19 Feb 2024 at 15:36, Konrad Dybcio wrote:
>
> Describe the GPU hardware on the QCM2290.
>
> Signed-off-by: Konrad Dybcio
> ---
> arch/arm64/boot/dts/qcom/qcm2290.dtsi | 154
> ++
> 1 file changed, 154 insertions(+)
>
Reviewed-by: Dmitry Baryshkov
--
On 18/02/2024 21:41, Boris Brezillon wrote:
> MMU and VM management is related and placed in the same source file.
>
> Page table updates are delegated to the io-pgtable-arm driver that's in
> the iommu subsystem.
>
> The VM management logic is based on drm_gpuva_mgr, and is assuming the
> VA spa
On Mon, 19 Feb 2024 at 15:36, Konrad Dybcio wrote:
>
> Add a driver for the GPU clock controller block found on the QCM2290 SoC.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/clk/qcom/Kconfig | 9 +
> drivers/clk/qcom/Makefile| 1 +
> drivers/clk/qcom/gpucc-qcm2290.c | 423
On Mon, Feb 19, 2024 at 02:35:48PM +0100, Konrad Dybcio wrote:
> Commit 134b55b7e19f ("clk: qcom: support Huayra type Alpha PLL")
> introduced an entry to the alpha offsets array, but diving into QCM2290
> downstream and some documentation, it turned out that the name Huayra
> apparently has been u
On Mon, 19 Feb 2024 at 15:36, Konrad Dybcio wrote:
>
> Commit 134b55b7e19f ("clk: qcom: support Huayra type Alpha PLL")
> introduced an entry to the alpha offsets array, but diving into QCM2290
> downstream and some documentation, it turned out that the name Huayra
> apparently has been used quite
On Mon, 19 Feb 2024 at 15:36, Konrad Dybcio wrote:
>
> Enable the A702 GPU (also marketed as "3D accelerator by qcom [1], lol).
Is it not?
>
> [1]
> https://docs.qualcomm.com/bundle/publicresource/87-61720-1_REV_A_QUALCOMM_ROBOTICS_RB1_PLATFORM__QUALCOMM_QRB2210__PRODUCT_BRIEF.pdf
> Signed-off-
On 17/02/24 02:26, Dmitry Baryshkov wrote:
The commit ea489a3d983b ("drm/ci: add sc7180-trogdor-kingoftown")
dropped the msm-sc7180-skips.txt file, which disabled suspend-to-RAM
tests. However testing shows that STR tests still can fail. Restore the
skiplist, applying it to both limozeen and ki
On Mon, 19 Feb 2024 at 15:21, Helen Koike wrote:
>
> Hi Dmitry,
>
>
> On 18/02/2024 01:12, Dmitry Baryshkov wrote:
> > Since the addition of testlist.txt the IGT has changed some of test
> > names. Some test names were changed to use '-' instead of '_'. In other
> > cases tests were just renamed.
@599: failed to match any schema with
compatible: ['qcom,qcm2290-gpucc']
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240219-topic-rb1_gpu-v1-2-d260fa854...@linaro.org
The base for the series is generally the latest
Commit 95da53d63dcf ("drm/omapdrm: Use regular fbdev I/O helpers")
broke console because there is no damage handling in fb_sys_write()
unlike we have in drm_fb_helper_sys_write().
Let's fix the issue by using deferred ops with fb helpers for damage.
Fixes: 95da53d63dcf ("drm/omapdrm: Use regular
The framebuffer console stopped updating with commit f231af498c29
("drm/fb-helper: Disconnect damage worker from update logic").
Let's fix the issue by implementing fb_dirty similar to what was done
with commit 039a72ce7e57 ("drm/i915/fbdev: Implement fb_dirty for intel
custom fb helper").
Fixes:
On Thu, Feb 15, 2024 at 12:00:01PM +0100, Maxime Ripard wrote:
> On Mon, Feb 12, 2024 at 06:06:18PM +0100, Sebastian Wick wrote:
> > On Mon, Feb 12, 2024 at 05:53:48PM +0100, Maxime Ripard wrote:
> > > On Mon, Feb 12, 2024 at 05:49:33PM +0200, Ville Syrjälä wrote:
> > > > On Mon, Feb 12, 2024 at 11
id,
enum dpu_hw_blk_type type, struct dpu_hw_blk **blks, int blks_size);
+/**
+ * dpu_rm_print_state - output the RM private state
+ * @p: DRM printer
+ * @global_state: global state
+ */
+void dpu_rm_print_state(struct drm_printer *p,
+ const struct dpu_global_state *global_state);
+
/**
* dpu_rm_get_intf - Return a struct dpu_hw_intf instance given it's index.
* @rm: DPU Resource Manager handle
---
base-commit: 41c177cf354126a22443b5c80cec9fdd313e67e1
change-id: 20240219-fd-rm-state-bd1218954b78
Best regards,
--
Dmitry Baryshkov
On Mon, Feb 19, 2024 at 11:41:41AM +0100, Johan Hovold wrote:
> It seems my initial suspicion that at least some of these regressions
> were related to the runtime PM work was correct. The hard resets happens
> when the DP controller is runtime suspended after being probed:
> [ 17.074925] bus:
Enable the A702 GPU (also marketed as "3D accelerator by qcom [1], lol).
[1]
https://docs.qualcomm.com/bundle/publicresource/87-61720-1_REV_A_QUALCOMM_ROBOTICS_RB1_PLATFORM__QUALCOMM_QRB2210__PRODUCT_BRIEF.pdf
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 8 +++
Describe the GPU hardware on the QCM2290.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/qcm2290.dtsi | 154 ++
1 file changed, 154 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcm2290.dtsi
b/arch/arm64/boot/dts/qcom/qcm2290.dtsi
index 89beac83
The A702 is a weird mix of 600 and 700 series.. Perhaps even a
testing ground for some A7xx features with good ol' A6xx silicon.
It's basically A610 that's been beefed up with some new registers
and hw features (like APRIV!), that was then cut back in size,
memory bus and some other ways.
Add supp
Add some defines required for A702. Can be substituted with a header
sync after merging mesa!27665 [1].
[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27665
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 18 ++
1 file changed, 18 insertion
Commit 134b55b7e19f ("clk: qcom: support Huayra type Alpha PLL")
introduced an entry to the alpha offsets array, but diving into QCM2290
downstream and some documentation, it turned out that the name Huayra
apparently has been used quite liberally across many chips, even with
noticeably different h
Add a driver for the GPU clock controller block found on the QCM2290 SoC.
Signed-off-by: Konrad Dybcio
---
drivers/clk/qcom/Kconfig | 9 +
drivers/clk/qcom/Makefile| 1 +
drivers/clk/qcom/gpucc-qcm2290.c | 423 +++
3 files changed, 433 inse
The GPU SMMU on QCM2290 nicely fits into the description we already have
for SM61[12]5. Add it.
Signed-off-by: Konrad Dybcio
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iommu/arm
Add device tree bindings for graphics clock controller for Qualcomm
Technology Inc's QCM2290 SoCs.
Signed-off-by: Konrad Dybcio
---
.../bindings/clock/qcom,qcm2290-gpucc.yaml | 76 ++
include/dt-bindings/clock/qcom,qcm2290-gpucc.h | 32 +
2 files changed,
u/drm/msm/adreno/adreno_device.c | 18 +
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 16 +-
include/dt-bindings/clock/qcom,qcm2290-gpucc.h | 32 ++
14 files changed, 888 insertions(+), 10 deletions(-)
---
base-commit: 26d7d52b6253574d5b6fec16a93e1110d1489cef
change-id: 20240219-
On Mon, 2024-02-19 at 13:25 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Tooling appears very strict so lets pacify it by adding some comments,
> even if fields are completely self-explanatory.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Tvrtko Ursulin
> Fixes: b11236486
From: Tvrtko Ursulin
Tooling appears very strict so lets pacify it by adding some comments,
even if fields are completely self-explanatory.
Signed-off-by: Tvrtko Ursulin
Fixes: b11236486749 ("drm/i915: Add GuC submission interface version query")
Reported-by: Stephen Rothwell
Cc: Jose Souza
-
On Tue, Feb 13, 2024 at 11:26:44AM +0200, Ville Syrjälä wrote:
> On Mon, Feb 12, 2024 at 05:50:36PM +0100, Sebastian Wick wrote:
> > On Mon, Feb 12, 2024 at 11:10:15AM +0200, Pekka Paalanen wrote:
> > > On Fri, 9 Feb 2024 17:53:07 +0100
> > > Xaver Hugl wrote:
> > >
> > > > Signed-off-by: Xaver
1 - 100 of 191 matches
Mail list logo
