Re: [RESEND PATCH v2 4/6] dt-bindings: display: simple: add Rocktech RK043FN48H
On 6/7/23 08:31, Dario Binacchi wrote: > Add compatible to panel-simple for Rocktech Displays Limited > RK043FN48H 4.3" 480x272 LCD-TFT panel. > > Signed-off-by: Dario Binacchi > Acked-by: Conor Dooley Reviewed-by: Raphael Gallais-Pou Thanks, Raphaël
Re: [PATCH 0/5] drm/ssd130x: A few enhancements and cleanups
Thomas Zimmermann writes: Hello Thomas, > Hi Javierm, > > I've read through the patches and they look correct to me. > > Reviewed-by: Thomas Zimmermann > Thanks a lot for your review! > But I had one question about the page size. You round up to multiples of > page_size in several places. That could lead to an out-of-bounds access. > Do you need to allocate GEM buffers to be multiples of page_size as well? > That's a good point and I would need to have a closer look to the driver to determine if that's needed or not as well. If that's the case though, the issue is already present in the driver. We could fix it as follow-up. > Best regards > Thomas > -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
[PATCH] drm/ingenic: Kconfig: select REGMAP and REGMAP_MMIO
Otherwise its failed to pass basic compile test on platform without REGMAP_MMIO selected by defconfig make -j$(nproc) ARCH=mips CROSS_COMPILE=mips64el-linux-gnuabi64- SYNCinclude/config/auto.conf.cmd Checking missing-syscalls for N32 CALLscripts/checksyscalls.sh Checking missing-syscalls for O32 CALLscripts/checksyscalls.sh CALLscripts/checksyscalls.sh MODPOST Module.symvers ERROR: modpost: "__devm_regmap_init_mmio_clk" [drivers/gpu/drm/ingenic/ingenic-drm.ko] undefined! make[1]: *** [scripts/Makefile.modpost:136: Module.symvers] Error 1 make: *** [Makefile:1978: modpost] Error 2 Signed-off-by: Sui Jingfeng --- drivers/gpu/drm/ingenic/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig index a53f475d33df..7457c0b65034 100644 --- a/drivers/gpu/drm/ingenic/Kconfig +++ b/drivers/gpu/drm/ingenic/Kconfig @@ -5,6 +5,8 @@ config DRM_INGENIC depends on CMA depends on OF depends on COMMON_CLK + select REGMAP + select REGMAP_MMIO select DRM_BRIDGE select DRM_PANEL_BRIDGE select DRM_KMS_HELPER -- 2.25.1
Re: [PATCH 01/30] backlight/bd6107: Compare against struct fb_info.device
Thomas Zimmermann writes: > Struct bd6107_platform_data refers to a platform device within > the Linux device hierarchy. The test in bd6107_backlight_check_fb() > compares it against the fbdev device in struct fb_info.dev, which > is different. Fix the test by comparing to struct fb_info.device. > > Fixes a bug in the backlight driver and prepares fbdev for making > struct fb_info.dev optional. > > Signed-off-by: Thomas Zimmermann > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 01/30] backlight/bd6107: Compare against struct fb_info.device
Thomas Zimmermann writes: > Struct bd6107_platform_data refers to a platform device within > the Linux device hierarchy. The test in bd6107_backlight_check_fb() > compares it against the fbdev device in struct fb_info.dev, which > is different. Fix the test by comparing to struct fb_info.device. > > Fixes a bug in the backlight driver and prepares fbdev for making > struct fb_info.dev optional. > > Signed-off-by: Thomas Zimmermann > Cc: Lee Jones > Cc: Daniel Thompson > Cc: Jingoo Han > --- I agree with what was discussed in this thread, the check fix and rename could be split in separate patches to make it easier to understand what is changed. Regardless, feel free to add: Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 1/9] dt-bindings: display: Add yamls for JH7110 display subsystem
On 02/06/2023 09:40, Keith Zhao wrote:
> Add bindings for JH7110 display subsystem which
> has a display controller verisilicon dc8200
> and an HDMI interface.
>
> Signed-off-by: Keith Zhao
> ---
> .../display/verisilicon/starfive-hdmi.yaml| 93 +++
> .../display/verisilicon/verisilicon-dc.yaml | 110 ++
> .../display/verisilicon/verisilicon-drm.yaml | 42 +++
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> MAINTAINERS | 7 ++
> 5 files changed, 254 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/verisilicon/verisilicon-drm.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml
> b/Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml
> new file mode 100644
> index ..c30b7954a355
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml
Filename matching compatible.
> @@ -0,0 +1,93 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/verisilicon/starfive-hdmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: StarFive HDMI transmiter
> +
> +description:
> + The StarFive SoC uses the HDMI signal transmiter based on innosilicon IP
> + to generate HDMI signal from its input and transmit the signal to the
> screen.
> +
> +maintainers:
> + - Keith Zhao
> + - ShengYang Chen
> +
> +properties:
> + compatible:
> +const: starfive,hdmi
Conor already commented on this.
> +
> + reg:
> +minItems: 1
> +
> + interrupts:
> +items:
> + - description: The HDMI hot plug detection interrupt.
> +
> + clocks:
> +items:
> + - description: System clock of HDMI module.
> + - description: Mclk clock of HDMI audio.
> + - description: Bclk clock of HDMI audio.
> + - description: Pixel clock generated by HDMI module.
> +
> + clock-names:
> +items:
> + - const: sysclk
> + - const: mclk
> + - const: bclk
> + - const: pclk
> +
> + resets:
> +items:
> + - description: Reset for HDMI module.
> +
> + reset-names:
> +items:
> + - const: hdmi_tx
> +
> + '#sound-dai-cells':
> +const: 0
> +
> + port:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> + Port node with one endpoint connected to a display connector node.
One port, so how do you get data? From where does it come?
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - resets
> + - reset-names
> + - '#sound-dai-cells'
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +hdmi: hdmi@2959 {
> + compatible = "starfive,hdmi";
> + reg = <0x2959 0x4000>;
> + interrupts = <99>;
> + clocks = <&voutcrg 17>,
> + <&voutcrg 15>,
> + <&voutcrg 16>,
> + <&hdmitx0_pixelclk>;
> + clock-names = "sysclk", "mclk","bclk","pclk";
> + resets = <&voutcrg 9>;
> + reset-names = "hdmi_tx";
> + #sound-dai-cells = <0>;
> + hdmi_in: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + hdmi_input: endpoint@0 {
> +reg = <0>;
> +remote-endpoint = <&dc_out_dpi0>;
Mixed up indentation.
> + };
> + };
> +};
> diff --git
> a/Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml
> b/Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml
> new file mode 100644
> index ..1322502c4cde
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml
Same problem.
> @@ -0,0 +1,110 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/verisilicon/verisilicon-dc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: StarFive display controller
> +
> +description:
> + The StarFive SoC uses the display controller based on Verisilicon IP
> + to transfer the image data from a video memory
> + buffer to an external LCD interface.
> +
> +maintainers:
> + - Keith Zhao
> + - ShengYang Chen
> +
> +properties:
> + compatible:
> +const: verisilicon,dc8200
> +
> + reg:
> +maxItems: 3
> +
> + interrupts:
> +items:
> + - description: The interrupt will be generated when DC finish one frame
> +
> + clocks:
> +items:
> + - description: Clock for display system noc bus.
> + - description: Pixel clock for display channel 0.
> + - description: Pixel clock for display channel 1.
> + - description: Clock
Re: [PATCH 03/30] backlight/lv5207lp: Compare against struct fb_info.device
Thomas Zimmermann writes: > Struct lv5207lp_platform_data refers to a platform device within > the Linux device hierarchy. The test in lv5207lp_backlight_check_fb() > compares it against the fbdev device in struct fb_info.dev, which > is different. Fix the test by comparing to struct fb_info.device. > > Fixes a bug in the backlight driver and prepares fbdev for making > struct fb_info.dev optional. > Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 04/30] fbdev/atyfb: Reorder backlight and framebuffer init/cleanup
Thomas Zimmermann writes: > The driver's backlight code requires the framebuffer to be > registered. Therefore reorder the init and cleanup calls for > both data structures. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 2/9] riscv: dts: starfive: jh7110: add dc&hdmi controller node
On 02/06/2023 09:40, Keith Zhao wrote:
> Add the dc controller and hdmi node for the Starfive JH7110 SoC.
>
> Signed-off-by: Keith Zhao
> ---
> .../jh7110-starfive-visionfive-2.dtsi | 87 +++
> arch/riscv/boot/dts/starfive/jh7110.dtsi | 46 ++
> 2 files changed, 133 insertions(+)
>
> diff --git a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
> b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
> index 1155b97b593d..8dc6c8a15c59 100644
> --- a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
> +++ b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
> @@ -31,6 +31,21 @@ memory@4000 {
> reg = <0x0 0x4000 0x1 0x0>;
> };
>
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + linux,cma {
> + compatible = "shared-dma-pool";
> + reusable;
> + size = <0x0 0x2000>;
> + alignment = <0x0 0x1000>;
> + alloc-ranges = <0x0 0x8000 0x0 0x2000>;
> + linux,cma-default;
> + };
> + };
> +
> gpio-restart {
> compatible = "gpio-restart";
> gpios = <&sysgpio 35 GPIO_ACTIVE_HIGH>;
> @@ -214,6 +229,41 @@ GPOEN_DISABLE,
> slew-rate = <0>;
> };
> };
> +
> + hdmi_pins: hdmi-0 {
> + hdmi-scl-pins {
> + pinmux = + GPOEN_SYS_HDMI_DDC_SCL,
> + GPI_SYS_HDMI_DDC_SCL)>;
> + input-enable;
> + bias-pull-up;
> + };
> +
> + hdmi-sda-pins {
> + pinmux = + GPOEN_SYS_HDMI_DDC_SDA,
> + GPI_SYS_HDMI_DDC_SDA)>;
> + input-enable;
> + bias-pull-up;
> + };
> +
> + hdmi-cec-pins {
> + pinmux = + GPOEN_SYS_HDMI_CEC_SDA,
> + GPI_SYS_HDMI_CEC_SDA)>;
> + input-enable;
> + bias-pull-up;
> + };
> +
> + hdmi-hpd-pins {
> + pinmux = + GPOEN_ENABLE,
> + GPI_SYS_HDMI_HPD)>;
> + input-enable;
> + bias-disable; /* external pull-up */
> + };
> + };
> +
> };
>
> &uart0 {
> @@ -221,3 +271,40 @@ &uart0 {
> pinctrl-0 = <&uart0_pins>;
> status = "okay";
> };
> +
> +&voutcrg {
> + status = "okay";
> +};
> +
> +&display {
> + status = "okay";
> +};
> +
> +&hdmi {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&hdmi_pins>;
> +
> + hdmi_in: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + hdmi_input: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&dc_out_dpi0>;
This does not make any sense. You wrote in bindings that this is display
output, but you call it HDMI input. If this is input, where is your output?
> + };
> + };
> +};
> +
> +&dc8200 {
> + status = "okay";
> +
> + dc_out: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + dc_out_dpi0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&hdmi_input>;
> + };
> +
Stray blank line.
> + };
> +};
> diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi
> b/arch/riscv/boot/dts/starfive/jh7110.dtsi
> index 9acb5fb1716d..66be6e65a066 100644
> --- a/arch/riscv/boot/dts/starfive/jh7110.dtsi
> +++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi
> @@ -249,6 +249,11 @@ tdm_ext: tdm-ext-clock {
> #clock-cells = <0>;
> };
>
> + display: display-subsystem {
> + compatible = "verisilicon,display-subsystem";
Drop fake nodes which do not represent hardware. Instead, DTS and
bindings should describe real hardware.
> + ports = <&dc_out>;
> + };
> +
> soc {
> compatible = "simple-bus";
> interrupt-parent = <&plic>;
> @@ -570,5 +575,46 @@ voutcrg: clock-controller@295c {
> #reset-cells = <1>;
> power-domains = <&pwrc JH7110_PD_VOUT>;
> };
> +
> + dc8200: dc8200@2940 {
Node names should be generic. See also explanation and list of examples
in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
> + compa
Re: [PATCH 05/30] fbdev/atyfb: Use hardware device as backlight parent
Thomas Zimmermann writes: > Use the hardware device in struct fb_info.device as parent of the > backlight device. Aligns the driver with the rest of the codebase > and prepares fbdev for making struct fb_info.dev optional. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 06/30] fbdev/aty128fb: Reorder backlight and framebuffer init/cleanup
Thomas Zimmermann writes: > The driver's backlight code requires the framebuffer to be > registered. Therefore reorder the init and cleanup calls for > both data structures. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH v2] drm/i915: Fix a VMA UAF for multi-gt platform
On 6/6/2023 10:56 PM, Andi Shyti wrote:
Hi Nirmoy,
On Tue, Jun 06, 2023 at 10:27:55PM +0200, Nirmoy Das wrote:
Ensure correct handling of closed VMAs on multi-gt platforms to prevent
Use-After-Free. Currently, when GT0 goes idle, closed VMAs that are
exclusively added to GT0's closed_vma link (gt->closed_vma) and
subsequently freed by i915_vma_parked(), which assumes the entire GPU is
idle. However, on platforms with multiple GTs, such as MTL, GT1 may
remain active while GT0 is idle. This causes GT0 to mistakenly consider
the closed VMAs in its closed_vma list as unnecessary, potentially
leading to Use-After-Free issues if a job for GT1 attempts to access a
freed VMA.
Although we do take a wakeref for GT0 but it happens later, after
evaluating VMAs. To mitigate this, it is necessary to hold a GT0 wakeref
early.
v2: Use gt id to detect multi-tile(Andi)
Fix the incorrect error path.
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Thomas Hellström
Cc: Chris Wilson
Cc: Andi Shyti
Cc: Andrzej Hajda
Cc: Sushma Venkatesh Reddy
Tested-by: Andi Shyti
Signed-off-by: Nirmoy Das
I wonder if we need any Fixes tag here, maybe this:
Fixes: d93939730347 ("drm/i915: Remove the vma refcount")
No, vma refcount is not enough unfortunately. Issue is i915_vma_parked()
expects only one GT.
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 3aeede6aee4d..c2a67435acfa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2683,6 +2683,7 @@ static int
eb_select_engine(struct i915_execbuffer *eb)
{
struct intel_context *ce, *child;
+ struct intel_gt *gt;
unsigned int idx;
int err;
@@ -2706,10 +2707,16 @@ eb_select_engine(struct i915_execbuffer *eb)
}
}
eb->num_batches = ce->parallel.number_children + 1;
+ gt = ce->engine->gt;
for_each_child(ce, child)
intel_context_get(child);
intel_gt_pm_get(ce->engine->gt);
+ /* Keep GT0 active on MTL so that i915_vma_parked() doesn't
+* free VMAs while execbuf ioctl is validating VMAs.
+*/
+ if (gt->info.id)
+ intel_gt_pm_get(to_gt(gt->i915));
if (!test_bit(CONTEXT_ALLOC_BIT, &ce->flags)) {
err = intel_context_alloc_state(ce);
@@ -2748,6 +2755,9 @@ eb_select_engine(struct i915_execbuffer *eb)
return err;
err:
+ if (gt->info.id)
+ intel_gt_pm_put(to_gt(gt->i915));
+
intel_gt_pm_put(ce->engine->gt);
for_each_child(ce, child)
intel_context_put(child);
@@ -2761,6 +2771,8 @@ eb_put_engine(struct i915_execbuffer *eb)
struct intel_context *child;
i915_vm_put(eb->context->vm);
+ if (eb->gt->info.id)
+ intel_gt_pm_put(to_gt(eb->gt->i915));
intel_gt_pm_put(eb->gt);
I would add a comment up here, just not to scare people when they
see this.
I can add a comment pairing comment mentioning
eb_select_engine().
Reviewed-by: Andi Shyti
Thanks,
Nirmoy
Andi
for_each_child(eb->context, child)
intel_context_put(child);
--
2.39.0
Re: [PATCH v2] drm/i915: Fix a VMA UAF for multi-gt platform
On 6/7/2023 8:20 AM, Andrzej Hajda wrote:
On 06.06.2023 22:27, Nirmoy Das wrote:
Ensure correct handling of closed VMAs on multi-gt platforms to prevent
Use-After-Free. Currently, when GT0 goes idle, closed VMAs that are
exclusively added to GT0's closed_vma link (gt->closed_vma) and
subsequently freed by i915_vma_parked(), which assumes the entire GPU is
idle. However, on platforms with multiple GTs, such as MTL, GT1 may
remain active while GT0 is idle. This causes GT0 to mistakenly consider
the closed VMAs in its closed_vma list as unnecessary, potentially
leading to Use-After-Free issues if a job for GT1 attempts to access a
freed VMA.
Although we do take a wakeref for GT0 but it happens later, after
evaluating VMAs. To mitigate this, it is necessary to hold a GT0 wakeref
early.
v2: Use gt id to detect multi-tile(Andi)
Fix the incorrect error path.
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Thomas Hellström
Cc: Chris Wilson
Cc: Andi Shyti
Cc: Andrzej Hajda
Cc: Sushma Venkatesh Reddy
Tested-by: Andi Shyti
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 3aeede6aee4d..c2a67435acfa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2683,6 +2683,7 @@ static int
eb_select_engine(struct i915_execbuffer *eb)
{
struct intel_context *ce, *child;
+ struct intel_gt *gt;
unsigned int idx;
int err;
@@ -2706,10 +2707,16 @@ eb_select_engine(struct i915_execbuffer *eb)
}
}
eb->num_batches = ce->parallel.number_children + 1;
+ gt = ce->engine->gt;
for_each_child(ce, child)
intel_context_get(child);
intel_gt_pm_get(ce->engine->gt);
intel_gt_pm_get(gt)
+ /* Keep GT0 active on MTL so that i915_vma_parked() doesn't
+ * free VMAs while execbuf ioctl is validating VMAs.
+ */
+ if (gt->info.id)
+ intel_gt_pm_get(to_gt(gt->i915));
if (!test_bit(CONTEXT_ALLOC_BIT, &ce->flags)) {
err = intel_context_alloc_state(ce);
@@ -2748,6 +2755,9 @@ eb_select_engine(struct i915_execbuffer *eb)
return err;
err:
+ if (gt->info.id)
+ intel_gt_pm_put(to_gt(gt->i915));
+
intel_gt_pm_put(ce->engine->gt);
intel_gt_pm_put(gt)
Will change both.
Reviewed-by: Andrzej Hajda
Thanks,
Nirmoy
Regards
Andrzej
for_each_child(ce, child)
intel_context_put(child);
@@ -2761,6 +2771,8 @@ eb_put_engine(struct i915_execbuffer *eb)
struct intel_context *child;
i915_vm_put(eb->context->vm);
+ if (eb->gt->info.id)
+ intel_gt_pm_put(to_gt(eb->gt->i915));
intel_gt_pm_put(eb->gt);
for_each_child(eb->context, child)
intel_context_put(child);
Re: [PATCH 07/30] fbdev/aty128fb: Use hardware device as backlight parent
Thomas Zimmermann writes: > Use the hardware device in struct fb_info.device as parent of the > backlight device. Aligns the driver with the rest of the codebase > and prepares fbdev for making struct fb_info.dev optional. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 08/30] fbdev/broadsheetfb: Call device_remove_file() with hardware device
Thomas Zimmermann writes: > Call device_remove_file() with the same device that has been used > for device_create_file(), which is the hardware device stored in > struct fb_info.device. Prepares fbdev for making struct fb_info.dev > optional. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
[PATCH v3] drm/i915: Fix a VMA UAF for multi-gt platform
Ensure correct handling of closed VMAs on multi-gt platforms to prevent
Use-After-Free. Currently, when GT0 goes idle, closed VMAs that are
exclusively added to GT0's closed_vma link (gt->closed_vma) and
subsequently freed by i915_vma_parked(), which assumes the entire GPU is
idle. However, on platforms with multiple GTs, such as MTL, GT1 may
remain active while GT0 is idle. This causes GT0 to mistakenly consider
the closed VMAs in its closed_vma list as unnecessary, potentially
leading to Use-After-Free issues if a job for GT1 attempts to access a
freed VMA.
Although we do take a wakeref for GT0 but it happens later, after
evaluating VMAs. To mitigate this, it is necessary to hold a GT0 wakeref
early.
v2: Use gt id to detect multi-tile(Andi)
Fix the incorrect error path.
v3: Add more comment(Andi)
Use the new gt var when possible(Andrzej)
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Thomas Hellström
Cc: Chris Wilson
Cc: Andi Shyti
Cc: Andrzej Hajda
Cc: Sushma Venkatesh Reddy
Signed-off-by: Nirmoy Das
Tested-by: Andi Shyti
Reviewed-by: Andi Shyti
Reviewed-by: Andrzej Hajda
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 21 +--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 5fb459ea4294..1de9de1e4782 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2692,6 +2692,7 @@ static int
eb_select_engine(struct i915_execbuffer *eb)
{
struct intel_context *ce, *child;
+ struct intel_gt *gt;
unsigned int idx;
int err;
@@ -2715,10 +2716,17 @@ eb_select_engine(struct i915_execbuffer *eb)
}
}
eb->num_batches = ce->parallel.number_children + 1;
+ gt = ce->engine->gt;
for_each_child(ce, child)
intel_context_get(child);
- intel_gt_pm_get(ce->engine->gt);
+ intel_gt_pm_get(gt);
+ /*
+* Keep GT0 active on MTL so that i915_vma_parked() doesn't
+* free VMAs while execbuf ioctl is validating VMAs.
+*/
+ if (gt->info.id)
+ intel_gt_pm_get(to_gt(gt->i915));
if (!test_bit(CONTEXT_ALLOC_BIT, &ce->flags)) {
err = intel_context_alloc_state(ce);
@@ -2757,7 +2765,10 @@ eb_select_engine(struct i915_execbuffer *eb)
return err;
err:
- intel_gt_pm_put(ce->engine->gt);
+ if (gt->info.id)
+ intel_gt_pm_put(to_gt(gt->i915));
+
+ intel_gt_pm_put(gt);
for_each_child(ce, child)
intel_context_put(child);
intel_context_put(ce);
@@ -2770,6 +2781,12 @@ eb_put_engine(struct i915_execbuffer *eb)
struct intel_context *child;
i915_vm_put(eb->context->vm);
+ /*
+* This works in conjunction with eb_select_engine() to prevent
+* i915_vma_parked() from interfering while execbuf validates vmas.
+*/
+ if (eb->gt->info.id)
+ intel_gt_pm_put(to_gt(eb->gt->i915));
intel_gt_pm_put(eb->gt);
for_each_child(eb->context, child)
intel_context_put(child);
--
2.39.0
Re: [PATCH v9 8/8] drm: Remove usage of deprecated DRM_DEBUG_KMS
On Wed, 07 Jun 2023, Laurent Pinchart wrote:
> Hi Jani,
>
> On Wed, Jun 07, 2023 at 12:39:44AM +0300, Jani Nikula wrote:
>> On Tue, 06 Jun 2023, Laurent Pinchart wrote:
>> > On Tue, Jun 06, 2023 at 04:15:22PM +0530, Siddh Raman Pant wrote:
>> >> @@ -777,7 +793,7 @@ int drm_client_modeset_probe(struct drm_client_dev
>> >> *client, unsigned int width,
>> >> int i, ret = 0;
>> >> bool *enabled;
>> >>
>> >> - DRM_DEBUG_KMS("\n");
>> >> + drm_dbg_kms(dev, "\n");
>> >
>> > This message is pretty useless, it could be dropped on top of this
>> > series.
>>
>> They do debug log the function being called.
>
> I overlooked the fact that ___drm_dbg() prints the caller's function
> name using __builtin_return_address(). It thus has marginally more value
> than I thought. Still, function tracing is best performed with ftrace().
I'm not going to argue this one too much, but it can be quite a step
getting a random bug reporter from providing dmesgs to running ftrace.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
Re: (subset) [RESEND PATCH v2 0/6] Add display support on the stm32f746-disco board
Hi, On Wed, 07 Jun 2023 08:31:33 +0200, Dario Binacchi wrote: > The series adds support for the display on the stm32f746-disco board, > along with a generic patch that adds the "bpp" parameter to the stm-drm > module. The intention is to allow users to size, within certain limits, > the memory footprint required by the framebuffer. > > Changes in v2: > - Add 'Acked-by' tag of Conor Dooley. > - Fix build warning reported by kernel test robot. > - Add 'Reported-by' tag of kernel test robot. > > [...] Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next) [4/6] dt-bindings: display: simple: add Rocktech RK043FN48H https://cgit.freedesktop.org/drm/drm-misc/commit/?id=c42a37a27c777d63961dd634a30f7c887949491a [5/6] drm/panel: simple: add support for Rocktech RK043FN48H panel https://cgit.freedesktop.org/drm/drm-misc/commit/?id=13cdd12a9f934158f4ec817cf048fcb4384aa9dc -- Neil
Re: [PATCH 00/30] fbdev: Make userspace interfaces optional
Hi Thomas,
Thanks for your series!
Over the past few days, I have been giving this some thought, that's
why I am replying only now...
On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann wrote:
> Add the new config option FB_DEVICE. If enabled, fbdev provides
> traditional userspace interfaces in devfs, sysfs and procfs, such
> as /dev/fb0 or /proc/fb.
>
> Modern Linux distrobutions have adopted DRM drivers for graphics
> output and use fbdev only for the kernel's framebuffer console.
> Userspace has also moved on, with no new fbdev code being written
> and existing support being removed.
>
> OTOH, fbdev provides userspace a way of accessing kernel or I/O
> memory, which might compromise the system's security. See the recent
True, in some form...
The amount of "kernel memory" that can be accessed is controlled by
the fbdev driver (or by the DRM fbdev emulation). Nothing unsafe here.
The I/O memory that can be accessed (if any) is controlled by the
fbdev driver, and the full capabilities (e.g. DMA to random addresses)
exported depend on the actual hardware.
> commit c8687694bb1f ("drm/fbdev-generic: prohibit potential
> out-of-bounds access") for an example. Disabling fbdev userspace
IMHO that's not a good example for the point you're trying to make,
but merely bad bounds checking in kernel copying code...
> interfaces is therefore a useful feature to limit unecessary
> exposure of fbdev code to processes of low privilegues.
This actually depends on the permissions on /dev/fb*...
BTW, I am wondering if it would be possible to write a DRM emulation
layer on top of (basic, e.g. no MMIO, just fb) fbdev?
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 1/9] dt-bindings: display: Add yamls for JH7110 display subsystem
Am Mittwoch, 7. Juni 2023, 00:37:53 CEST schrieb Conor Dooley: > On Wed, Jun 07, 2023 at 12:22:33AM +0200, Heiko Stübner wrote: > > Am Dienstag, 6. Juni 2023, 20:41:17 CEST schrieb Shengyu Qu: > > > > On Fri, Jun 02, 2023 at 03:40:35PM +0800, Keith Zhao wrote: > > > >> Add bindings for JH7110 display subsystem which > > > >> has a display controller verisilicon dc8200 > > > >> and an HDMI interface. > > > > >> +description: > > > >> + The StarFive SoC uses the HDMI signal transmiter based on > > > >> innosilicon IP > > > > Is innosilicon the same thing as verisilicon? Also > > > > s/transmiter/transmitter/, both here and in the title. > > > > > > I think that is not the same, I remember Rockchip has used a HDMI > > > transmitter from > > > > > > Innosilicon, and there is a existing driver for that in mainline. > > > > Yep, I think Innosilicon is the company you turn to when you want to save > > a bit of money ;-) . In the bigger SoCs Rockchip most of the time uses > > Designware hdmi blocks and looking at the history only the rk3036 ever > > used an Innosilicon block. > > > > Looking at the history, 2016 really was a long time ago :-D. > > > > > So Keith, if that's true, I think it is better to seperate the HDMI > > > stuff and reuse existing driver. > > > > I'm not so sure about that - at least from a cursory glance :-) . > > > > The registers do look slightly different and I don't know how much > > the IP changed between the rk3036-version and the jh7110 version. > > > > At the very least, I know my rk3036 board isn't booting right now, so > > I can't really provide help for generalizing the rockchip-driver. > > > > At the very least both the binding and driver could drop the "starfive-hdmi" > > and actually use the Innosilicon in the naming somewhere, so that it's > > clear for future developers :-) > > Seeing "based on" always makes me a little bit nervous to be honest when > it comes to using a compatible from the IP. Is it the IP? What version > is it? etc. Perhaps "starfive,jh7110-hdmi" & falling back to some sort > of "innosilicon,hdmi" would be more future/IP-silliness proof. > Driver can always be generic & bind against "innosilicon,hdmi" until > that becomes impossible. what Connor said makes a lot of sense. Just name the compatible after the actual implementation - aka "starfive,jh7110-hdmi" . This is similar to what the rk3036 does with its "rockchip,rk3036-inno-hdmi". That way you're nicely independent and future proof. Heiko
Re: PROBLEM: AMD Ryzen 9 7950X iGPU - Blinking Issue
Hi Guys, so I checked, the kernel I am running has this commit (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git /commit/?id=08da182175db4c7f80850354849d95f2670e8cd9) applied already! https://github.com/ju6ge/linux/commit/917680e6056aa288cac288d3afd2745d372beb61u And the bug of display flickering persists with or without the amdgpu.sg_display=0 variable applied! Kind regards, Felix Richter On 6/5/23 16:11, Alex Deucher wrote: + Hamza This is a known issue. You can workaround it by setting amdgpu.sg_display=0. It should be issue should be fixed in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=08da182175db4c7f80850354849d95f2670e8cd9 Alex Now if this is the desired long term fix I do not know … Kind regards, Felix Richter On 02.05.23 16:12, Linux regression tracking (Thorsten Leemhuis) wrote: On 02.05.23 15:48, Felix Richter wrote: On 5/2/23 15:34, Linux regression tracking (Thorsten Leemhuis) wrote: On 02.05.23 15:13, Alex Deucher wrote: On Tue, May 2, 2023 at 7:45 AM Linux regression tracking (Thorsten Leemhuis) wrote: On 30.04.23 13:44, Felix Richter wrote: Hi, I am running into an issue with the integrated GPU of the Ryzen 9 7950X. It seems to be a regression from kernel version 6.1 to 6.2. The bug materializes in from of my monitor blinking, meaning it turns full white shortly. This happens very often so that the system becomes unpleasant to use. I am running the Archlinux Kernel: The Issue happens on the bleeding edge kernel: 6.2.13 Switching back to the LTS kernel resolves the issue: 6.1.26 I have two monitors attached to the system. One 42 inch 4k Display and a 24 inch 1080p Display and am running sway as my desktop. Let me know if there is more information I could provide to help narrow down the issue. Thanks for the report. To be sure the issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression tracking bot: #regzbot ^introduced v6.1..v6.2 #regzbot title drm: amdgpu: system becomes unpleasant to use after monitor starts blinking and turns full white #regzbot ignore-activity This isn't a regression? This issue or a fix for it are already discussed somewhere else? It was fixed already? You want to clarify when the regression started to happen? Or point out I got the title or something else totally wrong? Then just reply and tell me -- ideally while also telling regzbot about it, as explained by the page listed in the footer of this mail. Developers: When fixing the issue, remember to add 'Link:' tags pointing to the report (the parent of this mail). See page linked in footer for details. This sounds exactly like the issue that was fixed in this patch which is already on it's way to Linus: https://gitlab.freedesktop.org/agd5f/linux/-/commit/08da182175db4c7f80850354849d95f2670e8cd9 FWIW, you in the flood of emails likely missed that this is the same thread where you yesterday replied "If the module parameter didn't help then perhaps you are seeing some other issue. Can you bisect?". That's why I decided to add this to the tracking. Or am I missing something obvious here? /me looks around again and can't see anything, but that doesn't have to mean anything... Felix, btw, this guide might help you with the bisection, even if it's just for kernel compilation: https://docs.kernel.org/next/admin-guide/quickly-build-trimmed-linux.html And to indirectly reply to your mail from yesterday[1]. You might want to ignore the arch linux kernel git repo and just do a bisection between 6.1 and the latest 6.2.y kernel using upstream repos; and if I were you I'd also try 6.3 or even mainline before that, in case the issue was fixed already. [1] https://lore.kernel.org/all/04749ee4-0728-92fe-bcb0-a7320279e...@felixrichter.tech/ Thanks for the pointers, I'll do a bisection on my desktop from 6.1 to the newest commit. FWIW, I wonder what you actually mean with "newest commit" here: a bisection between 6.1 and mainline HEAD might be a waste of time, *if* this is something that only happens in 6.2.y (say due to a broken or incomplete backport) That was the part I was mostly unsure about … where to start from. I was planning to use PKGBUILD scripts from arch to achieve the same configuration as I would when installing the package and just rewrite the script to use a local copy of the source code instead of the repository. That way I can just use the bisect command, rebuild the package and test again. In my experience trying to deal with Linux distro's package managers creates more trouble than it's worth. But I probably won't be able to finish it this week, since I am on vacation starting tomorrow and will not have access to the computer in question. I will be back next week, by that time the patch Alex is talking about might already be in mainline. So if that fixes it, I will notice and let you know. If not I will do the bisection to figure out what the actual issue is. Enjoy
[PATCH v9 1/8] Revert "drm: mipi-dsi: Convert logging to drm_* functions."
This reverts commit 1040e424353f5f4d39f6f3aa8723eb3bd6ea6446.
It used an incorrect way to use drm_* functions. Only drm_device ptrs
should be passed, but the mentioned commit passed mipi_dsi_host ptr.
It worked by accident due to macro magic.
Reported-by: Jani Nikula
Reviewed-by: Jani Nikula
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_mipi_dsi.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 3fd6c733ff4e..a37af4edf394 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -33,7 +33,6 @@
#include
#include
-#include
#include
@@ -156,18 +155,19 @@ static int mipi_dsi_device_add(struct mipi_dsi_device
*dsi)
static struct mipi_dsi_device *
of_mipi_dsi_device_add(struct mipi_dsi_host *host, struct device_node *node)
{
+ struct device *dev = host->dev;
struct mipi_dsi_device_info info = { };
int ret;
u32 reg;
if (of_alias_from_compatible(node, info.type, sizeof(info.type)) < 0) {
- drm_err(host, "modalias failure on %pOF\n", node);
+ dev_err(dev, "modalias failure on %pOF\n", node);
return ERR_PTR(-EINVAL);
}
ret = of_property_read_u32(node, "reg", ®);
if (ret) {
- drm_err(host, "device node %pOF has no valid reg property:
%d\n",
+ dev_err(dev, "device node %pOF has no valid reg property: %d\n",
node, ret);
return ERR_PTR(-EINVAL);
}
@@ -202,21 +202,22 @@ mipi_dsi_device_register_full(struct mipi_dsi_host *host,
const struct mipi_dsi_device_info *info)
{
struct mipi_dsi_device *dsi;
+ struct device *dev = host->dev;
int ret;
if (!info) {
- drm_err(host, "invalid mipi_dsi_device_info pointer\n");
+ dev_err(dev, "invalid mipi_dsi_device_info pointer\n");
return ERR_PTR(-EINVAL);
}
if (info->channel > 3) {
- drm_err(host, "invalid virtual channel: %u\n", info->channel);
+ dev_err(dev, "invalid virtual channel: %u\n", info->channel);
return ERR_PTR(-EINVAL);
}
dsi = mipi_dsi_device_alloc(host);
if (IS_ERR(dsi)) {
- drm_err(host, "failed to allocate DSI device %ld\n",
+ dev_err(dev, "failed to allocate DSI device %ld\n",
PTR_ERR(dsi));
return dsi;
}
@@ -227,7 +228,7 @@ mipi_dsi_device_register_full(struct mipi_dsi_host *host,
ret = mipi_dsi_device_add(dsi);
if (ret) {
- drm_err(host, "failed to add DSI device %d\n", ret);
+ dev_err(dev, "failed to add DSI device %d\n", ret);
kfree(dsi);
return ERR_PTR(ret);
}
--
2.39.2
Re: [PATCH v9 8/8] drm: Remove usage of deprecated DRM_DEBUG_KMS
On Tue, 06 Jun 2023 20:34:19 +0530, Laurent Pinchart wrote:
> Hi Siddh,
>
> Thank you for the patch.
Anytime :)
> > - DRM_DEBUG_KMS("\n");
> > + drm_dbg_kms(dev, "\n");
>
> This message is pretty useless, it could be dropped on top of this
> series.
Okay.
> > - DRM_DEBUG_KMS("\n");
> > + drm_dbg_kms(NULL, "\n");
>
> Same.
Okay.
> > - DRM_DEBUG_KMS("\n");
> > + drm_dbg_kms(&dbidev->drm, "\n");
>
> Same.
Okay.
> With the commit subject fixed,
>
> Reviewed-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com>
Thanks,
Siddh
[PATCH v10 7/9] drm: Remove usage of deprecated DRM_DEBUG_DRIVER in DRM core
drm_print.h says DRM_DEBUG_DRIVER is deprecated.
Thus, use newer drm_dbg_driver().
Also fix the deprecation comment in drm_print.h which
mentions drm_dbg() instead of drm_dbg_driver().
Reviewed-by: Laurent Pinchart
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_mipi_dbi.c | 10 +-
include/drm/drm_print.h| 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 58ff9503a403..ab5dd5933a1a 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -70,11 +70,11 @@
#define MIPI_DBI_DEBUG_COMMAND(cmd, data, len) \
({ \
if (!len) \
- DRM_DEBUG_DRIVER("cmd=%02x\n", cmd); \
+ drm_dbg_driver(NULL, "cmd=%02x\n", cmd); \
else if (len <= 32) \
- DRM_DEBUG_DRIVER("cmd=%02x, par=%*ph\n", cmd, (int)len, data);\
+ drm_dbg_driver(NULL, "cmd=%02x, par=%*ph\n", cmd, (int)len,
data);\
else \
- DRM_DEBUG_DRIVER("cmd=%02x, len=%zu\n", cmd, len); \
+ drm_dbg_driver(NULL, "cmd=%02x, len=%zu\n", cmd, len); \
})
static const u8 mipi_dbi_dcs_read_commands[] = {
@@ -708,7 +708,7 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *dbi)
DCS_POWER_MODE_DISPLAY_NORMAL_MODE | DCS_POWER_MODE_SLEEP_MODE))
return false;
- DRM_DEBUG_DRIVER("Display is ON\n");
+ drm_dbg_driver(NULL, "Display is ON\n");
return true;
}
@@ -1256,7 +1256,7 @@ int mipi_dbi_spi_init(struct spi_device *spi, struct
mipi_dbi *dbi,
mutex_init(&dbi->cmdlock);
- DRM_DEBUG_DRIVER("SPI speed: %uMHz\n", spi->max_speed_hz / 100);
+ drm_dbg_driver(NULL, "SPI speed: %uMHz\n", spi->max_speed_hz / 100);
return 0;
}
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 4b8532cf2ae6..2bac5e8fd550 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -589,7 +589,7 @@ void __drm_err(const char *format, ...);
#define DRM_DEBUG(fmt, ...)\
__drm_dbg(DRM_UT_CORE, fmt, ##__VA_ARGS__)
-/* NOTE: this is deprecated in favor of drm_dbg(NULL, ...). */
+/* NOTE: this is deprecated in favor of drm_dbg_driver(NULL, ...). */
#define DRM_DEBUG_DRIVER(fmt, ...) \
__drm_dbg(DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
--
2.39.2
Re: [PATCH v9 0/8] drm: Remove usage of deprecated DRM_* macros
On Tue, 06 Jun 2023 23:19:28 +0530, Laurent Pinchart wrote: > The idea would be to include the drm_print_deprecated.h header in > drivers that still use the deprecated macros. Yeah, what I meant was in a "first pass" kind of sense. > > Not every file can be seen at a case-by-case basis or by coccinelle > > as far as I understand its usage. Consider the following: > > > > DRM_INFO is used on line 210 of amd/amdgpu/amdgpu_acpi.c, but the > > file does not even include drm_print.h directly. It includes the > > amdgpu.h header, which includes the amdgpu_ring.h header, which > > finally has the "#include " line. > > > > If a simple find and replace has to be done, then that can be added > > at the end of the series. > > Maybe a simple grep for the deprecated macros would be enough to > identify all the files that still use them ? Hmm, so the drm_print_deprecated.h should be included individually on all the files, regardless of whether they include drm_print.h directly or not? Actually that makes sense, so further inclusion of top-level header would not automatically include the deprecated macros. Since this needs some thought, I will be sending v10 without this. This change can be sent later separately, as it will anyways be a huge patch, and 10 is already a big enough revision number. Thanks, Siddh
[PATCH v10 5/9] drm: Remove usage of deprecated DRM_ERROR in DRM core
drm_print.h says DRM_ERROR is deprecated in favor of drm_err().
Reviewed-by: Laurent Pinchart
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_bridge.c | 8
drivers/gpu/drm/drm_bufs.c | 8
drivers/gpu/drm/drm_client_modeset.c | 4 ++--
drivers/gpu/drm/drm_context.c| 4 ++--
drivers/gpu/drm/drm_crtc_helper.c| 8
drivers/gpu/drm/drm_debugfs_crc.c| 3 ++-
drivers/gpu/drm/drm_drv.c| 16
drivers/gpu/drm/drm_flip_work.c | 2 +-
drivers/gpu/drm/drm_framebuffer.c| 3 ++-
drivers/gpu/drm/drm_gem.c| 2 +-
drivers/gpu/drm/drm_gem_dma_helper.c | 2 +-
drivers/gpu/drm/drm_hashtab.c| 4 ++--
drivers/gpu/drm/drm_lock.c | 16
drivers/gpu/drm/drm_mipi_dbi.c | 2 +-
drivers/gpu/drm/drm_mm.c | 8
drivers/gpu/drm/drm_mode_config.c| 2 +-
drivers/gpu/drm/drm_modes.c | 26 +-
drivers/gpu/drm/drm_modeset_helper.c | 2 +-
drivers/gpu/drm/drm_plane.c | 2 +-
drivers/gpu/drm/drm_scatter.c| 9 +
drivers/gpu/drm/drm_vm.c | 2 +-
21 files changed, 68 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index c3d69af02e79..3d27f08db74d 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -351,11 +351,11 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct
drm_bridge *bridge,
list_del(&bridge->chain_node);
#ifdef CONFIG_OF
- DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n",
- bridge->of_node, encoder->name, ret);
+ drm_err(encoder->dev, "failed to attach bridge %pOF to encoder %s:
%d\n",
+ bridge->of_node, encoder->name, ret);
#else
- DRM_ERROR("failed to attach bridge to encoder %s: %d\n",
- encoder->name, ret);
+ drm_err(encoder->dev, "failed to attach bridge to encoder %s: %d\n",
+ encoder->name, ret);
#endif
return ret;
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 86700560fea2..aa66fe16ea6e 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -1470,15 +1470,15 @@ int drm_legacy_freebufs(struct drm_device *dev, void
*data,
if (copy_from_user(&idx, &request->list[i], sizeof(idx)))
return -EFAULT;
if (idx < 0 || idx >= dma->buf_count) {
- DRM_ERROR("Index %d (of %d max)\n",
- idx, dma->buf_count - 1);
+ drm_err(dev, "Index %d (of %d max)\n",
+ idx, dma->buf_count - 1);
return -EINVAL;
}
idx = array_index_nospec(idx, dma->buf_count);
buf = dma->buflist[idx];
if (buf->file_priv != file_priv) {
- DRM_ERROR("Process %d freeing buffer not owned\n",
- task_pid_nr(current));
+ drm_err(dev, "Process %d freeing buffer not owned\n",
+ task_pid_nr(current));
return -EINVAL;
}
drm_legacy_free_buffer(dev, buf);
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index ae19734974b5..e2403b8c6347 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -808,7 +808,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client,
unsigned int width,
offsets = kcalloc(connector_count, sizeof(*offsets), GFP_KERNEL);
enabled = kcalloc(connector_count, sizeof(bool), GFP_KERNEL);
if (!crtcs || !modes || !enabled || !offsets) {
- DRM_ERROR("Memory allocation failed\n");
+ drm_err(client->dev, "Memory allocation failed\n");
ret = -ENOMEM;
goto out;
}
@@ -832,7 +832,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client,
unsigned int width,
offsets, enabled, width, height)
&&
!drm_client_target_preferred(connectors, connector_count,
modes,
offsets, enabled, width,
height))
- DRM_ERROR("Unable to find initial modes\n");
+ drm_err(client->dev, "Unable to find initial modes\n");
DRM_DEBUG_KMS("picking CRTCs for %dx%d config\n",
width, height);
diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
index a0fc779e5e1e..bf1fc8bb97de 100644
--- a/drivers/gpu/drm/drm_context.c
+++ b/drivers/gpu/drm/drm_context.c
@@ -270,7 +270,7 @@ int drm_legacy_setsareactx(struct drm_device *dev, void
*data,
static int drm_context_switch(struct dr
Re: [PATCH v9 6/8] drm: Remove usage of deprecated DRM_DEBUG
On Tue, 06 Jun 2023 20:27:06 +0530, Laurent Pinchart wrote:
> Hi Siddh,
>
> Thank you for the patch.
Anytime :)
> > if (!ctx_entry) {
> > - DRM_DEBUG("out of memory\n");
> > + drm_dbg_core(dev, "out of memory\n");
>
> This message could also be dropped.
Okay.
> > - DRM_DEBUG("\n");
> > + drm_dbg_core(dev, "\n");
>
> This message seems of dubious value :-) Maybe you could drop it in a
> patch on top of this series ?
Okay.
> > - DRM_DEBUG("\n");
> > + drm_dbg_core(NULL, "\n");
>
> This is even worse :-) The next two messages are also fairly useless,
> they should be expanded, or dropped.
Okay.
> > - DRM_DEBUG("\n");
> > + drm_dbg_core(dev, "\n");
>
> Ditto.
Okay.
> > + drm_dbg_core(dev, "\n");
> > +
>
> Same, and the two messages below too.
Okay.
> > - DRM_DEBUG("\n");
> > + drm_dbg_core(dev, "\n");
>
> Here too.
Okay.
> With the commit subject fixed,
>
> Reviewed-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com>
Thanks,
Siddh
[PATCH v9 5/8] drm: Remove usage of deprecated DRM_ERROR
drm_print.h says DRM_ERROR is deprecated in favor of drm_err().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_bridge.c | 8
drivers/gpu/drm/drm_bufs.c | 8
drivers/gpu/drm/drm_client_modeset.c | 4 ++--
drivers/gpu/drm/drm_context.c| 4 ++--
drivers/gpu/drm/drm_crtc_helper.c| 8
drivers/gpu/drm/drm_debugfs_crc.c| 3 ++-
drivers/gpu/drm/drm_drv.c| 16
drivers/gpu/drm/drm_flip_work.c | 2 +-
drivers/gpu/drm/drm_framebuffer.c| 3 ++-
drivers/gpu/drm/drm_gem.c| 2 +-
drivers/gpu/drm/drm_gem_dma_helper.c | 2 +-
drivers/gpu/drm/drm_hashtab.c| 4 ++--
drivers/gpu/drm/drm_lock.c | 16
drivers/gpu/drm/drm_mipi_dbi.c | 2 +-
drivers/gpu/drm/drm_mm.c | 8
drivers/gpu/drm/drm_mode_config.c| 2 +-
drivers/gpu/drm/drm_modes.c | 26 +-
drivers/gpu/drm/drm_modeset_helper.c | 2 +-
drivers/gpu/drm/drm_plane.c | 2 +-
drivers/gpu/drm/drm_scatter.c| 9 +
drivers/gpu/drm/drm_vm.c | 2 +-
21 files changed, 68 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index c3d69af02e79..3d27f08db74d 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -351,11 +351,11 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct
drm_bridge *bridge,
list_del(&bridge->chain_node);
#ifdef CONFIG_OF
- DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n",
- bridge->of_node, encoder->name, ret);
+ drm_err(encoder->dev, "failed to attach bridge %pOF to encoder %s:
%d\n",
+ bridge->of_node, encoder->name, ret);
#else
- DRM_ERROR("failed to attach bridge to encoder %s: %d\n",
- encoder->name, ret);
+ drm_err(encoder->dev, "failed to attach bridge to encoder %s: %d\n",
+ encoder->name, ret);
#endif
return ret;
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 86700560fea2..aa66fe16ea6e 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -1470,15 +1470,15 @@ int drm_legacy_freebufs(struct drm_device *dev, void
*data,
if (copy_from_user(&idx, &request->list[i], sizeof(idx)))
return -EFAULT;
if (idx < 0 || idx >= dma->buf_count) {
- DRM_ERROR("Index %d (of %d max)\n",
- idx, dma->buf_count - 1);
+ drm_err(dev, "Index %d (of %d max)\n",
+ idx, dma->buf_count - 1);
return -EINVAL;
}
idx = array_index_nospec(idx, dma->buf_count);
buf = dma->buflist[idx];
if (buf->file_priv != file_priv) {
- DRM_ERROR("Process %d freeing buffer not owned\n",
- task_pid_nr(current));
+ drm_err(dev, "Process %d freeing buffer not owned\n",
+ task_pid_nr(current));
return -EINVAL;
}
drm_legacy_free_buffer(dev, buf);
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index ae19734974b5..e2403b8c6347 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -808,7 +808,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client,
unsigned int width,
offsets = kcalloc(connector_count, sizeof(*offsets), GFP_KERNEL);
enabled = kcalloc(connector_count, sizeof(bool), GFP_KERNEL);
if (!crtcs || !modes || !enabled || !offsets) {
- DRM_ERROR("Memory allocation failed\n");
+ drm_err(client->dev, "Memory allocation failed\n");
ret = -ENOMEM;
goto out;
}
@@ -832,7 +832,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client,
unsigned int width,
offsets, enabled, width, height)
&&
!drm_client_target_preferred(connectors, connector_count,
modes,
offsets, enabled, width,
height))
- DRM_ERROR("Unable to find initial modes\n");
+ drm_err(client->dev, "Unable to find initial modes\n");
DRM_DEBUG_KMS("picking CRTCs for %dx%d config\n",
width, height);
diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
index a0fc779e5e1e..bf1fc8bb97de 100644
--- a/drivers/gpu/drm/drm_context.c
+++ b/drivers/gpu/drm/drm_context.c
@@ -270,7 +270,7 @@ int drm_legacy_setsareactx(struct drm_device *dev, void
*data,
static int drm_context_switch(struct drm_device * dev, int old, int ne
[PATCH v9 3/8] drm: Remove usage of deprecated DRM_INFO
drm_print.h says DRM_INFO is deprecated in favor of drm_info().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_client_modeset.c | 2 +-
drivers/gpu/drm/drm_connector.c | 7 ---
drivers/gpu/drm/drm_drv.c| 2 +-
drivers/gpu/drm/drm_pci.c| 2 +-
4 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 1b12a3c201a3..ae19734974b5 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -331,7 +331,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
DRM_DEBUG_KMS("can clone using 1024x768\n");
return true;
}
- DRM_INFO("kms: can't enable cloning when we probably wanted to.\n");
+ drm_info(dev, "kms: can't enable cloning when we probably wanted
to.\n");
return false;
}
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 48df7a5ea503..dca8dd4ab93f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -168,13 +168,14 @@ static void drm_connector_get_cmdline_mode(struct
drm_connector *connector)
return;
if (mode->force) {
- DRM_INFO("forcing %s connector %s\n", connector->name,
-drm_get_connector_force_name(mode->force));
+ drm_info(connector->dev, "forcing %s connector %s\n",
+connector->name,
drm_get_connector_force_name(mode->force));
connector->force = mode->force;
}
if (mode->panel_orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN) {
- DRM_INFO("cmdline forces connector %s panel_orientation to
%d\n",
+ drm_info(connector->dev,
+"cmdline forces connector %s panel_orientation to
%d\n",
connector->name, mode->panel_orientation);
drm_connector_set_panel_orientation(connector,
mode->panel_orientation);
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 12687dd9e1ac..02eaa4c9344d 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -943,7 +943,7 @@ int drm_dev_register(struct drm_device *dev, unsigned long
flags)
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_register_all(dev);
- DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
+ drm_info(dev, "Initialized %s %d.%d.%d %s for %s on minor %d\n",
driver->name, driver->major, driver->minor,
driver->patchlevel, driver->date,
dev->dev ? dev_name(dev->dev) : "virtual device",
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 39d35fc3a43b..7dfb837d1325 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -262,7 +262,7 @@ void drm_legacy_pci_exit(const struct drm_driver *driver,
}
mutex_unlock(&legacy_dev_list_lock);
}
- DRM_INFO("Module unloaded\n");
+ drm_info(NULL, "Module unloaded\n");
}
EXPORT_SYMBOL(drm_legacy_pci_exit);
--
2.39.2
[PATCH v10 8/9] drm: Remove usage of deprecated DRM_DEBUG_KMS in DRM core
drm_print.h says DRM_DEBUG_KMS is deprecated in favor of
drm_dbg_kms().
Reviewed-by: Laurent Pinchart
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_client_modeset.c | 112 +++
drivers/gpu/drm/drm_color_mgmt.c | 4 +-
drivers/gpu/drm/drm_connector.c | 21 ++---
drivers/gpu/drm/drm_crtc.c | 36 -
drivers/gpu/drm/drm_crtc_helper.c| 54 ++---
drivers/gpu/drm/drm_debugfs_crc.c| 5 +-
drivers/gpu/drm/drm_displayid.c | 4 +-
drivers/gpu/drm/drm_edid.c | 17 ++--
drivers/gpu/drm/drm_lease.c | 2 +-
drivers/gpu/drm/drm_mipi_dbi.c | 7 +-
drivers/gpu/drm/drm_modes.c | 10 +--
drivers/gpu/drm/drm_plane.c | 32
drivers/gpu/drm/drm_probe_helper.c | 39 +-
drivers/gpu/drm/drm_rect.c | 4 +-
drivers/gpu/drm/drm_sysfs.c | 8 +-
15 files changed, 187 insertions(+), 168 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index e2403b8c6347..4e08ae688b83 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -242,8 +242,9 @@ static void drm_client_connectors_enabled(struct
drm_connector **connectors,
for (i = 0; i < connector_count; i++) {
connector = connectors[i];
enabled[i] = drm_connector_enabled(connector, true);
- DRM_DEBUG_KMS("connector %d enabled? %s\n", connector->base.id,
- connector->display_info.non_desktop ? "non
desktop" : str_yes_no(enabled[i]));
+ drm_dbg_kms(connector->dev, "connector %d enabled? %s\n",
+ connector->base.id,
+ connector->display_info.non_desktop ? "non desktop"
: str_yes_no(enabled[i]));
any_enabled |= enabled[i];
}
@@ -303,7 +304,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
}
if (can_clone) {
- DRM_DEBUG_KMS("can clone using command line\n");
+ drm_dbg_kms(dev, "can clone using command line\n");
return true;
}
@@ -328,7 +329,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
}
if (can_clone) {
- DRM_DEBUG_KMS("can clone using 1024x768\n");
+ drm_dbg_kms(dev, "can clone using 1024x768\n");
return true;
}
drm_info(dev, "kms: can't enable cloning when we probably wanted
to.\n");
@@ -352,8 +353,9 @@ static int drm_client_get_tile_offsets(struct drm_connector
**connectors,
continue;
if (!modes[i] && (h_idx || v_idx)) {
- DRM_DEBUG_KMS("no modes for connector tiled %d %d\n", i,
- connector->base.id);
+ drm_dbg_kms(connector->dev,
+ "no modes for connector tiled %d %d\n",
+ i, connector->base.id);
continue;
}
if (connector->tile_h_loc < h_idx)
@@ -364,7 +366,8 @@ static int drm_client_get_tile_offsets(struct drm_connector
**connectors,
}
offsets[idx].x = hoffset;
offsets[idx].y = voffset;
- DRM_DEBUG_KMS("returned %d %d for %d %d\n", hoffset, voffset, h_idx,
v_idx);
+ drm_dbg_kms(NULL, "returned %d %d for %d %d\n",
+ hoffset, voffset, h_idx, v_idx);
return 0;
}
@@ -421,14 +424,16 @@ static bool drm_client_target_preferred(struct
drm_connector **connectors,
drm_client_get_tile_offsets(connectors,
connector_count, modes, offsets, i,
connector->tile_h_loc,
connector->tile_v_loc);
}
- DRM_DEBUG_KMS("looking for cmdline mode on connector %d\n",
- connector->base.id);
+ drm_dbg_kms(connector->dev,
+ "looking for cmdline mode on connector %d\n",
+ connector->base.id);
/* got for command line mode first */
modes[i] = drm_connector_pick_cmdline_mode(connector);
if (!modes[i]) {
- DRM_DEBUG_KMS("looking for preferred mode on connector
%d %d\n",
- connector->base.id, connector->tile_group
? connector->tile_group->id : 0);
+ drm_dbg_kms(connector->dev,
+ "looking for preferred mode on connector %d
%d\n",
+ connector->base.id, connector->tile_group ?
connector->tile_group->id : 0);
modes[i] = drm_connector_has_preferred_mode(connector,
width, height);
}
/* No preferred modes, pick one off the list */
@@ -450,16 +455
Re: [Freedreno] [PATCH v3 5/7] drm/msm/dsi: Add configuration for MSM8226
On 6/1/2023 10:00 AM, Luca Weiss wrote:
Add the config for the v1.0.2 DSI found on MSM8226. We can reuse
existing bits from other revisions that are identical for v1.0.2.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Konrad Dybcio
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 ++
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 29ccd755cc2e..8a5fb6df7210 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -245,6 +245,8 @@ static const struct msm_dsi_cfg_handler dsi_cfg_handlers[]
= {
&apq8064_dsi_cfg, &msm_dsi_v2_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0,
&msm8974_apq8084_dsi_cfg, &msm_dsi_6g_host_ops},
+ {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0_2,
+ &msm8974_apq8084_dsi_cfg, &msm_dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1,
&msm8974_apq8084_dsi_cfg, &msm_dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1_1,
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
index 91bdaf50bb1a..43f0dd74edb6 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -11,6 +11,7 @@
#define MSM_DSI_VER_MAJOR_V2 0x02
#define MSM_DSI_VER_MAJOR_6G 0x03
#define MSM_DSI_6G_VER_MINOR_V1_0 0x1000
+#define MSM_DSI_6G_VER_MINOR_V1_0_20x1002
#define MSM_DSI_6G_VER_MINOR_V1_1 0x1001
#define MSM_DSI_6G_VER_MINOR_V1_1_1 0x10010001
#define MSM_DSI_6G_VER_MINOR_V1_2 0x1002
Reviewed-by: Jeykumar Sankaran
Re: [PATCH v9 0/8] drm: Remove usage of deprecated DRM_* macros
On Tue, 06 Jun 2023 20:35:45 +0530, Laurent Pinchart wrote: > This is a nice series, thank you for working on that. > > Now that the deprecated macros are used in drivers only, would it make > sense to move them to a drm_print_deprecated.h header, to make sure no > new driver uses them ? Sure, but then should that header be included wherever drm_print.h is included with a find and replace, to avoid breakage? Not every file can be seen at a case-by-case basis or by coccinelle as far as I understand its usage. Consider the following: DRM_INFO is used on line 210 of amd/amdgpu/amdgpu_acpi.c, but the file does not even include drm_print.h directly. It includes the amdgpu.h header, which includes the amdgpu_ring.h header, which finally has the "#include " line. If a simple find and replace has to be done, then that can be added at the end of the series. Thanks, Siddh
[PATCH v9 8/8] drm: Remove usage of deprecated DRM_DEBUG_KMS
drm_print.h says DRM_DEBUG_KMS is deprecated in favor of
drm_dbg_kms().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_client_modeset.c | 112 +++
drivers/gpu/drm/drm_color_mgmt.c | 4 +-
drivers/gpu/drm/drm_connector.c | 21 ++---
drivers/gpu/drm/drm_crtc.c | 36 -
drivers/gpu/drm/drm_crtc_helper.c| 54 ++---
drivers/gpu/drm/drm_debugfs_crc.c| 5 +-
drivers/gpu/drm/drm_displayid.c | 4 +-
drivers/gpu/drm/drm_edid.c | 17 ++--
drivers/gpu/drm/drm_lease.c | 2 +-
drivers/gpu/drm/drm_mipi_dbi.c | 7 +-
drivers/gpu/drm/drm_modes.c | 10 +--
drivers/gpu/drm/drm_plane.c | 32
drivers/gpu/drm/drm_probe_helper.c | 39 +-
drivers/gpu/drm/drm_rect.c | 4 +-
drivers/gpu/drm/drm_sysfs.c | 8 +-
15 files changed, 187 insertions(+), 168 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index e2403b8c6347..4e08ae688b83 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -242,8 +242,9 @@ static void drm_client_connectors_enabled(struct
drm_connector **connectors,
for (i = 0; i < connector_count; i++) {
connector = connectors[i];
enabled[i] = drm_connector_enabled(connector, true);
- DRM_DEBUG_KMS("connector %d enabled? %s\n", connector->base.id,
- connector->display_info.non_desktop ? "non
desktop" : str_yes_no(enabled[i]));
+ drm_dbg_kms(connector->dev, "connector %d enabled? %s\n",
+ connector->base.id,
+ connector->display_info.non_desktop ? "non desktop"
: str_yes_no(enabled[i]));
any_enabled |= enabled[i];
}
@@ -303,7 +304,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
}
if (can_clone) {
- DRM_DEBUG_KMS("can clone using command line\n");
+ drm_dbg_kms(dev, "can clone using command line\n");
return true;
}
@@ -328,7 +329,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
}
if (can_clone) {
- DRM_DEBUG_KMS("can clone using 1024x768\n");
+ drm_dbg_kms(dev, "can clone using 1024x768\n");
return true;
}
drm_info(dev, "kms: can't enable cloning when we probably wanted
to.\n");
@@ -352,8 +353,9 @@ static int drm_client_get_tile_offsets(struct drm_connector
**connectors,
continue;
if (!modes[i] && (h_idx || v_idx)) {
- DRM_DEBUG_KMS("no modes for connector tiled %d %d\n", i,
- connector->base.id);
+ drm_dbg_kms(connector->dev,
+ "no modes for connector tiled %d %d\n",
+ i, connector->base.id);
continue;
}
if (connector->tile_h_loc < h_idx)
@@ -364,7 +366,8 @@ static int drm_client_get_tile_offsets(struct drm_connector
**connectors,
}
offsets[idx].x = hoffset;
offsets[idx].y = voffset;
- DRM_DEBUG_KMS("returned %d %d for %d %d\n", hoffset, voffset, h_idx,
v_idx);
+ drm_dbg_kms(NULL, "returned %d %d for %d %d\n",
+ hoffset, voffset, h_idx, v_idx);
return 0;
}
@@ -421,14 +424,16 @@ static bool drm_client_target_preferred(struct
drm_connector **connectors,
drm_client_get_tile_offsets(connectors,
connector_count, modes, offsets, i,
connector->tile_h_loc,
connector->tile_v_loc);
}
- DRM_DEBUG_KMS("looking for cmdline mode on connector %d\n",
- connector->base.id);
+ drm_dbg_kms(connector->dev,
+ "looking for cmdline mode on connector %d\n",
+ connector->base.id);
/* got for command line mode first */
modes[i] = drm_connector_pick_cmdline_mode(connector);
if (!modes[i]) {
- DRM_DEBUG_KMS("looking for preferred mode on connector
%d %d\n",
- connector->base.id, connector->tile_group
? connector->tile_group->id : 0);
+ drm_dbg_kms(connector->dev,
+ "looking for preferred mode on connector %d
%d\n",
+ connector->base.id, connector->tile_group ?
connector->tile_group->id : 0);
modes[i] = drm_connector_has_preferred_mode(connector,
width, height);
}
/* No preferred modes, pick one off the list */
@@ -450,16 +455,17 @@ static bool drm_client_t
Re: [PATCH v9 3/8] drm: Remove usage of deprecated DRM_INFO
On Tue, 06 Jun 2023 19:53:22 +0530, Laurent Pinchart wrote: > Hi Siddh, > > Thank you for the patch. Anytime :) > Any plan to remove it from drivers as well ? If not you should mention > in the commit message (probably in the subject line itself) that you're > only addressing the DRM core. > > Same comment for further patches in this series. Yeah, this patch set aims to replace just in drm core (as mentioned in the cover). I thought "drm" would suffice since I did not specify a specific driver like i915. So the subject line should say "drm core: ..."? Thanks, Siddh
Re: [PATCH 1/9] dt-bindings: display: Add yamls for JH7110 display subsystem
Hi Conor, Hey Keith, On Fri, Jun 02, 2023 at 03:40:35PM +0800, Keith Zhao wrote: Add bindings for JH7110 display subsystem which has a display controller verisilicon dc8200 and an HDMI interface. Signed-off-by: Keith Zhao --- .../display/verisilicon/starfive-hdmi.yaml| 93 +++ .../display/verisilicon/verisilicon-dc.yaml | 110 ++ .../display/verisilicon/verisilicon-drm.yaml | 42 +++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 7 ++ 5 files changed, 254 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml create mode 100644 Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml create mode 100644 Documentation/devicetree/bindings/display/verisilicon/verisilicon-drm.yaml diff --git a/Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml b/Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml new file mode 100644 index ..c30b7954a355 --- /dev/null +++ b/Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml @@ -0,0 +1,93 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/verisilicon/starfive-hdmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive HDMI transmiter + +description: + The StarFive SoC uses the HDMI signal transmiter based on innosilicon IP Is innosilicon the same thing as verisilicon? Also s/transmiter/transmitter/, both here and in the title. I think that is not the same, I remember Rockchip has used a HDMI transmitter from Innosilicon, and there is a existing driver for that in mainline. So Keith, if that's true, I think it is better to seperate the HDMI stuff and reuse existing driver. Best regards, Shengyu + to generate HDMI signal from its input and transmit the signal to the screen. + +maintainers: + - Keith Zhao + - ShengYang Chen + +properties: + compatible: +const: starfive,hdmi Is this going to work on every SoC that StarFive has ever & will ever make? Please use soc-based compatibles ;) + + reg: +minItems: 1 + + interrupts: +items: + - description: The HDMI hot plug detection interrupt. + + clocks: +items: + - description: System clock of HDMI module. + - description: Mclk clock of HDMI audio. + - description: Bclk clock of HDMI audio. + - description: Pixel clock generated by HDMI module. + + clock-names: +items: + - const: sysclk + - const: mclk + - const: bclk + - const: pclk + + resets: +items: + - description: Reset for HDMI module. + + reset-names: +items: + - const: hdmi_tx You only have one item here, you don't need the "items: - const:", "const:" alone will do. diff --git a/Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml b/Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml new file mode 100644 index ..1322502c4cde --- /dev/null +++ b/Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml @@ -0,0 +1,110 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/verisilicon/verisilicon-dc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive display controller + +description: + The StarFive SoC uses the display controller based on Verisilicon IP + to transfer the image data from a video memory + buffer to an external LCD interface. Is it based on Verisilicon IP, or is it exactly that verisilicon IP? I ask because... +maintainers: + - Keith Zhao + - ShengYang Chen + +properties: + compatible: +const: verisilicon,dc8200 ...the compatible is the verisilicon IP. I would be a lot happier if the compatibles were set yp for something like: "starfive,jh7110-foo", "verisilicon,dc8200" diff --git a/Documentation/devicetree/bindings/display/verisilicon/verisilicon-drm.yaml b/Documentation/devicetree/bindings/display/verisilicon/verisilicon-drm.yaml new file mode 100644 index ..aed8d4af2c55 --- /dev/null +++ b/Documentation/devicetree/bindings/display/verisilicon/verisilicon-drm.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/verisilicon/verisilicon-drm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Verisilicon DRM master device + +maintainers: + - Keith Zhao + - ShengYang Chen + +description: | + The Verisilicon DRM master device is a virtual device needed to list all + display controller or other display interface nodes that comprise the + graphics subsystem. + +properties: + compatible: +const: verisilicon,display-subsystem Same here. diff --git a/Documentation/devicetree/bindin
[PATCH v9 7/8] drm: Remove usage of deprecated DRM_DEBUG_DRIVER
drm_print.h says DRM_DEBUG_DRIVER is deprecated.
Thus, use newer drm_dbg_driver().
Also fix the deprecation comment in drm_print.h which
mentions drm_dbg() instead of drm_dbg_driver().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_mipi_dbi.c | 10 +-
include/drm/drm_print.h| 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 58ff9503a403..ab5dd5933a1a 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -70,11 +70,11 @@
#define MIPI_DBI_DEBUG_COMMAND(cmd, data, len) \
({ \
if (!len) \
- DRM_DEBUG_DRIVER("cmd=%02x\n", cmd); \
+ drm_dbg_driver(NULL, "cmd=%02x\n", cmd); \
else if (len <= 32) \
- DRM_DEBUG_DRIVER("cmd=%02x, par=%*ph\n", cmd, (int)len, data);\
+ drm_dbg_driver(NULL, "cmd=%02x, par=%*ph\n", cmd, (int)len,
data);\
else \
- DRM_DEBUG_DRIVER("cmd=%02x, len=%zu\n", cmd, len); \
+ drm_dbg_driver(NULL, "cmd=%02x, len=%zu\n", cmd, len); \
})
static const u8 mipi_dbi_dcs_read_commands[] = {
@@ -708,7 +708,7 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *dbi)
DCS_POWER_MODE_DISPLAY_NORMAL_MODE | DCS_POWER_MODE_SLEEP_MODE))
return false;
- DRM_DEBUG_DRIVER("Display is ON\n");
+ drm_dbg_driver(NULL, "Display is ON\n");
return true;
}
@@ -1256,7 +1256,7 @@ int mipi_dbi_spi_init(struct spi_device *spi, struct
mipi_dbi *dbi,
mutex_init(&dbi->cmdlock);
- DRM_DEBUG_DRIVER("SPI speed: %uMHz\n", spi->max_speed_hz / 100);
+ drm_dbg_driver(NULL, "SPI speed: %uMHz\n", spi->max_speed_hz / 100);
return 0;
}
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 4b8532cf2ae6..2bac5e8fd550 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -589,7 +589,7 @@ void __drm_err(const char *format, ...);
#define DRM_DEBUG(fmt, ...)\
__drm_dbg(DRM_UT_CORE, fmt, ##__VA_ARGS__)
-/* NOTE: this is deprecated in favor of drm_dbg(NULL, ...). */
+/* NOTE: this is deprecated in favor of drm_dbg_driver(NULL, ...). */
#define DRM_DEBUG_DRIVER(fmt, ...) \
__drm_dbg(DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
--
2.39.2
[PATCH v10 6/9] drm: Remove usage of deprecated DRM_DEBUG in DRM core
drm_print.h says DRM_DEBUG is deprecated in favor of drm_dbg_core().
Reviewed-by: Laurent Pinchart
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_agpsupport.c | 4 +-
drivers/gpu/drm/drm_bufs.c| 114 +++---
drivers/gpu/drm/drm_context.c | 14 ++--
drivers/gpu/drm/drm_dma.c | 10 +--
drivers/gpu/drm/drm_drv.c | 10 +--
drivers/gpu/drm/drm_gem.c | 5 +-
drivers/gpu/drm/drm_hashtab.c | 6 +-
drivers/gpu/drm/drm_irq.c | 4 +-
drivers/gpu/drm/drm_lease.c | 2 +-
drivers/gpu/drm/drm_legacy_misc.c | 4 +-
drivers/gpu/drm/drm_lock.c| 20 +++---
drivers/gpu/drm/drm_mode_object.c | 6 +-
drivers/gpu/drm/drm_pci.c | 12 ++--
drivers/gpu/drm/drm_plane.c | 12 ++--
drivers/gpu/drm/drm_scatter.c | 10 +--
drivers/gpu/drm/drm_syncobj.c | 2 +-
drivers/gpu/drm/drm_sysfs.c | 14 ++--
drivers/gpu/drm/drm_vm.c | 43 ++-
18 files changed, 150 insertions(+), 142 deletions(-)
diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index a4ad6fd13abc..d27686d6e82d 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -315,8 +315,8 @@ int drm_legacy_agp_bind(struct drm_device *dev, struct
drm_agp_binding *request)
if (retcode)
return retcode;
entry->bound = dev->agp->base + (page << PAGE_SHIFT);
- DRM_DEBUG("base = 0x%lx entry->bound = 0x%lx\n",
- dev->agp->base, entry->bound);
+ drm_dbg_core(dev, "base = 0x%lx entry->bound = 0x%lx\n",
+dev->agp->base, entry->bound);
return 0;
}
EXPORT_SYMBOL(drm_legacy_agp_bind);
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index aa66fe16ea6e..a767f51c5369 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -171,8 +171,8 @@ static int drm_addmap_core(struct drm_device *dev,
resource_size_t offset,
kfree(map);
return -EINVAL;
}
- DRM_DEBUG("offset = 0x%08llx, size = 0x%08lx, type = %d\n",
- (unsigned long long)map->offset, map->size, map->type);
+ drm_dbg_core(dev, "offset = 0x%08llx, size = 0x%08lx, type = %d\n",
+(unsigned long long)map->offset, map->size, map->type);
/* page-align _DRM_SHM maps. They are allocated here so there is no
security
* hole created by that and it works around various broken drivers that
use
@@ -205,10 +205,10 @@ static int drm_addmap_core(struct drm_device *dev,
resource_size_t offset,
list = drm_find_matching_map(dev, map);
if (list != NULL) {
if (list->map->size != map->size) {
- DRM_DEBUG("Matching maps of type %d with "
- "mismatched sizes, (%ld vs %ld)\n",
- map->type, map->size,
- list->map->size);
+ drm_dbg_core(dev, "Matching maps of type %d
with "
+"mismatched sizes, (%ld vs %ld)\n",
+map->type, map->size,
+list->map->size);
list->map->size = map->size;
}
@@ -239,9 +239,9 @@ static int drm_addmap_core(struct drm_device *dev,
resource_size_t offset,
list = drm_find_matching_map(dev, map);
if (list != NULL) {
if (list->map->size != map->size) {
- DRM_DEBUG("Matching maps of type %d with "
- "mismatched sizes, (%ld vs %ld)\n",
- map->type, map->size,
list->map->size);
+ drm_dbg_core(dev, "Matching maps of type %d
with "
+"mismatched sizes, (%ld vs %ld)\n",
+map->type, map->size,
list->map->size);
list->map->size = map->size;
}
@@ -250,8 +250,8 @@ static int drm_addmap_core(struct drm_device *dev,
resource_size_t offset,
return 0;
}
map->handle = vmalloc_user(map->size);
- DRM_DEBUG("%lu %d %p\n",
- map->size, order_base_2(map->size), map->handle);
+ drm_dbg_core(dev, "%lu %d %p\n",
+map->size, order_base_2(map->size), map->handle);
if (!map->handle) {
kfree(map);
return -ENOMEM;
@@ -308,8 +308,8 @@ static int drm_addmap_core(struct drm_device *dev,
resource_size_t offset,
kfree(map);
retu
Re: [PATCH v9 5/8] drm: Remove usage of deprecated DRM_ERROR
On Tue, 06 Jun 2023 20:14:52 +0530, Laurent Pinchart wrote:
> Hi Siddh,
>
> Thank you for the patch.
Anytime :)
> > if (!crtcs || !modes || !enabled || !offsets) {
> > - DRM_ERROR("Memory allocation failed\n");
> > + drm_err(client->dev, "Memory allocation failed\n");
>
> We could probably drop this message as memory allocation functions are
> already vocal on failure, but that's a separate fix.
Okay. Should I send a patch at the end of the series removing the
superfluous messages you pointed out in drm core?
> > if (!drm_core_init_complete) {
> > - DRM_ERROR("DRM core is not initialized\n");
> > + drm_err(NULL, "DRM core is not initialized\n");
>
> Could this use dev ?
No, the drm_device's dev pointer is assigned later. See line 621.
> > if (!vma_offset_manager) {
> > - DRM_ERROR("out of memory\n");
> > + drm_err(dev, "out of memory\n");
>
> Same here, I think the message could be dropped.
Okay.
> > if (!ht->table) {
> > - DRM_ERROR("Out of memory for hash table\n");
> > + drm_err(NULL, "Out of memory for hash table\n");
>
> Same.
Okay.
> With the commit message fixed as mentioned in the review of an earlier
> patch in this series, and the issue in drm_dev_init() addressed if
> needed,
>
> Reviewed-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com>
Thanks,
Siddh
[PATCH v9 0/8] drm: Remove usage of deprecated DRM_* macros
This patchset aims to remove usages of deprecated DRM_* macros from the
files residing in drivers/gpu/drm root.
In process, I found out that NULL as first argument of drm_dbg_* wasn't
working, but it was listed as the alternative in deprecation comment,
so I fixed that before removing usages of DRM_DEBUG_* macros.
Courtesy discussion on v1, I added support for NULL in drm_()* macros too.
Courtesy discussion on v7, I removed generic macro stuff meant to accomodate
stuff like mipi_dsi_host, and instead reverted a commit which used the
drm_err() macro incorrectly by passing mipi_dsi_host.
This patchset should be applied in order as changes might be dependent.
Please review and let me know if any errors are there, and hopefully
this gets accepted.
---
v8 -> v9 (today):
- Rebased to drm-misc-next.
v7 -> v8 (28 Feb 2023):
- Reverted 1040e424353f ("drm: mipi-dsi: Convert logging to drm_* functions.")
which used drm_err macro incorrectly by passing mipi_dsi_host.
- Thus, removed _Generic and allow only drm_device.
v6 -> v7 (26 Feb 2023):
- Rebased to drm-misc-next, accounting for the merger of last 3 patches
in the previous series (4665280990fa, fc2602b553c8, 7bd224b6625a),
and 7428ff70a18 ("drm: initialize accel framework").
v5 -> v6 (09 Jan 2023):
- Move drm_device to default case in _Generic as it is the default behaviour.
- Fix incorrect const drm_device handling in _Generic.
- Minor positioning / comment changes.
v4 -> v5 (07 Jan 2023):
- Make separate function instead of using boolean in _Generic (sravn on IRC).
- Also, simplified the Generic macro, and renamed the function and macro.
v3 -> v4 (05 Jan 2023):
- Fix commit message for DRM_NOTE erroneously mentioning DRM_INFO.
- Rebased to drm-misc-next, as 723dad977acd added drm_dbg_core() to some
files.
- Move Generic out to a separate macro __drm_get_dev_ptr, so that interface
of drm_dbg_*() is also same as other drm_*() macros.
- Fix comment in __drm_get_dev_ptr (now ___drm_get_dev_ptr) to use correct
name.
v2 -> v3 (26 Dec 2022):
- Added support for NULL in __drm_printk and thus by extension to drm_()*.
- Thus, converted dropped pr_()* changes to drm_*(NULL, ...).
- Rebased to drm-misc-next and resulting appropriate changes.
v1 (20 Dec 2022) -> v2 (22 Dec 2022):
- Removed conversions to pr_*() in DRM_INFO, DRM_NOTE, and DRM_ERROR changes.
- Due to above, DRM_NOTE usage cannot be removed and the patch is dropped.
- DRY: NULL support is now achieved by way of a separate function.
Siddh Raman Pant (8):
Revert "drm: mipi-dsi: Convert logging to drm_* functions."
drm/print: Fix and add support for NULL as first argument in drm_*
macros
drm: Remove usage of deprecated DRM_INFO
drm: Remove usage of deprecated DRM_NOTE
drm: Remove usage of deprecated DRM_ERROR
drm: Remove usage of deprecated DRM_DEBUG
drm: Remove usage of deprecated DRM_DEBUG_DRIVER
drm: Remove usage of deprecated DRM_DEBUG_KMS
drivers/gpu/drm/drm_agpsupport.c| 4 +-
drivers/gpu/drm/drm_bridge.c| 8 +-
drivers/gpu/drm/drm_bufs.c | 122
drivers/gpu/drm/drm_client_modeset.c| 118 +--
drivers/gpu/drm/drm_color_mgmt.c| 4 +-
drivers/gpu/drm/drm_connector.c | 28 +++---
drivers/gpu/drm/drm_context.c | 18 ++--
drivers/gpu/drm/drm_crtc.c | 36 ---
drivers/gpu/drm/drm_crtc_helper.c | 62 ++--
drivers/gpu/drm/drm_debugfs_crc.c | 8 +-
drivers/gpu/drm/drm_displayid.c | 6 +-
drivers/gpu/drm/drm_dma.c | 10 +-
drivers/gpu/drm/drm_drv.c | 28 +++---
drivers/gpu/drm/drm_edid.c | 17 ++--
drivers/gpu/drm/drm_flip_work.c | 2 +-
drivers/gpu/drm/drm_framebuffer.c | 3 +-
drivers/gpu/drm/drm_gem.c | 7 +-
drivers/gpu/drm/drm_gem_dma_helper.c| 2 +-
drivers/gpu/drm/drm_hashtab.c | 10 +-
drivers/gpu/drm/drm_irq.c | 4 +-
drivers/gpu/drm/drm_kms_helper_common.c | 2 +-
drivers/gpu/drm/drm_lease.c | 4 +-
drivers/gpu/drm/drm_legacy_misc.c | 4 +-
drivers/gpu/drm/drm_lock.c | 36 +++
drivers/gpu/drm/drm_mipi_dbi.c | 19 ++--
drivers/gpu/drm/drm_mipi_dsi.c | 15 +--
drivers/gpu/drm/drm_mm.c| 8 +-
drivers/gpu/drm/drm_mode_config.c | 2 +-
drivers/gpu/drm/drm_mode_object.c | 6 +-
drivers/gpu/drm/drm_modes.c | 36 +++
drivers/gpu/drm/drm_modeset_helper.c| 2 +-
drivers/gpu/drm/drm_pci.c | 14 +--
drivers/gpu/drm/drm_plane.c | 46 -
drivers/gpu/drm/drm_probe_helper.c | 39
drivers/gpu/drm/drm_rect.c | 4 +-
drivers/gpu/drm/drm_scatter.c | 19 ++--
drivers/gpu/drm/drm_syncobj.c | 2 +-
drivers/gpu/drm/drm_sysfs.c | 22 ++---
drivers/gpu/drm/drm_vm.c| 45 +
in
Re: [PATCH 1/9] dt-bindings: display: Add yamls for JH7110 display subsystem
On 2023/6/7 14:41, Maxime Ripard wrote: > On Tue, Jun 06, 2023 at 11:37:53PM +0100, Conor Dooley wrote: >> On Wed, Jun 07, 2023 at 12:22:33AM +0200, Heiko Stübner wrote: >> > Am Dienstag, 6. Juni 2023, 20:41:17 CEST schrieb Shengyu Qu: >> > > > On Fri, Jun 02, 2023 at 03:40:35PM +0800, Keith Zhao wrote: >> > > >> Add bindings for JH7110 display subsystem which >> > > >> has a display controller verisilicon dc8200 >> > > >> and an HDMI interface. >> >> > > >> +description: >> > > >> + The StarFive SoC uses the HDMI signal transmiter based on >> > > >> innosilicon IP >> > > > Is innosilicon the same thing as verisilicon? Also >> > > > s/transmiter/transmitter/, both here and in the title. yes,innosilicon is the HDMI IP and verisilicon is the DC-controller IP >> > > >> > > I think that is not the same, I remember Rockchip has used a HDMI >> > > transmitter from >> > > >> > > Innosilicon, and there is a existing driver for that in mainline. >> > >> > Yep, I think Innosilicon is the company you turn to when you want to save >> > a bit of money ;-) . In the bigger SoCs Rockchip most of the time uses >> > Designware hdmi blocks and looking at the history only the rk3036 ever >> > used an Innosilicon block. >> > I have done a HDMIcomparison of the rk3036 and the jh7110, and they are both based on ip Innosilicon. the hardware of them . Some parts of the hardware of the two are common, such as the logic of hdmi I2C to obtain edid, and the register definition is consistent. Many registers are defined differently from the linux main line inno driver, including registers that contain specific bits and some registers in linux main line inno driver no longer used in my new inoo hdmi hardware. >> > Looking at the history, 2016 really was a long time ago :-D. >> > >> > > So Keith, if that's true, I think it is better to seperate the HDMI >> > > stuff and reuse existing driver. >> > >> > I'm not so sure about that - at least from a cursory glance :-) . >> > >> > The registers do look slightly different and I don't know how much >> > the IP changed between the rk3036-version and the jh7110 version. >> > >> > At the very least, I know my rk3036 board isn't booting right now, so >> > I can't really provide help for generalizing the rockchip-driver. >> > >> > At the very least both the binding and driver could drop the >> > "starfive-hdmi" >> > and actually use the Innosilicon in the naming somewhere, so that it's >> > clear for future developers :-) >> >> Seeing "based on" always makes me a little bit nervous to be honest when >> it comes to using a compatible from the IP. Is it the IP? What version >> is it? etc. Perhaps "starfive,jh7110-hdmi" & falling back to some sort >> of "innosilicon,hdmi" would be more future/IP-silliness proof. >> Driver can always be generic & bind against "innosilicon,hdmi" until >> that becomes impossible. > > Given that Neil was saying that there's at least two > generations/revisions/models of an HDMI controller from Innosilicon, I'm > not sure that compatible is enough to reach that goal anyway. > > Maxime I will change the the binding to meet innosilicon,hdmi . for the drivers part , I will study the possibility of RK-HDMI reuse. Thank you for your comments
[PATCH v10 9/9] drm: Remove superfluous print statements in DRM core
There are a couple of superfluous print statements using the drm_*
macros, which do stuff like printing newlines, print OOM messages
(OOM while allocating memory is already supposed to be noisy), and
printing strings like "Initialised" with no extra info whatsoever.
Thus, remove a couple of these superfluous strings.
Suggested-by: Laurent Pinchart
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_client_modeset.c | 3 ---
drivers/gpu/drm/drm_context.c| 1 -
drivers/gpu/drm/drm_crtc_helper.c| 2 --
drivers/gpu/drm/drm_drv.c| 7 ---
drivers/gpu/drm/drm_file.c | 2 --
drivers/gpu/drm/drm_gem.c| 1 -
drivers/gpu/drm/drm_hashtab.c| 1 -
drivers/gpu/drm/drm_legacy_misc.c| 1 -
drivers/gpu/drm/drm_mipi_dbi.c | 2 --
drivers/gpu/drm/drm_pci.c| 6 --
drivers/gpu/drm/drm_scatter.c| 2 --
11 files changed, 28 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 4e08ae688b83..e241f9aa5a16 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -793,8 +793,6 @@ int drm_client_modeset_probe(struct drm_client_dev *client,
unsigned int width,
int i, ret = 0;
bool *enabled;
- drm_dbg_kms(dev, "\n");
-
if (!width)
width = dev->mode_config.max_width;
if (!height)
@@ -824,7 +822,6 @@ int drm_client_modeset_probe(struct drm_client_dev *client,
unsigned int width,
offsets = kcalloc(connector_count, sizeof(*offsets), GFP_KERNEL);
enabled = kcalloc(connector_count, sizeof(bool), GFP_KERNEL);
if (!crtcs || !modes || !enabled || !offsets) {
- drm_err(client->dev, "Memory allocation failed\n");
ret = -ENOMEM;
goto out;
}
diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
index 8b7b925aee97..c8373294cce0 100644
--- a/drivers/gpu/drm/drm_context.c
+++ b/drivers/gpu/drm/drm_context.c
@@ -382,7 +382,6 @@ int drm_legacy_addctx(struct drm_device *dev, void *data,
ctx_entry = kmalloc(sizeof(*ctx_entry), GFP_KERNEL);
if (!ctx_entry) {
- drm_dbg_core(dev, "out of memory\n");
return -ENOMEM;
}
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 59e7b86eab93..fcf539439880 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -567,8 +567,6 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
int ret;
int i;
- drm_dbg_kms(NULL, "\n");
-
BUG_ON(!set);
BUG_ON(!set->crtc);
BUG_ON(!set->crtc->helper_private);
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 7adf10cc6e67..86b0df358184 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -166,8 +166,6 @@ static int drm_minor_register(struct drm_device *dev,
unsigned int type)
unsigned long flags;
int ret;
- drm_dbg_core(dev, "\n");
-
minor = *drm_minor_get_slot(dev, type);
if (!minor)
return 0;
@@ -422,8 +420,6 @@ void drm_minor_release(struct drm_minor *minor)
*/
void drm_put_dev(struct drm_device *dev)
{
- drm_dbg_core(NULL, "\n");
-
if (!dev) {
drm_err(NULL, "cleanup called no dev\n");
return;
@@ -1030,8 +1026,6 @@ static int drm_stub_open(struct inode *inode, struct file
*filp)
struct drm_minor *minor;
int err;
- drm_dbg_core(NULL, "\n");
-
minor = drm_minor_acquire(iminor(inode));
if (IS_ERR(minor))
return PTR_ERR(minor);
@@ -1099,7 +1093,6 @@ static int __init drm_core_init(void)
drm_core_init_complete = true;
- drm_dbg_core(NULL, "Initialized\n");
return 0;
error:
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 883d83bc0e3d..24c78f7ec101 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -454,8 +454,6 @@ EXPORT_SYMBOL(drm_open);
void drm_lastclose(struct drm_device * dev)
{
- drm_dbg_core(dev, "\n");
-
if (dev->driver->lastclose)
dev->driver->lastclose(dev);
drm_dbg_core(dev, "driver lastclose completed\n");
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 3d88f0483fdf..43326cb4b4f6 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -101,7 +101,6 @@ drm_gem_init(struct drm_device *dev)
vma_offset_manager = drmm_kzalloc(dev, sizeof(*vma_offset_manager),
GFP_KERNEL);
if (!vma_offset_manager) {
- drm_err(dev, "out of memory\n");
return -ENOMEM;
}
diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index 357f20d73b43..acc40d3ebb2a 100644
--- a/drivers/gpu/drm/drm_hashtab.
Re: [PATCH v9 3/8] drm: Remove usage of deprecated DRM_INFO
On Tue, 06 Jun 2023 20:16:25 +0530, Laurent Pinchart wrote: > I would write > > drm: Remove usage of deprecated DRM_INFO in DRM core > > The "drm: " prefix doesn't imply you're touching the core only, you > could do a tree-wide change that also touches all drivers. Okay, will send a v10 with the change after resolving discussions in other emails, if any. Thanks, Siddh
[PATCH v10 2/9] drm/print: Fix and add support for NULL as first argument in drm_* macros
Comments say macros DRM_DEBUG_* are deprecated in favor of
drm_dbg_*(NULL, ...), but they have broken support for it,
as the macro will result in `(NULL) ? (NULL)->dev : NULL`.
Thus, fix them by separating logic to get dev ptr in a new
function, which will return the dev ptr if arg is not NULL.
Use it in drm_dbg_*, and also in __DRM_DEFINE_DBG_RATELIMITED,
where a similar (but correct) NULL check was in place.
Also, add support for NULL in __drm_printk, so that all the
drm_* macros will hence support NULL as the first argument.
This also means that deprecation comments mentioning pr_()*
can now be changed to the drm equivalents.
Reviewed-by: Laurent Pinchart
Signed-off-by: Siddh Raman Pant
---
include/drm/drm_print.h | 79 +++--
1 file changed, 52 insertions(+), 27 deletions(-)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index a93a387f8a1a..4b8532cf2ae6 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -34,6 +34,7 @@
#include
#include
+#include
/* Do *not* use outside of drm_print.[ch]! */
extern unsigned long __drm_debug;
@@ -451,9 +452,32 @@ void __drm_dev_dbg(struct _ddebug *desc, const struct
device *dev,
* Prefer drm_device based logging over device or prink based logging.
*/
+/* Helpers for struct drm_device based logging. */
+
+/**
+ * __drm_dev_ptr - Helper function to get drm->dev pointer.
+ * @drm: struct drm_device pointer.
+ *
+ * RETURNS:
+ * The struct device pointer (NULL if @drm is NULL).
+ */
+static inline struct device *__drm_dev_ptr(const struct drm_device *drm)
+{
+ if (drm)
+ return drm->dev;
+
+ return NULL;
+}
+
/* Helper for struct drm_device based logging. */
#define __drm_printk(drm, level, type, fmt, ...) \
- dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
+({ \
+ struct device *__dev_ = __drm_dev_ptr(drm); \
+ if (__dev_) \
+ dev_##level##type(__dev_, "[drm] " fmt, ##__VA_ARGS__); \
+ else\
+ pr_##level##type("[drm] " fmt, ##__VA_ARGS__); \
+})
#define drm_info(drm, fmt, ...)\
@@ -487,25 +511,25 @@ void __drm_dev_dbg(struct _ddebug *desc, const struct
device *dev,
#define drm_dbg_core(drm, fmt, ...)\
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_CORE, fmt, ##__VA_ARGS__)
-#define drm_dbg_driver(drm, fmt, ...)
\
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt,
##__VA_ARGS__)
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_CORE, fmt, ##__VA_ARGS__)
+#define drm_dbg_driver(drm, fmt, ...) \
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
#define drm_dbg_kms(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__)
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_KMS, fmt, ##__VA_ARGS__)
#define drm_dbg_prime(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_PRIME, fmt, ##__VA_ARGS__)
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_PRIME, fmt, ##__VA_ARGS__)
#define drm_dbg_atomic(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_ATOMIC, fmt,
##__VA_ARGS__)
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_ATOMIC, fmt, ##__VA_ARGS__)
#define drm_dbg_vbl(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_VBL, fmt, ##__VA_ARGS__)
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_VBL, fmt, ##__VA_ARGS__)
#define drm_dbg_state(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_STATE, fmt, ##__VA_ARGS__)
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_STATE, fmt, ##__VA_ARGS__)
#define drm_dbg_lease(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_LEASE, fmt, ##__VA_ARGS__)
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_LEASE, fmt, ##__VA_ARGS__)
#define drm_dbg_dp(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DP, fmt, ##__VA_ARGS__)
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_DP, fmt, ##__VA_ARGS__)
#define drm_dbg_drmres(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRMRES, fmt,
##__VA_ARGS__)
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_DRMRES, fmt, ##__VA_ARGS__)
#define drm_dbg(drm, fmt, ...) drm_dbg_driver(drm, fmt, ##__VA_ARGS__)
@@ -533,31 +557,31 @@ void __drm_err(const char *format,
Re: [PATCH v9 1/8] Revert "drm: mipi-dsi: Convert logging to drm_* functions."
On Tue, 06 Jun 2023 18:25:37 +0530, Laurent Pinchart wrote: > Hi Siddh, > > Thank you for the patch. Anytime :) > Any chance we could prevent this from happening by turning the macros > into inline functions ? The next patch in the series almost does that, with a function introduced as Jani mentioned. The macros will call that function, so if the argument is not drm_device there will be error. Thanks, Siddh
[PATCH v10 4/9] drm: Remove usage of deprecated DRM_NOTE in DRM core
drm_print.h says DRM_NOTE is deprecated in favor of drm_notice().
Reviewed-by: Laurent Pinchart
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_displayid.c | 2 +-
drivers/gpu/drm/drm_kms_helper_common.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_displayid.c b/drivers/gpu/drm/drm_displayid.c
index 9edc111be7ee..27ffeee09e4f 100644
--- a/drivers/gpu/drm/drm_displayid.c
+++ b/drivers/gpu/drm/drm_displayid.c
@@ -42,7 +42,7 @@ validate_displayid(const u8 *displayid, int length, int idx)
for (i = 0; i < dispid_length; i++)
csum += displayid[idx + i];
if (csum) {
- DRM_NOTE("DisplayID checksum invalid, remainder is %d\n", csum);
+ drm_notice(NULL, "DisplayID checksum invalid, remainder is
%d\n", csum);
return ERR_PTR(-EINVAL);
}
diff --git a/drivers/gpu/drm/drm_kms_helper_common.c
b/drivers/gpu/drm/drm_kms_helper_common.c
index 0bf0fc1abf54..7a41373b67dc 100644
--- a/drivers/gpu/drm/drm_kms_helper_common.c
+++ b/drivers/gpu/drm/drm_kms_helper_common.c
@@ -41,7 +41,7 @@ MODULE_LICENSE("GPL and additional rights");
/* Backward compatibility for drm_kms_helper.edid_firmware */
static int edid_firmware_set(const char *val, const struct kernel_param *kp)
{
- DRM_NOTE("drm_kms_helper.edid_firmware is deprecated, please use
drm.edid_firmware instead.\n");
+ drm_notice(NULL, "drm_kms_helper.edid_firmware is deprecated, please
use drm.edid_firmware instead.\n");
return __drm_set_edid_firmware_path(val);
}
--
2.39.2
[PATCH v10 3/9] drm: Remove usage of deprecated DRM_INFO in DRM core
drm_print.h says DRM_INFO is deprecated in favor of drm_info().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_client_modeset.c | 2 +-
drivers/gpu/drm/drm_connector.c | 7 ---
drivers/gpu/drm/drm_drv.c| 2 +-
drivers/gpu/drm/drm_pci.c| 2 +-
4 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 1b12a3c201a3..ae19734974b5 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -331,7 +331,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
DRM_DEBUG_KMS("can clone using 1024x768\n");
return true;
}
- DRM_INFO("kms: can't enable cloning when we probably wanted to.\n");
+ drm_info(dev, "kms: can't enable cloning when we probably wanted
to.\n");
return false;
}
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 48df7a5ea503..dca8dd4ab93f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -168,13 +168,14 @@ static void drm_connector_get_cmdline_mode(struct
drm_connector *connector)
return;
if (mode->force) {
- DRM_INFO("forcing %s connector %s\n", connector->name,
-drm_get_connector_force_name(mode->force));
+ drm_info(connector->dev, "forcing %s connector %s\n",
+connector->name,
drm_get_connector_force_name(mode->force));
connector->force = mode->force;
}
if (mode->panel_orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN) {
- DRM_INFO("cmdline forces connector %s panel_orientation to
%d\n",
+ drm_info(connector->dev,
+"cmdline forces connector %s panel_orientation to
%d\n",
connector->name, mode->panel_orientation);
drm_connector_set_panel_orientation(connector,
mode->panel_orientation);
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 12687dd9e1ac..02eaa4c9344d 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -943,7 +943,7 @@ int drm_dev_register(struct drm_device *dev, unsigned long
flags)
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_register_all(dev);
- DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
+ drm_info(dev, "Initialized %s %d.%d.%d %s for %s on minor %d\n",
driver->name, driver->major, driver->minor,
driver->patchlevel, driver->date,
dev->dev ? dev_name(dev->dev) : "virtual device",
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 39d35fc3a43b..7dfb837d1325 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -262,7 +262,7 @@ void drm_legacy_pci_exit(const struct drm_driver *driver,
}
mutex_unlock(&legacy_dev_list_lock);
}
- DRM_INFO("Module unloaded\n");
+ drm_info(NULL, "Module unloaded\n");
}
EXPORT_SYMBOL(drm_legacy_pci_exit);
--
2.39.2
[PATCH v9 2/8] drm/print: Fix and add support for NULL as first argument in drm_* macros
Comments say macros DRM_DEBUG_* are deprecated in favor of
drm_dbg_*(NULL, ...), but they have broken support for it,
as the macro will result in `(NULL) ? (NULL)->dev : NULL`.
Thus, fix them by separating logic to get dev ptr in a new
function, which will return the dev ptr if arg is not NULL.
Use it in drm_dbg_*, and also in __DRM_DEFINE_DBG_RATELIMITED,
where a similar (but correct) NULL check was in place.
Also, add support for NULL in __drm_printk, so that all the
drm_* macros will hence support NULL as the first argument.
This also means that deprecation comments mentioning pr_()*
can now be changed to the drm equivalents.
Signed-off-by: Siddh Raman Pant
---
include/drm/drm_print.h | 79 +++--
1 file changed, 52 insertions(+), 27 deletions(-)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index a93a387f8a1a..4b8532cf2ae6 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -34,6 +34,7 @@
#include
#include
+#include
/* Do *not* use outside of drm_print.[ch]! */
extern unsigned long __drm_debug;
@@ -451,9 +452,32 @@ void __drm_dev_dbg(struct _ddebug *desc, const struct
device *dev,
* Prefer drm_device based logging over device or prink based logging.
*/
+/* Helpers for struct drm_device based logging. */
+
+/**
+ * __drm_dev_ptr - Helper function to get drm->dev pointer.
+ * @drm: struct drm_device pointer.
+ *
+ * RETURNS:
+ * The struct device pointer (NULL if @drm is NULL).
+ */
+static inline struct device *__drm_dev_ptr(const struct drm_device *drm)
+{
+ if (drm)
+ return drm->dev;
+
+ return NULL;
+}
+
/* Helper for struct drm_device based logging. */
#define __drm_printk(drm, level, type, fmt, ...) \
- dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
+({ \
+ struct device *__dev_ = __drm_dev_ptr(drm); \
+ if (__dev_) \
+ dev_##level##type(__dev_, "[drm] " fmt, ##__VA_ARGS__); \
+ else\
+ pr_##level##type("[drm] " fmt, ##__VA_ARGS__); \
+})
#define drm_info(drm, fmt, ...)\
@@ -487,25 +511,25 @@ void __drm_dev_dbg(struct _ddebug *desc, const struct
device *dev,
#define drm_dbg_core(drm, fmt, ...)\
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_CORE, fmt, ##__VA_ARGS__)
-#define drm_dbg_driver(drm, fmt, ...)
\
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt,
##__VA_ARGS__)
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_CORE, fmt, ##__VA_ARGS__)
+#define drm_dbg_driver(drm, fmt, ...) \
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
#define drm_dbg_kms(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__)
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_KMS, fmt, ##__VA_ARGS__)
#define drm_dbg_prime(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_PRIME, fmt, ##__VA_ARGS__)
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_PRIME, fmt, ##__VA_ARGS__)
#define drm_dbg_atomic(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_ATOMIC, fmt,
##__VA_ARGS__)
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_ATOMIC, fmt, ##__VA_ARGS__)
#define drm_dbg_vbl(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_VBL, fmt, ##__VA_ARGS__)
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_VBL, fmt, ##__VA_ARGS__)
#define drm_dbg_state(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_STATE, fmt, ##__VA_ARGS__)
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_STATE, fmt, ##__VA_ARGS__)
#define drm_dbg_lease(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_LEASE, fmt, ##__VA_ARGS__)
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_LEASE, fmt, ##__VA_ARGS__)
#define drm_dbg_dp(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DP, fmt, ##__VA_ARGS__)
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_DP, fmt, ##__VA_ARGS__)
#define drm_dbg_drmres(drm, fmt, ...) \
- drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRMRES, fmt,
##__VA_ARGS__)
+ drm_dev_dbg(__drm_dev_ptr(drm), DRM_UT_DRMRES, fmt, ##__VA_ARGS__)
#define drm_dbg(drm, fmt, ...) drm_dbg_driver(drm, fmt, ##__VA_ARGS__)
@@ -533,31 +557,31 @@ void __drm_err(const char *format, ...);
#define _DRM_PRINTK(once
[PATCH v9 4/8] drm: Remove usage of deprecated DRM_NOTE
drm_print.h says DRM_NOTE is deprecated in favor of drm_notice().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_displayid.c | 2 +-
drivers/gpu/drm/drm_kms_helper_common.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_displayid.c b/drivers/gpu/drm/drm_displayid.c
index 9edc111be7ee..27ffeee09e4f 100644
--- a/drivers/gpu/drm/drm_displayid.c
+++ b/drivers/gpu/drm/drm_displayid.c
@@ -42,7 +42,7 @@ validate_displayid(const u8 *displayid, int length, int idx)
for (i = 0; i < dispid_length; i++)
csum += displayid[idx + i];
if (csum) {
- DRM_NOTE("DisplayID checksum invalid, remainder is %d\n", csum);
+ drm_notice(NULL, "DisplayID checksum invalid, remainder is
%d\n", csum);
return ERR_PTR(-EINVAL);
}
diff --git a/drivers/gpu/drm/drm_kms_helper_common.c
b/drivers/gpu/drm/drm_kms_helper_common.c
index 0bf0fc1abf54..7a41373b67dc 100644
--- a/drivers/gpu/drm/drm_kms_helper_common.c
+++ b/drivers/gpu/drm/drm_kms_helper_common.c
@@ -41,7 +41,7 @@ MODULE_LICENSE("GPL and additional rights");
/* Backward compatibility for drm_kms_helper.edid_firmware */
static int edid_firmware_set(const char *val, const struct kernel_param *kp)
{
- DRM_NOTE("drm_kms_helper.edid_firmware is deprecated, please use
drm.edid_firmware instead.\n");
+ drm_notice(NULL, "drm_kms_helper.edid_firmware is deprecated, please
use drm.edid_firmware instead.\n");
return __drm_set_edid_firmware_path(val);
}
--
2.39.2
[PATCH v9 6/8] drm: Remove usage of deprecated DRM_DEBUG
drm_print.h says DRM_DEBUG is deprecated in favor of drm_dbg_core().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_agpsupport.c | 4 +-
drivers/gpu/drm/drm_bufs.c| 114 +++---
drivers/gpu/drm/drm_context.c | 14 ++--
drivers/gpu/drm/drm_dma.c | 10 +--
drivers/gpu/drm/drm_drv.c | 10 +--
drivers/gpu/drm/drm_gem.c | 5 +-
drivers/gpu/drm/drm_hashtab.c | 6 +-
drivers/gpu/drm/drm_irq.c | 4 +-
drivers/gpu/drm/drm_lease.c | 2 +-
drivers/gpu/drm/drm_legacy_misc.c | 4 +-
drivers/gpu/drm/drm_lock.c| 20 +++---
drivers/gpu/drm/drm_mode_object.c | 6 +-
drivers/gpu/drm/drm_pci.c | 12 ++--
drivers/gpu/drm/drm_plane.c | 12 ++--
drivers/gpu/drm/drm_scatter.c | 10 +--
drivers/gpu/drm/drm_syncobj.c | 2 +-
drivers/gpu/drm/drm_sysfs.c | 14 ++--
drivers/gpu/drm/drm_vm.c | 43 ++-
18 files changed, 150 insertions(+), 142 deletions(-)
diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index a4ad6fd13abc..d27686d6e82d 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -315,8 +315,8 @@ int drm_legacy_agp_bind(struct drm_device *dev, struct
drm_agp_binding *request)
if (retcode)
return retcode;
entry->bound = dev->agp->base + (page << PAGE_SHIFT);
- DRM_DEBUG("base = 0x%lx entry->bound = 0x%lx\n",
- dev->agp->base, entry->bound);
+ drm_dbg_core(dev, "base = 0x%lx entry->bound = 0x%lx\n",
+dev->agp->base, entry->bound);
return 0;
}
EXPORT_SYMBOL(drm_legacy_agp_bind);
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index aa66fe16ea6e..a767f51c5369 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -171,8 +171,8 @@ static int drm_addmap_core(struct drm_device *dev,
resource_size_t offset,
kfree(map);
return -EINVAL;
}
- DRM_DEBUG("offset = 0x%08llx, size = 0x%08lx, type = %d\n",
- (unsigned long long)map->offset, map->size, map->type);
+ drm_dbg_core(dev, "offset = 0x%08llx, size = 0x%08lx, type = %d\n",
+(unsigned long long)map->offset, map->size, map->type);
/* page-align _DRM_SHM maps. They are allocated here so there is no
security
* hole created by that and it works around various broken drivers that
use
@@ -205,10 +205,10 @@ static int drm_addmap_core(struct drm_device *dev,
resource_size_t offset,
list = drm_find_matching_map(dev, map);
if (list != NULL) {
if (list->map->size != map->size) {
- DRM_DEBUG("Matching maps of type %d with "
- "mismatched sizes, (%ld vs %ld)\n",
- map->type, map->size,
- list->map->size);
+ drm_dbg_core(dev, "Matching maps of type %d
with "
+"mismatched sizes, (%ld vs %ld)\n",
+map->type, map->size,
+list->map->size);
list->map->size = map->size;
}
@@ -239,9 +239,9 @@ static int drm_addmap_core(struct drm_device *dev,
resource_size_t offset,
list = drm_find_matching_map(dev, map);
if (list != NULL) {
if (list->map->size != map->size) {
- DRM_DEBUG("Matching maps of type %d with "
- "mismatched sizes, (%ld vs %ld)\n",
- map->type, map->size,
list->map->size);
+ drm_dbg_core(dev, "Matching maps of type %d
with "
+"mismatched sizes, (%ld vs %ld)\n",
+map->type, map->size,
list->map->size);
list->map->size = map->size;
}
@@ -250,8 +250,8 @@ static int drm_addmap_core(struct drm_device *dev,
resource_size_t offset,
return 0;
}
map->handle = vmalloc_user(map->size);
- DRM_DEBUG("%lu %d %p\n",
- map->size, order_base_2(map->size), map->handle);
+ drm_dbg_core(dev, "%lu %d %p\n",
+map->size, order_base_2(map->size), map->handle);
if (!map->handle) {
kfree(map);
return -ENOMEM;
@@ -308,8 +308,8 @@ static int drm_addmap_core(struct drm_device *dev,
resource_size_t offset,
kfree(map);
return -EPERM;
}
-
Re: [PATCH] drm/bridge: ti-sn65dsi86: Avoid possible buffer overflow
Hi,
On 2023/6/6 23:28, Doug Anderson wrote:
Hi,
On Tue, Jun 6, 2023 at 12:56 AM Su Hui wrote:
Smatch error:buffer overflow 'ti_sn_bridge_refclk_lut' 5 <= 5.
Fixes: cea86c5bb442 ("drm/bridge: ti-sn65dsi86: Implement the pwm_chip")
Signed-off-by: Su Hui
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 7a748785c545..952aae4221e7 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -305,7 +305,8 @@ static void ti_sn_bridge_set_refclk_freq(struct
ti_sn65dsi86 *pdata)
* The PWM refclk is based on the value written to SN_DPPLL_SRC_REG,
* regardless of its actual sourcing.
*/
- pdata->pwm_refclk_freq = ti_sn_bridge_refclk_lut[i];
+ if (i < refclk_lut_size)
+ pdata->pwm_refclk_freq = ti_sn_bridge_refclk_lut[i];
I don't think this is quite the right fix. I don't think we can just
skip assigning "pdata->pwm_refclk_freq". In general I think we're in
pretty bad shape if we ever fail to match a refclk from the table and
I'm not quite sure how the bridge chip could work at all in this case.
Probably that at least deserves a warning message in the logs. There's
no place to return an error though, so I guess the warning is the best
we can do and then we can do our best to do something reasonable.
In this case, I think "reasonable" might be that if the for loop exits
and "i == refclk_lut_size" that we should set "i" to 1. According to
the datasheet [1] setting a value of 5 (which the existing code does)
is the same as setting a value of 1 (the default) and if it's 1 then
we'll be able to look this up in the table.
I think you are right. And " if ( i >= refclk_lut_size) i=1" is a
suitable change.
I will send patch v2 a litter latter.
Thanks for your suggestion.
Su Hui
[1] https://www.ti.com/lit/gpn/sn65dsi86
-Doug
Re: [Freedreno] [PATCH v3 4/7] drm/msm/mdp5: Add MDP5 configuration for MSM8226
On 6/1/2023 10:00 AM, Luca Weiss wrote:
Add the required config for the v1.1 MDP5 found on MSM8226.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 82
1 file changed, 82 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index 2eec2d78f32a..694d54341337 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -103,6 +103,87 @@ static const struct mdp5_cfg_hw msm8x74v1_config = {
.max_clk = 2,
};
+static const struct mdp5_cfg_hw msm8x26_config = {
+ .name = "msm8x26",
+ .mdp = {
+ .count = 1,
+ .caps = MDP_CAP_SMP |
+ 0,
+ },
+ .smp = {
+ .mmb_count = 7,
+ .mmb_size = 4096,
+ .clients = {
+ [SSPP_VIG0] = 1,
+ [SSPP_DMA0] = 4,
+ [SSPP_RGB0] = 7,
+ },
+ },
+ .ctl = {
+ .count = 2,
+ .base = { 0x00500, 0x00600 },
+ .flush_hw_mask = 0x0003,
+ },
+ .pipe_vig = {
+ .count = 1,
+ .base = { 0x01100 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SCALE |
+ MDP_PIPE_CAP_CSC |
+ 0,
+ },
+ .pipe_rgb = {
+ .count = 1,
+ .base = { 0x01d00 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SCALE |
+ 0,
+ },
+ .pipe_dma = {
+ .count = 1,
+ .base = { 0x02900 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ 0,
+ },
+ .lm = {
+ .count = 2,
+ .base = { 0x03100, 0x03d00 },
+ .instances = {
+ { .id = 0, .pp = 0, .dspp = 0,
+ .caps = MDP_LM_CAP_DISPLAY, },
+ { .id = 1, .pp = -1, .dspp = -1,
+ .caps = MDP_LM_CAP_WB },
+},
+ .nb_stages = 2,
+ .max_width = 2048,
+ .max_height = 0x,
+ },
+ .dspp = {
+ .count = 1,
+ .base = { 0x04500 },
+ },
+ .pp = {
+ .count = 1,
+ .base = { 0x21a00 },
+ },
+ .intf = {
+ .base = { 0x0, 0x21200 },
+ .connect = {
+ [0] = INTF_DISABLED,
+ [1] = INTF_DSI,
+ },
+ },
+ .perf = {
+ .ab_inefficiency = 100,
+ .ib_inefficiency = 200,
+ .clk_inefficiency = 125
+ },
+ .max_clk = 2,
+};
+
static const struct mdp5_cfg_hw msm8x74v2_config = {
.name = "msm8x74",
.mdp = {
@@ -1236,6 +1317,7 @@ static const struct mdp5_cfg_hw sdm660_config = {
static const struct mdp5_cfg_handler cfg_handlers_v1[] = {
{ .revision = 0, .config = { .hw = &msm8x74v1_config } },
+ { .revision = 1, .config = { .hw = &msm8x26_config } },
{ .revision = 2, .config = { .hw = &msm8x74v2_config } },
{ .revision = 3, .config = { .hw = &apq8084_config } },
{ .revision = 6, .config = { .hw = &msm8x16_config } },
Reviewed-by: Jeykumar Sankaran
[PATCH v10 0/9] drm: Remove usage of deprecated DRM_* macros in DRM core
This patchset aims to remove usages of deprecated DRM_* macros from the
DRM core (i.e. drivers/gpu/drm/*.c).
In process, I found out that NULL as first argument of drm_dbg_* wasn't
working, but it was listed as the alternative in deprecation comment,
so I fixed that before removing usages of DRM_DEBUG_* macros.
Courtesy discussion on v1, I added support for NULL in drm_()* macros too.
Courtesy discussion on v7, I removed generic macro stuff meant to accomodate
stuff like mipi_dsi_host in earlier versions of the patch series, and instead
reverted a commit which used the drm_err() macro incorrectly by passing
mipi_dsi_host.
Courtesy discussion on v9, a number of superfluous print statements across
the drm core have also been removed, and the commit messages clarified.
This patchset should be applied in order as changes might be dependent.
Please review and let me know if any errors are there, and hopefully
this gets accepted.
---
v9 -> v10 (today)
- Clarified commit message to point out the changes are in DRM core.
- Remove superfluous print messages after the changes.
v8 -> v9 (today):
- Rebased to drm-misc-next.
v7 -> v8 (28 Feb 2023):
- Reverted 1040e424353f ("drm: mipi-dsi: Convert logging to drm_* functions.")
which used drm_err macro incorrectly by passing mipi_dsi_host.
- Thus, removed _Generic and allow only drm_device.
v6 -> v7 (26 Feb 2023):
- Rebased to drm-misc-next, accounting for the merger of last 3 patches
in the previous series (4665280990fa, fc2602b553c8, 7bd224b6625a),
and 7428ff70a18 ("drm: initialize accel framework").
v5 -> v6 (09 Jan 2023):
- Move drm_device to default case in _Generic as it is the default behaviour.
- Fix incorrect const drm_device handling in _Generic.
- Minor positioning / comment changes.
v4 -> v5 (07 Jan 2023):
- Make separate function instead of using boolean in _Generic (sravn on IRC).
- Also, simplified the Generic macro, and renamed the function and macro.
v3 -> v4 (05 Jan 2023):
- Fix commit message for DRM_NOTE erroneously mentioning DRM_INFO.
- Rebased to drm-misc-next, as 723dad977acd added drm_dbg_core() to some
files.
- Move Generic out to a separate macro __drm_get_dev_ptr, so that interface
of drm_dbg_*() is also same as other drm_*() macros.
- Fix comment in __drm_get_dev_ptr (now ___drm_get_dev_ptr) to use correct
name.
v2 -> v3 (26 Dec 2022):
- Added support for NULL in __drm_printk and thus by extension to drm_()*.
- Thus, converted dropped pr_()* changes to drm_*(NULL, ...).
- Rebased to drm-misc-next and resulting appropriate changes.
v1 (20 Dec 2022) -> v2 (22 Dec 2022):
- Removed conversions to pr_*() in DRM_INFO, DRM_NOTE, and DRM_ERROR changes.
- Due to above, DRM_NOTE usage cannot be removed and the patch is dropped.
- DRY: NULL support is now achieved by way of a separate function.
Siddh Raman Pant (9):
Revert "drm: mipi-dsi: Convert logging to drm_* functions."
drm/print: Fix and add support for NULL as first argument in drm_*
macros
drm: Remove usage of deprecated DRM_INFO in DRM core
drm: Remove usage of deprecated DRM_NOTE in DRM core
drm: Remove usage of deprecated DRM_ERROR in DRM core
drm: Remove usage of deprecated DRM_DEBUG in DRM core
drm: Remove usage of deprecated DRM_DEBUG_DRIVER in DRM core
drm: Remove usage of deprecated DRM_DEBUG_KMS in DRM core
drm: Remove superfluous print statements in DRM core
drivers/gpu/drm/drm_agpsupport.c| 4 +-
drivers/gpu/drm/drm_bridge.c| 8 +-
drivers/gpu/drm/drm_bufs.c | 122
drivers/gpu/drm/drm_client_modeset.c| 117 +--
drivers/gpu/drm/drm_color_mgmt.c| 4 +-
drivers/gpu/drm/drm_connector.c | 28 +++---
drivers/gpu/drm/drm_context.c | 17 ++--
drivers/gpu/drm/drm_crtc.c | 36 ---
drivers/gpu/drm/drm_crtc_helper.c | 62 ++--
drivers/gpu/drm/drm_debugfs_crc.c | 8 +-
drivers/gpu/drm/drm_displayid.c | 6 +-
drivers/gpu/drm/drm_dma.c | 10 +-
drivers/gpu/drm/drm_drv.c | 27 ++
drivers/gpu/drm/drm_edid.c | 17 ++--
drivers/gpu/drm/drm_file.c | 2 -
drivers/gpu/drm/drm_flip_work.c | 2 +-
drivers/gpu/drm/drm_framebuffer.c | 3 +-
drivers/gpu/drm/drm_gem.c | 6 +-
drivers/gpu/drm/drm_gem_dma_helper.c| 2 +-
drivers/gpu/drm/drm_hashtab.c | 9 +-
drivers/gpu/drm/drm_irq.c | 4 +-
drivers/gpu/drm/drm_kms_helper_common.c | 2 +-
drivers/gpu/drm/drm_lease.c | 4 +-
drivers/gpu/drm/drm_legacy_misc.c | 3 +-
drivers/gpu/drm/drm_lock.c | 36 +++
drivers/gpu/drm/drm_mipi_dbi.c | 19 ++--
drivers/gpu/drm/drm_mipi_dsi.c | 15 +--
drivers/gpu/drm/drm_mm.c| 8 +-
drivers/gpu/drm/drm_mode_config.c | 2 +-
drivers/gpu/drm/drm_mode_object.c | 6 +-
drivers/gpu/drm/drm_modes.c
Re: [PATCH v9 2/8] drm/print: Fix and add support for NULL as first argument in drm_* macros
On Tue, 06 Jun 2023 19:35:12 +0530, Laurent Pinchart wrote:
> Hi Siddh,
>
> Thank you for the patch.
Anytime :)
> On Tue, Jun 06, 2023 at 04:15:16PM +0530, Siddh Raman Pant wrote:
> > Comments say macros DRM_DEBUG_* are deprecated in favor of
> > drm_dbg_*(NULL, ...), but they have broken support for it,
> > as the macro will result in `(NULL) ? (NULL)->dev : NULL`.
>
> What's the problem there ?
(NULL)->dev is invalid C. It's a macro, so preprocessor substitutes
that text directly, there is no evaluation. GCC will throw an error
regarding dereferencing a void* pointer.
> > /* Helper for struct drm_device based logging. */
> > #define __drm_printk(drm, level, type, fmt, ...) \
> > - dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
> > +({ \
> > + struct device *__dev_ = __drm_dev_ptr(drm); \
> > + if (__dev_) \
> > + dev_##level##type(__dev_, "[drm] " fmt, ##__VA_ARGS__); \
> > + else\
> > + pr_##level##type("[drm] " fmt, ##__VA_ARGS__); \
>
> If I recall correctly, dev_*() handle a NULL dev pointer just fine. Do
> we need to manually fall back to pr_*() ?
I took drm_dev_printk (on line 261 of drm_print.c) as the reference,
wherein it uses a conditional for determining whether dev_printk or
printk should be called.
I suppose it is to avoid printing "(NULL device *)", which dev_printk
does if it gets a NULL device pointer (refer the definition on line
4831 of drivers/base/core.c). Though if I'm wrong, kindly let me know.
Thanks,
Siddh
[PATCH v10 1/9] Revert "drm: mipi-dsi: Convert logging to drm_* functions."
This reverts commit 1040e424353f5f4d39f6f3aa8723eb3bd6ea6446.
It used an incorrect way to use drm_* functions. Only drm_device ptrs
should be passed, but the mentioned commit passed mipi_dsi_host ptr.
It worked by accident due to macro magic.
Reported-by: Jani Nikula
Reviewed-by: Jani Nikula
Reviewed-by: Laurent Pinchart
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_mipi_dsi.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 3fd6c733ff4e..a37af4edf394 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -33,7 +33,6 @@
#include
#include
-#include
#include
@@ -156,18 +155,19 @@ static int mipi_dsi_device_add(struct mipi_dsi_device
*dsi)
static struct mipi_dsi_device *
of_mipi_dsi_device_add(struct mipi_dsi_host *host, struct device_node *node)
{
+ struct device *dev = host->dev;
struct mipi_dsi_device_info info = { };
int ret;
u32 reg;
if (of_alias_from_compatible(node, info.type, sizeof(info.type)) < 0) {
- drm_err(host, "modalias failure on %pOF\n", node);
+ dev_err(dev, "modalias failure on %pOF\n", node);
return ERR_PTR(-EINVAL);
}
ret = of_property_read_u32(node, "reg", ®);
if (ret) {
- drm_err(host, "device node %pOF has no valid reg property:
%d\n",
+ dev_err(dev, "device node %pOF has no valid reg property: %d\n",
node, ret);
return ERR_PTR(-EINVAL);
}
@@ -202,21 +202,22 @@ mipi_dsi_device_register_full(struct mipi_dsi_host *host,
const struct mipi_dsi_device_info *info)
{
struct mipi_dsi_device *dsi;
+ struct device *dev = host->dev;
int ret;
if (!info) {
- drm_err(host, "invalid mipi_dsi_device_info pointer\n");
+ dev_err(dev, "invalid mipi_dsi_device_info pointer\n");
return ERR_PTR(-EINVAL);
}
if (info->channel > 3) {
- drm_err(host, "invalid virtual channel: %u\n", info->channel);
+ dev_err(dev, "invalid virtual channel: %u\n", info->channel);
return ERR_PTR(-EINVAL);
}
dsi = mipi_dsi_device_alloc(host);
if (IS_ERR(dsi)) {
- drm_err(host, "failed to allocate DSI device %ld\n",
+ dev_err(dev, "failed to allocate DSI device %ld\n",
PTR_ERR(dsi));
return dsi;
}
@@ -227,7 +228,7 @@ mipi_dsi_device_register_full(struct mipi_dsi_host *host,
ret = mipi_dsi_device_add(dsi);
if (ret) {
- drm_err(host, "failed to add DSI device %d\n", ret);
+ dev_err(dev, "failed to add DSI device %d\n", ret);
kfree(dsi);
return ERR_PTR(ret);
}
--
2.39.2
Re: [PATCH 09/30] fbdev/ep93xx-fb: Alloc DMA memory from hardware device
Thomas Zimmermann writes: > Pass the hardware device to the DMA helpers dma_alloc_wc(), dma_mmap_wc() > and dma_free_coherent(). The fbdev device that is currently being used is > a software device and does not provide DMA memory. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 30/30] fbdev: Make support for userspace interfaces configurable
Hi Thomas,
Thanks for your patch!
On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann wrote:
> Add Kconfig option CONFIG_FB_DEVICE and make the virtual fbdev
> device optional. If the new option has not been selected, fbdev
> does not create a files in devfs or sysfs.
>
> Most modern Linux systems run a DRM-based graphics stack that uses
> the kernel's framebuffer console, but has otherwise deprecated fbdev
> support. Yet fbdev userspace interfaces are still present.
>
> The option makes it possible to use the fbdev subsystem as console
> implementation without support for userspace. This closes potential
> entry points to manipulate kernel or I/O memory via framebuffers. It
I'd leave out the part about manipulating kernel memory, as that's a
driver bug, if possible.
> also prevents the execution of driver code via ioctl or sysfs, both
> of which might allow malicious software to exploit bugs in the fbdev
> code.
Of course disabling ioctls reduces the attack surface, and this is not
limited to fbdev... ;-)
I'm wondering if it would be worthwhile to optionally provide a more
limited userspace API for real fbdev drivers:
1. No access to MMIO, only to the mapped frame buffer,
2. No driver-specific ioctls, only the standard ones.
> A small number of fbdev drivers require struct fbinfo.dev to be
> initialized, usually for the support of sysfs interface. Make these
> drivers depend on FB_DEVICE. They can later be fixed if necessary.
>
> Signed-off-by: Thomas Zimmermann
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -57,6 +57,15 @@ config FIRMWARE_EDID
> combination with certain motherboards and monitors are known to
> suffer from this problem.
>
> +config FB_DEVICE
> +bool "Provide legacy /dev/fb* device"
Perhaps "default y if !DRM", although that does not help for a
mixed drm/fbdev kernel build?
Or reserve "FB" for real fbdev drivers, and introduce a new FB_CORE,
to be selected by both FB and DRM_FBDEV_EMULATION?
Then FB_DEVICE can depend on FB_CORE, and default to y if FB.
> +depends on FB
> +help
> + Say Y here if you want the legacy /dev/fb* device file. It's
> + only required if you have userspace programs that depend on
> + fbdev for graphics output. This does not effect the framebuffer
affect
> + console.
> +
> config FB_DDC
> tristate
> depends on FB
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 v5 01/11] i2c: Enhance i2c_new_ancillary_device API
Hi all, sorry for not being able to chime in earlier. > In Biju's particular use case, the i2c device responds to two addresses, > which is the standard i2c ancillary use case. However, what's special Not quite. ancillary is used when a *driver* needs to take care of two addresses. We already have devices bundling two features into the same chip. I recall at least RTC + EEPROM somewhere. And so far, we have been handling this by creating two nodes in DT and have proper binding docs. I think this is cleaner. First, you can see in DT already what the compound device really consists of. In this case, which RTC and RTC driver is exactly needed. Second, the code added here adds complexity to the I2C core with another layer of inderection for dummy devices. > As some resources are shared (knowledge about the clocks), splitting > this in two distinct devices in DT (which is what Biju's initial patch > series did) would need phandles to link both nodes together. > > Do you have a better idea how to represent this? Not sure if I understood this chip correctly, but maybe: The PMIC driver exposes a clock gate which can be consumed by the RTC driver? Happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH 3/9] drm/verisilicon: Add basic drm driver
Hi Keith,
Am Freitag, dem 02.06.2023 um 15:40 +0800 schrieb Keith Zhao:
> Add a basic platform driver of the DRM driver for JH7110 SoC.
>
> Signed-off-by: Keith Zhao
> ---
> MAINTAINERS | 2 +
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/verisilicon/Kconfig | 13 ++
> drivers/gpu/drm/verisilicon/Makefile | 6 +
> drivers/gpu/drm/verisilicon/vs_drv.c | 284 +++
> drivers/gpu/drm/verisilicon/vs_drv.h | 48 +
> include/uapi/drm/drm_fourcc.h| 83
> include/uapi/drm/vs_drm.h| 50 +
> 9 files changed, 489 insertions(+)
> create mode 100644 drivers/gpu/drm/verisilicon/Kconfig
> create mode 100644 drivers/gpu/drm/verisilicon/Makefile
> create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.c
> create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.h
> create mode 100644 include/uapi/drm/vs_drm.h
>
>
> [...]
> +#endif /* __VS_DRV_H__ */
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index de703c6be969..af4fb50f9207 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -419,6 +419,7 @@ extern "C" {
> #define DRM_FORMAT_MOD_VENDOR_ARM 0x08
> #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
> #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
> +#define DRM_FORMAT_MOD_VENDOR_VS 0x0b
>
> /* add more to the end as needed */
>
> @@ -1519,6 +1520,88 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64
> modifier)
> #define AMD_FMT_MOD_CLEAR(field) \
> (~((__u64)AMD_FMT_MOD_##field##_MASK << AMD_FMT_MOD_##field##_SHIFT))
>
> +#define DRM_FORMAT_MOD_VS_TYPE_NORMAL0x00
> +#define DRM_FORMAT_MOD_VS_TYPE_COMPRESSED0x01
> +#define DRM_FORMAT_MOD_VS_TYPE_CUSTOM_10BIT 0x02
> +#define DRM_FORMAT_MOD_VS_TYPE_MASK ((__u64)0x3 << 54)
> +
> +#define fourcc_mod_vs_code(type, val) \
> + fourcc_mod_code(VS, __u64)type) << 54) | (val)))
> +
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_MODE_MASK0x3F
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_8X8_XMAJOR 0x00
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_8X8_YMAJOR 0x01
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_16X4 0x02
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_8X4 0x03
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_4X8 0x04
> +#define DRM_FORMAT_MOD_VS_DEC_RASTER_16X4 0x06
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_64X4 0x07
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_32X4 0x08
> +#define DRM_FORMAT_MOD_VS_DEC_RASTER_256X1 0x09
> +#define DRM_FORMAT_MOD_VS_DEC_RASTER_128X1 0x0A
> +#define DRM_FORMAT_MOD_VS_DEC_RASTER_64X4 0x0B
> +#define DRM_FORMAT_MOD_VS_DEC_RASTER_256X2 0x0C
> +#define DRM_FORMAT_MOD_VS_DEC_RASTER_128X2 0x0D
> +#define DRM_FORMAT_MOD_VS_DEC_RASTER_128X4 0x0E
> +#define DRM_FORMAT_MOD_VS_DEC_RASTER_64X1 0x0F
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_16X8 0x10
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_8X16 0x11
> +#define DRM_FORMAT_MOD_VS_DEC_RASTER_512X1 0x12
> +#define DRM_FORMAT_MOD_VS_DEC_RASTER_32X4 0x13
> +#define DRM_FORMAT_MOD_VS_DEC_RASTER_64X2 0x14
> +#define DRM_FORMAT_MOD_VS_DEC_RASTER_32X2 0x15
> +#define DRM_FORMAT_MOD_VS_DEC_RASTER_32X1 0x16
> +#define DRM_FORMAT_MOD_VS_DEC_RASTER_16X1 0x17
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_128X40x18
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_256X40x19
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_512X40x1A
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_16X160x1B
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_32X160x1C
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_64X160x1D
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_128X80x1E
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_8X4_S0x1F
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_16X4_S 0x20
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_32X4_S 0x21
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_16X4_LSB 0x22
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_32X4_LSB 0x23
> +#define DRM_FORMAT_MOD_VS_DEC_TILE_32X8 0x24
> +
> +#define DRM_FORMAT_MOD_VS_DEC_ALIGN_32 (0x01 << 6)
> +#define DRM_FORMAT_MOD_VS_DEC_ALIGN_64 (0x01 << 7)
> +
> +#define fourcc_mod_vs_dec_code(tile, align) \
> + fourcc_mod_vs_code(DRM_FORMAT_MOD_VS_TYPE_COMPRESSED, \
> + ((tile) | (align)))
> +
> +#define DRM_FORMAT_MOD_VS_NORM_MODE_MASK0x1F
> +#define DRM_FORMAT_MOD_VS_LINEAR0x00
> +#define DRM_FORMAT_MOD_VS_TILED4x4 0x01
> +#define DRM_FORMAT_MOD_VS_SUPER_TILED_XMAJOR0x02
> +#define DRM_FORMAT_MOD_VS_SUPER_TILED_YMAJOR0x03
> +#define DRM_FORMAT_MOD_VS_TILE_8X8 0x04
> +#define DRM_FORMAT_MOD_VS_TILE_MODE10x05
> +#define DRM_FORMAT_MOD_VS_TILE_MODE20x06
> +#define DRM_FORMAT_MOD_VS_TILE_8X4 0x07
> +#define DRM_FORMAT_MOD_VS_TILE_MODE40x08
> +#define DRM_FORMAT_MOD_VS_TILE_MODE50x09
> +#define DRM_FORMAT_MOD_VS_TILE_MODE60x0A
> +#define DRM_FORMAT_MOD_VS_SUPER_TILED_XMAJOR_8X40x0B
> +#define DRM_FORMAT
[PULL] drm-misc-next
Hi Dave and Daniel,
here's the weekly PR for drm-misc-next.
Best regards
Thomas
drm-misc-next-2023-06-07:
drm-misc-next for v6.5:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
Driver Changes:
* bridge
* imx: Fix module linking
* tc358762: Support reset GPIO
* meson
* Add support for MIPI DSI displays; plus fixes and DT bindings
* panel
* Add Support for Rocktech RK043FN48H; plus DT bindings
* Add support for Starry himax83102-j02; plus DT bindings
* Add support for Starry ili9882t; plus DT bindings
* virtio
* Support sync-object UAPI
The following changes since commit 43049f17b5262826ef64a19762a096782398ef8f:
drm/i915: Implement dedicated fbdev I/O helpers (2023-06-01 12:41:40 +0200)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2023-06-07
for you to fetch changes up to 13cdd12a9f934158f4ec817cf048fcb4384aa9dc:
drm/panel: simple: add support for Rocktech RK043FN48H panel (2023-06-07
10:13:10 +0200)
drm-misc-next for v6.5:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
Driver Changes:
* bridge
* imx: Fix module linking
* tc358762: Support reset GPIO
* meson
* Add support for MIPI DSI displays; plus fixes and DT bindings
* panel
* Add Support for Rocktech RK043FN48H; plus DT bindings
* Add support for Starry himax83102-j02; plus DT bindings
* Add support for Starry ili9882t; plus DT bindings
* virtio
* Support sync-object UAPI
Arnd Bergmann (1):
drm/meson: venc: include linux/bitfield.h
Cong Yang (4):
dt-bindings: display: panel: Add compatible for Starry himax83102-j02
drm/panel: Support for Starry-himax83102-j02 TDDI MIPI-DSI panel
dt-bindings: display: panel: Add compatible for Starry ili9882t
drm/panel: Support for Starry-ili9882t TDDI MIPI-DSI panel
Dario Binacchi (2):
dt-bindings: display: simple: add Rocktech RK043FN48H
drm/panel: simple: add support for Rocktech RK043FN48H panel
Dmitry Osipenko (2):
drm/virtio: Refactor and optimize job submission code path
drm/virtio: Wait for each dma-fence of in-fence array individually
Jeffrey Hugo (1):
MAINTAINERS: Add Carl/Pranjal as QAIC reviewers
Marek Vasut (2):
dt-bindings: display: bridge: tc358762: Document reset-gpios
drm/bridge: tc358762: Add reset GPIO support
Masahiro Yamada (2):
drm/bridge: imx: fix mixed module-builtin object
drm/bridge: imx: turn imx8{qm,qxp}-ldb into single-object modules
Maxime Ripard (1):
mailmap: Add missing email address
Neil Armstrong (8):
dt-bindings: display: add Amlogic MIPI DSI Host Controller bindings
dt-bindings: display: meson-vpu: add third DPI output port
drm/meson: fix unbind path if HDMI fails to bind
drm/meson: only use components with dw-hdmi
drm/meson: venc: add ENCL encoder setup for MIPI-DSI output
drm/meson: add DSI encoder
drm/meson: add support for MIPI-DSI transceiver
drm/panel: khadas-ts050: update timings to achieve 60Hz refresh rate
Yang Li (1):
drm/meson: Remove unneeded semicolon
.mailmap | 1 +
.../display/amlogic,meson-g12a-dw-mipi-dsi.yaml| 118 ++
.../bindings/display/amlogic,meson-vpu.yaml| 5 +
.../bindings/display/bridge/toshiba,tc358762.yaml | 3 +
.../bindings/display/panel/boe,tv101wum-nl6.yaml | 4 +
.../bindings/display/panel/panel-simple.yaml | 2 +
MAINTAINERS| 2 +
drivers/gpu/drm/bridge/imx/Kconfig | 5 +
drivers/gpu/drm/bridge/imx/Makefile| 5 +-
drivers/gpu/drm/bridge/imx/imx-ldb-helper.c| 17 +
.../bridge/imx/{imx8qm-ldb-drv.c => imx8qm-ldb.c} | 0
.../imx/{imx8qxp-ldb-drv.c => imx8qxp-ldb.c} | 0
drivers/gpu/drm/bridge/tc358762.c | 15 +
drivers/gpu/drm/meson/Kconfig | 7 +
drivers/gpu/drm/meson/Makefile | 3 +-
drivers/gpu/drm/meson/meson_drv.c | 62 ++-
drivers/gpu/drm/meson/meson_drv.h | 1 +
drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 352 +++
drivers/gpu/drm/meson/meson_dw_mipi_dsi.h | 160 +++
drivers/gpu/drm/meson/meson_encoder_dsi.c | 174
drivers/gpu/drm/meson/meson_encoder_dsi.h | 13 +
drivers/gpu/drm/meson/meson_registers.h| 25 ++
drivers/gpu/drm/meson/meson_venc.c | 212 -
drivers/gpu/drm/meson/meson_venc.h | 6 +
drivers/gpu/drm/meson/meson_vpp.h | 2 +
drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 472 +
drivers/gpu/drm/panel/panel-khadas-ts050.c | 16 +-
drivers/gpu/drm/panel/panel-simple.c
Re: [PATCH 10/30] fbdev/ep93xx-fb: Output messages with fb_info() and fb_err()
Thomas Zimmermann writes: > Fix cases were output helpers are called with struct fb_info.dev. > Use fb_info() and fb_err() instead. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 11/30] fbdev/ep93xx-fb: Do not assign to struct fb_info.dev
Thomas Zimmermann writes: > Do not assing the Linux device to struct fb_info.dev. The call to > register_framebuffer() initializes the field to the fbdev device. > Drivers should not override its value. > > Fixes a bug where the driver incorrectly decreases the hardware > device's reference counter and leaks the fbdev device. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 12/30] fbdev/mb862xxfb: Output messages with fb_dbg() and fb_err()
Thomas Zimmermann writes: > Fix cases were output helpers are called with struct fb_info.dev. > Use fb_dbg() and fb_err() instead. Prepares fbdev for making struct > fb_info.dev optional. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 13/30] fbdev/metronomefb: Use hardware device for dev_err()
Thomas Zimmermann writes: > Replace the use of the fbdev software device, stored in struct > fb_info.dev, with the hardware device from struct fb_info.device > in load_waveform(). The device is only used for printing errors > with dev_err(). > > This change aligns load_waveform() with the rest of the driver and > prepares fbdev for making struct fb_info.dev optional. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 14/30] fbdev/nvidiafb: Reorder backlight and framebuffer init/cleanup
Thomas Zimmermann writes: > The driver's backlight code requires the framebuffer to be > registered. Therefore reorder the init and cleanup calls for > both data structures. > > Signed-off-by: Thomas Zimmermann > Cc: Antonino Daplas > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 15/30] fbdev/nvidiafb: Use hardware device as backlight parent
Thomas Zimmermann writes: > Use the hardware device in struct fb_info.device as parent of the > backlight device. Aligns the driver with the rest of the codebase > and prepares fbdev for making struct fb_info.dev optional. > > Signed-off-by: Thomas Zimmermann > Cc: Antonino Daplas > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [1/4] fbdev: imsttfb: Fix error handling in init_imstt()
> I think the return value isn't checked at all, so you could > simply return below "-ENODEV" for all cases (instead of "return ret"). > Then you don't need the e_nodev label and can simplify the flow. I noticed that the software evolution was continued with an other change variant. fbdev: imsttfb: Release framebuffer and dealloc cmap on error path https://lore.kernel.org/linux-fbdev/20230527093016.486521-1-del...@gmx.de/ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/video/fbdev/imsttfb.c?h=v6.4-rc5&id=5cf9a090a39c97f4506b7b53739d469b1c05a7e9 Regards, Markus
Re: [2/4] fbdev: imsttfb: Fix exception handling in imsttfb_probe()
> The exception handling was incomplete. > > The label “error” was used to jump to another pointer check despite of > the detail in the implementation of the function “imsttfb_probe” > that it was determined already that the corresponding variable > contained a null pointer. > > * Thus use more appropriate labels instead. > > * Delete two redundant checks. I noticed that the software evolution was continued with an other change variant. fbdev: imsttfb: Fix error path of imsttfb_probe() https://lore.kernel.org/linux-fbdev/20230527093901.487483-1-del...@gmx.de/ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/video/fbdev/imsttfb.c?h=v6.4-rc5&id=518ecb6a209f6ff678aeadf9f2bf870c0982ca85 Regards, Markus
Re: [PATCH 16/30] fbdev/pxa168fb: Do not assign to struct fb_info.dev
Thomas Zimmermann writes: > Do not assign the hardware device to struct fb_info.dev. The > field references the fbdev software device, which is unrelated. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
RE: [PATCH] drm/amdgpu: display/Kconfig: replace leading spaces with tab
[Public] It's https://gitlab.freedesktop.org/agd5f/linux/-/tree/amd-staging-drm-next?ref_type=heads. Latest patches including yours's will be pushed to this branch after a while. Regards, Guchun > -Original Message- > From: amd-gfx On Behalf Of Sui > Jingfeng > Sent: Wednesday, June 7, 2023 2:34 PM > To: Alex Deucher > Cc: Li, Sun peng (Leo) ; David Airlie > ; Pan, Xinhui ; Siqueira, Rodrigo > ; linux-ker...@vger.kernel.org; dri- > de...@lists.freedesktop.org; amd-...@lists.freedesktop.org; Daniel Vetter > ; Deucher, Alexander ; > Wentland, Harry ; Koenig, Christian > > Subject: Re: [PATCH] drm/amdgpu: display/Kconfig: replace leading spaces > with tab > > https://cgit.freedesktop.org/amd/drm-amd/ > > > This one has a long time with no update. > > > On 2023/6/7 14:31, Sui Jingfeng wrote: > > Hi, > > > > On 2023/6/7 03:15, Alex Deucher wrote: > >> Applied. Thanks! > > > > Where is the official branch of drm/amdgpu, I can't find it on the > > internet. > > > > Sorry for asking this silly question. > > > > >> Alex > >> > >> On Tue, Jun 6, 2023 at 9:33 AM Sui Jingfeng > >> wrote: > >>> This patch replace the leading spaces with tab, make them keep > >>> aligned with the rest of the config options. No functional change. > >>> > >>> Signed-off-by: Sui Jingfeng > >>> --- > >>> drivers/gpu/drm/amd/display/Kconfig | 17 +++-- > >>> 1 file changed, 7 insertions(+), 10 deletions(-) > >>> > >>> diff --git a/drivers/gpu/drm/amd/display/Kconfig > >>> b/drivers/gpu/drm/amd/display/Kconfig > >>> index 2d8e55e29637..04ccfc70d583 100644 > >>> --- a/drivers/gpu/drm/amd/display/Kconfig > >>> +++ b/drivers/gpu/drm/amd/display/Kconfig > >>> @@ -42,16 +42,13 @@ config DEBUG_KERNEL_DC > >>>Choose this option if you want to hit kdgb_break in assert. > >>> > >>> config DRM_AMD_SECURE_DISPLAY > >>> -bool "Enable secure display support" > >>> -depends on DEBUG_FS > >>> -depends on DRM_AMD_DC_FP > >>> -help > >>> -Choose this option if you want to > >>> -support secure display > >>> - > >>> -This option enables the calculation > >>> -of crc of specific region via debugfs. > >>> -Cooperate with specific DMCU FW. > >>> + bool "Enable secure display support" > >>> + depends on DEBUG_FS > >>> + depends on DRM_AMD_DC_FP > >>> + help > >>> + Choose this option if you want to support secure display > >>> > >>> + This option enables the calculation of crc of specific > >>> region via > >>> + debugfs. Cooperate with specific DMCU FW. > >>> > >>> endmenu > >>> -- > >>> 2.25.1 > >>> > -- > Jingfeng
Re: [PATCH 17/30] fbdev/radeonfb: Reorder backlight and framebuffer cleanup
Thomas Zimmermann writes: > The driver's backlight code requires the framebuffer to be > registered. Therefore reorder the cleanup calls for both data > structures. The init calls are already in the correct order. > > Signed-off-by: Thomas Zimmermann > Cc: Benjamin Herrenschmidt > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 18/30] fbdev/radeonfb: Use hardware device as backlight parent
Thomas Zimmermann writes: > Use the hardware device in struct fb_info.device as parent of the > backlight device. Aligns the driver with the rest of the codebase > and prepares fbdev for making struct fb_info.dev optional. > > Signed-off-by: Thomas Zimmermann > Benjamin Herrenschmidt > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 19/30] fbdev/rivafb: Reorder backlight and framebuffer init/cleanup
Thomas Zimmermann writes: > The driver's backlight code requires the framebuffer to be > registered. Therefore reorder the init and cleanup calls for > both data structures. > > Signed-off-by: Thomas Zimmermann > Cc: Antonino Daplas > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 20/30] fbdev/rivafb: Use hardware device as backlight parent
Thomas Zimmermann writes: > Use the hardware device in struct fb_info.device as parent of the > backlight device. Aligns the driver with the rest of the codebase > and prepares fbdev for making struct fb_info.dev optional. > > Signed-off-by: Thomas Zimmermann > Cc: Antonino Daplas > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 21/30] fbdev/sm501fb: Output message with fb_err()
Thomas Zimmermann writes: > Fix case were dev_err() is being called with struct fb_info.dev. > Use fb_err() instead. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH v2] drm/vkms: Add support to 1D gamma LUT
On Tue, 6 Jun 2023 17:53:52 -0300
Arthur Grillo wrote:
> Support a 1D gamma LUT with interpolation for each color channel on the
> VKMS driver. Add a check for the LUT length by creating
> vkms_atomic_check().
>
> Tested with:
> igt@kms_color@gamma
> igt@kms_color@legacy-gamma
> igt@kms_color@invalid-gamma-lut-sizes
>
> v2:
> - Add interpolation between the values of the LUT (Simon Ser)
>
> Signed-off-by: Arthur Grillo
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 97
> drivers/gpu/drm/vkms/vkms_crtc.c | 3 +
> drivers/gpu/drm/vkms/vkms_drv.c | 20 +-
> drivers/gpu/drm/vkms/vkms_drv.h | 2 +
> 4 files changed, 121 insertions(+), 1 deletion(-)
>
Hi,
here are some casual suggestions that I hope are helpful, nothing more.
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 906d3df40cdb..24bffd98ba49 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -89,6 +90,100 @@ static void fill_background(const struct pixel_argb_u16
> *background_color,
> output_buffer->pixels[i] = *background_color;
> }
>
> +// lerp(a, b, t) = a + (b - a) * t
> +static u16 lerp_u16(u16 a, u16 b, s64 t)
> +{
> + s64 a_fp = drm_int2fixp(a);
> + s64 b_fp = drm_int2fixp(b);
> +
> + s64 ratio = drm_fixp_mul(b_fp - a_fp, t);
This is more like a delta than a ratio. A ratio would be a unitless
x/y, but delta has the same units as a_fp.
> +
> + return drm_fixp2int(a_fp + ratio);
> +}
> +
> +static s64 get_lut_index(u16 color_channel, size_t lut_length)
> +{
> + const s64 max_lut_index_fp = drm_int2fixp(lut_length - 1);
> + const s64 u16_max_fp = drm_int2fixp(0x);
> +
> + s64 ratio = drm_fixp_div(max_lut_index_fp, u16_max_fp);
This division is a constant for a specific LUT. Are you sure it won't
be calculated repeatedly for every transformed pixel component?
> +
> + s64 color_channel_fp = drm_int2fixp(color_channel);
> +
> + return drm_fixp_mul(color_channel_fp, ratio);
First this multiplication looked really strange, because "color
channel" is one of R, G or B, so likely 0, 1, or 2. But it's not color
channel, it is channel value.
> +}
> +
> +enum lut_area {
> + LUT_RED,
> + LUT_GREEN,
> + LUT_BLUE,
> + LUT_RESERVED
> +};
> +
> +static void apply_lut_to_color_channel(u16 *color_channel, enum lut_area
> area,
> +struct drm_color_lut *lut, size_t
> lut_length)
"u16 *color_channel" sounds like it is a pointer to a whole row of a
specific component of many pixels. I got confused, because I think
everything around here uses packed and not planar pixel layout, so it
looked really weird.
If you have nothing to return from a function otherwise, return the
computation result. In this case, pass the input value by-value, since
the indirection is not necessary. That makes the function easier to
read. Ideally the compiler will inline it anyway - a real function call
in innermost loop would be costly.
I suspect struct drm_color_lut and lut_length should be stored together
in a struct, so that you can also pre-compute and store 'ratio' in it.
> +{
> + s64 ratio;
> +
> + s64 lut_index = get_lut_index(*color_channel, lut_length);
> +
> + size_t floor_index = drm_fixp2int(lut_index);
> + size_t ceil_index = drm_fixp2int_ceil(lut_index);
> +
> + struct drm_color_lut floor_lut_value = lut[floor_index];
> + struct drm_color_lut ceil_lut_value = lut[ceil_index];
> +
> + u16 floor_color_channel;
> + u16 ceil_color_channel;
> +
> + switch (area) {
Is it a good idea from performance perspective to do a switch like this
three times per pixel? I cannot guess what the compiler would do.
It would be possible to reinterpret drm_color_lut as a __u16[4], so you
could simply index into it instead of using 'if'. Or maybe the compiler
already does that, or something even smarter? Only benchmarking would
tell which form is better.
The reason I'm paying so much attention to performance here is that
while VKMS is expected to be a slow software implementation, it could
still be smarter instead of even slower than necessary. That usually
translates to structuring code such that the innermost loops will do
only the absolute minimum required work, and everything possible is
pre-computed. I don't think it would make the code too complicated,
either.
Thanks,
pq
> + case LUT_RED:
> + floor_color_channel = floor_lut_value.red;
> + ceil_color_channel = ceil_lut_value.red;
> + break;
> + case LUT_GREEN:
> + floor_color_channel = floor_lut_value.green;
> + ceil_color_channel = ceil_lut_value.green;
> + break;
> + case LUT_BLUE:
> + floor_color_channel = floor_lut_v
Re: [Lima] [PATCH] drm/lima: fix sched context destroy
Acked-by: Christian König
While you are at it: It's beneficial for drivers to implement the flush
callback on the file descriptor.
This way you can still send a SIGKILL when a terminating application
waits for the entity to be flushed out to the hardware and all the
pending jobs are canceled.
Regards,
Christian.
Am 07.06.23 um 06:04 schrieb Qiang Yu:
Reviewed-by: Qiang Yu
Applied to drm-misc-fixes.
On Wed, Jun 7, 2023 at 9:18 AM Vasily Khoruzhick wrote:
On Tue, Jun 6, 2023 at 7:33 AM Erico Nunes wrote:
The drm sched entity must be flushed before finishing, to account for
jobs potentially still in flight at that time.
Lima did not do this flush until now, so switch the destroy call to the
drm_sched_entity_destroy() wrapper which will take care of that.
This fixes a regression on lima which started since the rework in
commit 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini")
where some specific types of applications may hang indefinitely.
Fixes: 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini")
Signed-off-by: Erico Nunes
Reviewed-by: Vasily Khoruzhick
---
drivers/gpu/drm/lima/lima_sched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_sched.c
index ff003403fbbc..ffd91a5ee299 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -165,7 +165,7 @@ int lima_sched_context_init(struct lima_sched_pipe *pipe,
void lima_sched_context_fini(struct lima_sched_pipe *pipe,
struct lima_sched_context *context)
{
- drm_sched_entity_fini(&context->base);
+ drm_sched_entity_destroy(&context->base);
}
struct dma_fence *lima_sched_context_queue_task(struct lima_sched_task *task)
--
2.40.1
Re: [PATCH v3 2/3] dt-bindings: display: panel: add fannal,c3004
Hello Krzysztof, uto, 6. lip 2023. u 16:43 Krzysztof Kozlowski napisao je: > > On 06/06/2023 16:07, Paulo Pavacic wrote: > > Added fannal to vendor-prefixes and dt bindings for Fannal C3004. > > Fannal C3004 is a 480x800 MIPI DSI Panel which requires > > DCS initialization sequences with certain delays between certain > > commands. > > > > Signed-off-by: Paulo Pavacic > > --- > > v4 changelog: > > - add spaces between properties > > ??? Added empty lines between properties in yml file > > I pointed out last incorrect versioning. This is v3, not v4. Or is it v4? It is v4 of the patch but v3 of the patchset. I wasn't sure whether somebody would complain if I were to name [patch 2/3] in a patch set with different version. I will try to edit changelog to match patchset version. > > What about my tag? > I have changed in MAINTAINERS file from "+C: matrix:r/mipi-dsi-bringup:matrix.org" to " +C: matrix:r/linux-drm:matrix.org". So I wasn't sure whether to add it. I will add it in future version of the patch. > What about my comment? > I thought you wanted me to have more generalized MAINTAINERS community URI that's why I have changed it to linux-drm. I will remove community URI in future version of the patch. > Best regards, > Krzysztof > Thanks, Paulo
Re: [PATCH] drm: gem: add an option for supporting the dma-coherent hardware.
Hi Sui,
Le mercredi 07 juin 2023 à 13:30 +0800, Sui Jingfeng a écrit :
> The single map_noncoherent member of struct drm_gem_dma_object may
> not
> sufficient for describing the backing memory of the GEM buffer
> object.
>
> Especially on dma-coherent systems, the backing memory is both cached
> coherent for multi-core CPUs and dma-coherent for peripheral device.
> Say architectures like X86-64, LoongArch64, Loongson Mips64, etc.
>
> Whether a peripheral device is dma-coherent or not can be
> implementation-dependent. The single map_noncoherent option is not
> enough
> to reflect real hardware anymore. For example, the Loongson LS3A4000
> CPU
> and LS2K2000/LS2K1000 SoC, peripheral device of such hardware
> platform
> allways snoop CPU's cache. Doing the allocation with
> dma_alloc_coherent
> function is preferred. The return buffer is cached, it should not
> using
> the default write-combine mapping. While with the current implement,
> there
> no way to tell the drm core to reflect this.
>
> This patch adds cached and coherent members to struct
> drm_gem_dma_object.
> which allow driver implements to inform the core. Introducing new
> mappings
> while keeping the original default behavior unchanged.
Did you try to simply set the "dma-coherent" property to the device's
node?
From what I understand if you add that property then Linux will use DMA
coherent memory even though you use dma_alloc_noncoherent() and the
sync_single_for_cpu() / sync_single_for_device() are then NOPs.
Cheers,
-Paul
> Signed-off-by: Sui Jingfeng
> ---
> drivers/gpu/drm/drm_fb_dma_helper.c | 11 +--
> drivers/gpu/drm/drm_fbdev_dma.c | 2 +-
> drivers/gpu/drm/drm_gem_dma_helper.c | 20
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 5 -
> drivers/gpu/drm/rcar-du/Kconfig | 2 --
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 4 +++-
> include/drm/drm_gem_dma_helper.h | 7 +--
> 7 files changed, 34 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_dma_helper.c
> b/drivers/gpu/drm/drm_fb_dma_helper.c
> index 3b535ad1b07c..93ff05041192 100644
> --- a/drivers/gpu/drm/drm_fb_dma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_dma_helper.c
> @@ -106,16 +106,15 @@ dma_addr_t drm_fb_dma_get_gem_addr(struct
> drm_framebuffer *fb,
> EXPORT_SYMBOL_GPL(drm_fb_dma_get_gem_addr);
>
> /**
> - * drm_fb_dma_sync_non_coherent - Sync GEM object to non-coherent
> backing
> - * memory
> + * drm_fb_dma_sync_non_coherent - Sync GEM object to cached backing
> memory
> * @drm: DRM device
> * @old_state: Old plane state
> * @state: New plane state
> *
> * This function can be used by drivers that use damage clips and
> have
> - * DMA GEM objects backed by non-coherent memory. Calling this
> function
> - * in a plane's .atomic_update ensures that all the data in the
> backing
> - * memory have been written to RAM.
> + * DMA GEM objects backed by cached memory. Calling this function in
> a
> + * plane's .atomic_update ensures that all the data in the backing
> memory
> + * have been written to RAM.
> */
> void drm_fb_dma_sync_non_coherent(struct drm_device *drm,
> struct drm_plane_state *old_state,
> @@ -131,7 +130,7 @@ void drm_fb_dma_sync_non_coherent(struct
> drm_device *drm,
>
> for (i = 0; i < finfo->num_planes; i++) {
> dma_obj = drm_fb_dma_get_gem_obj(state->fb, i);
> - if (!dma_obj->map_noncoherent)
> + if (dma_obj->cached && dma_obj->coherent)
> continue;
>
> daddr = drm_fb_dma_get_gem_addr(state->fb, state, i);
> diff --git a/drivers/gpu/drm/drm_fbdev_dma.c
> b/drivers/gpu/drm/drm_fbdev_dma.c
> index d86773fa8ab0..49fe9b284cc8 100644
> --- a/drivers/gpu/drm/drm_fbdev_dma.c
> +++ b/drivers/gpu/drm/drm_fbdev_dma.c
> @@ -131,7 +131,7 @@ static int drm_fbdev_dma_helper_fb_probe(struct
> drm_fb_helper *fb_helper,
>
> /* screen */
> info->flags |= FBINFO_VIRTFB; /* system memory */
> - if (dma_obj->map_noncoherent)
> + if (dma_obj->cached)
> info->flags |= FBINFO_READS_FAST; /* signal caching
> */
> info->screen_size = sizes->surface_height * fb->pitches[0];
> info->screen_buffer = map.vaddr;
> diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c
> b/drivers/gpu/drm/drm_gem_dma_helper.c
> index 870b90b78bc4..dec1d512bdf1 100644
> --- a/drivers/gpu/drm/drm_gem_dma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_dma_helper.c
> @@ -93,7 +93,11 @@ __drm_gem_dma_create(struct drm_device *drm,
> size_t size, bool private)
> drm_gem_private_object_init(drm, gem_obj, size);
>
> /* Always use writecombine for dma-buf mappings */
> - dma_obj->map_noncoherent = false;
> + /* FIXME: This is not always true, on some dma
> coherent system,
> + * cached mappings should be preferred over
> writecomb
Re: [PATCH v5 04/13] drm/connector: Use common colorspace_names array
On Tuesday, June 6th, 2023 at 22:25, Harry Wentland wrote: > We an use bitfields to track the support ones for HDMI Typo: "We can"
Re: [PATCH] drm: xlnx: zynqmp_dpsub: Add missing check for dma_set_mask
On 07/06/2023 08:07, Laurent Pinchart wrote:
Hello Jiasheng,
Thank you for the patch.
On Wed, Jun 07, 2023 at 10:05:29AM +0800, Jiasheng Jiang wrote:
Add check for dma_set_mask() and return the error if it fails.
Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort
Subsystem")
Signed-off-by: Jiasheng Jiang
---
drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
index bab862484d42..068413be6527 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
@@ -227,7 +227,9 @@ static int zynqmp_dpsub_probe(struct platform_device *pdev)
dpsub->dev = &pdev->dev;
platform_set_drvdata(pdev, dpsub);
- dma_set_mask(dpsub->dev, DMA_BIT_MASK(ZYNQMP_DISP_MAX_DMA_BIT));
+ ret = dma_set_mask(dpsub->dev, DMA_BIT_MASK(ZYNQMP_DISP_MAX_DMA_BIT));
+ if (ret)
+ return ret;
This seems reasonable.
Reviewed-by: Laurent Pinchart
Tomi, would you be able to quickly test this ?
Works for me.
Reviewed-by: Tomi Valkeinen
Tomi
Re: [PATCH v2 0/2] Enable GPU on Smaug
On Tue, May 16, 2023 at 09:28:27AM +0100, Diogo Ivo wrote: > Hello, > > This patch series enables the use of the GM20B GPU in the > Google Pixel C. > > Patch 1 adds the needed regulator DT node for the GPU. > > Patch 2 enables the GPU in the DT. Hello, Gentle ping on these patches. Thank you, Diogo Ivo
Re: [PATCH v5 06/13] drm/connector: Allow drivers to pass list of supported colorspaces
On Tuesday, June 6th, 2023 at 22:26, Harry Wentland
wrote:
> -int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
> +int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector,
> + u32 supported_colorspaces)
> {
> - return drm_mode_create_colorspace_property(connector, hdmi_colorspaces);
> + u32 colorspaces = supported_colorspaces & hdmi_colorspaces;
This creates a potentially weird situation where the driver passes a
non-0 supported_colorspaces, but the intersection with hdmi_colorspaces
ends up being empty, and all colorspaces end up being advertised.
[PATCH] accel/ivpu: Fix sporadic VPU boot failure
From: Andrzej Kacprowski
Wait for AON bit in HOST_SS_CPR_RST_CLR to return 0 before
starting VPUIP power up sequence, otherwise the VPU device
may sporadically fail to boot.
An error in power up sequence is propagated to the runtime
power management - the device will be in an error state
until the VPU driver is reloaded.
Fixes: 35b137630f08 ("accel/ivpu: Introduce a new DRM driver for Intel VPU")
Cc: sta...@vger.kernel.org # 6.3.x
Signed-off-by: Andrzej Kacprowski
Reviewed-by: Krystian Pradzynski
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/ivpu_hw_mtl.c | 13 -
drivers/accel/ivpu/ivpu_hw_mtl_reg.h | 1 +
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/accel/ivpu/ivpu_hw_mtl.c b/drivers/accel/ivpu/ivpu_hw_mtl.c
index 382ec127be8e..efae679d7b7a 100644
--- a/drivers/accel/ivpu/ivpu_hw_mtl.c
+++ b/drivers/accel/ivpu/ivpu_hw_mtl.c
@@ -197,6 +197,11 @@ static void ivpu_pll_init_frequency_ratios(struct
ivpu_device *vdev)
hw->pll.pn_ratio = clamp_t(u8, fuse_pn_ratio, hw->pll.min_ratio,
hw->pll.max_ratio);
}
+static int ivpu_hw_mtl_wait_for_vpuip_bar(struct ivpu_device *vdev)
+{
+ return REGV_POLL_FLD(MTL_VPU_HOST_SS_CPR_RST_CLR, AON, 0, 100);
+}
+
static int ivpu_pll_drive(struct ivpu_device *vdev, bool enable)
{
struct ivpu_hw_info *hw = vdev->hw;
@@ -239,6 +244,12 @@ static int ivpu_pll_drive(struct ivpu_device *vdev, bool
enable)
ivpu_err(vdev, "Timed out waiting for PLL ready
status\n");
return ret;
}
+
+ ret = ivpu_hw_mtl_wait_for_vpuip_bar(vdev);
+ if (ret) {
+ ivpu_err(vdev, "Timed out waiting for VPUIP bar\n");
+ return ret;
+ }
}
return 0;
@@ -256,7 +267,7 @@ static int ivpu_pll_disable(struct ivpu_device *vdev)
static void ivpu_boot_host_ss_rst_clr_assert(struct ivpu_device *vdev)
{
- u32 val = REGV_RD32(MTL_VPU_HOST_SS_CPR_RST_CLR);
+ u32 val = 0;
val = REG_SET_FLD(MTL_VPU_HOST_SS_CPR_RST_CLR, TOP_NOC, val);
val = REG_SET_FLD(MTL_VPU_HOST_SS_CPR_RST_CLR, DSS_MAS, val);
diff --git a/drivers/accel/ivpu/ivpu_hw_mtl_reg.h
b/drivers/accel/ivpu/ivpu_hw_mtl_reg.h
index d83ccfd9a871..593b8ff07417 100644
--- a/drivers/accel/ivpu/ivpu_hw_mtl_reg.h
+++ b/drivers/accel/ivpu/ivpu_hw_mtl_reg.h
@@ -91,6 +91,7 @@
#define MTL_VPU_HOST_SS_CPR_RST_SET_MSS_MAS_MASK
BIT_MASK(11)
#define MTL_VPU_HOST_SS_CPR_RST_CLR
0x0098u
+#define MTL_VPU_HOST_SS_CPR_RST_CLR_AON_MASK
BIT_MASK(0)
#define MTL_VPU_HOST_SS_CPR_RST_CLR_TOP_NOC_MASK
BIT_MASK(1)
#define MTL_VPU_HOST_SS_CPR_RST_CLR_DSS_MAS_MASK
BIT_MASK(10)
#define MTL_VPU_HOST_SS_CPR_RST_CLR_MSS_MAS_MASK
BIT_MASK(11)
--
2.25.1
Re: [PATCH] drm/ingenic: Kconfig: select REGMAP and REGMAP_MMIO
Hi Sui, Le mercredi 07 juin 2023 à 15:22 +0800, Sui Jingfeng a écrit : > Otherwise its failed to pass basic compile test on platform without > REGMAP_MMIO selected by defconfig > > make -j$(nproc) ARCH=mips CROSS_COMPILE=mips64el-linux-gnuabi64- > > SYNC include/config/auto.conf.cmd > Checking missing-syscalls for N32 > CALL scripts/checksyscalls.sh > Checking missing-syscalls for O32 > CALL scripts/checksyscalls.sh > CALL scripts/checksyscalls.sh > MODPOST Module.symvers > ERROR: modpost: "__devm_regmap_init_mmio_clk" > [drivers/gpu/drm/ingenic/ingenic-drm.ko] undefined! > make[1]: *** [scripts/Makefile.modpost:136: Module.symvers] Error 1 > make: *** [Makefile:1978: modpost] Error 2 > > Signed-off-by: Sui Jingfeng > --- > drivers/gpu/drm/ingenic/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/ingenic/Kconfig > b/drivers/gpu/drm/ingenic/Kconfig > index a53f475d33df..7457c0b65034 100644 > --- a/drivers/gpu/drm/ingenic/Kconfig > +++ b/drivers/gpu/drm/ingenic/Kconfig > @@ -5,6 +5,8 @@ config DRM_INGENIC > depends on CMA > depends on OF > depends on COMMON_CLK > + select REGMAP > + select REGMAP_MMIO nit: order alphabetically (move them after the DRM_* ones). Cheers, -Paul > select DRM_BRIDGE > select DRM_PANEL_BRIDGE > select DRM_KMS_HELPER
Re: [PATCH v5 04/13] drm/connector: Use common colorspace_names array
On Tuesday, June 6th, 2023 at 22:25, Harry Wentland wrote: > + if (supported_colorspaces != 0 && (colorspaces & BIT(i)) == 0) This patch actually also introduces a change in behavior: passing no colorspace will make the function advertise all colorspaces. I have a hard time understanding how this can be useful: we want to either advertise all DP colorspaces, or all HDMI colorspaces, but not both? One way to fix this would be to handle the "zero means everything" behavior in the specific DP/HDMI callers. But I wonder, is it really worth the magic if we can expose a simple const variable with all DP/HDMI colorspaces?
Re: [PATCH] drm/amdgpu: display/Kconfig: replace leading spaces with tab
Hi, On 2023/6/7 17:09, Chen, Guchun wrote: [Public] It's https://gitlab.freedesktop.org/agd5f/linux/-/tree/amd-staging-drm-next?ref_type=heads. Latest patches including yours's will be pushed to this branch after a while. Now I know, thanks for your kindness reply. Regards, Guchun -Original Message- From: amd-gfx On Behalf Of Sui Jingfeng Sent: Wednesday, June 7, 2023 2:34 PM To: Alex Deucher Cc: Li, Sun peng (Leo) ; David Airlie ; Pan, Xinhui ; Siqueira, Rodrigo ; linux-ker...@vger.kernel.org; dri- de...@lists.freedesktop.org; amd-...@lists.freedesktop.org; Daniel Vetter ; Deucher, Alexander ; Wentland, Harry ; Koenig, Christian Subject: Re: [PATCH] drm/amdgpu: display/Kconfig: replace leading spaces with tab https://cgit.freedesktop.org/amd/drm-amd/ This one has a long time with no update. On 2023/6/7 14:31, Sui Jingfeng wrote: Hi, On 2023/6/7 03:15, Alex Deucher wrote: Applied. Thanks! Where is the official branch of drm/amdgpu, I can't find it on the internet. Sorry for asking this silly question. Alex On Tue, Jun 6, 2023 at 9:33 AM Sui Jingfeng wrote: This patch replace the leading spaces with tab, make them keep aligned with the rest of the config options. No functional change. Signed-off-by: Sui Jingfeng --- drivers/gpu/drm/amd/display/Kconfig | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/amd/display/Kconfig b/drivers/gpu/drm/amd/display/Kconfig index 2d8e55e29637..04ccfc70d583 100644 --- a/drivers/gpu/drm/amd/display/Kconfig +++ b/drivers/gpu/drm/amd/display/Kconfig @@ -42,16 +42,13 @@ config DEBUG_KERNEL_DC Choose this option if you want to hit kdgb_break in assert. config DRM_AMD_SECURE_DISPLAY -bool "Enable secure display support" -depends on DEBUG_FS -depends on DRM_AMD_DC_FP -help -Choose this option if you want to -support secure display - -This option enables the calculation -of crc of specific region via debugfs. -Cooperate with specific DMCU FW. + bool "Enable secure display support" + depends on DEBUG_FS + depends on DRM_AMD_DC_FP + help + Choose this option if you want to support secure display + This option enables the calculation of crc of specific region via + debugfs. Cooperate with specific DMCU FW. endmenu -- 2.25.1 -- Jingfeng -- Jingfeng
Re: [PATCH v3 2/3] dt-bindings: display: panel: add fannal,c3004
On 07/06/2023 11:29, Paulo Pavacic wrote: > Hello Krzysztof, > > uto, 6. lip 2023. u 16:43 Krzysztof Kozlowski > napisao je: >> >> On 06/06/2023 16:07, Paulo Pavacic wrote: >>> Added fannal to vendor-prefixes and dt bindings for Fannal C3004. >>> Fannal C3004 is a 480x800 MIPI DSI Panel which requires >>> DCS initialization sequences with certain delays between certain >>> commands. >>> >>> Signed-off-by: Paulo Pavacic >>> --- >>> v4 changelog: >>> - add spaces between properties >> >> ??? > > Added empty lines between properties in yml file > >> >> I pointed out last incorrect versioning. This is v3, not v4. Or is it v4? > > It is v4 of the patch but v3 of the patchset. I wasn't sure whether > somebody would complain if I were to name [patch 2/3] in a patch set > with different version. I will try to edit changelog to match patchset > version. Please maintain consistent versioning. There is only one version - that's the version you are sending. > >> >> What about my tag? >> > > I have changed in MAINTAINERS file from "+C: > matrix:r/mipi-dsi-bringup:matrix.org" to " +C: > matrix:r/linux-drm:matrix.org". So I wasn't sure whether to add it. > I will add it in future version of the patch. Keep the tags you received. > >> What about my comment? >> > > I thought you wanted me to have more generalized MAINTAINERS community > URI that's why I have changed it to linux-drm. I will remove community > URI in future version of the patch. The chat should be in subsystem entry, not in individual drivers. People will not hop between 100 IRC rooms to figure out discussion. Just like we have only one mailing list dedicated to given topic. Best regards, Krzysztof
[PATCH] drm/panel-edp: Add AUO B116XAB01.4 edp panel entry
Add a panel entry for the AUO B116XAB01.4 edp panel, found in the Acer
Chromebook Spin 311 (CP311-3H) laptop.
Signed-off-by: Laura Nao
---
drivers/gpu/drm/panel/panel-edp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index fbd114b4f0be..5f6297531347 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -1867,6 +1867,7 @@ static const struct panel_delay delay_200_500_e200 = {
static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('A', 'U', 'O', 0x1062, &delay_200_500_e50,
"B120XAN01.0"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x1e9b, &delay_200_500_e50,
"B133UAN02.1"),
+ EDP_PANEL_ENTRY('A', 'U', 'O', 0x145c, &delay_200_500_e50,
"B116XAB01.4"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x1ea5, &delay_200_500_e50,
"B116XAK01.6"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, &auo_b116xak01.delay,
"B116XAK01"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x582d, &delay_200_500_e50,
"B133UAN01.0"),
--
2.30.2
Re: [PATCH] drm/ingenic: Kconfig: select REGMAP and REGMAP_MMIO
Ok, thanks On 2023/6/7 17:46, Paul Cercueil wrote: Hi Sui, Le mercredi 07 juin 2023 à 15:22 +0800, Sui Jingfeng a écrit : Otherwise its failed to pass basic compile test on platform without REGMAP_MMIO selected by defconfig make -j$(nproc) ARCH=mips CROSS_COMPILE=mips64el-linux-gnuabi64- SYNC include/config/auto.conf.cmd Checking missing-syscalls for N32 CALL scripts/checksyscalls.sh Checking missing-syscalls for O32 CALL scripts/checksyscalls.sh CALL scripts/checksyscalls.sh MODPOST Module.symvers ERROR: modpost: "__devm_regmap_init_mmio_clk" [drivers/gpu/drm/ingenic/ingenic-drm.ko] undefined! make[1]: *** [scripts/Makefile.modpost:136: Module.symvers] Error 1 make: *** [Makefile:1978: modpost] Error 2 Signed-off-by: Sui Jingfeng --- drivers/gpu/drm/ingenic/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig index a53f475d33df..7457c0b65034 100644 --- a/drivers/gpu/drm/ingenic/Kconfig +++ b/drivers/gpu/drm/ingenic/Kconfig @@ -5,6 +5,8 @@ config DRM_INGENIC depends on CMA depends on OF depends on COMMON_CLK + select REGMAP + select REGMAP_MMIO nit: order alphabetically (move them after the DRM_* ones). Cheers, -Paul select DRM_BRIDGE select DRM_PANEL_BRIDGE select DRM_KMS_HELPER -- Jingfeng
Re: [PATCH] drm: gem: add an option for supporting the dma-coherent hardware.
Hi,
On 2023/6/7 17:36, Paul Cercueil wrote:
Hi Sui,
Le mercredi 07 juin 2023 à 13:30 +0800, Sui Jingfeng a écrit :
The single map_noncoherent member of struct drm_gem_dma_object may
not
sufficient for describing the backing memory of the GEM buffer
object.
Especially on dma-coherent systems, the backing memory is both cached
coherent for multi-core CPUs and dma-coherent for peripheral device.
Say architectures like X86-64, LoongArch64, Loongson Mips64, etc.
Whether a peripheral device is dma-coherent or not can be
implementation-dependent. The single map_noncoherent option is not
enough
to reflect real hardware anymore. For example, the Loongson LS3A4000
CPU
and LS2K2000/LS2K1000 SoC, peripheral device of such hardware
platform
allways snoop CPU's cache. Doing the allocation with
dma_alloc_coherent
function is preferred. The return buffer is cached, it should not
using
the default write-combine mapping. While with the current implement,
there
no way to tell the drm core to reflect this.
This patch adds cached and coherent members to struct
drm_gem_dma_object.
which allow driver implements to inform the core. Introducing new
mappings
while keeping the original default behavior unchanged.
Did you try to simply set the "dma-coherent" property to the device's
node?
But this approach can only be applied for the device driver with DT support.
X86-64, Loongson ls3a4000 mips64, Loongson ls3a5000 CPU typically do not
have DT support.
They using ACPI to pass parameter from the firmware to Linux kernel.
You approach will lost the effectiveness on such a case.
From what I understand if you add that property then Linux will use DMA
coherent memory even though you use dma_alloc_noncoherent() and the
sync_single_for_cpu() / sync_single_for_device() are then NOPs.
Please do not mitigate the problems with confusing method.
This approach not only tend to generate confusion but also
implement-dependent
and arch-dependent. It's definitely problematic.
How does the dma_alloc_coherent/dma_alloc_noncoherent is a ARCH specific
thing.
Dependent on how does the arch_dma_ops is implemented.
The definition of the coherent on different ARCH has different meanings.
The definition of the wirte-combine on different ARCH has different
meanings.
The wirte-combine(uncache acceleration) on mips is non dma-coherent.
But on arm, It seem that wirte-combine is coherent. (guaranteed by arch
implement).
I also heard using dma_alloc_coherent to allocation the buffer for the
non-coherent doesn't hurt, but the reverse is not true.
But please do not create confusion.
software composite is faster because better cacheusing rate and
cache is faster to read.
It is faster because it is cached, not because it is non-coherent.
non-coherent is arch thing and/or driver-side thing,
it is a side effect of using the cached mapping.
It should left to driver to handle such a side effect. The device driver
know their device, so its the device driver's responsibility to maintain
the coherency. On loongson platform, we don't need to call
drm_fb_dma_sync_non_coherent() function, Its already guaranteed by hardware.
Cheers,
-Paul
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/drm_fb_dma_helper.c | 11 +--
drivers/gpu/drm/drm_fbdev_dma.c | 2 +-
drivers/gpu/drm/drm_gem_dma_helper.c | 20
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 5 -
drivers/gpu/drm/rcar-du/Kconfig | 2 --
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 4 +++-
include/drm/drm_gem_dma_helper.h | 7 +--
7 files changed, 34 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_dma_helper.c
b/drivers/gpu/drm/drm_fb_dma_helper.c
index 3b535ad1b07c..93ff05041192 100644
--- a/drivers/gpu/drm/drm_fb_dma_helper.c
+++ b/drivers/gpu/drm/drm_fb_dma_helper.c
@@ -106,16 +106,15 @@ dma_addr_t drm_fb_dma_get_gem_addr(struct
drm_framebuffer *fb,
EXPORT_SYMBOL_GPL(drm_fb_dma_get_gem_addr);
/**
- * drm_fb_dma_sync_non_coherent - Sync GEM object to non-coherent
backing
- * memory
+ * drm_fb_dma_sync_non_coherent - Sync GEM object to cached backing
memory
* @drm: DRM device
* @old_state: Old plane state
* @state: New plane state
*
* This function can be used by drivers that use damage clips and
have
- * DMA GEM objects backed by non-coherent memory. Calling this
function
- * in a plane's .atomic_update ensures that all the data in the
backing
- * memory have been written to RAM.
+ * DMA GEM objects backed by cached memory. Calling this function in
a
+ * plane's .atomic_update ensures that all the data in the backing
memory
+ * have been written to RAM.
*/
void drm_fb_dma_sync_non_coherent(struct drm_device *drm,
struct drm_plane_state *old_state,
@@ -131,7 +130,7 @@ void drm_fb_dma_sync_non_coherent(struct
drm_device *drm,
for (i = 0; i < finfo->num_planes; i++) {
[PATCH v8 1/8] drm/etnaviv: add a dedicated function to register an irq handler
From: Sui Jingfeng
Because getting IRQ from a device is platform-dependent, PCI devices have
different methods for getting an IRQ. This patch is a preparation patch to
extend the driver for the PCI device support.
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: Philipp Zabel
Cc: Bjorn Helgaas
Cc: Daniel Vetter
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 34 ---
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index de8c9894967c..b9c12d3145a2 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1817,6 +1817,29 @@ static const struct of_device_id etnaviv_gpu_match[] = {
};
MODULE_DEVICE_TABLE(of, etnaviv_gpu_match);
+static int etnaviv_gpu_register_irq(struct etnaviv_gpu *gpu, int irq)
+{
+ struct device *dev = gpu->dev;
+ int err;
+
+ if (irq < 0) {
+ dev_err(dev, "failed to get irq: %d\n", irq);
+ return irq;
+ }
+
+ err = devm_request_irq(dev, irq, irq_handler, 0, dev_name(dev), gpu);
+ if (err) {
+ dev_err(dev, "failed to request irq %u: %d\n", irq, err);
+ return err;
+ }
+
+ gpu->irq = irq;
+
+ dev_info(dev, "irq(%d) handler registered\n", irq);
+
+ return 0;
+}
+
static int etnaviv_gpu_platform_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -1837,16 +1860,9 @@ static int etnaviv_gpu_platform_probe(struct
platform_device *pdev)
return PTR_ERR(gpu->mmio);
/* Get Interrupt: */
- gpu->irq = platform_get_irq(pdev, 0);
- if (gpu->irq < 0)
- return gpu->irq;
-
- err = devm_request_irq(&pdev->dev, gpu->irq, irq_handler, 0,
- dev_name(gpu->dev), gpu);
- if (err) {
- dev_err(dev, "failed to request IRQ%u: %d\n", gpu->irq, err);
+ err = etnaviv_gpu_register_irq(gpu, platform_get_irq(pdev, 0));
+ if (err)
return err;
- }
/* Get Clocks: */
gpu->clk_reg = devm_clk_get_optional(&pdev->dev, "reg");
--
2.25.1
[PATCH v8 0/8] drm/etnaviv: add pci device driver support
From: Sui Jingfeng There is a Vivante GC1000 (v5037) in LS2K1000 and LS7A1000, this GPU is a PCI device, and it has 2D and 3D cores in the same core. Thus, this patch set is trying to add PCI device driver support to etnaviv. v6: * Fix build issue on system without CONFIG_PCI enabled v7: * Add a separate patch for the platform driver rearrangement (Bjorn) * Switch to runtime check if the GPU is dma coherent or not (Lucas) * Add ETNAVIV_PARAM_GPU_COHERENT to allow userspace to query (Lucas) * Remove etnaviv_gpu.no_clk member (Lucas) * Various Typos and coding style fixed (Bjorn) v8: * Fix typos and remove unnecessary header included (Bjorn). * Add a dedicated function to create the virtual master platform device. Sui Jingfeng (8): drm/etnaviv: add a dedicated function to register an irq handler drm/etnaviv: add a dedicated function to get various clocks drm/etnaviv: add dedicated functions to create and destroy platform devices drm/etnaviv: add helpers for private data construction and destruction drm/etnaviv: allow bypass component framework drm/etnaviv: add driver support for the PCI devices drm/etnaviv: add support for the dma coherent device drm/etnaviv: add a dedicated function to create the virtual master drivers/gpu/drm/etnaviv/Kconfig | 10 + drivers/gpu/drm/etnaviv/Makefile| 2 + drivers/gpu/drm/etnaviv/etnaviv_drv.c | 257 ++-- drivers/gpu/drm/etnaviv/etnaviv_drv.h | 10 + drivers/gpu/drm/etnaviv/etnaviv_gem.c | 22 +- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 7 +- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 168 - drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 9 + drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c | 75 ++ drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h | 9 + include/uapi/drm/etnaviv_drm.h | 1 + 11 files changed, 440 insertions(+), 130 deletions(-) create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h -- 2.25.1
[PATCH v8 2/8] drm/etnaviv: add a dedicated function to get various clocks
From: Sui Jingfeng
Because it is also platform-dependent, there are environments where don't
have CLK subsystem support, for example, discreted PCI GPUs. So don't rage
quit if there is no CLK subsystem support.
For the GPU in LS7A1000 and LS2K1000, the working frequency of the GPU is
tuned by configuring the PLL registers.
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: Philipp Zabel
Cc: Bjorn Helgaas
Cc: Daniel Vetter
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 53 ---
1 file changed, 32 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index b9c12d3145a2..d4f99cb0456f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1565,6 +1565,35 @@ static irqreturn_t irq_handler(int irq, void *data)
return ret;
}
+static int etnaviv_gpu_clk_get(struct etnaviv_gpu *gpu)
+{
+ struct device *dev = gpu->dev;
+
+ gpu->clk_reg = devm_clk_get_optional(dev, "reg");
+ DBG("clk_reg: %p", gpu->clk_reg);
+ if (IS_ERR(gpu->clk_reg))
+ return PTR_ERR(gpu->clk_reg);
+
+ gpu->clk_bus = devm_clk_get_optional(dev, "bus");
+ DBG("clk_bus: %p", gpu->clk_bus);
+ if (IS_ERR(gpu->clk_bus))
+ return PTR_ERR(gpu->clk_bus);
+
+ gpu->clk_core = devm_clk_get(dev, "core");
+ DBG("clk_core: %p", gpu->clk_core);
+ if (IS_ERR(gpu->clk_core))
+ return PTR_ERR(gpu->clk_core);
+ gpu->base_rate_core = clk_get_rate(gpu->clk_core);
+
+ gpu->clk_shader = devm_clk_get_optional(dev, "shader");
+ DBG("clk_shader: %p", gpu->clk_shader);
+ if (IS_ERR(gpu->clk_shader))
+ return PTR_ERR(gpu->clk_shader);
+ gpu->base_rate_shader = clk_get_rate(gpu->clk_shader);
+
+ return 0;
+}
+
static int etnaviv_gpu_clk_enable(struct etnaviv_gpu *gpu)
{
int ret;
@@ -1865,27 +1894,9 @@ static int etnaviv_gpu_platform_probe(struct
platform_device *pdev)
return err;
/* Get Clocks: */
- gpu->clk_reg = devm_clk_get_optional(&pdev->dev, "reg");
- DBG("clk_reg: %p", gpu->clk_reg);
- if (IS_ERR(gpu->clk_reg))
- return PTR_ERR(gpu->clk_reg);
-
- gpu->clk_bus = devm_clk_get_optional(&pdev->dev, "bus");
- DBG("clk_bus: %p", gpu->clk_bus);
- if (IS_ERR(gpu->clk_bus))
- return PTR_ERR(gpu->clk_bus);
-
- gpu->clk_core = devm_clk_get(&pdev->dev, "core");
- DBG("clk_core: %p", gpu->clk_core);
- if (IS_ERR(gpu->clk_core))
- return PTR_ERR(gpu->clk_core);
- gpu->base_rate_core = clk_get_rate(gpu->clk_core);
-
- gpu->clk_shader = devm_clk_get_optional(&pdev->dev, "shader");
- DBG("clk_shader: %p", gpu->clk_shader);
- if (IS_ERR(gpu->clk_shader))
- return PTR_ERR(gpu->clk_shader);
- gpu->base_rate_shader = clk_get_rate(gpu->clk_shader);
+ err = etnaviv_gpu_clk_get(gpu);
+ if (err)
+ return err;
/* TODO: figure out max mapped size */
dev_set_drvdata(dev, gpu);
--
2.25.1
[PATCH v8 4/8] drm/etnaviv: add helpers for private data construction and destruction
From: Sui Jingfeng
struct etnaviv_drm_private contains a lot of common resources that are
shared by all GPUs. This patch introduces two dedicated functions, which
is for the construction and destruction of instances of this structure.
The idea is to avoid leaking its members outside. The error handling code
can also be simplified.
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: Philipp Zabel
Cc: Bjorn Helgaas
Cc: Daniel Vetter
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 73 +--
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 +
2 files changed, 47 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index cec005035d0e..6a048be02857 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -24,9 +24,47 @@
#include "etnaviv_perfmon.h"
/*
- * DRM operations:
+ * etnaviv private data construction and destructions:
*/
+static struct etnaviv_drm_private *
+etnaviv_alloc_private(struct device *dev, struct drm_device *drm)
+{
+ struct etnaviv_drm_private *priv;
+
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return ERR_PTR(-ENOMEM);
+
+ priv->drm = drm;
+
+ xa_init_flags(&priv->active_contexts, XA_FLAGS_ALLOC);
+
+ mutex_init(&priv->gem_lock);
+ INIT_LIST_HEAD(&priv->gem_list);
+ priv->num_gpus = 0;
+ priv->shm_gfp_mask = GFP_HIGHUSER | __GFP_RETRY_MAYFAIL | __GFP_NOWARN;
+ priv->cmdbuf_suballoc = etnaviv_cmdbuf_suballoc_new(dev);
+ if (IS_ERR(priv->cmdbuf_suballoc)) {
+ kfree(priv);
+ dev_err(dev, "Failed to create cmdbuf suballocator\n");
+ return ERR_PTR(-ENOMEM);
+ }
+
+ return priv;
+}
+
+static void etnaviv_free_private(struct etnaviv_drm_private *priv)
+{
+ if (!priv)
+ return;
+
+ etnaviv_cmdbuf_suballoc_destroy(priv->cmdbuf_suballoc);
+
+ xa_destroy(&priv->active_contexts);
+
+ kfree(priv);
+}
static void load_gpu(struct drm_device *dev)
{
@@ -511,35 +549,21 @@ static int etnaviv_bind(struct device *dev)
if (IS_ERR(drm))
return PTR_ERR(drm);
- priv = kzalloc(sizeof(*priv), GFP_KERNEL);
- if (!priv) {
- dev_err(dev, "failed to allocate private data\n");
- ret = -ENOMEM;
+ priv = etnaviv_alloc_private(dev, drm);
+ if (IS_ERR(priv)) {
+ ret = PTR_ERR(priv);
goto out_put;
}
+
drm->dev_private = priv;
dma_set_max_seg_size(dev, SZ_2G);
- xa_init_flags(&priv->active_contexts, XA_FLAGS_ALLOC);
-
- mutex_init(&priv->gem_lock);
- INIT_LIST_HEAD(&priv->gem_list);
- priv->num_gpus = 0;
- priv->shm_gfp_mask = GFP_HIGHUSER | __GFP_RETRY_MAYFAIL | __GFP_NOWARN;
-
- priv->cmdbuf_suballoc = etnaviv_cmdbuf_suballoc_new(drm->dev);
- if (IS_ERR(priv->cmdbuf_suballoc)) {
- dev_err(drm->dev, "Failed to create cmdbuf suballocator\n");
- ret = PTR_ERR(priv->cmdbuf_suballoc);
- goto out_free_priv;
- }
-
dev_set_drvdata(dev, drm);
ret = component_bind_all(dev, drm);
if (ret < 0)
- goto out_destroy_suballoc;
+ goto out_free_priv;
load_gpu(drm);
@@ -551,10 +575,8 @@ static int etnaviv_bind(struct device *dev)
out_unbind:
component_unbind_all(dev, drm);
-out_destroy_suballoc:
- etnaviv_cmdbuf_suballoc_destroy(priv->cmdbuf_suballoc);
out_free_priv:
- kfree(priv);
+ etnaviv_free_private(priv);
out_put:
drm_dev_put(drm);
@@ -570,12 +592,9 @@ static void etnaviv_unbind(struct device *dev)
component_unbind_all(dev, drm);
- etnaviv_cmdbuf_suballoc_destroy(priv->cmdbuf_suballoc);
-
- xa_destroy(&priv->active_contexts);
+ etnaviv_free_private(priv);
drm->dev_private = NULL;
- kfree(priv);
drm_dev_put(drm);
}
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index b3eb1662e90c..e58f82e698de 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -35,6 +35,7 @@ struct etnaviv_file_private {
};
struct etnaviv_drm_private {
+ struct drm_device *drm;
int num_gpus;
struct etnaviv_gpu *gpu[ETNA_MAX_PIPES];
gfp_t shm_gfp_mask;
--
2.25.1
[PATCH v8 6/8] drm/etnaviv: add driver support for the PCI devices
From: Sui Jingfeng
This patch adds PCI driver support on top of what we already have. Take
the GC1000 in LS7A1000/LS2K1000 as the first instance of the PCI device
driver. There is only one GPU core for the GC1000 in the LS7A1000 and
LS2K1000. Therefore, component frameworks can be avoided.
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: Philipp Zabel
Cc: Bjorn Helgaas
Cc: Daniel Vetter
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/Kconfig | 10 +++
drivers/gpu/drm/etnaviv/Makefile | 2 +
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 20 +-
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 3 +
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 8 +--
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 6 ++
drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c | 75 +++
drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h | 9 +++
8 files changed, 126 insertions(+), 7 deletions(-)
create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.c
create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_pci_drv.h
diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
index faa7fc68b009..1b5b162efb61 100644
--- a/drivers/gpu/drm/etnaviv/Kconfig
+++ b/drivers/gpu/drm/etnaviv/Kconfig
@@ -15,6 +15,16 @@ config DRM_ETNAVIV
help
DRM driver for Vivante GPUs.
+config DRM_ETNAVIV_PCI_DRIVER
+ bool "enable ETNAVIV PCI driver support"
+ depends on DRM_ETNAVIV
+ depends on PCI
+ default y
+ help
+ Compile in support for PCI GPUs of Vivante.
+ For example, the GC1000 in LS7A1000 and LS2K1000.
+ Say Y if you have such a hardware.
+
config DRM_ETNAVIV_THERMAL
bool "enable ETNAVIV thermal throttling"
depends on DRM_ETNAVIV
diff --git a/drivers/gpu/drm/etnaviv/Makefile b/drivers/gpu/drm/etnaviv/Makefile
index 46e5ffad69a6..6829e1ebf2db 100644
--- a/drivers/gpu/drm/etnaviv/Makefile
+++ b/drivers/gpu/drm/etnaviv/Makefile
@@ -16,4 +16,6 @@ etnaviv-y := \
etnaviv_perfmon.o \
etnaviv_sched.o
+etnaviv-$(CONFIG_DRM_ETNAVIV_PCI_DRIVER) += etnaviv_pci_drv.o
+
obj-$(CONFIG_DRM_ETNAVIV) += etnaviv.o
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 93ca240cd4c0..033afe542a3a 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -23,6 +23,10 @@
#include "etnaviv_mmu.h"
#include "etnaviv_perfmon.h"
+#ifdef CONFIG_DRM_ETNAVIV_PCI_DRIVER
+#include "etnaviv_pci_drv.h"
+#endif
+
/*
* etnaviv private data construction and destructions:
*/
@@ -538,7 +542,7 @@ static const struct drm_driver etnaviv_drm_driver = {
static struct etnaviv_drm_private *etna_private_ptr;
-static int etnaviv_drm_bind(struct device *dev, bool component)
+int etnaviv_drm_bind(struct device *dev, bool component)
{
struct etnaviv_drm_private *priv;
struct drm_device *drm;
@@ -588,7 +592,7 @@ static int etnaviv_drm_bind(struct device *dev, bool
component)
return ret;
}
-static void etnaviv_drm_unbind(struct device *dev, bool component)
+void etnaviv_drm_unbind(struct device *dev, bool component)
{
struct etnaviv_drm_private *priv = etna_private_ptr;
struct drm_device *drm = priv->drm;
@@ -746,6 +750,12 @@ static int __init etnaviv_init(void)
if (ret != 0)
goto unregister_gpu_driver;
+#ifdef CONFIG_DRM_ETNAVIV_PCI_DRIVER
+ ret = etnaviv_register_pci_driver();
+ if (ret != 0)
+ goto unregister_platform_driver;
+#endif
+
/*
* If the DT contains at least one available GPU device, instantiate
* the DRM platform device.
@@ -763,7 +773,7 @@ static int __init etnaviv_init(void)
break;
}
- return 0;
+ return ret;
unregister_platform_driver:
platform_driver_unregister(&etnaviv_platform_driver);
@@ -778,6 +788,10 @@ static void __exit etnaviv_exit(void)
etnaviv_destroy_platform_device(&etnaviv_platform_device);
platform_driver_unregister(&etnaviv_platform_driver);
platform_driver_unregister(&etnaviv_gpu_driver);
+
+#ifdef CONFIG_DRM_ETNAVIV_PCI_DRIVER
+ etnaviv_unregister_pci_driver();
+#endif
}
module_exit(etnaviv_exit);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index e58f82e698de..9cd72948cfad 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -83,6 +83,9 @@ bool etnaviv_cmd_validate_one(struct etnaviv_gpu *gpu,
u32 *stream, unsigned int size,
struct drm_etnaviv_gem_submit_reloc *relocs, unsigned int reloc_size);
+int etnaviv_drm_bind(struct device *dev, bool component);
+void etnaviv_drm_unbind(struct device *dev, bool component);
+
#ifdef CONFIG_DEBUG_FS
void etnaviv_gem_describe_objects(struct etnaviv_drm_private *priv,
struct seq_file *m);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu
[PATCH v8 3/8] drm/etnaviv: add dedicated functions to create and destroy platform devices
From: Sui Jingfeng
Also rename the virtual master platform device as etnaviv_platform_device,
for better reflection that it is a platform device, not a DRM device.
Another benefit is that we no longer need to call of_node_put() for three
different cases, Instead, we only need to call it once.
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: Philipp Zabel
Cc: Bjorn Helgaas
Cc: Daniel Vetter
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 56 +++
1 file changed, 39 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 31a7f59ccb49..cec005035d0e 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -656,12 +656,44 @@ static struct platform_driver etnaviv_platform_driver = {
},
};
-static struct platform_device *etnaviv_drm;
+static struct platform_device *etnaviv_platform_device;
-static int __init etnaviv_init(void)
+static int etnaviv_create_platform_device(const char *name,
+ struct platform_device **ppdev)
{
struct platform_device *pdev;
int ret;
+
+ pdev = platform_device_alloc(name, PLATFORM_DEVID_NONE);
+ if (!pdev)
+ return -ENOMEM;
+
+ ret = platform_device_add(pdev);
+ if (ret) {
+ platform_device_put(pdev);
+ return ret;
+ }
+
+ *ppdev = pdev;
+
+ return 0;
+}
+
+static void etnaviv_destroy_platform_device(struct platform_device **ppdev)
+{
+ struct platform_device *pdev = *ppdev;
+
+ if (!pdev)
+ return;
+
+ platform_device_unregister(pdev);
+
+ *ppdev = NULL;
+}
+
+static int __init etnaviv_init(void)
+{
+ int ret;
struct device_node *np;
etnaviv_validate_init();
@@ -681,23 +713,13 @@ static int __init etnaviv_init(void)
for_each_compatible_node(np, NULL, "vivante,gc") {
if (!of_device_is_available(np))
continue;
+ of_node_put(np);
- pdev = platform_device_alloc("etnaviv", PLATFORM_DEVID_NONE);
- if (!pdev) {
- ret = -ENOMEM;
- of_node_put(np);
- goto unregister_platform_driver;
- }
-
- ret = platform_device_add(pdev);
- if (ret) {
- platform_device_put(pdev);
- of_node_put(np);
+ ret = etnaviv_create_platform_device("etnaviv",
+&etnaviv_platform_device);
+ if (ret)
goto unregister_platform_driver;
- }
- etnaviv_drm = pdev;
- of_node_put(np);
break;
}
@@ -713,7 +735,7 @@ module_init(etnaviv_init);
static void __exit etnaviv_exit(void)
{
- platform_device_unregister(etnaviv_drm);
+ etnaviv_destroy_platform_device(&etnaviv_platform_device);
platform_driver_unregister(&etnaviv_platform_driver);
platform_driver_unregister(&etnaviv_gpu_driver);
}
--
2.25.1
[PATCH v8 8/8] drm/etnaviv: add a dedicated function to create the virtual master
From: Sui Jingfeng
After introducing the etnaviv_of_first_available_node() helper, the
creation of the virtual master platform device can also be simplified.
So, switch to etnaviv_create_virtual_master() function.
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: Philipp Zabel
Cc: Bjorn Helgaas
Cc: Daniel Vetter
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 43 ---
1 file changed, 26 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index d7e7498826f5..6f2260a76433 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -769,10 +769,32 @@ static void etnaviv_destroy_platform_device(struct
platform_device **ppdev)
*ppdev = NULL;
}
+static int etnaviv_create_virtual_master(void)
+{
+ struct platform_device **master = &etnaviv_platform_device;
+ struct device_node *np;
+
+ /*
+* If the DT contains at least one available GPU device, instantiate
+* the DRM platform device.
+*/
+ np = etnaviv_of_first_available_node();
+ if (np) {
+ int ret;
+
+ of_node_put(np);
+
+ ret = etnaviv_create_platform_device("etnaviv", master);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
static int __init etnaviv_init(void)
{
int ret;
- struct device_node *np;
etnaviv_validate_init();
@@ -790,22 +812,9 @@ static int __init etnaviv_init(void)
goto unregister_platform_driver;
#endif
- /*
-* If the DT contains at least one available GPU device, instantiate
-* the DRM platform device.
-*/
- for_each_compatible_node(np, NULL, "vivante,gc") {
- if (!of_device_is_available(np))
- continue;
- of_node_put(np);
-
- ret = etnaviv_create_platform_device("etnaviv",
-&etnaviv_platform_device);
- if (ret)
- goto unregister_platform_driver;
-
- break;
- }
+ ret = etnaviv_create_virtual_master();
+ if (ret)
+ goto unregister_platform_driver;
return ret;
--
2.25.1
[PATCH v8 5/8] drm/etnaviv: allow bypass component framework
From: Sui Jingfeng
Adds another code path to allow bypass component frameworks, A platform
with a single GPU core could probably try the non-component code path.
This patch is for code sharing, no functional change.
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: Philipp Zabel
Cc: Bjorn Helgaas
Cc: Daniel Vetter
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 47 ++-
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 83 +--
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 3 +
3 files changed, 91 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 6a048be02857..93ca240cd4c0 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -536,10 +536,9 @@ static const struct drm_driver etnaviv_drm_driver = {
.minor = 3,
};
-/*
- * Platform driver:
- */
-static int etnaviv_bind(struct device *dev)
+static struct etnaviv_drm_private *etna_private_ptr;
+
+static int etnaviv_drm_bind(struct device *dev, bool component)
{
struct etnaviv_drm_private *priv;
struct drm_device *drm;
@@ -556,12 +555,15 @@ static int etnaviv_bind(struct device *dev)
}
drm->dev_private = priv;
+ etna_private_ptr = priv;
dma_set_max_seg_size(dev, SZ_2G);
- dev_set_drvdata(dev, drm);
+ if (component)
+ ret = component_bind_all(dev, drm);
+ else
+ ret = etnaviv_gpu_bind(dev, NULL, drm);
- ret = component_bind_all(dev, drm);
if (ret < 0)
goto out_free_priv;
@@ -574,7 +576,10 @@ static int etnaviv_bind(struct device *dev)
return 0;
out_unbind:
- component_unbind_all(dev, drm);
+ if (component)
+ component_unbind_all(dev, drm);
+ else
+ etnaviv_gpu_unbind(dev, NULL, drm);
out_free_priv:
etnaviv_free_private(priv);
out_put:
@@ -583,14 +588,17 @@ static int etnaviv_bind(struct device *dev)
return ret;
}
-static void etnaviv_unbind(struct device *dev)
+static void etnaviv_drm_unbind(struct device *dev, bool component)
{
- struct drm_device *drm = dev_get_drvdata(dev);
- struct etnaviv_drm_private *priv = drm->dev_private;
+ struct etnaviv_drm_private *priv = etna_private_ptr;
+ struct drm_device *drm = priv->drm;
drm_dev_unregister(drm);
- component_unbind_all(dev, drm);
+ if (component)
+ component_unbind_all(dev, drm);
+ else
+ etnaviv_gpu_unbind(dev, NULL, drm);
etnaviv_free_private(priv);
@@ -599,9 +607,22 @@ static void etnaviv_unbind(struct device *dev)
drm_dev_put(drm);
}
+/*
+ * Platform driver:
+ */
+static int etnaviv_master_bind(struct device *dev)
+{
+ return etnaviv_drm_bind(dev, true);
+}
+
+static void etnaviv_master_unbind(struct device *dev)
+{
+ return etnaviv_drm_unbind(dev, true);
+}
+
static const struct component_master_ops etnaviv_master_ops = {
- .bind = etnaviv_bind,
- .unbind = etnaviv_unbind,
+ .bind = etnaviv_master_bind,
+ .unbind = etnaviv_master_unbind,
};
static int etnaviv_pdev_probe(struct platform_device *pdev)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index d4f99cb0456f..a6ac4c15b231 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1737,8 +1737,7 @@ static const struct thermal_cooling_device_ops
cooling_ops = {
.set_cur_state = etnaviv_gpu_cooling_set_cur_state,
};
-static int etnaviv_gpu_bind(struct device *dev, struct device *master,
- void *data)
+int etnaviv_gpu_bind(struct device *dev, struct device *master, void *data)
{
struct drm_device *drm = data;
struct etnaviv_drm_private *priv = drm->dev_private;
@@ -1769,7 +1768,6 @@ static int etnaviv_gpu_bind(struct device *dev, struct
device *master,
if (ret < 0)
goto out_sched;
-
gpu->drm = drm;
gpu->fence_context = dma_fence_context_alloc(1);
xa_init_flags(&gpu->user_fences, XA_FLAGS_ALLOC);
@@ -1798,8 +1796,7 @@ static int etnaviv_gpu_bind(struct device *dev, struct
device *master,
return ret;
}
-static void etnaviv_gpu_unbind(struct device *dev, struct device *master,
- void *data)
+void etnaviv_gpu_unbind(struct device *dev, struct device *master, void *data)
{
struct etnaviv_gpu *gpu = dev_get_drvdata(dev);
@@ -1869,9 +1866,11 @@ static int etnaviv_gpu_register_irq(struct etnaviv_gpu
*gpu, int irq)
return 0;
}
-static int etnaviv_gpu_platform_probe(struct platform_device *pdev)
+/* platform independent */
+
+static int etnaviv_gpu_driver_create(struct device *dev, void __iomem *mmio,
+int irq, bool component, bool has_clk)
{
- struct device *dev = &pdev->dev;
[PATCH v8 7/8] drm/etnaviv: add support for the dma coherent device
From: Sui Jingfeng
Loongson CPUs maintain cache coherency by hardware, which means that the
data in the CPU cache is identical to the data in main system memory. As
for the peripheral device, most of Loongson chips chose to define the
peripherals as DMA coherent by default, device drivers do not need to
maintain the coherency between a processor and an I/O device manually.
There are exceptions, for LS2K1000 SoC, part of peripheral device can be
configured as DMA non-coherent. But there is no released version of such
firmware exist in the market. Peripherals of older LS2K1000 is also DMA
non-coherent, but they are nearly outdated. So, those are trivial cases.
Nevertheless, kernel space still need to do the probe work, because vivante
GPU IP has been integrated into various platform. Hence, this patch add
runtime detection code to probe if a specific GPU is DMA coherent, If the
answer is yes, we are going to utilize such features. On Loongson platform,
When a buffer is accessed by both the GPU and the CPU, the driver should
prefer ETNA_BO_CACHED over ETNA_BO_WC.
This patch also add a new parameter: etnaviv_param_gpu_coherent, which
allow userspace to know if such a feature is available. Because
write-combined BO is still preferred in some case, especially where don't
need CPU read, for example, uploading shader bin.
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: Philipp Zabel
Cc: Bjorn Helgaas
Cc: Daniel Vetter
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 34 +
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 6
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 22 ++---
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 7 -
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 +++
include/uapi/drm/etnaviv_drm.h | 1 +
6 files changed, 69 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 033afe542a3a..d7e7498826f5 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -5,7 +5,9 @@
#include
#include
+#include
#include
+#include
#include
#include
@@ -27,6 +29,34 @@
#include "etnaviv_pci_drv.h"
#endif
+static struct device_node *etnaviv_of_first_available_node(void)
+{
+ struct device_node *core_node;
+
+ for_each_compatible_node(core_node, NULL, "vivante,gc") {
+ if (of_device_is_available(core_node))
+ return core_node;
+ }
+
+ return NULL;
+}
+
+static bool etnaviv_is_dma_coherent(struct device *dev)
+{
+ struct device_node *np;
+ bool coherent;
+
+ np = etnaviv_of_first_available_node();
+ if (np) {
+ coherent = of_dma_is_coherent(np);
+ of_node_put(np);
+ } else {
+ coherent = dev_is_dma_coherent(dev);
+ }
+
+ return coherent;
+}
+
/*
* etnaviv private data construction and destructions:
*/
@@ -55,6 +85,10 @@ etnaviv_alloc_private(struct device *dev, struct drm_device
*drm)
return ERR_PTR(-ENOMEM);
}
+ priv->dma_coherent = etnaviv_is_dma_coherent(dev);
+
+ drm_info(drm, "%s is dma coherent\n", dev_name(dev));
+
return priv;
}
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index 9cd72948cfad..644e5712c050 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -46,6 +46,12 @@ struct etnaviv_drm_private {
struct xarray active_contexts;
u32 next_context_id;
+ /*
+* If true, the GPU is capable of snooping cpu cache. Here, it
+* also means that cache coherency is enforced by the hardware.
+*/
+ bool dma_coherent;
+
/* list of GEM objects: */
struct mutex gem_lock;
struct list_head gem_list;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index b5f73502e3dd..39bdc3774f2d 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -343,6 +343,7 @@ void *etnaviv_gem_vmap(struct drm_gem_object *obj)
static void *etnaviv_gem_vmap_impl(struct etnaviv_gem_object *obj)
{
struct page **pages;
+ pgprot_t prot;
lockdep_assert_held(&obj->lock);
@@ -350,8 +351,19 @@ static void *etnaviv_gem_vmap_impl(struct
etnaviv_gem_object *obj)
if (IS_ERR(pages))
return NULL;
- return vmap(pages, obj->base.size >> PAGE_SHIFT,
- VM_MAP, pgprot_writecombine(PAGE_KERNEL));
+ switch (obj->flags) {
+ case ETNA_BO_CACHED:
+ prot = PAGE_KERNEL;
+ break;
+ case ETNA_BO_UNCACHED:
+ prot = pgprot_noncached(PAGE_KERNEL);
+ break;
+ case ETNA_BO_WC:
+ default:
+ prot = pgprot_writecombine(PAGE_KERNEL);
+ }
+
RE: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
Hi Wolfram, > Subject: Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API > > Hi all, > > sorry for not being able to chime in earlier. > > > In Biju's particular use case, the i2c device responds to two > > addresses, which is the standard i2c ancillary use case. However, > > what's special > > Not quite. ancillary is used when a *driver* needs to take care of two > addresses. We already have devices bundling two features into the same > chip. I recall at least RTC + EEPROM somewhere. And so far, we have been > handling this by creating two nodes in DT and have proper binding docs. > I think this is cleaner. First, you can see in DT already what the > compound device really consists of. In this case, which RTC and RTC driver > is exactly needed. Second, the code added here adds complexity to the I2C > core with another layer of inderection for dummy devices. FYI, please see [1] and [2] As per DT maintainers, most of PMICs are described with one node, even though RTC is on separate address. According to them the DT schema allows multiple addresses for children. But currently we lacks implementation for that. The enhancement to this API allows that. [1] https://lore.kernel.org/linux-renesas-soc/bce6cbcd-b693-4027-7d17-8e582b8fa...@linaro.org/ and [2] https://lore.kernel.org/linux-renesas-soc/CAMuHMdVrH5R4mAjm1c9zRqiGhNsfT7Y13xxaV-v05T-MCJ6=r...@mail.gmail.com/ Cheers, Biju > > > As some resources are shared (knowledge about the clocks), splitting > > this in two distinct devices in DT (which is what Biju's initial patch > > series did) would need phandles to link both nodes together. > > > > Do you have a better idea how to represent this? > > Not sure if I understood this chip correctly, but maybe: The PMIC driver > exposes a clock gate which can be consumed by the RTC driver? > > Happy hacking, > >Wolfram
