Re: [PATCH 1/4] drm/exynos/vidi: fix memory leak in .get_modes()
Hi Jani Nikula,
The patch(1/4) has been applied to the -fixes branch, and the other
three patches(2/4 ~ 4/4) have been applied to the -next branch.
Thanks,
Inki Dae
2024년 5월 30일 (목) 오후 7:02, Jani Nikula 님이 작성:
>
> The duplicated EDID is never freed. Fix it.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> index fab135308b70..11a720fef32b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -309,6 +309,7 @@ static int vidi_get_modes(struct drm_connector *connector)
> struct vidi_context *ctx = ctx_from_connector(connector);
> struct edid *edid;
> int edid_len;
> + int count;
>
> /*
> * the edid data comes from user side and it would be set
> @@ -328,7 +329,11 @@ static int vidi_get_modes(struct drm_connector
> *connector)
>
> drm_connector_update_edid_property(connector, edid);
>
> - return drm_add_edid_modes(connector, edid);
> + count = drm_add_edid_modes(connector, edid);
> +
> + kfree(edid);
> +
> + return count;
> }
>
> static const struct drm_connector_helper_funcs vidi_connector_helper_funcs =
> {
> --
> 2.39.2
>
>
Re: [PATCH] drm/msm/a6xx: request memory region
On Sat, Jun 08, 2024 at 11:43:47AM -0400, Kiarash Hajian wrote: > The driver's memory regions are currently just ioremap()ed, but not > reserved through a request. That's not a bug, but having the request is > a little more robust. > > Implement the region-request through the corresponding managed > devres-function. > > Signed-off-by: Kiarash Hajian > --- > Changes in v6: > -Fix compile error > -Link to v5: > https://lore.kernel.org/all/20240607-memory-v1-1-8664f52fc...@gmail.com > > Changes in v5: > - Fix error hanlding problems. > - Link to v4: > https://lore.kernel.org/r/20240512-msm-adreno-memory-region-v4-1-3881a6408...@gmail.com > > Changes in v4: > - Combine v3 commits into a singel commit > - Link to v3: > https://lore.kernel.org/r/20240512-msm-adreno-memory-region-v3-0-0a728ad45...@gmail.com > > Changes in v3: > - Remove redundant devm_iounmap calls, relying on devres for automatic > resource cleanup. > > Changes in v2: > - update the subject prefix to "drm/msm/a6xx:", to match the majority of > other changes to this file. > --- > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 33 +++-- > 1 file changed, 11 insertions(+), 22 deletions(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH net-next v10 02/14] net: page_pool: create hooks for custom page providers
On 6/7/24 17:59, Mina Almasry wrote: On Fri, Jun 7, 2024 at 8:47 AM Pavel Begunkov wrote: On 6/7/24 16:42, Pavel Begunkov wrote: On 6/7/24 15:27, David Ahern wrote: On 6/7/24 7:42 AM, Pavel Begunkov wrote: I haven't seen any arguments against from the (net) maintainers so far. Nor I see any objection against callbacks from them (considering that either option adds an if). I have said before I do not understand why the dmabuf paradigm is not sufficient for both device memory and host memory. A less than ideal control path to put hostmem in a dmabuf wrapper vs extra checks and changes in the datapath. The former should always be preferred. If we're talking about types of memory specifically, I'm not strictly against wrapping into dmabuf in kernel, but that just doesn't give anything. And the reason I don't have too strong of an opinion on that is mainly because it's just setup/cleanup path. I agree wrapping io uring in dmabuf seems to be an unnecessary detour. I never understood the need or upside to do that, but it could be a lack of understanding on my part. However, the concern that David brings up may materialize. I've had to spend a lot of time minimizing or justifying checks to the code with page pool benchmarks that detect even 1 cycle regressions. You may be asked to run the same benchmarks and minimize similar overhead. The benchmark in question is Jesper's bench_page_pool_simple. I've forked it and applied it on top of net-next here: https://github.com/mina/linux/commit/927596f87ab5791a8a6ba8597ba2189747396e54 As io_uring ZC comes close to merging, I suspect it would be good to run this to understand the regression in the fast path, if any. If there are no to little regressions, I have no concerns over io uring memory not being wrapped in dmabufs, and David may agree as well. That's the easiest part as io_uring only reusing call points you added for devmem and thus doesn't add anything new on top to hot paths. -- Pavel Begunkov
Re: [PATCH net-next v10 02/14] net: page_pool: create hooks for custom page providers
On 6/10/24 01:37, David Wei wrote: On 2024-06-07 17:52, Jason Gunthorpe wrote: IMHO it seems to compose poorly if you can only use the io_uring lifecycle model with io_uring registered memory, and not with DMABUF memory registered through Mina's mechanism. By this, do you mean io_uring must be exclusively used to use this feature? And you'd rather see the two decoupled, so userspace can register w/ say dmabuf then pass it to io_uring? Personally, I have no clue what Jason means. You can just as well say that it's poorly composable that write(2) to a disk cannot post a completion into a XDP ring, or a netlink socket, or io_uring's main completion queue, or name any other API. The devmem TCP callback can implement it in a way feasible to the project, but it cannot directly post events to an unrelated API like io_uring. And devmem attaches buffers to a socket, for which a ring for returning buffers might even be a nuisance. -- Pavel Begunkov
Re: [PATCH net-next v10 02/14] net: page_pool: create hooks for custom page providers
On 2024-06-07 17:52, Jason Gunthorpe wrote: > IMHO it seems to compose poorly if you can only use the io_uring > lifecycle model with io_uring registered memory, and not with DMABUF > memory registered through Mina's mechanism. By this, do you mean io_uring must be exclusively used to use this feature? And you'd rather see the two decoupled, so userspace can register w/ say dmabuf then pass it to io_uring? > > Jason
Re: [PATCH net-next v10 02/14] net: page_pool: create hooks for custom page providers
On 2024-06-07 17:27, David Ahern wrote: > I also do not understand why the ifq cache and overloading xdp functions > have stuck around; I always thought both were added by Jonathan to > simplify kernel ports during early POC days. Setting up an Rx queue for ZC w/ a different pp will be done properly using the new queue API that Mina merged recently. Those custom XDP hooks will be gone in a non-RFC patchset.
[PATCH 2/2] drm/panel: Add Samsung AMS639RQ08 panel driver
Add the driver for Samsung AMS639RQ08 FHD Plus CMD mode panel support
found in:
- Xiaomi Mi 9 Lite / CC9 (sdm710-xiaomi-pyxis)
- Xiaomi Mi 9T / Redmi K20 (sm7150-xiaomi-davinci)
- Xiaomi Mi 9T Pro / Redmi K20 Pro (sm8150-xiaomi-raphael)
Tested-by: Degdag Mohamed # xiaomi-raphael
Tested-by: Jens Reidel # xiaomi-davinci
Signed-off-by: Danila Tikhonov
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-samsung-ams639rq08.c | 362 ++
3 files changed, 372 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-samsung-ams639rq08.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 2ae0eb0638f32..8a86960ae812a 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -576,6 +576,15 @@ config DRM_PANEL_RONBO_RB070D30
Say Y here if you want to enable support for Ronbo Electronics
RB070D30 1024x600 DSI panel.
+config DRM_PANEL_SAMSUNG_AMS639RQ08
+ tristate "Samsung AMS639RQ08 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y or M here if you want to enable support for the
+ Samsung AMS639RQ08 FHD Plus (2340x1080@60Hz) CMD mode panel.
+
config DRM_PANEL_SAMSUNG_S6E88A0_AMS452EF01
tristate "Samsung AMS452EF01 panel with S6E88A0 DSI video mode
controller"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f0203f6e02f44..eb87bc01b0414 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) +=
panel-raydium-rm68200.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM692E5) += panel-raydium-rm692e5.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM69380) += panel-raydium-rm69380.o
obj-$(CONFIG_DRM_PANEL_RONBO_RB070D30) += panel-ronbo-rb070d30.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_AMS639RQ08) += panel-samsung-ams639rq08.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20) += panel-samsung-atna33xc20.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_DB7430) += panel-samsung-db7430.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-ams639rq08.c
b/drivers/gpu/drm/panel/panel-samsung-ams639rq08.c
new file mode 100644
index 0..f9789fdd6c326
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-ams639rq08.c
@@ -0,0 +1,362 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2024, Danila Tikhonov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+
+/* Manufacturer Command Set */
+#define MCS_ACCESS_PROT_OFF0xb0
+#define MCS_UNKNOWN_B7 0xb7
+#define MCS_BIAS_CURRENT_CTRL 0xd1
+#define MCS_PASSWD10xf0
+#define MCS_PASSWD20xfc
+#define MCS_UNKNOWN_FF 0xff
+
+struct ams639rq08 {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi;
+ struct gpio_desc *reset_gpio;
+ struct regulator_bulk_data supplies[4];
+};
+
+static inline struct ams639rq08 *to_ams639rq08(struct drm_panel *panel)
+{
+ return container_of(panel, struct ams639rq08, panel);
+}
+
+static void ams639rq08_reset(struct ams639rq08 *ctx)
+{
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+ usleep_range(1000, 2000);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ usleep_range(1, 11000);
+}
+
+static int ams639rq08_on(struct ams639rq08 *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi;
+ struct device *dev = &dsi->dev;
+ int ret;
+
+ /* Delay 2ms for VCI1 power */
+ mipi_dsi_dcs_write_seq(dsi, MCS_PASSWD1, 0x5a, 0x5a);
+ mipi_dsi_dcs_write_seq(dsi, MCS_PASSWD2, 0x5a, 0x5a);
+ mipi_dsi_dcs_write_seq(dsi, MCS_ACCESS_PROT_OFF, 0x0c);
+ mipi_dsi_dcs_write_seq(dsi, MCS_UNKNOWN_FF, 0x10);
+ mipi_dsi_dcs_write_seq(dsi, MCS_ACCESS_PROT_OFF, 0x2f);
+ mipi_dsi_dcs_write_seq(dsi, MCS_BIAS_CURRENT_CTRL, 0x01);
+ mipi_dsi_dcs_write_seq(dsi, MCS_PASSWD1, 0xa5, 0xa5);
+ mipi_dsi_dcs_write_seq(dsi, MCS_PASSWD2, 0xa5, 0xa5);
+
+ /* Sleep Out */
+ ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
+ return ret;
+ }
+ usleep_range(1, 11000);
+
+ /* TE OUT (Vsync On) */
+ mipi_dsi_dcs_write_seq(dsi, MCS_PASSWD1, 0x5a, 0x5a);
+
+ ret = mipi_dsi_dcs_set_tear_on(dsi, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set tear on: %d\n", ret);
+ return ret;
+ }
+
+ /* DBV Smooth Transition */
+ mipi_dsi_dcs_write_seq(dsi, MCS_UNKNOWN_B7, 0x01, 0x4b);
+
+ /* Edge Dimming Speed Setting */
+ mipi_dsi_dcs_write_seq(dsi, MCS_ACCESS_PROT_OFF, 0x06);
+
Re: 6.10/bisected/regression - commits bc87d666c05 and 6d4279cb99ac cause appearing green flashing bar on top of screen on Radeon 6900XT and 120Hz
On Fri, Jun 7, 2024 at 6:39 PM Alex Deucher wrote: > > --- a/drivers/gpu/drm/amd/display/dc/optc/dcn10/dcn10_optc.c > +++ b/drivers/gpu/drm/amd/display/dc/optc/dcn10/dcn10_optc.c > @@ -944,7 +944,7 @@ void optc1_set_drr( > OTG_V_TOTAL_MAX_SEL, 1, > OTG_FORCE_LOCK_ON_EVENT, 0, > OTG_SET_V_TOTAL_MIN_MASK_EN, 0, > - OTG_SET_V_TOTAL_MIN_MASK, 0); > + OTG_SET_V_TOTAL_MIN_MASK, (1 << 1)); /* TRIGA > */ > > // Setup manual flow control for EOF via TRIG_A > optc->funcs->setup_manual_trigger(optc); Thanks, Alex. I applied this patch on top of 771ed66105de and unfortunately the issue is not fixed. I saw a green flashing bar on top of the screen again. -- Best Regards, Mike Gavrilov.
[PATCH 1/2] dt-bindings: display: panel: Add Samsung AMS639RQ08
The Samsung AMS639RQ08 is a 6.39 inch 1080x2340 MIPI-DSI CMD mode
AMOLED panel used in:
- Xiaomi Mi 9 Lite / CC9 (sdm710-xiaomi-pyxis)
- Xiaomi Mi 9T / Redmi K20 (sm7150-xiaomi-davinci)
- Xiaomi Mi 9T Pro / Redmi K20 Pro (sm8150-xiaomi-raphael)
Add a dt-binding for it.
Signed-off-by: Danila Tikhonov
---
.../display/panel/samsung,ams639rq08.yaml | 80 +++
1 file changed, 80 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/samsung,ams639rq08.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/samsung,ams639rq08.yaml
b/Documentation/devicetree/bindings/display/panel/samsung,ams639rq08.yaml
new file mode 100644
index 0..3a561156f5601
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,ams639rq08.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/samsung,ams639rq08.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung AMS639RQ08 EA8076-based 6.39" 1080x2340 MIPI-DSI Panel
+
+maintainers:
+ - Danila Tikhonov
+ - Jens Reidel
+
+description: |
+ The Samsung AMS639RQ08 is a 6.39 inch 1080x2340 MIPI-DSI CMD mode AMOLED
panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: samsung,ams639rq08
+
+ reg:
+maxItems: 1
+
+ vdd3p3-supply:
+description: 3.3V source voltage rail
+
+ vddio-supply:
+description: I/O source voltage rail
+
+ vsn-supply:
+description: Positive source voltage rail
+
+ vsp-supply:
+description: Negative source voltage rail
+
+ reset-gpios: true
+ port: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - vdd3p3-supply
+ - vddio-supply
+ - vsn-supply
+ - vsp-supply
+ - reset-gpios
+ - port
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "samsung,ams639rq08";
+reg = <0>;
+
+vdd3p3-supply = <&vreg_l18a_2p8>;
+vddio-supply = <&vreg_l13a_1p8>;
+vsn-supply = <&vreg_ibb>;
+vsp-supply = <&vreg_lab>;
+
+reset-gpios = <&pm6150l_gpios 9 GPIO_ACTIVE_LOW>;
+
+port {
+panel_in: endpoint {
+remote-endpoint = <&mdss_dsi0_out>;
+};
+};
+};
+};
+
+...
--
2.45.2
[drm-misc:topic/rust-drm 12/20] error: cannot find macro `define_pci_id_table` in this scope
tree: git://anongit.freedesktop.org/drm/drm-misc topic/rust-drm
head: 508348922df19178b613531fb6cc7beb624642ae
commit: 40ece0eeffd16953a9a20d50a4a3b35f87016556 [12/20] rust: add basic PCI
driver abstractions
config: riscv-randconfig-r121-20240609
(https://download.01.org/0day-ci/archive/20240610/202406100506.3t1kzbeq-...@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project
d7d2d4f53fc79b4b58e8d8d08151b577c3699d4a)
reproduce:
(https://download.01.org/0day-ci/archive/20240610/202406100506.3t1kzbeq-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202406100506.3t1kzbeq-...@intel.com/
All errors (new ones prefixed by >>):
>> error[E0412]: cannot find type `MyDriver` in this scope
--> rust/doctests_kernel_generated.rs:2331:23
|
2331 | impl pci::Driver for MyDriver {
| not found in this scope
--
>> error[E0412]: cannot find type `Arc` in this scope
--> rust/doctests_kernel_generated.rs:2332:18
|
2332 | type Data = Arc;
| ^^^ not found in this scope
|
help: consider importing this struct
|
3+ use kernel::sync::Arc;
|
--
>> error[E0412]: cannot find type `MyDeviceData` in this scope
--> rust/doctests_kernel_generated.rs:2332:22
|
2332 | type Data = Arc;
| not found in this scope
|
help: you might be missing a type parameter
|
2331 | impl pci::Driver for MyDriver {
| ++
--
>> error[E0412]: cannot find type `Arc` in this scope
--> rust/doctests_kernel_generated.rs:2345:18
|
2345 | ) -> Result> {
| ^^^ not found in this scope
|
help: consider importing this struct
|
3+ use kernel::sync::Arc;
|
--
>> error[E0412]: cannot find type `MyDriver` in this scope
--> rust/doctests_kernel_generated.rs:2355:12
|
2355 | type: MyDriver,
| not found in this scope
--
>> error: missing type for `static` item
--> rust/doctests_kernel_generated.rs:2354:2
|
2354 | / kernel::module_pci_driver! {
2355 | | type: MyDriver,
2356 | | name: "Module name",
2357 | | author: "Author name",
2358 | | description: "Description",
2359 | | license: "GPL v2",
2360 | | }
| |__^ help: provide a type for the item: `: `
|
= note: this error originates in the macro `$crate::prelude::module` which
comes from the expansion of the macro `kernel::module_pci_driver` (in Nightly
builds, run with -Z macro-backtrace for more info)
--
>> error: unexpected token: `...`
--> rust/doctests_kernel_generated.rs:2346:10
|
2346 | ...
| ^^^
|
help: use `..` for an exclusive range
|
2346 | ..
|
help: or `..=` for an inclusive range
|
2346 | ..=
|
--
>> error[E0586]: inclusive range with no end
--> rust/doctests_kernel_generated.rs:2346:10
|
2346 | ...
| ^^^ help: use `..` instead
|
= note: inclusive ranges must be bounded at the end (`..=b` or `a..=b`)
--
>> error: unexpected token: `...`
--> rust/doctests_kernel_generated.rs:2350:10
|
2350 | ...
| ^^^
|
help: use `..` for an exclusive range
|
2350 | ..
|
help: or `..=` for an inclusive range
|
2350 | ..=
|
--
>> error[E0586]: inclusive range with no end
--> rust/doctests_kernel_generated.rs:2350:10
|
2350 | ...
| ^^^ help: use `..` instead
|
= note: inclusive ranges must be bounded at the end (`..=b` or `a..=b`)
--
>> error: expected one of `:`, `;`, or `=`, found `name_initcall`
--> rust/doctests_kernel_generated.rs:2354:2
|
2354 | / kernel::module_pci_driver! {
2355 | | type: MyDriver,
2356 | | name: "Module name",
2357 | | author: "Author name",
2358 | | description: "Description",
2359 | | license: "GPL v2",
2360 | | }
| |__^ expected one of `:`, `;`, or `=`
|
= note: this error originates in the macro `$crate::prelude::module` which
comes from the expansion of the macro `kernel::module_pci_driver` (in Nightly
builds, run with -Z macro-backtrace for more info)
..
sparse warnings: (new ones prefixed by >>)
>> rust/helpers.c:203:5: sparse: sparse: symbol 'rust_helper_pci_resource_len'
>> was not declared. Should it be static?
rust/helpers.c:62:6: sparse: sparse: context imbalance in
'rust_helper_spin_lock' - wrong count at exit
rust/helpers
Re: [PATCH] drm/bridge: it6505: Fix potential NULL dereference
On Sun, Jun 09, 2024 at 10:38:39PM +0300, Dmitry Baryshkov wrote:
> On Sat, Jun 08, 2024 at 05:21:08PM +0300, Dan Carpenter wrote:
> > Smatch complains correctly that the NULL checking isn't consistent:
> >
> > drivers/gpu/drm/bridge/ite-it6505.c:2583 it6505_poweron()
> > error: we previously assumed 'pdata->pwr18' could be null
> > (see line 2569)
> >
> > Add a NULL check to prevent a NULL dereference on the error path.
> >
> > Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
> > Signed-off-by: Dan Carpenter
> > ---
> > drivers/gpu/drm/bridge/ite-it6505.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/ite-it6505.c
> > b/drivers/gpu/drm/bridge/ite-it6505.c
> > index 3f68c82888c2..4f01fadaec0f 100644
> > --- a/drivers/gpu/drm/bridge/ite-it6505.c
> > +++ b/drivers/gpu/drm/bridge/ite-it6505.c
> > @@ -2580,7 +2580,8 @@ static int it6505_poweron(struct it6505 *it6505)
> > usleep_range(1000, 2000);
> > err = regulator_enable(pdata->ovdd);
> > if (err) {
> > - regulator_disable(pdata->pwr18);
> > + if (pdata->pwr18)
> > + regulator_disable(pdata->pwr18);
>
> Wait... I wat too quick to R-B it. The driver uses devm_regulator_get(),
> which always returns non-NULL result. So all `if (pdata->pwr18)` and
> `if (pdata->ovdd)` checks in the driver are useless. Could you please
> send a patch, removing them?
>
Sure. Will do.
regards,
dan carpenter
[PATCH 0/2] Add Samsung AMS639RQ08 panel support
This series adds Samsung AMS639RQ08 panel support used in: - Xiaomi Mi 9 Lite / CC9 (sdm710-xiaomi-pyxis) - Xiaomi Mi 9T / Redmi K20 (sm7150-xiaomi-davinci) - Xiaomi Mi 9T Pro / Redmi K20 Pro (sm8150-xiaomi-raphael) Was tested on sm7150-xiaomi-davinci and sm8150-xiaomi-raphael. Based on my analysis of the downstream DTS, this driver should be fully compatible with the sdm710-xiaomi-pyxis (unfortunately not tested) without requiring any modifications. To: Neil Armstrong To: Jessica Zhang To: Sam Ravnborg To: David Airlie To: Daniel Vetter To: Maarten Lankhorst To: Maxime Ripard To: Thomas Zimmermann To: Rob Herring To: Krzysztof Kozlowski To: Conor Dooley Cc: dri-devel@lists.freedesktop.org Cc: devicet...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: Jens Reidel Cc: Degdag Mohamed Signed-off-by: Danila Tikhonov Danila Tikhonov (2): dt-bindings: display: panel: Add Samsung AMS639RQ08 drm/panel: Add Samsung AMS639RQ08 panel driver .../display/panel/samsung,ams639rq08.yaml | 80 drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-samsung-ams639rq08.c | 362 ++ 4 files changed, 452 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,ams639rq08.yaml create mode 100644 drivers/gpu/drm/panel/panel-samsung-ams639rq08.c -- 2.45.2
Re: [PATCH] drm/bridge: it6505: Fix potential NULL dereference
On Sat, Jun 08, 2024 at 05:21:08PM +0300, Dan Carpenter wrote:
> Smatch complains correctly that the NULL checking isn't consistent:
>
> drivers/gpu/drm/bridge/ite-it6505.c:2583 it6505_poweron()
> error: we previously assumed 'pdata->pwr18' could be null
> (see line 2569)
>
> Add a NULL check to prevent a NULL dereference on the error path.
>
> Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
> Signed-off-by: Dan Carpenter
> ---
> drivers/gpu/drm/bridge/ite-it6505.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/ite-it6505.c
> b/drivers/gpu/drm/bridge/ite-it6505.c
> index 3f68c82888c2..4f01fadaec0f 100644
> --- a/drivers/gpu/drm/bridge/ite-it6505.c
> +++ b/drivers/gpu/drm/bridge/ite-it6505.c
> @@ -2580,7 +2580,8 @@ static int it6505_poweron(struct it6505 *it6505)
> usleep_range(1000, 2000);
> err = regulator_enable(pdata->ovdd);
> if (err) {
> - regulator_disable(pdata->pwr18);
> + if (pdata->pwr18)
> + regulator_disable(pdata->pwr18);
Wait... I wat too quick to R-B it. The driver uses devm_regulator_get(),
which always returns non-NULL result. So all `if (pdata->pwr18)` and
`if (pdata->ovdd)` checks in the driver are useless. Could you please
send a patch, removing them?
> return err;
> }
> }
> --
> 2.43.0
>
--
With best wishes
Dmitry
Re: [PATCH] drm/bridge: add missing MODULE_DESCRIPTION() macros
Hi Jeff,
Thank you for the patch.
On Sun, Jun 09, 2024 at 10:06:17AM -0700, Jeff Johnson wrote:
> make allmodconfig && make W=1 C=1 reports:
> WARNING: modpost: missing MODULE_DESCRIPTION() in
> drivers/gpu/drm/bridge/lontium-lt9611.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in
> drivers/gpu/drm/bridge/lontium-lt9611uxc.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in
> drivers/gpu/drm/bridge/sil-sii8620.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in
> drivers/gpu/drm/bridge/sii9234.o
>
> Add the missing invocations of the MODULE_DESCRIPTION() macro.
>
> Signed-off-by: Jeff Johnson
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/lontium-lt9611.c| 1 +
> drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 1 +
> drivers/gpu/drm/bridge/sii9234.c | 1 +
> drivers/gpu/drm/bridge/sil-sii8620.c | 1 +
> 4 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
> b/drivers/gpu/drm/bridge/lontium-lt9611.c
> index b99fe87ec738..73983f9b50cb 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt9611.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
> @@ -1195,4 +1195,5 @@ static struct i2c_driver lt9611_driver = {
> };
> module_i2c_driver(lt9611_driver);
>
> +MODULE_DESCRIPTION("Lontium LT9611 DSI/HDMI bridge driver");
> MODULE_LICENSE("GPL v2");
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> index ab702471f3ab..724a08f526db 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> @@ -1021,6 +1021,7 @@ static struct i2c_driver lt9611uxc_driver = {
> module_i2c_driver(lt9611uxc_driver);
>
> MODULE_AUTHOR("Dmitry Baryshkov ");
> +MODULE_DESCRIPTION("Lontium LT9611UXC DSI/HDMI bridge driver");
> MODULE_LICENSE("GPL v2");
>
> MODULE_FIRMWARE(FW_FILE);
> diff --git a/drivers/gpu/drm/bridge/sii9234.c
> b/drivers/gpu/drm/bridge/sii9234.c
> index d8373d918324..0c74cdc07032 100644
> --- a/drivers/gpu/drm/bridge/sii9234.c
> +++ b/drivers/gpu/drm/bridge/sii9234.c
> @@ -961,4 +961,5 @@ static struct i2c_driver sii9234_driver = {
> };
>
> module_i2c_driver(sii9234_driver);
> +MODULE_DESCRIPTION("Silicon Image SII9234 HDMI/MHL bridge driver");
> MODULE_LICENSE("GPL");
> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
> b/drivers/gpu/drm/bridge/sil-sii8620.c
> index 599164e3877d..6bb755e9f0a5 100644
> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> @@ -2384,4 +2384,5 @@ static struct i2c_driver sii8620_driver = {
> };
>
> module_i2c_driver(sii8620_driver);
> +MODULE_DESCRIPTION("Silicon Image SiI8620 HDMI/MHL bridge driver");
> MODULE_LICENSE("GPL v2");
>
> ---
> base-commit: 19ca0d8a433ff37018f9429f7e7739e9f3d3d2b4
> change-id: 20240609-md-drivers-gpu-drm-bridge-6ab32656df86
>
--
Regards,
Laurent Pinchart
Re: [PATCH] drm/bridge: it6505: Fix potential NULL dereference
On Sat, Jun 08, 2024 at 05:21:08PM +0300, Dan Carpenter wrote:
> Smatch complains correctly that the NULL checking isn't consistent:
>
> drivers/gpu/drm/bridge/ite-it6505.c:2583 it6505_poweron()
> error: we previously assumed 'pdata->pwr18' could be null
> (see line 2569)
>
> Add a NULL check to prevent a NULL dereference on the error path.
>
> Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
> Signed-off-by: Dan Carpenter
> ---
> drivers/gpu/drm/bridge/ite-it6505.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
[PATCH] drm: add missing MODULE_DESCRIPTION() macros
On x86, make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/gud/gud.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/drm_panel_orientation_quirks.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/drm_mipi_dbi.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/i915/kvmgt.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/udl/udl.o
Add the missing invocation of the MODULE_DESCRIPTION() macro to all
files which have a MODULE_LICENSE().
For consistency this includes drivers/gpu/drm/drm_simple_kms_helper.c
since it contains a MODULE_LICENSE() even though it isn't built as a
separate module -- it is always built as part of drm_kms_helper and
drm_kms_helper_common.c already provides a MODULE_DESCRIPTION for that
module.
Signed-off-by: Jeff Johnson
---
This is the last in a set of patches to drivers/gpu/drm. The
preceeding patches cleaned up subdirectiries that had more than one
issue. This patch cleans up the stragglers. Let me know if any of
these modifications need to segregated into separate patches.
---
drivers/gpu/drm/drm_mipi_dbi.c | 1 +
drivers/gpu/drm/drm_panel_orientation_quirks.c | 1 +
drivers/gpu/drm/drm_simple_kms_helper.c| 1 +
drivers/gpu/drm/gud/gud_drv.c | 1 +
drivers/gpu/drm/i915/gvt/kvmgt.c | 1 +
drivers/gpu/drm/udl/udl_drv.c | 1 +
6 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index daac649aabdb..ee6fa8185b13 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -1475,4 +1475,5 @@ EXPORT_SYMBOL(mipi_dbi_debugfs_init);
#endif
+MODULE_DESCRIPTION("MIPI Display Bus Interface (DBI) LCD controller support");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index aa93129c3397..ca5aebc0 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -501,4 +501,5 @@ EXPORT_SYMBOL(drm_get_panel_orientation_quirk);
#endif
+MODULE_DESCRIPTION("Quirks for non-normal panel orientation");
MODULE_LICENSE("Dual MIT/GPL");
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 270523ae36d4..250819fbc5ce 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -453,4 +453,5 @@ int drm_simple_display_pipe_init(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_simple_display_pipe_init);
+MODULE_DESCRIPTION("Helpers for drivers for simple display hardware");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c
index 9d7bf8ee45f1..db2b7d2e246f 100644
--- a/drivers/gpu/drm/gud/gud_drv.c
+++ b/drivers/gpu/drm/gud/gud_drv.c
@@ -678,4 +678,5 @@ static struct usb_driver gud_usb_driver = {
module_usb_driver(gud_usb_driver);
MODULE_AUTHOR("Noralf Trønnes");
+MODULE_DESCRIPTION("GUD USB Display driver");
MODULE_LICENSE("Dual MIT/GPL");
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 4f74d867fe1a..38830818c120 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1985,5 +1985,6 @@ static void __exit kvmgt_exit(void)
module_init(kvmgt_init);
module_exit(kvmgt_exit);
+MODULE_DESCRIPTION("Intel mediated pass-through framework for KVM");
MODULE_LICENSE("GPL and additional rights");
MODULE_AUTHOR("Intel Corporation");
diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index 1506094a8009..de78a9b0eed7 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -160,4 +160,5 @@ static struct usb_driver udl_driver = {
.id_table = id_table,
};
module_usb_driver(udl_driver);
+MODULE_DESCRIPTION("KMS driver for the USB displaylink video adapters");
MODULE_LICENSE("GPL");
---
base-commit: 19ca0d8a433ff37018f9429f7e7739e9f3d3d2b4
change-id: 20240609-md-drivers-gpu-drm-0d9933ac8281
Re: [PATCH V2] drm/bridge: adv7511: Fix Intermittent EDID failures
On Sat, Jun 1, 2024 at 8:25 AM Adam Ford wrote:
>
> In the process of adding support for shared IRQ pins, a scenario
> was accidentally created where adv7511_irq_process returned
> prematurely causing the EDID to fail randomly.
>
> Since the interrupt handler is broken up into two main helper functions,
> update both of them to treat the helper functions as IRQ handlers. These
> IRQ routines process their respective tasks as before, but if they
> determine that actual work was done, mark the respective IRQ status
> accordingly, and delay the check until everything has been processed.
>
> This should guarantee the helper functions don't return prematurely
> while still returning proper values of either IRQ_HANDLED or IRQ_NONE.
>
> Reported-by: Liu Ying
> Fixes: f3d9683346d6 ("drm/bridge: adv7511: Allow IRQ to share GPIO pins")
> Signed-off-by: Adam Ford
> Tested-by: Liu Ying # i.MX8MP EVK ADV7535 EDID retrieval
> w/o IRQ
Gentile nudge on this. It would be nice to get this fix applied since
it caused a regression.
adam
> ---
> V2: Fix uninitialized cec_status
> Cut back a little on error handling to return either IRQ_NONE or
> IRQ_HANDLED.
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> index ea271f62b214..ec0b7f3d889c 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -401,7 +401,7 @@ struct adv7511 {
>
> #ifdef CONFIG_DRM_I2C_ADV7511_CEC
> int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511);
> -void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
> +int adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
> #else
> static inline int adv7511_cec_init(struct device *dev, struct adv7511
> *adv7511)
> {
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> index 44451a9658a3..651fb1dde780 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> @@ -119,7 +119,7 @@ static void adv7511_cec_rx(struct adv7511 *adv7511, int
> rx_buf)
> cec_received_msg(adv7511->cec_adap, &msg);
> }
>
> -void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1)
> +int adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1)
> {
> unsigned int offset = adv7511->info->reg_cec_offset;
> const u32 irq_tx_mask = ADV7511_INT1_CEC_TX_READY |
> @@ -130,17 +130,21 @@ void adv7511_cec_irq_process(struct adv7511 *adv7511,
> unsigned int irq1)
> ADV7511_INT1_CEC_RX_READY3;
> unsigned int rx_status;
> int rx_order[3] = { -1, -1, -1 };
> - int i;
> + int i, ret = 0;
> + int irq_status = IRQ_NONE;
>
> - if (irq1 & irq_tx_mask)
> + if (irq1 & irq_tx_mask) {
> adv_cec_tx_raw_status(adv7511, irq1);
> + irq_status = IRQ_HANDLED;
> + }
>
> if (!(irq1 & irq_rx_mask))
> - return;
> + return irq_status;
>
> - if (regmap_read(adv7511->regmap_cec,
> - ADV7511_REG_CEC_RX_STATUS + offset, &rx_status))
> - return;
> + ret = regmap_read(adv7511->regmap_cec,
> + ADV7511_REG_CEC_RX_STATUS + offset, &rx_status);
> + if (ret < 0)
> + return irq_status;
>
> /*
> * ADV7511_REG_CEC_RX_STATUS[5:0] contains the reception order of RX
> @@ -172,6 +176,8 @@ void adv7511_cec_irq_process(struct adv7511 *adv7511,
> unsigned int irq1)
>
> adv7511_cec_rx(adv7511, rx_buf);
> }
> +
> + return IRQ_HANDLED;
> }
>
> static int adv7511_cec_adap_enable(struct cec_adapter *adap, bool enable)
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index 66ccb61e2a66..c8d2c4a157b2 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -469,6 +469,8 @@ static int adv7511_irq_process(struct adv7511 *adv7511,
> bool process_hpd)
> {
> unsigned int irq0, irq1;
> int ret;
> + int cec_status = IRQ_NONE;
> + int irq_status = IRQ_NONE;
>
> ret = regmap_read(adv7511->regmap, ADV7511_REG_INT(0), &irq0);
> if (ret < 0)
> @@ -478,29 +480,31 @@ static int adv7511_irq_process(struct adv7511 *adv7511,
> bool process_hpd)
> if (ret < 0)
> return ret;
>
> - /* If there is no IRQ to handle, exit indicating no IRQ data */
> - if (!(irq0 & (ADV7511_INT0_HPD | ADV7511_INT0_EDID_READY)) &&
> - !(irq1 & ADV7511_INT1_DDC_ERROR))
> - return -ENODATA;
> -
> regmap_write(adv7511->regmap, ADV7511_REG_INT(0), irq0);
> regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1);
>
> - if (process_hpd && irq0 & ADV7511_INT0_HPD && adv751
[PATCH] drm/tiny: add missing MODULE_DESCRIPTION() macros
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tiny/bochs.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tiny/cirrus.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/tiny/gm12u320.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Signed-off-by: Jeff Johnson
---
drivers/gpu/drm/tiny/bochs.c| 1 +
drivers/gpu/drm/tiny/cirrus.c | 1 +
drivers/gpu/drm/tiny/gm12u320.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c
index c23c9f0cf49c..d15f4d3baeab 100644
--- a/drivers/gpu/drm/tiny/bochs.c
+++ b/drivers/gpu/drm/tiny/bochs.c
@@ -736,4 +736,5 @@ drm_module_pci_driver_if_modeset(bochs_pci_driver,
bochs_modeset);
MODULE_DEVICE_TABLE(pci, bochs_pci_tbl);
MODULE_AUTHOR("Gerd Hoffmann ");
+MODULE_DESCRIPTION("DRM Support for bochs dispi vga interface (qemu stdvga)");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
index 4e3a152f897a..89484f7084bd 100644
--- a/drivers/gpu/drm/tiny/cirrus.c
+++ b/drivers/gpu/drm/tiny/cirrus.c
@@ -760,4 +760,5 @@ static struct pci_driver cirrus_pci_driver = {
drm_module_pci_driver(cirrus_pci_driver)
MODULE_DEVICE_TABLE(pci, pciidlist);
+MODULE_DESCRIPTION("Cirrus driver for QEMU emulated device");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c
index 0187539ff5ea..07c6640022c2 100644
--- a/drivers/gpu/drm/tiny/gm12u320.c
+++ b/drivers/gpu/drm/tiny/gm12u320.c
@@ -755,4 +755,5 @@ static struct usb_driver gm12u320_usb_driver = {
module_usb_driver(gm12u320_usb_driver);
MODULE_AUTHOR("Hans de Goede ");
+MODULE_DESCRIPTION("GM12U320 driver for USB projectors");
MODULE_LICENSE("GPL");
---
base-commit: 19ca0d8a433ff37018f9429f7e7739e9f3d3d2b4
change-id: 20240609-md-drivers-gpu-drm-tiny-a3370189f560
[PATCH] drm/bridge: add missing MODULE_DESCRIPTION() macros
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/bridge/lontium-lt9611.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/bridge/lontium-lt9611uxc.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/bridge/sil-sii8620.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/bridge/sii9234.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Signed-off-by: Jeff Johnson
---
drivers/gpu/drm/bridge/lontium-lt9611.c| 1 +
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 1 +
drivers/gpu/drm/bridge/sii9234.c | 1 +
drivers/gpu/drm/bridge/sil-sii8620.c | 1 +
4 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index b99fe87ec738..73983f9b50cb 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -1195,4 +1195,5 @@ static struct i2c_driver lt9611_driver = {
};
module_i2c_driver(lt9611_driver);
+MODULE_DESCRIPTION("Lontium LT9611 DSI/HDMI bridge driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index ab702471f3ab..724a08f526db 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -1021,6 +1021,7 @@ static struct i2c_driver lt9611uxc_driver = {
module_i2c_driver(lt9611uxc_driver);
MODULE_AUTHOR("Dmitry Baryshkov ");
+MODULE_DESCRIPTION("Lontium LT9611UXC DSI/HDMI bridge driver");
MODULE_LICENSE("GPL v2");
MODULE_FIRMWARE(FW_FILE);
diff --git a/drivers/gpu/drm/bridge/sii9234.c b/drivers/gpu/drm/bridge/sii9234.c
index d8373d918324..0c74cdc07032 100644
--- a/drivers/gpu/drm/bridge/sii9234.c
+++ b/drivers/gpu/drm/bridge/sii9234.c
@@ -961,4 +961,5 @@ static struct i2c_driver sii9234_driver = {
};
module_i2c_driver(sii9234_driver);
+MODULE_DESCRIPTION("Silicon Image SII9234 HDMI/MHL bridge driver");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 599164e3877d..6bb755e9f0a5 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -2384,4 +2384,5 @@ static struct i2c_driver sii8620_driver = {
};
module_i2c_driver(sii8620_driver);
+MODULE_DESCRIPTION("Silicon Image SiI8620 HDMI/MHL bridge driver");
MODULE_LICENSE("GPL v2");
---
base-commit: 19ca0d8a433ff37018f9429f7e7739e9f3d3d2b4
change-id: 20240609-md-drivers-gpu-drm-bridge-6ab32656df86
[PATCH] drm/panel: add missing MODULE_DESCRIPTION() macros
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/panel/panel-abt-y030xx067a.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/panel/panel-auo-a030jtn01.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/panel/panel-innolux-ej030na.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/panel/panel-newvision-nv3052c.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/panel/panel-novatek-nt39016.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/panel/panel-orisetech-ota5601a.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Signed-off-by: Jeff Johnson
---
drivers/gpu/drm/panel/panel-abt-y030xx067a.c | 1 +
drivers/gpu/drm/panel/panel-auo-a030jtn01.c | 1 +
drivers/gpu/drm/panel/panel-innolux-ej030na.c| 1 +
drivers/gpu/drm/panel/panel-newvision-nv3052c.c | 1 +
drivers/gpu/drm/panel/panel-novatek-nt39016.c| 1 +
drivers/gpu/drm/panel/panel-orisetech-ota5601a.c | 1 +
6 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
b/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
index 662c7bcbe6e5..4692c36fe217 100644
--- a/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
+++ b/drivers/gpu/drm/panel/panel-abt-y030xx067a.c
@@ -381,4 +381,5 @@ module_spi_driver(y030xx067a_driver);
MODULE_AUTHOR("Paul Cercueil ");
MODULE_AUTHOR("Christophe Branchereau ");
+MODULE_DESCRIPTION("Asia Better Technology Ltd. Y030XX067A IPS LCD panel
driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/panel/panel-auo-a030jtn01.c
b/drivers/gpu/drm/panel/panel-auo-a030jtn01.c
index 6c86ebf2cad7..77604d6a4e72 100644
--- a/drivers/gpu/drm/panel/panel-auo-a030jtn01.c
+++ b/drivers/gpu/drm/panel/panel-auo-a030jtn01.c
@@ -305,4 +305,5 @@ module_spi_driver(a030jtn01_driver);
MODULE_AUTHOR("Paul Cercueil ");
MODULE_AUTHOR("Christophe Branchereau ");
+MODULE_DESCRIPTION("AU Optronics A030JTN01.0 TFT LCD panel driver");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/panel/panel-innolux-ej030na.c
b/drivers/gpu/drm/panel/panel-innolux-ej030na.c
index 8fdbda59be48..f85b7a4cbb42 100644
--- a/drivers/gpu/drm/panel/panel-innolux-ej030na.c
+++ b/drivers/gpu/drm/panel/panel-innolux-ej030na.c
@@ -306,4 +306,5 @@ module_spi_driver(ej030na_driver);
MODULE_AUTHOR("Paul Cercueil ");
MODULE_AUTHOR("Christophe Branchereau ");
+MODULE_DESCRIPTION("Innolux/Chimei EJ030NA TFT LCD panel driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
index 1aab0c9ae52f..b8f7c673ab50 100644
--- a/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
@@ -719,4 +719,5 @@ module_spi_driver(nv3052c_driver);
MODULE_AUTHOR("Paul Cercueil ");
MODULE_AUTHOR("Christophe Branchereau ");
+MODULE_DESCRIPTION("NewVision NV3052C IPS LCD panel driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt39016.c
b/drivers/gpu/drm/panel/panel-novatek-nt39016.c
index 059260262b5a..9fa7654e2b67 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt39016.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt39016.c
@@ -356,4 +356,5 @@ module_spi_driver(nt39016_driver);
MODULE_AUTHOR("Maarten ter Huurne ");
MODULE_AUTHOR("Paul Cercueil ");
+MODULE_DESCRIPTION("Novatek NT39016 TFT LCD panel driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/panel/panel-orisetech-ota5601a.c
b/drivers/gpu/drm/panel/panel-orisetech-ota5601a.c
index c415dacf1816..fc87f61d4400 100644
--- a/drivers/gpu/drm/panel/panel-orisetech-ota5601a.c
+++ b/drivers/gpu/drm/panel/panel-orisetech-ota5601a.c
@@ -360,4 +360,5 @@ static struct spi_driver ota5601a_driver = {
module_spi_driver(ota5601a_driver);
MODULE_AUTHOR("Christophe Branchereau ");
+MODULE_DESCRIPTION("Orisetech OTA5601A TFT LCD panel driver");
MODULE_LICENSE("GPL");
---
base-commit: 19ca0d8a433ff37018f9429f7e7739e9f3d3d2b4
change-id: 20240609-md-drivers-gpu-drm-panel-6580abcf3d7e
[PATCH] drm/ttm/tests: add missing MODULE_DESCRIPTION() macros
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/ttm/tests/ttm_device_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/ttm/tests/ttm_pool_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/ttm/tests/ttm_resource_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/ttm/tests/ttm_tt_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/ttm/tests/ttm_bo_test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Signed-off-by: Jeff Johnson
---
drivers/gpu/drm/ttm/tests/ttm_bo_test.c | 1 +
drivers/gpu/drm/ttm/tests/ttm_device_test.c | 1 +
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 1 +
drivers/gpu/drm/ttm/tests/ttm_pool_test.c | 1 +
drivers/gpu/drm/ttm/tests/ttm_resource_test.c | 1 +
drivers/gpu/drm/ttm/tests/ttm_tt_test.c | 1 +
6 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
b/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
index 1f8a4f8adc92..c18547c65985 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
@@ -619,4 +619,5 @@ static struct kunit_suite ttm_bo_test_suite = {
kunit_test_suites(&ttm_bo_test_suite);
+MODULE_DESCRIPTION("KUnit tests for ttm_bo APIs");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/ttm/tests/ttm_device_test.c
b/drivers/gpu/drm/ttm/tests/ttm_device_test.c
index 19eaff22e6ae..5bdfa4f88438 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_device_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_device_test.c
@@ -209,4 +209,5 @@ static struct kunit_suite ttm_device_test_suite = {
kunit_test_suites(&ttm_device_test_suite);
+MODULE_DESCRIPTION("KUnit tests for ttm_device APIs");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
index 7b7c1fa805fc..d9d29b34b23b 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
@@ -156,4 +156,5 @@ void ttm_test_devices_fini(struct kunit *test)
}
EXPORT_SYMBOL_GPL(ttm_test_devices_fini);
+MODULE_DESCRIPTION("TTM KUnit test helper functions");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
b/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
index 0a3fede84da9..2d1928b615a0 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
@@ -433,4 +433,5 @@ static struct kunit_suite ttm_pool_test_suite = {
kunit_test_suites(&ttm_pool_test_suite);
+MODULE_DESCRIPTION("KUnit tests for ttm_pool APIs");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
b/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
index 029e1f094bb0..ade487fea179 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
@@ -332,4 +332,5 @@ static struct kunit_suite ttm_resource_test_suite = {
kunit_test_suites(&ttm_resource_test_suite);
+MODULE_DESCRIPTION("KUnit tests for ttm_resource and ttm_sys_man APIs");
MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
b/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
index fd4502c18de6..d78e1e9896d8 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
@@ -292,4 +292,5 @@ static struct kunit_suite ttm_tt_test_suite = {
kunit_test_suites(&ttm_tt_test_suite);
+MODULE_DESCRIPTION("KUnit tests for ttm_tt APIs");
MODULE_LICENSE("GPL");
---
base-commit: 19ca0d8a433ff37018f9429f7e7739e9f3d3d2b4
change-id: 20240609-md-drivers-gpu-drm-ttm-tests-f7b63f46eb3c
[drm-misc:topic/rust-drm 11/20] error: expected one of `:`, `@`, or `|`, found `paddr`
tree: git://anongit.freedesktop.org/drm/drm-misc topic/rust-drm
head: 508348922df19178b613531fb6cc7beb624642ae
commit: e98a3de09cfc9fae923c259a48e3622cc2a6bb2e [11/20] rust: add devres
abstraction
config: riscv-randconfig-r121-20240609
(https://download.01.org/0day-ci/archive/20240610/202406100042.hx2ljmfc-...@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project
d7d2d4f53fc79b4b58e8d8d08151b577c3699d4a)
reproduce:
(https://download.01.org/0day-ci/archive/20240610/202406100042.hx2ljmfc-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202406100042.hx2ljmfc-...@intel.com/
All errors (new ones prefixed by >>):
>> error: expected one of `:`, `@`, or `|`, found `paddr`
--> rust/doctests_kernel_generated.rs:793:18
|
793 | fn new(usize paddr, usize len) -> Result{
|--^
|| |
|| expected one of `:`, `@`, or `|`
|help: declare the type after the parameter binding:
`: `
--
>> error: expected one of `:`, `@`, or `|`, found `len`
--> rust/doctests_kernel_generated.rs:793:31
|
793 | fn new(usize paddr, usize len) -> Result{
| --^^^
| | |
| | expected one of `:`, `@`, or `|`
| help: declare the type after the parameter
binding: `: `
--
>> error[E0412]: cannot find type `IoMem` in this scope
--> rust/doctests_kernel_generated.rs:790:16
|
790 | struct IoRemap(IoMem);
|^ not found in this scope
--
>> error[E0405]: cannot find trait `Deref` in this scope
--> rust/doctests_kernel_generated.rs:808:6
|
808 | impl Deref for IoRemap {
| ^ not found in this scope
|
help: consider importing this trait
|
3 + use core::ops::Deref;
|
--
>> error[E0412]: cannot find type `IoMem` in this scope
--> rust/doctests_kernel_generated.rs:809:18
|
809 |type Target = IoMem;
| ^ not found in this scope
--
>> error[E0425]: cannot find value `dev` in this scope
--> rust/doctests_kernel_generated.rs:816:26
|
816 | let devres = Devres::new(dev, IoRemap::new(0xBAAD, 0x4)?,
GFP_KERNEL)?;
| ^^^ not found in this scope
--
>> error[E0433]: failed to resolve: use of undeclared type `IoMem`
--> rust/doctests_kernel_generated.rs:796:21
|
796 | let iomem = IoMem::new(addr, len)?;
| ^ use of undeclared type `IoMem`
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [RFC PATCH 3/8] rust: drm: Add Device and Driver abstractions
Hi Lina, Welcome back! On Sun, Jun 09, 2024 at 02:15:57PM +0900, Asahi Lina wrote: > > > On 5/22/24 6:23 AM, Rob Herring wrote: > > On Mon, May 20, 2024 at 07:20:50PM +0200, Danilo Krummrich wrote: > >> From: Asahi Lina > > This is missing an entry for DRIVER_GEM_GPUVA. And some others perhaps. > > I suppose some are legacy which won't be needed any time soon if ever. > > Not sure if you intend for this to be complete, or you are just adding > > what you are using? Only FEAT_GEM is used by nova ATM. > > > > This was developed before DRIVER_GEM_GPUVA existed ^^ > > I have this in my branch since I'm using the GPUVA manager now. Danilo, > what tree are you using for this submission? It would be good to > coordinate this and try to keep the WIP branches from diverging too much... Trying to prevent things from diverging was one of my main objectives when I started those efforts a couple of month ago (I also sent you a mail for that purpose back then). I am maintaining a couple of branches: In the RfL repository [1]: - staging/rust-device [2] (Device / driver, devres infrastructure) - staging/dev [3] (common branch containing all the Rust infrastructure I'm currently upstreaming, including PCI and firmware abstractions) In the drm-misc repository [4]: - topic/rust-drm [5] (all the DRM abstractions) In the Nova repository [6] - nova-next [7] (the Nova stub driver making use of everything) I regularly rebase those branches and keep them up to date with improvements and feedback from the mailing list. The device / driver and PCI abstractions are getting most of my attention currently, but there are some recent changes (besides some minor ones) on the DRM abstractions I plan to send in a v2 as well: - static const allocation of driver and fops structures - rework of the `Registration` type to use `Devres` and combine the new() and register() methods to register in new() already There is also some more information regarding those branches in the cover letters of the series and the links included there. [1] https://github.com/Rust-for-Linux/linux [2] https://github.com/Rust-for-Linux/linux/tree/staging/rust-device [3] https://github.com/Rust-for-Linux/linux/tree/staging/dev [4] https://gitlab.freedesktop.org/drm/misc/kernel [5] https://gitlab.freedesktop.org/drm/misc/kernel/-/tree/topic/rust-drm [6] https://gitlab.freedesktop.org/drm/nova [7] https://gitlab.freedesktop.org/drm/nova/-/tree/nova-next > > That said, I don't think there's reason to support all features unless > we expect new drivers to actually use them. The goal of the abstractions > is to serve the drivers that will use them, and to evolve together with > them and any newer drivers, not to attempt to be feature-complete from > the get go (it's very difficult to evaluate an abstraction if it has no > users!). In general my approach when writing them was to abstract what I > need and add "obvious" extra trivial features that didn't require much > thought even if I wasn't using them, but otherwise not attempt to > comprehensively cover everything. Fully agree, I think the point here only was whether we want to list all the feature flags in the abstraction already. Which I think is something we can do. However, I'm also find with only listing the ones we actually use and keep adding further ones subsequently. It just shouldn't be random. - Danilo > > ~~ Lina >
Re: [PATCH v8 4/4] ARM: configs: at91: Enable LVDS serializer support
On 21.04.2024 04:10, Dharma Balasubiramani wrote: > Enable LVDS serializer support for display pipeline. > > Signed-off-by: Dharma Balasubiramani > Acked-by: Hari Prasath Gujulan Elango > Acked-by: Nicolas Ferre Applied to at91-defconfig, thanks!
Re: [PATCH v10 0/6] iio: new DMABUF based API v10
On Wed, 5 Jun 2024 13:08:39 +0200 Paul Cercueil wrote: > Hi Jonathan, > > Here is a revised (and hopefully final?) version of my DMABUF patchset. Fingers crossed it's just docs changes for v11. So on to the details of how to merge this... For the DMAEngine maintainers: Given IIO changes dominate this series it makes sense for me to pick it up through IIO. Do you want an immutable branch with the first patch on it, or is this unlikely to cause merge conflicts with any other ongoing work in dmabuffer land? I'm fine either way and if I don't hear back on this will do an immutable branch and announce it when I apply v11 (I hope!) Jonathan > > This v10 removes the extra "flags" parameter of > dmaengine_prep_peripheral_dma_vec(), and adds kernel doc to the function > as Vinod requested. > > As Nuno upstreamed support for output buffers, I (slightly) modified > patch 5/6 and now output buffers are supported with the DMABUF API. > All I did was remove a "fail if output" check really. > > This was based on next-20240605. > > Changelog: > - [1/6]: > - Add kernel doc to dmaengine_prep_peripheral_dma_vec() > - Remove extra flags parameter > - [2/6]: > - Use the new function prototype (without the extra prep_flags). > - [5/6]: > - Remove extra flags parameter to dmaengine_prep_peripheral_dma_vec() > - Add support for TX transfers > > Cheers, > -Paul > > Paul Cercueil (6): > dmaengine: Add API function dmaengine_prep_peripheral_dma_vec() > dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec > iio: core: Add new DMABUF interface infrastructure > iio: buffer-dma: Enable support for DMABUFs > iio: buffer-dmaengine: Support new DMABUF based userspace API > Documentation: iio: Document high-speed DMABUF based API > > Documentation/iio/iio_dmabuf_api.rst | 54 ++ > Documentation/iio/index.rst | 1 + > drivers/dma/dma-axi-dmac.c| 40 ++ > drivers/iio/Kconfig | 1 + > drivers/iio/buffer/industrialio-buffer-dma.c | 180 ++- > .../buffer/industrialio-buffer-dmaengine.c| 62 ++- > drivers/iio/industrialio-buffer.c | 462 ++ > include/linux/dmaengine.h | 33 ++ > include/linux/iio/buffer-dma.h| 31 ++ > include/linux/iio/buffer_impl.h | 30 ++ > include/uapi/linux/iio/buffer.h | 22 + > 11 files changed, 896 insertions(+), 20 deletions(-) > create mode 100644 Documentation/iio/iio_dmabuf_api.rst >
Re: [PATCH v10 4/6] iio: buffer-dma: Enable support for DMABUFs
On Wed, 5 Jun 2024 13:08:43 +0200
Paul Cercueil wrote:
> Implement iio_dma_buffer_attach_dmabuf(), iio_dma_buffer_detach_dmabuf()
> and iio_dma_buffer_transfer_dmabuf(), which can then be used by the IIO
> DMA buffer implementations.
>
> Signed-off-by: Paul Cercueil
> Signed-off-by: Nuno Sa
>
Same thing on SoB.
Also another missing structure field related docs comment inline.
> diff --git a/include/linux/iio/buffer-dma.h b/include/linux/iio/buffer-dma.h
> index 6e27e47077d5..e54158e53fd6 100644
> --- a/include/linux/iio/buffer-dma.h
> +++ b/include/linux/iio/buffer-dma.h
> @@ -7,6 +7,7 @@
> #ifndef __INDUSTRIALIO_DMA_BUFFER_H__
> #define __INDUSTRIALIO_DMA_BUFFER_H__
>
> +#include
> #include
> #include
> #include
> @@ -16,6 +17,9 @@
> struct iio_dma_buffer_queue;
> struct iio_dma_buffer_ops;
> struct device;
> +struct dma_buf_attachment;
> +struct dma_fence;
> +struct sg_table;
>
> /**
> * enum iio_block_state - State of a struct iio_dma_buffer_block
> @@ -41,6 +45,8 @@ enum iio_block_state {
> * @queue: Parent DMA buffer queue
> * @kref: kref used to manage the lifetime of block
> * @state: Current state of the block
> + * @cyclic: True if this is a cyclic buffer
> + * @fileio: True if this buffer is used for fileio mode
kernel doc needs to be complete. So missing attach, sg_table and fence.
> */
> struct iio_dma_buffer_block {
> /* May only be accessed by the owner of the block */
> @@ -63,6 +69,14 @@ struct iio_dma_buffer_block {
>* queue->list_lock if the block is not owned by the core.
>*/
> enum iio_block_state state;
> +
> + bool cyclic;
> + bool fileio;
> +
> + struct dma_buf_attachment *attach;
> + struct sg_table *sg_table;
> +
> + struct dma_fence *fence;
> };
Re: [PATCH v10 3/6] iio: core: Add new DMABUF interface infrastructure
On Wed, 5 Jun 2024 13:08:42 +0200
Paul Cercueil wrote:
> Add the necessary infrastructure to the IIO core to support a new
> optional DMABUF based interface.
>
> With this new interface, DMABUF objects (externally created) can be
> attached to a IIO buffer, and subsequently used for data transfer.
>
> A userspace application can then use this interface to share DMABUF
> objects between several interfaces, allowing it to transfer data in a
> zero-copy fashion, for instance between IIO and the USB stack.
>
> The userspace application can also memory-map the DMABUF objects, and
> access the sample data directly. The advantage of doing this vs. the
> read() interface is that it avoids an extra copy of the data between the
> kernel and userspace. This is particularly userful for high-speed
> devices which produce several megabytes or even gigabytes of data per
> second.
>
> As part of the interface, 3 new IOCTLs have been added:
>
> IIO_BUFFER_DMABUF_ATTACH_IOCTL(int fd):
> Attach the DMABUF object identified by the given file descriptor to the
> buffer.
>
> IIO_BUFFER_DMABUF_DETACH_IOCTL(int fd):
> Detach the DMABUF object identified by the given file descriptor from
> the buffer. Note that closing the IIO buffer's file descriptor will
> automatically detach all previously attached DMABUF objects.
>
> IIO_BUFFER_DMABUF_ENQUEUE_IOCTL(struct iio_dmabuf *):
> Request a data transfer to/from the given DMABUF object. Its file
> descriptor, as well as the transfer size and flags are provided in the
> "iio_dmabuf" structure.
>
> These three IOCTLs have to be performed on the IIO buffer's file
> descriptor, obtained using the IIO_BUFFER_GET_FD_IOCTL() ioctl.
>
> Signed-off-by: Paul Cercueil
> Signed-off-by: Nuno Sa
Need a brief note on the sign off chain.
What is Nuno's role in this series as he's not sending the emails and not
marked with Co-developed-by
I gave this a much more thorough look in earlier versions than I have today but
a few really minor things inline (that I might have fixed up whilst applying)
but looks like you'll be done a v11 for Randy's docs comments anyway :(
Jonathan
> diff --git a/drivers/iio/industrialio-buffer.c
> b/drivers/iio/industrialio-buffer.c
> index 0138b21b244f..c98c8ac83785 100644
> --- a/drivers/iio/industrialio-buffer.c
> +++ b/drivers/iio/industrialio-buffer.c
> +struct iio_dmabuf_priv {
> + struct list_head entry;
> + struct kref ref;
> +
> + struct iio_buffer *buffer;
> + struct iio_dma_buffer_block *block;
> +
> + u64 context;
> + spinlock_t lock;
Given you are going to have a v11, please add a comment to this lock
to say what data it is protecting.
> +
> + struct dma_buf_attachment *attach;
> + struct sg_table *sgt;
> + enum dma_data_direction dir;
> + atomic_t seqno;
> +};
> diff --git a/include/linux/iio/buffer_impl.h b/include/linux/iio/buffer_impl.h
> index 89c3fd7c29ca..1a221c1d7736 100644
> --- a/include/linux/iio/buffer_impl.h
> +++ b/include/linux/iio/buffer_impl.h
> @@ -9,8 +9,12 @@
> #include
> #include
>
> +struct dma_buf_attachment;
> +struct dma_fence;
> struct iio_dev;
> +struct iio_dma_buffer_block;
> struct iio_buffer;
> +struct sg_table;
>
> /**
> * INDIO_BUFFER_FLAG_FIXED_WATERMARK - Watermark level of the buffer can not
> be
> @@ -39,6 +43,13 @@ struct iio_buffer;
> * device stops sampling. Calles are balanced with
> @enable.
> * @release: called when the last reference to the buffer is dropped,
> * should free all resources allocated by the buffer.
> + * @attach_dmabuf: called from userspace via ioctl to attach one external
> + * DMABUF.
> + * @detach_dmabuf: called from userspace via ioctl to detach one previously
> + * attached DMABUF.
> + * @enqueue_dmabuf: called from userspace via ioctl to queue this DMABUF
> + * object to this buffer. Requires a valid DMABUF fd, that
> + * was previouly attached to this buffer.
Missing docs for lock_queue() and unlock_queue()
Kernel-doc must be complete or bots are going to moan at us :(
> * @modes: Supported operating modes by this buffer type
> * @flags: A bitmask combination of INDIO_BUFFER_FLAG_*
> *
> @@ -68,6 +79,17 @@ struct iio_buffer_access_funcs {
>
> void (*release)(struct iio_buffer *buffer);
>
> + struct iio_dma_buffer_block * (*attach_dmabuf)(struct iio_buffer
> *buffer,
> +struct
> dma_buf_attachment *attach);
> + void (*detach_dmabuf)(struct iio_buffer *buffer,
> + struct iio_dma_buffer_block *block);
> + int (*enqueue_dmabuf)(struct iio_buffer *buffer,
> + struct iio_dma_buffer_block *block,
> + struct dma_fence *fence, struct sg_table *sgt,
> + size_t size, bool cyclic);
> +
