Re: [PATCH v2 06/17] drm/v3d: Decouple job allocation from job initiation
El jue, 23-11-2023 a las 21:47 -0300, Maíra Canal escribió:
> We want to allow the IOCTLs to allocate the job without initiating
> it.
> This will be useful for the CPU job submission IOCTL, as the CPU job
> has
> the need to use information from the user extensions. Currently, the
> user extensions are parsed before the job allocation, making it
> impossible to fill the CPU job when parsing the user extensions.
> Therefore, decouple the job allocation from the job initiation.
>
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/v3d/v3d_submit.c | 23 ++-
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_submit.c
> b/drivers/gpu/drm/v3d/v3d_submit.c
> index fe46dd316ca0..ed1a310bbd2f 100644
> --- a/drivers/gpu/drm/v3d/v3d_submit.c
> +++ b/drivers/gpu/drm/v3d/v3d_submit.c
> @@ -135,6 +135,21 @@ void v3d_job_put(struct v3d_job *job)
> kref_put(&job->refcount, job->free);
> }
>
> +static int
> +v3d_job_allocate(void **container, size_t size)
> +{
> + if (*container)
> + return 0;
Mmm... is this really what we want? At least right now we expect
v3d_job_allocate to always allocate memory, is there any scenario in
which we would expect to call this with an already allocated container?
Iago
> +
> + *container = kcalloc(1, size, GFP_KERNEL);
> + if (!*container) {
> + DRM_ERROR("Cannot allocate memory for V3D job.\n");
> + return -ENOMEM;
> + }
> +
> + return 0;
> +}
> +
> static int
> v3d_job_init(struct v3d_dev *v3d, struct drm_file *file_priv,
> void **container, size_t size, void (*free)(struct kref
> *ref),
> @@ -145,11 +160,9 @@ v3d_job_init(struct v3d_dev *v3d, struct
> drm_file *file_priv,
> bool has_multisync = se && (se->flags &
> DRM_V3D_EXT_ID_MULTI_SYNC);
> int ret, i;
>
> - *container = kcalloc(1, size, GFP_KERNEL);
> - if (!*container) {
> - DRM_ERROR("Cannot allocate memory for v3d job.");
> - return -ENOMEM;
> - }
> + ret = v3d_job_allocate(container, size);
> + if (ret)
> + return ret;
>
> job = *container;
> job->v3d = v3d;
Re: (subset) [PATCH v9 00/12] drm/meson: add support for MIPI DSI Display
Hi, On Fri, 24 Nov 2023 09:41:11 +0100, Neil Armstrong wrote: > The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver > (ver 1.21a), > with a custom glue managing the IP resets, clock and data input similar to > the DW-HDMI > glue on the same Amlogic SoCs. > > This is a follow-up of v5 now the DRM patches are applied, the clk & DT > changes > remains for a full DSI support on G12A & SM1 platforms. > > [...] Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v6.8/arm64-dt) [02/12] dt-bindings: soc: amlogic,meson-gx-hhi-sysctrl: add example covering meson-axg-hhi-sysctrl https://git.kernel.org/amlogic/c/beb9c30ba4188e481991d91124c554f61a7ec121 These changes has been applied on the intermediate git tree [1]. The v6.8/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers for inclusion in their intermediate git branches in order to be sent to Linus during the next merge window, or sooner if it's a set of fixes. In the cases of fixes, those will be merged in the current release candidate kernel and as soon they appear on the Linux master branch they will be backported to the previous Stable and Long-Stable kernels [2]. The intermediate git branches are merged daily in the linux-next tree [3], people are encouraged testing these pre-release kernels and report issues on the relevant mailing-lists. If problems are discovered on those changes, please submit a signed-off-by revert patch followed by a corrective changeset. [1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git [3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git -- Neil
Re: [PATCH v9 00/12] drm/meson: add support for MIPI DSI Display
Hi Vinod, On 24/11/2023 09:41, Neil Armstrong wrote: --- Neil Armstrong (12): dt-bindings: clk: g12a-clkc: add CTS_ENCL clock ids dt-bindings: soc: amlogic,meson-gx-hhi-sysctrl: add example covering meson-axg-hhi-sysctrl dt-bindings: phy: amlogic,meson-axg-mipi-pcie-analog: drop text about parent syscon and drop example dt-bindings: phy: amlogic,g12a-mipi-dphy-analog: drop unneeded reg property and example Could you pick patches 3 and 4 ? they are both reviewed. Thanks, Neil dt-bindings: arm: amlogic: Document the MNT Reform 2 CM4 adapter with a BPI-CM4 Module clk: meson: g12a: add CTS_ENCL & CTS_ENCL_SEL clocks clk: meson: add vclk driver clk: meson: g12a: make VCLK2 and ENCL clock path configurable by CCF drm/meson: gate px_clk when setting rate arm64: meson: g12-common: add the MIPI DSI nodes DONOTMERGE: arm64: meson: khadas-vim3l: add DSI panel arm64: dts: amlogic: meson-g12b-bananapi-cm4: add support for MNT Reform2 with CM4 adaper Documentation/devicetree/bindings/arm/amlogic.yaml | 1 + .../phy/amlogic,g12a-mipi-dphy-analog.yaml | 12 - .../phy/amlogic,meson-axg-mipi-pcie-analog.yaml| 17 - .../soc/amlogic/amlogic,meson-gx-hhi-sysctrl.yaml | 33 ++ arch/arm64/boot/dts/amlogic/Makefile | 1 + arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 70 .../meson-g12b-bananapi-cm4-mnt-reform2.dts| 384 + .../boot/dts/amlogic/meson-g12b-khadas-vim3.dtsi | 2 +- arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi | 74 .../boot/dts/amlogic/meson-sm1-khadas-vim3l.dts| 2 +- drivers/clk/meson/Kconfig | 5 + drivers/clk/meson/Makefile | 1 + drivers/clk/meson/g12a.c | 106 -- drivers/clk/meson/vclk.c | 141 drivers/clk/meson/vclk.h | 51 +++ drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 7 + include/dt-bindings/clock/g12a-clkc.h | 2 + 17 files changed, 858 insertions(+), 51 deletions(-) --- base-commit: b0b93834348aaf1a6e14693b4f1d17d3ec024257 change-id: 20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-b8e5217e1f4a Best regards,
Re: [PATCH v9 07/12] clk: meson: add vclk driver
On 24/11/2023 15:41, Jerome Brunet wrote:
On Fri 24 Nov 2023 at 09:41, Neil Armstrong wrote:
The VCLK and VCLK_DIV clocks have supplementary bits.
The VCLK has a "SOFT RESET" bit to toggle after the whole
VCLK sub-tree rate has been set, this is implemented in
the gate enable callback.
The VCLK_DIV clocks as enable and reset bits used to disable
and reset the divider, associated with CLK_SET_RATE_GATE it ensures
the rate is set while the divider is disabled and in reset mode.
The VCLK_DIV enable bit isn't implemented as a gate since it's part
of the divider logic and vendor does this exact sequence to ensure
the divider is correctly set.
Signed-off-by: Neil Armstrong
---
drivers/clk/meson/Kconfig | 5 ++
drivers/clk/meson/Makefile | 1 +
drivers/clk/meson/vclk.c | 141 +
drivers/clk/meson/vclk.h | 51
4 files changed, 198 insertions(+)
diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
index 29ffd14d267b..59a40a49f8e1 100644
--- a/drivers/clk/meson/Kconfig
+++ b/drivers/clk/meson/Kconfig
@@ -30,6 +30,10 @@ config COMMON_CLK_MESON_VID_PLL_DIV
tristate
select COMMON_CLK_MESON_REGMAP
+config COMMON_CLK_MESON_VCLK
+ tristate
+ select COMMON_CLK_MESON_REGMAP
+
config COMMON_CLK_MESON_CLKC_UTILS
tristate
@@ -140,6 +144,7 @@ config COMMON_CLK_G12A
select COMMON_CLK_MESON_EE_CLKC
select COMMON_CLK_MESON_CPU_DYNDIV
select COMMON_CLK_MESON_VID_PLL_DIV
+ select COMMON_CLK_MESON_VCLK
This particular line belong in the next patch
Indeed
select MFD_SYSCON
help
Support for the clock controller on Amlogic S905D2, S905X2 and S905Y2
diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index 9ee4b954c896..9ba43fe7a07a 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK_MESON_PLL) += clk-pll.o
obj-$(CONFIG_COMMON_CLK_MESON_REGMAP) += clk-regmap.o
obj-$(CONFIG_COMMON_CLK_MESON_SCLK_DIV) += sclk-div.o
obj-$(CONFIG_COMMON_CLK_MESON_VID_PLL_DIV) += vid-pll-div.o
+obj-$(CONFIG_COMMON_CLK_MESON_VCLK) += vclk.o
# Amlogic Clock controllers
diff --git a/drivers/clk/meson/vclk.c b/drivers/clk/meson/vclk.c
new file mode 100644
index ..47f08a52b49f
--- /dev/null
+++ b/drivers/clk/meson/vclk.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 Neil Armstrong
+ */
+
+#include
+#include "vclk.h"
+
+/* The VCLK gate has a supplementary reset bit to pulse after ungating */
+
+static inline struct clk_regmap_vclk_data *
+clk_get_regmap_vclk_data(struct clk_regmap *clk)
+{
+ return (struct clk_regmap_vclk_data *)clk->data;
+}
+
+static int clk_regmap_vclk_enable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct clk_regmap_vclk_data *vclk = clk_get_regmap_vclk_data(clk);
+
+ meson_parm_write(clk->map, &vclk->enable, 1);
+
+ /* Do a reset pulse */
+ meson_parm_write(clk->map, &vclk->reset, 1);
+ meson_parm_write(clk->map, &vclk->reset, 0);
+
+ return 0;
+}
+
+static void clk_regmap_vclk_disable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct clk_regmap_vclk_data *vclk = clk_get_regmap_vclk_data(clk);
+
+ meson_parm_write(clk->map, &vclk->enable, 0);
+}
+
+static int clk_regmap_vclk_is_enabled(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct clk_regmap_vclk_data *vclk = clk_get_regmap_vclk_data(clk);
+
+ return meson_parm_read(clk->map, &vclk->enable);
+}
+
+const struct clk_ops clk_regmap_vclk_ops = {
+ .enable = clk_regmap_vclk_enable,
+ .disable = clk_regmap_vclk_disable,
+ .is_enabled = clk_regmap_vclk_is_enabled,
+};
+EXPORT_SYMBOL_GPL(clk_regmap_vclk_ops);
s/clk_regmap_vclk/meson_vclk at least for what is exported, ideally most
all the code.
I get clk_regmap_ comes from code copied from clk_regmap.c.
The reason the this part is different (and not using parm) if that when
I converted amlogic to regmap, I hope we could make this generic,
possibly converging between aml and qcom (which was the only other
platform using regmap for clock at the time). This is why clk_regmap.c
is a bit different from the other driver.
For the aml specific drivers, best to look at the mpll or cpu-dyndiv one.
Ack
+
+/* The VCLK Divider has supplementary reset & enable bits */
+
+static inline struct clk_regmap_vclk_div_data *
+clk_get_regmap_vclk_div_data(struct clk_regmap *clk)
+{
+ return (struct clk_regmap_vclk_div_data *)clk->data;
+}
+
+static unsigned long clk_regmap_vclk_div_recalc_rate(struct clk_hw *hw,
+unsigned long prate)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct clk_regmap_vclk_div_data *vclk =
clk_get_regmap_vclk_div_data(clk);
Re: [PATCH v9 08/12] clk: meson: g12a: make VCLK2 and ENCL clock path configurable by CCF
Hi, On 24/11/2023 16:32, Jerome Brunet wrote: On Fri 24 Nov 2023 at 16:15, Neil Armstrong wrote: On 24/11/2023 15:12, Jerome Brunet wrote: On Fri 24 Nov 2023 at 09:41, Neil Armstrong wrote: In order to setup the DSI clock, let's make the unused VCLK2 clock path configuration via CCF. The nocache option is removed from following clocks: - vclk2_sel - vclk2_input - vclk2_div - vclk2 - vclk_div1 - vclk2_div2_en - vclk2_div4_en - vclk2_div6_en - vclk2_div12_en - vclk2_div2 - vclk2_div4 - vclk2_div6 - vclk2_div12 - cts_encl_sel vclk2 and vclk2_div uses the newly introduced vclk regmap driver to handle the enable and reset bits. In order to set a rate on cts_encl via the vclk2 clock path, the NO_REPARENT flag is set on cts_encl_sel & vclk2_sel in order to keep CCF from selection a parent. The parents of cts_encl_sel & vclk2_sel are expected to be defined in DT. The following clock scheme is to be used for DSI: xtal \_ gp0_pll_dco \_ gp0_pll |- vclk2_sel | \_ vclk2_input | \_ vclk2_div |\_ vclk2 | \_ vclk2_div1 | \_ cts_encl_sel | \_ cts_encl -> to VPU LCD Encoder |- mipi_dsi_pxclk_sel \_ mipi_dsi_pxclk_div \_ mipi_dsi_pxclk-> to DSI controller The mipi_dsi_pxclk_div is set as RO in order to use the same GP0 for mipi_dsi_pxclk and vclk2_input. Could you explain a bit more this part of about the RO ops ? Maybe I'm missing something. You would be relying on the reset being always the way it. It is probable but not safe. A way to deal with the shared GP0 would be to: * cut rate propagation at mipi_dsi_pxclk_sel (already done) and (vclk2_sel - TBD) ... * Set GP0 base rate through assigned-clock-rate (which you already in patch 11) With this, I'm not sure anything needs to be RO for the rates to be set properly for each subtree. Also, with the subtree above and your example in patch 11, it looks odd that PXCLK is manually set through DT while ENCL is not. Both are input of dsi driver. So the deal is about dynamic setup of clocks for DSI bridges, not really for panels where we can probably know in advance the clock setup. In this particular case, we need to keep a ratio between the vclk and the DSI bitclk, the DSI bitclk is taken from mipi_dsi_pxclk and vclk is derived from gp0 via vclk2. If we set the bitclk rate via mipi_dsi_pxclk, CCF will try to use mipi_dsi_pxclk_div to achieve the rate, If you have CLK_RATE_PARENT on mipi_dsi_pxclk_sel, I'm not surprised it does that, but you don't :/ I'm quite surprised it would do that, or even could. Hmm, I need to recheck the clock tree again... seems I got lost in the different revisions... From your example setting 96Mhz on both gp0 and mipi_dsi_pxclk, since you've proposed RO-OPS, I suppose the divider is assumed to be 1 and stay like that forever. With rate propagation disabled mipi_dsi_pxclk_sel and GP0 is 96Mhz, CCF would have no choice but picking 1 as divider, so I don't understand how CCF would pick anything else and how RO-OPS help and it does it everytime I tried, breaking the vclk/bitclk ratio, and we have no way to know the gp0 rate in this case. If you really want to ensure the divider value is always 1, why not use a divider table allowing only 1 ? Adding a comment in the g12 clock driver would nice because this not obvious. It would be safer than relying on the reset value. Indeed, will switch to that I suspect mipi_dsi_pxclk_div was added to achieve fractional vclk/bitclk ratios, since it doesn't exist on AXG. Not sure we would ever need it... and none of the other upstream DSI drivers supports such setups. The main reasons I set only mipi_dsi_pxclk in DT is because : 1) the DSI controller requires a bitclk to respond, pclk is not enough 2) GP0 is disabled with an invalid config at cold boot, thus we cannot rely on a default/safe rate on an initial prepare_enable(). This permits setting initial valid state for the DSI controller, while the actual bitclk and vclk are calculated dynamically with panel/bridge runtime parameters. Nothing against setting rate in DT when it is static. Setting it then overriding it is not easy to follow. Yup, would be simpler to only have parenting set in DT, since it must stay static, I'm fine trying to move rate setup to code. To work around GP0 not being set, assuming you want to keep rate propagation as it is, you could call clk_set_rate() on cts_encl (possibly w/o enabling it) to force a setup on gp0 then clk_prepare_enable() on pxclk. You'd get a your safe rate on GP0 and the clock you need on pxclk. It is a bit hackish. Might be better to claim gp0 in your driver to manage it directly, cutting rate propagation above it to control each branch of the subtree as you need. It seems you need to have control over that anyway and it would be clear GP0 is expected to belong to DSI. Controlling the PLL from the DSI control
Re: [PATCH v9 03/20] dt-bindings: gpu: Add Imagination Technologies PowerVR/IMG GPU
Hi Donald,
On Wed, Nov 22, 2023 at 5:36 PM Donald Robson wrote:
> From: Sarah Walker
>
> Add the device tree binding documentation for the IMG AXE GPU used in
> TI AM62 SoCs.
>
> Co-developed-by: Frank Binns
> Signed-off-by: Frank Binns
> Signed-off-by: Sarah Walker
> Signed-off-by: Donald Robson
Thanks for your patch, which is now commit 6a85c3b14728f0d5
("dt-bindings: gpu: Add Imagination Technologies PowerVR/IMG GPU") in
drm-misc/for-linux-next.
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> +properties:
> + compatible:
> +items:
> + - enum:
> + - ti,am62-gpu
> + - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable
Why the double "img", and not just "img,axe"?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 07/17] drm/v3d: Add a CPU job submission
El jue, 23-11-2023 a las 21:47 -0300, Maíra Canal escribió:
> From: Melissa Wen
>
> Create a new type of job, a CPU job. A CPU job is a type of job that
> performs operations that requires CPU intervention. The overall idea
> is
> to use user extensions to enable different types of CPU job, allowing
> the
> CPU job to perform different operations according to the type of user
> externsion. The user extension ID identify the type of CPU job that
s/externsion/extension
Iago
> must
> be dealt.
>
> Having a CPU job is interesting for synchronization purposes as a CPU
> job has a queue like any other V3D job and can be synchoronized by
> the
> multisync extension.
>
> Signed-off-by: Melissa Wen
> Co-developed-by: Maíra Canal
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/v3d/v3d_drv.c | 4 ++
> drivers/gpu/drm/v3d/v3d_drv.h | 14 +-
> drivers/gpu/drm/v3d/v3d_sched.c | 57 +++
> drivers/gpu/drm/v3d/v3d_submit.c | 79
>
> include/uapi/drm/v3d_drm.h | 17 +++
> 5 files changed, 170 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_drv.c
> b/drivers/gpu/drm/v3d/v3d_drv.c
> index 44a1ca57d6a4..3debf37e7d9b 100644
> --- a/drivers/gpu/drm/v3d/v3d_drv.c
> +++ b/drivers/gpu/drm/v3d/v3d_drv.c
> @@ -91,6 +91,9 @@ static int v3d_get_param_ioctl(struct drm_device
> *dev, void *data,
> case DRM_V3D_PARAM_SUPPORTS_MULTISYNC_EXT:
> args->value = 1;
> return 0;
> + case DRM_V3D_PARAM_SUPPORTS_CPU_QUEUE:
> + args->value = 1;
> + return 0;
> default:
> DRM_DEBUG("Unknown parameter %d\n", args->param);
> return -EINVAL;
> @@ -189,6 +192,7 @@ static const struct drm_ioctl_desc
> v3d_drm_ioctls[] = {
> DRM_IOCTL_DEF_DRV(V3D_PERFMON_CREATE,
> v3d_perfmon_create_ioctl, DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(V3D_PERFMON_DESTROY,
> v3d_perfmon_destroy_ioctl, DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(V3D_PERFMON_GET_VALUES,
> v3d_perfmon_get_values_ioctl, DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(V3D_SUBMIT_CPU, v3d_submit_cpu_ioctl,
> DRM_RENDER_ALLOW | DRM_AUTH),
> };
>
> static const struct drm_driver v3d_drm_driver = {
> diff --git a/drivers/gpu/drm/v3d/v3d_drv.h
> b/drivers/gpu/drm/v3d/v3d_drv.h
> index 4db9ace66024..010b146140ad 100644
> --- a/drivers/gpu/drm/v3d/v3d_drv.h
> +++ b/drivers/gpu/drm/v3d/v3d_drv.h
> @@ -19,7 +19,7 @@ struct reset_control;
>
> #define GMP_GRANULARITY (128 * 1024)
>
> -#define V3D_MAX_QUEUES (V3D_CACHE_CLEAN + 1)
> +#define V3D_MAX_QUEUES (V3D_CPU + 1)
>
> static inline char *v3d_queue_to_string(enum v3d_queue queue)
> {
> @@ -29,6 +29,7 @@ static inline char *v3d_queue_to_string(enum
> v3d_queue queue)
> case V3D_TFU: return "tfu";
> case V3D_CSD: return "csd";
> case V3D_CACHE_CLEAN: return "cache_clean";
> + case V3D_CPU: return "cpu";
> }
> return "UNKNOWN";
> }
> @@ -122,6 +123,7 @@ struct v3d_dev {
> struct v3d_render_job *render_job;
> struct v3d_tfu_job *tfu_job;
> struct v3d_csd_job *csd_job;
> + struct v3d_cpu_job *cpu_job;
>
> struct v3d_queue_state queue[V3D_MAX_QUEUES];
>
> @@ -312,6 +314,14 @@ struct v3d_csd_job {
> struct drm_v3d_submit_csd args;
> };
>
> +enum v3d_cpu_job_type {};
> +
> +struct v3d_cpu_job {
> + struct v3d_job base;
> +
> + enum v3d_cpu_job_type job_type;
> +};
> +
> struct v3d_submit_outsync {
> struct drm_syncobj *syncobj;
> };
> @@ -414,6 +424,8 @@ int v3d_submit_tfu_ioctl(struct drm_device *dev,
> void *data,
> struct drm_file *file_priv);
> int v3d_submit_csd_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file_priv);
> +int v3d_submit_cpu_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file_priv);
>
> /* v3d_irq.c */
> int v3d_irq_init(struct v3d_dev *v3d);
> diff --git a/drivers/gpu/drm/v3d/v3d_sched.c
> b/drivers/gpu/drm/v3d/v3d_sched.c
> index fccbea2a5f2e..a32c91b94898 100644
> --- a/drivers/gpu/drm/v3d/v3d_sched.c
> +++ b/drivers/gpu/drm/v3d/v3d_sched.c
> @@ -55,6 +55,12 @@ to_csd_job(struct drm_sched_job *sched_job)
> return container_of(sched_job, struct v3d_csd_job,
> base.base);
> }
>
> +static struct v3d_cpu_job *
> +to_cpu_job(struct drm_sched_job *sched_job)
> +{
> + return container_of(sched_job, struct v3d_cpu_job,
> base.base);
> +}
> +
> static void
> v3d_sched_job_free(struct drm_sched_job *sched_job)
> {
> @@ -262,6 +268,42 @@ v3d_csd_job_run(struct drm_sched_job *sched_job)
> return fence;
> }
>
> +static struct dma_fence *
> +v3d_cpu_job_run(struct drm_sched_job *sched_job)
> +{
> + struct v3d_cpu_job *job = to_cpu_job(sched_job);
> + struct v3d_dev *v3d = job->base.v3d;
> + struct v3d_file_priv *file = job->base.
Re: [PATCH v3] drm/mediatek: Stop using iommu_present()
Il 23/11/23 14:41, Robin Murphy ha scritto: Remove the pointless check. If an IOMMU is providing transparent DMA API ops for any device(s) we care about, the DT code will have enforced the appropriate probe ordering already. And if the IOMMU *is* entirely absent, then attempting to go ahead with CMA and either suceeding or failing decisively seems more useful than deferring forever. Signed-off-by: Robin Murphy Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v2 07/17] drm/v3d: Add a CPU job submission
El jue, 23-11-2023 a las 21:47 -0300, Maíra Canal escribió:
> From: Melissa Wen
>
> Create a new type of job, a CPU job. A CPU job is a type of job that
> performs operations that requires CPU intervention. The overall idea
> is
> to use user extensions to enable different types of CPU job, allowing
> the
> CPU job to perform different operations according to the type of user
> externsion. The user extension ID identify the type of CPU job that
> must
> be dealt.
>
> Having a CPU job is interesting for synchronization purposes as a CPU
> job has a queue like any other V3D job and can be synchoronized by
> the
> multisync extension.
>
> Signed-off-by: Melissa Wen
> Co-developed-by: Maíra Canal
> Signed-off-by: Maíra Canal
> ---
>
(...)
> diff --git a/drivers/gpu/drm/v3d/v3d_sched.c
> b/drivers/gpu/drm/v3d/v3d_sched.c
> index fccbea2a5f2e..a32c91b94898 100644
> --- a/drivers/gpu/drm/v3d/v3d_sched.c
> +++ b/drivers/gpu/drm/v3d/v3d_sched.c
> @@ -55,6 +55,12 @@ to_csd_job(struct drm_sched_job *sched_job)
> return container_of(sched_job, struct v3d_csd_job,
> base.base);
> }
>
> +static struct v3d_cpu_job *
> +to_cpu_job(struct drm_sched_job *sched_job)
> +{
> + return container_of(sched_job, struct v3d_cpu_job,
> base.base);
> +}
> +
> static void
> v3d_sched_job_free(struct drm_sched_job *sched_job)
> {
> @@ -262,6 +268,42 @@ v3d_csd_job_run(struct drm_sched_job *sched_job)
> return fence;
> }
>
> +static struct dma_fence *
> +v3d_cpu_job_run(struct drm_sched_job *sched_job)
> +{
> + struct v3d_cpu_job *job = to_cpu_job(sched_job);
> + struct v3d_dev *v3d = job->base.v3d;
> + struct v3d_file_priv *file = job->base.file->driver_priv;
> + u64 runtime;
> +
> + void (*v3d_cpu_job_fn[])(struct v3d_cpu_job *job) = { };
Shouldn't this be a static const? Also, maybe we want declare it
outside the function itself?
Iago
> +
> + v3d->cpu_job = job;
> +
> + if (job->job_type >= ARRAY_SIZE(v3d_cpu_job_fn)) {
> + DRM_DEBUG_DRIVER("Unknown CPU job: %d\n", job-
> >job_type);
> + return NULL;
> + }
> +
> + file->start_ns[V3D_CPU] = local_clock();
> + v3d->queue[V3D_CPU].start_ns = file->start_ns[V3D_CPU];
> +
> + v3d_cpu_job_fn[job->job_type](job);
> +
> + runtime = local_clock() - file->start_ns[V3D_CPU];
> +
> + file->enabled_ns[V3D_CPU] += runtime;
> + v3d->queue[V3D_CPU].enabled_ns += runtime;
> +
> + file->jobs_sent[V3D_CPU]++;
> + v3d->queue[V3D_CPU].jobs_sent++;
> +
> + file->start_ns[V3D_CPU] = 0;
> + v3d->queue[V3D_CPU].start_ns = 0;
> +
> + return NULL;
> +}
Re: [PATCH] drm/mxsfb: Switch to drmm_mode_config_init
Hi
Am 25.11.23 um 23:25 schrieb Marek Vasut:
Switch from deprecated unmanaged drm_mode_config_init() to
managed drmm_mode_config_init(). No functional change.
Signed-off-by: Marek Vasut
---
Cc: Daniel Vetter
Cc: David Airlie
Cc: Fabio Estevam
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: NXP Linux Team
Cc: Pengutronix Kernel Team
Cc: Sascha Hauer
Cc: Shawn Guo
Cc: Stefan Agner
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 3bfa369b2507e..9f746852b8ff2 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -248,7 +248,11 @@ static int mxsfb_load(struct drm_device *drm,
pm_runtime_enable(drm->dev);
/* Modeset init */
- drm_mode_config_init(drm);
The corresponding call to drm_mode_config_cleanup() needs to be removed
as well.
Best regards
Thomas
+ ret = drmm_mode_config_init(drm);
+ if (ret) {
+ dev_err(drm->dev, "Failed to initialize mode config\n");
+ goto err_vblank;
+ }
ret = mxsfb_kms_init(mxsfb);
if (ret < 0) {
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [PATCH] drm/mxsfb: Drop extra space in request_irq args
Am 25.11.23 um 23:24 schrieb Marek Vasut: Drop extra space, no functional change. Signed-off-by: Marek Vasut --- Cc: Daniel Vetter Cc: David Airlie Cc: Fabio Estevam Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: NXP Linux Team Cc: Pengutronix Kernel Team Cc: Sascha Hauer Cc: Shawn Guo Cc: Stefan Agner Cc: Thomas Zimmermann Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-ker...@lists.infradead.org Reviewed-by: Thomas Zimmermann --- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c index 625c1bfc41733..3bfa369b2507e 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c @@ -197,7 +197,7 @@ static int mxsfb_irq_install(struct drm_device *dev, int irq) mxsfb_irq_disable(dev); - return request_irq(irq, mxsfb_irq_handler, 0, dev->driver->name, dev); + return request_irq(irq, mxsfb_irq_handler, 0, dev->driver->name, dev); } static void mxsfb_irq_uninstall(struct drm_device *dev) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH v1 0/3] Rockchip inno_hdmi update
Hi Johan, On Sun, Nov 26, 2023 at 11:55:03AM +0100, Johan Jonker wrote: > Combined update for the Rockchip inno_hdmi driver in a > somewhat similar way to what is proposed for the > "Create HDMI Connector infrastructure patch serie". > Keeping the inno_hdmi and rk3066_hdmi driver functions > comparable makes maintanance easier. It's not clear to me what your intent is exactly, these are my exact patches that you just sent again? Maxime signature.asc Description: PGP signature
Re: [PATCH v2 13/17] drm/v3d: Create a CPU job extension for the timestamp query job
El jue, 23-11-2023 a las 21:47 -0300, Maíra Canal escribió:
(...)
> +static void
> +v3d_timestamp_query(struct v3d_cpu_job *job)
> +{
> + struct v3d_timestamp_query_info *timestamp_query = &job-
> >timestamp_query;
> + struct v3d_bo *bo = to_v3d_bo(job->base.bo[0]);
I presume there is an implicit expectation here that a timestamp query
job only has one BO where we are writing query results, right? Maybe we
should document this more explicitly in the uAPI and also check that we
have at least that one BO before trying to map it and write to it?
Also, is there a reason why we take the job reference from job-
>base.bo[0] instead of job->bo[0]?
Iago
> + u8 *value_addr;
> +
> + v3d_get_bo_vaddr(bo);
> +
> + for (int i = 0; i < timestamp_query->count; i++) {
> + value_addr = ((u8 *) bo->vaddr) + timestamp_query-
> >queries[i].offset;
> + *((u64 *) value_addr) = i == 0 ? ktime_get_ns() :
> 0ull;
> +
> + drm_syncobj_replace_fence(timestamp_query-
> >queries[i].syncobj,
> + job->base.done_fence);
> + }
> +
> + v3d_put_bo_vaddr(bo);
> +}
> +
> static struct dma_fence *
> v3d_cpu_job_run(struct drm_sched_job *sched_job)
> {
> @@ -315,6 +352,7 @@ v3d_cpu_job_run(struct drm_sched_job *sched_job)
>
> void (*v3d_cpu_job_fn[])(struct v3d_cpu_job *job) = {
> [V3D_CPU_JOB_TYPE_INDIRECT_CSD] =
> v3d_rewrite_csd_job_wg_counts_from_indirect,
> + [V3D_CPU_JOB_TYPE_TIMESTAMP_QUERY] =
> v3d_timestamp_query,
> };
>
> v3d->cpu_job = job;
> @@ -504,7 +542,7 @@ static const struct drm_sched_backend_ops
> v3d_cache_clean_sched_ops = {
> static const struct drm_sched_backend_ops v3d_cpu_sched_ops = {
> .run_job = v3d_cpu_job_run,
> .timedout_job = v3d_generic_job_timedout,
> - .free_job = v3d_sched_job_free
> + .free_job = v3d_cpu_job_free
> };
>
> int
> diff --git a/drivers/gpu/drm/v3d/v3d_submit.c
> b/drivers/gpu/drm/v3d/v3d_submit.c
> index b6707ef42706..2f03c8bca593 100644
> --- a/drivers/gpu/drm/v3d/v3d_submit.c
> +++ b/drivers/gpu/drm/v3d/v3d_submit.c
> @@ -438,6 +438,64 @@ v3d_get_cpu_indirect_csd_params(struct drm_file
> *file_priv,
> NULL, &info->acquire_ctx);
> }
>
> +/* Get data for the query timestamp job submission. */
> +static int
> +v3d_get_cpu_timestamp_query_params(struct drm_file *file_priv,
> + struct drm_v3d_extension __user
> *ext,
> + struct v3d_cpu_job *job)
> +{
> + u32 __user *offsets, *syncs;
> + struct drm_v3d_timestamp_query timestamp;
> +
> + if (!job) {
> + DRM_DEBUG("CPU job extension was attached to a GPU
> job.\n");
> + return -EINVAL;
> + }
> +
> + if (job->job_type) {
> + DRM_DEBUG("Two CPU job extensions were added to the
> same CPU job.\n");
> + return -EINVAL;
> + }
> +
> + if (copy_from_user(×tamp, ext, sizeof(timestamp)))
> + return -EFAULT;
> +
> + if (timestamp.pad)
> + return -EINVAL;
> +
> + job->job_type = V3D_CPU_JOB_TYPE_TIMESTAMP_QUERY;
> +
> + job->timestamp_query.queries =
> kvmalloc_array(timestamp.count,
> + sizeof(struct
> v3d_timestamp_query),
> + GFP_KERNEL);
> + if (!job->timestamp_query.queries)
> + return -ENOMEM;
> +
> + offsets = u64_to_user_ptr(timestamp.offsets);
> + syncs = u64_to_user_ptr(timestamp.syncs);
> +
> + for (int i = 0; i < timestamp.count; i++) {
> + u32 offset, sync;
> +
> + if (copy_from_user(&offset, offsets++,
> sizeof(offset))) {
> + kvfree(job->timestamp_query.queries);
> + return -EFAULT;
> + }
> +
> + job->timestamp_query.queries[i].offset = offset;
> +
> + if (copy_from_user(&sync, syncs++, sizeof(sync))) {
> + kvfree(job->timestamp_query.queries);
> + return -EFAULT;
> + }
> +
> + job->timestamp_query.queries[i].syncobj =
> drm_syncobj_find(file_priv, sync);
> + }
> + job->timestamp_query.count = timestamp.count;
> +
> + return 0;
> +}
> +
> /* Whenever userspace sets ioctl extensions, v3d_get_extensions
> parses data
> * according to the extension id (name).
> */
> @@ -466,6 +524,9 @@ v3d_get_extensions(struct drm_file *file_priv,
> case DRM_V3D_EXT_ID_CPU_INDIRECT_CSD:
> ret =
> v3d_get_cpu_indirect_csd_params(file_priv, user_ext, job);
> break;
> + case DRM_V3D_EXT_ID_CPU_TIMESTAMP_QUERY:
> + ret =
> v3d_get_cpu_timestamp_query_params(fil
Re: [PATCH v9 08/12] clk: meson: g12a: make VCLK2 and ENCL clock path configurable by CCF
>> >>> >>> I suspect mipi_dsi_pxclk_div was added to achieve fractional vclk/bitclk >>> ratios, >>> since it doesn't exist on AXG. Not sure we would ever need it... and none >>> of the other upstream DSI drivers supports such setups. >>> >>> The main reasons I set only mipi_dsi_pxclk in DT is because : >>> 1) the DSI controller requires a bitclk to respond, pclk is not enough >>> 2) GP0 is disabled with an invalid config at cold boot, thus we cannot >>> rely on a default/safe rate on an initial prepare_enable(). >>> This permits setting initial valid state for the DSI controller, while >>> the actual bitclk and vclk are calculated dynamically with panel/bridge >>> runtime parameters. >> Nothing against setting rate in DT when it is static. Setting it then >> overriding it is not easy to follow. > > Yup, would be simpler to only have parenting set in DT, since it must > stay static, I'm fine trying to move rate setup to code. > >> To work around GP0 not being set, assuming you want to keep rate >> propagation as it is, you could call clk_set_rate() on cts_encl (possibly w/o >> enabling it) to force a setup on gp0 then clk_prepare_enable() on >> pxclk. You'd get a your safe rate on GP0 and the clock you need on pxclk. >> It is a bit hackish. Might be better to claim gp0 in your driver to >> manage it directly, cutting rate propagation above it to control each >> branch of the subtree as you need. It seems you need to have control over >> that anyway and it would be clear GP0 is expected to belong to DSI. > > Controlling the PLL from the DSI controller seems violating too much layers, > DSI controller driver is not feed directly by the PLL so it's a non-sense > regarding DT properties. Not sure what you mean by this. You have shown in your the commit message that the DSI clocks make significant subtree. I don't see a problem if you need to manage the root of that subtree. I'd be great if you didn't need to, but it is what it is ... > > Setting a safe clock from the DSI controller probe is an idea, but again I > don't know which value I should use... You mentionned that the problem comes DSI bridges that needs to change at runtime. I don't know much about those TBH, but is there anyway you can come up with a static GP0 rate that would then be able to divide to serve all the rates bridge would need in your use case ? GP0 can go a lot higher than ~100MHz and there are dividers unused in the tree it seems. I suppose there is a finite number of required rate for each use case ? If there are not too many and there is a common divider that allows a common rate GP0 can do, it would solve your problem. It's a lot of if but It is worth checking. This is how audio works and DT assigned rate is a good match in this case. > > I'll review the clk parenting flags and try to hack something. > > Thanks, > Neil > >
Re: [PATCH 1/2] dt-bindings: display: simple: Add boe,bp101wx1-100 panel
On 27/11/2023 06:15, Tony Lindgren wrote: > This panel is found on Motorola mapphone tablets mz615 to mz617. > > Signed-off-by: Tony Lindgren Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v3 0/2] Add DSS support for TI AM62A7 SoC
Hi, On 08/11/2023 19:16, Aradhya Bhatia wrote: This patch series adds a new compatible for the Display SubSystem (DSS) controller on TI's AM62A7 SoC. It further adds the required support, for the same, in the tidss driver. The DSS controller is similar to the recently added AM625 DSS, with the key difference being the absence of VP1 output on the SoC. The VP1 in AM62A7 DSS is tied off and cannot be used, unlike in AM625, where the VP1 was connected to 2 OLDI TXes. The video pipeline that corresponds to VP1 still exists and can be used to overlay planes on the VP2's primary plane. This can be done using the overlay managers inside the SoC. Moreover, DSS VP2 can output Full-HD RGB888 DPI video signals. I have tested these patches on AM62A7 SK-EVM, which converts DPI signals to HDMI on the platform using the Sil9022A HDMI transmitter. All the patches, required to enable display on AM62A7-SK, can be found on my github fork[0] in the branch "next_am62a-v3". Regards Aradhya [0]: https://github.com/aradhya07/linux-ab/tree/next_am62a-v3 Change Log: V2 -> V3: - Add Krzysztof Kozlowski's R-b in patch 1/2. - Add new DISPC_VP_TIED_OFF for tied-off video-ports in patch 2/2. V1 -> V2: - Correctly sort DISPC_AM62A7 macro after DISPC_AM625 in patch 2/2. Previous Versions: V1: https://lore.kernel.org/all/20230818131750.4779-1-a-bhat...@ti.com/ V2: https://lore.kernel.org/all/20230818142124.8561-1-a-bhat...@ti.com/ Aradhya Bhatia (2): dt-bindings: display: ti: Add support for am62a7 dss drivers/tidss: Add support for AM62A7 DSS .../bindings/display/ti/ti,am65x-dss.yaml | 14 + drivers/gpu/drm/tidss/tidss_dispc.c | 59 +++ drivers/gpu/drm/tidss/tidss_dispc.h | 3 + drivers/gpu/drm/tidss/tidss_drv.c | 1 + 4 files changed, 77 insertions(+) base-commit: 2220f68f4504aa1ccce0fac721ccdb301e9da32f For the series: Reviewed-by: Tomi Valkeinen Tomi
Re: [PATCH v3 101/108] drm/bridge: ti-sn65dsi86: Make use of devm_pwmchip_alloc() function
Hello,
On Thu, Nov 23, 2023 at 10:17:15AM +0100, Uwe Kleine-König wrote:
> On Tue, Nov 21, 2023 at 08:14:14AM -0800, Doug Anderson wrote:
> > On Tue, Nov 21, 2023 at 8:05 AM Uwe Kleine-König
> > wrote:
> > > On Tue, Nov 21, 2023 at 07:15:51AM -0800, Doug Anderson wrote:
> > > > > @@ -1585,22 +1586,28 @@ static const struct pwm_ops ti_sn_pwm_ops = {
> > > > > static int ti_sn_pwm_probe(struct auxiliary_device *adev,
> > > > >const struct auxiliary_device_id *id)
> > > > > {
> > > > > + struct pwm_chip *chip;
> > > > > struct ti_sn65dsi86 *pdata =
> > > > > dev_get_drvdata(adev->dev.parent);
> > > > >
> > > > > - pdata->pchip.dev = pdata->dev;
> > > > > - pdata->pchip.ops = &ti_sn_pwm_ops;
> > > > > - pdata->pchip.npwm = 1;
> > > > > - pdata->pchip.of_xlate = of_pwm_single_xlate;
> > > > > - pdata->pchip.of_pwm_n_cells = 1;
> > > > > + /* XXX: should this better use adev->dev instead of
> > > > > pdata->dev? */
> > > > > + pdata->pchip = chip = devm_pwmchip_alloc(pdata->dev, 1,
> > > > > sizeof(&pdata));
> > > >
> > > > Yes, it should be "adev->dev". See recent commits like commit
> > > > 7b821db95140 ("drm/bridge: ti-sn65dsi86: Associate DSI device lifetime
> > > > with auxiliary device").
> > >
> > > I'd do that in a separate commit and not change that hidden in patch
> > > like this one. Agree? Then I'd keep that as is and not address this in
> > > this series. Maybe it will take another cycle until this patch goes in
> > > anyhow ...
> >
> > You could do it in a commit _before_ this one, but not a commit after
> > this one. Specifically before "${SUBJECT}" commit I think it was
> > benign to set pdata->pchip.dev to pdata->dev. Now you're starting to
> > use it for devm and the incorrect lifetime is worse, I think. Do you
> > agree?
>
> I considered suggesting:
>
> -->8--
> From 35e5050084737070686fc3e293e88e50276f0eeb Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=
> Date: Thu, 23 Nov 2023 09:55:13 +0100
> Subject: [PATCH] drm/bridge: ti-sn65dsi86: Associate PWM device to auxiliary
> device
>
> It's the ti_sn65dsi86.pwm auxiliary driver that creates the pwmchip, so
> let the auxiliary device be the parent of the pwm device.
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index c45c07840f64..b5d4c30c28b7 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -1587,7 +1587,7 @@ static int ti_sn_pwm_probe(struct auxiliary_device
> *adev,
> {
> struct ti_sn65dsi86 *pdata = dev_get_drvdata(adev->dev.parent);
>
> - pdata->pchip.dev = pdata->dev;
> + pdata->pchip.dev = &adev->dev;
> pdata->pchip.ops = &ti_sn_pwm_ops;
> pdata->pchip.npwm = 1;
> pdata->pchip.of_xlate = of_pwm_single_xlate;
>
> base-commit: 815d8b0425ad1164e45953ac3d56a9f6f63792cc
> -->8--
>
> But I wonder if pwm lookup (e.g. in
> arch/arm64/boot/dts/qcom/sc7180-acer-aspire1.dts for &backlight) still
> works then?
I checked the source and I think it works fine because
ti_sn65dsi86_add_aux_device() calls
device_set_of_node_from_dev(&aux->dev, dev); and so the
auxiliary_device's of_node points to the node with the #pwm-cells
property. I'll send a proper patch.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Re: [PATCH RFC v3 22/37] drm/rockchip: inno_hdmi: Remove useless output format
Hi, On Sat, Nov 25, 2023 at 11:00:52AM +0100, Johan Jonker wrote: > In stead of further cripplingRockchip HDMI drivers one could also make > it functional based on EDID info. I'm not crippling it, it was dead code. This has no functional impact whatsoever. > To start with the output could you turn RGB888 input and switch between > RGB444, YCBCR444 and YCBCR422 output. I don't have any hardware to test that out Maxime signature.asc Description: PGP signature
Re: [PATCH v2 11/12] drm/rockchip: vop2: Add debugfs support
On Wed, Nov 22, 2023 at 08:56:01PM +0800, Andy Yan wrote:
> From: Andy Yan
>
> /sys/kernel/debug/dri/vop2/summary: dump vop display state
> /sys/kernel/debug/dri/vop2/regs: dump whole vop registers
> /sys/kernel/debug/dri/vop2/active_regs: only dump the registers of
> activated modules
>
> Signed-off-by: Andy Yan
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 399 +++
> 1 file changed, 399 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index 9eecbe1f71f9..4a2342209c15 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -187,6 +188,7 @@ struct vop2 {
>*/
> u32 registered_num_wins;
>
> + struct resource *res;
> void __iomem *regs;
> struct regmap *map;
>
> @@ -228,6 +230,44 @@ struct vop2 {
> #define vop2_output_if_is_lvds(x)(x == ROCKCHIP_VOP2_EP_LVDS0 || x ==
> ROCKCHIP_VOP2_EP_LVDS1)
> #define vop2_output_if_is_dpi(x) (x == ROCKCHIP_VOP2_EP_RGB0)
>
> +struct vop2_regs_dump {
> + const char *name;
> + u32 base;
> + u32 en_reg;
> + u32 en_val;
> + u32 en_mask;
> +};
> +
> +/*
> + * bus-format types.
> + */
> +struct drm_bus_format_enum_list {
> + int type;
> + const char *name;
> +};
> +
> +static const struct drm_bus_format_enum_list drm_bus_format_enum_list[] = {
> + { DRM_MODE_CONNECTOR_Unknown, "Unknown" },
> + { MEDIA_BUS_FMT_RGB565_1X16, "RGB565_1X16" },
> + { MEDIA_BUS_FMT_RGB666_1X18, "RGB666_1X18" },
> + { MEDIA_BUS_FMT_RGB666_1X24_CPADHI, "RGB666_1X24_CPADHI" },
> + { MEDIA_BUS_FMT_RGB666_1X7X3_SPWG, "RGB666_1X7X3_SPWG" },
> + { MEDIA_BUS_FMT_YUV8_1X24, "YUV8_1X24" },
> + { MEDIA_BUS_FMT_UYYVYY8_0_5X24, "UYYVYY8_0_5X24" },
> + { MEDIA_BUS_FMT_YUV10_1X30, "YUV10_1X30" },
> + { MEDIA_BUS_FMT_UYYVYY10_0_5X30, "UYYVYY10_0_5X30" },
> + { MEDIA_BUS_FMT_RGB888_3X8, "RGB888_3X8" },
> + { MEDIA_BUS_FMT_RGB888_1X24, "RGB888_1X24" },
> + { MEDIA_BUS_FMT_RGB888_1X7X4_SPWG, "RGB888_1X7X4_SPWG" },
> + { MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA, "RGB888_1X7X4_JEIDA" },
> + { MEDIA_BUS_FMT_UYVY8_2X8, "UYVY8_2X8" },
> + { MEDIA_BUS_FMT_YUYV8_1X16, "YUYV8_1X16" },
> + { MEDIA_BUS_FMT_UYVY8_1X16, "UYVY8_1X16" },
> + { MEDIA_BUS_FMT_RGB101010_1X30, "RGB101010_1X30" },
> + { MEDIA_BUS_FMT_YUYV10_1X20, "YUYV10_1X20" },
> +};
> +static DRM_ENUM_NAME_FN(drm_get_bus_format_name, drm_bus_format_enum_list)
> +
> static const struct regmap_config vop2_regmap_config;
>
> static struct vop2_video_port *to_vop2_video_port(struct drm_crtc *crtc)
> @@ -2487,6 +2527,363 @@ static const struct drm_crtc_helper_funcs
> vop2_crtc_helper_funcs = {
> .atomic_disable = vop2_crtc_atomic_disable,
> };
>
> +static void vop2_dump_connector_on_crtc(struct drm_crtc *crtc, struct
> seq_file *s)
> +{
> + struct drm_connector_list_iter conn_iter;
> + struct drm_connector *connector;
> +
> + drm_connector_list_iter_begin(crtc->dev, &conn_iter);
> + drm_for_each_connector_iter(connector, &conn_iter) {
> + if (crtc->state->connector_mask & drm_connector_mask(connector))
> + seq_printf(s, "Connector: %s\n", connector->name);
> +
> + }
> + drm_connector_list_iter_end(&conn_iter);
> +}
> +
> +static int vop2_plane_state_dump(struct seq_file *s, struct drm_plane *plane)
> +{
> + struct vop2_win *win = to_vop2_win(plane);
> + struct drm_plane_state *pstate = plane->state;
> + struct drm_rect *src, *dst;
> + struct drm_framebuffer *fb;
> + struct drm_gem_object *obj;
> + struct rockchip_gem_object *rk_obj;
> + bool xmirror;
> + bool ymirror;
> + bool rotate_270;
> + bool rotate_90;
> + dma_addr_t fb_addr;
> + int i;
> +
> + seq_printf(s, "%s: %s\n", win->data->name, pstate->crtc ? "ACTIVE"
> : "DISABLED");
> + if (!pstate || !pstate->fb)
> + return 0;
> +
> + fb = pstate->fb;
> + src = &pstate->src;
> + dst = &pstate->dst;
> + xmirror = pstate->rotation & DRM_MODE_REFLECT_X ? true : false;
> + ymirror = pstate->rotation & DRM_MODE_REFLECT_Y ? true : false;
> + rotate_270 = pstate->rotation & DRM_MODE_ROTATE_270;
> + rotate_90 = pstate->rotation & DRM_MODE_ROTATE_90;
> +
> + seq_printf(s, "\twin_id: %d\n", win->win_id);
> +
> + seq_printf(s, "\tformat: %p4cc%s glb_alpha[0x%x]\n",
> +&fb->format->format,
> +drm_is_afbc(fb->modifier) ? "[AFBC]" : "",
> +pstate->alpha >> 8);
> + seq_printf(s, "\trotate: xmirror: %d ymirror: %d rotate_90: %d
> rotate_270: %d\n",
> +xmirror, ymirror, rotate_90, rotate_270);
> + seq_printf(s, "\tzpos: %d\n", pstate->normalized_zpos);
>
[PATCH] drm/bridge: ti-sn65dsi86: Associate PWM device to auxiliary device
It's the ti_sn65dsi86.pwm auxiliary driver that creates the pwmchip, so
let the auxiliary device be the parent of the pwm device.
Note that getting a reference to the ti-sn65dsi86's pwm using pwm_get()
isn't affected by this change as ti_sn65dsi86_add_aux_device() sets the
auxiliary device's of_node to that of the main device.
Also change PM runtime tracking and diagnostic messages to use that one.
As the PM runtime functions also handle parent devices this should work
fine, too.
Signed-off-by: Uwe Kleine-König
---
Hello,
this patch has an (easy to resolve) conflict with a patch I sent earlier
"drm/bridge: ti-sn65dsi86: Simplify using pm_runtime_resume_and_get()"
(https://lore.kernel.org/dri-devel/20231123175425.496956-2-u.kleine-koe...@pengutronix.de).
I was unsure if I should base this new patch on that older one.
While I think the patch is fine, I'd have a better feeling about it if
someone could give feedback that the PWM still works as intended with
this change.
Best regards
Uwe
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index c45c07840f64..254f0039dad2 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -1413,9 +1413,9 @@ static int ti_sn_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
int ret;
if (!pdata->pwm_enabled) {
- ret = pm_runtime_get_sync(pdata->dev);
+ ret = pm_runtime_get_sync(chip->dev);
if (ret < 0) {
- pm_runtime_put_sync(pdata->dev);
+ pm_runtime_put_sync(chip->dev);
return ret;
}
}
@@ -1431,7 +1431,7 @@ static int ti_sn_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
SN_GPIO_MUX_MASK << (2 *
SN_PWM_GPIO_IDX),
SN_GPIO_MUX_SPECIAL << (2 *
SN_PWM_GPIO_IDX));
if (ret) {
- dev_err(pdata->dev, "failed to mux in PWM
function\n");
+ dev_err(chip->dev, "failed to mux in PWM
function\n");
goto out;
}
}
@@ -1507,7 +1507,7 @@ static int ti_sn_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
ret = regmap_write(pdata->regmap, SN_PWM_PRE_DIV_REG, pre_div);
if (ret) {
- dev_err(pdata->dev, "failed to update PWM_PRE_DIV\n");
+ dev_err(chip->dev, "failed to update PWM_PRE_DIV\n");
goto out;
}
@@ -1519,7 +1519,7 @@ static int ti_sn_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
FIELD_PREP(SN_PWM_INV_MASK, state->polarity ==
PWM_POLARITY_INVERSED);
ret = regmap_write(pdata->regmap, SN_PWM_EN_INV_REG, pwm_en_inv);
if (ret) {
- dev_err(pdata->dev, "failed to update PWM_EN/PWM_INV\n");
+ dev_err(chip->dev, "failed to update PWM_EN/PWM_INV\n");
goto out;
}
@@ -1527,7 +1527,7 @@ static int ti_sn_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
out:
if (!pdata->pwm_enabled)
- pm_runtime_put_sync(pdata->dev);
+ pm_runtime_put_sync(chip->dev);
return ret;
}
@@ -1587,7 +1587,7 @@ static int ti_sn_pwm_probe(struct auxiliary_device *adev,
{
struct ti_sn65dsi86 *pdata = dev_get_drvdata(adev->dev.parent);
- pdata->pchip.dev = pdata->dev;
+ pdata->pchip.dev = &adev->dev;
pdata->pchip.ops = &ti_sn_pwm_ops;
pdata->pchip.npwm = 1;
pdata->pchip.of_xlate = of_pwm_single_xlate;
@@ -1603,7 +1603,7 @@ static void ti_sn_pwm_remove(struct auxiliary_device
*adev)
pwmchip_remove(&pdata->pchip);
if (pdata->pwm_enabled)
- pm_runtime_put_sync(pdata->dev);
+ pm_runtime_put_sync(&adev->dev);
}
static const struct auxiliary_device_id ti_sn_pwm_id_table[] = {
base-commit: 48bbaf8b793e0770798519f8ee1ea2908ff0943a
--
2.42.0
Re: [PATCH v2 11/12] drm/rockchip: vop2: Add debugfs support
Hi Sascha:
thanks for you review.
On 11/27/23 18:13, Sascha Hauer wrote:
On Wed, Nov 22, 2023 at 08:56:01PM +0800, Andy Yan wrote:
From: Andy Yan
/sys/kernel/debug/dri/vop2/summary: dump vop display state
/sys/kernel/debug/dri/vop2/regs: dump whole vop registers
/sys/kernel/debug/dri/vop2/active_regs: only dump the registers of
activated modules
Signed-off-by: Andy Yan
---
(no changes since v1)
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 399 +++
1 file changed, 399 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 9eecbe1f71f9..4a2342209c15 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -187,6 +188,7 @@ struct vop2 {
*/
u32 registered_num_wins;
+ struct resource *res;
void __iomem *regs;
struct regmap *map;
@@ -228,6 +230,44 @@ struct vop2 {
#define vop2_output_if_is_lvds(x) (x == ROCKCHIP_VOP2_EP_LVDS0 || x ==
ROCKCHIP_VOP2_EP_LVDS1)
#define vop2_output_if_is_dpi(x) (x == ROCKCHIP_VOP2_EP_RGB0)
+struct vop2_regs_dump {
+ const char *name;
+ u32 base;
+ u32 en_reg;
+ u32 en_val;
+ u32 en_mask;
+};
+
+/*
+ * bus-format types.
+ */
+struct drm_bus_format_enum_list {
+ int type;
+ const char *name;
+};
+
+static const struct drm_bus_format_enum_list drm_bus_format_enum_list[] = {
+ { DRM_MODE_CONNECTOR_Unknown, "Unknown" },
+ { MEDIA_BUS_FMT_RGB565_1X16, "RGB565_1X16" },
+ { MEDIA_BUS_FMT_RGB666_1X18, "RGB666_1X18" },
+ { MEDIA_BUS_FMT_RGB666_1X24_CPADHI, "RGB666_1X24_CPADHI" },
+ { MEDIA_BUS_FMT_RGB666_1X7X3_SPWG, "RGB666_1X7X3_SPWG" },
+ { MEDIA_BUS_FMT_YUV8_1X24, "YUV8_1X24" },
+ { MEDIA_BUS_FMT_UYYVYY8_0_5X24, "UYYVYY8_0_5X24" },
+ { MEDIA_BUS_FMT_YUV10_1X30, "YUV10_1X30" },
+ { MEDIA_BUS_FMT_UYYVYY10_0_5X30, "UYYVYY10_0_5X30" },
+ { MEDIA_BUS_FMT_RGB888_3X8, "RGB888_3X8" },
+ { MEDIA_BUS_FMT_RGB888_1X24, "RGB888_1X24" },
+ { MEDIA_BUS_FMT_RGB888_1X7X4_SPWG, "RGB888_1X7X4_SPWG" },
+ { MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA, "RGB888_1X7X4_JEIDA" },
+ { MEDIA_BUS_FMT_UYVY8_2X8, "UYVY8_2X8" },
+ { MEDIA_BUS_FMT_YUYV8_1X16, "YUYV8_1X16" },
+ { MEDIA_BUS_FMT_UYVY8_1X16, "UYVY8_1X16" },
+ { MEDIA_BUS_FMT_RGB101010_1X30, "RGB101010_1X30" },
+ { MEDIA_BUS_FMT_YUYV10_1X20, "YUYV10_1X20" },
+};
+static DRM_ENUM_NAME_FN(drm_get_bus_format_name, drm_bus_format_enum_list)
+
static const struct regmap_config vop2_regmap_config;
static struct vop2_video_port *to_vop2_video_port(struct drm_crtc *crtc)
@@ -2487,6 +2527,363 @@ static const struct drm_crtc_helper_funcs
vop2_crtc_helper_funcs = {
.atomic_disable = vop2_crtc_atomic_disable,
};
+static void vop2_dump_connector_on_crtc(struct drm_crtc *crtc, struct seq_file *s)
+{
+ struct drm_connector_list_iter conn_iter;
+ struct drm_connector *connector;
+
+ drm_connector_list_iter_begin(crtc->dev, &conn_iter);
+ drm_for_each_connector_iter(connector, &conn_iter) {
+ if (crtc->state->connector_mask & drm_connector_mask(connector))
+ seq_printf(s, "Connector: %s\n", connector->name);
+
+ }
+ drm_connector_list_iter_end(&conn_iter);
+}
+
+static int vop2_plane_state_dump(struct seq_file *s, struct drm_plane *plane)
+{
+ struct vop2_win *win = to_vop2_win(plane);
+ struct drm_plane_state *pstate = plane->state;
+ struct drm_rect *src, *dst;
+ struct drm_framebuffer *fb;
+ struct drm_gem_object *obj;
+ struct rockchip_gem_object *rk_obj;
+ bool xmirror;
+ bool ymirror;
+ bool rotate_270;
+ bool rotate_90;
+ dma_addr_t fb_addr;
+ int i;
+
+ seq_printf(s, "%s: %s\n", win->data->name, pstate->crtc ? "ACTIVE" :
"DISABLED");
+ if (!pstate || !pstate->fb)
+ return 0;
+
+ fb = pstate->fb;
+ src = &pstate->src;
+ dst = &pstate->dst;
+ xmirror = pstate->rotation & DRM_MODE_REFLECT_X ? true : false;
+ ymirror = pstate->rotation & DRM_MODE_REFLECT_Y ? true : false;
+ rotate_270 = pstate->rotation & DRM_MODE_ROTATE_270;
+ rotate_90 = pstate->rotation & DRM_MODE_ROTATE_90;
+
+ seq_printf(s, "\twin_id: %d\n", win->win_id);
+
+ seq_printf(s, "\tformat: %p4cc%s glb_alpha[0x%x]\n",
+ &fb->format->format,
+ drm_is_afbc(fb->modifier) ? "[AFBC]" : "",
+ pstate->alpha >> 8);
+ seq_printf(s, "\trotate: xmirror: %d ymirror: %d rotate_90: %d rotate_270:
%d\n",
+ xmirror, ymirror, rotate_90, rotate_270);
+ seq_printf(s, "\tzpos: %d\n", pstate->normalized_zpos);
+ seq_printf(s, "\tsrc: pos[%d, %d] rect[%d
Re: [PATCH -next] drm/imagination: Remove unneeded semicolon
Hi, Thank you for the patch. On Mon, 2023-11-27 at 09:04 +0800, Yang Li wrote: > ./drivers/gpu/drm/imagination/pvr_free_list.c:258:2-3: Unneeded semicolon > > Reported-by: Abaci Robot > Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7635 > Signed-off-by: Yang Li Reviewed-by: Frank Binns > --- > drivers/gpu/drm/imagination/pvr_free_list.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/imagination/pvr_free_list.c > b/drivers/gpu/drm/imagination/pvr_free_list.c > index c61fd417edcb..5e51bc980751 100644 > --- a/drivers/gpu/drm/imagination/pvr_free_list.c > +++ b/drivers/gpu/drm/imagination/pvr_free_list.c > @@ -255,7 +255,7 @@ pvr_free_list_insert_pages_locked(struct pvr_free_list > *free_list, > > if (!num_pages) > break; > - }; > + } > /* clang-format on */ > > /* Make sure our free_list update is flushed. */
Re: [PATCH][next] drm/imagination: Fix a couple of spelling mistakes in literal strings
Hi Colin,
Thank you for the patch.
On Fri, 2023-11-24 at 16:39 +, Colin Ian King wrote:
> There are a couple of spelling mistakes in literal strings in the
> stid_fmts array. Fix these.
>
> Signed-off-by: Colin Ian King
Reviewed-by: Frank Binns
> ---
> drivers/gpu/drm/imagination/pvr_rogue_fwif_sf.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/imagination/pvr_rogue_fwif_sf.h
> b/drivers/gpu/drm/imagination/pvr_rogue_fwif_sf.h
> index 571954182f33..56e11009e123 100644
> --- a/drivers/gpu/drm/imagination/pvr_rogue_fwif_sf.h
> +++ b/drivers/gpu/drm/imagination/pvr_rogue_fwif_sf.h
> @@ -497,7 +497,7 @@ static const struct rogue_km_stid_fmt stid_fmts[] = {
> { ROGUE_FW_LOG_CREATESFID(213, ROGUE_FW_GROUP_MAIN, 1),
> "Safety Watchdog threshold period set to 0x%x clock cycles" },
> { ROGUE_FW_LOG_CREATESFID(214, ROGUE_FW_GROUP_MAIN, 0),
> - "MTS Safety Event trigged by the safety watchdog." },
> + "MTS Safety Event triggered by the safety watchdog." },
> { ROGUE_FW_LOG_CREATESFID(215, ROGUE_FW_GROUP_MAIN, 3),
> "DM%d USC tasks range limit 0 - %d, stride %d" },
> { ROGUE_FW_LOG_CREATESFID(216, ROGUE_FW_GROUP_MAIN, 1),
> @@ -1114,7 +1114,7 @@ static const struct rogue_km_stid_fmt stid_fmts[] = {
> { ROGUE_FW_LOG_CREATESFID(39, ROGUE_FW_GROUP_SPM, 2),
> "3DMemFree matches freelist 0x%08x (FL type = %u)" },
> { ROGUE_FW_LOG_CREATESFID(40, ROGUE_FW_GROUP_SPM, 0),
> - "Raise the 3DMemFreeDedected flag" },
> + "Raise the 3DMemFreeDetected flag" },
> { ROGUE_FW_LOG_CREATESFID(41, ROGUE_FW_GROUP_SPM, 1),
> "Wait for pending grow on Freelist 0x%08x" },
> { ROGUE_FW_LOG_CREATESFID(42, ROGUE_FW_GROUP_SPM, 1),
Re: Implement per-key keyboard backlight as auxdisplay?
Hi Hans, Am 22.11.23 um 19:34 schrieb Hans de Goede: Hi Werner, [snip] Another idea I want to throw in the mix: Maybe the kernel is not the right place to implement this at all. RGB stuff is not at all standardized and every vendor is doing completely different interfaces, which does not fit the kernel userpsace apis desire to be uniformal and fixed. e.g. Auxdisplay might fit static setting of RGB values, but it does not fit the snake-effect mode, or the raindrops mode, or the 4-different-colors-in-the-edges-breathing-and-color-cycling mode. So my current idea: Implement these keyboards as a single zone RGB kbd_backlight in the leds interface to have something functional out of the box, but make it runtime disable-able if something like https://gitlab.com/CalcProgrammer1/OpenRGB wants to take over more fine granular control from userspace via hidraw. That sounds like a good approach to me. We are seeing the same with game controllers where steam and wine/proton also sometimes use hidraw mode to get access to all the crazy^W interesting features. That would mean that all we need to standardize and the kernel <-> userspace API level is adding a standard way to disable the single zone RGB kbd_backlight support in the kernel. I would suggest a simple "enable" entry. Default is 1. When set to 0 the kernel driver no longer does anything. I'm not in favor of using "enable" as sysfs attribute for this, I would like to see a more descriptive name, how about: "disable_kernel_kbd_backlight_support" And then maybe also have the driver actually unregister the LED class device ? Or just make the support inactive when writing 1 to this and allow re-enabling it by writing 0? Unregistering would mean that it can't be reenabled without module reload/reboot? I would prefer that the userspace driver could easily give back control to the leds interface. Questions: - Should the driver try to reset the settings to boot default? Or just leave the device in the current state? With the former I could see issues that they keyboard is flashing when changing from kernelspace control to userspace control. With the later the burden on bringing the device to a know state lies with the userspace driver. My vote would go to leave the state as is. Even if the hw does not support state readback, then the userspace code can readback the state before writing 1 to "disable_kernel_kbd_backlight_support" ack - Should this be a optional entry that only shows up on drivers supporting it, or could this implemented in a generic way affecting all current led entries? IMHO this should be optional. If we go with the variant where writing 1 to "disable_kernel_kbd_backlight_support" just disables support and 0 re-enables it then I guess we could have support for this in the LED-core, enabled by a flag set by the driver. If we go with unregistering the led class device, then this needs to be mostly handled in the driver. Either way the kernel driver should know about this even if it is mostly handled in the LED core so that e.g. it does not try to restore settings on resume from suspend. So a generic implementation would still require all current led drivers to be touched? For the sake of simplicity I would then prefer the optional variant. - I guess UPower integration for the userspace driver could be archived with https://www.kernel.org/doc/html/latest/leds/uleds.html however this limited to brightness atm, so when accent colors actually come to UPower this would also need some expansion to be able to pass a preferred color to the userspace driver (regardless of what that driver is then doing with that information). Using uleds is an interesting suggestion, but upower atm does not support LED class kbd_backlight devices getting hot-plugged. It only scans for them once at boot. Jelle van der Waa (a colleague of mine, added to the Cc) has indicated he is interested in maybe working on fixing this upower short-coming as a side project, once his current side-projects are finished. Nice to hear. On a different note: This approach does currently not cover the older EC controlled 3 zone keyboards from clevo. Here only the kernel has access access to the device so the kernel driver has to expose all functionality somehow. Should this be done by an arbitrarily designed platform device? Interesting question, this reminds there was a discussion about how to handle zoned keyboards using plain LED class APIs here: https://lore.kernel.org/linux-leds/544484b9-c0ac-2fd0-1f41-8fa94cb94...@redhat.com/ Basically the idea discussed there is to create separate multi-color LED sysfs devices for each zone, using :rgb:kbd_zoned_backlight-xxx as postfix, e.g. : :rgb:kbd_zoned_backlight-left :rgb:kbd_zoned_backlight-middle :rgb:kbd_zoned_backlight-right :rgb:kbd_zoned_backlight-wasd As postfixes for the 4 per zone LED class devices and then teach upower to just treat this as a single kbd-backli
Re: [PATCH v2 10/12] drm/rockchip: vop2: Add support for rk3588
Hi Andy,
Looks good overall, two small things inside.
On Wed, Nov 22, 2023 at 08:55:44PM +0800, Andy Yan wrote:
>
> +#define vop2_output_if_is_hdmi(x)(x == ROCKCHIP_VOP2_EP_HDMI0 || x ==
> ROCKCHIP_VOP2_EP_HDMI1)
> +#define vop2_output_if_is_dp(x) (x == ROCKCHIP_VOP2_EP_DP0 || x
> == ROCKCHIP_VOP2_EP_DP1)
> +#define vop2_output_if_is_edp(x) (x == ROCKCHIP_VOP2_EP_EDP0 || x ==
> ROCKCHIP_VOP2_EP_EDP1)
> +#define vop2_output_if_is_mipi(x)(x == ROCKCHIP_VOP2_EP_MIPI0 || x ==
> ROCKCHIP_VOP2_EP_MIPI1)
> +#define vop2_output_if_is_lvds(x)(x == ROCKCHIP_VOP2_EP_LVDS0 || x ==
> ROCKCHIP_VOP2_EP_LVDS1)
> +#define vop2_output_if_is_dpi(x) (x == ROCKCHIP_VOP2_EP_RGB0)
Not that it matters in practice here, but you should add braces around
the x argument in the macros usage, i.e. ((x) == ROCKCHIP_VOP2_EP_RGB0)
> +static unsigned long rk3588_set_intf_mux(struct vop2_video_port *vp, int id,
> u32 polflags)
> +{
> + struct vop2 *vop2 = vp->vop2;
> + int dclk_core_div, dclk_out_div, if_pixclk_div, if_dclk_div;
> + unsigned long clock;
> + u32 die, dip, div, vp_clk_div, val;
> +
> + clock = rk3588_calc_cru_cfg(vp, id, &dclk_core_div, &dclk_out_div,
> + &if_pixclk_div, &if_dclk_div);
> + if (!clock)
> + return 0;
> +
> + vp_clk_div = FIELD_PREP(RK3588_VP_CLK_CTRL__DCLK_CORE_DIV,
> dclk_core_div);
> + vp_clk_div |= FIELD_PREP(RK3588_VP_CLK_CTRL__DCLK_OUT_DIV,
> dclk_out_div);
> +
> + die = vop2_readl(vop2, RK3568_DSP_IF_EN);
> + dip = vop2_readl(vop2, RK3568_DSP_IF_POL);
> + div = vop2_readl(vop2, RK3568_DSP_IF_CTRL);
> +
> + switch (id) {
> + case ROCKCHIP_VOP2_EP_HDMI0:
> + div |= FIELD_PREP(RK3588_DSP_IF_EDP_HDMI0_DCLK_DIV,
> if_dclk_div);
you should clear the bits of a mask before setting them again. The same
goes for several other bits modified in this switch/case.
> + div |= FIELD_PREP(RK3588_DSP_IF_EDP_HDMI0_PCLK_DIV,
> if_pixclk_div);
> + die &= ~RK3588_SYS_DSP_INFACE_EN_EDP_HDMI0_MUX;
> + die |= RK3588_SYS_DSP_INFACE_EN_HDMI0 |
> + FIELD_PREP(RK3588_SYS_DSP_INFACE_EN_EDP_HDMI0_MUX,
> vp->id);
> + val = rk3588_get_hdmi_pol(polflags);
> + regmap_write(vop2->vop_grf, RK3588_GRF_VOP_CON2,
> HIWORD_UPDATE(1, 1, 1));
> + regmap_write(vop2->vo1_grf, RK3588_GRF_VO1_CON0,
> HIWORD_UPDATE(val, 6, 5));
> + break;
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH drm-misc-next 0/5] PowerVR VM fixes
Hi, Thank you for the patches. On Sat, 2023-11-25 at 00:36 +0100, Danilo Krummrich wrote: > Hi, > > Some major GPUVM changes landed just before v8 of the PowerVR series. Since v8 > went in rather quickly (review process was finished otherwise) I haven't had > the > chance to review the subsequent code changes. > > Hence, this series with a few fixes in this context. Plus a minor GPUVM patch > to > make the drm_gpuvm_prepare_* helpers useful for PowerVR. > > - Danilo > > > Danilo Krummrich (5): > drm/imagination: vm: prevent duplicate drm_gpuvm_bo instances > drm/imagination: vm: check for drm_gpuvm_range_valid() > drm/imagination: vm: fix drm_gpuvm reference count > drm/gpuvm: fall back to drm_exec_lock_obj() > drm/imagination: vm: make use of GPUVM's drm_exec helper > > drivers/gpu/drm/drm_gpuvm.c | 36 -- > drivers/gpu/drm/imagination/pvr_vm.c | 46 +++- > drivers/gpu/drm/imagination/pvr_vm.h | 3 +- > include/drm/drm_gpuvm.h | 23 ++ > 4 files changed, 63 insertions(+), 45 deletions(-) > > > base-commit: 46990918f35c1bf6e367cf8e0423e7344fec9fcb For the series: Tested-by: Frank Binns I'll leave it to Donald to do the review. Thanks Frank
Re: [PATCH] drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()
On 24.11.2023 13:45, Marek Szyprowski wrote:
> On 22.11.2023 10:29, Krzysztof Kozlowski wrote:
>> On 22/11/2023 10:06, AngeloGioacchino Del Regno wrote:
>>>>>> Hey Krzysztof,
>>>>>>
>>>>>> This is interesting. It might be about the cores that are missing
>>>>>> from the partial
>>>>>> core_mask raising interrupts, but an external abort on
>>>>>> non-linefetch is strange to
>>>>>> see here.
>>>>> I've seen such external aborts in the past, and the fault type has
>>>>> often been misleading. It's unlikely to have anything to do with a
>>>> Yeah, often accessing device with power or clocks gated.
>>>>
>>> Except my commit does *not* gate SoC power, nor SoC clocks 🙂
>> It could be that something (like clocks or power supplies) was missing
>> on this board/SoC, which was not critical till your patch came.
>>
>>> What the "Really power off ..." commit does is to ask the GPU to
>>> internally power
>>> off the shaders, tilers and L2, that's why I say that it is strange
>>> to see that
>>> kind of abort.
>>>
>>> The GPU_INT_CLEAR GPU_INT_STAT, GPU_FAULT_STATUS and
>>> GPU_FAULT_ADDRESS_{HI/LO}
>>> registers should still be accessible even with shaders, tilers and
>>> cache OFF.
>>>
>>> Anyway, yes, synchronizing IRQs before calling the poweroff sequence
>>> would also
>>> work, but that'd add up quite a bit of latency on the
>>> runtime_suspend() call, so
>>> in this case I'd be more for avoiding to execute any register r/w in
>>> the handler
>>> by either checking if the GPU is supposed to be OFF, or clearing
>>> interrupts, which
>>> may not work if those are generated after the execution of the
>>> poweroff function.
>>> Or we could simply disable the irq after power_off, but that'd be
>>> hacky (as well).
>>>
>>>
>>> Let's see if asking to poweroff *everything* works:
>> Worked.
>
> Yes, I also got into this issue some time ago, but I didn't report it
> because I also had some power supply related problems on my test farm
> and everything was a bit unstable. I wasn't 100% sure that the
> $subject patch is responsible for the observed issues. Now, after
> fixing power supply, I confirm that the issue was revealed by the
> $subject patch and above mentioned change fixes the problem. Feel free
> to add:
>
> Tested-by: Marek Szyprowski
I must revoke my tested-by tag for the above fix alone. Although it
fixed the boot issue and system stability issue, it looks that there is
still something missing and opening the panfrost dri device causes a
system crash:
root@target:~# ./modetest -C
trying to open device 'i915'...failed
trying to open device 'amdgpu'...failed
trying to open device 'radeon'...failed
trying to open device 'nouveau'...failed
trying to open device 'vmwgfx'...failed
trying to open device 'omapdrm'...failed
trying to open device 'exynos'...done
root@target:~#
8<--- cut here ---
Unhandled fault: external abort on non-linefetch (0x1008) at 0xf0c6803c
[f0c6803c] *pgd=42d87811, *pte=11800653, *ppte=11800453
Internal error: : 1008 [#1] PREEMPT SMP ARM
Modules linked in: exynos_gsc s5p_mfc s5p_jpeg v4l2_mem2mem
videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common
videodev mc s5p_cec
CPU: 0 PID: 0 Comm: swapper/0 Not tainted
6.7.0-rc2-next-20231127-00055-ge14abcb527d6 #7649
Hardware name: Samsung Exynos (Flattened Device Tree)
PC is at panfrost_gpu_irq_handler+0x18/0xfc
LR is at __handle_irq_event_percpu+0xcc/0x31c
...
Process swapper/0 (pid: 0, stack limit = 0x0e2875ff)
Stack: (0xc1301e48 to 0xc1302000)
...
panfrost_gpu_irq_handler from __handle_irq_event_percpu+0xcc/0x31c
__handle_irq_event_percpu from handle_irq_event+0x38/0x80
handle_irq_event from handle_fasteoi_irq+0x9c/0x250
handle_fasteoi_irq from generic_handle_domain_irq+0x24/0x34
generic_handle_domain_irq from gic_handle_irq+0x88/0xa8
gic_handle_irq from generic_handle_arch_irq+0x34/0x44
generic_handle_arch_irq from __irq_svc+0x8c/0xd0
Exception stack(0xc1301f10 to 0xc1301f58)
...
__irq_svc from default_idle_call+0x20/0x2c4
default_idle_call from do_idle+0x244/0x2b4
do_idle from cpu_startup_entry+0x28/0x2c
cpu_startup_entry from rest_init+0xec/0x190
rest_init from arch_post_acpi_subsys_init+0x0/0x8
Code: e591300c e593402c f57ff04f e591300c (e593903c)
---[ end trace ]---
Kernel panic - not syncing: Fatal exception in interrupt
CPU2: stopping
It looks that the panfrost interrupts must be somehow synchronized with
turning power off, what has been already discussed. Let me know if you
want me to test any patch.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Re: [PATCH v1 3/4] drm/rockchip: rk3066_hdmi: Remove useless output format
Hi Johan,
Am Donnerstag, 23. November 2023, 13:54:28 CET schrieb Johan Jonker:
>
> On 11/20/23 18:06, Heiko Stuebner wrote:
> > Hi Johan,
> >
> > Am Donnerstag, 2. November 2023, 14:42:19 CET schrieb Johan Jonker:
> >> The Rk3066 hdmi output format is hard coded to RGB. Remove
> >> all useless code related to colorimetry and enc_out_format.
> >>
> >> Signed-off-by: Johan Jonker
> >
>
> > I guess my first question is, is the hardcoding happening just because
> > of missing functionality in the driver, or does the hardware only
> > support RGB?
>
> This driver can do so much more..., but is crippled by various causes.
> If in need for a full functional rk3066 driver a little bit
> help/advise/action from other people is needed.
Part of me wants to have fully working drivers, but on the other hand,
both the rk3066-hdmi and also the inno-hdmi drivers are sort of one-off
drivers used by rk3066 and rk3036 (inno-hdmi) and most likely won't see
new SoCs using them in the future.
So I guess after thinking more about this, I should probably just apply
your patch to simplify the code and if by some magical happenings in
future someone really wants to spend time on either one of these drivers
they can always use "git revert" to bring back the old code?
Heiko
> 1:
> Missing rk3066 TRM HDMI register info.
> Could Rockchip (= Sandy Huang) disclose this info to the open source
> community?
>
> As a way around we can look at older driver code and port to mainline.
> More info gives better results.
> rk30_hdmi_config_csc() function:
> https://github.com/RockchipOpensourceCommunity/px2-android-kernel-3.0/blob/master/drivers/video/rockchip/hdmi/chips/rkpx2/rkpx2_hdmi_hw.c#L315
>
> 2:
> Could DRM people show us examples for:
> - How to advertise to the VOP driver what data formats (RGB, YCBCR) it can
> send to the HDMI driver or any other Rockchip DRM sub driver other then RGB.
> - Advertise EDID data monitor modes RGB444, YCBCR444 and YCBCR422 to the HDMI
> driver.
>
> https://github.com/RockchipOpensourceCommunity/px2-android-kernel-3.0/blob/master/drivers/video/rockchip/hdmi/rk_hdmi_edid.c#L217C1-L218C41
>
> 3:
> Advise when what Infoframe is needed for only RGB vs. the rest according to
> the specification.
> https://engineering.purdue.edu/ece477/Archive/2012/Spring/S12-Grp10/Datasheets/CEC_HDMI_Specification.pdf
>
> rk3066 currently only sends avi info. Does it need vsi as well? Can anyone
> give some clarity here?
> inno_hdime sends avi and vsi info.
>
> 4:
> rk3066_hdmi and inno_hdmi are HDMI 1.4a drivers for DVI and HDMI.
> Validated by drm_match_cea_mode() this function only gives us both HDMI +
> HDMI2 focus, but nothing for old DVI monitors.
> How to improve?
>
> 5:
> Sound support was submitted:
> Re: [PATCH v6 2/5] drm: rockchip: add sound support to rk3066 hdmi driver
> https://lore.kernel.org/linux-rockchip/48dbe9b7-0aa0-f459-301f-f380e2b7f...@gmail.com/
>
> No reply was given (by Heiko or others) on why it wasn't applied or what
> needs to be improved.
>
> Without reply no improvement.
>
> Johan
>
>
> >
> >
> >> ---
> >> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 20 +---
> >> 1 file changed, 1 insertion(+), 19 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> >> b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> >> index 0e7aae341960..f2b1b2faa096 100644
> >> --- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> >> +++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> >> @@ -23,8 +23,6 @@
> >>
> >> struct hdmi_data_info {
> >>int vic; /* The CEA Video ID (VIC) of the current drm display mode. */
> >> - unsigned int enc_out_format;
> >> - unsigned int colorimetry;
> >> };
> >>
> >> struct rk3066_hdmi_i2c {
> >> @@ -200,14 +198,7 @@ static int rk3066_hdmi_config_avi(struct rk3066_hdmi
> >> *hdmi,
> >>rc = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
> >> &hdmi->connector, mode);
> >>
> >> - if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444)
> >> - frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
> >> - else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV422)
> >> - frame.avi.colorspace = HDMI_COLORSPACE_YUV422;
> >> - else
> >> - frame.avi.colorspace = HDMI_COLORSPACE_RGB;
> >> -
> >> - frame.avi.colorimetry = hdmi->hdmi_data.colorimetry;
> >> + frame.avi.colorspace = HDMI_COLORSPACE_RGB;
> >>frame.avi.scan_mode = HDMI_SCAN_MODE_NONE;
> >>
> >>return rk3066_hdmi_upload_frame(hdmi, rc, &frame,
> >> @@ -329,15 +320,6 @@ static int rk3066_hdmi_setup(struct rk3066_hdmi *hdmi,
> >>struct drm_display_info *display = &hdmi->connector.display_info;
> >>
> >>hdmi->hdmi_data.vic = drm_match_cea_mode(mode);
> >> - hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
> >> -
> >> - if (hdmi->hdmi_data.vic == 6 || hdmi->hdmi_data.vic == 7 ||
> >> - hdmi->hdmi_data.vic == 21 || hdmi->hdmi_data.vic == 22 ||
> >> - hdmi->hdm
Re: [PATCH] drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()
Il 27/11/23 12:24, Marek Szyprowski ha scritto:
On 24.11.2023 13:45, Marek Szyprowski wrote:
On 22.11.2023 10:29, Krzysztof Kozlowski wrote:
On 22/11/2023 10:06, AngeloGioacchino Del Regno wrote:
Hey Krzysztof,
This is interesting. It might be about the cores that are missing
from the partial
core_mask raising interrupts, but an external abort on
non-linefetch is strange to
see here.
I've seen such external aborts in the past, and the fault type has
often been misleading. It's unlikely to have anything to do with a
Yeah, often accessing device with power or clocks gated.
Except my commit does *not* gate SoC power, nor SoC clocks 🙂
It could be that something (like clocks or power supplies) was missing
on this board/SoC, which was not critical till your patch came.
What the "Really power off ..." commit does is to ask the GPU to
internally power
off the shaders, tilers and L2, that's why I say that it is strange
to see that
kind of abort.
The GPU_INT_CLEAR GPU_INT_STAT, GPU_FAULT_STATUS and
GPU_FAULT_ADDRESS_{HI/LO}
registers should still be accessible even with shaders, tilers and
cache OFF.
Anyway, yes, synchronizing IRQs before calling the poweroff sequence
would also
work, but that'd add up quite a bit of latency on the
runtime_suspend() call, so
in this case I'd be more for avoiding to execute any register r/w in
the handler
by either checking if the GPU is supposed to be OFF, or clearing
interrupts, which
may not work if those are generated after the execution of the
poweroff function.
Or we could simply disable the irq after power_off, but that'd be
hacky (as well).
Let's see if asking to poweroff *everything* works:
Worked.
Yes, I also got into this issue some time ago, but I didn't report it
because I also had some power supply related problems on my test farm
and everything was a bit unstable. I wasn't 100% sure that the
$subject patch is responsible for the observed issues. Now, after
fixing power supply, I confirm that the issue was revealed by the
$subject patch and above mentioned change fixes the problem. Feel free
to add:
Tested-by: Marek Szyprowski
I must revoke my tested-by tag for the above fix alone. Although it
fixed the boot issue and system stability issue, it looks that there is
still something missing and opening the panfrost dri device causes a
system crash:
root@target:~# ./modetest -C
trying to open device 'i915'...failed
trying to open device 'amdgpu'...failed
trying to open device 'radeon'...failed
trying to open device 'nouveau'...failed
trying to open device 'vmwgfx'...failed
trying to open device 'omapdrm'...failed
trying to open device 'exynos'...done
root@target:~#
8<--- cut here ---
Unhandled fault: external abort on non-linefetch (0x1008) at 0xf0c6803c
[f0c6803c] *pgd=42d87811, *pte=11800653, *ppte=11800453
Internal error: : 1008 [#1] PREEMPT SMP ARM
Modules linked in: exynos_gsc s5p_mfc s5p_jpeg v4l2_mem2mem
videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common
videodev mc s5p_cec
CPU: 0 PID: 0 Comm: swapper/0 Not tainted
6.7.0-rc2-next-20231127-00055-ge14abcb527d6 #7649
Hardware name: Samsung Exynos (Flattened Device Tree)
PC is at panfrost_gpu_irq_handler+0x18/0xfc
LR is at __handle_irq_event_percpu+0xcc/0x31c
...
Process swapper/0 (pid: 0, stack limit = 0x0e2875ff)
Stack: (0xc1301e48 to 0xc1302000)
...
panfrost_gpu_irq_handler from __handle_irq_event_percpu+0xcc/0x31c
__handle_irq_event_percpu from handle_irq_event+0x38/0x80
handle_irq_event from handle_fasteoi_irq+0x9c/0x250
handle_fasteoi_irq from generic_handle_domain_irq+0x24/0x34
generic_handle_domain_irq from gic_handle_irq+0x88/0xa8
gic_handle_irq from generic_handle_arch_irq+0x34/0x44
generic_handle_arch_irq from __irq_svc+0x8c/0xd0
Exception stack(0xc1301f10 to 0xc1301f58)
...
__irq_svc from default_idle_call+0x20/0x2c4
default_idle_call from do_idle+0x244/0x2b4
do_idle from cpu_startup_entry+0x28/0x2c
cpu_startup_entry from rest_init+0xec/0x190
rest_init from arch_post_acpi_subsys_init+0x0/0x8
Code: e591300c e593402c f57ff04f e591300c (e593903c)
---[ end trace ]---
Kernel panic - not syncing: Fatal exception in interrupt
CPU2: stopping
It looks that the panfrost interrupts must be somehow synchronized with
turning power off, what has been already discussed. Let me know if you
want me to test any patch.
The new series containing the whole interrupts sync code is almost ready,
currently testing it on my machines here.
I should be able to send it between today and tomorrow.
Cheers,
Angelo
Re: [PATCH 1/2] drm/panfrost: Consider dma-buf imported objects as resident
On 25/11/2023 20:52, Adrián Larumbe wrote:
> A GEM object constructed from a dma-buf imported sgtable should be regarded
> as being memory resident, because the dma-buf API mandates backing storage
> to be allocated when attachment succeeds.
This obviously can cause a bit of double-counting system wide (both the
exporter and importer could show the memory usage). But I think we're
better off over-counting rather than under-counting.
Reviewed-by: Steven Price
> Signed-off-by: Adrián Larumbe
> Fixes: 9ccdac7aa822 ("drm/panfrost: Add fdinfo support for memory stats")
> Reported-by: Boris Brezillon
> ---
> drivers/gpu/drm/panfrost/panfrost_gem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
> b/drivers/gpu/drm/panfrost/panfrost_gem.c
> index 0cf64456e29a..d47b40b82b0b 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
> @@ -200,7 +200,7 @@ static enum drm_gem_object_status
> panfrost_gem_status(struct drm_gem_object *obj
> struct panfrost_gem_object *bo = to_panfrost_bo(obj);
> enum drm_gem_object_status res = 0;
>
> - if (bo->base.pages)
> + if (bo->base.base.import_attach || bo->base.pages)
> res |= DRM_GEM_OBJECT_RESIDENT;
>
> if (bo->base.madv == PANFROST_MADV_DONTNEED)
Re: [PATCH 2/2] drm/panfrost: Fix incorrect updating of current device frequency
On 25/11/2023 20:52, Adrián Larumbe wrote:
> It was noticed when setting the Panfrost's DVFS device to the performant
> governor, GPU frequency as reported by fdinfo had dropped to 0 permamently.
>
> There are two separate issues causing this behaviour:
> - Not initialising the device's current_frequency variable to its original
> value during device probe().
> - Updating said variable in Panfrost devfreq's get_dev_status() rather
> than after the new OPP's frequency had been retrieved in target(), which
> meant the old frequency would be assigned instead.
Good catch - I'd not looked at the performance governor. I'd assumed
that one was "too simple to be wrong" ;)
Reviewed-by: Steven Price
>
> Signed-off-by: Adrián Larumbe
> Fixes: f11b0417eec2 ("drm/panfrost: Add fdinfo support GPU load metrics")
> ---
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> index f59c82ea8870..2d30da38c2c3 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> @@ -29,14 +29,20 @@ static void panfrost_devfreq_update_utilization(struct
> panfrost_devfreq *pfdevfr
> static int panfrost_devfreq_target(struct device *dev, unsigned long *freq,
> u32 flags)
> {
> + struct panfrost_device *ptdev = dev_get_drvdata(dev);
> struct dev_pm_opp *opp;
> + int err;
>
> opp = devfreq_recommended_opp(dev, freq, flags);
> if (IS_ERR(opp))
> return PTR_ERR(opp);
> dev_pm_opp_put(opp);
>
> - return dev_pm_opp_set_rate(dev, *freq);
> + err = dev_pm_opp_set_rate(dev, *freq);
> + if (!err)
> + ptdev->pfdevfreq.current_frequency = *freq;
> +
> + return err;
> }
>
> static void panfrost_devfreq_reset(struct panfrost_devfreq *pfdevfreq)
> @@ -58,7 +64,6 @@ static int panfrost_devfreq_get_dev_status(struct device
> *dev,
> spin_lock_irqsave(&pfdevfreq->lock, irqflags);
>
> panfrost_devfreq_update_utilization(pfdevfreq);
> - pfdevfreq->current_frequency = status->current_frequency;
>
> status->total_time = ktime_to_ns(ktime_add(pfdevfreq->busy_time,
> pfdevfreq->idle_time));
> @@ -164,6 +169,14 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
>
> panfrost_devfreq_profile.initial_freq = cur_freq;
>
> + /*
> + * We could wait until panfrost_devfreq_target() to set this value, but
> + * since the simple_ondemand governor works asynchronously, there's a
> + * chance by the time someone opens the device's fdinfo file, current
> + * frequency hasn't been updated yet, so let's just do an early set.
> + */
> + pfdevfreq->current_frequency = cur_freq;
> +
> /*
>* Set the recommend OPP this will enable and configure the regulator
>* if any and will avoid a switch off by regulator_late_cleanup()
[PATCH v1 1/2] dt-bindings: display: bridge: cdns: Add properties to support StarFive JH7110 SoC
From: Keith Zhao Add properties in CDNS DSI yaml file to match with CDNS DSI module in StarFive JH7110 SoC. Signed-off-by: Keith Zhao --- .../bindings/display/bridge/cdns,dsi.yaml | 38 ++- 1 file changed, 36 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml index 23060324d16e..3f02ee383aad 100644 --- a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml @@ -17,6 +17,7 @@ properties: enum: - cdns,dsi - ti,j721e-dsi + - starfive,cdns-dsi reg: minItems: 1 @@ -27,14 +28,20 @@ properties: Register block for wrapper settings registers in case of TI J7 SoCs. clocks: +minItems: 2 items: - description: PSM clock, used by the IP - description: sys clock, used by the IP + - description: apb clock, used by the IP + - description: txesc clock, used by the IP clock-names: +minItems: 2 items: - const: dsi_p_clk - const: dsi_sys_clk + - const: apb + - const: txesc phys: maxItems: 1 @@ -46,10 +53,21 @@ properties: maxItems: 1 resets: -maxItems: 1 +minItems: 1 +items: + - description: dsi sys reset line + - description: dsi dpi reset line + - description: dsi apb reset line + - description: dsi txesc reset line + - description: dsi txbytehs reset line reset-names: -const: dsi_p_rst +items: + - const: dsi_p_rst + - const: dsi_dpi + - const: dsi_apb + - const: dsi_txesc + - const: dsi_txbytehs ports: $ref: /schemas/graph.yaml#/properties/ports @@ -90,6 +108,22 @@ allOf: reg: maxItems: 1 + - if: + properties: +compatible: + contains: +const: starfive,cdns-dsi +then: + properties: +clocks: + minItems: 4 + maxItems: 4 +resets: + minItems: 5 + maxItems: 5 + required: +- reset-names + required: - compatible - reg -- 2.17.1
[PATCH v1 0/2] Add StarFive JH7110 SoC DSI support
This series is the v1 series that attempts to support the CDNS DSI driver used to converts DPI to DSI. CDNS DSI is embedded in StarFive JH7110 SoC. The series has been tested on the VisionFive 2 board. Keith Zhao (2): dt-bindings: display: bridge: cdns: Add properties to support StarFive JH7110 SoC gpu: drm: bridge: cadence: Add a driver and platform ops for StarFive JH7110 SoC .../bindings/display/bridge/cdns,dsi.yaml | 38 +- MAINTAINERS | 8 + drivers/gpu/drm/bridge/cadence/Kconfig| 7 + drivers/gpu/drm/bridge/cadence/Makefile | 1 + .../gpu/drm/bridge/cadence/cdns-dsi-core.c| 28 +- .../gpu/drm/bridge/cadence/cdns-dsi-core.h| 19 + .../gpu/drm/bridge/cadence/cdns-dsi-jh7110.c | 386 ++ .../gpu/drm/bridge/cadence/cdns-dsi-jh7110.h | 186 + 8 files changed, 670 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-jh7110.c create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-jh7110.h -- 2.17.1
[PATCH v1 2/2] gpu: drm: bridge: cadence: Add a driver and platform ops for StarFive JH7110 SoC
From: Keith Zhao
In order to fit CDNS DSI module in StarFive JH7110 SoC,
The mainly modification is followed:
1.Add driver for StarFive JH7110 SoC to drive its CDNS DSI module.
2.Add platform ops in cdns-dsi.c for StarFive JH7110 SoC probing.
Signed-off-by: Keith Zhao
---
MAINTAINERS | 8 +
drivers/gpu/drm/bridge/cadence/Kconfig| 7 +
drivers/gpu/drm/bridge/cadence/Makefile | 1 +
.../gpu/drm/bridge/cadence/cdns-dsi-core.c| 28 +-
.../gpu/drm/bridge/cadence/cdns-dsi-core.h| 19 +
.../gpu/drm/bridge/cadence/cdns-dsi-jh7110.c | 386 ++
.../gpu/drm/bridge/cadence/cdns-dsi-jh7110.h | 186 +
7 files changed, 634 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-jh7110.c
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-jh7110.h
diff --git a/MAINTAINERS b/MAINTAINERS
index ea790149af79..e3c8e81c7656 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6868,6 +6868,14 @@ F:
Documentation/devicetree/bindings/display/solomon,ssd-common.yaml
F: Documentation/devicetree/bindings/display/solomon,ssd13*.yaml
F: drivers/gpu/drm/solomon/ssd130x*
+DRM DRIVERS FOR STARFIVE
+M: Keith Zhao
+M: Shengyang Chen
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/bridge/cadence/cdns-dsi-jh7110*
+
DRM DRIVER FOR ST-ERICSSON MCDE
M: Linus Walleij
S: Maintained
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
index cced81633ddc..ad9f572f4720 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -19,6 +19,13 @@ config DRM_CDNS_DSI_J721E
help
Support J721E Cadence DSI wrapper. The wrapper manages
the routing of the DSS DPI signal to the Cadence DSI.
+
+config DRM_CDNS_DSI_JH7110
+ bool "JH7110 SOC Cadence DSI support"
+ default n
+ help
+ Cadence DPI to DSI bridge which is embedded in the
+ StarFive JH7110 SoC.
endif
config DRM_CDNS_MHDP8546
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
b/drivers/gpu/drm/bridge/cadence/Makefile
index c95fd5b81d13..87f603a9f4ad 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
cdns-dsi-y := cdns-dsi-core.o
cdns-dsi-$(CONFIG_DRM_CDNS_DSI_J721E) += cdns-dsi-j721e.o
+cdns-dsi-$(CONFIG_DRM_CDNS_DSI_JH7110) += cdns-dsi-jh7110.o
obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
index 7457d38622b0..114385890dd1 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
@@ -27,6 +27,10 @@
#include "cdns-dsi-j721e.h"
#endif
+#ifdef CONFIG_DRM_CDNS_DSI_JH7110
+#include "cdns-dsi-jh7110.h"
+#endif
+
#define IP_CONF0x0
#define SP_HS_FIFO_DEPTH(x)(((x) & GENMASK(30, 26)) >> 26)
#define SP_LP_FIFO_DEPTH(x)(((x) & GENMASK(25, 21)) >> 21)
@@ -586,6 +590,9 @@ static int cdns_dsi_check_conf(struct cdns_dsi *dsi,
if (ret)
return ret;
+ if (dsi->platform_ops && dsi->platform_ops->update)
+ dsi->platform_ops->update(dsi, dsi_cfg, mode);
+
dsi_hss_hsa_hse_hbp = dsi_cfg->hbp + DSI_HBP_FRAME_OVERHEAD;
if (output->dev->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
dsi_hss_hsa_hse_hbp += dsi_cfg->hsa + DSI_HSA_FRAME_OVERHEAD;
@@ -683,7 +690,7 @@ static void cdns_dsi_bridge_post_disable(struct drm_bridge
*bridge)
pm_runtime_put(dsi->base.dev);
}
-static void cdns_dsi_hs_init(struct cdns_dsi *dsi)
+void cdns_dsi_hs_init(struct cdns_dsi *dsi)
{
struct cdns_dsi_output *output = &dsi->output;
u32 status;
@@ -1026,6 +1033,14 @@ static ssize_t cdns_dsi_transfer(struct mipi_dsi_host
*host,
cdns_dsi_init_link(dsi);
+ /*
+* on Jh7110 soc , when transfer dsi command ,
+* cdns_dsi_hs_init is needed.
+* or the final ret will be error value.
+*/
+ if (dsi->platform_ops && dsi->platform_ops->transfer)
+ dsi->platform_ops->transfer(dsi);
+
ret = mipi_dsi_create_packet(&packet, msg);
if (ret)
goto out;
@@ -1142,6 +1157,9 @@ static int __maybe_unused cdns_dsi_resume(struct device
*dev)
clk_prepare_enable(dsi->dsi_p_clk);
clk_prepare_enable(dsi->dsi_sys_clk);
+ if (dsi->platform_ops && dsi->platform_ops->resume)
+ dsi->platform_ops->resume(dsi);
+
return 0;
}
@@ -1152,6 +1170,10 @@ static int __maybe_un
Re: [PATCH v1 1/2] dt-bindings: display: bridge: cdns: Add properties to support StarFive JH7110 SoC
On 27/11/2023 12:34, Shengyang Chen wrote: > From: Keith Zhao > > Add properties in CDNS DSI yaml file to match with > CDNS DSI module in StarFive JH7110 SoC. > > Signed-off-by: Keith Zhao > --- > .../bindings/display/bridge/cdns,dsi.yaml | 38 ++- > 1 file changed, 36 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml > b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml > index 23060324d16e..3f02ee383aad 100644 > --- a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml > @@ -17,6 +17,7 @@ properties: > enum: >- cdns,dsi >- ti,j721e-dsi > + - starfive,cdns-dsi Keep alphabetical order. > >reg: > minItems: 1 > @@ -27,14 +28,20 @@ properties: >Register block for wrapper settings registers in case of TI J7 > SoCs. > >clocks: > +minItems: 2 > items: >- description: PSM clock, used by the IP >- description: sys clock, used by the IP > + - description: apb clock, used by the IP > + - description: txesc clock, used by the IP > >clock-names: > +minItems: 2 > items: >- const: dsi_p_clk >- const: dsi_sys_clk > + - const: apb > + - const: txesc > >phys: > maxItems: 1 > @@ -46,10 +53,21 @@ properties: > maxItems: 1 > >resets: > -maxItems: 1 > +minItems: 1 > +items: > + - description: dsi sys reset line > + - description: dsi dpi reset line > + - description: dsi apb reset line > + - description: dsi txesc reset line > + - description: dsi txbytehs reset line > >reset-names: > -const: dsi_p_rst > +items: > + - const: dsi_p_rst > + - const: dsi_dpi > + - const: dsi_apb > + - const: dsi_txesc > + - const: dsi_txbytehs > >ports: > $ref: /schemas/graph.yaml#/properties/ports > @@ -90,6 +108,22 @@ allOf: > reg: >maxItems: 1 > You need to restrict other variants, because you just relaxed several properties for everyone... Best regards, Krzysztof
Re: [PATCH v1 1/2] dt-bindings: display: bridge: cdns: Add properties to support StarFive JH7110 SoC
On 27/11/2023 12:34, Shengyang Chen wrote: > From: Keith Zhao > > Add properties in CDNS DSI yaml file to match with > CDNS DSI module in StarFive JH7110 SoC. > > Signed-off-by: Keith Zhao > --- > .../bindings/display/bridge/cdns,dsi.yaml | 38 ++- > 1 file changed, 36 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml > b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml > index 23060324d16e..3f02ee383aad 100644 > --- a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml > @@ -17,6 +17,7 @@ properties: > enum: >- cdns,dsi >- ti,j721e-dsi > + - starfive,cdns-dsi BTW, one more thing, I really doubt that starfive created "cdns" block. "cdns" is vendor prefix. Use SoCs-specific compatibles. Best regards, Krzysztof
Re: Bug in the error handling in TTMs pool implementation
On 24.11.2023 16:53, Christian König wrote:
@Karolina do you of hand know a way how we could exercise this in a TTM
unit test? Basically we would need to redirect the alloc_pages_node()
symbol to an unit test internal function and let it return an error (or
something like that).
Do I understand correctly that you want to mock NULL from
alloc_pages_node() in ttm_pool_alloc_page()? I had a quick look at it,
and found a(n ugly) way to do it.
KUnit provides an API to redirect calls using KUNIT_STATIC_STUB_REDIRECT
that can be registered in the original function and then overridden in
the test. You can read more about the mechanism in [1].
The problem is that we'd need to introduce a wrapper call for
alloc_pages_node() in TTM and expose it, so the function can be
substituted during the test. We can't directly modify alloc_pages_node()
due to cyclic dependencies caused by kunit/static_stub.h.
For example, in ttm_pool.c, we'd have:
+struct page *ttm_alloc_pages_node(int nid, gfp_t gfp_mask,
+ unsigned int order)
+{
+ KUNIT_STATIC_STUB_REDIRECT(ttm_alloc_pages_node, nid, gfp_mask,
order);
+ return alloc_pages_node(nid, gfp_mask, order);
+}
+EXPORT_SYMBOL(ttm_alloc_pages_node);
+
/* Allocate pages of size 1 << order with the given gfp_flags */
static struct page *ttm_pool_alloc_page(struct ttm_pool *pool, gfp_t
gfp_flags,
unsigned int order)
(...)
if (!pool->use_dma_alloc) {
- p = alloc_pages_node(pool->nid, gfp_flags, order);
+ p = ttm_alloc_pages_node(pool->nid, gfp_flags, order);
if (p)
p->private = order;
return p;
And in the test we would say:
+static struct page *fake_ttm_alloc_pages_node(int nid, gfp_t gfp_mask,
+ unsigned int order)
+{
+ return NULL;
+}
+
+static void ttm_pool_alloc_failed(struct kunit *test)
+{
(...)
+ kunit_activate_static_stub(test, ttm_alloc_pages_node,
+ fake_ttm_alloc_pages_node);
+ err = ttm_pool_alloc(pool, tt, &simple_ctx);
+ kunit_deactivate_static_stub(test, ttm_alloc_pages_node);
Christian, what do you think?
All the best,
Karolina
-
[1] -
https://lore.kernel.org/all/20230128074918.1180523-1-david...@google.com/
[PATCH] Revert "drm/sched: Qualify drm_sched_wakeup() by drm_sched_entity_is_ready()"
Commit f3123c25 (in combination with the use of work queues by the gpu
scheduler) leads to random lock ups of the GUI [1,2].
This is not a complete revert of commit f3123c25 as drm_sched_wakeup
still needs its entity argument to pass it to drm_sched_can_queue.
[1] https://gitlab.freedesktop.org/drm/amd/-/issues/2994
[2] https://lists.freedesktop.org/archives/dri-devel/2023-November/431606.html
This reverts commit f3123c2590005c5ff631653d31428e40cd10c618.
---
drivers/gpu/drm/scheduler/sched_main.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 682aebe96db7..550492a7a031 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -1029,9 +1029,8 @@ EXPORT_SYMBOL(drm_sched_job_cleanup);
void drm_sched_wakeup(struct drm_gpu_scheduler *sched,
struct drm_sched_entity *entity)
{
- if (drm_sched_entity_is_ready(entity))
- if (drm_sched_can_queue(sched, entity))
- drm_sched_run_job_queue(sched);
+ if (drm_sched_can_queue(sched, entity))
+ drm_sched_run_job_queue(sched);
}
/**
--
2.43.0
Re: [PATCH 1/6] dt-bindings: tc358775: Add support for tc358765
Hi, > The tc358765 is similar to tc358775 except for the stdby-gpios. Bad timing (for me). I'm about to send a bigger patch series for the tc358775 which fixes the (completely) broken initialialization. And also contains some of your fixes. That being said, I intend to make the standby gpio optional also for the tc358755, because it might just be hardwired on the board. But second, I'm really curious if this bridge is working for you correctly as it is at the moment. One particular thing I've noticed is that you must release the reset while both the clock and the data lanes are in LP11 mode. Otherwise, the bridge won't work properly (i.e. horizontally shifted picture, or no picture at all). What DSI host controller are you using? -michael
Re: [PATCH v2 06/17] drm/v3d: Decouple job allocation from job initiation
Hi Iago,
On 11/27/23 05:12, Iago Toral wrote:
El jue, 23-11-2023 a las 21:47 -0300, Maíra Canal escribió:
We want to allow the IOCTLs to allocate the job without initiating
it.
This will be useful for the CPU job submission IOCTL, as the CPU job
has
the need to use information from the user extensions. Currently, the
user extensions are parsed before the job allocation, making it
impossible to fill the CPU job when parsing the user extensions.
Therefore, decouple the job allocation from the job initiation.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_submit.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c
b/drivers/gpu/drm/v3d/v3d_submit.c
index fe46dd316ca0..ed1a310bbd2f 100644
--- a/drivers/gpu/drm/v3d/v3d_submit.c
+++ b/drivers/gpu/drm/v3d/v3d_submit.c
@@ -135,6 +135,21 @@ void v3d_job_put(struct v3d_job *job)
kref_put(&job->refcount, job->free);
}
+static int
+v3d_job_allocate(void **container, size_t size)
+{
+ if (*container)
+ return 0;
Mmm... is this really what we want? At least right now we expect
Yeah, it is.
v3d_job_allocate to always allocate memory, is there any scenario in
which we would expect to call this with an already allocated container?
Take a look here:
19 int
18 v3d_submit_cpu_ioctl(struct drm_device *dev, void *data,
17 struct drm_file *file_priv)
16 {
15 struct v3d_dev *v3d = to_v3d_dev(dev);
14 struct drm_v3d_submit_cpu *args = data;
13 struct v3d_submit_ext se = {0};
12 struct v3d_submit_ext *out_se = NULL;
11 struct v3d_cpu_job *cpu_job = NULL;
10 struct v3d_csd_job *csd_job = NULL;
9 struct v3d_job *clean_job = NULL;
8 struct ww_acquire_ctx acquire_ctx;
7 int ret;
6
5 if (args->flags && !(args->flags &
DRM_V3D_SUBMIT_EXTENSION)) {
4 DRM_INFO("invalid flags: %d\n", args->flags);
3 return -EINVAL;
2 }
1
1187 ret = v3d_job_allocate((void *)&cpu_job, sizeof(*cpu_job));
1 if (ret)
2 return ret;
Here we allocate the CPU job, as we need it allocated to fill its fields
with the information in the extensions.
3
4 if (args->flags & DRM_V3D_SUBMIT_EXTENSION) {
5 ret = v3d_get_extensions(file_priv,
args->extensions, &se, cpu_job);
So, here we filling the CPU job fields with relevant information.
6 if (ret) {
7 DRM_DEBUG("Failed to get extensions.\n");
8 goto fail;
9 }
10 }
11
12 /* Every CPU job must have a CPU job user extension */
13 if (!cpu_job->job_type) {
14 DRM_DEBUG("CPU job must have a CPU job user
extension.\n");
15 goto fail;
16 }
17
18 trace_v3d_submit_cpu_ioctl(&v3d->drm, cpu_job->job_type);
19
20 ret = v3d_job_init(v3d, file_priv, (void *)&cpu_job,
sizeof(*cpu_job),
21v3d_job_free, 0, &se, V3D_CPU);
Here we are initiating the job (drm_sched_job_init and syncobjs stuff).
If I don't have this condition in v3d_job_allocate, I would allocate
the container twice.
22 if (ret)
23 goto fail;
Best Regards,
- Maíra
Iago
+
+ *container = kcalloc(1, size, GFP_KERNEL);
+ if (!*container) {
+ DRM_ERROR("Cannot allocate memory for V3D job.\n");
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
static int
v3d_job_init(struct v3d_dev *v3d, struct drm_file *file_priv,
void **container, size_t size, void (*free)(struct kref
*ref),
@@ -145,11 +160,9 @@ v3d_job_init(struct v3d_dev *v3d, struct
drm_file *file_priv,
bool has_multisync = se && (se->flags &
DRM_V3D_EXT_ID_MULTI_SYNC);
int ret, i;
- *container = kcalloc(1, size, GFP_KERNEL);
- if (!*container) {
- DRM_ERROR("Cannot allocate memory for v3d job.");
- return -ENOMEM;
- }
+ ret = v3d_job_allocate(container, size);
+ if (ret)
+ return ret;
job = *container;
job->v3d = v3d;
[PATCH] nouveau/gsp/r535: remove a stray unlock in r535_gsp_rpc_send()
This unlock doesn't belong here and it leads to a double unlock in
the caller, r535_gsp_rpc_push().
Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
index dc44f5c7833f..818e5c73b7a6 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
@@ -365,10 +365,8 @@ r535_gsp_rpc_send(struct nvkm_gsp *gsp, void *argv, bool
wait, u32 repc)
}
ret = r535_gsp_cmdq_push(gsp, rpc);
- if (ret) {
- mutex_unlock(&gsp->cmdq.mutex);
+ if (ret)
return ERR_PTR(ret);
- }
if (wait) {
msg = r535_gsp_msg_recv(gsp, fn, repc);
--
2.42.0
Re: [PATCH 1/6] dt-bindings: tc358775: Add support for tc358765
* Michael Walle [231127 12:44]: > Hi, > > > The tc358765 is similar to tc358775 except for the stdby-gpios. > > Bad timing (for me). I'm about to send a bigger patch series for the > tc358775 which fixes the (completely) broken initialialization. And also > contains some of your fixes. OK cool, let's merge patches as needed then. Maybe ack the patches that can already be merged, and put together some merged set for the rest of the patches? Or let me know what you prefer, I'll be glad to test and tweak as needed for tc358765. > That being said, I intend to make the standby gpio optional also for the > tc358755, because it might just be hardwired on the board. OK that sounds good to me. > But second, I'm really curious if this bridge is working for you correctly > as it is at the moment. One particular thing I've noticed is that you must > release the reset while both the clock and the data lanes are in LP11 mode. > Otherwise, the bridge won't work properly (i.e. horizontally shifted > picture, or no picture at all). Yes things are working for me. But then again the bridge is initialized by the bootloader, and then Android kernel, and then I kexec to the mainline kernel. And this is with a tc358765 if that might make a difference. So I have not seen your reset issue. Andreas may be seeing it on another tc bridge variant though, so adding Andreas to the loop also. > What DSI host controller are you using? This is an old motorola mz617 tablet with a tc358765 bridge, so omapdrm. I do have one pending patch for omapdrm dsi to change the init order a bit so tc358765 probes reliably. But seems that's a separate issue from your reset issue, I'll post that to the lists too to discuss. What's the dsi host you have? Do you also have some separate i2c eeprom that's needed for initializing something or is that lcd panel specific? No idea what the eeprom is really doing here.. Regards, Tony
Re: [PATCH 2/6] drm/bridge: tc358775: Fix getting dsi host data lanes
> The current code assume hardcoded dsi host endpoint 1, which may not
> be the case. Let's fix that and simplify the code by getting the dsi
> endpoint with of_graph_get_remote_endpoint() that does not assume any
> endpoint numbering.
>
> Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver")
> Signed-off-by: Tony Lindgren
> ---
> drivers/gpu/drm/bridge/tc358775.c | 16
> 1 file changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358775.c
> b/drivers/gpu/drm/bridge/tc358775.c
> --- a/drivers/gpu/drm/bridge/tc358775.c
> +++ b/drivers/gpu/drm/bridge/tc358775.c
> @@ -528,25 +528,17 @@ tc_mode_valid(struct drm_bridge *bridge,
> static int tc358775_parse_dt(struct device_node *np, struct tc_data *tc)
> {
> struct device_node *endpoint;
> - struct device_node *parent;
> struct device_node *remote;
> int dsi_lanes = -1;
>
> - /*
> - * To get the data-lanes of dsi, we need to access the dsi0_out of port1
> - * of dsi0 endpoint from bridge port0 of d2l_in
> - */
> endpoint = of_graph_get_endpoint_by_regs(tc->dev->of_node,
>TC358775_DSI_IN, -1);
> if (endpoint) {
> - /* dsi0_out node */
> - parent = of_graph_get_remote_port_parent(endpoint);
> + /* Get the configured data lanes on the dsi host side */
> + remote = of_graph_get_remote_endpoint(endpoint);
> of_node_put(endpoint);
> - if (parent) {
> - /* dsi0 port 1 */
> - dsi_lanes = drm_of_get_data_lanes_count_ep(parent, 1,
> -1, 1, 4);
> - of_node_put(parent);
> - }
> + dsi_lanes = drm_of_get_data_lanes_count(remote, 1, 4);
I actually have the same fix, but with one additional detail, which I'm
unsure about though: This looks at the data-lanes property of the *remote*
endpoint whereas other bridge drivers (see tc358767, ti-sn65dsi83, lt8912b,
anx7625) look at the local endpoint and I'm not sure what is correct.
-michael
Re: Bug in the error handling in TTMs pool implementation
Am 27.11.23 um 13:24 schrieb Karolina Stolarek:
On 24.11.2023 16:53, Christian König wrote:
@Karolina do you of hand know a way how we could exercise this in a
TTM unit test? Basically we would need to redirect the
alloc_pages_node() symbol to an unit test internal function and let
it return an error (or something like that).
Do I understand correctly that you want to mock NULL from
alloc_pages_node() in ttm_pool_alloc_page()? I had a quick look at it,
and found a(n ugly) way to do it.
KUnit provides an API to redirect calls using
KUNIT_STATIC_STUB_REDIRECT that can be registered in the original
function and then overridden in the test. You can read more about the
mechanism in [1].
The problem is that we'd need to introduce a wrapper call for
alloc_pages_node() in TTM and expose it, so the function can be
substituted during the test. We can't directly modify
alloc_pages_node() due to cyclic dependencies caused by
kunit/static_stub.h.
For example, in ttm_pool.c, we'd have:
+struct page *ttm_alloc_pages_node(int nid, gfp_t gfp_mask,
+ unsigned int order)
+{
+ KUNIT_STATIC_STUB_REDIRECT(ttm_alloc_pages_node, nid, gfp_mask,
order);
+ return alloc_pages_node(nid, gfp_mask, order);
+}
+EXPORT_SYMBOL(ttm_alloc_pages_node);
+
/* Allocate pages of size 1 << order with the given gfp_flags */
static struct page *ttm_pool_alloc_page(struct ttm_pool *pool, gfp_t
gfp_flags,
unsigned int order)
(...)
if (!pool->use_dma_alloc) {
- p = alloc_pages_node(pool->nid, gfp_flags, order);
+ p = ttm_alloc_pages_node(pool->nid, gfp_flags, order);
if (p)
p->private = order;
return p;
And in the test we would say:
+static struct page *fake_ttm_alloc_pages_node(int nid, gfp_t gfp_mask,
+ unsigned int order)
+{
+ return NULL;
+}
+
+static void ttm_pool_alloc_failed(struct kunit *test)
+{
(...)
+ kunit_activate_static_stub(test, ttm_alloc_pages_node,
+ fake_ttm_alloc_pages_node);
+ err = ttm_pool_alloc(pool, tt, &simple_ctx);
+ kunit_deactivate_static_stub(test, ttm_alloc_pages_node);
Christian, what do you think?
Yes, that was exactly what I was looking for.
And you are right that is indeed quite a bit ugly, I was hoping more
like adding debugging hooks or something like that.
Need to look into that in more detail, thanks for the pointer.
Regards,
Christian.
All the best,
Karolina
-
[1] -
https://lore.kernel.org/all/20230128074918.1180523-1-david...@google.com/
[PATCH v2 03/32] fbdev/vfb: Set FBINFO_VIRTFB flag
The vfb driver operates on system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas --- drivers/video/fbdev/vfb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/fbdev/vfb.c b/drivers/video/fbdev/vfb.c index 1b7c338f99560..c748b9311fb12 100644 --- a/drivers/video/fbdev/vfb.c +++ b/drivers/video/fbdev/vfb.c @@ -440,6 +440,7 @@ static int vfb_probe(struct platform_device *dev) if (!info) goto err; + info->flags |= FBINFO_VIRTFB; info->screen_buffer = videomemory; info->fbops = &vfb_ops; -- 2.43.0
[PATCH v2 25/32] staging/sm750fb: Declare fb_ops as constant
Split up lynxfb_ops and declare each as constant. The fb_ops
instance used to be modified while initializing the driver. It is
now constant and the driver picks the correct instance, depending
on the settings for acceleration and cursor support.
Signed-off-by: Thomas Zimmermann
Cc: Sudip Mukherjee
Cc: Teddy Wang
Cc: Greg Kroah-Hartman
Cc: linux-stag...@lists.linux.dev
Acked-by: Javier Martinez Canillas
---
drivers/staging/sm750fb/sm750.c | 59 +++--
1 file changed, 49 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 79bcd5bd49380..35098516f53c9 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -663,16 +663,53 @@ static int sm750fb_set_drv(struct lynxfb_par *par)
return ret;
}
-static struct fb_ops lynxfb_ops = {
+static const struct fb_ops lynxfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = lynxfb_ops_check_var,
.fb_set_par = lynxfb_ops_set_par,
.fb_setcolreg = lynxfb_ops_setcolreg,
.fb_blank = lynxfb_ops_blank,
+ .fb_pan_display = lynxfb_ops_pan_display,
.fb_fillrect = cfb_fillrect,
.fb_imageblit = cfb_imageblit,
.fb_copyarea = cfb_copyarea,
- /* cursor */
+};
+
+static const struct fb_ops lynxfb_ops_with_cursor = {
+ .owner = THIS_MODULE,
+ .fb_check_var = lynxfb_ops_check_var,
+ .fb_set_par = lynxfb_ops_set_par,
+ .fb_setcolreg = lynxfb_ops_setcolreg,
+ .fb_blank = lynxfb_ops_blank,
+ .fb_pan_display = lynxfb_ops_pan_display,
+ .fb_fillrect = cfb_fillrect,
+ .fb_copyarea = cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+ .fb_cursor = lynxfb_ops_cursor,
+};
+
+static const struct fb_ops lynxfb_ops_accel = {
+ .owner = THIS_MODULE,
+ .fb_check_var = lynxfb_ops_check_var,
+ .fb_set_par = lynxfb_ops_set_par,
+ .fb_setcolreg = lynxfb_ops_setcolreg,
+ .fb_blank = lynxfb_ops_blank,
+ .fb_pan_display = lynxfb_ops_pan_display,
+ .fb_fillrect = lynxfb_ops_fillrect,
+ .fb_copyarea = lynxfb_ops_copyarea,
+ .fb_imageblit = lynxfb_ops_imageblit,
+};
+
+static const struct fb_ops lynxfb_ops_accel_with_cursor = {
+ .owner = THIS_MODULE,
+ .fb_check_var = lynxfb_ops_check_var,
+ .fb_set_par = lynxfb_ops_set_par,
+ .fb_setcolreg = lynxfb_ops_setcolreg,
+ .fb_blank = lynxfb_ops_blank,
+ .fb_pan_display = lynxfb_ops_pan_display,
+ .fb_fillrect = lynxfb_ops_fillrect,
+ .fb_copyarea = lynxfb_ops_copyarea,
+ .fb_imageblit = lynxfb_ops_imageblit,
.fb_cursor = lynxfb_ops_cursor,
};
@@ -714,7 +751,6 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int
index)
par->index = index;
output->channel = &crtc->channel;
sm750fb_set_drv(par);
- lynxfb_ops.fb_pan_display = lynxfb_ops_pan_display;
/*
* set current cursor variable and proc pointer,
@@ -731,19 +767,22 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int
index)
crtc->cursor.vstart = sm750_dev->pvMem + crtc->cursor.offset;
memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);
- if (!g_hwcursor) {
- lynxfb_ops.fb_cursor = NULL;
+ if (!g_hwcursor)
sm750_hw_cursor_disable(&crtc->cursor);
- }
/* set info->fbops, must be set before fb_find_mode */
if (!sm750_dev->accel_off) {
/* use 2d acceleration */
- lynxfb_ops.fb_fillrect = lynxfb_ops_fillrect;
- lynxfb_ops.fb_copyarea = lynxfb_ops_copyarea;
- lynxfb_ops.fb_imageblit = lynxfb_ops_imageblit;
+ if (!g_hwcursor)
+ info->fbops = &lynxfb_ops_accel;
+ else
+ info->fbops = &lynxfb_ops_accel_with_cursor;
+ } else {
+ if (!g_hwcursor)
+ info->fbops = &lynxfb_ops;
+ else
+ info->fbops = &lynxfb_ops_with_cursor;
}
- info->fbops = &lynxfb_ops;
if (!g_fbmode[index]) {
g_fbmode[index] = g_def_fbmode;
--
2.43.0
[PATCH v2 10/32] auxdisplay/ht16k33: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in virtual address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Cc: Miguel Ojeda
Cc: Robin van der Gracht
Reviewed-by: Javier Martinez Canillas
Acked-by: Miguel Ojeda
Reviewed-by: Robin van der Gracht
---
drivers/auxdisplay/Kconfig | 5 +
drivers/auxdisplay/ht16k33.c | 7 ++-
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/auxdisplay/Kconfig b/drivers/auxdisplay/Kconfig
index 4377e53f8f572..d944d5298eca8 100644
--- a/drivers/auxdisplay/Kconfig
+++ b/drivers/auxdisplay/Kconfig
@@ -167,10 +167,7 @@ config IMG_ASCII_LCD
config HT16K33
tristate "Holtek Ht16K33 LED controller with keyscan"
depends on FB && I2C && INPUT
- select FB_SYS_FOPS
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
+ select FB_SYSMEM_HELPERS
select INPUT_MATRIXKMAP
select FB_BACKLIGHT
select NEW_LEDS
diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c
index f1716e3ce6a92..2f1dc6b4e2765 100644
--- a/drivers/auxdisplay/ht16k33.c
+++ b/drivers/auxdisplay/ht16k33.c
@@ -356,12 +356,9 @@ static int ht16k33_mmap(struct fb_info *info, struct
vm_area_struct *vma)
static const struct fb_ops ht16k33_fb_ops = {
.owner = THIS_MODULE,
- .fb_read = fb_sys_read,
- .fb_write = fb_sys_write,
+ __FB_DEFAULT_SYSMEM_OPS_RDWR,
.fb_blank = ht16k33_blank,
- .fb_fillrect = sys_fillrect,
- .fb_copyarea = sys_copyarea,
- .fb_imageblit = sys_imageblit,
+ __FB_DEFAULT_SYSMEM_OPS_DRAW,
.fb_mmap = ht16k33_mmap,
};
--
2.43.0
[PATCH v2 00/32] fbdev: Modularize helpers for struct fb_ops
Convert the remaining fbdev drivers to use fbdev's helpers macros for struct fb_ops. Then push the current default code for file-I/O operations into a module and remove it as default. Each driver now selects the helpers its needs for file I/O and drawing to its framebuffer. If no helper has been set for an operation in struct fb_ops, the operation is unsupported. Once applied, fbdev drivers will not include unnecessary helper code. The helpers will also be more robust against mis-use. The first 2 patches are bug fixes. Patches 3 to 26 modify fbdev drivers to set up their fb_ops structures correctly and select the necessary helpers. Patches 27 and 28 do a few additional minor cleanups. Patches 29 to 32 move all helpers for struct fb_ops into modules and drop the default. Helpers also warn if they operate on the wrong type of framebuffer memory. Framebuffers in I/O memory and system memory can only be used with the correct helper functions. v2: * warn once if I/O callbacks are missing (Javier) Thomas Zimmermann (32): fbdev/acornfb: Fix name of fb_ops initializer macro fbdev/sm712fb: Use correct initializer macros for struct fb_ops fbdev/vfb: Set FBINFO_VIRTFB flag fbdev/vfb: Initialize fb_ops with fbdev macros fbdev/arcfb: Set FBINFO_VIRTFB flag fbdev/arcfb: Use generator macros for deferred I/O auxdisplay/cfag12864bfb: Set FBINFO_VIRTFB flag auxdisplay/cfag12864bfb: Initialize fb_ops with fbdev macros auxdisplay/ht16k33: Set FBINFO_VIRTFB flag auxdisplay/ht16k33: Initialize fb_ops with fbdev macros hid/picolcd_fb: Set FBINFO_VIRTFB flag fbdev/sh_mobile_lcdcfb: Set FBINFO_VIRTFB flag fbdev/sh_mobile_lcdcfb: Initialize fb_ops with fbdev macros fbdev/smscufx: Select correct helpers fbdev/udlfb: Select correct helpers fbdev/au1200fb: Set FBINFO_VIRTFB flag fbdev/au1200fb: Initialize fb_ops with fbdev macros fbdev/ps3fb: Set FBINFO_VIRTFB flag fbdev/ps3fb: Initialize fb_ops with fbdev macros media/ivtvfb: Initialize fb_ops to fbdev I/O-memory helpers fbdev/clps711x-fb: Initialize fb_ops with fbdev macros fbdev/vt8500lcdfb: Initialize fb_ops with fbdev macros fbdev/wm8505fb: Initialize fb_ops to fbdev I/O-memory helpers fbdev/cyber2000fb: Initialize fb_ops with fbdev macros staging/sm750fb: Declare fb_ops as constant staging/sm750fb: Initialize fb_ops with fbdev macros fbdev: Rename FB_SYS_FOPS token to FB_SYSMEM_FOPS fbdev: Remove trailing whitespaces fbdev: Push pgprot_decrypted() into mmap implementations fbdev: Move default fb_mmap code into helper function fbdev: Warn on incorrect framebuffer access fbdev: Remove default file-I/O implementations drivers/auxdisplay/Kconfig| 10 +- drivers/auxdisplay/cfag12864bfb.c | 10 +- drivers/auxdisplay/ht16k33.c | 10 +- drivers/hid/hid-picolcd_fb.c | 1 + drivers/media/pci/ivtv/Kconfig| 4 +- drivers/media/pci/ivtv/ivtvfb.c | 6 +- drivers/staging/sm750fb/sm750.c | 65 -- drivers/video/fbdev/Kconfig | 50 ++-- drivers/video/fbdev/acornfb.c | 2 +- drivers/video/fbdev/amba-clcd.c | 2 + drivers/video/fbdev/arcfb.c | 114 +- drivers/video/fbdev/au1100fb.c| 2 + drivers/video/fbdev/au1200fb.c| 11 +- drivers/video/fbdev/clps711x-fb.c | 4 +- drivers/video/fbdev/core/Kconfig | 7 +- drivers/video/fbdev/core/Makefile | 2 +- drivers/video/fbdev/core/cfbcopyarea.c| 3 + drivers/video/fbdev/core/cfbfillrect.c| 3 + drivers/video/fbdev/core/cfbimgblt.c | 3 + drivers/video/fbdev/core/fb_chrdev.c | 68 ++- drivers/video/fbdev/core/fb_defio.c | 2 + drivers/video/fbdev/core/fb_io_fops.c | 36 ++ drivers/video/fbdev/core/fb_sys_fops.c| 6 + drivers/video/fbdev/core/syscopyarea.c| 3 + drivers/video/fbdev/core/sysfillrect.c| 3 + drivers/video/fbdev/core/sysimgblt.c | 3 + drivers/video/fbdev/cyber2000fb.c | 9 +- drivers/video/fbdev/ep93xx-fb.c | 2 + drivers/video/fbdev/gbefb.c | 2 + drivers/video/fbdev/omap/omapfb_main.c| 2 + .../video/fbdev/omap2/omapfb/omapfb-main.c| 2 + drivers/video/fbdev/ps3fb.c | 11 +- drivers/video/fbdev/sa1100fb.c| 2 + drivers/video/fbdev/sbuslib.c | 5 +- drivers/video/fbdev/sh_mobile_lcdcfb.c| 16 +-- drivers/video/fbdev/sm712fb.c | 6 +- drivers/video/fbdev/smscufx.c | 2 + drivers/video/fbdev/udlfb.c | 2 + drivers/video/fbdev/vermilion/vermilion.c | 2 + drivers/video/fbdev/vfb.c | 10 +- drivers/video/fbdev/vt8500lcdfb.c | 4 +- drivers/v
[PATCH v2 17/32] fbdev/au1200fb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in DMA-able virtual address space. Set the
read/write, draw and mmap callbacks to the correct implementation
and avoid implicit defaults. Also select the necessary helpers in
Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig| 5 +
drivers/video/fbdev/au1200fb.c | 7 ++-
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index de57bf59e0179..4c82890887ba1 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1457,10 +1457,7 @@ config FB_AU1100
config FB_AU1200
bool "Au1200/Au1300 LCD Driver"
depends on (FB = y) && MIPS_ALCHEMY
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
- select FB_SYS_FOPS
+ select FB_DMAMEM_HELPERS
help
This is the framebuffer driver for the Au1200/Au1300 SOCs.
It can drive various panels and CRTs by passing in kernel cmd line
diff --git a/drivers/video/fbdev/au1200fb.c b/drivers/video/fbdev/au1200fb.c
index 817c1ebb625b6..16ebbab500972 100644
--- a/drivers/video/fbdev/au1200fb.c
+++ b/drivers/video/fbdev/au1200fb.c
@@ -1488,15 +1488,12 @@ static int au1200fb_ioctl(struct fb_info *info,
unsigned int cmd,
static const struct fb_ops au1200fb_fb_ops = {
.owner = THIS_MODULE,
+ __FB_DEFAULT_DMAMEM_OPS_RDWR,
.fb_check_var = au1200fb_fb_check_var,
.fb_set_par = au1200fb_fb_set_par,
.fb_setcolreg = au1200fb_fb_setcolreg,
.fb_blank = au1200fb_fb_blank,
- .fb_fillrect= sys_fillrect,
- .fb_copyarea= sys_copyarea,
- .fb_imageblit = sys_imageblit,
- .fb_read= fb_sys_read,
- .fb_write = fb_sys_write,
+ __FB_DEFAULT_DMAMEM_OPS_DRAW,
.fb_sync= NULL,
.fb_ioctl = au1200fb_ioctl,
.fb_mmap= au1200fb_fb_mmap,
--
2.43.0
[PATCH v2 12/32] fbdev/sh_mobile_lcdcfb: Set FBINFO_VIRTFB flag
The sh_mobile_lcdcfb driver operates on DMA-able system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas --- drivers/video/fbdev/sh_mobile_lcdcfb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c b/drivers/video/fbdev/sh_mobile_lcdcfb.c index 1364dafaadb1d..5c99fc8a409fd 100644 --- a/drivers/video/fbdev/sh_mobile_lcdcfb.c +++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c @@ -1567,6 +1567,7 @@ sh_mobile_lcdc_overlay_fb_init(struct sh_mobile_lcdc_overlay *ovl) info->fbops = &sh_mobile_lcdc_overlay_ops; info->device = priv->dev; + info->flags |= FBINFO_VIRTFB; info->screen_buffer = ovl->fb_mem; info->par = ovl; @@ -2053,6 +2054,7 @@ sh_mobile_lcdc_channel_fb_init(struct sh_mobile_lcdc_chan *ch, info->fbops = &sh_mobile_lcdc_ops; info->device = priv->dev; + info->flags |= FBINFO_VIRTFB; info->screen_buffer = ch->fb_mem; info->pseudo_palette = &ch->pseudo_palette; info->par = ch; -- 2.43.0
[PATCH v2 24/32] fbdev/cyber2000fb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig | 5 +
drivers/video/fbdev/cyber2000fb.c | 9 +
2 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 004a63cdea5a3..37c8188752baf 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -178,10 +178,7 @@ config FB_IMX
config FB_CYBER2000
tristate "CyberPro 2000/2010/5000 support"
depends on FB && PCI && (BROKEN || !SPARC64)
- select FB_CFB_FILLRECT
- select FB_CFB_COPYAREA
- select FB_CFB_IMAGEBLIT
- select FB_IOMEM_FOPS
+ select FB_IOMEM_HELPERS
select VIDEO_NOMODESET
help
This enables support for the Integraphics CyberPro 20x0 and 5000
diff --git a/drivers/video/fbdev/cyber2000fb.c
b/drivers/video/fbdev/cyber2000fb.c
index 52105dc1a72f3..abb87d3576db0 100644
--- a/drivers/video/fbdev/cyber2000fb.c
+++ b/drivers/video/fbdev/cyber2000fb.c
@@ -227,13 +227,6 @@ cyber2000fb_copyarea(struct fb_info *info, const struct
fb_copyarea *region)
CO_REG_CMD_H, cfb);
}
-static void
-cyber2000fb_imageblit(struct fb_info *info, const struct fb_image *image)
-{
- cfb_imageblit(info, image);
- return;
-}
-
static int cyber2000fb_sync(struct fb_info *info)
{
struct cfb_info *cfb = container_of(info, struct cfb_info, fb);
@@ -1069,7 +1062,7 @@ static const struct fb_ops cyber2000fb_ops = {
.fb_pan_display = cyber2000fb_pan_display,
.fb_fillrect= cyber2000fb_fillrect,
.fb_copyarea= cyber2000fb_copyarea,
- .fb_imageblit = cyber2000fb_imageblit,
+ .fb_imageblit = cfb_imageblit,
.fb_sync= cyber2000fb_sync,
__FB_DEFAULT_IOMEM_OPS_MMAP,
};
--
2.43.0
[PATCH v2 23/32] fbdev/wm8505fb: Initialize fb_ops to fbdev I/O-memory helpers
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in DMA-able address space. This explictily
sets the read/write, draw and mmap callbacks to the correct default
implementation. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default implementation to be invoked; hence requireing the I/O
helpers to be built in any case. Setting all callbacks in all
drivers explicitly will allow to make the I/O helpers optional.
This benefits systems that do not use these functions.
Set the callbacks via macros. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig| 1 +
drivers/video/fbdev/wm8505fb.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 4e06e403d0217..004a63cdea5a3 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1480,6 +1480,7 @@ config FB_WM8505
select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
select FB_MODE_HELPERS
select VIDEOMODE_HELPERS
help
diff --git a/drivers/video/fbdev/wm8505fb.c b/drivers/video/fbdev/wm8505fb.c
index 5833147aa43d1..00952e9c88028 100644
--- a/drivers/video/fbdev/wm8505fb.c
+++ b/drivers/video/fbdev/wm8505fb.c
@@ -248,6 +248,7 @@ static int wm8505fb_blank(int blank, struct fb_info *info)
static const struct fb_ops wm8505fb_ops = {
.owner = THIS_MODULE,
+ __FB_DEFAULT_DMAMEM_OPS_RDWR,
.fb_set_par = wm8505fb_set_par,
.fb_setcolreg = wm8505fb_setcolreg,
.fb_fillrect= wmt_ge_fillrect,
@@ -256,6 +257,7 @@ static const struct fb_ops wm8505fb_ops = {
.fb_sync= wmt_ge_sync,
.fb_pan_display = wm8505fb_pan_display,
.fb_blank = wm8505fb_blank,
+ __FB_DEFAULT_IOMEM_OPS_MMAP,
};
static int wm8505fb_probe(struct platform_device *pdev)
--
2.43.0
[PATCH v2 01/32] fbdev/acornfb: Fix name of fb_ops initializer macro
Fix build by using the correct name for the initializer macro
for struct fb_ops.
Signed-off-by: Thomas Zimmermann
Fixes: 9037afde8b9d ("fbdev/acornfb: Use fbdev I/O helpers")
Cc: Thomas Zimmermann
Cc: Sam Ravnborg
Cc: Helge Deller
Cc: Javier Martinez Canillas
Cc: Arnd Bergmann
Cc: # v6.6+
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/acornfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/acornfb.c b/drivers/video/fbdev/acornfb.c
index 163d2c9f951c3..f0600f6ca2548 100644
--- a/drivers/video/fbdev/acornfb.c
+++ b/drivers/video/fbdev/acornfb.c
@@ -605,7 +605,7 @@ acornfb_pan_display(struct fb_var_screeninfo *var, struct
fb_info *info)
static const struct fb_ops acornfb_ops = {
.owner = THIS_MODULE,
- FB_IOMEM_DEFAULT_OPS,
+ FB_DEFAULT_IOMEM_OPS,
.fb_check_var = acornfb_check_var,
.fb_set_par = acornfb_set_par,
.fb_setcolreg = acornfb_setcolreg,
--
2.43.0
[PATCH v2 29/32] fbdev: Push pgprot_decrypted() into mmap implementations
If a driver sets struct fb_ops.fb_mmap, the fbdev core automatically
calls pgprot_decrypted(). But the default fb_mmap code doesn't handle
pgprot_decrypted().
Move the call to pgprot_decrypted() into each drivers' fb_mmap function.
This only concerns fb_mmap functions for system and DMA memory. For
I/O memory, which is the default case, nothing changes. The fb_mmap
for I/O-memory can later be moved into a helper as well.
DRM's fbdev emulation handles pgprot_decrypted() internally via the
Prime helpers. Fbdev doesn't have to do anything in this case. In
cases where DRM uses deferred I/O, this patch updates fb_mmap correctly.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/auxdisplay/cfag12864bfb.c | 2 ++
drivers/auxdisplay/ht16k33.c | 2 ++
drivers/video/fbdev/amba-clcd.c| 2 ++
drivers/video/fbdev/au1100fb.c | 2 ++
drivers/video/fbdev/au1200fb.c | 2 ++
drivers/video/fbdev/core/fb_chrdev.c | 5 -
drivers/video/fbdev/core/fb_defio.c| 2 ++
drivers/video/fbdev/ep93xx-fb.c| 2 ++
drivers/video/fbdev/gbefb.c| 2 ++
drivers/video/fbdev/omap/omapfb_main.c | 2 ++
drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 2 ++
drivers/video/fbdev/ps3fb.c| 2 ++
drivers/video/fbdev/sa1100fb.c | 2 ++
drivers/video/fbdev/sbuslib.c | 1 +
drivers/video/fbdev/sh_mobile_lcdcfb.c | 4
drivers/video/fbdev/smscufx.c | 2 ++
drivers/video/fbdev/udlfb.c| 2 ++
drivers/video/fbdev/vermilion/vermilion.c | 2 ++
drivers/video/fbdev/vfb.c | 2 ++
19 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/drivers/auxdisplay/cfag12864bfb.c
b/drivers/auxdisplay/cfag12864bfb.c
index ede0f9a513110..5ba19c339f088 100644
--- a/drivers/auxdisplay/cfag12864bfb.c
+++ b/drivers/auxdisplay/cfag12864bfb.c
@@ -51,6 +51,8 @@ static int cfag12864bfb_mmap(struct fb_info *info, struct
vm_area_struct *vma)
{
struct page *pages = virt_to_page(cfag12864b_buffer);
+ vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+
return vm_map_pages_zero(vma, &pages, 1);
}
diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c
index 2f1dc6b4e2765..a90430b7d07ba 100644
--- a/drivers/auxdisplay/ht16k33.c
+++ b/drivers/auxdisplay/ht16k33.c
@@ -351,6 +351,8 @@ static int ht16k33_mmap(struct fb_info *info, struct
vm_area_struct *vma)
struct ht16k33_priv *priv = info->par;
struct page *pages = virt_to_page(priv->fbdev.buffer);
+ vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+
return vm_map_pages_zero(vma, &pages, 1);
}
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 0399db369e709..47d373f04f3f0 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -829,6 +829,8 @@ static int clcdfb_of_dma_setup(struct clcd_fb *fb)
static int clcdfb_of_dma_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
{
+ vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+
return dma_mmap_wc(&fb->dev->dev, vma, fb->fb.screen_base,
fb->fb.fix.smem_start, fb->fb.fix.smem_len);
}
diff --git a/drivers/video/fbdev/au1100fb.c b/drivers/video/fbdev/au1100fb.c
index a9c8d33a6ef71..08109ce535cd4 100644
--- a/drivers/video/fbdev/au1100fb.c
+++ b/drivers/video/fbdev/au1100fb.c
@@ -342,6 +342,8 @@ int au1100fb_fb_mmap(struct fb_info *fbi, struct
vm_area_struct *vma)
{
struct au1100fb_device *fbdev = to_au1100fb_device(fbi);
+ vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+
pgprot_val(vma->vm_page_prot) |= (6 << 9); //CCA=6
return dma_mmap_coherent(fbdev->dev, vma, fbdev->fb_mem, fbdev->fb_phys,
diff --git a/drivers/video/fbdev/au1200fb.c b/drivers/video/fbdev/au1200fb.c
index 16ebbab500972..6f20efc663d7e 100644
--- a/drivers/video/fbdev/au1200fb.c
+++ b/drivers/video/fbdev/au1200fb.c
@@ -1236,6 +1236,8 @@ static int au1200fb_fb_mmap(struct fb_info *info, struct
vm_area_struct *vma)
{
struct au1200fb_device *fbdev = info->par;
+ vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+
return dma_mmap_coherent(fbdev->dev, vma,
fbdev->fb_mem, fbdev->fb_phys, fbdev->fb_len);
}
diff --git a/drivers/video/fbdev/core/fb_chrdev.c
b/drivers/video/fbdev/core/fb_chrdev.c
index 32a7315b4b6dd..b73a122950a94 100644
--- a/drivers/video/fbdev/core/fb_chrdev.c
+++ b/drivers/video/fbdev/core/fb_chrdev.c
@@ -325,11 +325,6 @@ static int fb_mmap(struct file *file, struct
vm_area_struct *vma)
if (info->fbops->fb_mmap) {
int res;
- /*
-* The framebuffer needs to be accessed decrypted, be sure
-* SME protection is remo
[PATCH v2 22/32] fbdev/vt8500lcdfb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in DMA-able virtual address space. Set the
read/write, draw and mmap callbacks to the correct implementation
and avoid implicit defaults. Also select the necessary helpers in
Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig | 1 +
drivers/video/fbdev/vt8500lcdfb.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 6fc43b40acac3..4e06e403d0217 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1467,6 +1467,7 @@ config FB_VT8500
select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS)
select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS)
select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
select FB_MODE_HELPERS
select VIDEOMODE_HELPERS
help
diff --git a/drivers/video/fbdev/vt8500lcdfb.c
b/drivers/video/fbdev/vt8500lcdfb.c
index 42d39a9d5130f..42c25dc851976 100644
--- a/drivers/video/fbdev/vt8500lcdfb.c
+++ b/drivers/video/fbdev/vt8500lcdfb.c
@@ -241,6 +241,7 @@ static int vt8500lcd_blank(int blank, struct fb_info *info)
static const struct fb_ops vt8500lcd_ops = {
.owner = THIS_MODULE,
+ __FB_DEFAULT_DMAMEM_OPS_RDWR,
.fb_set_par = vt8500lcd_set_par,
.fb_setcolreg = vt8500lcd_setcolreg,
.fb_fillrect= wmt_ge_fillrect,
@@ -250,6 +251,7 @@ static const struct fb_ops vt8500lcd_ops = {
.fb_ioctl = vt8500lcd_ioctl,
.fb_pan_display = vt8500lcd_pan_display,
.fb_blank = vt8500lcd_blank,
+ // .fb_mmap needs DMA mmap
};
static irqreturn_t vt8500lcd_handle_irq(int irq, void *dev_id)
@@ -357,7 +359,7 @@ static int vt8500lcd_probe(struct platform_device *pdev)
fbi->fb.fix.smem_start = fb_mem_phys;
fbi->fb.fix.smem_len= fb_mem_len;
- fbi->fb.screen_base = fb_mem_virt;
+ fbi->fb.screen_buffer = fb_mem_virt;
fbi->palette_size = PAGE_ALIGN(512);
fbi->palette_cpu= dma_alloc_coherent(&pdev->dev,
--
2.43.0
[PATCH v2 08/32] auxdisplay/cfag12864bfb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in virtual address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Cc: Miguel Ojeda
Reviewed-by: Javier Martinez Canillas
Acked-by: Miguel Ojeda
---
drivers/auxdisplay/Kconfig| 5 +
drivers/auxdisplay/cfag12864bfb.c | 7 ++-
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/auxdisplay/Kconfig b/drivers/auxdisplay/Kconfig
index 64012cda4d126..4377e53f8f572 100644
--- a/drivers/auxdisplay/Kconfig
+++ b/drivers/auxdisplay/Kconfig
@@ -112,10 +112,7 @@ config CFAG12864B
depends on X86
depends on FB
depends on KS0108
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
- select FB_SYS_FOPS
+ select FB_SYSMEM_HELPERS
default n
help
If you have a Crystalfontz 128x64 2-color LCD, cfag12864b Series,
diff --git a/drivers/auxdisplay/cfag12864bfb.c
b/drivers/auxdisplay/cfag12864bfb.c
index c0ba693845aaf..ede0f9a513110 100644
--- a/drivers/auxdisplay/cfag12864bfb.c
+++ b/drivers/auxdisplay/cfag12864bfb.c
@@ -56,11 +56,8 @@ static int cfag12864bfb_mmap(struct fb_info *info, struct
vm_area_struct *vma)
static const struct fb_ops cfag12864bfb_ops = {
.owner = THIS_MODULE,
- .fb_read = fb_sys_read,
- .fb_write = fb_sys_write,
- .fb_fillrect = sys_fillrect,
- .fb_copyarea = sys_copyarea,
- .fb_imageblit = sys_imageblit,
+ __FB_DEFAULT_SYSMEM_OPS_RDWR,
+ __FB_DEFAULT_SYSMEM_OPS_DRAW,
.fb_mmap = cfag12864bfb_mmap,
};
--
2.43.0
[PATCH v2 14/32] fbdev/smscufx: Select correct helpers
The driver uses deferred I/O. Select the correct helpers via FB_SYSMEM_HELPERS_DEFERRED in the Kconfig file. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas --- drivers/video/fbdev/Kconfig | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index 1eab89a07bbc5..d110d89b21d46 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -1683,11 +1683,7 @@ config FB_SMSCUFX tristate "SMSC UFX6000/7000 USB Framebuffer support" depends on FB && USB select FB_MODE_HELPERS - select FB_SYS_FILLRECT - select FB_SYS_COPYAREA - select FB_SYS_IMAGEBLIT - select FB_SYS_FOPS - select FB_DEFERRED_IO + select FB_SYSMEM_HELPERS_DEFERRED help This is a kernel framebuffer driver for SMSC UFX USB devices. Supports fbdev clients like xf86-video-fbdev, kdrive, fbi, and -- 2.43.0
[PATCH v2 26/32] staging/sm750fb: Initialize fb_ops with fbdev macros
Initialize all instances of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Cc: Sudip Mukherjee
Cc: Teddy Wang
Cc: Greg Kroah-Hartman
Cc: linux-stag...@lists.linux.dev
Reviewed-by: Javier Martinez Canillas
---
drivers/staging/sm750fb/sm750.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 35098516f53c9..04c1b32a22c5e 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -665,31 +665,28 @@ static int sm750fb_set_drv(struct lynxfb_par *par)
static const struct fb_ops lynxfb_ops = {
.owner = THIS_MODULE,
+ FB_DEFAULT_IOMEM_OPS,
.fb_check_var = lynxfb_ops_check_var,
.fb_set_par = lynxfb_ops_set_par,
.fb_setcolreg = lynxfb_ops_setcolreg,
.fb_blank = lynxfb_ops_blank,
.fb_pan_display = lynxfb_ops_pan_display,
- .fb_fillrect = cfb_fillrect,
- .fb_imageblit = cfb_imageblit,
- .fb_copyarea = cfb_copyarea,
};
static const struct fb_ops lynxfb_ops_with_cursor = {
.owner = THIS_MODULE,
+ FB_DEFAULT_IOMEM_OPS,
.fb_check_var = lynxfb_ops_check_var,
.fb_set_par = lynxfb_ops_set_par,
.fb_setcolreg = lynxfb_ops_setcolreg,
.fb_blank = lynxfb_ops_blank,
.fb_pan_display = lynxfb_ops_pan_display,
- .fb_fillrect = cfb_fillrect,
- .fb_copyarea = cfb_copyarea,
- .fb_imageblit = cfb_imageblit,
.fb_cursor = lynxfb_ops_cursor,
};
static const struct fb_ops lynxfb_ops_accel = {
.owner = THIS_MODULE,
+ __FB_DEFAULT_IOMEM_OPS_RDWR,
.fb_check_var = lynxfb_ops_check_var,
.fb_set_par = lynxfb_ops_set_par,
.fb_setcolreg = lynxfb_ops_setcolreg,
@@ -698,10 +695,12 @@ static const struct fb_ops lynxfb_ops_accel = {
.fb_fillrect = lynxfb_ops_fillrect,
.fb_copyarea = lynxfb_ops_copyarea,
.fb_imageblit = lynxfb_ops_imageblit,
+ __FB_DEFAULT_IOMEM_OPS_MMAP,
};
static const struct fb_ops lynxfb_ops_accel_with_cursor = {
.owner = THIS_MODULE,
+ __FB_DEFAULT_IOMEM_OPS_RDWR,
.fb_check_var = lynxfb_ops_check_var,
.fb_set_par = lynxfb_ops_set_par,
.fb_setcolreg = lynxfb_ops_setcolreg,
@@ -711,6 +710,7 @@ static const struct fb_ops lynxfb_ops_accel_with_cursor = {
.fb_copyarea = lynxfb_ops_copyarea,
.fb_imageblit = lynxfb_ops_imageblit,
.fb_cursor = lynxfb_ops_cursor,
+ __FB_DEFAULT_IOMEM_OPS_MMAP,
};
static int lynxfb_set_fbinfo(struct fb_info *info, int index)
--
2.43.0
[PATCH v2 30/32] fbdev: Move default fb_mmap code into helper function
Move the default fb_mmap code for I/O address spaces into the helper
function fb_io_mmap(). The helper can either be called via struct
fb_ops.fb_mmap or as the default if no fb_mmap has been set. Also
set the new helper in __FB_DEFAULT_IOMEM_OPS_MMAP.
In the mid-term, fb_io_mmap() is supposed to become optional. Fbdev
drivers will initialize their struct fb_ops.fb_mmap to the helper
and select a corresponding Kconfig token. The helper can then be made
optional at compile time.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/core/fb_chrdev.c | 36 +--
drivers/video/fbdev/core/fb_io_fops.c | 27
include/linux/fb.h| 3 ++-
3 files changed, 35 insertions(+), 31 deletions(-)
diff --git a/drivers/video/fbdev/core/fb_chrdev.c
b/drivers/video/fbdev/core/fb_chrdev.c
index b73a122950a94..089441c9d810f 100644
--- a/drivers/video/fbdev/core/fb_chrdev.c
+++ b/drivers/video/fbdev/core/fb_chrdev.c
@@ -314,20 +314,16 @@ static long fb_compat_ioctl(struct file *file, unsigned
int cmd,
static int fb_mmap(struct file *file, struct vm_area_struct *vma)
{
struct fb_info *info = file_fb_info(file);
- unsigned long mmio_pgoff;
- unsigned long start;
- u32 len;
+ int res;
if (!info)
return -ENODEV;
+
mutex_lock(&info->mm_lock);
if (info->fbops->fb_mmap) {
- int res;
res = info->fbops->fb_mmap(info, vma);
- mutex_unlock(&info->mm_lock);
- return res;
#if IS_ENABLED(CONFIG_FB_DEFERRED_IO)
} else if (info->fbdefio) {
/*
@@ -335,35 +331,15 @@ static int fb_mmap(struct file *file, struct
vm_area_struct *vma)
* minimum, point struct fb_ops.fb_mmap to
fb_deferred_io_mmap().
*/
dev_warn_once(info->dev, "fbdev mmap not set up for deferred
I/O.\n");
- mutex_unlock(&info->mm_lock);
- return -ENODEV;
+ res = -ENODEV;
#endif
+ } else {
+ res = fb_io_mmap(info, vma);
}
- /*
-* Ugh. This can be either the frame buffer mapping, or
-* if pgoff points past it, the mmio mapping.
-*/
- start = info->fix.smem_start;
- len = info->fix.smem_len;
- mmio_pgoff = PAGE_ALIGN((start & ~PAGE_MASK) + len) >> PAGE_SHIFT;
- if (vma->vm_pgoff >= mmio_pgoff) {
- if (info->var.accel_flags) {
- mutex_unlock(&info->mm_lock);
- return -EINVAL;
- }
-
- vma->vm_pgoff -= mmio_pgoff;
- start = info->fix.mmio_start;
- len = info->fix.mmio_len;
- }
mutex_unlock(&info->mm_lock);
- vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
- vma->vm_page_prot = pgprot_framebuffer(vma->vm_page_prot, vma->vm_start,
- vma->vm_end, start);
-
- return vm_iomap_memory(vma, start, len);
+ return res;
}
static int fb_open(struct inode *inode, struct file *file)
diff --git a/drivers/video/fbdev/core/fb_io_fops.c
b/drivers/video/fbdev/core/fb_io_fops.c
index 871b829521af3..60805e43914e5 100644
--- a/drivers/video/fbdev/core/fb_io_fops.c
+++ b/drivers/video/fbdev/core/fb_io_fops.c
@@ -132,5 +132,32 @@ ssize_t fb_io_write(struct fb_info *info, const char
__user *buf, size_t count,
}
EXPORT_SYMBOL(fb_io_write);
+int fb_io_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ unsigned long start = info->fix.smem_start;
+ u32 len = info->fix.smem_len;
+ unsigned long mmio_pgoff = PAGE_ALIGN((start & ~PAGE_MASK) + len) >>
PAGE_SHIFT;
+
+ /*
+* This can be either the framebuffer mapping, or if pgoff points
+* past it, the mmio mapping.
+*/
+ if (vma->vm_pgoff >= mmio_pgoff) {
+ if (info->var.accel_flags)
+ return -EINVAL;
+
+ vma->vm_pgoff -= mmio_pgoff;
+ start = info->fix.mmio_start;
+ len = info->fix.mmio_len;
+ }
+
+ vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
+ vma->vm_page_prot = pgprot_framebuffer(vma->vm_page_prot, vma->vm_start,
+ vma->vm_end, start);
+
+ return vm_iomap_memory(vma, start, len);
+}
+EXPORT_SYMBOL(fb_io_mmap);
+
MODULE_DESCRIPTION("Fbdev helpers for framebuffers in I/O memory");
MODULE_LICENSE("GPL");
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 94e2c44c65699..a36d05b576b0c 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -536,6 +536,7 @@ extern ssize_t fb_io_read(struct fb_info *info, char __user
*buf,
size_t count, loff_t *ppos);
extern ssize_t fb_io_write(struct fb_info *info, const char __user *buf,
size_t count, l
[PATCH v2 32/32] fbdev: Remove default file-I/O implementations
Drop the default implementations for file read, write and mmap
operations. Each fbdev driver must now provide an implementation
and select any necessary helpers. If no implementation has been
set, fbdev returns an errno code to user space. The code is the
same as if the operation had not been set in the file_operations
struct.
This change makes the fbdev helpers for I/O memory optional. Most
systems only use system-memory framebuffers via DRM's fbdev emulation.
v2:
* warn once if I/O callbacks are missing (Javier)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/core/Kconfig | 1 -
drivers/video/fbdev/core/fb_chrdev.c | 37 +---
include/linux/fb.h | 5
3 files changed, 17 insertions(+), 26 deletions(-)
diff --git a/drivers/video/fbdev/core/Kconfig b/drivers/video/fbdev/core/Kconfig
index faab5d50cac3c..21053bf00dc58 100644
--- a/drivers/video/fbdev/core/Kconfig
+++ b/drivers/video/fbdev/core/Kconfig
@@ -4,7 +4,6 @@
#
config FB_CORE
- select FB_IOMEM_FOPS
select VIDEO_CMDLINE
tristate
diff --git a/drivers/video/fbdev/core/fb_chrdev.c
b/drivers/video/fbdev/core/fb_chrdev.c
index 089441c9d810f..4ebd16b7e3b8d 100644
--- a/drivers/video/fbdev/core/fb_chrdev.c
+++ b/drivers/video/fbdev/core/fb_chrdev.c
@@ -34,13 +34,13 @@ static ssize_t fb_read(struct file *file, char __user *buf,
size_t count, loff_t
if (!info)
return -ENODEV;
+ if (fb_WARN_ON_ONCE(info, !info->fbops->fb_read))
+ return -EINVAL;
+
if (info->state != FBINFO_STATE_RUNNING)
return -EPERM;
- if (info->fbops->fb_read)
- return info->fbops->fb_read(info, buf, count, ppos);
-
- return fb_io_read(info, buf, count, ppos);
+ return info->fbops->fb_read(info, buf, count, ppos);
}
static ssize_t fb_write(struct file *file, const char __user *buf, size_t
count, loff_t *ppos)
@@ -50,13 +50,13 @@ static ssize_t fb_write(struct file *file, const char
__user *buf, size_t count,
if (!info)
return -ENODEV;
+ if (fb_WARN_ON_ONCE(info, !info->fbops->fb_write))
+ return -EINVAL;
+
if (info->state != FBINFO_STATE_RUNNING)
return -EPERM;
- if (info->fbops->fb_write)
- return info->fbops->fb_write(info, buf, count, ppos);
-
- return fb_io_write(info, buf, count, ppos);
+ return info->fbops->fb_write(info, buf, count, ppos);
}
static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
@@ -319,24 +319,11 @@ static int fb_mmap(struct file *file, struct
vm_area_struct *vma)
if (!info)
return -ENODEV;
- mutex_lock(&info->mm_lock);
-
- if (info->fbops->fb_mmap) {
-
- res = info->fbops->fb_mmap(info, vma);
-#if IS_ENABLED(CONFIG_FB_DEFERRED_IO)
- } else if (info->fbdefio) {
- /*
-* FB deferred I/O wants you to handle mmap in your drivers. At
a
-* minimum, point struct fb_ops.fb_mmap to
fb_deferred_io_mmap().
-*/
- dev_warn_once(info->dev, "fbdev mmap not set up for deferred
I/O.\n");
- res = -ENODEV;
-#endif
- } else {
- res = fb_io_mmap(info, vma);
- }
+ if (fb_WARN_ON_ONCE(info, !info->fbops->fb_mmap))
+ return -ENODEV;
+ mutex_lock(&info->mm_lock);
+ res = info->fbops->fb_mmap(info, vma);
mutex_unlock(&info->mm_lock);
return res;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 24f0ec3662352..05dc9624897df 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -867,4 +867,9 @@ static inline bool fb_modesetting_disabled(const char
*drvname)
#define fb_warn_once(fb_info, fmt, ...)
\
pr_warn_once("fb%d: " fmt, (fb_info)->node, ##__VA_ARGS__)
+#define fb_WARN_ONCE(fb_info, condition, fmt, ...) \
+ WARN_ONCE(condition, "fb%d: " fmt, (fb_info)->node, ##__VA_ARGS__)
+#define fb_WARN_ON_ONCE(fb_info, x) \
+ fb_WARN_ONCE(fb_info, (x), "%s", "fb_WARN_ON_ONCE(" __stringify(x) ")")
+
#endif /* _LINUX_FB_H */
--
2.43.0
[PATCH v2 28/32] fbdev: Remove trailing whitespaces
Fix coding style. No functional changes. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas --- drivers/video/fbdev/sbuslib.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/sbuslib.c b/drivers/video/fbdev/sbuslib.c index 21e9fd8e69e26..4d524db5c4f26 100644 --- a/drivers/video/fbdev/sbuslib.c +++ b/drivers/video/fbdev/sbuslib.c @@ -48,7 +48,7 @@ int sbusfb_mmap_helper(struct sbus_mmap_map *map, unsigned long map_offset = 0; unsigned long off; int i; - + if (!(vma->vm_flags & (VM_SHARED | VM_MAYSHARE))) return -EINVAL; @@ -72,7 +72,7 @@ int sbusfb_mmap_helper(struct sbus_mmap_map *map, #define POFF_MASK (PAGE_MASK|0x1UL) #else #define POFF_MASK (PAGE_MASK) -#endif +#endif map_offset = (physbase + map[i].poff) & POFF_MASK; break; } -- 2.43.0
[PATCH v2 09/32] auxdisplay/ht16k33: Set FBINFO_VIRTFB flag
The ht16k33 driver operates on system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Cc: Miguel Ojeda Cc: Robin van der Gracht Reviewed-by: Javier Martinez Canillas Acked-by: Miguel Ojeda Acked-by: Robin van der Gracht --- drivers/auxdisplay/ht16k33.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c index 3a2d883872249..f1716e3ce6a92 100644 --- a/drivers/auxdisplay/ht16k33.c +++ b/drivers/auxdisplay/ht16k33.c @@ -640,6 +640,7 @@ static int ht16k33_fbdev_probe(struct device *dev, struct ht16k33_priv *priv, INIT_DELAYED_WORK(&priv->work, ht16k33_fb_update); fbdev->info->fbops = &ht16k33_fb_ops; + fbdev->info->flags |= FBINFO_VIRTFB; fbdev->info->screen_buffer = fbdev->buffer; fbdev->info->screen_size = HT16K33_FB_SIZE; fbdev->info->fix = ht16k33_fb_fix; -- 2.43.0
[PATCH v2 04/32] fbdev/vfb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in virtual address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig | 5 +
drivers/video/fbdev/vfb.c | 7 ++-
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 53693c826ebdd..63956382ffb65 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1800,10 +1800,7 @@ config FB_DA8XX
config FB_VIRTUAL
tristate "Virtual Frame Buffer support (ONLY FOR TESTING!)"
depends on FB
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
- select FB_SYS_FOPS
+ select FB_SYSMEM_HELPERS
help
This is a `virtual' frame buffer device. It operates on a chunk of
unswappable kernel memory instead of on the memory of a graphics
diff --git a/drivers/video/fbdev/vfb.c b/drivers/video/fbdev/vfb.c
index c748b9311fb12..f6140f247e4b0 100644
--- a/drivers/video/fbdev/vfb.c
+++ b/drivers/video/fbdev/vfb.c
@@ -80,15 +80,12 @@ static int vfb_mmap(struct fb_info *info,
static const struct fb_ops vfb_ops = {
.owner = THIS_MODULE,
- .fb_read= fb_sys_read,
- .fb_write = fb_sys_write,
+ __FB_DEFAULT_SYSMEM_OPS_RDWR,
.fb_check_var = vfb_check_var,
.fb_set_par = vfb_set_par,
.fb_setcolreg = vfb_setcolreg,
.fb_pan_display = vfb_pan_display,
- .fb_fillrect= sys_fillrect,
- .fb_copyarea= sys_copyarea,
- .fb_imageblit = sys_imageblit,
+ __FB_DEFAULT_SYSMEM_OPS_DRAW,
.fb_mmap= vfb_mmap,
};
--
2.43.0
[PATCH v2 31/32] fbdev: Warn on incorrect framebuffer access
Test in framebuffer read, write and drawing helpers if FBINFO_VIRTFB
has been set correctly. Framebuffers in I/O memory should only be
accessed with the architecture's respective helpers. Framebuffers
in system memory should be accessed with the regular load and
store operations. Presumably not all drivers get this right, so we
now warn about it.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/core/cfbcopyarea.c | 3 +++
drivers/video/fbdev/core/cfbfillrect.c | 3 +++
drivers/video/fbdev/core/cfbimgblt.c | 3 +++
drivers/video/fbdev/core/fb_io_fops.c | 9 +
drivers/video/fbdev/core/fb_sys_fops.c | 6 ++
drivers/video/fbdev/core/syscopyarea.c | 3 +++
drivers/video/fbdev/core/sysfillrect.c | 3 +++
drivers/video/fbdev/core/sysimgblt.c | 3 +++
include/linux/fb.h | 8 +++-
9 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/cfbcopyarea.c
b/drivers/video/fbdev/core/cfbcopyarea.c
index 5b80bf3dae504..a271f57d9c6c1 100644
--- a/drivers/video/fbdev/core/cfbcopyarea.c
+++ b/drivers/video/fbdev/core/cfbcopyarea.c
@@ -391,6 +391,9 @@ void cfb_copyarea(struct fb_info *p, const struct
fb_copyarea *area)
if (p->state != FBINFO_STATE_RUNNING)
return;
+ if (p->flags & FBINFO_VIRTFB)
+ fb_warn_once(p, "Framebuffer is not in I/O address space.");
+
/* if the beginning of the target area might overlap with the end of
the source area, be have to copy the area reverse. */
if ((dy == sy && dx > sx) || (dy > sy)) {
diff --git a/drivers/video/fbdev/core/cfbfillrect.c
b/drivers/video/fbdev/core/cfbfillrect.c
index ba9f58b2a5e86..cbaa4c9e2355a 100644
--- a/drivers/video/fbdev/core/cfbfillrect.c
+++ b/drivers/video/fbdev/core/cfbfillrect.c
@@ -287,6 +287,9 @@ void cfb_fillrect(struct fb_info *p, const struct
fb_fillrect *rect)
if (p->state != FBINFO_STATE_RUNNING)
return;
+ if (p->flags & FBINFO_VIRTFB)
+ fb_warn_once(p, "Framebuffer is not in I/O address space.");
+
if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
p->fix.visual == FB_VISUAL_DIRECTCOLOR )
fg = ((u32 *) (p->pseudo_palette))[rect->color];
diff --git a/drivers/video/fbdev/core/cfbimgblt.c
b/drivers/video/fbdev/core/cfbimgblt.c
index 9ebda4e0dc7ab..7d1d2f1a627dc 100644
--- a/drivers/video/fbdev/core/cfbimgblt.c
+++ b/drivers/video/fbdev/core/cfbimgblt.c
@@ -326,6 +326,9 @@ void cfb_imageblit(struct fb_info *p, const struct fb_image
*image)
if (p->state != FBINFO_STATE_RUNNING)
return;
+ if (p->flags & FBINFO_VIRTFB)
+ fb_warn_once(p, "Framebuffer is not in I/O address space.");
+
bitstart = (dy * p->fix.line_length * 8) + (dx * bpp);
start_index = bitstart & (32 - 1);
pitch_index = (p->fix.line_length & (bpl - 1)) * 8;
diff --git a/drivers/video/fbdev/core/fb_io_fops.c
b/drivers/video/fbdev/core/fb_io_fops.c
index 60805e43914e5..3408ff1b2b7a0 100644
--- a/drivers/video/fbdev/core/fb_io_fops.c
+++ b/drivers/video/fbdev/core/fb_io_fops.c
@@ -12,6 +12,9 @@ ssize_t fb_io_read(struct fb_info *info, char __user *buf,
size_t count, loff_t
int c, cnt = 0, err = 0;
unsigned long total_size, trailing;
+ if (info->flags & FBINFO_VIRTFB)
+ fb_warn_once(info, "Framebuffer is not in I/O address space.");
+
if (!info->screen_base)
return -ENODEV;
@@ -73,6 +76,9 @@ ssize_t fb_io_write(struct fb_info *info, const char __user
*buf, size_t count,
int c, cnt = 0, err = 0;
unsigned long total_size, trailing;
+ if (info->flags & FBINFO_VIRTFB)
+ fb_warn_once(info, "Framebuffer is not in I/O address space.");
+
if (!info->screen_base)
return -ENODEV;
@@ -138,6 +144,9 @@ int fb_io_mmap(struct fb_info *info, struct vm_area_struct
*vma)
u32 len = info->fix.smem_len;
unsigned long mmio_pgoff = PAGE_ALIGN((start & ~PAGE_MASK) + len) >>
PAGE_SHIFT;
+ if (info->flags & FBINFO_VIRTFB)
+ fb_warn_once(info, "Framebuffer is not in I/O address space.");
+
/*
* This can be either the framebuffer mapping, or if pgoff points
* past it, the mmio mapping.
diff --git a/drivers/video/fbdev/core/fb_sys_fops.c
b/drivers/video/fbdev/core/fb_sys_fops.c
index 0cb0989abda61..a9aa6519a5b30 100644
--- a/drivers/video/fbdev/core/fb_sys_fops.c
+++ b/drivers/video/fbdev/core/fb_sys_fops.c
@@ -22,6 +22,9 @@ ssize_t fb_sys_read(struct fb_info *info, char __user *buf,
size_t count,
unsigned long total_size, c;
ssize_t ret;
+ if (!(info->flags & FBINFO_VIRTFB))
+ fb_warn_once(info, "Framebuffer is not in virtual address
space.");
+
if (!info->screen_buffer)
return -ENODEV;
@@ -64,6 +67,9 @@ ssize_t fb_sys_write(struct fb
[PATCH v2 02/32] fbdev/sm712fb: Use correct initializer macros for struct fb_ops
Only initialize mmap and draw helpers with macros; leave read/write
callbacks to driver implementations. Fixes the following warnings:
CC [M] drivers/video/fbdev/sm712fb.o
sm712fb.c:1355:25: warning: initialized field overwritten [-Woverride-init]
1355 | .fb_fillrect = cfb_fillrect,
| ^~~~
sm712fb.c:1355:25: note: (near initialization for 'smtcfb_ops.fb_fillrect')
sm712fb.c:1356:25: warning: initialized field overwritten [-Woverride-init]
1356 | .fb_imageblit = cfb_imageblit,
| ^
sm712fb.c:1356:25: note: (near initialization for 'smtcfb_ops.fb_imageblit')
sm712fb.c:1357:25: warning: initialized field overwritten [-Woverride-init]
1357 | .fb_copyarea = cfb_copyarea,
| ^~~~
sm712fb.c:1357:25: note: (near initialization for 'smtcfb_ops.fb_copyarea')
sm712fb.c:1358:25: warning: initialized field overwritten [-Woverride-init]
1358 | .fb_read = smtcfb_read,
| ^~~
sm712fb.c:1358:25: note: (near initialization for 'smtcfb_ops.fb_read')
sm712fb.c:1359:25: warning: initialized field overwritten [-Woverride-init]
1359 | .fb_write = smtcfb_write,
| ^~~~
sm712fb.c:1359:25: note: (near initialization for 'smtcfb_ops.fb_write')
Signed-off-by: Thomas Zimmermann
Fixes: 586132cf1d38 ("fbdev/sm712fb: Initialize fb_ops to fbdev I/O-memory
helpers")
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: Sudip Mukherjee
Cc: Teddy Wang
Cc: Sam Ravnborg
Cc: Helge Deller
Cc: Arnd Bergmann
Cc: linux-fb...@vger.kernel.org
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/sm712fb.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/sm712fb.c b/drivers/video/fbdev/sm712fb.c
index 3f8ef50e32095..104f122e0f273 100644
--- a/drivers/video/fbdev/sm712fb.c
+++ b/drivers/video/fbdev/sm712fb.c
@@ -1347,16 +1347,14 @@ static int smtc_set_par(struct fb_info *info)
static const struct fb_ops smtcfb_ops = {
.owner= THIS_MODULE,
- FB_DEFAULT_IOMEM_OPS,
.fb_check_var = smtc_check_var,
.fb_set_par = smtc_set_par,
.fb_setcolreg = smtc_setcolreg,
.fb_blank = smtc_blank,
- .fb_fillrect = cfb_fillrect,
- .fb_imageblit = cfb_imageblit,
- .fb_copyarea = cfb_copyarea,
+ __FB_DEFAULT_IOMEM_OPS_DRAW,
.fb_read = smtcfb_read,
.fb_write = smtcfb_write,
+ __FB_DEFAULT_IOMEM_OPS_MMAP,
};
/*
--
2.43.0
[PATCH v2 05/32] fbdev/arcfb: Set FBINFO_VIRTFB flag
The arcfb driver operates on system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Cc: Jaya Kumar Reviewed-by: Javier Martinez Canillas --- drivers/video/fbdev/arcfb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/fbdev/arcfb.c b/drivers/video/fbdev/arcfb.c index cff11cb04a551..7344e825543af 100644 --- a/drivers/video/fbdev/arcfb.c +++ b/drivers/video/fbdev/arcfb.c @@ -529,6 +529,7 @@ static int arcfb_probe(struct platform_device *dev) if (!info) goto err_fb_alloc; + info->flags |= FBINFO_VIRTFB; info->screen_buffer = videomemory; info->fbops = &arcfb_ops; -- 2.43.0
[PATCH v2 11/32] hid/picolcd_fb: Set FBINFO_VIRTFB flag
The picolcd_fb driver operates on system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Cc: "Bruno Prémont" Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: linux-in...@vger.kernel.org Reviewed-by: Javier Martinez Canillas Acked-by: Bruno Prémont Acked-by: Jiri Kosina --- drivers/hid/hid-picolcd_fb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/hid/hid-picolcd_fb.c b/drivers/hid/hid-picolcd_fb.c index a4dccdcda26fc..d799d325e 100644 --- a/drivers/hid/hid-picolcd_fb.c +++ b/drivers/hid/hid-picolcd_fb.c @@ -505,6 +505,7 @@ int picolcd_init_framebuffer(struct picolcd_data *data) dev_err(dev, "can't get a free page for framebuffer\n"); goto err_nomem; } + info->flags |= FBINFO_VIRTFB; info->screen_buffer = fbdata->bitmap; info->fix.smem_start = (unsigned long)fbdata->bitmap; memset(fbdata->vbitmap, 0xff, PICOLCDFB_SIZE); -- 2.43.0
[PATCH v2 18/32] fbdev/ps3fb: Set FBINFO_VIRTFB flag
The ps3fb driver operates on system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Christophe Leroy Cc: linuxppc-...@lists.ozlabs.org Reviewed-by: Javier Martinez Canillas --- drivers/video/fbdev/ps3fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/ps3fb.c b/drivers/video/fbdev/ps3fb.c index 64d291d6b1532..de81ad3a5d1ed 100644 --- a/drivers/video/fbdev/ps3fb.c +++ b/drivers/video/fbdev/ps3fb.c @@ -1145,7 +1145,7 @@ static int ps3fb_probe(struct ps3_system_bus_device *dev) info->fix.smem_len = ps3fb_videomemory.size - GPU_FB_START; info->pseudo_palette = par->pseudo_palette; - info->flags = FBINFO_READS_FAST | + info->flags = FBINFO_VIRTFB | FBINFO_READS_FAST | FBINFO_HWACCEL_XPAN | FBINFO_HWACCEL_YPAN; retval = fb_alloc_cmap(&info->cmap, 256, 0); -- 2.43.0
[PATCH v2 15/32] fbdev/udlfb: Select correct helpers
The driver uses deferred I/O. Select the correct helpers via FB_SYSMEM_HELPERS_DEFERRED in the Kconfig file. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas --- drivers/video/fbdev/Kconfig | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index d110d89b21d46..de57bf59e0179 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -1696,11 +1696,7 @@ config FB_UDL depends on FB && USB depends on FB_DEVICE select FB_MODE_HELPERS - select FB_SYS_FILLRECT - select FB_SYS_COPYAREA - select FB_SYS_IMAGEBLIT - select FB_SYS_FOPS - select FB_DEFERRED_IO + select FB_SYSMEM_HELPERS_DEFERRED help This is a kernel framebuffer driver for DisplayLink USB devices. Supports fbdev clients like xf86-video-fbdev, kdrive, fbi, and -- 2.43.0
[PATCH v2 20/32] media/ivtvfb: Initialize fb_ops to fbdev I/O-memory helpers
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. This explictily sets
the read/write, draw and mmap callbacks to the correct default
implementation.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default implementation to be invoked; hence requireing the I/O
helpers to be built in any case. Setting all callbacks in all
drivers explicitly will allow to make the I/O helpers optional.
This benefits systems that do not use these functions.
Set the callbacks via macros. No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Andy Walls
Cc: Mauro Carvalho Chehab
Cc: linux-me...@vger.kernel.org
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Hans Verkuil
---
drivers/media/pci/ivtv/Kconfig | 4 +---
drivers/media/pci/ivtv/ivtvfb.c | 6 +++---
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/media/pci/ivtv/Kconfig b/drivers/media/pci/ivtv/Kconfig
index 9be52101bc4f2..2498f9079b756 100644
--- a/drivers/media/pci/ivtv/Kconfig
+++ b/drivers/media/pci/ivtv/Kconfig
@@ -48,9 +48,7 @@ config VIDEO_IVTV_ALSA
config VIDEO_FB_IVTV
tristate "Conexant cx23415 framebuffer support"
depends on VIDEO_IVTV && FB
- select FB_CFB_FILLRECT
- select FB_CFB_COPYAREA
- select FB_CFB_IMAGEBLIT
+ select FB_IOMEM_HELPERS
help
This is a framebuffer driver for the Conexant cx23415 MPEG
encoder/decoder.
diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 23c8c094e791b..410477e3e6216 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -927,17 +927,17 @@ static int ivtvfb_blank(int blank_mode, struct fb_info
*info)
static const struct fb_ops ivtvfb_ops = {
.owner = THIS_MODULE,
+ .fb_read= fb_io_read,
.fb_write = ivtvfb_write,
.fb_check_var = ivtvfb_check_var,
.fb_set_par = ivtvfb_set_par,
.fb_setcolreg = ivtvfb_setcolreg,
- .fb_fillrect= cfb_fillrect,
- .fb_copyarea= cfb_copyarea,
- .fb_imageblit = cfb_imageblit,
+ __FB_DEFAULT_IOMEM_OPS_DRAW,
.fb_cursor = NULL,
.fb_ioctl = ivtvfb_ioctl,
.fb_pan_display = ivtvfb_pan_display,
.fb_blank = ivtvfb_blank,
+ __FB_DEFAULT_IOMEM_OPS_MMAP,
};
/* Restore hardware after firmware restart */
--
2.43.0
[PATCH v2 06/32] fbdev/arcfb: Use generator macros for deferred I/O
Implement the driver's fops with the generator macros for deferred
I/O. Only requires per-driver code for the on-scren scanout buffer.
The generated helpers implement reading, writing and drawing on top
of that. Also update the selected Kconfig tokens accordingly.
Actual support for deferred I/O is missing from the driver. So
writing to memory-mapped pages does not automatically update the
scanout buffer.
Signed-off-by: Thomas Zimmermann
Cc: Jaya Kumar
Acked-by: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig | 5 +-
drivers/video/fbdev/arcfb.c | 113 +---
2 files changed, 27 insertions(+), 91 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 63956382ffb65..44bf622fc8d74 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -272,10 +272,7 @@ config FB_FM2
config FB_ARC
tristate "Arc Monochrome LCD board support"
depends on FB && (X86 || COMPILE_TEST)
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
- select FB_SYS_FOPS
+ select FB_SYSMEM_HELPERS_DEFERRED
help
This enables support for the Arc Monochrome LCD board. The board
is based on the KS-108 lcd controller and is typically a matrix
diff --git a/drivers/video/fbdev/arcfb.c b/drivers/video/fbdev/arcfb.c
index 7344e825543af..b2408543277ce 100644
--- a/drivers/video/fbdev/arcfb.c
+++ b/drivers/video/fbdev/arcfb.c
@@ -363,39 +363,6 @@ static void arcfb_lcd_update(struct arcfb_par *par,
unsigned int dx,
}
}
-static void arcfb_fillrect(struct fb_info *info,
- const struct fb_fillrect *rect)
-{
- struct arcfb_par *par = info->par;
-
- sys_fillrect(info, rect);
-
- /* update the physical lcd */
- arcfb_lcd_update(par, rect->dx, rect->dy, rect->width, rect->height);
-}
-
-static void arcfb_copyarea(struct fb_info *info,
- const struct fb_copyarea *area)
-{
- struct arcfb_par *par = info->par;
-
- sys_copyarea(info, area);
-
- /* update the physical lcd */
- arcfb_lcd_update(par, area->dx, area->dy, area->width, area->height);
-}
-
-static void arcfb_imageblit(struct fb_info *info, const struct fb_image *image)
-{
- struct arcfb_par *par = info->par;
-
- sys_imageblit(info, image);
-
- /* update the physical lcd */
- arcfb_lcd_update(par, image->dx, image->dy, image->width,
- image->height);
-}
-
static int arcfb_ioctl(struct fb_info *info,
unsigned int cmd, unsigned long arg)
{
@@ -436,76 +403,48 @@ static int arcfb_ioctl(struct fb_info *info,
}
}
-/*
- * this is the access path from userspace. they can seek and write to
- * the fb. it's inefficient for them to do anything less than 64*8
- * writes since we update the lcd in each write() anyway.
- */
-static ssize_t arcfb_write(struct fb_info *info, const char __user *buf,
- size_t count, loff_t *ppos)
+static void arcfb_damage_range(struct fb_info *info, off_t off, size_t len)
{
- /* modded from epson 1355 */
-
- unsigned long p;
- int err;
- unsigned int fbmemlength,x,y,w,h, bitppos, startpos, endpos, bitcount;
- struct arcfb_par *par;
- unsigned int xres;
-
- if (!info->screen_buffer)
- return -ENODEV;
-
- p = *ppos;
- par = info->par;
- xres = info->var.xres;
- fbmemlength = (xres * info->var.yres)/8;
-
- if (p > fbmemlength)
- return -ENOSPC;
-
- err = 0;
- if ((count + p) > fbmemlength) {
- count = fbmemlength - p;
- err = -ENOSPC;
- }
-
- if (count) {
- char *base_addr;
-
- base_addr = info->screen_buffer;
- count -= copy_from_user(base_addr + p, buf, count);
- *ppos += count;
- err = -EFAULT;
- }
-
+ struct arcfb_par *par = info->par;
+ unsigned int xres = info->var.xres;
+ unsigned int bitppos, startpos, endpos, bitcount;
+ unsigned int x, y, width, height;
- bitppos = p*8;
+ bitppos = off * 8;
startpos = floorXres(bitppos, xres);
- endpos = ceilXres((bitppos + (count*8)), xres);
+ endpos = ceilXres((bitppos + (len * 8)), xres);
bitcount = endpos - startpos;
x = startpos % xres;
y = startpos / xres;
- w = xres;
- h = bitcount / xres;
- arcfb_lcd_update(par, x, y, w, h);
+ width = xres;
+ height = bitcount / xres;
+
+ arcfb_lcd_update(par, x, y, width, height);
+}
- if (count)
- return count;
- return err;
+static void arcfb_damage_area(struct fb_info *info, u32 x, u32 y,
+ u32 width, u32 height)
+{
+ struct arcfb_par *par = info->par;
+
+ /* update the physic
[PATCH v2 21/32] fbdev/clps711x-fb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
The driver previously selected drawing ops for system memory
although it operates on I/O memory. Fixed now.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig | 4 +---
drivers/video/fbdev/clps711x-fb.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index f9dab4c900332..6fc43b40acac3 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -146,10 +146,8 @@ config FB_ACORN
config FB_CLPS711X
tristate "CLPS711X LCD support"
depends on FB && (ARCH_CLPS711X || COMPILE_TEST)
+ select FB_IOMEM_HELPERS
select FB_MODE_HELPERS
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
select LCD_CLASS_DEVICE
select VIDEOMODE_HELPERS
help
diff --git a/drivers/video/fbdev/clps711x-fb.c
b/drivers/video/fbdev/clps711x-fb.c
index e956c90efcdcc..dcfd1fbbc7e10 100644
--- a/drivers/video/fbdev/clps711x-fb.c
+++ b/drivers/video/fbdev/clps711x-fb.c
@@ -155,13 +155,11 @@ static int clps711x_fb_blank(int blank, struct fb_info
*info)
static const struct fb_ops clps711x_fb_ops = {
.owner = THIS_MODULE,
+ FB_DEFAULT_IOMEM_OPS,
.fb_setcolreg = clps711x_fb_setcolreg,
.fb_check_var = clps711x_fb_check_var,
.fb_set_par = clps711x_fb_set_par,
.fb_blank = clps711x_fb_blank,
- .fb_fillrect= sys_fillrect,
- .fb_copyarea= sys_copyarea,
- .fb_imageblit = sys_imageblit,
};
static int clps711x_lcd_check_fb(struct lcd_device *lcddev, struct fb_info *fi)
--
2.43.0
[PATCH v2 27/32] fbdev: Rename FB_SYS_FOPS token to FB_SYSMEM_FOPS
Rename the token to harmonize naming among various helpers. For example, I/O-memory helpers use FB_IOMEM_FOPS. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas --- drivers/video/fbdev/Kconfig | 4 ++-- drivers/video/fbdev/core/Kconfig | 6 +++--- drivers/video/fbdev/core/Makefile | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index 37c8188752baf..d5909a9206ffd 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -1464,7 +1464,7 @@ config FB_VT8500 select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS) select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS) select FB_SYS_IMAGEBLIT - select FB_SYS_FOPS + select FB_SYSMEM_FOPS select FB_MODE_HELPERS select VIDEOMODE_HELPERS help @@ -1477,7 +1477,7 @@ config FB_WM8505 select FB_SYS_FILLRECT if (!FB_WMT_GE_ROPS) select FB_SYS_COPYAREA if (!FB_WMT_GE_ROPS) select FB_SYS_IMAGEBLIT - select FB_SYS_FOPS + select FB_SYSMEM_FOPS select FB_MODE_HELPERS select VIDEOMODE_HELPERS help diff --git a/drivers/video/fbdev/core/Kconfig b/drivers/video/fbdev/core/Kconfig index 7a3ed13bed708..faab5d50cac3c 100644 --- a/drivers/video/fbdev/core/Kconfig +++ b/drivers/video/fbdev/core/Kconfig @@ -129,7 +129,7 @@ config FB_LITTLE_ENDIAN endchoice -config FB_SYS_FOPS +config FB_SYSMEM_FOPS tristate depends on FB_CORE @@ -142,8 +142,8 @@ config FB_DMAMEM_HELPERS depends on FB_CORE select FB_SYS_COPYAREA select FB_SYS_FILLRECT - select FB_SYS_FOPS select FB_SYS_IMAGEBLIT + select FB_SYSMEM_FOPS config FB_IOMEM_FOPS tristate @@ -168,8 +168,8 @@ config FB_SYSMEM_HELPERS depends on FB_CORE select FB_SYS_COPYAREA select FB_SYS_FILLRECT - select FB_SYS_FOPS select FB_SYS_IMAGEBLIT + select FB_SYSMEM_FOPS config FB_SYSMEM_HELPERS_DEFERRED bool diff --git a/drivers/video/fbdev/core/Makefile b/drivers/video/fbdev/core/Makefile index c1d657601b2be..d159747590869 100644 --- a/drivers/video/fbdev/core/Makefile +++ b/drivers/video/fbdev/core/Makefile @@ -32,6 +32,6 @@ obj-$(CONFIG_FB_IOMEM_FOPS)+= fb_io_fops.o obj-$(CONFIG_FB_SYS_FILLRECT) += sysfillrect.o obj-$(CONFIG_FB_SYS_COPYAREA) += syscopyarea.o obj-$(CONFIG_FB_SYS_IMAGEBLIT) += sysimgblt.o -obj-$(CONFIG_FB_SYS_FOPS) += fb_sys_fops.o +obj-$(CONFIG_FB_SYSMEM_FOPS) += fb_sys_fops.o obj-$(CONFIG_FB_SVGALIB) += svgalib.o obj-$(CONFIG_FB_DDC) += fb_ddc.o -- 2.43.0
[PATCH v2 16/32] fbdev/au1200fb: Set FBINFO_VIRTFB flag
The au1200fb driver operates on DMA-able system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas --- drivers/video/fbdev/au1200fb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/fbdev/au1200fb.c b/drivers/video/fbdev/au1200fb.c index 98afd385c49cd..817c1ebb625b6 100644 --- a/drivers/video/fbdev/au1200fb.c +++ b/drivers/video/fbdev/au1200fb.c @@ -1568,6 +1568,8 @@ static int au1200fb_init_fbinfo(struct au1200fb_device *fbdev) fbi->fix.mmio_len = 0; fbi->fix.accel = FB_ACCEL_NONE; + fbi->flags |= FBINFO_VIRTFB; + fbi->screen_buffer = fbdev->fb_mem; au1200fb_update_fbinfo(fbi); -- 2.43.0
[PATCH v2 19/32] fbdev/ps3fb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in virtual address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: linuxppc-...@lists.ozlabs.org
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig | 5 +
drivers/video/fbdev/ps3fb.c | 7 ++-
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 4c82890887ba1..f9dab4c900332 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1715,10 +1715,7 @@ config FB_IBM_GXT4500
config FB_PS3
tristate "PS3 GPU framebuffer driver"
depends on FB && PS3_PS3AV
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
- select FB_SYS_FOPS
+ select FB_SYSMEM_HELPERS
help
Include support for the virtual frame buffer in the PS3 platform.
diff --git a/drivers/video/fbdev/ps3fb.c b/drivers/video/fbdev/ps3fb.c
index de81ad3a5d1ed..de8d78bf070a0 100644
--- a/drivers/video/fbdev/ps3fb.c
+++ b/drivers/video/fbdev/ps3fb.c
@@ -939,15 +939,12 @@ static const struct fb_ops ps3fb_ops = {
.owner = THIS_MODULE,
.fb_open= ps3fb_open,
.fb_release = ps3fb_release,
- .fb_read= fb_sys_read,
- .fb_write = fb_sys_write,
+ __FB_DEFAULT_SYSMEM_OPS_RDWR,
.fb_check_var = ps3fb_check_var,
.fb_set_par = ps3fb_set_par,
.fb_setcolreg = ps3fb_setcolreg,
.fb_pan_display = ps3fb_pan_display,
- .fb_fillrect= sys_fillrect,
- .fb_copyarea= sys_copyarea,
- .fb_imageblit = sys_imageblit,
+ __FB_DEFAULT_SYSMEM_OPS_DRAW,
.fb_mmap= ps3fb_mmap,
.fb_blank = ps3fb_blank,
.fb_ioctl = ps3fb_ioctl,
--
2.43.0
[PATCH v2 07/32] auxdisplay/cfag12864bfb: Set FBINFO_VIRTFB flag
The cfag12864bfb driver operates on system memory. Mark the framebuffer accordingly. Helpers operating on the framebuffer memory will test for the presence of this flag. Signed-off-by: Thomas Zimmermann Cc: Miguel Ojeda Reviewed-by: Javier Martinez Canillas Acked-by: Miguel Ojeda --- drivers/auxdisplay/cfag12864bfb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/auxdisplay/cfag12864bfb.c b/drivers/auxdisplay/cfag12864bfb.c index 729845bcc803a..c0ba693845aaf 100644 --- a/drivers/auxdisplay/cfag12864bfb.c +++ b/drivers/auxdisplay/cfag12864bfb.c @@ -72,6 +72,7 @@ static int cfag12864bfb_probe(struct platform_device *device) if (!info) goto none; + info->flags = FBINFO_VIRTFB; info->screen_buffer = cfag12864b_buffer; info->screen_size = CFAG12864B_SIZE; info->fbops = &cfag12864bfb_ops; -- 2.43.0
[PATCH v2 13/32] fbdev/sh_mobile_lcdcfb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in DMA-able virtual address space. Set the
read/write, draw and mmap callbacks to the correct implementation
and avoid implicit defaults. Also select the necessary helpers in
Kconfig.
The driver uses a mixture of DMA helpers and deferred I/O. That
probably needs fixing by a driver maintainer.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig| 7 ++-
drivers/video/fbdev/sh_mobile_lcdcfb.c | 10 +++---
2 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 44bf622fc8d74..1eab89a07bbc5 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1634,12 +1634,9 @@ config FB_SH_MOBILE_LCDC
depends on FB && HAVE_CLK && HAS_IOMEM
depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
depends on FB_DEVICE
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
- select FB_SYS_FOPS
- select FB_DEFERRED_IO
select FB_BACKLIGHT
+ select FB_DEFERRED_IO
+ select FB_DMAMEM_HELPERS
help
Frame buffer driver for the on-chip SH-Mobile LCD controller.
diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c
b/drivers/video/fbdev/sh_mobile_lcdcfb.c
index 5c99fc8a409fd..d84628de51893 100644
--- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
+++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
@@ -1488,13 +1488,10 @@ sh_mobile_lcdc_overlay_mmap(struct fb_info *info,
struct vm_area_struct *vma)
static const struct fb_ops sh_mobile_lcdc_overlay_ops = {
.owner = THIS_MODULE,
- .fb_read= fb_sys_read,
- .fb_write = fb_sys_write,
- .fb_fillrect= sys_fillrect,
- .fb_copyarea= sys_copyarea,
- .fb_imageblit = sys_imageblit,
+ __FB_DEFAULT_DMAMEM_OPS_RDWR,
.fb_blank = sh_mobile_lcdc_overlay_blank,
.fb_pan_display = sh_mobile_lcdc_overlay_pan,
+ __FB_DEFAULT_DMAMEM_OPS_DRAW,
.fb_ioctl = sh_mobile_lcdc_overlay_ioctl,
.fb_check_var = sh_mobile_lcdc_overlay_check_var,
.fb_set_par = sh_mobile_lcdc_overlay_set_par,
@@ -1966,8 +1963,7 @@ sh_mobile_lcdc_mmap(struct fb_info *info, struct
vm_area_struct *vma)
static const struct fb_ops sh_mobile_lcdc_ops = {
.owner = THIS_MODULE,
.fb_setcolreg = sh_mobile_lcdc_setcolreg,
- .fb_read= fb_sys_read,
- .fb_write = fb_sys_write,
+ __FB_DEFAULT_DMAMEM_OPS_RDWR,
.fb_fillrect= sh_mobile_lcdc_fillrect,
.fb_copyarea= sh_mobile_lcdc_copyarea,
.fb_imageblit = sh_mobile_lcdc_imageblit,
--
2.43.0
Re: [PATCH 2/6] drm/bridge: tc358775: Fix getting dsi host data lanes
* Michael Walle [231127 13:10]: > I actually have the same fix, but with one additional detail, which I'm > unsure about though: This looks at the data-lanes property of the *remote* > endpoint whereas other bridge drivers (see tc358767, ti-sn65dsi83, lt8912b, > anx7625) look at the local endpoint and I'm not sure what is correct. Yes I've been wondering about that too. Let's just move it over to the bridge node? We could produce a warning if the dsi host node has the data-lanes property.. No current in kernel users AFAIK. FYI, for omapdrm, we already have a legacy dt property "lanes" for the wiring that tells number of lanes used and the order of the lanes. Regards, Tony
Re: [PATCH 1/6] dt-bindings: tc358775: Add support for tc358765
Hi, Am Montag, 27. November 2023, 13:44:30 CET schrieb Michael Walle: > Hi, > > > The tc358765 is similar to tc358775 except for the stdby-gpios. > > Bad timing (for me). I'm about to send a bigger patch series for the > tc358775 which fixes the (completely) broken initialialization. And also > contains some of your fixes. > > That being said, I intend to make the standby gpio optional also for the > tc358755, because it might just be hardwired on the board. > > But second, I'm really curious if this bridge is working for you correctly > as it is at the moment. One particular thing I've noticed is that you must > release the reset while both the clock and the data lanes are in LP11 mode. > Otherwise, the bridge won't work properly (i.e. horizontally shifted > picture, or no picture at all). Apparently this seems to be true for all Toshiba DSI bridges. The power on sequence for TC9595 (TC358767) also requires LP-11 before releasing the reset signal RESX. Additionally LP-11 is requires for using the DP AUX channel. This also relates to the patch set from Dmitry [1]. Best regards, Alexander [1] https://lore.kernel.org/dri-devel/20231016165355.1327217-1-dmitry.barysh...@linaro.org/ > What DSI host controller are you using? > > -michael -- TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany Amtsgericht München, HRB 105018 Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider http://www.tq-group.com/
Re: [PATCH] phy: mediatek: mipi: mt8183: fix minimal supported frequency
On Thu, 23 Nov 2023 12:02:02 +0100, Michael Walle wrote: > The lowest supported clock frequency of the PHY is 125MHz (see also > mtk_mipi_tx_pll_enable()), but the clamping in .round_rate() has the > wrong minimal value, which will make the .enable() op return -EINVAL on > low frequencies. Fix the minimal clamping value. > > Applied, thanks! [1/1] phy: mediatek: mipi: mt8183: fix minimal supported frequency commit: 06f76e464ac81c6915430b7155769ea4ef16efe4 Best regards, -- ~Vinod
Re: (subset) [PATCH 00/31] Fix and improve Rockchip RK3128 support
On Tue, 29 Aug 2023 19:16:16 +0200, Alex Bee wrote: > this series fixes some issues I found when testing my "new" RK3128 board > with the mainline kernel and adds some core functionality like SMP bringup, > usb and networking. > > The propably most distinctive change is the split up of the DTs for the > different SoCs of this platform: RK3126 and RK3128. Even if I'm not adding > a RK3126 board in this series: I think this change should be done as early > as possible in order to avoid issues in future. > Actually it should have been done like that in the first place. > > [...] Applied, thanks! [08/31] phy: rockchip-inno-usb2: Split ID interrupt phy registers commit: 2fda59099462ee700e424ba3ac928d13ad6389a8 [09/31] phy: phy-rockchip-inno-usb2: Add RK3128 support commit: 62ff41017e147472b07de6125c3be82ce02a8dd7 Best regards, -- ~Vinod
Re: (subset) [PATCH v9 00/12] drm/meson: add support for MIPI DSI Display
On Fri, 24 Nov 2023 09:41:11 +0100, Neil Armstrong wrote: > The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver > (ver 1.21a), > with a custom glue managing the IP resets, clock and data input similar to > the DW-HDMI > glue on the same Amlogic SoCs. > > This is a follow-up of v5 now the DRM patches are applied, the clk & DT > changes > remains for a full DSI support on G12A & SM1 platforms. > > [...] Applied, thanks! [03/12] dt-bindings: phy: amlogic,meson-axg-mipi-pcie-analog: drop text about parent syscon and drop example commit: 130601d488fa06447283767e447909ce9e975e43 [04/12] dt-bindings: phy: amlogic,g12a-mipi-dphy-analog: drop unneeded reg property and example commit: 5f4a9a66f8a7582e90311fa8251da33a8d2111d7 Best regards, -- ~Vinod
Re: (subset) [PATCH 0/4] drm/mediatek: support DSI output on MT8195
On Thu, 23 Nov 2023 14:37:45 +0100, Michael Walle wrote: > Add support for a DSI output on VDOSYS0. Luckily, there is a new > feature to support dynamic selections of the output (connector). > Use it to add support for a DSI output. > > Apart from that, this is pretty straghtforward by just adding new > compatibles and add the correct DSI nodes to the SoC dtsi. > > [...] Applied, thanks! [2/4] dt-bindings: phy: add compatible for Mediatek MT8195 commit: fa50920b4f82993941e0aac349eb8081ce11e38f Best regards, -- ~Vinod
Re: [PATCH] dma-buf: fix check in dma_resv_add_fence
Ping? Can I get an rb or acked-by for that?
Thanks,
Christian.
Am 15.11.23 um 10:30 schrieb Christian König:
It's valid to add the same fence multiple times to a dma-resv object and
we shouldn't need one extra slot for each.
Signed-off-by: Christian König
Fixes: a3f7c10a269d5 ("dma-buf/dma-resv: check if the new fence is really
later")
Cc: sta...@vger.kernel.org # v5.19+
---
drivers/dma-buf/dma-resv.c | 2 +-
include/linux/dma-fence.h | 15 +++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 38b4110378de..eb8b733065b2 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -301,7 +301,7 @@ void dma_resv_add_fence(struct dma_resv *obj, struct
dma_fence *fence,
dma_resv_list_entry(fobj, i, obj, &old, &old_usage);
if ((old->context == fence->context && old_usage >= usage &&
-dma_fence_is_later(fence, old)) ||
+dma_fence_is_later_or_same(fence, old)) ||
dma_fence_is_signaled(old)) {
dma_resv_list_set(fobj, i, fence, usage);
dma_fence_put(old);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index ebe78bd3d121..b3772edca2e6 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -498,6 +498,21 @@ static inline bool dma_fence_is_later(struct dma_fence *f1,
return __dma_fence_is_later(f1->seqno, f2->seqno, f1->ops);
}
+/**
+ * dma_fence_is_later_or_same - return true if f1 is later or same as f2
+ * @f1: the first fence from the same context
+ * @f2: the second fence from the same context
+ *
+ * Returns true if f1 is chronologically later than f2 or the same fence. Both
+ * fences must be from the same context, since a seqno is not re-used across
+ * contexts.
+ */
+static inline bool dma_fence_is_later_or_same(struct dma_fence *f1,
+ struct dma_fence *f2)
+{
+ return f1 == f2 || dma_fence_is_later(f1, f2);
+}
+
/**
* dma_fence_later - return the chronologically later fence
* @f1: the first fence from the same context
Re: [PATCH 3/6] drm/bridge: tc358775: Add jeida-24 support
> The jeida-24 register values are the default hardware settings, but they
> not listed in the driver. Let's add them.
jeida-24 and jeida-18 should have the same mapping, jeida-18 is broken in
this driver. could you test this patch:
--snip--
>From 46da1d76d4908e5879ed746cce1faeacd69c432e Mon Sep 17 00:00:00 2001
From: Michael Walle
Date: Wed, 4 Oct 2023 13:52:57 +0200
Subject: [PATCH] drm/bridge: tc358775: fix support for jeida-18 and jeida-24
The bridge always uses 24bpp internally. Therefore, for jeida-18
mapping we need to discard the lowest two bits for each channel and thus
starting with LV_[RGB]2. jeida-24 has the same mapping but uses four
lanes instead of three, with the forth pair transmitting the lowest two
bits of each channel. Thus, the mapping between jeida-18 and jeida-24
is actually the same, except that one channel is turned off (by
selecting the RGB666 format in VPCTRL).
While at it, remove the bogus comment about the hardware default because
the default is overwritten in any case.
Tested with a jeida-18 display (Evervision VGG644804).
Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver")
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm/bridge/tc358775.c
index 90a89d70d832..592c69c2aedc 100644
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -454,10 +454,6 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
dev_dbg(tc->dev, "bus_formats %04x bpc %d\n",
connector->display_info.bus_formats[0],
tc->bpc);
- /*
-* Default hardware register settings of tc358775 configured
-* with MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA jeida-24 format
-*/
if (connector->display_info.bus_formats[0] ==
MEDIA_BUS_FMT_RGB888_1X7X4_SPWG) {
/* VESA-24 */
@@ -468,14 +464,15 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
d2l_write(tc->i2c, LV_MX1619, LV_MX(LVI_B6, LVI_B7, LVI_B1,
LVI_B2));
d2l_write(tc->i2c, LV_MX2023, LV_MX(LVI_B3, LVI_B4, LVI_B5,
LVI_L0));
d2l_write(tc->i2c, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE,
LVI_R6));
- } else { /* MEDIA_BUS_FMT_RGB666_1X7X3_SPWG - JEIDA-18 */
- d2l_write(tc->i2c, LV_MX0003, LV_MX(LVI_R0, LVI_R1, LVI_R2,
LVI_R3));
- d2l_write(tc->i2c, LV_MX0407, LV_MX(LVI_R4, LVI_L0, LVI_R5,
LVI_G0));
- d2l_write(tc->i2c, LV_MX0811, LV_MX(LVI_G1, LVI_G2, LVI_L0,
LVI_L0));
- d2l_write(tc->i2c, LV_MX1215, LV_MX(LVI_G3, LVI_G4, LVI_G5,
LVI_B0));
- d2l_write(tc->i2c, LV_MX1619, LV_MX(LVI_L0, LVI_L0, LVI_B1,
LVI_B2));
- d2l_write(tc->i2c, LV_MX2023, LV_MX(LVI_B3, LVI_B4, LVI_B5,
LVI_L0));
- d2l_write(tc->i2c, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE,
LVI_L0));
+ } else {
+ /* JEIDA-18 and JEIDA-24 */
+ d2l_write(tc->i2c, LV_MX0003, LV_MX(LVI_R2, LVI_R3, LVI_R4,
LVI_R5));
+ d2l_write(tc->i2c, LV_MX0407, LV_MX(LVI_R6, LVI_R1, LVI_R7,
LVI_G2));
+ d2l_write(tc->i2c, LV_MX0811, LV_MX(LVI_G3, LVI_G4, LVI_G0,
LVI_G1));
+ d2l_write(tc->i2c, LV_MX1215, LV_MX(LVI_G5, LVI_G6, LVI_G7,
LVI_B2));
+ d2l_write(tc->i2c, LV_MX1619, LV_MX(LVI_B0, LVI_B1, LVI_B3,
LVI_B4));
+ d2l_write(tc->i2c, LV_MX2023, LV_MX(LVI_B5, LVI_B6, LVI_B7,
LVI_L0));
+ d2l_write(tc->i2c, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE,
LVI_R0));
}
d2l_write(tc->i2c, VFUEN, VFUEN_EN);
--
2.39.2
Re: [PATCH v2 13/17] drm/v3d: Create a CPU job extension for the timestamp query job
Hi Iago,
On 11/27/23 06:16, Iago Toral wrote:
El jue, 23-11-2023 a las 21:47 -0300, Maíra Canal escribió:
(...)
+static void
+v3d_timestamp_query(struct v3d_cpu_job *job)
+{
+ struct v3d_timestamp_query_info *timestamp_query = &job-
timestamp_query;
+ struct v3d_bo *bo = to_v3d_bo(job->base.bo[0]);
I presume there is an implicit expectation here that a timestamp query
job only has one BO where we are writing query results, right? Maybe we
should document this more explicitly in the uAPI and also check that we
have at least that one BO before trying to map it and write to it?
I'll do it.
Also, is there a reason why we take the job reference from job-
base.bo[0] instead of job->bo[0]?
job is a struct v3d_cpu_job, which has a struct v3d_job as base.
The BOs are stored on struct v3d_job, as this is a common functionality
of all job types.
Best Regards,
- Maíra
Iago
+ u8 *value_addr;
+
+ v3d_get_bo_vaddr(bo);
+
+ for (int i = 0; i < timestamp_query->count; i++) {
+ value_addr = ((u8 *) bo->vaddr) + timestamp_query-
queries[i].offset;
+ *((u64 *) value_addr) = i == 0 ? ktime_get_ns() :
0ull;
+
+ drm_syncobj_replace_fence(timestamp_query-
queries[i].syncobj,
+ job->base.done_fence);
+ }
+
+ v3d_put_bo_vaddr(bo);
+}
+
static struct dma_fence *
v3d_cpu_job_run(struct drm_sched_job *sched_job)
{
@@ -315,6 +352,7 @@ v3d_cpu_job_run(struct drm_sched_job *sched_job)
void (*v3d_cpu_job_fn[])(struct v3d_cpu_job *job) = {
[V3D_CPU_JOB_TYPE_INDIRECT_CSD] =
v3d_rewrite_csd_job_wg_counts_from_indirect,
+ [V3D_CPU_JOB_TYPE_TIMESTAMP_QUERY] =
v3d_timestamp_query,
};
v3d->cpu_job = job;
@@ -504,7 +542,7 @@ static const struct drm_sched_backend_ops
v3d_cache_clean_sched_ops = {
static const struct drm_sched_backend_ops v3d_cpu_sched_ops = {
.run_job = v3d_cpu_job_run,
.timedout_job = v3d_generic_job_timedout,
- .free_job = v3d_sched_job_free
+ .free_job = v3d_cpu_job_free
};
int
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c
b/drivers/gpu/drm/v3d/v3d_submit.c
index b6707ef42706..2f03c8bca593 100644
--- a/drivers/gpu/drm/v3d/v3d_submit.c
+++ b/drivers/gpu/drm/v3d/v3d_submit.c
@@ -438,6 +438,64 @@ v3d_get_cpu_indirect_csd_params(struct drm_file
*file_priv,
NULL, &info->acquire_ctx);
}
+/* Get data for the query timestamp job submission. */
+static int
+v3d_get_cpu_timestamp_query_params(struct drm_file *file_priv,
+ struct drm_v3d_extension __user
*ext,
+ struct v3d_cpu_job *job)
+{
+ u32 __user *offsets, *syncs;
+ struct drm_v3d_timestamp_query timestamp;
+
+ if (!job) {
+ DRM_DEBUG("CPU job extension was attached to a GPU
job.\n");
+ return -EINVAL;
+ }
+
+ if (job->job_type) {
+ DRM_DEBUG("Two CPU job extensions were added to the
same CPU job.\n");
+ return -EINVAL;
+ }
+
+ if (copy_from_user(×tamp, ext, sizeof(timestamp)))
+ return -EFAULT;
+
+ if (timestamp.pad)
+ return -EINVAL;
+
+ job->job_type = V3D_CPU_JOB_TYPE_TIMESTAMP_QUERY;
+
+ job->timestamp_query.queries =
kvmalloc_array(timestamp.count,
+ sizeof(struct
v3d_timestamp_query),
+ GFP_KERNEL);
+ if (!job->timestamp_query.queries)
+ return -ENOMEM;
+
+ offsets = u64_to_user_ptr(timestamp.offsets);
+ syncs = u64_to_user_ptr(timestamp.syncs);
+
+ for (int i = 0; i < timestamp.count; i++) {
+ u32 offset, sync;
+
+ if (copy_from_user(&offset, offsets++,
sizeof(offset))) {
+ kvfree(job->timestamp_query.queries);
+ return -EFAULT;
+ }
+
+ job->timestamp_query.queries[i].offset = offset;
+
+ if (copy_from_user(&sync, syncs++, sizeof(sync))) {
+ kvfree(job->timestamp_query.queries);
+ return -EFAULT;
+ }
+
+ job->timestamp_query.queries[i].syncobj =
drm_syncobj_find(file_priv, sync);
+ }
+ job->timestamp_query.count = timestamp.count;
+
+ return 0;
+}
+
/* Whenever userspace sets ioctl extensions, v3d_get_extensions
parses data
* according to the extension id (name).
*/
@@ -466,6 +524,9 @@ v3d_get_extensions(struct drm_file *file_priv,
case DRM_V3D_EXT_ID_CPU_INDIRECT_CSD:
ret =
v3d_get_cpu_indirect_csd_params(file_priv, user_ext, job);
break;
+ case DRM_V3D_EXT_ID_CPU_TIMESTAMP_QUERY:
+ ret =
v3d_get_cpu_timestamp_que
Re: [PATCH 3/4] arm64: dts: mediatek: mt8195: add DSI and MIPI DPHY nodes
Il 23/11/23 14:37, Michael Walle ha scritto: Add the two DSI controller node and the associated DPHY nodes. Individual boards have to enable them in the board device tree. Signed-off-by: Michael Walle Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH 1/4] dt-bindings: display: mediatek: dsi: add compatible for MediaTek MT8195
Il 23/11/23 14:37, Michael Walle ha scritto: Add the compatible string for MediaTek MT8195 SoC, using the same DSI block as the MT8183. Signed-off-by: Michael Walle Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH 4/4] drm/mediatek: support the DSI0 output on the MT8195 VDOSYS0
Il 23/11/23 14:37, Michael Walle ha scritto: With the latest dynamic selection of the output component, we can now support different outputs. Move current output component into the dynamic routes array and add the new DSI0 output. Signed-off-by: Michael Walle Reviewed-by: AngeloGioacchino Del Regno
[PATCH] Revert "drm/sched: Qualify drm_sched_wakeup() by drm_sched_entity_is_ready()"
Commit f3123c25 (in combination with the use of work queues by the gpu
scheduler) leads to random lock ups of the GUI [1,2].
This is not a complete revert of commit f3123c25 as drm_sched_wakeup
still needs its entity argument to pass it to drm_sched_can_queue.
[1] https://gitlab.freedesktop.org/drm/amd/-/issues/2994
[2] https://lists.freedesktop.org/archives/dri-devel/2023-November/431606.html
This reverts commit f3123c2590005c5ff631653d31428e40cd10c618.
---
drivers/gpu/drm/scheduler/sched_main.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 682aebe96db7..550492a7a031 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -1029,9 +1029,8 @@ EXPORT_SYMBOL(drm_sched_job_cleanup);
void drm_sched_wakeup(struct drm_gpu_scheduler *sched,
struct drm_sched_entity *entity)
{
- if (drm_sched_entity_is_ready(entity))
- if (drm_sched_can_queue(sched, entity))
- drm_sched_run_job_queue(sched);
+ if (drm_sched_can_queue(sched, entity))
+ drm_sched_run_job_queue(sched);
}
/**
--
2.43.0
Re: [PATCH] drm/bridge: panel: Check device dependency before managing device link
On Thu, Nov 23, 2023 at 11:26:15AM +0800, Liu Ying wrote:
> Some panel devices already depend on DRM device, like the panel in
> arch/arm/boot/dts/st/ste-ux500-samsung-skomer.dts, because DRM device is
> the ancestor of those panel devices. device_link_add() would fail by
> returning a NULL pointer for those panel devices because of the existing
> dependency. So, check the dependency by calling device_is_dependent()
> before adding or deleting device link between panel device and DRM device
> so that the link is managed only for independent panel devices.
>
> Fixes: 887878014534 ("drm/bridge: panel: Fix device link for
> DRM_BRIDGE_ATTACH_NO_CONNECTOR")
> Fixes: 199cf07ebd2b ("drm/bridge: panel: Add a device link between drm device
> and panel device")
> Reported-by: Linus Walleij
> Closes:
> https://lore.kernel.org/lkml/cacrpkdagzxd6hbix7mvunjajtmepg00pp6+nj1p0jrfj-ar...@mail.gmail.com/T/
> Tested-by: Linus Walleij
> Signed-off-by: Liu Ying
> ---
> drivers/gpu/drm/bridge/panel.c | 27 ++-
> 1 file changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> index e48823a4f1ed..5e8980023407 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -23,6 +23,7 @@ struct panel_bridge {
> struct drm_panel *panel;
> struct device_link *link;
> u32 connector_type;
> + bool is_independent;
> };
>
> static inline struct panel_bridge *
> @@ -67,12 +68,17 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
> struct drm_device *drm_dev = bridge->dev;
> int ret;
>
> - panel_bridge->link = device_link_add(drm_dev->dev, panel->dev,
> - DL_FLAG_STATELESS);
> - if (!panel_bridge->link) {
> - DRM_ERROR("Failed to add device link between %s and %s\n",
> - dev_name(drm_dev->dev), dev_name(panel->dev));
> - return -EINVAL;
> + panel_bridge->is_independent = !device_is_dependent(drm_dev->dev,
> + panel->dev);
This broke the build. Looks like device_is_dependent() is not even exported.
ERROR: modpost: "device_is_dependent" [drivers/gpu/drm/drm_kms_helper.ko]
undefined!
The recommended defconfigs in rerere-cache do seem to have
CONFIG_DRM_KMS_HELPER=m
so this should have been caught before pushing. How did it slip through?
> +
> + if (panel_bridge->is_independent) {
> + panel_bridge->link = device_link_add(drm_dev->dev, panel->dev,
> + DL_FLAG_STATELESS);
> + if (!panel_bridge->link) {
> + DRM_ERROR("Failed to add device link between %s and
> %s\n",
> + dev_name(drm_dev->dev), dev_name(panel->dev));
> + return -EINVAL;
> + }
> }
>
> if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> @@ -80,7 +86,8 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
>
> if (!bridge->encoder) {
> DRM_ERROR("Missing encoder\n");
> - device_link_del(panel_bridge->link);
> + if (panel_bridge->is_independent)
> + device_link_del(panel_bridge->link);
> return -ENODEV;
> }
>
> @@ -92,7 +99,8 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
>panel_bridge->connector_type);
> if (ret) {
> DRM_ERROR("Failed to initialize connector\n");
> - device_link_del(panel_bridge->link);
> + if (panel_bridge->is_independent)
> + device_link_del(panel_bridge->link);
> return ret;
> }
>
> @@ -115,7 +123,8 @@ static void panel_bridge_detach(struct drm_bridge *bridge)
> struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
> struct drm_connector *connector = &panel_bridge->connector;
>
> - device_link_del(panel_bridge->link);
> + if (panel_bridge->is_independent)
> + device_link_del(panel_bridge->link);
>
> /*
>* Cleanup the connector if we know it was initialized.
> --
> 2.37.1
--
Ville Syrjälä
Intel
Re: [PATCH 3/6] drm/bridge: tc358775: Add jeida-24 support
* Michael Walle [231127 13:25]:
> > The jeida-24 register values are the default hardware settings, but they
> > not listed in the driver. Let's add them.
>
> jeida-24 and jeida-18 should have the same mapping, jeida-18 is broken in
> this driver. could you test this patch:
Yes great works for me with the tc358765 patches:
Tested-by: Tony Lindgren
> --snip--
>
> From 46da1d76d4908e5879ed746cce1faeacd69c432e Mon Sep 17 00:00:00 2001
> From: Michael Walle
> Date: Wed, 4 Oct 2023 13:52:57 +0200
> Subject: [PATCH] drm/bridge: tc358775: fix support for jeida-18 and jeida-24
>
> The bridge always uses 24bpp internally. Therefore, for jeida-18
> mapping we need to discard the lowest two bits for each channel and thus
> starting with LV_[RGB]2. jeida-24 has the same mapping but uses four
> lanes instead of three, with the forth pair transmitting the lowest two
> bits of each channel. Thus, the mapping between jeida-18 and jeida-24
> is actually the same, except that one channel is turned off (by
> selecting the RGB666 format in VPCTRL).
>
> While at it, remove the bogus comment about the hardware default because
> the default is overwritten in any case.
>
> Tested with a jeida-18 display (Evervision VGG644804).
>
> Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver")
> Signed-off-by: Michael Walle
> ---
> drivers/gpu/drm/bridge/tc358775.c | 21 +
> 1 file changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358775.c
> b/drivers/gpu/drm/bridge/tc358775.c
> index 90a89d70d832..592c69c2aedc 100644
> --- a/drivers/gpu/drm/bridge/tc358775.c
> +++ b/drivers/gpu/drm/bridge/tc358775.c
> @@ -454,10 +454,6 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
> dev_dbg(tc->dev, "bus_formats %04x bpc %d\n",
> connector->display_info.bus_formats[0],
> tc->bpc);
> - /*
> - * Default hardware register settings of tc358775 configured
> - * with MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA jeida-24 format
> - */
> if (connector->display_info.bus_formats[0] ==
> MEDIA_BUS_FMT_RGB888_1X7X4_SPWG) {
> /* VESA-24 */
> @@ -468,14 +464,15 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
> d2l_write(tc->i2c, LV_MX1619, LV_MX(LVI_B6, LVI_B7, LVI_B1,
> LVI_B2));
> d2l_write(tc->i2c, LV_MX2023, LV_MX(LVI_B3, LVI_B4, LVI_B5,
> LVI_L0));
> d2l_write(tc->i2c, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE,
> LVI_R6));
> - } else { /* MEDIA_BUS_FMT_RGB666_1X7X3_SPWG - JEIDA-18 */
> - d2l_write(tc->i2c, LV_MX0003, LV_MX(LVI_R0, LVI_R1, LVI_R2,
> LVI_R3));
> - d2l_write(tc->i2c, LV_MX0407, LV_MX(LVI_R4, LVI_L0, LVI_R5,
> LVI_G0));
> - d2l_write(tc->i2c, LV_MX0811, LV_MX(LVI_G1, LVI_G2, LVI_L0,
> LVI_L0));
> - d2l_write(tc->i2c, LV_MX1215, LV_MX(LVI_G3, LVI_G4, LVI_G5,
> LVI_B0));
> - d2l_write(tc->i2c, LV_MX1619, LV_MX(LVI_L0, LVI_L0, LVI_B1,
> LVI_B2));
> - d2l_write(tc->i2c, LV_MX2023, LV_MX(LVI_B3, LVI_B4, LVI_B5,
> LVI_L0));
> - d2l_write(tc->i2c, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE,
> LVI_L0));
> + } else {
> + /* JEIDA-18 and JEIDA-24 */
> + d2l_write(tc->i2c, LV_MX0003, LV_MX(LVI_R2, LVI_R3, LVI_R4,
> LVI_R5));
> + d2l_write(tc->i2c, LV_MX0407, LV_MX(LVI_R6, LVI_R1, LVI_R7,
> LVI_G2));
> + d2l_write(tc->i2c, LV_MX0811, LV_MX(LVI_G3, LVI_G4, LVI_G0,
> LVI_G1));
> + d2l_write(tc->i2c, LV_MX1215, LV_MX(LVI_G5, LVI_G6, LVI_G7,
> LVI_B2));
> + d2l_write(tc->i2c, LV_MX1619, LV_MX(LVI_B0, LVI_B1, LVI_B3,
> LVI_B4));
> + d2l_write(tc->i2c, LV_MX2023, LV_MX(LVI_B5, LVI_B6, LVI_B7,
> LVI_L0));
> + d2l_write(tc->i2c, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE,
> LVI_R0));
> }
>
> d2l_write(tc->i2c, VFUEN, VFUEN_EN);
> --
> 2.39.2
>
Re: [PATCH drm-misc-next 4/5] drm/gpuvm: fall back to drm_exec_lock_obj()
Am 25.11.23 um 00:40 schrieb Danilo Krummrich:
Hi Christian,
do you think it makes sense to handle this in drm_exec_prepare_obj() or
even dma_resv_reserve_fences() even?
IIRC for drm_exec the discussion has gone a bit back and forth between
handling 0 and having a separate function which doesn't allocate fences.
We ended up with the solution using separate calls since you either know
that you don't need fences (because you for example only need to look
something up) or you need fences and eventually calculate the number you
need dynamically and if you then end up with 0 it's a bug.
So to sum it up the conclusion was that it's more defensive to complain
about 0 fences to reserve (which reminds me that
dma_resv_reserve_fences() still needs to get a warning for 0 fences as
well).
Regards,
Christian.
- Danilo
On 11/25/23 00:36, Danilo Krummrich wrote:
Fall back to drm_exec_lock_obj() if num_fences is zero for the
drm_gpuvm_prepare_* function family.
Otherwise dma_resv_reserve_fences() would actually allocate slots even
though num_fences is zero.
Cc: Christian König
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/drm_gpuvm.c | 36 +---
include/drm/drm_gpuvm.h | 23 +++
2 files changed, 36 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
index 54f5e8851de5..d1d1c2379e44 100644
--- a/drivers/gpu/drm/drm_gpuvm.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -1085,6 +1085,36 @@ drm_gpuvm_put(struct drm_gpuvm *gpuvm)
}
EXPORT_SYMBOL_GPL(drm_gpuvm_put);
+static int
+exec_prepare_obj(struct drm_exec *exec, struct drm_gem_object *obj,
+ unsigned int num_fences)
+{
+ return num_fences ? drm_exec_prepare_obj(exec, obj, num_fences) :
+ drm_exec_lock_obj(exec, obj);
+}
+
+/**
+ * drm_gpuvm_prepare_vm() - prepare the GPUVMs common dma-resv
+ * @gpuvm: the &drm_gpuvm
+ * @exec: the &drm_exec context
+ * @num_fences: the amount of &dma_fences to reserve
+ *
+ * Calls drm_exec_prepare_obj() for the GPUVMs dummy &drm_gem_object.
+ *
+ * Using this function directly, it is the drivers responsibility to
call
+ * drm_exec_init() and drm_exec_fini() accordingly.
+ *
+ * Returns: 0 on success, negative error code on failure.
+ */
+int
+drm_gpuvm_prepare_vm(struct drm_gpuvm *gpuvm,
+ struct drm_exec *exec,
+ unsigned int num_fences)
+{
+ return exec_prepare_obj(exec, gpuvm->r_obj, num_fences);
+}
+EXPORT_SYMBOL_GPL(drm_gpuvm_prepare_vm);
+
static int
__drm_gpuvm_prepare_objects(struct drm_gpuvm *gpuvm,
struct drm_exec *exec,
@@ -1095,7 +1125,7 @@ __drm_gpuvm_prepare_objects(struct drm_gpuvm
*gpuvm,
int ret = 0;
for_each_vm_bo_in_list(gpuvm, extobj, &extobjs, vm_bo) {
- ret = drm_exec_prepare_obj(exec, vm_bo->obj, num_fences);
+ ret = exec_prepare_obj(exec, vm_bo->obj, num_fences);
if (ret)
break;
}
@@ -1116,7 +1146,7 @@ drm_gpuvm_prepare_objects_locked(struct
drm_gpuvm *gpuvm,
drm_gpuvm_resv_assert_held(gpuvm);
list_for_each_entry(vm_bo, &gpuvm->extobj.list,
list.entry.extobj) {
- ret = drm_exec_prepare_obj(exec, vm_bo->obj, num_fences);
+ ret = exec_prepare_obj(exec, vm_bo->obj, num_fences);
if (ret)
break;
@@ -1186,7 +1216,7 @@ drm_gpuvm_prepare_range(struct drm_gpuvm
*gpuvm, struct drm_exec *exec,
drm_gpuvm_for_each_va_range(va, gpuvm, addr, end) {
struct drm_gem_object *obj = va->gem.obj;
- ret = drm_exec_prepare_obj(exec, obj, num_fences);
+ ret = exec_prepare_obj(exec, obj, num_fences);
if (ret)
return ret;
}
diff --git a/include/drm/drm_gpuvm.h b/include/drm/drm_gpuvm.h
index f94fec9a8517..b3f82ec7fb17 100644
--- a/include/drm/drm_gpuvm.h
+++ b/include/drm/drm_gpuvm.h
@@ -544,26 +544,9 @@ struct drm_gpuvm_exec {
} extra;
};
-/**
- * drm_gpuvm_prepare_vm() - prepare the GPUVMs common dma-resv
- * @gpuvm: the &drm_gpuvm
- * @exec: the &drm_exec context
- * @num_fences: the amount of &dma_fences to reserve
- *
- * Calls drm_exec_prepare_obj() for the GPUVMs dummy &drm_gem_object.
- *
- * Using this function directly, it is the drivers responsibility to
call
- * drm_exec_init() and drm_exec_fini() accordingly.
- *
- * Returns: 0 on success, negative error code on failure.
- */
-static inline int
-drm_gpuvm_prepare_vm(struct drm_gpuvm *gpuvm,
- struct drm_exec *exec,
- unsigned int num_fences)
-{
- return drm_exec_prepare_obj(exec, gpuvm->r_obj, num_fences);
-}
+int drm_gpuvm_prepare_vm(struct drm_gpuvm *gpuvm,
+ struct drm_exec *exec,
+ unsigned int num_fences);
int drm_gpuvm_prepare_objects(struct drm_gpuvm *gpuvm,
struct drm_exec *exec,
Re: [PATCH v2 25/32] staging/sm750fb: Declare fb_ops as constant
On Mon, Nov 27, 2023 at 02:15:54PM +0100, Thomas Zimmermann wrote: > Split up lynxfb_ops and declare each as constant. The fb_ops > instance used to be modified while initializing the driver. It is > now constant and the driver picks the correct instance, depending > on the settings for acceleration and cursor support. > > Signed-off-by: Thomas Zimmermann > Cc: Sudip Mukherjee > Cc: Teddy Wang > Cc: Greg Kroah-Hartman > Cc: linux-stag...@lists.linux.dev > Acked-by: Javier Martinez Canillas > --- > drivers/staging/sm750fb/sm750.c | 59 +++-- > 1 file changed, 49 insertions(+), 10 deletions(-) Acked-by: Greg Kroah-Hartman
Re: [PATCH v2 26/32] staging/sm750fb: Initialize fb_ops with fbdev macros
On Mon, Nov 27, 2023 at 02:15:55PM +0100, Thomas Zimmermann wrote: > Initialize all instances of struct fb_ops with fbdev initializer > macros for framebuffers in I/O address space. Set the read/write, > draw and mmap callbacks to the correct implementation and avoid > implicit defaults. Also select the necessary helpers in Kconfig. > > Fbdev drivers sometimes rely on the callbacks being NULL for a > default I/O-memory-based implementation to be invoked; hence > requiring the I/O helpers to be built in any case. Setting all > callbacks in all drivers explicitly will allow to make the I/O > helpers optional. This benefits systems that do not use these > functions. > > Signed-off-by: Thomas Zimmermann > Cc: Sudip Mukherjee > Cc: Teddy Wang > Cc: Greg Kroah-Hartman > Cc: linux-stag...@lists.linux.dev > Reviewed-by: Javier Martinez Canillas Acked-by: Greg Kroah-Hartman
Re: [PATCH 1/2] drm/sched: Rename priority MIN to LOW
Hi Luben,
Am 24.11.23 um 08:57 schrieb Christian König:
Am 24.11.23 um 06:27 schrieb Luben Tuikov:
Rename DRM_SCHED_PRIORITY_MIN to DRM_SCHED_PRIORITY_LOW.
This mirrors DRM_SCHED_PRIORITY_HIGH, for a list of DRM scheduler
priorities
in ascending order,
DRM_SCHED_PRIORITY_LOW,
DRM_SCHED_PRIORITY_NORMAL,
DRM_SCHED_PRIORITY_HIGH,
DRM_SCHED_PRIORITY_KERNEL.
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Danilo Krummrich
Cc: Alex Deucher
Cc: Christian König
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Luben Tuikov
Reviewed-by: Christian König
Looks like you missed one usage in Nouveau:
drivers/gpu/drm/nouveau/nouveau_sched.c:21:41: error:
‘DRM_SCHED_PRIORITY_MIN’ undeclared here (not in a function); did you
mean ‘DRM_SCHED_PRIORITY_LOW’?
21 | NOUVEAU_SCHED_PRIORITY_SINGLE = DRM_SCHED_PRIORITY_MIN,
| ^~
| DRM_SCHED_PRIORITY_LOW
This now results in a build error on drm-misc-next.
Christian.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 +-
drivers/gpu/drm/msm/msm_gpu.h | 2 +-
drivers/gpu/drm/scheduler/sched_entity.c | 2 +-
drivers/gpu/drm/scheduler/sched_main.c | 10 +-
include/drm/gpu_scheduler.h | 2 +-
6 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index e2ae9ba147ba97..5cb33ac99f7089 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -73,10 +73,10 @@ amdgpu_ctx_to_drm_sched_prio(int32_t ctx_prio)
return DRM_SCHED_PRIORITY_NORMAL;
case AMDGPU_CTX_PRIORITY_VERY_LOW:
- return DRM_SCHED_PRIORITY_MIN;
+ return DRM_SCHED_PRIORITY_LOW;
case AMDGPU_CTX_PRIORITY_LOW:
- return DRM_SCHED_PRIORITY_MIN;
+ return DRM_SCHED_PRIORITY_LOW;
case AMDGPU_CTX_PRIORITY_NORMAL:
return DRM_SCHED_PRIORITY_NORMAL;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 62bb7fc7448ad9..1a25931607c514 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -325,7 +325,7 @@ void amdgpu_job_stop_all_jobs_on_sched(struct
drm_gpu_scheduler *sched)
int i;
/* Signal all jobs not yet scheduled */
- for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_MIN; i--) {
+ for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_LOW; i--) {
struct drm_sched_rq *rq = sched->sched_rq[i];
spin_lock(&rq->lock);
list_for_each_entry(s_entity, &rq->entities, list) {
diff --git a/drivers/gpu/drm/msm/msm_gpu.h
b/drivers/gpu/drm/msm/msm_gpu.h
index 4252e3839fbc83..eb0c97433e5f8a 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -347,7 +347,7 @@ struct msm_gpu_perfcntr {
* DRM_SCHED_PRIORITY_KERNEL priority level is treated specially in
some
* cases, so we don't use it (no need for kernel generated jobs).
*/
-#define NR_SCHED_PRIORITIES (1 + DRM_SCHED_PRIORITY_HIGH -
DRM_SCHED_PRIORITY_MIN)
+#define NR_SCHED_PRIORITIES (1 + DRM_SCHED_PRIORITY_HIGH -
DRM_SCHED_PRIORITY_LOW)
/**
* struct msm_file_private - per-drm_file context
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 20c9c561843ce1..cb7445be3cbb4e 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -88,7 +88,7 @@ int drm_sched_entity_init(struct drm_sched_entity
*entity,
drm_err(sched_list[0], "entity with out-of-bounds
priority:%u num_rqs:%u\n",
entity->priority, sched_list[0]->num_rqs);
entity->priority = max_t(s32, (s32)
sched_list[0]->num_rqs - 1,
- (s32) DRM_SCHED_PRIORITY_MIN);
+ (s32) DRM_SCHED_PRIORITY_LOW);
}
entity->rq = sched_list[0]->sched_rq[entity->priority];
}
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 044a8c4875ba64..b6d7bc49ff6ef4 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -1052,7 +1052,7 @@ drm_sched_select_entity(struct
drm_gpu_scheduler *sched)
int i;
/* Kernel run queue has higher priority than normal run queue*/
- for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_MIN; i--) {
+ for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_LOW; i--) {
entity = drm_sched_policy == DRM_SCHED_POLICY_FIFO ?
drm_sched_rq_select_entity_fifo(sched,
sched->sched_rq[i]) :
drm_sched_rq_select_entity_rr(sched, sched->sched_rq[i]);
@@ -1291,7 +1291,7 @@ int drm_sched_init(struct drm_gpu_scheduler
*sched,
if (!sche
Re: [PATCH v2 01/12] drm/rockchip: move output interface related definition to rockchip_drm_drv.h
On Wed, Nov 22, 2023 at 08:53:49PM +0800, Andy Yan wrote:
> From: Andy Yan
>
> The output interface related definition can shared between
> vop and vop2, move them to rockchip_drm_drv.h can avoid duplicated
> definition.
>
> Signed-off-by: Andy Yan
Reviewed-by: Sascha Hauer
Sascha
>
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 1 -
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 1 -
> drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 1 -
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 -
> drivers/gpu/drm/rockchip/inno_hdmi.c| 1 -
> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 1 -
> drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 17 +
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 12 +---
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.h| 16 +---
> drivers/gpu/drm/rockchip/rockchip_lvds.c| 1 -
> drivers/gpu/drm/rockchip/rockchip_rgb.c | 1 -
> 11 files changed, 19 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index 84aa811ca1e9..bd08d57486fe 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -30,7 +30,6 @@
> #include
>
> #include "rockchip_drm_drv.h"
> -#include "rockchip_drm_vop.h"
>
> #define RK3288_GRF_SOC_CON6 0x25c
> #define RK3288_EDP_LCDC_SEL BIT(5)
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index 21254e4e107a..a855c45ae7f3 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -24,7 +24,6 @@
>
> #include "cdn-dp-core.h"
> #include "cdn-dp-reg.h"
> -#include "rockchip_drm_vop.h"
>
> static inline struct cdn_dp_device *connector_to_dp(struct drm_connector
> *connector)
> {
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index 6396f9324dab..4cc8ed8f4fbd 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> @@ -26,7 +26,6 @@
> #include
>
> #include "rockchip_drm_drv.h"
> -#include "rockchip_drm_vop.h"
>
> #define DSI_PHY_RSTZ 0xa0
> #define PHY_DISFORCEPLL 0
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index 341550199111..fe33092abbe7 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -18,7 +18,6 @@
> #include
>
> #include "rockchip_drm_drv.h"
> -#include "rockchip_drm_vop.h"
>
> #define RK3228_GRF_SOC_CON2 0x0408
> #define RK3228_HDMI_SDAIN_MSKBIT(14)
> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
> b/drivers/gpu/drm/rockchip/inno_hdmi.c
> index 6e5b922a121e..f6d819803c0e 100644
> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> @@ -23,7 +23,6 @@
> #include
>
> #include "rockchip_drm_drv.h"
> -#include "rockchip_drm_vop.h"
>
> #include "inno_hdmi.h"
>
> diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> index fa6e592e0276..78136d0c5a65 100644
> --- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> +++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
> @@ -17,7 +17,6 @@
> #include "rk3066_hdmi.h"
>
> #include "rockchip_drm_drv.h"
> -#include "rockchip_drm_vop.h"
>
> #define DEFAULT_PLLA_RATE 3000
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> index aeb03a57240f..3d8ab2defa1b 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> @@ -20,6 +20,23 @@
> #define ROCKCHIP_MAX_CONNECTOR 2
> #define ROCKCHIP_MAX_CRTC4
>
> +/*
> + * display output interface supported by rockchip lcdc
> + */
> +#define ROCKCHIP_OUT_MODE_P888 0
> +#define ROCKCHIP_OUT_MODE_BT1120 0
> +#define ROCKCHIP_OUT_MODE_P666 1
> +#define ROCKCHIP_OUT_MODE_P565 2
> +#define ROCKCHIP_OUT_MODE_BT656 5
> +#define ROCKCHIP_OUT_MODE_S888 8
> +#define ROCKCHIP_OUT_MODE_S888_DUMMY 12
> +#define ROCKCHIP_OUT_MODE_YUV420 14
> +/* for use special outface */
> +#define ROCKCHIP_OUT_MODE_ 15
> +
> +/* output flags */
> +#define ROCKCHIP_OUTPUT_DSI_DUAL BIT(0)
> +
> struct drm_device;
> struct drm_connector;
> struct iommu_domain;
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> index 4b2daefeb8c1..43d9c9191b7a 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> @@ -277,17 +277,7 @@ struct
Re: [PATCH v2 02/12] Revert "drm/rockchip: vop2: Use regcache_sync() to fix suspend/resume"
On Wed, Nov 22, 2023 at 08:54:00PM +0800, Andy Yan wrote:
> From: Andy Yan
>
> This reverts commit b63a553e8f5aa6574eeb535a551817a93c426d8c.
>
> regcache_sync will try to reload the configuration in regcache to
> hardware, but the registers of 4 Cluster windows and Esmart1/2/3 on
> the upcoming rk3588 can not be set successfully before internal PD
> power on.
>
> Also it's better to keep the hardware register as it is before we really
> enable it.
>
> So let's revert this version, and keep the first version:
> commit afa965a45e01 ("drm/rockchip: vop2: fix suspend/resume")
>
> Signed-off-by: Andy Yan
Reviewed-by: Sascha Hauer
Sascha
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index 312da5783362..57784d0a22a6 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -217,6 +217,8 @@ struct vop2 {
> struct vop2_win win[];
> };
>
> +static const struct regmap_config vop2_regmap_config;
> +
> static struct vop2_video_port *to_vop2_video_port(struct drm_crtc *crtc)
> {
> return container_of(crtc, struct vop2_video_port, crtc);
> @@ -883,7 +885,11 @@ static void vop2_enable(struct vop2 *vop2)
> return;
> }
>
> - regcache_sync(vop2->map);
> + ret = regmap_reinit_cache(vop2->map, &vop2_regmap_config);
> + if (ret) {
> + drm_err(vop2->drm, "failed to reinit cache: %d\n", ret);
> + return;
> + }
>
> if (vop2->data->soc_id == 3566)
> vop2_writel(vop2, RK3568_OTP_WIN_EN, 1);
> @@ -913,8 +919,6 @@ static void vop2_disable(struct vop2 *vop2)
>
> pm_runtime_put_sync(vop2->dev);
>
> - regcache_mark_dirty(vop2->map);
> -
> clk_disable_unprepare(vop2->aclk);
> clk_disable_unprepare(vop2->hclk);
> }
> --
> 2.34.1
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v2 03/12] drm/rockchip: vop2: set half_block_en bit in all mode
On Wed, Nov 22, 2023 at 08:54:13PM +0800, Andy Yan wrote:
> From: Andy Yan
>
> At first we thought the half_block_en bit in AFBCD_CTRL register
> only work in afbc mode. But the fact is that it control the line
> buffer in all mode(afbc/tile/line), so we need configure it in
> all case.
>
> Signed-off-by: Andy Yan
Reviewed-by: Sascha Hauer
Sascha
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 25 ++--
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index 57784d0a22a6..639dfebc6bd1 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -521,6 +521,18 @@ static bool rockchip_vop2_mod_supported(struct drm_plane
> *plane, u32 format,
> return vop2_convert_afbc_format(format) >= 0;
> }
>
> +/*
> + * 0: Full mode, 16 lines for one tail
> + * 1: half block mode, 8 lines one tail
> + */
> +static bool vop2_half_block_enable(struct drm_plane_state *pstate)
> +{
> + if (pstate->rotation & (DRM_MODE_ROTATE_270 | DRM_MODE_ROTATE_90))
> + return false;
> + else
> + return true;
> +}
> +
> static u32 vop2_afbc_transform_offset(struct drm_plane_state *pstate,
> bool afbc_half_block_en)
> {
> @@ -1144,6 +1156,7 @@ static void vop2_plane_atomic_update(struct drm_plane
> *plane,
> bool rotate_90 = pstate->rotation & DRM_MODE_ROTATE_90;
> struct rockchip_gem_object *rk_obj;
> unsigned long offset;
> + bool half_block_en;
> bool afbc_en;
> dma_addr_t yrgb_mst;
> dma_addr_t uv_mst;
> @@ -1236,6 +1249,7 @@ static void vop2_plane_atomic_update(struct drm_plane
> *plane,
> dsp_info = (dsp_h - 1) << 16 | ((dsp_w - 1) & 0x);
>
> format = vop2_convert_format(fb->format->format);
> + half_block_en = vop2_half_block_enable(pstate);
>
> drm_dbg(vop2->drm, "vp%d update %s[%dx%d->%dx%d@%dx%d] fmt[%p4cc_%s]
> addr[%pad]\n",
> vp->id, win->data->name, actual_w, actual_h, dsp_w, dsp_h,
> @@ -1243,6 +1257,9 @@ static void vop2_plane_atomic_update(struct drm_plane
> *plane,
> &fb->format->format,
> afbc_en ? "AFBC" : "", &yrgb_mst);
>
> + if (vop2_cluster_window(win))
> + vop2_win_write(win, VOP2_WIN_AFBC_HALF_BLOCK_EN, half_block_en);
> +
> if (afbc_en) {
> u32 stride;
>
> @@ -1283,13 +1300,7 @@ static void vop2_plane_atomic_update(struct drm_plane
> *plane,
> vop2_win_write(win, VOP2_WIN_AFBC_UV_SWAP, uv_swap);
> vop2_win_write(win, VOP2_WIN_AFBC_AUTO_GATING_EN, 0);
> vop2_win_write(win, VOP2_WIN_AFBC_BLOCK_SPLIT_EN, 0);
> - if (pstate->rotation & (DRM_MODE_ROTATE_270 |
> DRM_MODE_ROTATE_90)) {
> - vop2_win_write(win, VOP2_WIN_AFBC_HALF_BLOCK_EN, 0);
> - transform_offset = vop2_afbc_transform_offset(pstate,
> false);
> - } else {
> - vop2_win_write(win, VOP2_WIN_AFBC_HALF_BLOCK_EN, 1);
> - transform_offset = vop2_afbc_transform_offset(pstate,
> true);
> - }
> + transform_offset = vop2_afbc_transform_offset(pstate,
> half_block_en);
> vop2_win_write(win, VOP2_WIN_AFBC_HDR_PTR, yrgb_mst);
> vop2_win_write(win, VOP2_WIN_AFBC_PIC_SIZE, act_info);
> vop2_win_write(win, VOP2_WIN_AFBC_TRANSFORM_OFFSET,
> transform_offset);
> --
> 2.34.1
>
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v2 04/12] drm/rockchip: vop2: clear afbc en and transform bit for cluster window at linear mode
On Wed, Nov 22, 2023 at 08:54:25PM +0800, Andy Yan wrote:
> From: Andy Yan
>
> The enable bit and transform offset of cluster windows should be
> cleared when it work at linear mode, or we may have a iommu fault
> issue.
>
> Signed-off-by: Andy Yan
Reviewed-by: Sascha Hauer
Sascha
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index 639dfebc6bd1..a019cc9bbd54 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -1312,6 +1312,11 @@ static void vop2_plane_atomic_update(struct drm_plane
> *plane,
> vop2_win_write(win, VOP2_WIN_AFBC_ROTATE_270, rotate_270);
> vop2_win_write(win, VOP2_WIN_AFBC_ROTATE_90, rotate_90);
> } else {
> + if (vop2_cluster_window(win)) {
> + vop2_win_write(win, VOP2_WIN_AFBC_ENABLE, 0);
> + vop2_win_write(win, VOP2_WIN_AFBC_TRANSFORM_OFFSET, 0);
> + }
> +
> vop2_win_write(win, VOP2_WIN_YRGB_VIR,
> DIV_ROUND_UP(fb->pitches[0], 4));
> }
>
> --
> 2.34.1
>
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
