Re: [PATCH 3/3] drm-panel: If drm_panel_dp_aux_backlight() fails, don't fail panel probe
Hi,
On Mon, Mar 25, 2024 at 5:07 PM Hsin-Yi Wang wrote:
>
> On Mon, Mar 25, 2024 at 2:57 PM Douglas Anderson
> wrote:
> >
> > If we're using the AUX channel for eDP backlight and it fails to probe
> > for some reason, let's _not_ fail the panel probe.
> >
> > At least one case where we could fail to init the backlight is because
> > of a dead or physically missing panel. As talked about in detail in
> > the earlier patch in this series, ("drm/panel-edp: If we fail to
> > powerup/get EDID, use conservative timings"), this can cause the
> > entire system's display pipeline to fail to come up and that's
> > non-ideal.
> >
> > If we fail to init the backlight for some transitory reason, we should
> > dig in and see if there's a way to fix this (perhaps retries?). Even
> > in that case, though, having a panel whose backlight is stuck at 100%
> > (the default, at least in the panel Samsung ATNA33XC20 I tested) is
> > better than having no panel at all.
> >
> > Signed-off-by: Douglas Anderson
>
> Reviewed-by: Hsin-Yi Wang
Pushed to drm-misc-next:
b48ccb18e642 drm-panel: If drm_panel_dp_aux_backlight() fails, don't
fail panel probe
Re: [PATCH 2/3] drm/panel-edp: If we fail to powerup/get EDID, use conservative timings
Hi, On Mon, Mar 25, 2024 at 5:05 PM Hsin-Yi Wang wrote: > > On Mon, Mar 25, 2024 at 2:57 PM Douglas Anderson > wrote: > > > > If at boot we fail to power up the eDP panel (most often happens if > > the eDP panel never asserts HPD to us) or if we are unable to read the > > EDID at bootup to figure out the panel's ID then let's use the > > conservative eDP panel powerup/powerdown timings but _not_ fail the > > probe. > > > > It might seem strange to _not_ fail the probe in this case since we > > were unable to powerup the panel and confirm it's there. However, > > there is a reason to do this. Specifically, if we fail to probe the > > panel then it really throws the whole display pipeline for loop. Most > > DRM subsystems are written so that they wait until all components > > (including the panel) have probed before they set everything up. When > > the panel doesn't come up then this never happens. As a side effect of > > not setting everything up then other display adapters don't get > > initialized. As a practical example, I can see that if I open up a > > sc7180-trogdor based Chromebook that's using the generic "edp-panel" > > and unplug the eDP panel that it causes the _external_ DP monitor not > > to function. This is obviously bad because it means that a device with > > a dead eDP panel becomes e-waste when it could instead still be given > > useful life with an external display. > > > > NOTES: > > - When we fail to probe like this, boot is a bit slow because we try > > several times to power the panel up. This doesn't feel horrible > > because it'll eventually work and the retries are known to help > > bring some panels up. > > - In the case where we hit the condition of failing to power up, the > > display will likely _never_ have a chance to work again until > > reboot. Once the panel-edp pm_runtime resume function fails it > > doesn't ever seem to retry. This is probably for the best given that > > we don't have any real timing/modes. eDP isn't expected to be > > "hotplugged" so this makes some sense. > > - It turns out that this makes panel-edp behave more similarly for > > users of the generic "edp-panel" compatible string and the old fixed > > panel compatible string. With the old fixed panel compatible string > > we don't talk to the panel during probe so we'd actually behave much > > the same way that we'll now behave for the generic "edp-panel". > > > > Signed-off-by: Douglas Anderson > > Reviewed-by: Hsin-Yi Wang Pushed to drm-misc-next: ce0ff22388ab drm/panel-edp: If we fail to powerup/get EDID, use conservative timings
Re: [PATCH 1/3] drm/panel-edp: Abstract out function to set conservative timings
Hi, On Mon, Mar 25, 2024 at 4:52 PM Hsin-Yi Wang wrote: > > On Mon, Mar 25, 2024 at 2:56 PM Douglas Anderson > wrote: > > > > If we're using the generic "edp-panel" compatible string and we fail > > to detect an eDP panel then we fall back to conservative timings for > > powering up and powering down the panel. Abstract out the function for > > setting these timings so it can be used in future patches. > > > > No functional change expected--just code movement. > > > > Signed-off-by: Douglas Anderson > > Reviewed-by: Hsin-Yi Wang Pushed to drm-misc-next: 2cbee8ae55f5 drm/panel-edp: Abstract out function to set conservative timings
Re: [PATCH v4 0/5] Pinephone video out fixes (flipping between two frames)
Quoting Frank Oltmanns (2024-04-03 08:31:47) > Dear clk and sunxi-ng maintainers, > > Patches 1-4 have been reviewed and there are no pending issues. If there > is something else you need me to do to get this applied, please let me > know. > I'm assuming sunxi maintainers will pick up the clk patches and send them to clk tree in a PR.
[PATCH] nouveau: fix devinit paths to only handle display on GSP.
This reverts:
nouveau/gsp: don't check devinit disable on GSP.
and applies a further fix.
It turns out the open gpu driver, checks this register, but only for display.
Match that behaviour and only disable displays on turings.
Fixes: 5d4e8ae6e57b ("nouveau/gsp: don't check devinit disable on GSP.")
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gm107.c | 12
drivers/gpu/drm/nouveau/nvkm/subdev/devinit/r535.c | 1 +
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gm107.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gm107.c
index 7bcbc4895ec2..271bfa038f5b 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gm107.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gm107.c
@@ -25,6 +25,7 @@
#include
#include
+#include
void
gm107_devinit_disable(struct nvkm_devinit *init)
@@ -33,10 +34,13 @@ gm107_devinit_disable(struct nvkm_devinit *init)
u32 r021c00 = nvkm_rd32(device, 0x021c00);
u32 r021c04 = nvkm_rd32(device, 0x021c04);
- if (r021c00 & 0x0001)
- nvkm_subdev_disable(device, NVKM_ENGINE_CE, 0);
- if (r021c00 & 0x0004)
- nvkm_subdev_disable(device, NVKM_ENGINE_CE, 2);
+ /* gsp only wants to enable/disable display */
+ if (!nvkm_gsp_rm(device->gsp)) {
+ if (r021c00 & 0x0001)
+ nvkm_subdev_disable(device, NVKM_ENGINE_CE, 0);
+ if (r021c00 & 0x0004)
+ nvkm_subdev_disable(device, NVKM_ENGINE_CE, 2);
+ }
if (r021c04 & 0x0001)
nvkm_subdev_disable(device, NVKM_ENGINE_DISP, 0);
}
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/r535.c
index 11b4c9c274a1..666eb93b1742 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/r535.c
@@ -41,6 +41,7 @@ r535_devinit_new(const struct nvkm_devinit_func *hw,
rm->dtor = r535_devinit_dtor;
rm->post = hw->post;
+ rm->disable = hw->disable;
ret = nv50_devinit_new_(rm, device, type, inst, pdevinit);
if (ret)
--
2.44.0
Re: [PATCH v2 0/4] drm/xe: Support PCIe FLR
On 05/04/24 10:30, Aravind Iddamsetty wrote: > On 05/04/24 03:55, Rodrigo Vivi wrote: >> On Tue, Apr 02, 2024 at 02:28:55PM +0530, Aravind Iddamsetty wrote: >>> PCI subsystem provides callbacks to inform the driver about a request to >>> do function level reset by user, initiated by writing to sysfs entry >>> /sys/bus/pci/devices/.../reset. This will allow the driver to handle FLR >>> without the need to do unbind and rebind as the driver needs to >>> reinitialize the device afresh post FLR. >>> >>> v2: >> all the patches looks good to me here. feel free to use >> >> Reviewed-by: Rodrigo Vivi >> >> on them. > Thank you! > >> but I do have some concerns (below) >> >>> 1. Directly expose the devm_drm_dev_release_action instead of introducing >>> a helper (Rodrigo) >>> 2. separate out gt idle and pci save/restore to a separate patch (Lucas) >>> 3. Fixed the warnings seen around xe_guc_submit_stop, xe_guc_puc_fini >> On this I also had to fight to get something working on the wedged_mode=2: >> lore.kernel.org/all/20240403150732.102678-4-rodrigo.v...@intel.com >> >> perhaps we can unify things here. > I guess we dealing with different scenarios, in this the warning in > xe_guc_submit_stop > was because not invoking xe_uc_reset_prepare before. and we needn't invoke > xe_guc_pc_fini as guc is already in stopped. >>> Cc: Rodrigo Vivi >>> Cc: Lucas De Marchi >>> >>> dmesg snip showing FLR recovery: >> things came different at my DG2 here with display working and all: > after you mentioned this i tested on DG2 i got warnings but no segmentation > fault > and NPD, i have tested my branch which might not be update to date, will re > test with the > latest branch. While I check upon this is it ok to have this version of series to be merged, as I see even with warnings with display the device and driver are recoverable. Thanks, Aravind. > > > Thanks, > Aravnd. >> root@rdvivi-desk:/sys/module/xe/drivers/pci:xe/:03:00.0# echo 1 > reset >> Segmentation fault >> >> and many kernel warnings >> WARNING: CPU: 8 PID: 2389 at >> drivers/gpu/drm/i915/display/intel_display_power_well.c:281 >> hsw_wait_for_power_well_enable+0x3e7/0x570 [xe] >> WARNING: CPU: 9 PID: 1700 at drivers/gpu/drm/drm_mm.c:999 >> drm_mm_takedown+0x41/0x60 >> >> [ 117.128330] KASAN: null-ptr-deref in range >> [0x04e8-0x04ef] >> [ 117.128332] CPU: 13 PID: 2389 Comm: bash Tainted: GW >> 6.9.0-rc1+ #9 >> [ 117.135501] ? exc_invalid_op+0x13/0x40 >> [ 117.143626] Hardware name: iBUYPOWER INTEL/B660 DS3H AC DDR4-Y1, BIOS F5 >> 12/17/2021 >> [ 117.143627] RIP: 0010:__mutex_lock+0x124/0x14a0 >> [ 117.143631] Code: d0 7c 08 84 d2 0f 85 62 0f 00 00 8b 0d 85 c8 8f 04 85 >> c9 75 29 48 b8 00 00 00 00 00 fc ff df 49 8d 7f 68 48 89 fa 48 c1 ea 03 <80> >> 3c 02 00 0f 85 46 0f 00 00 4d 3b 7f 68 0f 85 aa 0e 00 00 bf 01 >> [ 117.150630] ? asm_exc_invalid_op+0x16/0x20 >> [ 117.156401] RSP: 0018:c90005a37690 EFLAGS: 00010202 >> [ 117.156403] RAX: dc00 RBX: RCX: >> >> [ 117.163571] ? drm_buddy_fini+0x181/0x220 >> >> >> and more issues. >> >> so it looks like we are still missing some parts of the puzzle here... >> >> >>> [ 590.486336] xe :4d:00.0: enabling device (0140 -> 0142) >>> [ 590.506933] xe :4d:00.0: [drm] Using GuC firmware from >>> xe/pvc_guc_70.20.0.bin version 70.20.0 >>> [ 590.542355] xe :4d:00.0: [drm] Using GuC firmware from >>> xe/pvc_guc_70.20.0.bin version 70.20.0 >>> [ 590.578532] xe :4d:00.0: [drm] VISIBLE VRAM: 0x2020, >>> 0x0020 >>> [ 590.578556] xe :4d:00.0: [drm] VRAM[0, 0]: Actual physical size >>> 0x0010, usable size exclude stolen 0x000fff00, CPU >>> accessible size 0x000fff00 >>> [ 590.578560] xe :4d:00.0: [drm] VRAM[0, 0]: DPA range: >>> [0x-10], io range: >>> [0x2020-202fff00] >>> [ 590.578585] xe :4d:00.0: [drm] VRAM[1, 1]: Actual physical size >>> 0x0010, usable size exclude stolen 0x000fff00, CPU >>> accessible size 0x000fff00 >>> [ 590.578589] xe :4d:00.0: [drm] VRAM[1, 1]: DPA range: >>> [0x0010-20], io range: >>> [0x2030-203fff00] >>> [ 590.578592] xe :4d:00.0: [drm] Total VRAM: 0x2020, >>> 0x0020 >>> [ 590.578594] xe :4d:00.0: [drm] Available VRAM: >>> 0x2020, 0x001ffe00 >>> [ 590.738899] xe :4d:00.0: [drm] GT0: CCS_MODE=0 config:0040, >>> num_engines:1, num_slices:4 >>> [ 590.889991] xe :4d:00.0: [drm] GT1: CCS_MODE=0 config:0040, >>> num_engines:1, num_slices:4 >>> [ 590.892835] [drm] Initialized xe 1.1.0 20201103 for :4d:00.0 on >>> minor 1 >>> [ 590.900215] xe :9a:00.0: enabling device (0140 -> 0142) >>> [ 590.915991] xe :9a:00.0: [drm] Using GuC firmware from >>> xe/pvc_guc_70.20.0.bin version 70.20.0 >>> [ 590.957450] xe :9a:00
Re: [PATCH v1 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
On Thu, Apr 4, 2024 at 4:16 PM AngeloGioacchino Del Regno wrote: > > Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths > per HW instance (so potentially up to six displays for multi-vdo SoCs). > > The MMSYS or VDOSYS is always the first component in the DDP pipeline, > so it only supports an output port with multiple endpoints - where each > endpoint defines the starting point for one of the (currently three) > possible hardware paths. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++ > 1 file changed, 23 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > index b3c6888c1457..90758bb5bcb1 100644 > --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml > @@ -93,6 +93,29 @@ properties: >'#reset-cells': > const: 1 > > + port: > +$ref: /schemas/graph.yaml#/properties/port > +description: > + Output port node. This port connects the MMSYS/VDOSYS output to > + the first component of one display pipeline, for example one of > + the available OVL or RDMA blocks. > + Some MediaTek SoCs support up to three display outputs per MMSYS. > +properties: > + endpoint@0: > +$ref: /schemas/graph.yaml#/properties/endpoint > +description: Output to the primary display pipeline > + > + endpoint@1: > +$ref: /schemas/graph.yaml#/properties/endpoint > +description: Output to the secondary display pipeline > + > + endpoint@2: > +$ref: /schemas/graph.yaml#/properties/endpoint > +description: Output to the tertiary display pipeline > + > + required: > +- endpoint@0 > + Technically the mmsys device serves as an glue layer for the display pipeline, providing things like clock control and signal routing; the device itself is not part of the pipeline, and probably shouldn't be part of the graph? ChenYu > required: >- compatible >- reg > -- > 2.44.0 >
[PATCH] drm/vmwgfx: Enable DMA mappings with SEV
Enable DMA mappings in vmwgfx after TTM has been fixed in commit
3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based iomem")
This enables full guest-backed memory support and in particular allows
usage of screen targets as the presentation mechanism.
Signed-off-by: Zack Rusin
Reported-by: Ye Li
Tested-by: Ye Li
Fixes: 3b0d6458c705 ("drm/vmwgfx: Refuse DMA operation when SEV encryption is
active")
Cc: Broadcom internal kernel review list
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.6+
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 41ad13e45554..bdad93864b98 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -667,11 +667,12 @@ static int vmw_dma_select_mode(struct vmw_private
*dev_priv)
[vmw_dma_map_populate] = "Caching DMA mappings.",
[vmw_dma_map_bind] = "Giving up DMA mappings early."};
- /* TTM currently doesn't fully support SEV encryption. */
- if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
- return -EINVAL;
-
- if (vmw_force_coherent)
+ /*
+* When running with SEV we always want dma mappings, because
+* otherwise ttm tt pool pages will bounce through swiotlb running
+* out of available space.
+*/
+ if (vmw_force_coherent || cc_platform_has(CC_ATTR_MEM_ENCRYPT))
dev_priv->map_mode = vmw_dma_alloc_coherent;
else if (vmw_restrict_iommu)
dev_priv->map_mode = vmw_dma_map_bind;
--
2.40.1
[PATCH v5 3/4] drm/mipi-dsi: add mipi_dsi_compression_mode_ext()
Add the extended version of mipi_dsi_compression_mode(). It provides
a way to specify the algorithm and PPS selector.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_mipi_dsi.c | 41 ++---
include/drm/drm_mipi_dsi.h | 9 +
2 files changed, 43 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 9874ff6d4718..795001bb7ff1 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -645,29 +645,56 @@ int mipi_dsi_set_maximum_return_packet_size(struct
mipi_dsi_device *dsi,
EXPORT_SYMBOL(mipi_dsi_set_maximum_return_packet_size);
/**
- * mipi_dsi_compression_mode() - enable/disable DSC on the peripheral
+ * mipi_dsi_compression_mode_ext() - enable/disable DSC on the peripheral
* @dsi: DSI peripheral device
* @enable: Whether to enable or disable the DSC
+ * @algo: Selected compression algorithm
+ * @pps_selector: Select PPS from the table of pre-stored or uploaded PPS
entries
*
- * Enable or disable Display Stream Compression on the peripheral using the
- * default Picture Parameter Set and VESA DSC 1.1 algorithm.
+ * Enable or disable Display Stream Compression on the peripheral.
*
* Return: 0 on success or a negative error code on failure.
*/
-int mipi_dsi_compression_mode(struct mipi_dsi_device *dsi, bool enable)
+int mipi_dsi_compression_mode_ext(struct mipi_dsi_device *dsi, bool enable,
+ enum mipi_dsi_compression_algo algo,
+ unsigned int pps_selector)
{
- /* Note: Needs updating for non-default PPS or algorithm */
- u8 tx[2] = { enable << 0, 0 };
+ u8 tx[2] = { };
struct mipi_dsi_msg msg = {
.channel = dsi->channel,
.type = MIPI_DSI_COMPRESSION_MODE,
.tx_len = sizeof(tx),
.tx_buf = tx,
};
- int ret = mipi_dsi_device_transfer(dsi, &msg);
+ int ret;
+
+ if (algo > 3 || pps_selector > 3)
+ return -EINVAL;
+
+ tx[0] = (enable << 0) |
+ (algo << 1) |
+ (pps_selector << 4);
+
+ ret = mipi_dsi_device_transfer(dsi, &msg);
return (ret < 0) ? ret : 0;
}
+EXPORT_SYMBOL(mipi_dsi_compression_mode_ext);
+
+/**
+ * mipi_dsi_compression_mode() - enable/disable DSC on the peripheral
+ * @dsi: DSI peripheral device
+ * @enable: Whether to enable or disable the DSC
+ *
+ * Enable or disable Display Stream Compression on the peripheral using the
+ * default Picture Parameter Set and VESA DSC 1.1 algorithm.
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int mipi_dsi_compression_mode(struct mipi_dsi_device *dsi, bool enable)
+{
+ return mipi_dsi_compression_mode_ext(dsi, enable,
MIPI_DSI_COMPRESSION_DSC, 0);
+}
EXPORT_SYMBOL(mipi_dsi_compression_mode);
/**
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 3011d33eccbd..82b1cc434ea3 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -226,6 +226,12 @@ static inline int mipi_dsi_pixel_format_to_bpp(enum
mipi_dsi_pixel_format fmt)
return -EINVAL;
}
+enum mipi_dsi_compression_algo {
+ MIPI_DSI_COMPRESSION_DSC = 0,
+ MIPI_DSI_COMPRESSION_VENDOR = 3,
+ /* other two values are reserved, DSI 1.3 */
+};
+
struct mipi_dsi_device *
mipi_dsi_device_register_full(struct mipi_dsi_host *host,
const struct mipi_dsi_device_info *info);
@@ -242,6 +248,9 @@ int mipi_dsi_turn_on_peripheral(struct mipi_dsi_device
*dsi);
int mipi_dsi_set_maximum_return_packet_size(struct mipi_dsi_device *dsi,
u16 value);
int mipi_dsi_compression_mode(struct mipi_dsi_device *dsi, bool enable);
+int mipi_dsi_compression_mode_ext(struct mipi_dsi_device *dsi, bool enable,
+ enum mipi_dsi_compression_algo algo,
+ unsigned int pps_selector);
int mipi_dsi_picture_parameter_set(struct mipi_dsi_device *dsi,
const struct drm_dsc_picture_parameter_set
*pps);
--
2.39.2
[PATCH v5 1/4] dt-bindings: panel: Add LG SW43408 MIPI-DSI panel
From: Sumit Semwal
LG SW43408 is 1080x2160, 4-lane MIPI-DSI panel present on Google Pixel 3
phones.
Signed-off-by: Vinod Koul
Signed-off-by: Sumit Semwal
[caleb: convert to yaml]
Signed-off-by: Caleb Connolly
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Dmitry Baryshkov
---
.../bindings/display/panel/lg,sw43408.yaml | 62 ++
1 file changed, 62 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml
b/Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml
new file mode 100644
index ..1e08648f5bc7
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/lg,sw43408.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LG SW43408 1080x2160 DSI panel
+
+maintainers:
+ - Caleb Connolly
+
+description:
+ This panel is used on the Pixel 3, it is a 60hz OLED panel which
+ required DSC (Display Stream Compression) and has rounded corners.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+items:
+ - const: lg,sw43408
+
+ reg: true
+ port: true
+ vddi-supply: true
+ vpnl-supply: true
+ reset-gpios: true
+
+required:
+ - compatible
+ - vddi-supply
+ - vpnl-supply
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "lg,sw43408";
+reg = <0>;
+
+vddi-supply = <&vreg_l14a_1p88>;
+vpnl-supply = <&vreg_l28a_3p0>;
+
+reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>;
+
+port {
+endpoint {
+remote-endpoint = <&mdss_dsi0_out>;
+};
+};
+};
+};
+...
--
2.39.2
[PATCH v5 4/4] drm: panel: Add LG sw43408 panel driver
From: Sumit Semwal
LG SW43408 is 1080x2160@60Hz, 4-lane MIPI-DSI panel, used in some
Google Pixel-3 phones.
Signed-off-by: Sumit Semwal
[vinod: Add DSC support]
Signed-off-by: Vinod Koul
[caleb: cleanup and support turning off the panel]
Signed-off-by: Caleb Connolly
[DB: partially rewrote the driver and fixed DSC programming]
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
MAINTAINERS | 8 +
drivers/gpu/drm/panel/Kconfig| 11 ++
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-lg-sw43408.c | 323 +++
4 files changed, 343 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d36c19c1bf81..4cc43c16e07e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6789,6 +6789,14 @@ S: Maintained
F: Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
F: drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
+DRM DRIVER FOR LG SW43408 PANELS
+M: Sumit Semwal
+M: Caleb Connolly
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml
+F: drivers/gpu/drm/panel/panel-lg-sw43408.c
+
DRM DRIVER FOR LOGICVC DISPLAY CONTROLLER
M: Paul Kocialkowski
S: Supported
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 6dc451f58a3e..4dc435fd9a44 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -335,6 +335,17 @@ config DRM_PANEL_LG_LG4573
Say Y here if you want to enable support for LG4573 RGB panel.
To compile this driver as a module, choose M here.
+config DRM_PANEL_LG_SW43408
+ tristate "LG SW43408 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for LG sw43408 panel.
+ The panel has a 1080x2160@60Hz resolution and uses 24 bit RGB per
+ pixel. It provides a MIPI DSI interface to the host and has a
+ built-in LED backlight.
+
config DRM_PANEL_MAGNACHIP_D53E6EA8966
tristate "Magnachip D53E6EA8966 DSI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 24a02655d726..0b40b010e8e7 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) +=
panel-leadtek-ltk050h3146w.o
obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
+obj-$(CONFIG_DRM_PANEL_LG_SW43408) += panel-lg-sw43408.o
obj-$(CONFIG_DRM_PANEL_MAGNACHIP_D53E6EA8966) += panel-magnachip-d53e6ea8966.o
obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
obj-$(CONFIG_DRM_PANEL_NEWVISION_NV3051D) += panel-newvision-nv3051d.o
diff --git a/drivers/gpu/drm/panel/panel-lg-sw43408.c
b/drivers/gpu/drm/panel/panel-lg-sw43408.c
new file mode 100644
index ..bd9706ae7615
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-lg-sw43408.c
@@ -0,0 +1,323 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-2024 Linaro Ltd
+ * Author: Sumit Semwal
+ * Dmitry Baryshkov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#define NUM_SUPPLIES 2
+
+struct sw43408_panel {
+ struct drm_panel base;
+ struct mipi_dsi_device *link;
+
+ struct regulator_bulk_data supplies[NUM_SUPPLIES];
+
+ struct gpio_desc *reset_gpio;
+
+ struct drm_dsc_config dsc;
+};
+
+static inline struct sw43408_panel *to_panel_info(struct drm_panel *panel)
+{
+ return container_of(panel, struct sw43408_panel, base);
+}
+
+static int sw43408_unprepare(struct drm_panel *panel)
+{
+ struct sw43408_panel *ctx = to_panel_info(panel);
+ int ret;
+
+ ret = mipi_dsi_dcs_set_display_off(ctx->link);
+ if (ret < 0)
+ dev_err(panel->dev, "set_display_off cmd failed ret = %d\n",
ret);
+
+ ret = mipi_dsi_dcs_enter_sleep_mode(ctx->link);
+ if (ret < 0)
+ dev_err(panel->dev, "enter_sleep cmd failed ret = %d\n", ret);
+
+ msleep(100);
+
+ gpiod_set_value(ctx->reset_gpio, 1);
+
+ return regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
+}
+
+static int sw43408_program(struct drm_panel *panel)
+{
+ struct sw43408_panel *ctx = to_panel_info(panel);
+ struct drm_dsc_picture_parameter_set pps;
+
+ mipi_dsi_dcs_write_seq(ctx->link, MIPI_DCS_SET_GAMMA_CURVE, 0x02);
+
+ mipi_dsi_dcs_set_tear_on(ctx->link, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
+
+ mipi_dsi_dcs_write_seq(ctx->link, 0x53, 0x0c, 0x30);
+ mipi_dsi_dcs_write_seq(ctx->link, 0x55, 0x00, 0x70, 0xdf, 0x00, 0x7
[PATCH v5 0/4] drm/panel: add support for LG SW43408 panel
The LG SW43408 panel is used on Google Pixel3 devices. For a long time we could not submit the driver, as the panel was not coming up from the reset. The panel seems to be picky about some of the delays during init and it also uses non-standard payload for MIPI_DSI_COMPRESSION_MODE. Signed-off-by: Dmitry Baryshkov --- Changes in v5: - Mention 60 Hz in the commit message (Marijn) - Fix the comment regarding the panel being DSC-only (Marijn) - Link to v4: https://lore.kernel.org/r/20240403-lg-sw43408-panel-v4-0-a386d5d3b...@linaro.org Changes in v4: - Fix order of mipi_dsi_compression_mode_ext() args (Marijn) - Expanded kerneldoc coments for this function (Marijn) - And added arguments validation (Marijn) - In the panel driver send the COMPRESSION_MODE in LPM mode like it was done originally - Expanded the .clock maths to show the reason behind the value (Marijn) - Moved the mode out of the match data (Marijn) - Link to v3: https://lore.kernel.org/r/20240402-lg-sw43408-panel-v3-0-144f17a11...@linaro.org Changes in v3: - Fixed return type of MIPI DSC functions - Replaced mipi_dsi_compression_mode_raw() with mipi_dsi_compression_mode_ext() (Marijn) - Link to v2: https://lore.kernel.org/r/20240330-lg-sw43408-panel-v2-0-293a58717...@linaro.org Changes in v2: - Removed formatting char from schema (Krzysztof) - Moved additionalProperties after required (Krzysztof) - Added example to the schema (Krzysztof) - Removed obsolete comment in the commit message (Marijn) - Moved DSC params to the panel struct (Marijn) - Changed dsc_en to be an array (Marijn) - Added comment regiarding slice_width and slice_count (Marijn) - Link to v1: https://lore.kernel.org/r/20240330-lg-sw43408-panel-v1-0-f5580fc9f...@linaro.org --- Dmitry Baryshkov (2): drm/mipi-dsi: use correct return type for the DSC functions drm/mipi-dsi: add mipi_dsi_compression_mode_ext() Sumit Semwal (2): dt-bindings: panel: Add LG SW43408 MIPI-DSI panel drm: panel: Add LG sw43408 panel driver .../bindings/display/panel/lg,sw43408.yaml | 62 MAINTAINERS| 8 + drivers/gpu/drm/drm_mipi_dsi.c | 45 ++- drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-lg-sw43408.c | 323 + include/drm/drm_mipi_dsi.h | 15 +- 7 files changed, 453 insertions(+), 12 deletions(-) --- base-commit: a6bd6c997f5a0e2667d4d82fef8c970108f2 change-id: 20240330-lg-sw43408-panel-b552f411c53e Best regards, -- Dmitry Baryshkov
[PATCH v5 2/4] drm/mipi-dsi: use correct return type for the DSC functions
The functions mipi_dsi_compression_mode() and
mipi_dsi_picture_parameter_set() return 0-or-error rather than a buffer
size. Follow example of other similar MIPI DSI functions and use int
return type instead of size_t.
Fixes: f4dea1aaa9a1 ("drm/dsi: add helpers for DSI compression mode and PPS
packets")
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_mipi_dsi.c | 6 +++---
include/drm/drm_mipi_dsi.h | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index ef6e416522f8..9874ff6d4718 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -654,7 +654,7 @@ EXPORT_SYMBOL(mipi_dsi_set_maximum_return_packet_size);
*
* Return: 0 on success or a negative error code on failure.
*/
-ssize_t mipi_dsi_compression_mode(struct mipi_dsi_device *dsi, bool enable)
+int mipi_dsi_compression_mode(struct mipi_dsi_device *dsi, bool enable)
{
/* Note: Needs updating for non-default PPS or algorithm */
u8 tx[2] = { enable << 0, 0 };
@@ -679,8 +679,8 @@ EXPORT_SYMBOL(mipi_dsi_compression_mode);
*
* Return: 0 on success or a negative error code on failure.
*/
-ssize_t mipi_dsi_picture_parameter_set(struct mipi_dsi_device *dsi,
- const struct
drm_dsc_picture_parameter_set *pps)
+int mipi_dsi_picture_parameter_set(struct mipi_dsi_device *dsi,
+ const struct drm_dsc_picture_parameter_set
*pps)
{
struct mipi_dsi_msg msg = {
.channel = dsi->channel,
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index c0aec0d4d664..3011d33eccbd 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -241,9 +241,9 @@ int mipi_dsi_shutdown_peripheral(struct mipi_dsi_device
*dsi);
int mipi_dsi_turn_on_peripheral(struct mipi_dsi_device *dsi);
int mipi_dsi_set_maximum_return_packet_size(struct mipi_dsi_device *dsi,
u16 value);
-ssize_t mipi_dsi_compression_mode(struct mipi_dsi_device *dsi, bool enable);
-ssize_t mipi_dsi_picture_parameter_set(struct mipi_dsi_device *dsi,
- const struct
drm_dsc_picture_parameter_set *pps);
+int mipi_dsi_compression_mode(struct mipi_dsi_device *dsi, bool enable);
+int mipi_dsi_picture_parameter_set(struct mipi_dsi_device *dsi,
+ const struct drm_dsc_picture_parameter_set
*pps);
ssize_t mipi_dsi_generic_write(struct mipi_dsi_device *dsi, const void
*payload,
size_t size);
--
2.39.2
Re: [PATCH 2/2] dt-bindings: display: bridge: lt8912b: document 'lontium, pn-swap' property
On Tue, Apr 02, 2024 at 01:59:25PM +0300, Alexandru Ardelean wrote: > On some HW designs, it's easier for the layout if the P/N pins are swapped. > The driver currently has a DT property to do that. > > This change documents the 'lontium,pn-swap' property. > > Signed-off-by: Alexandru Ardelean > --- > .../devicetree/bindings/display/bridge/lontium,lt8912b.yaml | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml > b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml > index 2cef252157985..3a804926b288a 100644 > --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml > @@ -24,6 +24,12 @@ properties: > maxItems: 1 > description: GPIO connected to active high RESET pin. > > + lontium,pn-swap: > +description: Swap the polarities of the P/N pins in software. > + On some HW designs, the layout is simplified if the P/N pins > + are inverted. > +type: boolean > + I'd like to point out the standard `lane-polarities` property defined at Documentation/devicetree/bindings/media/video-interfaces.yaml. You can define and use it for the corresponding endpoint in the lt8912b schema. >ports: > $ref: /schemas/graph.yaml#/properties/ports > > -- > 2.44.0 > -- With best wishes Dmitry
Re: [PATCH v3] drm/msm/dp: call dp_hpd_plug_handle()/unplug_handle() directly for external HPD
On Fri, Apr 05, 2024 at 08:15:47PM -0700, Abhinav Kumar wrote: > From: Kuogee Hsieh [..] > diff --git a/drivers/gpu/drm/msm/dp/dp_display.c > b/drivers/gpu/drm/msm/dp/dp_display.c > index d80f89581760..bfb6dfff27e8 100644 > --- a/drivers/gpu/drm/msm/dp/dp_display.c > +++ b/drivers/gpu/drm/msm/dp/dp_display.c > @@ -1665,7 +1665,7 @@ void dp_bridge_hpd_notify(struct drm_bridge *bridge, > return; > > if (!dp_display->link_ready && status == connector_status_connected) > - dp_add_event(dp, EV_HPD_PLUG_INT, 0, 0); > + dp_hpd_plug_handle(dp, 0); If I read the code correctly, and we get an external connect event inbetween a previous disconnect and the related disable call, this should result in a PLUG_INT being injected into the queue still. Will that not cause the same problem? Regards, Bjorn > else if (dp_display->link_ready && status == > connector_status_disconnected) > - dp_add_event(dp, EV_HPD_UNPLUG_INT, 0, 0); > + dp_hpd_unplug_handle(dp, 0); > } > -- > 2.43.2 >
Re: [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers
Hi Easwar, > Sorry, got excited. :) There were drivers I'd been part of that I specifically > wanted to fixup, but then the scope grew to other users of algobit. Well, you got some positive feedback, so that is good. > > It is true that I changed quite some controller drivers within the i2c > > realm. I did this to gain experience. As you also noticed quite some > > questions came up. We need to agree on answers first. And once we are > > happy with the answers we found, then IMO we can go outside of the i2c > > realm and send patches to other subsystems referencing agreed > > precedence. I intentionally did not go outside i2c yet. Since your > > patches are already there, you probably want to foster them until they > > are ready for inclusion. > > Sorry, I don't quite follow what you mean by foster in this context. Are > you asking me to hold off on merging the series, or to follow through on > getting it merged? I think they are your patches, so this is up to you to decide. With "foster", I meant you keep working on them until everyone is happy. I haven't looked at the drivers you modify. I can't tell if they can be converted right away or if they use a lot of I2C API calls, so that it makes sense to wait until the core is converted. I trust you to decide this. Happy hacking, Wolfram signature.asc Description: PGP signature
Re: [PATCH v2] drm/msm/dp: Remove now unused connector_type from desc
On 24-04-05 20:14:11, Bjorn Andersson wrote:
> Now that the connector_type is dynamically determined, the
> connector_type of the struct msm_dp_desc is unused. Clean it up.
>
> Remaining duplicate entries are squashed.
>
> Signed-off-by: Bjorn Andersson
Reviewed-by: Abel Vesa
> ---
> This cleans up after, and hence depends on,
> https://lore.kernel.org/all/20240324-x1e80100-display-refactor-connector-v4-1-e0ebaea66...@linaro.org/
> ---
> Changes in v2:
> - Squashed now duplicate entries
> - Link to v1:
> https://lore.kernel.org/r/20240328-dp-connector-type-cleanup-v1-1-9bf84c5a6...@quicinc.com
> ---
> drivers/gpu/drm/msm/dp/dp_display.c | 48
> +
> 1 file changed, 17 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 521cba76d2a0..12c01625c551 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -119,55 +119,41 @@ struct dp_display_private {
> struct msm_dp_desc {
> phys_addr_t io_start;
> unsigned int id;
> - unsigned int connector_type;
> bool wide_bus_supported;
> };
>
> static const struct msm_dp_desc sc7180_dp_descs[] = {
> - { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
> DRM_MODE_CONNECTOR_DisplayPort },
> + { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0 },
> {}
> };
>
> static const struct msm_dp_desc sc7280_dp_descs[] = {
> - { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
> DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
> - { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_1, .connector_type =
> DRM_MODE_CONNECTOR_eDP, .wide_bus_supported = true },
> + { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0,
> .wide_bus_supported = true },
> + { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_1,
> .wide_bus_supported = true },
> {}
> };
>
> static const struct msm_dp_desc sc8180x_dp_descs[] = {
> - { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
> DRM_MODE_CONNECTOR_DisplayPort },
> - { .io_start = 0x0ae98000, .id = MSM_DP_CONTROLLER_1, .connector_type =
> DRM_MODE_CONNECTOR_DisplayPort },
> - { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
> DRM_MODE_CONNECTOR_eDP },
> + { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0 },
> + { .io_start = 0x0ae98000, .id = MSM_DP_CONTROLLER_1 },
> + { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2 },
> {}
> };
>
> static const struct msm_dp_desc sc8280xp_dp_descs[] = {
> - { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
> DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
> - { .io_start = 0x0ae98000, .id = MSM_DP_CONTROLLER_1, .connector_type =
> DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
> - { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
> DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
> - { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_3, .connector_type =
> DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
> - { .io_start = 0x2209, .id = MSM_DP_CONTROLLER_0, .connector_type =
> DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
> - { .io_start = 0x22098000, .id = MSM_DP_CONTROLLER_1, .connector_type =
> DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
> - { .io_start = 0x2209a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
> DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
> - { .io_start = 0x220a, .id = MSM_DP_CONTROLLER_3, .connector_type =
> DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
> - {}
> -};
> -
> -static const struct msm_dp_desc sc8280xp_edp_descs[] = {
> - { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
> DRM_MODE_CONNECTOR_eDP, .wide_bus_supported = true },
> - { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_3, .connector_type =
> DRM_MODE_CONNECTOR_eDP, .wide_bus_supported = true },
> - { .io_start = 0x2209a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
> DRM_MODE_CONNECTOR_eDP, .wide_bus_supported = true },
> - { .io_start = 0x220a, .id = MSM_DP_CONTROLLER_3, .connector_type =
> DRM_MODE_CONNECTOR_eDP, .wide_bus_supported = true },
> - {}
> -};
> -
> -static const struct msm_dp_desc sm8350_dp_descs[] = {
> - { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
> DRM_MODE_CONNECTOR_DisplayPort },
> + { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0,
> .wide_bus_supported = true },
> + { .io_start = 0x0ae98000, .id = MSM_DP_CONTROLLER_1,
> .wide_bus_supported = true },
> + { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2,
> .wide_bus_supported = true },
> + { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_3,
> .wide_bus_supported = tr
[PATCH AUTOSEL 6.6 19/22] drm/amdkfd: range check cp bad op exception interrupts
From: Jonathan Kim
[ Upstream commit 0cac183b98d8a8c692c98e8dba37df15a9e9210d ]
Due to a CP interrupt bug, bad packet garbage exception codes are raised.
Do a range check so that the debugger and runtime do not receive garbage
codes.
Update the user api to guard exception code type checking as well.
Signed-off-by: Jonathan Kim
Tested-by: Jesse Zhang
Reviewed-by: Felix Kuehling
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/amdkfd/kfd_int_process_v10.c| 3 ++-
.../gpu/drm/amd/amdkfd/kfd_int_process_v11.c| 3 ++-
drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c | 3 ++-
include/uapi/linux/kfd_ioctl.h | 17 ++---
4 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v10.c
b/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v10.c
index a7697ec8188e0..f85ca6cb90f56 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v10.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v10.c
@@ -336,7 +336,8 @@ static void event_interrupt_wq_v10(struct kfd_node *dev,
break;
}
kfd_signal_event_interrupt(pasid, context_id0 &
0x7f, 23);
- } else if (source_id == SOC15_INTSRC_CP_BAD_OPCODE) {
+ } else if (source_id == SOC15_INTSRC_CP_BAD_OPCODE &&
+
KFD_DBG_EC_TYPE_IS_PACKET(KFD_DEBUG_CP_BAD_OP_ECODE(context_id0))) {
kfd_set_dbg_ev_from_interrupt(dev, pasid,
KFD_DEBUG_DOORBELL_ID(context_id0),
KFD_EC_MASK(KFD_DEBUG_CP_BAD_OP_ECODE(context_id0)),
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v11.c
b/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v11.c
index 2a65792fd1162..3ca9c160da7c2 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v11.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v11.c
@@ -325,7 +325,8 @@ static void event_interrupt_wq_v11(struct kfd_node *dev,
/* CP */
if (source_id == SOC15_INTSRC_CP_END_OF_PIPE)
kfd_signal_event_interrupt(pasid, context_id0, 32);
- else if (source_id == SOC15_INTSRC_CP_BAD_OPCODE)
+ else if (source_id == SOC15_INTSRC_CP_BAD_OPCODE &&
+
KFD_DBG_EC_TYPE_IS_PACKET(KFD_CTXID0_CP_BAD_OP_ECODE(context_id0)))
kfd_set_dbg_ev_from_interrupt(dev, pasid,
KFD_CTXID0_DOORBELL_ID(context_id0),
KFD_EC_MASK(KFD_CTXID0_CP_BAD_OP_ECODE(context_id0)),
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
b/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
index 27cdaea405017..8a6729939ae55 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
@@ -385,7 +385,8 @@ static void event_interrupt_wq_v9(struct kfd_node *dev,
break;
}
kfd_signal_event_interrupt(pasid, sq_int_data, 24);
- } else if (source_id == SOC15_INTSRC_CP_BAD_OPCODE) {
+ } else if (source_id == SOC15_INTSRC_CP_BAD_OPCODE &&
+
KFD_DBG_EC_TYPE_IS_PACKET(KFD_DEBUG_CP_BAD_OP_ECODE(context_id0))) {
kfd_set_dbg_ev_from_interrupt(dev, pasid,
KFD_DEBUG_DOORBELL_ID(context_id0),
KFD_EC_MASK(KFD_DEBUG_CP_BAD_OP_ECODE(context_id0)),
diff --git a/include/uapi/linux/kfd_ioctl.h b/include/uapi/linux/kfd_ioctl.h
index eeb2fdcbdcb70..cd924c959d732 100644
--- a/include/uapi/linux/kfd_ioctl.h
+++ b/include/uapi/linux/kfd_ioctl.h
@@ -909,14 +909,25 @@ enum kfd_dbg_trap_exception_code {
KFD_EC_MASK(EC_DEVICE_NEW))
#define KFD_EC_MASK_PROCESS(KFD_EC_MASK(EC_PROCESS_RUNTIME) | \
KFD_EC_MASK(EC_PROCESS_DEVICE_REMOVE))
+#define KFD_EC_MASK_PACKET
(KFD_EC_MASK(EC_QUEUE_PACKET_DISPATCH_DIM_INVALID) |\
+
KFD_EC_MASK(EC_QUEUE_PACKET_DISPATCH_GROUP_SEGMENT_SIZE_INVALID) | \
+
KFD_EC_MASK(EC_QUEUE_PACKET_DISPATCH_CODE_INVALID) | \
+KFD_EC_MASK(EC_QUEUE_PACKET_RESERVED) |
\
+KFD_EC_MASK(EC_QUEUE_PACKET_UNSUPPORTED) |
\
+
KFD_EC_MASK(EC_QUEUE_PACKET_DISPATCH_WORK_GROUP_SIZE_INVALID) |\
+
KFD_EC_MASK(EC_QUEUE_PACKET_DISPATCH_REGISTER_INVALID) | \
+
KFD_EC_MASK(EC_QUEUE_PACKET_VENDOR_UNSUPPORTED))
/* Checks for exception code types for KFD search */
+#define KFD_DBG_EC_IS_VALID(ecode) (ecode > EC_NONE && ecode < EC_MAX)
#define KFD_DBG_EC_TYPE_IS_QUEUE(ecode)
[PATCH AUTOSEL 6.6 18/22] drm/amdkfd: Check cgroup when returning DMABuf info
From: Mukul Joshi [ Upstream commit 9d7993a7ab9651afd5fb295a4992e511b2b727aa ] Check cgroup permissions when returning DMA-buf info and based on cgroup info return the GPU id of the GPU that have access to the BO. Signed-off-by: Mukul Joshi Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c index c37f1fcd2165b..c7933d7d11b10 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c @@ -1516,7 +1516,7 @@ static int kfd_ioctl_get_dmabuf_info(struct file *filep, /* Find a KFD GPU device that supports the get_dmabuf_info query */ for (i = 0; kfd_topology_enum_kfd_devices(i, &dev) == 0; i++) - if (dev) + if (dev && !kfd_devcgroup_check_permission(dev)) break; if (!dev) return -EINVAL; @@ -1538,7 +1538,7 @@ static int kfd_ioctl_get_dmabuf_info(struct file *filep, if (xcp_id >= 0) args->gpu_id = dmabuf_adev->kfd.dev->nodes[xcp_id]->id; else - args->gpu_id = dmabuf_adev->kfd.dev->nodes[0]->id; + args->gpu_id = dev->id; args->flags = flags; /* Copy metadata buffer to user mode */ -- 2.43.0
[PATCH AUTOSEL 6.8 22/25] drm/amdkfd: range check cp bad op exception interrupts
From: Jonathan Kim
[ Upstream commit 0cac183b98d8a8c692c98e8dba37df15a9e9210d ]
Due to a CP interrupt bug, bad packet garbage exception codes are raised.
Do a range check so that the debugger and runtime do not receive garbage
codes.
Update the user api to guard exception code type checking as well.
Signed-off-by: Jonathan Kim
Tested-by: Jesse Zhang
Reviewed-by: Felix Kuehling
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/amdkfd/kfd_int_process_v10.c| 3 ++-
.../gpu/drm/amd/amdkfd/kfd_int_process_v11.c| 3 ++-
drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c | 3 ++-
include/uapi/linux/kfd_ioctl.h | 17 ++---
4 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v10.c
b/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v10.c
index a7697ec8188e0..f85ca6cb90f56 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v10.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v10.c
@@ -336,7 +336,8 @@ static void event_interrupt_wq_v10(struct kfd_node *dev,
break;
}
kfd_signal_event_interrupt(pasid, context_id0 &
0x7f, 23);
- } else if (source_id == SOC15_INTSRC_CP_BAD_OPCODE) {
+ } else if (source_id == SOC15_INTSRC_CP_BAD_OPCODE &&
+
KFD_DBG_EC_TYPE_IS_PACKET(KFD_DEBUG_CP_BAD_OP_ECODE(context_id0))) {
kfd_set_dbg_ev_from_interrupt(dev, pasid,
KFD_DEBUG_DOORBELL_ID(context_id0),
KFD_EC_MASK(KFD_DEBUG_CP_BAD_OP_ECODE(context_id0)),
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v11.c
b/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v11.c
index 2a65792fd1162..3ca9c160da7c2 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v11.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v11.c
@@ -325,7 +325,8 @@ static void event_interrupt_wq_v11(struct kfd_node *dev,
/* CP */
if (source_id == SOC15_INTSRC_CP_END_OF_PIPE)
kfd_signal_event_interrupt(pasid, context_id0, 32);
- else if (source_id == SOC15_INTSRC_CP_BAD_OPCODE)
+ else if (source_id == SOC15_INTSRC_CP_BAD_OPCODE &&
+
KFD_DBG_EC_TYPE_IS_PACKET(KFD_CTXID0_CP_BAD_OP_ECODE(context_id0)))
kfd_set_dbg_ev_from_interrupt(dev, pasid,
KFD_CTXID0_DOORBELL_ID(context_id0),
KFD_EC_MASK(KFD_CTXID0_CP_BAD_OP_ECODE(context_id0)),
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
b/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
index 27cdaea405017..8a6729939ae55 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
@@ -385,7 +385,8 @@ static void event_interrupt_wq_v9(struct kfd_node *dev,
break;
}
kfd_signal_event_interrupt(pasid, sq_int_data, 24);
- } else if (source_id == SOC15_INTSRC_CP_BAD_OPCODE) {
+ } else if (source_id == SOC15_INTSRC_CP_BAD_OPCODE &&
+
KFD_DBG_EC_TYPE_IS_PACKET(KFD_DEBUG_CP_BAD_OP_ECODE(context_id0))) {
kfd_set_dbg_ev_from_interrupt(dev, pasid,
KFD_DEBUG_DOORBELL_ID(context_id0),
KFD_EC_MASK(KFD_DEBUG_CP_BAD_OP_ECODE(context_id0)),
diff --git a/include/uapi/linux/kfd_ioctl.h b/include/uapi/linux/kfd_ioctl.h
index f0ed68974c543..5fdaf0ab460da 100644
--- a/include/uapi/linux/kfd_ioctl.h
+++ b/include/uapi/linux/kfd_ioctl.h
@@ -912,14 +912,25 @@ enum kfd_dbg_trap_exception_code {
KFD_EC_MASK(EC_DEVICE_NEW))
#define KFD_EC_MASK_PROCESS(KFD_EC_MASK(EC_PROCESS_RUNTIME) | \
KFD_EC_MASK(EC_PROCESS_DEVICE_REMOVE))
+#define KFD_EC_MASK_PACKET
(KFD_EC_MASK(EC_QUEUE_PACKET_DISPATCH_DIM_INVALID) |\
+
KFD_EC_MASK(EC_QUEUE_PACKET_DISPATCH_GROUP_SEGMENT_SIZE_INVALID) | \
+
KFD_EC_MASK(EC_QUEUE_PACKET_DISPATCH_CODE_INVALID) | \
+KFD_EC_MASK(EC_QUEUE_PACKET_RESERVED) |
\
+KFD_EC_MASK(EC_QUEUE_PACKET_UNSUPPORTED) |
\
+
KFD_EC_MASK(EC_QUEUE_PACKET_DISPATCH_WORK_GROUP_SIZE_INVALID) |\
+
KFD_EC_MASK(EC_QUEUE_PACKET_DISPATCH_REGISTER_INVALID) | \
+
KFD_EC_MASK(EC_QUEUE_PACKET_VENDOR_UNSUPPORTED))
/* Checks for exception code types for KFD search */
+#define KFD_DBG_EC_IS_VALID(ecode) (ecode > EC_NONE && ecode < EC_MAX)
#define KFD_DBG_EC_TYPE_IS_QUEUE(ecode)
[PATCH AUTOSEL 6.8 21/25] drm/amdgpu/vpe: power on vpe when hw_init
From: Peyton Lee [ Upstream commit eed14eb48ee176fe0144c6a999d00c855d0b199b ] To fix mode2 reset failure. Should power on VPE when hw_init. Signed-off-by: Peyton Lee Reviewed-by: Lang Yu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_vpe.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vpe.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vpe.c index b9a15d51eb5c3..ad44012cc01e2 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vpe.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vpe.c @@ -390,6 +390,12 @@ static int vpe_hw_init(void *handle) struct amdgpu_vpe *vpe = &adev->vpe; int ret; + /* Power on VPE */ + ret = amdgpu_device_ip_set_powergating_state(adev, AMD_IP_BLOCK_TYPE_VPE, +AMD_PG_STATE_UNGATE); + if (ret) + return ret; + ret = vpe_load_microcode(vpe); if (ret) return ret; -- 2.43.0
[PATCH AUTOSEL 6.8 20/25] drm/amdkfd: Check cgroup when returning DMABuf info
From: Mukul Joshi [ Upstream commit 9d7993a7ab9651afd5fb295a4992e511b2b727aa ] Check cgroup permissions when returning DMA-buf info and based on cgroup info return the GPU id of the GPU that have access to the BO. Signed-off-by: Mukul Joshi Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c index 80e90fdef291d..9a88b35cd8966 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c @@ -1522,7 +1522,7 @@ static int kfd_ioctl_get_dmabuf_info(struct file *filep, /* Find a KFD GPU device that supports the get_dmabuf_info query */ for (i = 0; kfd_topology_enum_kfd_devices(i, &dev) == 0; i++) - if (dev) + if (dev && !kfd_devcgroup_check_permission(dev)) break; if (!dev) return -EINVAL; @@ -1544,7 +1544,7 @@ static int kfd_ioctl_get_dmabuf_info(struct file *filep, if (xcp_id >= 0) args->gpu_id = dmabuf_adev->kfd.dev->nodes[xcp_id]->id; else - args->gpu_id = dmabuf_adev->kfd.dev->nodes[0]->id; + args->gpu_id = dev->id; args->flags = flags; /* Copy metadata buffer to user mode */ -- 2.43.0
[PATCH AUTOSEL 6.8 16/25] drm/xe: Fix END redefinition
From: Lucas De Marchi
[ Upstream commit 0d8cf0c924732a045273c6aca6900a340ac88529 ]
mips declares an END macro in its headers so it can't be used without
namespace in a driver like xe.
Instead of coming up with a longer name, just remove the macro and
replace its use with 0 since it's still clear what that means:
set_offsets() was already using that implicitly when checking the data
variable.
Reported-by: Guenter Roeck
Closes: http://kisskb.ellerman.id.au/kisskb/buildresult/15143996/
Tested-by: Guenter Roeck
Reviewed-by: Jani Nikula
Link:
https://patchwork.freedesktop.org/patch/msgid/20240322145037.196548-1-lucas.demar...@intel.com
Signed-off-by: Lucas De Marchi
(cherry picked from commit 35b22649eb4155ca6bcffcb2c6e2a1d311aaaf72)
Signed-off-by: Lucas De Marchi
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/xe/xe_lrc.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_lrc.c b/drivers/gpu/drm/xe/xe_lrc.c
index b38319d2801e0..0aa4bcfb90d9d 100644
--- a/drivers/gpu/drm/xe/xe_lrc.c
+++ b/drivers/gpu/drm/xe/xe_lrc.c
@@ -95,7 +95,6 @@ static void set_offsets(u32 *regs,
#define REG16(x) \
(((x) >> 9) | BIT(7) | BUILD_BUG_ON_ZERO(x >= 0x1)), \
(((x) >> 2) & 0x7f)
-#define END 0
{
const u32 base = hwe->mmio_base;
@@ -166,7 +165,7 @@ static const u8 gen12_xcs_offsets[] = {
REG16(0x274),
REG16(0x270),
- END
+ 0
};
static const u8 dg2_xcs_offsets[] = {
@@ -200,7 +199,7 @@ static const u8 dg2_xcs_offsets[] = {
REG16(0x274),
REG16(0x270),
- END
+ 0
};
static const u8 gen12_rcs_offsets[] = {
@@ -296,7 +295,7 @@ static const u8 gen12_rcs_offsets[] = {
REG(0x084),
NOP(1),
- END
+ 0
};
static const u8 xehp_rcs_offsets[] = {
@@ -337,7 +336,7 @@ static const u8 xehp_rcs_offsets[] = {
LRI(1, 0),
REG(0x0c8),
- END
+ 0
};
static const u8 dg2_rcs_offsets[] = {
@@ -380,7 +379,7 @@ static const u8 dg2_rcs_offsets[] = {
LRI(1, 0),
REG(0x0c8),
- END
+ 0
};
static const u8 mtl_rcs_offsets[] = {
@@ -423,7 +422,7 @@ static const u8 mtl_rcs_offsets[] = {
LRI(1, 0),
REG(0x0c8),
- END
+ 0
};
#define XE2_CTX_COMMON \
@@ -469,7 +468,7 @@ static const u8 xe2_rcs_offsets[] = {
LRI(1, 0), /* [0x47] */
REG(0x0c8), /* [0x48] R_PWR_CLK_STATE */
- END
+ 0
};
static const u8 xe2_bcs_offsets[] = {
@@ -480,16 +479,15 @@ static const u8 xe2_bcs_offsets[] = {
REG16(0x200), /* [0x42] BCS_SWCTRL */
REG16(0x204), /* [0x44] BLIT_CCTL */
- END
+ 0
};
static const u8 xe2_xcs_offsets[] = {
XE2_CTX_COMMON,
- END
+ 0
};
-#undef END
#undef REG16
#undef REG
#undef LRI
--
2.43.0
Re: [PATCH v0 10/14] sfc: falcon: Make I2C terminology more inclusive
On Thu, Apr 04, 2024 at 12:17:26PM -0700, Easwar Hariharan wrote: > On 4/2/2024 1:29 AM, Simon Horman wrote: > > On Fri, Mar 29, 2024 at 05:00:34PM +, Easwar Hariharan wrote: > >> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave" > >> with more appropriate terms. Inspired by and following on to Wolfram's > >> series to fix drivers/i2c/[1], fix the terminology for users of > >> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists > >> in the specification. > >> > >> Compile tested, no functionality changes intended > >> > >> [1]: > >> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/ > >> > >> Signed-off-by: Easwar Hariharan > > > > Reviewed-by: Simon Horman > > > Thank you, Simon, for reviewing. I believe that we are settling on > controller/target > terminology from feedback on the other drivers in this series. Would you want > to re-review > v1 with that change, or should I add you R-B in v1 despite the change? Thanks for asking, either way is fine by me.
Re: [PATCH v9 1/6] dmaengine: Add API function dmaengine_prep_peripheral_dma_vec()
On 02-04-24, 13:31, Paul Cercueil wrote:
> Hi Vinod,
>
> Le jeudi 28 mars 2024 à 11:53 +0530, Vinod Koul a écrit :
> > On 10-03-24, 13:48, Paul Cercueil wrote:
> > > This function can be used to initiate a scatter-gather DMA
> > > transfer,
> > > where the address and size of each segment is located in one entry
> > > of
> > > the dma_vec array.
> > >
> > > The major difference with dmaengine_prep_slave_sg() is that it
> > > supports
> > > specifying the lengths of each DMA transfer; as trying to override
> > > the
> > > length of the transfer with dmaengine_prep_slave_sg() is a very
> > > tedious
> > > process. The introduction of a new API function is also justified
> > > by the
> > > fact that scatterlists are on their way out.
> > >
> > > Note that dmaengine_prep_interleaved_dma() is not helpful either in
> > > that
> > > case, as it assumes that the address of each segment will be higher
> > > than
> > > the one of the previous segment, which we just cannot guarantee in
> > > case
> > > of a scatter-gather transfer.
> > >
> > > Signed-off-by: Paul Cercueil
> > > Signed-off-by: Nuno Sa
> > >
> > > ---
> > > v3: New patch
> > >
> > > v5: Replace with function dmaengine_prep_slave_dma_vec(), and
> > > struct
> > > 'dma_vec'.
> > > Note that at some point we will need to support cyclic
> > > transfers
> > > using dmaengine_prep_slave_dma_vec(). Maybe with a new "flags"
> > > parameter to the function?
> > >
> > > v7:
> > > - Renamed *device_prep_slave_dma_vec() ->
> > > device_prep_peripheral_dma_vec();
> > > - Added a new flag parameter to the function as agreed between
> > > Paul
> > > and Vinod. I renamed the first parameter to prep_flags as it's
> > > supposed to
> > > be used (I think) with enum dma_ctrl_flags. I'm not really sure
> > > how that API
> > > can grow but I was thinking in just having a bool cyclic
> > > parameter (as the
> > > first intention of the flags is to support cyclic transfers)
> > > but ended up
> > > "respecting" the previously agreed approach.
> > > ---
> > > include/linux/dmaengine.h | 27 +++
> > > 1 file changed, 27 insertions(+)
> > >
> > > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > > index 752dbde4cec1..856df8cd9a4e 100644
> > > --- a/include/linux/dmaengine.h
> > > +++ b/include/linux/dmaengine.h
> > > @@ -160,6 +160,16 @@ struct dma_interleaved_template {
> > > struct data_chunk sgl[];
> > > };
> > >
> > > +/**
> > > + * struct dma_vec - DMA vector
> > > + * @addr: Bus address of the start of the vector
> > > + * @len: Length in bytes of the DMA vector
> > > + */
> > > +struct dma_vec {
> > > + dma_addr_t addr;
> > > + size_t len;
> > > +};
> > > +
> > > /**
> > > * enum dma_ctrl_flags - DMA flags to augment operation
> > > preparation,
> > > * control completion, and communicate status.
> > > @@ -910,6 +920,10 @@ struct dma_device {
> > > struct dma_async_tx_descriptor
> > > *(*device_prep_dma_interrupt)(
> > > struct dma_chan *chan, unsigned long flags);
> > >
> > > + struct dma_async_tx_descriptor
> > > *(*device_prep_peripheral_dma_vec)(
> > > + struct dma_chan *chan, const struct dma_vec *vecs,
> > > + size_t nents, enum dma_transfer_direction
> > > direction,
> > > + unsigned long prep_flags, unsigned long flags);
> > > struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
> > > struct dma_chan *chan, struct scatterlist *sgl,
> > > unsigned int sg_len, enum dma_transfer_direction
> > > direction,
> > > @@ -973,6 +987,19 @@ static inline struct dma_async_tx_descriptor
> > > *dmaengine_prep_slave_single(
> > > dir, flags,
> > > NULL);
> > > }
> > >
> > > +static inline struct dma_async_tx_descriptor
> > > *dmaengine_prep_peripheral_dma_vec(
> > > + struct dma_chan *chan, const struct dma_vec *vecs, size_t
> > > nents,
> > > + enum dma_transfer_direction dir, unsigned long prep_flags,
> > > + unsigned long flags)
> > > +{
> > > + if (!chan || !chan->device || !chan->device-
> > > >device_prep_peripheral_dma_vec)
> > > + return NULL;
> > > +
> > > + return chan->device->device_prep_peripheral_dma_vec(chan,
> > > vecs, nents,
> > > + dir,
> > > prep_flags,
> > > +
> > > flags);
> > > +}
> >
> > API looks good to me, thanks
> > Few nits though:
> > - Can we add kernel-doc for this new API please
> > - Also update the documentation adding this new api
> > - Lastly, we seem to have two flags, I know you have added a comment
> > but
> > I dont seem to recall the discussion (looked at old threads for
> > clue
> > as well), can you please remind me why we need both? And in your
> > case,
> > what is the intended usage of these flags, i would prefer single
> > clean one...
> >
>
> The "prep_flags" is a mask of "enum dma_ctrl_flags".
