On 2/23/2024 1:21 PM, Konrad Dybcio wrote:
> + /* Wait 50us for PLL_LOCK_DET bit to go high */
> + usleep_range(50, 55);
> +
> + /* Enable PLL output */
> + regmap_update_bits(regmap, PLL_MODE(pll), PLL_OUTCTRL, PLL_OUTCTRL);
> +}
> +EXPORT_SYMBOL(clk_huayra_2290_pll_configure);
On Fri, 23 Feb 2024 at 23:21, Konrad Dybcio wrote:
>
> 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
> ---
>
On Fri, 23 Feb 2024 at 23:21, 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
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
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
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
Describe the GPU hardware on the QCM2290.
Reviewed-by: Dmitry Baryshkov
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
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
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
Add a driver for the GPU clock controller block found on the QCM2290 SoC.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/clk/qcom/Kconfig | 9 +
drivers/clk/qcom/Makefile| 1 +
drivers/clk/qcom/gpucc-qcm2290.c | 423
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 | 77 ++
include/dt-bindings/clock/qcom,qcm2290-gpucc.h | 32 +
2 files changed,
Bit of a megaseries, bunched together for your testing convenience..
Needs mesa!27665 [1] on the userland part, kmscube happily spins.
I'm feeling quite lukewarm about the memory barriers in patch 3..
Patch 1 for Will/smmu, 5-6 for drm/msm, rest for qcom
[1]
On Fri, 23 Feb 2024 at 22:48, Abhinav Kumar wrote:
>
>
>
> On 2/22/2024 3:43 AM, Dmitry Baryshkov wrote:
> > The DPU driver provides support for 4:2:0 planar YCbCr plane formats.
> > Extend it to also support 4:2:2 and 4:4:4 plat formats.
> >
>
> I checked myself and also internally on this. On
On 2/22/2024 3:43 AM, Dmitry Baryshkov wrote:
The DPU driver provides support for 4:2:0 planar YCbCr plane formats.
Extend it to also support 4:2:2 and 4:4:4 plat formats.
I checked myself and also internally on this. On sm8250, the DPU planes
do not support YUV444 and YUV422 (and the
On Wed, Feb 21, 2024 at 6:36 PM Dmitry Baryshkov
wrote:
>
> On Tue, 20 Feb 2024 at 16:31, Helen Koike wrote:
> >
> >
> >
> > On 20/02/2024 09:17, Dmitry Baryshkov wrote:
> > > Bump IGT revision to pick up Rob Clark's fixes for the msm driver:
> > >
> > > -
On 2/23/2024 9:56 AM, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> [
>This is a treewide change. I will likely re-create this patch again in
>the second week of the merge window of v6.9 and submit it then. Hoping
>to keep the conflicts that it will cause to a minimum.
On Fri, 23 Feb 2024 at 16:55, Neil Armstrong wrote:
>
> On 23/02/2024 15:52, Johan Hovold wrote:
> > On Fri, Feb 23, 2024 at 03:38:13PM +0100, Neil Armstrong wrote:
> >> On 23/02/2024 15:21, Johan Hovold wrote:
> >
> >>> But it is *not* standalone as I tried to explain above.
> >>>
> >>> So you
On Sat, 17 Feb 2024 16:02:22 +0100, Johan Hovold wrote:
> Starting with 6.8-rc1 the internal display sometimes fails to come up on
> machines like the Lenovo ThinkPad X13s and the logs indicate that this
> is due to a regression in the DRM subsystem [1].
>
> This series fixes a race in the
On 23/02/2024 15:52, Johan Hovold wrote:
On Fri, Feb 23, 2024 at 03:38:13PM +0100, Neil Armstrong wrote:
On 23/02/2024 15:21, Johan Hovold wrote:
But it is *not* standalone as I tried to explain above.
So you have to drop it again as the later patches depend on it and
cannot be merged
On 17/02/2024 16:02, Johan Hovold wrote:
Starting with 6.8-rc1 the internal display sometimes fails to come up on
machines like the Lenovo ThinkPad X13s and the logs indicate that this
is due to a regression in the DRM subsystem [1].
This series fixes a race in the pmic_glink_altmode driver
On Fri, Feb 23, 2024 at 03:38:13PM +0100, Neil Armstrong wrote:
> On 23/02/2024 15:21, Johan Hovold wrote:
> > But it is *not* standalone as I tried to explain above.
> >
> > So you have to drop it again as the later patches depend on it and
> > cannot be merged (through a different tree)
On 23/02/2024 15:21, Johan Hovold wrote:
On Fri, Feb 23, 2024 at 02:52:28PM +0100, Neil Armstrong wrote:
On 23/02/2024 13:51, Johan Hovold wrote:
On Fri, Feb 23, 2024 at 12:03:10PM +0100, Neil Armstrong wrote:
On 23/02/2024 12:02, Neil Armstrong wrote:
Thanks, Applied to
On Fri, Feb 23, 2024 at 04:18:08PM +0200, Dmitry Baryshkov wrote:
> On Fri, 23 Feb 2024 at 15:52, Neil Armstrong
> wrote:
> > On 23/02/2024 13:51, Johan Hovold wrote:
> > > On Fri, Feb 23, 2024 at 12:03:10PM +0100, Neil Armstrong wrote:
> > >> On 23/02/2024 12:02, Neil Armstrong wrote:
> > >>>
On Fri, Feb 23, 2024 at 02:52:28PM +0100, Neil Armstrong wrote:
> On 23/02/2024 13:51, Johan Hovold wrote:
> > On Fri, Feb 23, 2024 at 12:03:10PM +0100, Neil Armstrong wrote:
> >> On 23/02/2024 12:02, Neil Armstrong wrote:
> >>> Thanks, Applied to
On Fri, 23 Feb 2024 at 15:52, Neil Armstrong wrote:
>
> On 23/02/2024 13:51, Johan Hovold wrote:
> > On Fri, Feb 23, 2024 at 12:03:10PM +0100, Neil Armstrong wrote:
> >> On 23/02/2024 12:02, Neil Armstrong wrote:
> >>> Hi,
> >>>
> >>> On Sat, 17 Feb 2024 16:02:22 +0100, Johan Hovold wrote:
>
On 23/02/2024 13:51, Johan Hovold wrote:
On Fri, Feb 23, 2024 at 12:03:10PM +0100, Neil Armstrong wrote:
On 23/02/2024 12:02, Neil Armstrong wrote:
Hi,
On Sat, 17 Feb 2024 16:02:22 +0100, Johan Hovold wrote:
Starting with 6.8-rc1 the internal display sometimes fails to come up on
machines
On Fri, Feb 23, 2024 at 12:03:10PM +0100, Neil Armstrong wrote:
> On 23/02/2024 12:02, Neil Armstrong wrote:
> > Hi,
> >
> > On Sat, 17 Feb 2024 16:02:22 +0100, Johan Hovold wrote:
> >> Starting with 6.8-rc1 the internal display sometimes fails to come up on
> >> machines like the Lenovo ThinkPad
On Thu, Feb 22, 2024 at 10:57:07PM +0200, Dmitry Baryshkov wrote:
> On Sat, 17 Feb 2024 at 17:03, Johan Hovold wrote:
> >
> > Combining allocation and registration is an anti-pattern that should be
> > avoided. Add two new functions for allocating and registering an dp-hpd
> > bridge with a
On 17-02-24, 16:02, Johan Hovold wrote:
> Due to a long-standing issue in driver core, drivers may not probe defer
> after having registered child devices to avoid triggering a probe
> deferral loop (see fbc35b45f9f6 ("Add documentation on meaning of
> -EPROBE_DEFER")).
>
> Move registration of
On 17-02-24, 16:02, Johan Hovold wrote:
> Due to a long-standing issue in driver core, drivers may not probe defer
> after having registered child devices to avoid triggering a probe
> deferral loop (see fbc35b45f9f6 ("Add documentation on meaning of
> -EPROBE_DEFER")).
>
> This could potentially
On 17/02/2024 16:02, Johan Hovold wrote:
From: Rob Clark
We need to bail out before adding/removing devices if we are going to
-EPROBE_DEFER. Otherwise boot can get stuck in a probe deferral loop due
to a long-standing issue in driver core (see fbc35b45f9f6 ("Add
documentation on meaning of
On 23/02/2024 12:02, Neil Armstrong wrote:
Hi,
On Sat, 17 Feb 2024 16:02:22 +0100, Johan Hovold wrote:
Starting with 6.8-rc1 the internal display sometimes fails to come up on
machines like the Lenovo ThinkPad X13s and the logs indicate that this
is due to a regression in the DRM subsystem
Hi,
On Sat, 17 Feb 2024 16:02:22 +0100, Johan Hovold wrote:
> Starting with 6.8-rc1 the internal display sometimes fails to come up on
> machines like the Lenovo ThinkPad X13s and the logs indicate that this
> is due to a regression in the DRM subsystem [1].
>
> This series fixes a race in the
On 17/02/2024 16:02, Johan Hovold wrote:
The two device node references taken during allocation need to be
dropped when the auxiliary device is freed.
Fixes: 6914968a0b52 ("drm/bridge: properly refcount DT nodes in aux bridge
drivers")
Cc: Dmitry Baryshkov
Cc: Neil Armstrong
Signed-off-by:
On 17/02/2024 16:02, Johan Hovold wrote:
The two device node references taken during allocation need to be
dropped when the auxiliary device is freed.
Fixes: 6914968a0b52 ("drm/bridge: properly refcount DT nodes in aux bridge
drivers")
Cc: Dmitry Baryshkov
Cc: Neil Armstrong
Signed-off-by:
34 matches
Mail list logo
