Re: [PATCH v7 0/6] iio: new DMABUF based API
On Sun, 2024-03-03 at 17:42 +, Jonathan Cameron wrote: > On Fri, 23 Feb 2024 13:13:58 +0100 > Nuno Sa wrote: > > > Hi Jonathan, likely you're wondering why I'm sending v7. Well, to be > > honest, we're hoping to get this merged this for the 6.9 merge window. > > Main reason is because the USB part is already in (so it would be nice > > to get the whole thing in). Moreover, the changes asked in v6 were simple > > (even though I'm not quite sure in one of them) and Paul has no access to > > it's laptop so he can't send v7 himself. So he kind of said/asked for me to > > do it. > > So, we are cutting this very fine. If Linus hints strongly at an rc8 maybe we > can sneak this in. However, I need an Ack from Vinod for the dma engine > changes first. > > Also I'd love a final 'looks ok' comment from DMABUF folk (Ack even better!) > > Seems that the other side got resolved in the USB gadget, but last we heard > form > Daniel and Christian looks to have been back on v5. I'd like them to confirm > they are fine with the changes made as a result. > I can ask Christian or Daniel for some acks but my feeling (I still need, at some point, to get really familiar with all of this) is that this should be pretty similar to the USB series (from a DMABUF point of view) as they are both importers. > I've been happy with the IIO parts for a few versions now but my ability to > review > the DMABUF and DMA engine bits is limited. > > A realistic path to get this in is rc8 is happening, is all Acks in place by > Wednesday, > I get apply it and hits Linux-next Thursday, Pull request to Greg on Saturday > and Greg > is feeling particularly generous to take one on the day he normally closes his > trees. > Well, it looks like we still have a shot. I'll try to see if Vinod is fine with the DMAENGINE stuff. - Nuno Sá
Re: [PATCH v2] dt-bindings: display: atmel,lcdc: convert to dtschema
On 04/03/2024 06:36, Dharma Balasubiramani wrote: > Convert the atmel,lcdc bindings to DT schema. > Changes during conversion: add missing clocks and clock-names properties. > > Signed-off-by: Dharma Balasubiramani > --- > This patch converts the existing lcdc display text binding to JSON schema. > The binding is split into two namely > lcdc.yaml > - Holds the frame buffer properties > lcdc-display.yaml > - Holds the display panel properties which is a phandle to the display > property in lcdc fb node. > > These bindings are tested against the existing at91 dts files using > dtbs_check. > --- > Changes in v2: > - Run checkpatch and remove whitespace errors. > - Add the standard interrupt flags. > - Split the binding into two, namely lcdc.yaml and lcdc-display.yaml. > - Link to v1: > https://lore.kernel.org/r/20240223-lcdc-fb-v1-1-4c64cb627...@microchip.com > --- > .../bindings/display/atmel,lcdc-display.yaml | 98 > ++ > .../devicetree/bindings/display/atmel,lcdc.txt | 87 --- > .../devicetree/bindings/display/atmel,lcdc.yaml| 70 > 3 files changed, 168 insertions(+), 87 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/atmel,lcdc-display.yaml > b/Documentation/devicetree/bindings/display/atmel,lcdc-display.yaml > new file mode 100644 > index ..ea4fd34b9e2c > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/atmel,lcdc-display.yaml > @@ -0,0 +1,98 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/atmel,lcdc-display.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Microchip's LCDC Display > + > +maintainers: > + - Nicolas Ferre > + - Dharma Balasubiramani > + > +description: > + The LCD Controller (LCDC) consists of logic for transferring LCD image data > + from an external display buffer to a TFT LCD panel. The LCDC has one > display > + input buffer per layer that fetches pixels through the single bus host > + interface and a look-up table to allow palletized display configurations. > The > + LCDC is programmable on a per layer basis, and supports different LCD > + resolutions, window sizes, image formats and pixel depths. > + > +# We need a select here since this schema is applicable only for nodes with > the > +# following properties > + > +select: > + anyOf: > +- required: [ 'atmel,dmacon' ] > +- required: [ 'atmel,lcdcon2' ] > +- required: [ 'atmel,guard-time' ] > +- required: [ bits-per-pixel ] Why quotes in other places? bits-per-pixel is generic property, so you are now selecting other bindings. Read carefully what Rob wrote. Best regards, Krzysztof
[PATCH v3 5/5] arm64: dts: allwinner: a64: Run GPU at 432 MHz
The Allwinner A64's GPU has currently three operating points. However,
the BSP runs the GPU fixed at 432 MHz. In addition, at least one of the
devices using that SoC - the pinephone - shows unstabilities (see link)
that can be circumvented by running the GPU at a fixed rate.
Therefore, remove the other two operating points from the GPU OPP table,
so that the GPU runs at a fixed rate of 432 MHz.
Link: https://gitlab.com/postmarketOS/pmaports/-/issues/805
Signed-off-by: Frank Oltmanns
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8
1 file changed, 8 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 57ac18738c99..c810380aab6d 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -107,14 +107,6 @@ de: display-engine {
gpu_opp_table: opp-table-gpu {
compatible = "operating-points-v2";
- opp-12000 {
- opp-hz = /bits/ 64 <12000>;
- };
-
- opp-31200 {
- opp-hz = /bits/ 64 <31200>;
- };
-
opp-43200 {
opp-hz = /bits/ 64 <43200>;
};
--
2.44.0
[PATCH v3 4/5] clk: sunxi-ng: a64: Add constraints on PLL-MIPI's n/m ratio and parent rate
The Allwinner A64 manual lists the following constraints for the
PLL-MIPI clock:
- M/N <= 3
- (PLL_VIDEO0)/M >= 24MHz
Use these constraints.
Reviewed-by: Jernej Skrabec
Signed-off-by: Frank Oltmanns
---
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 6a4b2b9ef30a..07796c79a23e 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -171,11 +171,13 @@ static struct ccu_nkm pll_mipi_clk = {
* user manual, and by experiments the PLL doesn't work without
* these bits toggled.
*/
- .enable = BIT(31) | BIT(23) | BIT(22),
- .lock = BIT(28),
- .n = _SUNXI_CCU_MULT(8, 4),
- .k = _SUNXI_CCU_MULT_MIN(4, 2, 2),
- .m = _SUNXI_CCU_DIV(0, 4),
+ .enable = BIT(31) | BIT(23) | BIT(22),
+ .lock = BIT(28),
+ .n = _SUNXI_CCU_MULT(8, 4),
+ .k = _SUNXI_CCU_MULT_MIN(4, 2, 2),
+ .m = _SUNXI_CCU_DIV(0, 4),
+ .max_m_n_ratio = 3,
+ .min_parent_m_ratio = 2400,
.common = {
.reg= 0x040,
.hw.init= CLK_HW_INIT("pll-mipi", "pll-video0",
--
2.44.0
[PATCH v3 3/5] clk: sunxi-ng: nkm: Support constraints on m/n ratio and parent rate
The Allwinner A64 manual lists the following constraints for the
PLL-MIPI clock:
- M/N <= 3
- (PLL_VIDEO0)/M >= 24MHz
The PLL-MIPI clock is implemented as ccu_nkm. Therefore, add support for
these constraints.
Reviewed-by: Jernej Skrabec
Signed-off-by: Frank Oltmanns
---
drivers/clk/sunxi-ng/ccu_nkm.c | 21 +
drivers/clk/sunxi-ng/ccu_nkm.h | 2 ++
2 files changed, 23 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
index 853f84398e2b..1168d894d636 100644
--- a/drivers/clk/sunxi-ng/ccu_nkm.c
+++ b/drivers/clk/sunxi-ng/ccu_nkm.c
@@ -16,6 +16,20 @@ struct _ccu_nkm {
unsigned long m, min_m, max_m;
};
+static bool ccu_nkm_is_valid_rate(struct ccu_common *common, unsigned long
parent,
+ unsigned long n, unsigned long m)
+{
+ struct ccu_nkm *nkm = container_of(common, struct ccu_nkm, common);
+
+ if (nkm->max_m_n_ratio && (m > nkm->max_m_n_ratio * n))
+ return false;
+
+ if (nkm->min_parent_m_ratio && (parent < nkm->min_parent_m_ratio * m))
+ return false;
+
+ return true;
+}
+
static unsigned long ccu_nkm_find_best_with_parent_adj(struct ccu_common
*common,
struct clk_hw *parent_hw,
unsigned long *parent,
unsigned long rate,
@@ -31,6 +45,10 @@ static unsigned long
ccu_nkm_find_best_with_parent_adj(struct ccu_common *common
unsigned long tmp_rate, tmp_parent;
tmp_parent = clk_hw_round_rate(parent_hw, rate
* _m / (_n * _k));
+
+ if (!ccu_nkm_is_valid_rate(common, tmp_parent,
_n, _m))
+ continue;
+
tmp_rate = tmp_parent * _n * _k / _m;
if (ccu_is_better_rate(common, rate, tmp_rate,
best_rate) ||
@@ -64,6 +82,9 @@ static unsigned long ccu_nkm_find_best(unsigned long parent,
unsigned long rate,
for (_k = nkm->min_k; _k <= nkm->max_k; _k++) {
for (_n = nkm->min_n; _n <= nkm->max_n; _n++) {
for (_m = nkm->min_m; _m <= nkm->max_m; _m++) {
+ if (!ccu_nkm_is_valid_rate(common, parent, _n,
_m))
+ continue;
+
unsigned long tmp_rate;
tmp_rate = parent * _n * _k / _m;
diff --git a/drivers/clk/sunxi-ng/ccu_nkm.h b/drivers/clk/sunxi-ng/ccu_nkm.h
index 6601defb3f38..c409212ee40e 100644
--- a/drivers/clk/sunxi-ng/ccu_nkm.h
+++ b/drivers/clk/sunxi-ng/ccu_nkm.h
@@ -27,6 +27,8 @@ struct ccu_nkm {
struct ccu_mux_internal mux;
unsigned intfixed_post_div;
+ unsigned long max_m_n_ratio;
+ unsigned long min_parent_m_ratio;
struct ccu_common common;
};
--
2.44.0
[PATCH v3 2/5] clk: sunxi-ng: a64: Set minimum and maximum rate for PLL-MIPI
When the Allwinner A64's TCON0 searches the ideal rate for the connected
panel, it may happen that it requests a rate from its parent PLL-MIPI
which PLL-MIPI does not support.
This happens for example on the Olimex TERES-I laptop where TCON0
requests PLL-MIPI to change to a rate of several GHz which causes the
panel to stay blank. It also happens on the pinephone where a rate of
less than 500 MHz is requested which causes instabilities on some
phones.
Set the minimum and maximum rate of Allwinner A64's PLL-MIPI according
to the Allwinner User Manual.
Fixes: ca1170b69968 ("clk: sunxi-ng: a64: force select PLL_MIPI in TCON0 mux")
Reported-by: Diego Roversi
Closes: https://groups.google.com/g/linux-sunxi/c/Rh-Uqqa66bw
Signed-off-by: Frank Oltmanns
Tested-by: Diego Roversi
Cc: sta...@vger.kernel.org
---
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 8951ffc14ff5..6a4b2b9ef30a 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -182,6 +182,8 @@ static struct ccu_nkm pll_mipi_clk = {
_nkm_ops,
CLK_SET_RATE_UNGATE |
CLK_SET_RATE_PARENT),
.features = CCU_FEATURE_CLOSEST_RATE,
+ .min_rate = 5,
+ .max_rate = 14,
},
};
--
2.44.0
[PATCH v3 1/5] clk: sunxi-ng: common: Support minimum and maximum rate
The Allwinner SoC's typically have an upper and lower limit for their
clocks' rates. Up until now, support for that has been implemented
separately for each clock type.
Implement that functionality in the sunxi-ng's common part making use of
the CCF rate liming capabilities, so that it is available for all clock
types.
Suggested-by: Maxime Ripard
Signed-off-by: Frank Oltmanns
Cc: sta...@vger.kernel.org
---
drivers/clk/sunxi-ng/ccu_common.c | 15 +++
drivers/clk/sunxi-ng/ccu_common.h | 3 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu_common.c
b/drivers/clk/sunxi-ng/ccu_common.c
index 8babce55302f..2152063eee16 100644
--- a/drivers/clk/sunxi-ng/ccu_common.c
+++ b/drivers/clk/sunxi-ng/ccu_common.c
@@ -44,6 +44,12 @@ bool ccu_is_better_rate(struct ccu_common *common,
unsigned long current_rate,
unsigned long best_rate)
{
+ if (common->max_rate && current_rate > common->max_rate)
+ return false;
+
+ if (common->min_rate && current_rate < common->min_rate)
+ return false;
+
if (common->features & CCU_FEATURE_CLOSEST_RATE)
return abs(current_rate - target_rate) < abs(best_rate -
target_rate);
@@ -122,7 +128,10 @@ static int sunxi_ccu_probe(struct sunxi_ccu *ccu, struct
device *dev,
for (i = 0; i < desc->hw_clks->num ; i++) {
struct clk_hw *hw = desc->hw_clks->hws[i];
+ struct ccu_common *common = hw_to_ccu_common(hw);
const char *name;
+ unsigned long min_rate = 0;
+ unsigned long max_rate = ULONG_MAX;
if (!hw)
continue;
@@ -136,6 +145,12 @@ static int sunxi_ccu_probe(struct sunxi_ccu *ccu, struct
device *dev,
pr_err("Couldn't register clock %d - %s\n", i, name);
goto err_clk_unreg;
}
+
+ if (common->min_rate)
+ min_rate = common->min_rate;
+ if (common->max_rate)
+ max_rate = common->max_rate;
+ clk_hw_set_rate_range(hw, min_rate, max_rate);
}
ret = of_clk_add_hw_provider(node, of_clk_hw_onecell_get,
diff --git a/drivers/clk/sunxi-ng/ccu_common.h
b/drivers/clk/sunxi-ng/ccu_common.h
index 942a72c09437..329734f8cf42 100644
--- a/drivers/clk/sunxi-ng/ccu_common.h
+++ b/drivers/clk/sunxi-ng/ccu_common.h
@@ -31,6 +31,9 @@ struct ccu_common {
u16 lock_reg;
u32 prediv;
+ unsigned long min_rate;
+ unsigned long max_rate;
+
unsigned long features;
spinlock_t *lock;
struct clk_hw hw;
--
2.44.0
[PATCH v3 0/5] Pinephone video out fixes (flipping between two frames)
On some pinephones the video output sometimes freezes (flips between two frames) [1]. It seems to be that the reason for this behaviour is that PLL-MIPI is outside its limits, and the GPU is not running at a fixed rate. In this patch series I propose the following changes: 1. sunxi-ng: Adhere to the following constraints given in the Allwinner A64 Manual regarding PLL-MIPI: * M/N <= 3 * (PLL_VIDEO0)/M >= 24MHz * 500MHz <= clockrate <= 1400MHz 2. Remove two operating points from the A64 DTS OPPs, so that the GPU runs at a fixed rate of 432 MHz. Note, that when pinning the GPU to 432 MHz the issue [1] completely disappears for me. I've searched the BSP and could not find any indication that supports the idea of having the three OPPs. The only frequency I found in the BPSs for A64 is 432 MHz, which has also proven stable for me. Another bigger change compared to the previous version is that I've removed the patch to adapt the XBD599 panel's timings to Allwinner A64's PLL-MIPI new constraints from this series. Mainly, because I'm currently evaluationg other options that may or may not work. (It may work at least until HDMI support is upstreamed.) I'll probably resend the patch at a later point in time. I very much appreciate your feedback! [1] https://gitlab.com/postmarketOS/pmaports/-/issues/805 Signed-off-by: Frank Oltmanns --- Changes in v3: - dts: Pin GPU to 432 MHz. - nkm and a64: Move minimum and maximum rate handling to the common part of the sunxi-ng driver. - Removed st7703 patch from series. - Link to v2: https://lore.kernel.org/r/20240205-pinephone-pll-fixes-v2-0-96a46a2d8...@oltmanns.dev Changes in v2: - dts: Increase minimum GPU frequency to 192 MHz. - nkm and a64: Add minimum and maximum rate for PLL-MIPI. - nkm: Use the same approach for skipping invalid rates in ccu_nkm_find_best() as in ccu_nkm_find_best_with_parent_adj(). - nkm: Improve names for ratio struct members and hence get rid of describing comments. - nkm and a64: Correct description in the commit messages: M/N <= 3 - Remove patches for nm as they were not needed. - st7703: Rework the commit message to cover more background for the change. - Link to v1: https://lore.kernel.org/r/20231218-pinephone-pll-fixes-v1-0-e238b6ed6...@oltmanns.dev --- Frank Oltmanns (5): clk: sunxi-ng: common: Support minimum and maximum rate clk: sunxi-ng: a64: Set minimum and maximum rate for PLL-MIPI clk: sunxi-ng: nkm: Support constraints on m/n ratio and parent rate clk: sunxi-ng: a64: Add constraints on PLL-MIPI's n/m ratio and parent rate arm64: dts: allwinner: a64: Run GPU at 432 MHz arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 14 +- drivers/clk/sunxi-ng/ccu_common.c | 15 +++ drivers/clk/sunxi-ng/ccu_common.h | 3 +++ drivers/clk/sunxi-ng/ccu_nkm.c| 21 + drivers/clk/sunxi-ng/ccu_nkm.h| 2 ++ 6 files changed, 50 insertions(+), 13 deletions(-) --- base-commit: 216c1282dde38ca87ebdf1ccacee5a0682901574 change-id: 20231218-pinephone-pll-fixes-0ccdfde273e4 Best regards, -- Frank Oltmanns
Re: [PATCH v2] dt-bindings: display: atmel,lcdc: convert to dtschema
On Mon, 04 Mar 2024 11:06:39 +0530, Dharma Balasubiramani wrote: > Convert the atmel,lcdc bindings to DT schema. > Changes during conversion: add missing clocks and clock-names properties. > > Signed-off-by: Dharma Balasubiramani > --- > This patch converts the existing lcdc display text binding to JSON schema. > The binding is split into two namely > lcdc.yaml > - Holds the frame buffer properties > lcdc-display.yaml > - Holds the display panel properties which is a phandle to the display > property in lcdc fb node. > > These bindings are tested against the existing at91 dts files using > dtbs_check. > --- > Changes in v2: > - Run checkpatch and remove whitespace errors. > - Add the standard interrupt flags. > - Split the binding into two, namely lcdc.yaml and lcdc-display.yaml. > - Link to v1: > https://lore.kernel.org/r/20240223-lcdc-fb-v1-1-4c64cb627...@microchip.com > --- > .../bindings/display/atmel,lcdc-display.yaml | 98 > ++ > .../devicetree/bindings/display/atmel,lcdc.txt | 87 --- > .../devicetree/bindings/display/atmel,lcdc.yaml| 70 > 3 files changed, 168 insertions(+), 87 deletions(-) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.example.dtb: display0: 'atmel,dmacon' is a required property from schema $id: http://devicetree.org/schemas/display/atmel,lcdc-display.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.example.dtb: display0: 'atmel,lcdcon2' is a required property from schema $id: http://devicetree.org/schemas/display/atmel,lcdc-display.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.example.dtb: display0: 'atmel,guard-time' is a required property from schema $id: http://devicetree.org/schemas/display/atmel,lcdc-display.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.example.dtb: display0: 'fsl,pcr', 'model' do not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/display/atmel,lcdc-display.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240304-lcdc-fb-v2-1-a14b463c1...@microchip.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
[PATCH v2] dt-bindings: display: atmel,lcdc: convert to dtschema
Convert the atmel,lcdc bindings to DT schema.
Changes during conversion: add missing clocks and clock-names properties.
Signed-off-by: Dharma Balasubiramani
---
This patch converts the existing lcdc display text binding to JSON schema.
The binding is split into two namely
lcdc.yaml
- Holds the frame buffer properties
lcdc-display.yaml
- Holds the display panel properties which is a phandle to the display
property in lcdc fb node.
These bindings are tested against the existing at91 dts files using
dtbs_check.
---
Changes in v2:
- Run checkpatch and remove whitespace errors.
- Add the standard interrupt flags.
- Split the binding into two, namely lcdc.yaml and lcdc-display.yaml.
- Link to v1:
https://lore.kernel.org/r/20240223-lcdc-fb-v1-1-4c64cb627...@microchip.com
---
.../bindings/display/atmel,lcdc-display.yaml | 98 ++
.../devicetree/bindings/display/atmel,lcdc.txt | 87 ---
.../devicetree/bindings/display/atmel,lcdc.yaml| 70
3 files changed, 168 insertions(+), 87 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/atmel,lcdc-display.yaml
b/Documentation/devicetree/bindings/display/atmel,lcdc-display.yaml
new file mode 100644
index ..ea4fd34b9e2c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/atmel,lcdc-display.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/atmel,lcdc-display.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip's LCDC Display
+
+maintainers:
+ - Nicolas Ferre
+ - Dharma Balasubiramani
+
+description:
+ The LCD Controller (LCDC) consists of logic for transferring LCD image data
+ from an external display buffer to a TFT LCD panel. The LCDC has one display
+ input buffer per layer that fetches pixels through the single bus host
+ interface and a look-up table to allow palletized display configurations. The
+ LCDC is programmable on a per layer basis, and supports different LCD
+ resolutions, window sizes, image formats and pixel depths.
+
+# We need a select here since this schema is applicable only for nodes with the
+# following properties
+
+select:
+ anyOf:
+- required: [ 'atmel,dmacon' ]
+- required: [ 'atmel,lcdcon2' ]
+- required: [ 'atmel,guard-time' ]
+- required: [ bits-per-pixel ]
+
+properties:
+ atmel,dmacon:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: dma controller configuration
+
+ atmel,lcdcon2:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: lcd controller configuration
+
+ atmel,guard-time:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: lcd guard time (Delay in frame periods)
+
+ bits-per-pixel:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: lcd panel bit-depth.
+
+ atmel,lcdcon-backlight:
+$ref: /schemas/types.yaml#/definitions/flag
+description: enable backlight
+
+ atmel,lcdcon-backlight-inverted:
+$ref: /schemas/types.yaml#/definitions/flag
+description: invert backlight PWM polarity
+
+ atmel,lcd-wiring-mode:
+$ref: /schemas/types.yaml#/definitions/non-unique-string-array
+description: lcd wiring mode "RGB" or "BRG"
+
+ atmel,power-control-gpio:
+description: gpio to power on or off the LCD (as many as needed)
+
+ display-timings:
+$ref: panel/display-timings.yaml#
+
+required:
+ - atmel,dmacon
+ - atmel,lcdcon2
+ - atmel,guard-time
+ - bits-per-pixel
+
+additionalProperties: false
+
+examples:
+ - |
+display: panel {
+ bits-per-pixel = <32>;
+ atmel,lcdcon-backlight;
+ atmel,dmacon = <0x1>;
+ atmel,lcdcon2 = <0x80008002>;
+ atmel,guard-time = <9>;
+ atmel,lcd-wiring-mode = <1>;
+
+ display-timings {
+native-mode = <>;
+timing0: timing0 {
+ clock-frequency = <900>;
+ hactive = <480>;
+ vactive = <272>;
+ hback-porch = <1>;
+ hfront-porch = <1>;
+ vback-porch = <40>;
+ vfront-porch = <1>;
+ hsync-len = <45>;
+ vsync-len = <1>;
+};
+ };
+};
diff --git a/Documentation/devicetree/bindings/display/atmel,lcdc.txt
b/Documentation/devicetree/bindings/display/atmel,lcdc.txt
deleted file mode 100644
index b5e355ada2fa..
--- a/Documentation/devicetree/bindings/display/atmel,lcdc.txt
+++ /dev/null
@@ -1,87 +0,0 @@
-Atmel LCDC Framebuffer
--
-
-Required properties:
-- compatible :
- "atmel,at91sam9261-lcdc" ,
- "atmel,at91sam9263-lcdc" ,
- "atmel,at91sam9g10-lcdc" ,
- "atmel,at91sam9g45-lcdc" ,
- "atmel,at91sam9g45es-lcdc" ,
- "atmel,at91sam9rl-lcdc" ,
-- reg : Should contain 1 register ranges(address and length).
- Can contain an additional register range(address and length)
- for fixed framebuffer memory. Useful for
[PATCH v2 4/4] video: fbdev: replace of_graph_get_next_endpoint()
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_regs(xxx, 0, -1);
Link: https://lore.kernel.org/r/20240202174941.ga310089-r...@kernel.org
Signed-off-by: Kuninori Morimoto
Reviewed-by: Laurent Pinchart
---
drivers/video/fbdev/omap2/omapfb/dss/dsi.c| 3 ++-
drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 20 +--
drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 3 ++-
drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c | 3 ++-
drivers/video/fbdev/omap2/omapfb/dss/venc.c | 3 ++-
drivers/video/fbdev/pxafb.c | 2 +-
include/video/omapfb_dss.h| 3 ---
7 files changed, 10 insertions(+), 27 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
index b7eb17a16ec4..1f13bcf73da5 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -5079,7 +5080,7 @@ static int dsi_probe_of(struct platform_device *pdev)
struct device_node *ep;
struct omap_dsi_pin_config pin_cfg;
- ep = omapdss_of_get_first_endpoint(node);
+ ep = of_graph_get_endpoint_by_regs(node, 0, -1);
if (!ep)
return 0;
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
index 0282d4eef139..14965a3fd05b 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
@@ -130,24 +130,6 @@ static struct device_node
*omapdss_of_get_remote_port(const struct device_node *
return np;
}
-struct device_node *
-omapdss_of_get_first_endpoint(const struct device_node *parent)
-{
- struct device_node *port, *ep;
-
- port = omapdss_of_get_next_port(parent, NULL);
-
- if (!port)
- return NULL;
-
- ep = omapdss_of_get_next_endpoint(port, NULL);
-
- of_node_put(port);
-
- return ep;
-}
-EXPORT_SYMBOL_GPL(omapdss_of_get_first_endpoint);
-
struct omap_dss_device *
omapdss_of_find_source_for_first_ep(struct device_node *node)
{
@@ -155,7 +137,7 @@ omapdss_of_find_source_for_first_ep(struct device_node
*node)
struct device_node *src_port;
struct omap_dss_device *src;
- ep = omapdss_of_get_first_endpoint(node);
+ ep = of_graph_get_endpoint_by_regs(node, 0, -1);
if (!ep)
return ERR_PTR(-EINVAL);
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
index f05b4e35a842..8f407ec134dc 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -529,7 +530,7 @@ static int hdmi_probe_of(struct platform_device *pdev)
struct device_node *ep;
int r;
- ep = omapdss_of_get_first_endpoint(node);
+ ep = of_graph_get_endpoint_by_regs(node, 0, -1);
if (!ep)
return 0;
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
index 03292945b1d4..4ad219f522b9 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -561,7 +562,7 @@ static int hdmi_probe_of(struct platform_device *pdev)
struct device_node *ep;
int r;
- ep = omapdss_of_get_first_endpoint(node);
+ ep = of_graph_get_endpoint_by_regs(node, 0, -1);
if (!ep)
return 0;
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
index c9d40e28a06f..0bd80d3b8f1b 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -764,7 +765,7 @@ static int venc_probe_of(struct platform_device *pdev)
u32 channels;
int r;
- ep = omapdss_of_get_first_endpoint(node);
+ ep = of_graph_get_endpoint_by_regs(node, 0, -1);
if (!ep)
return 0;
diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index fa943612c4e2..2ef56fa28aff 100644
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -2171,7 +2171,7 @@ static int of_get_pxafb_mode_info(struct device *dev,
u32 bus_width;
int ret, i;
- np = of_graph_get_next_endpoint(dev->of_node, NULL);
+ np = of_graph_get_endpoint_by_regs(dev->of_node,
[PATCH v2 3/4] media: platform: replace of_graph_get_next_endpoint()
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_regs(xxx, 0, -1);
Link: https://lore.kernel.org/r/20240202174941.ga310089-r...@kernel.org
Signed-off-by: Kuninori Morimoto
---
drivers/media/platform/atmel/atmel-isi.c | 4 ++--
drivers/media/platform/intel/pxa_camera.c | 2 +-
drivers/media/platform/samsung/exynos4-is/fimc-is.c | 2 +-
drivers/media/platform/samsung/exynos4-is/mipi-csis.c | 3 ++-
drivers/media/platform/st/stm32/stm32-dcmi.c | 4 ++--
drivers/media/platform/ti/davinci/vpif.c | 3 +--
6 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/atmel/atmel-isi.c
b/drivers/media/platform/atmel/atmel-isi.c
index f8450a8ccda6..c1108df72dd5 100644
--- a/drivers/media/platform/atmel/atmel-isi.c
+++ b/drivers/media/platform/atmel/atmel-isi.c
@@ -834,7 +834,7 @@ static int atmel_isi_parse_dt(struct atmel_isi *isi,
isi->pdata.full_mode = 1;
isi->pdata.frate = ISI_CFG1_FRATE_CAPTURE_ALL;
- np = of_graph_get_next_endpoint(np, NULL);
+ np = of_graph_get_endpoint_by_regs(np, 0, -1);
if (!np) {
dev_err(>dev, "Could not find the endpoint\n");
return -EINVAL;
@@ -1158,7 +1158,7 @@ static int isi_graph_init(struct atmel_isi *isi)
struct device_node *ep;
int ret;
- ep = of_graph_get_next_endpoint(isi->dev->of_node, NULL);
+ ep = of_graph_get_endpoint_by_regs(isi->dev->of_node, 0, -1);
if (!ep)
return -EINVAL;
diff --git a/drivers/media/platform/intel/pxa_camera.c
b/drivers/media/platform/intel/pxa_camera.c
index 59b89e421dc2..d904952bf00e 100644
--- a/drivers/media/platform/intel/pxa_camera.c
+++ b/drivers/media/platform/intel/pxa_camera.c
@@ -2207,7 +2207,7 @@ static int pxa_camera_pdata_from_dt(struct device *dev,
pcdev->mclk = mclk_rate;
}
- np = of_graph_get_next_endpoint(np, NULL);
+ np = of_graph_get_endpoint_by_regs(np, 0, -1);
if (!np) {
dev_err(dev, "could not find endpoint\n");
return -EINVAL;
diff --git a/drivers/media/platform/samsung/exynos4-is/fimc-is.c
b/drivers/media/platform/samsung/exynos4-is/fimc-is.c
index a08c87ef6e2d..39aab667910d 100644
--- a/drivers/media/platform/samsung/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/samsung/exynos4-is/fimc-is.c
@@ -175,7 +175,7 @@ static int fimc_is_parse_sensor_config(struct fimc_is *is,
unsigned int index,
return -EINVAL;
}
- ep = of_graph_get_next_endpoint(node, NULL);
+ ep = of_graph_get_endpoint_by_regs(node, 0, -1);
if (!ep)
return -ENXIO;
diff --git a/drivers/media/platform/samsung/exynos4-is/mipi-csis.c
b/drivers/media/platform/samsung/exynos4-is/mipi-csis.c
index aae8a8b2c0f4..4b9b20ba3504 100644
--- a/drivers/media/platform/samsung/exynos4-is/mipi-csis.c
+++ b/drivers/media/platform/samsung/exynos4-is/mipi-csis.c
@@ -727,7 +727,8 @@ static int s5pcsis_parse_dt(struct platform_device *pdev,
>max_num_lanes))
return -EINVAL;
- node = of_graph_get_next_endpoint(node, NULL);
+ /* from port@3 or port@4 */
+ node = of_graph_get_endpoint_by_regs(node, -1, -1);
if (!node) {
dev_err(>dev, "No port node at %pOF\n",
pdev->dev.of_node);
diff --git a/drivers/media/platform/st/stm32/stm32-dcmi.c
b/drivers/media/platform/st/stm32/stm32-dcmi.c
index c4610e305546..ff3331af9406 100644
--- a/drivers/media/platform/st/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/st/stm32/stm32-dcmi.c
@@ -1855,7 +1855,7 @@ static int dcmi_graph_init(struct stm32_dcmi *dcmi)
struct device_node *ep;
int ret;
- ep = of_graph_get_next_endpoint(dcmi->dev->of_node, NULL);
+ ep = of_graph_get_endpoint_by_regs(dcmi->dev->of_node, 0, -1);
if (!ep) {
dev_err(dcmi->dev, "Failed to get next endpoint\n");
return -EINVAL;
@@ -1907,7 +1907,7 @@ static int dcmi_probe(struct platform_device *pdev)
"Could not get reset control\n");
/* Get bus characteristics from devicetree */
- np = of_graph_get_next_endpoint(np, NULL);
+ np = of_graph_get_endpoint_by_regs(np, 0, -1);
if (!np) {
dev_err(>dev, "Could not find the endpoint\n");
return -ENODEV;
diff --git a/drivers/media/platform/ti/davinci/vpif.c
b/drivers/media/platform/ti/davinci/vpif.c
index 63cdfed37bc9..f4e1fa76bf37 100644
--- a/drivers/media/platform/ti/davinci/vpif.c
+++ b/drivers/media/platform/ti/davinci/vpif.c
@@ -465,8 +465,7 @@ static int
[PATCH v2 2/4] media: i2c: replace of_graph_get_next_endpoint()
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_regs(xxx, 0, -1);
Link: https://lore.kernel.org/r/20240202174941.ga310089-r...@kernel.org
Link: https://lore.kernel.org/r/9d1e99b0-892d-4a72-a9b3-886b8ed09...@xs4all.nl
Signed-off-by: Kuninori Morimoto
---
drivers/media/i2c/adv7343.c | 2 +-
drivers/media/i2c/adv7604.c | 4 ++--
drivers/media/i2c/mt9p031.c | 2 +-
drivers/media/i2c/mt9v032.c | 2 +-
drivers/media/i2c/ov2659.c | 2 +-
drivers/media/i2c/ov5645.c | 2 +-
drivers/media/i2c/ov5647.c | 2 +-
drivers/media/i2c/s5c73m3/s5c73m3-core.c | 2 +-
drivers/media/i2c/s5k5baf.c | 2 +-
drivers/media/i2c/tc358743.c | 2 +-
drivers/media/i2c/tda1997x.c | 2 +-
drivers/media/i2c/tvp514x.c | 2 +-
drivers/media/i2c/tvp7002.c | 2 +-
13 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/media/i2c/adv7343.c b/drivers/media/i2c/adv7343.c
index ff21cd4744d3..4fbe4e18570e 100644
--- a/drivers/media/i2c/adv7343.c
+++ b/drivers/media/i2c/adv7343.c
@@ -403,7 +403,7 @@ adv7343_get_pdata(struct i2c_client *client)
if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
return client->dev.platform_data;
- np = of_graph_get_next_endpoint(client->dev.of_node, NULL);
+ np = of_graph_get_endpoint_by_regs(client->dev.of_node, 0, -1);
if (!np)
return NULL;
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 810fa8826f30..319db3e847c4 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -3204,8 +3204,8 @@ static int adv76xx_parse_dt(struct adv76xx_state *state)
np = state->i2c_clients[ADV76XX_PAGE_IO]->dev.of_node;
- /* Parse the endpoint. */
- endpoint = of_graph_get_next_endpoint(np, NULL);
+ /* FIXME: Parse the endpoint. */
+ endpoint = of_graph_get_endpoint_by_regs(np, -1, -1);
if (!endpoint)
return -EINVAL;
diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
index 596200d0248c..f4b481212356 100644
--- a/drivers/media/i2c/mt9p031.c
+++ b/drivers/media/i2c/mt9p031.c
@@ -1078,7 +1078,7 @@ mt9p031_get_pdata(struct i2c_client *client)
if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
return client->dev.platform_data;
- np = of_graph_get_next_endpoint(client->dev.of_node, NULL);
+ np = of_graph_get_endpoint_by_regs(client->dev.of_node, 0, -1);
if (!np)
return NULL;
diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
index 3ca76eeae7ff..e9f5c6647f97 100644
--- a/drivers/media/i2c/mt9v032.c
+++ b/drivers/media/i2c/mt9v032.c
@@ -1006,7 +1006,7 @@ mt9v032_get_pdata(struct i2c_client *client)
if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
return client->dev.platform_data;
- np = of_graph_get_next_endpoint(client->dev.of_node, NULL);
+ np = of_graph_get_endpoint_by_regs(client->dev.of_node, 0, -1);
if (!np)
return NULL;
diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
index 1d0ef72a6403..d1653d7431d0 100644
--- a/drivers/media/i2c/ov2659.c
+++ b/drivers/media/i2c/ov2659.c
@@ -1388,7 +1388,7 @@ ov2659_get_pdata(struct i2c_client *client)
if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
return client->dev.platform_data;
- endpoint = of_graph_get_next_endpoint(client->dev.of_node, NULL);
+ endpoint = of_graph_get_endpoint_by_regs(client->dev.of_node, 0, -1);
if (!endpoint)
return NULL;
diff --git a/drivers/media/i2c/ov5645.c b/drivers/media/i2c/ov5645.c
index a26ac11c989d..9daf06ffedf4 100644
--- a/drivers/media/i2c/ov5645.c
+++ b/drivers/media/i2c/ov5645.c
@@ -1056,7 +1056,7 @@ static int ov5645_probe(struct i2c_client *client)
ov5645->i2c_client = client;
ov5645->dev = dev;
- endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
+ endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1);
if (!endpoint) {
dev_err(dev, "endpoint node not found\n");
return -EINVAL;
diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c
index 96c0fd4ff5ab..7e1ecdf2485f 100644
--- a/drivers/media/i2c/ov5647.c
+++ b/drivers/media/i2c/ov5647.c
@@ -1363,7 +1363,7 @@ static int ov5647_parse_dt(struct ov5647 *sensor, struct
device_node *np)
struct device_node *ep;
int ret;
- ep = of_graph_get_next_endpoint(np, NULL);
+ ep = of_graph_get_endpoint_by_regs(np, 0, -1);
if (!ep)
[PATCH v2 1/4] gpu: drm: replace of_graph_get_next_endpoint()
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_regs(xxx, 0, -1);
Link: https://lore.kernel.org/r/20240202174941.ga310089-r...@kernel.org
Signed-off-by: Kuninori Morimoto
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/drm_of.c | 4 +++-
drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 2 +-
drivers/gpu/drm/tiny/arcpgu.c | 2 +-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 177b600895d3..b6b2cade69ae 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -504,6 +504,8 @@ EXPORT_SYMBOL_GPL(drm_of_get_data_lanes_count_ep);
* Gets parent DSI bus for a DSI device controlled through a bus other
* than MIPI-DCS (SPI, I2C, etc.) using the Device Tree.
*
+ * This function assumes that the device's port@0 is the DSI input.
+ *
* Returns pointer to mipi_dsi_host if successful, -EINVAL if the
* request is unsupported, -EPROBE_DEFER if the DSI host is found but
* not available, or -ENODEV otherwise.
@@ -516,7 +518,7 @@ struct mipi_dsi_host *drm_of_get_dsi_bus(struct device *dev)
/*
* Get first endpoint child from device.
*/
- endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
+ endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1);
if (!endpoint)
return ERR_PTR(-ENODEV);
diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
index 4618c892cdd6..e10e469aa7a6 100644
--- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
+++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
@@ -400,7 +400,7 @@ static int rpi_touchscreen_probe(struct i2c_client *i2c)
rpi_touchscreen_i2c_write(ts, REG_POWERON, 0);
/* Look up the DSI host. It needs to probe before we do. */
- endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
+ endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1);
if (!endpoint)
return -ENODEV;
diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/drivers/gpu/drm/tiny/arcpgu.c
index 4f8f3172379e..8c29b719ea62 100644
--- a/drivers/gpu/drm/tiny/arcpgu.c
+++ b/drivers/gpu/drm/tiny/arcpgu.c
@@ -288,7 +288,7 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
* There is only one output port inside each device. It is linked with
* encoder endpoint.
*/
- endpoint_node = of_graph_get_next_endpoint(pdev->dev.of_node, NULL);
+ endpoint_node = of_graph_get_endpoint_by_regs(pdev->dev.of_node, 0, -1);
if (endpoint_node) {
encoder_node = of_graph_get_remote_port_parent(endpoint_node);
of_node_put(endpoint_node);
--
2.25.1
[PATCH v2 resend 0/4] of: replace of_graph_get_next_endpoint()
Hi Rob This is resend v2 of replace of_graph_get_next_endpoint() We should get rid of or minimize of_graph_get_next_endpoint() in its current form. In general, drivers should be asking for a specific port number because their function is fixed in the binding. https://lore.kernel.org/r/20240131184347.ga1906672-r...@kernel.org This patch-set replace of_graph_get_next_endpoint() by of_graph_get_endpoint_by_regs(). There are still next_endpoint() after this patch-set, but it will be replaced by for_each_endpoint_of_node() in next patch-set (A) [*] this patch-set [o] done [o] tidyup of_graph_get_endpoint_count() [*] replace endpoint func - use endpoint_by_regs() (A) [ ] replace endpoint func - use for_each() [ ] rename endpoint func to device_endpoint [ ] add new port function [ ] add new endpont function [ ] remove of_graph_get_next_device_endpoint() v1 -> v2 - add Reviewed-by from Launrent - use by_regs(xx, -1, -1) for some devices - add extra explain for drm_of_get_dsi_bus() - add FIXME and Link on adv7604.c - based on latest of branch Kuninori Morimoto (4): gpu: drm: replace of_graph_get_next_endpoint() media: i2c: replace of_graph_get_next_endpoint() media: platform: replace of_graph_get_next_endpoint() video: fbdev: replace of_graph_get_next_endpoint() drivers/gpu/drm/drm_of.c | 4 +++- .../drm/panel/panel-raspberrypi-touchscreen.c | 2 +- drivers/gpu/drm/tiny/arcpgu.c | 2 +- drivers/media/i2c/adv7343.c | 2 +- drivers/media/i2c/adv7604.c | 4 ++-- drivers/media/i2c/mt9p031.c | 2 +- drivers/media/i2c/mt9v032.c | 2 +- drivers/media/i2c/ov2659.c| 2 +- drivers/media/i2c/ov5645.c| 2 +- drivers/media/i2c/ov5647.c| 2 +- drivers/media/i2c/s5c73m3/s5c73m3-core.c | 2 +- drivers/media/i2c/s5k5baf.c | 2 +- drivers/media/i2c/tc358743.c | 2 +- drivers/media/i2c/tda1997x.c | 2 +- drivers/media/i2c/tvp514x.c | 2 +- drivers/media/i2c/tvp7002.c | 2 +- drivers/media/platform/atmel/atmel-isi.c | 4 ++-- drivers/media/platform/intel/pxa_camera.c | 2 +- .../platform/samsung/exynos4-is/fimc-is.c | 2 +- .../platform/samsung/exynos4-is/mipi-csis.c | 3 ++- drivers/media/platform/st/stm32/stm32-dcmi.c | 4 ++-- drivers/media/platform/ti/davinci/vpif.c | 3 +-- drivers/video/fbdev/omap2/omapfb/dss/dsi.c| 3 ++- drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 20 +-- drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 3 ++- drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c | 3 ++- drivers/video/fbdev/omap2/omapfb/dss/venc.c | 3 ++- drivers/video/fbdev/pxafb.c | 2 +- include/video/omapfb_dss.h| 3 --- 29 files changed, 38 insertions(+), 53 deletions(-)
Re: [PATCH] dt-bindings: display: atmel,lcdc: convert to dtschema
On 01/03/24 11:40 pm, Rob Herring wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Thu, Feb 29, 2024 at 06:25:56AM +, dharm...@microchip.com wrote: >> On 28/02/24 3:53 pm, Krzysztof Kozlowski wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the >>> content is safe >>> >>> On 28/02/2024 11:18, dharm...@microchip.com wrote: On 28/02/24 12:43 pm, Krzysztof Kozlowski wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know > the content is safe > > On 28/02/2024 07:59, dharm...@microchip.com wrote: >> >>> >>> I don't know what's this exactly, but if embedded display then maybe >>> could be part of this device node. If some other display, then maybe you >>> need another schema, with compatible? But first I would check how others >>> are doing this. >> >> Okay, then I think the driver also needs to be modified, currently the >> driver parses the phandle and looks for these properties. Also the >> corresponding dts files. > > Driver does not have to be modified in my proposal. You would still have > phandle. If I understand correctly, I could define the dt bindings as below display: $ref: /schemas/types.yaml#/definitions/phandle description: A phandle pointing to the display node. panel: $ref: panel/panel-common.yaml# properties: >>> >>> So these are standard panel bindings? Then the node should live outside >>> of lcdc. If current driver needs to poke inside panel and panel could be >>> anything, then probably you need peripheral-props-like approach. :/ >> >> Thank you so much, so can I use something like this >> >> display: >> $ref: /schemas/types.yaml#/definitions/phandle >> description: A phandle pointing to the display node. >> >> patternProperties: >> "^panel": > > Just 'panel' and not a pattern. > > However, that's not what the original binding had. It was a separate > node. If you want to preserve that, then you'll need a separate > schema file and a special 'select'. Something like: > > select: >anyOf: > - required: [ atmel,dmacon ] > - required: [ atmel,lcdcon2 ] > - required: [ atmel,guard-time ] > > Up to you and at91 maintainers if you want to have to update your dts > files or not. > > Rob Thank you so much Rob, I will introduce a new binding for lcdc-display with a special select as you suggested. I will send a v2 with the following changes - Run checkpatch and remove whitespace errors. - Add the standard interrupt flags. - Split the binding into two namely lcdc.yaml and lcdc-display.yaml. for your kind perusal. -- With Best Regards, Dharma B.
[PATCH v2 1/1] UPSTREAM: drm/bridge: it6505: fix hibernate to resume no display issue
From: kuro chung
ITE added a FIFO reset bit for input video. When system power resume,
the TTL input of it6505 may get some noise before video signal stable
and the hardware function reset is required.
But the input FIFO reset will also trigger error interrupts of output module
rising.
Thus, it6505 have to wait a period can clear those expected error interrupts
caused by manual hardware reset in one interrupt handler calling to avoid
interrupt looping.
Signed-off-by: Allen Chen
(cherry picked from commit Iaa3cd9da92a625496f579d87d0ab74ca9c4937c4)
BUG=None
TEST=None
Change-Id: Iaa3cd9da92a625496f579d87d0ab74ca9c4937c4
---
drivers/gpu/drm/bridge/ite-it6505.c | 54 -
1 file changed, 45 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ite-it6505.c
b/drivers/gpu/drm/bridge/ite-it6505.c
index b53da9bb65a16..e592e14a48578 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -1318,6 +1318,8 @@ static void it6505_video_reset(struct it6505 *it6505)
it6505_set_bits(it6505, REG_DATA_MUTE_CTRL, EN_VID_MUTE, EN_VID_MUTE);
it6505_set_bits(it6505, REG_INFOFRAME_CTRL, EN_VID_CTRL_PKT, 0x00);
it6505_set_bits(it6505, REG_RESET_CTRL, VIDEO_RESET, VIDEO_RESET);
+ it6505_set_bits(it6505, REG_VID_BUS_CTRL1, TX_FIFO_RESET, 0x02);
+ it6505_set_bits(it6505, REG_VID_BUS_CTRL1, TX_FIFO_RESET, 0x00);
it6505_set_bits(it6505, REG_501_FIFO_CTRL, RST_501_FIFO, RST_501_FIFO);
it6505_set_bits(it6505, REG_501_FIFO_CTRL, RST_501_FIFO, 0x00);
it6505_set_bits(it6505, REG_RESET_CTRL, VIDEO_RESET, 0x00);
@@ -2480,10 +2482,6 @@ static void it6505_irq_video_fifo_error(struct it6505
*it6505)
struct device *dev = >client->dev;
DRM_DEV_DEBUG_DRIVER(dev, "video fifo overflow interrupt");
- it6505->auto_train_retry = AUTO_TRAIN_RETRY;
- flush_work(>link_works);
- it6505_stop_hdcp(it6505);
- it6505_video_reset(it6505);
}
static void it6505_irq_io_latch_fifo_overflow(struct it6505 *it6505)
@@ -2491,10 +2489,6 @@ static void it6505_irq_io_latch_fifo_overflow(struct
it6505 *it6505)
struct device *dev = >client->dev;
DRM_DEV_DEBUG_DRIVER(dev, "IO latch fifo overflow interrupt");
- it6505->auto_train_retry = AUTO_TRAIN_RETRY;
- flush_work(>link_works);
- it6505_stop_hdcp(it6505);
- it6505_video_reset(it6505);
}
static bool it6505_test_bit(unsigned int bit, const unsigned int *addr)
@@ -2502,6 +2496,46 @@ static bool it6505_test_bit(unsigned int bit, const
unsigned int *addr)
return 1 & (addr[bit / BITS_PER_BYTE] >> (bit % BITS_PER_BYTE));
}
+static bool it6505_is_video_error_int(const int *int_status)
+{
+ if ((it6505_test_bit(BIT_INT_VID_FIFO_ERROR, (unsigned int
*)int_status)) || (it6505_test_bit(BIT_INT_IO_FIFO_OVERFLOW, (unsigned int
*)int_status)))
+ return 1;
+ return 0;
+}
+
+static void it6505_irq_video_error_handler(struct it6505 *it6505)
+{
+ struct device *dev = >client->dev;
+ int int_status[3] = {0};
+ int reg_0d;
+ int i;
+
+ it6505->auto_train_retry = AUTO_TRAIN_RETRY;
+ flush_work(>link_works);
+ it6505_stop_hdcp(it6505);
+ it6505_video_reset(it6505);
+
+ DRM_DEV_DEBUG_DRIVER(dev, "Video Error reset wait video...");
+
+ for (i = 0; i < 10; i++) {
+ usleep_range(1, 11000);
+ int_status[2] = it6505_read(it6505, INT_STATUS_03);
+ reg_0d = it6505_read(it6505, REG_SYSTEM_STS);
+ it6505_write(it6505, INT_STATUS_03, int_status[2]);
+
+ DRM_DEV_DEBUG_DRIVER(dev, "reg08 = 0x%02x", int_status[2]);
+ DRM_DEV_DEBUG_DRIVER(dev, "reg0D = 0x%02x", reg_0d);
+
+ if ((reg_0d & VIDEO_STB) && (reg_0d >= 0))
+ break;
+
+ if (it6505_is_video_error_int(int_status)) {
+ it6505_video_reset(it6505);
+ DRM_DEV_DEBUG_DRIVER(dev, "Video Error reset wait video
(%d)", i);
+ }
+ }
+}
+
static irqreturn_t it6505_int_threaded_handler(int unused, void *data)
{
struct it6505 *it6505 = data;
@@ -2522,7 +2556,7 @@ static irqreturn_t it6505_int_threaded_handler(int
unused, void *data)
{ BIT_INT_VID_FIFO_ERROR, it6505_irq_video_fifo_error },
{ BIT_INT_IO_FIFO_OVERFLOW, it6505_irq_io_latch_fifo_overflow },
};
- int int_status[3], i;
+ int int_status[3], i, reg_0d;
if (it6505->enable_drv_hold || !it6505->powered)
return IRQ_HANDLED;
@@ -2550,6 +2584,8 @@ static irqreturn_t it6505_int_threaded_handler(int
unused, void *data)
if (it6505_test_bit(irq_vec[i].bit, (unsigned int
*)int_status))
irq_vec[i].handler(it6505);
}
+ if (it6505_is_video_error_int(int_status))
+
[PATCH v2 0/1] drm/bridge: it6505: fix hibernate to resume no display issue patch v2
From: kuro chung New patch description for v2 patch Missing declaration for i variable in function it6505_irq_video_error_handler , add it by this patch Origianl description for v1 patch drm/bridge: it6505: fix hibernate to resume no display issue ITE added a FIFO reset bit for input video. When system power resume, the TTL input of it6505 may get some noise before video signal stable and the hardware function reset is required. But the input FIFO reset will also trigger error interrupts of output module rising. Thus, it6505 have to wait a period can clear those expected error interrupts caused by manual hardware reset in one interrupt handler calling to avoid interrupt looping. Signed-off-by: Allen Chen (cherry picked from commit Iaa3cd9da92a625496f579d87d0ab74ca9c4937c4) allen (1): UPSTREAM: drm/bridge: it6505: fix hibernate to resume no display issue drivers/gpu/drm/bridge/ite-it6505.c | 54 - 1 file changed, 45 insertions(+), 9 deletions(-) -- 2.25.1
Re: [PATCH] nouveau/dmem: handle kcalloc() allocation failure
On Sun, Mar 3, 2024 at 4:46 AM Duoming Zhou wrote: > > The kcalloc() in nouveau_dmem_evict_chunk() will return null if > the physical memory has run out. As a result, if we dereference > src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs > will happen. > > This patch uses stack variables to replace the kcalloc(). Won't this blow the stack? And why not just test the return value of kcalloc?
linux-next: manual merge of the drm tree with Linus' tree
Hi all,
FIXME: Add owner of second tree to To:
Add author(s)/SOB of conflicting commits.
Today's linux-next merge of the drm tree got conflicts in:
drivers/gpu/drm/xe/xe_exec_queue.c
drivers/gpu/drm/xe/xe_exec_queue_types.h
between commit:
eaa367a0317e ("drm/xe/uapi: Remove unused flags")
from Linus' tree and commits:
25ce7c5063b3 ("drm/xe: Finish refactoring of exec_queue_create")
f1a9abc0cf31 ("drm/xe/uapi: Remove support for persistent exec_queues")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/xe/xe_exec_queue.c
index 49223026c89f,4bb8f897bf15..
--- a/drivers/gpu/drm/xe/xe_exec_queue.c
+++ b/drivers/gpu/drm/xe/xe_exec_queue.c
@@@ -306,9 -347,98 +347,13 @@@ static int exec_queue_set_timeslice(str
!xe_hw_engine_timeout_in_range(value, min, max))
return -EINVAL;
- return q->ops->set_timeslice(q, value);
+ if (!create)
+ return q->ops->set_timeslice(q, value);
+
+ q->sched_props.timeslice_us = value;
+ return 0;
}
-static int exec_queue_set_preemption_timeout(struct xe_device *xe,
- struct xe_exec_queue *q, u64 value,
- bool create)
-{
- u32 min = 0, max = 0;
-
- xe_exec_queue_get_prop_minmax(q->hwe->eclass,
-XE_EXEC_QUEUE_PREEMPT_TIMEOUT, ,
);
-
- if (xe_exec_queue_enforce_schedule_limit() &&
- !xe_hw_engine_timeout_in_range(value, min, max))
- return -EINVAL;
-
- if (!create)
- return q->ops->set_preempt_timeout(q, value);
-
- q->sched_props.preempt_timeout_us = value;
- return 0;
-}
-
-static int exec_queue_set_job_timeout(struct xe_device *xe, struct
xe_exec_queue *q,
-u64 value, bool create)
-{
- u32 min = 0, max = 0;
-
- if (XE_IOCTL_DBG(xe, !create))
- return -EINVAL;
-
- xe_exec_queue_get_prop_minmax(q->hwe->eclass,
-XE_EXEC_QUEUE_JOB_TIMEOUT, , );
-
- if (xe_exec_queue_enforce_schedule_limit() &&
- !xe_hw_engine_timeout_in_range(value, min, max))
- return -EINVAL;
-
- q->sched_props.job_timeout_ms = value;
-
- return 0;
-}
-
-static int exec_queue_set_acc_trigger(struct xe_device *xe, struct
xe_exec_queue *q,
-u64 value, bool create)
-{
- if (XE_IOCTL_DBG(xe, !create))
- return -EINVAL;
-
- if (XE_IOCTL_DBG(xe, !xe->info.has_usm))
- return -EINVAL;
-
- q->usm.acc_trigger = value;
-
- return 0;
-}
-
-static int exec_queue_set_acc_notify(struct xe_device *xe, struct
xe_exec_queue *q,
- u64 value, bool create)
-{
- if (XE_IOCTL_DBG(xe, !create))
- return -EINVAL;
-
- if (XE_IOCTL_DBG(xe, !xe->info.has_usm))
- return -EINVAL;
-
- q->usm.acc_notify = value;
-
- return 0;
-}
-
-static int exec_queue_set_acc_granularity(struct xe_device *xe, struct
xe_exec_queue *q,
-u64 value, bool create)
-{
- if (XE_IOCTL_DBG(xe, !create))
- return -EINVAL;
-
- if (XE_IOCTL_DBG(xe, !xe->info.has_usm))
- return -EINVAL;
-
- if (value > DRM_XE_ACC_GRANULARITY_64M)
- return -EINVAL;
-
- q->usm.acc_granularity = value;
-
- return 0;
-}
-
typedef int (*xe_exec_queue_set_property_fn)(struct xe_device *xe,
struct xe_exec_queue *q,
u64 value, bool create);
diff --cc drivers/gpu/drm/xe/xe_exec_queue_types.h
index 36f4901d8d7e,c40240e88068..
--- a/drivers/gpu/drm/xe/xe_exec_queue_types.h
+++ b/drivers/gpu/drm/xe/xe_exec_queue_types.h
pgpb1cvuqnp5E.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the drm tree with Linus' tree
Hi all,
Today's linux-next merge of the drm tree got conflicts in:
drivers/gpu/drm/xe/xe_bo.c
drivers/gpu/drm/xe/xe_bo.h
between commits:
a09946a9a903 ("drm/xe/xe_bo_move: Enhance xe_bo_move trace")
8188cae3cc3d ("drm/xe/xe_trace: Add move_lacks_source detail to xe_bo_move
trace")
from Linus' tree and commit:
a0df2cc858c3 ("drm/xe/xe_bo_move: Enhance xe_bo_move trace")
from the drm tree.
I fixed it up (I just used the former) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgp85cmnXwQF0.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/2] drm_edid: Add a function to get EDID base block
On Thu, 29 Feb 2024 at 19:11, Doug Anderson wrote: > > Hi, > > On Thu, Feb 29, 2024 at 8:43 AM Jani Nikula > wrote: > > > > On Wed, 28 Feb 2024, Doug Anderson wrote: > > > Hi, > > > > > > On Tue, Feb 27, 2024 at 5:27 PM Hsin-Yi Wang wrote: > > >> > > >> On Tue, Feb 27, 2024 at 1:09 AM Jani Nikula > > >> wrote: > > >> > > > >> > On Fri, 23 Feb 2024, Hsin-Yi Wang wrote: > > >> > > It's found that some panels have variants that they share the same > > >> > > panel id > > >> > > although their EDID and names are different. Besides panel id, now > > >> > > we need > > >> > > the hash of entire EDID base block to distinguish these panel > > >> > > variants. > > >> > > > > >> > > Add drm_edid_get_base_block to returns the EDID base block, so > > >> > > caller can > > >> > > further use it to get panel id and/or the hash. > > >> > > > >> > Please reconsider the whole approach here. > > >> > > > >> > Please let's not add single-use special case functions to read an EDID > > >> > base block. > > >> > > > >> > Please consider reading the whole EDID, using the regular EDID reading > > >> > functions, and use that instead. > > >> > > > >> > Most likely you'll only have 1-2 blocks anyway. And you might consider > > >> > caching the EDID in struct panel_edp if reading the entire EDID is too > > >> > slow. (And if it is, this is probably sensible even if the EDID only > > >> > consists of one block.) > > >> > > > >> > Anyway, please do *not* merge this as-is. > > >> > > > >> > > >> hi Jani, > > >> > > >> I sent a v2 here implementing this method: > > >> https://lore.kernel.org/lkml/20240228011133.1238439-2-hsi...@chromium.org/ > > >> > > >> We still have to read edid twice due to: > > >> 1. The first caller is in panel probe, at that time, connector is > > >> still unknown, so we can't update connector status (eg. update > > >> edid_corrupt). > > >> 2. It's possible that the connector can have some override > > >> (drm_edid_override_get) to EDID, that is still unknown during the > > >> first read. > > > > > > I'll also comment in Hsin-Yi's v2, but given Hsin-Yi's digging and the > > > fact that we can't cache the EDID (because we don't yet have a > > > "drm_connector"), I'd much prefer Hsin-Yi's solution here from v1 that > > > allows reading just the first block. If we try to boot a device with a > > > multi-block EDID we're now wastefully reading all the blocks of the > > > EDID twice at bootup which will slow boot time. > > > > > > If you can see a good solution to avoid reading the EDID twice then > > > that would be amazing, but if not it seems like we should go back to > > > what's here in v1. What do you think? Anyone else have any opinions? > > > > I haven't replied so far, because I've been going back and forth with > > this. I'm afraid I don't really like either approach now. Handling the > > no connector case in v2 is a bit ugly too. :( > > > > Seems like you only need this to extend the panel ID with a hash. And > > panel-edp.c is the only user of drm_edid_get_panel_id(). And EDID quirks > > in drm_edid.c could theoretically hit the same problem you're solving. > > Good point. That would imply that more of the logic could go into > "drm_edid.c" in case the EDID quirks code eventually needs it. > > > > So maybe something like: > > > > u32 drm_edid_get_panel_id(struct i2c_adapter *adapter, u32 *hash); > > > > or if you want to be fancy add a struct capturing both id and hash: > > > > bool drm_edid_get_panel_id(struct i2c_adapter *adapter, struct > > drm_edid_panel_id *id); > > > > And put the hash (or whatever mechanism you have) computation in > > drm_edid.c. Just hide it all in drm_edid.c, and keep the EDID interfaces > > neat. > > > > How would that work for you? > > The problem is that Dmitry didn't like the idea of using a hash and in > v2 Hsin-Yi has moved to using the name of the display. ...except of > course that eDP panels don't always properly specify > "EDID_DETAIL_MONITOR_NAME". See the discussion [1]. If you want to see > some of the EDIDs involved, you can see Hsin-Yi's post [2]. The panels > included stuff like this: > > Alphanumeric Data String: 'AUO' > Alphanumeric Data String: 'B116XAN04.0 ' > > The fact that there is more than one string in there makes it hard to > just "return" the display name in a generic way. The way Hsin-Yi's > code was doing it was that it would consider it a match if the panel > name was in any of the strings... > > How about this as a solution: we change drm_edid_get_panel_id() to > return an opaque type (struct drm_edid_panel_id_blob) that's really > just the first block of the EDID but we can all pretend that it isn't. > Then we can add a function in drm_edid.c that takes this opaque blob, > a 32-bit integer (as per drm_edid_encode_panel_id()), and a string > name and it can tell us if the blob matches? Would it be easier to push drm_edid_match to drm_edid.c? It looks way more simpler than the opaque blob. > [1] >
Re: [PATCH] drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE
On Thu, 29 Feb 2024 at 11:27, Luca Weiss wrote:
>
> On Wed Jan 17, 2024 at 9:59 AM CET, Luca Weiss wrote:
> > On Mon Jan 15, 2024 at 9:43 AM CET, Neil Armstrong wrote:
> > > Hi Luca,
> > >
> > > On 11/01/2024 13:38, Luca Weiss wrote:
> > > > Since the kconfig symbol of DRM_PANEL_BRIDGE is only adding
> > > > bridge/panel.o to drm_kms_helper object, we need to select
> > > > DRM_KMS_HELPER to make sure the file is actually getting built.
> > > >
> > > > Otherwise with certain defconfigs e.g. devm_drm_of_get_bridge will not
> > > > be properly available:
> > > >
> > > >aarch64-linux-gnu-ld: drivers/phy/qualcomm/phy-qcom-qmp-combo.o: in
> > > > function `qmp_combo_bridge_attach':
> > > >drivers/phy/qualcomm/phy-qcom-qmp-combo.c:3204:(.text+0x8f4):
> > > > undefined reference to `devm_drm_of_get_bridge'
> > > >
> > > > Signed-off-by: Luca Weiss
> > > > ---
> > > > I can see "depends on DRM_KMS_HELPER" was removed with commit
> > > > 3c3384050d68 ("drm: Don't make DRM_PANEL_BRIDGE dependent on
> > > > DRM_KMS_HELPERS")
Could you please make sure that the usecase described in the mentioned
commit message doesn't get broken by your change?
> > > >
> > > > I'm not too familiar with Kconfig but it feels more correct if
> > > > PHY_QCOM_QMP_COMBO selects DRM_PANEL_BRIDGE that that's enough; and it
> > > > doesn't also has to explicitly select DRM_KMS_HELPER because of how the
> > > > objects are built in the Makefile.
> > > >
> > > > Alternatively solution to this patch could be adjusting this line in
> > > > include/drm/drm_bridge.h:
> > > >
> > > >-#if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL_BRIDGE)
> > > >+#if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL_BRIDGE) &&
> > > > defined(CONFIG_DRM_KMS_HELPER)
> > > > struct drm_bridge *devm_drm_of_get_bridge(struct device *dev,
> > > > struct device_node *node,
> > > > u32 port, u32 endpoint);
> > > >
> > > > .. and then selecting DRM_KMS_HELPER for PHY_QCOM_QMP_COMBO.
> > > >
> > > > But I think the solution in this patch is better. Let me know what you
> > > > think.
> > >
> > > I think this is no more the case after on linux-next:
> > > 35921910bbd0 phy: qcom: qmp-combo: switch to DRM_AUX_BRIDGE
> > >
> > > But could you still check ?
> >
> > On next-20240117 the error happens in the aux-bridge file instead then.
> >
> > aarch64-linux-gnu-ld: drivers/gpu/drm/bridge/aux-bridge.o: in function
> > `drm_aux_bridge_probe':
> > drivers/gpu/drm/bridge/aux-bridge.c:115:(.text+0xe0): undefined reference
> > to `devm_drm_of_get_bridge'
> >
> > I'm attaching the defconfig with which I can reproduce this but it's
> > really just DRM_KMS_HELPER=n and PHY_QCOM_QMP_COMBO=y I believe.
>
> Hi Neil,
>
> Ping on this patch
>
> Regards
> Luca
>
> >
> > Regards
> > Luca
> >
> >
> > >
> > > Neil
> > >
> > > > ---
> > > > drivers/gpu/drm/bridge/Kconfig | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > > > b/drivers/gpu/drm/bridge/Kconfig
> > > > index ac9ec5073619..ae782b427829 100644
> > > > --- a/drivers/gpu/drm/bridge/Kconfig
> > > > +++ b/drivers/gpu/drm/bridge/Kconfig
> > > > @@ -8,6 +8,7 @@ config DRM_BRIDGE
> > > > config DRM_PANEL_BRIDGE
> > > > def_bool y
> > > > depends on DRM_BRIDGE
> > > > + select DRM_KMS_HELPER
> > > > select DRM_PANEL
> > > > help
> > > > DRM bridge wrapper of DRM panels
> > > >
> > > > ---
> > > > base-commit: b9c3a1fa6fb324e691a03cf124b79f4842e65d76
> > > > change-id: 20240111-drm-panel-bridge-fixup-5c2977fb969f
> > > >
> > > > Best regards,
>
--
With best wishes
Dmitry
Re: [PATCH v2 1/3] dt-bindings: display: msm: dp-controller: document X1E80100 compatible
On Fri, 1 Mar 2024 at 19:52, Rob Herring wrote: > > On Tue, Feb 27, 2024 at 04:45:25PM +0100, Krzysztof Kozlowski wrote: > > On 22/02/2024 16:55, Abel Vesa wrote: > > > Add the X1E80100 to the list of compatibles and document the is-edp > > > flag. The controllers are expected to operate in DP mode by default, > > > and this flag can be used to select eDP mode. > > > > > > Signed-off-by: Abel Vesa > > > --- > > > Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 6 > > > ++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > > > b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > > > index ae53cbfb2193..ed11852e403d 100644 > > > --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > > > +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > > > @@ -27,6 +27,7 @@ properties: > > >- qcom,sdm845-dp > > >- qcom,sm8350-dp > > >- qcom,sm8650-dp > > > + - qcom,x1e80100-dp > > >- items: > > >- enum: > > >- qcom,sm8150-dp > > > @@ -73,6 +74,11 @@ properties: > > >- description: phy 0 parent > > >- description: phy 1 parent > > > > > > + is-edp: > > > +$ref: /schemas/types.yaml#/definitions/flag > > > +description: > > > + Tells the controller to switch to eDP mode > > > > > > DP controller cannot be edp, so property "is-edp" is confusing. Probably > > you want to choose some phy mode, so you should rather use "phy-mode" > > property. I am sure we've been here... > > phy-mode belongs in the phy node though. Not that you couldn't look in > the phy node and see, but everyone likes all the properties they need > nicely packaged up in their driver's node. > > > Anyway, if you define completely new property without vendor prefix, > > that's a generic property, so you need to put it in some common schema > > for all Display Controllers, not only Qualcomm. Is there a generic schema for DisplayPort controllers? I think there is none at this point. We can probably add it, declaring is-edp property, link-frequencies, etc. However Mediatek already uses a different option to specify supported link frequencies. > > I'm trying to unsee what the driver is doing... Hard-coding the > connector type and some instance indices. U! I'm sure I'm to blame > for rejecting those in DT. Once this patchset is accepted (in this or that or whatever else form), we will cleanup most of those hardcoded types. > > I've suggested connector nodes in the past. More generally, whatever is > attached at the other end (as it could be a bridge rather than a > connector) knows what mode is needed. It's simple negotiation. Each end > presents what they support. You take the union of the list(s) and get > the mode. If there's more than one, then the kernel or user gets to > choose. It's not that easy. First, probing of the bridge chain differs slightly depending on whether the controller is eDP or DP controller. eDP should use AUX BUS, while DP (currently) doesn't use it. More importantly, error conditions differ too. For example, in the DP case it is perfectly fine to have nothing attached to the controller. It just means that the display chain needs no additional handling and the HPD pin will be handled by the controller itself. In the eDP case if neither a panel nor a bridge are attached, it is considered to be an error and thus the driver will return probe error. > Qualcomm is not the only one with this problem. Solve it for everyone... -- With best wishes Dmitry
Re: [PATCH v4 10/10] drm/vboxvideo: fix mapping leaks
Hi,
On 3/1/24 12:29, Philipp Stanner wrote:
> When the PCI devres API was introduced to this driver, it was wrongly
> assumed that initializing the device with pcim_enable_device() instead
> of pci_enable_device() will make all PCI functions managed.
>
> This is wrong and was caused by the quite confusing PCI devres API in
> which some, but not all, functions become managed that way.
>
> The function pci_iomap_range() is never managed.
>
> Replace pci_iomap_range() with the actually managed function
> pcim_iomap_range().
>
> CC: # v5.10+
> Fixes: 8558de401b5f ("drm/vboxvideo: use managed pci functions")
> Signed-off-by: Philipp Stanner
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede
Since this depends on the pcim_iomap_range() function which is new
in this series and since the vboxvideo code does not see a lot
of changes I think that it would be best for this patch to be
merged through the PCI tree together with the rest of the series.
Regards,
Hans
> ---
> drivers/gpu/drm/vboxvideo/vbox_main.c | 20 +---
> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_main.c
> b/drivers/gpu/drm/vboxvideo/vbox_main.c
> index 42c2d8a99509..d4ade9325401 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_main.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_main.c
> @@ -42,12 +42,11 @@ static int vbox_accel_init(struct vbox_private *vbox)
> /* Take a command buffer for each screen from the end of usable VRAM. */
> vbox->available_vram_size -= vbox->num_crtcs * VBVA_MIN_BUFFER_SIZE;
>
> - vbox->vbva_buffers = pci_iomap_range(pdev, 0,
> - vbox->available_vram_size,
> - vbox->num_crtcs *
> - VBVA_MIN_BUFFER_SIZE);
> - if (!vbox->vbva_buffers)
> - return -ENOMEM;
> + vbox->vbva_buffers = pcim_iomap_range(
> + pdev, 0, vbox->available_vram_size,
> + vbox->num_crtcs * VBVA_MIN_BUFFER_SIZE);
> + if (IS_ERR(vbox->vbva_buffers))
> + return PTR_ERR(vbox->vbva_buffers);
>
> for (i = 0; i < vbox->num_crtcs; ++i) {
> vbva_setup_buffer_context(>vbva_info[i],
> @@ -116,11 +115,10 @@ int vbox_hw_init(struct vbox_private *vbox)
> DRM_INFO("VRAM %08x\n", vbox->full_vram_size);
>
> /* Map guest-heap at end of vram */
> - vbox->guest_heap =
> - pci_iomap_range(pdev, 0, GUEST_HEAP_OFFSET(vbox),
> - GUEST_HEAP_SIZE);
> - if (!vbox->guest_heap)
> - return -ENOMEM;
> + vbox->guest_heap = pcim_iomap_range(pdev, 0,
> + GUEST_HEAP_OFFSET(vbox), GUEST_HEAP_SIZE);
> + if (IS_ERR(vbox->guest_heap))
> + return PTR_ERR(vbox->guest_heap);
>
> /* Create guest-heap mem-pool use 2^4 = 16 byte chunks */
> vbox->guest_pool = devm_gen_pool_create(vbox->ddev.dev, 4, -1,
Re: [PATCH v7 0/6] iio: new DMABUF based API
On Fri, 23 Feb 2024 13:13:58 +0100 Nuno Sa wrote: > Hi Jonathan, likely you're wondering why I'm sending v7. Well, to be > honest, we're hoping to get this merged this for the 6.9 merge window. > Main reason is because the USB part is already in (so it would be nice > to get the whole thing in). Moreover, the changes asked in v6 were simple > (even though I'm not quite sure in one of them) and Paul has no access to > it's laptop so he can't send v7 himself. So he kind of said/asked for me to > do it. So, we are cutting this very fine. If Linus hints strongly at an rc8 maybe we can sneak this in. However, I need an Ack from Vinod for the dma engine changes first. Also I'd love a final 'looks ok' comment from DMABUF folk (Ack even better!) Seems that the other side got resolved in the USB gadget, but last we heard form Daniel and Christian looks to have been back on v5. I'd like them to confirm they are fine with the changes made as a result. I've been happy with the IIO parts for a few versions now but my ability to review the DMABUF and DMA engine bits is limited. A realistic path to get this in is rc8 is happening, is all Acks in place by Wednesday, I get apply it and hits Linux-next Thursday, Pull request to Greg on Saturday and Greg is feeling particularly generous to take one on the day he normally closes his trees. Whilst I'll cross my fingers, looks like 6.10 material to me :( I'd missed the progress on the USB side so wasn't paying enough attention. Sorry! Jonathan > > v6: > * > https://lore.kernel.org/linux-iio/20240129170201.133785-1-p...@crapouillou.net/ > > v7: > - Patch 1 > * 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. > - Patch 2 > * Adapted patch for the changes made in patch 1. > - Patch 5 > * Adapted patch for the changes made in patch 1. > > Patchset based on next-20240223. > > --- > 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/dmabuf_api.rst | 54 +++ > Documentation/iio/index.rst| 2 + > drivers/dma/dma-axi-dmac.c | 40 ++ > drivers/iio/buffer/industrialio-buffer-dma.c | 181 +++- > drivers/iio/buffer/industrialio-buffer-dmaengine.c | 59 ++- > drivers/iio/industrialio-buffer.c | 462 > + > include/linux/dmaengine.h | 27 ++ > include/linux/iio/buffer-dma.h | 31 ++ > include/linux/iio/buffer_impl.h| 33 ++ > include/uapi/linux/iio/buffer.h| 22 + > 10 files changed, 894 insertions(+), 17 deletions(-) > --- > base-commit: 33e1d31873f87d119e5120b88cd350efa68ef276 > change-id: 20240223-iio-dmabuf-5ee0530195ca > -- > > Thanks! > - Nuno Sá >
Re: [PATCH 3/4] drm: xlnx: zynqmp_dpsub: Set input live format
Hi Anatoliy,
kernel test robot noticed the following build warnings:
[auto build test WARNING on bfa4437fd3938ae2e186e7664b2db65bb8775670]
url:
https://github.com/intel-lab-lkp/linux/commits/Anatoliy-Klymenko/drm-xlnx-zynqmp_dpsub-Set-layer-mode-during-creation/20240227-124631
base: bfa4437fd3938ae2e186e7664b2db65bb8775670
patch link:
https://lore.kernel.org/r/20240226-dp-live-fmt-v1-3-b78c3f69c9d8%40amd.com
patch subject: [PATCH 3/4] drm: xlnx: zynqmp_dpsub: Set input live format
config: x86_64-allmodconfig
(https://download.01.org/0day-ci/archive/20240304/202403040104.mwzqu5gs-...@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project
6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240304/202403040104.mwzqu5gs-...@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/202403040104.mwzqu5gs-...@intel.com/
All warnings (new ones prefixed by >>):
drivers/gpu/drm/xlnx/zynqmp_disp.c:164: warning: Function parameter or
struct member 'blend' not described in 'zynqmp_disp'
drivers/gpu/drm/xlnx/zynqmp_disp.c:164: warning: Function parameter or
struct member 'avbuf' not described in 'zynqmp_disp'
drivers/gpu/drm/xlnx/zynqmp_disp.c:164: warning: Function parameter or
struct member 'audio' not described in 'zynqmp_disp'
>> drivers/gpu/drm/xlnx/zynqmp_disp.c:1019: warning: Function parameter or
>> struct member 'bus_format' not described in
>> 'zynqmp_disp_layer_set_live_format'
>> drivers/gpu/drm/xlnx/zynqmp_disp.c:1019: warning: Excess function parameter
>> 'info' description in 'zynqmp_disp_layer_set_live_format'
vim +1019 drivers/gpu/drm/xlnx/zynqmp_disp.c
1009
1010 /**
1011 * zynqmp_disp_layer_set_live_format - Set live layer input format
1012 * @layer: The layer
1013 * @info: Input media bus format
1014 *
1015 * Set the live @layer input bus format. The layer must be disabled.
1016 */
1017 void zynqmp_disp_layer_set_live_format(struct zynqmp_disp_layer *layer,
1018 u32 bus_format)
> 1019 {
1020 int i;
1021 const struct zynqmp_disp_format *fmt;
1022
1023 for (i = 0; i < ARRAY_SIZE(avbuf_live_fmts); ++i) {
1024 fmt = _live_fmts[i];
1025 if (fmt->bus_fmt == bus_format) {
1026 layer->disp_fmt = fmt;
1027 layer->drm_fmt = drm_format_info(fmt->drm_fmt);
1028 zynqmp_disp_avbuf_set_live_format(layer->disp,
layer, fmt);
1029 return;
1030 }
1031 }
1032 }
1033
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [PATCH 1/2] drm/bridge: adv7511: Allow IRQ to share GPIO pins
On Sun, Mar 03, 2024 at 09:44:03AM -0600, Adam Ford wrote:
> On Wed, Feb 28, 2024 at 10:31 AM Laurent Pinchart wrote:
> > On Wed, Feb 28, 2024 at 05:37:35AM -0600, Adam Ford wrote:
> > > The IRQ registration currently assumes that the GPIO is
> > > dedicated to it, but that may not necessarily be the case.
> > > If the board has another device sharing the IRQ, it won't be
> > > registered and the hot-plug detect fails. This is easily
> > > fixed by add the IRQF_SHARED flag.
> > >
> > > Signed-off-by: Adam Ford
> > >
> > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > index b5518ff97165..21f08b2ae265 100644
> > > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > @@ -1318,7 +1318,8 @@ static int adv7511_probe(struct i2c_client *i2c)
> > >
> > > ret = devm_request_threaded_irq(dev, i2c->irq, NULL,
> > > adv7511_irq_handler,
> > > - IRQF_ONESHOT, dev_name(dev),
> > > + IRQF_ONESHOT | IRQF_SHARED,
> > > + dev_name(dev),
> >
> > This looks fine, but the IRQ handler doesn't.
>
> Thanks for the review.
>
> > static int adv7511_irq_process(struct adv7511 *adv7511, bool process_hpd)
> > {
> > unsigned int irq0, irq1;
> > int ret;
> >
> > ret = regmap_read(adv7511->regmap, ADV7511_REG_INT(0), );
> > if (ret < 0)
> > return ret;
> >
> > ret = regmap_read(adv7511->regmap, ADV7511_REG_INT(1), );
> > if (ret < 0)
> > return ret;
>
> If I did a check here and returned if there was no IRQ to handle,
> would that be sufficient?
>
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -477,6 +477,11 @@ 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 handled */
> + if (!(irq0 & (ADV7511_INT0_HPD | ADV7511_INT0_EDID_READY)) &&
> + !(irq1 & ADV7511_INT1_DDC_ERROR))
If these are the only interrupt sources that the driver enables, this is
fine.
> + return -1;
Maybe a defined error code instead ?
> +
> regmap_write(adv7511->regmap, ADV7511_REG_INT(0), irq0);
> regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1);
>
> With this, I would expect adv7511_irq_handler to return IRQ_NONE. If
> you're OK with that approach, I can do that. If you want me to merge
> adv7511_irq_handler, and adv7511_irq_process, I can do that too to
> make the return codes a little more intuitive.
>
> >
> > 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 &&
> > adv7511->bridge.encoder)
> > schedule_work(>hpd_work);
> >
> > if (irq0 & ADV7511_INT0_EDID_READY || irq1 &
> > ADV7511_INT1_DDC_ERROR) {
> > adv7511->edid_read = true;
> >
> > if (adv7511->i2c_main->irq)
> > wake_up_all(>wq);
> > }
> >
> > #ifdef CONFIG_DRM_I2C_ADV7511_CEC
> > adv7511_cec_irq_process(adv7511, irq1);
> > #endif
> >
> > return 0;
> > }
> >
> > static irqreturn_t adv7511_irq_handler(int irq, void *devid)
> > {
> > struct adv7511 *adv7511 = devid;
> > int ret;
> >
> > ret = adv7511_irq_process(adv7511, true);
> > return ret < 0 ? IRQ_NONE : IRQ_HANDLED;
> > }
> >
> > The function will return IRQ_HANDLED as long as the registers can be
> > read, even if they don't report any interrupt.
> >
> > > adv7511);
> > > if (ret)
> > > goto err_unregister_audio;
--
Regards,
Laurent Pinchart
Re: [PATCH 1/2] drm/bridge: adv7511: Allow IRQ to share GPIO pins
On Wed, Feb 28, 2024 at 10:31 AM Laurent Pinchart
wrote:
>
> Hi Adam,
>
> Thank you for the patch.
>
> On Wed, Feb 28, 2024 at 05:37:35AM -0600, Adam Ford wrote:
> > The IRQ registration currently assumes that the GPIO is
> > dedicated to it, but that may not necessarily be the case.
> > If the board has another device sharing the IRQ, it won't be
> > registered and the hot-plug detect fails. This is easily
> > fixed by add the IRQF_SHARED flag.
> >
> > Signed-off-by: Adam Ford
> >
> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > index b5518ff97165..21f08b2ae265 100644
> > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > @@ -1318,7 +1318,8 @@ static int adv7511_probe(struct i2c_client *i2c)
> >
> > ret = devm_request_threaded_irq(dev, i2c->irq, NULL,
> > adv7511_irq_handler,
> > - IRQF_ONESHOT, dev_name(dev),
> > + IRQF_ONESHOT | IRQF_SHARED,
> > + dev_name(dev),
>
> This looks fine, but the IRQ handler doesn't.
Thanks for the review.
>
> static int adv7511_irq_process(struct adv7511 *adv7511, bool process_hpd)
> {
> unsigned int irq0, irq1;
> int ret;
>
> ret = regmap_read(adv7511->regmap, ADV7511_REG_INT(0), );
> if (ret < 0)
> return ret;
>
> ret = regmap_read(adv7511->regmap, ADV7511_REG_INT(1), );
> if (ret < 0)
> return ret;
If I did a check here and returned if there was no IRQ to handle,
would that be sufficient?
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -477,6 +477,11 @@ 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 handled */
+ if (!(irq0 & (ADV7511_INT0_HPD | ADV7511_INT0_EDID_READY)) &&
+ !(irq1 & ADV7511_INT1_DDC_ERROR))
+ return -1;
+
regmap_write(adv7511->regmap, ADV7511_REG_INT(0), irq0);
regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1);
With this, I would expect adv7511_irq_handler to return IRQ_NONE. If
you're OK with that approach, I can do that. If you want me to merge
adv7511_irq_handler, and adv7511_irq_process, I can do that too to
make the return codes a little more intuitive.
adam
>
> 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 && adv7511->bridge.encoder)
> schedule_work(>hpd_work);
>
> if (irq0 & ADV7511_INT0_EDID_READY || irq1 & ADV7511_INT1_DDC_ERROR) {
> adv7511->edid_read = true;
>
> if (adv7511->i2c_main->irq)
> wake_up_all(>wq);
> }
>
> #ifdef CONFIG_DRM_I2C_ADV7511_CEC
> adv7511_cec_irq_process(adv7511, irq1);
> #endif
>
> return 0;
> }
>
> static irqreturn_t adv7511_irq_handler(int irq, void *devid)
> {
> struct adv7511 *adv7511 = devid;
> int ret;
>
> ret = adv7511_irq_process(adv7511, true);
> return ret < 0 ? IRQ_NONE : IRQ_HANDLED;
> }
>
> The function will return IRQ_HANDLED as long as the registers can be
> read, even if they don't report any interrupt.
>
> > adv7511);
> > if (ret)
> > goto err_unregister_audio;
>
> --
> Regards,
>
> Laurent Pinchart
Re: [PATCH] drm/nouveau: keep DMA buffers required for suspend/resume
On Fri, Mar 1, 2024 at 2:23 AM Sid Pranjale wrote: > > Nouveau deallocates a few buffers post GPU init which are required for GPU > suspend/resume to function correctly. > This is likely not as big an issue on systems where the NVGPU is the only > GPU, but on multi-GPU set ups it leads to a regression where the kernel > module errors and results in a system-wide rendering freeze. Were you able to catch this because nvkm_gsp_mem_dtor() now poisons the buffers?
Re: [PATCH] drm/fourcc: Add RGB161616 and BGR161616 formats
Reviewed-by: Simon Ser
Re: [PATCH] drm/nouveau: keep DMA buffers required for suspend/resume
[adding a bunch of list and people as well as Timur Tabi, who authored
the culprit]
Sid Pranjale, thx for the report. FWIW, I'm just replying to add this to
the regression tracking to ensure it does not fall through the cracks.
Nevertheless let me mention two things while at it:
On 29.02.24 18:58, Sid Pranjale wrote:
> Nouveau deallocates a few buffers post GPU init which are required for GPU
> suspend/resume to function correctly.
> This is likely not as big an issue on systems where the NVGPU is the only
> GPU, but on multi-GPU set ups it leads to a regression where the kernel
> module errors and results in a system-wide rendering freeze.
These lines are too long, see
Documentation/process/submitting-patches.rst for details.
> This commit addresses that regression by moving the two buffers required for
> suspend and resume to be deallocated at driver unload instead of post init.
>
> Fixes: 042b5f8 ("drm/nouveau: fix several DMA buffer leaks")
And that should be:
Fixes: 042b5f83841fbf ("drm/nouveau: fix several DMA buffer leaks")
> Signed-off-by: Sid Pranjale
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
> index a64c81385..a73a5b589 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
> @@ -1054,8 +1054,6 @@ r535_gsp_postinit(struct nvkm_gsp *gsp)
> /* Release the DMA buffers that were needed only for boot and init */
> nvkm_gsp_mem_dtor(gsp, >boot.fw);
> nvkm_gsp_mem_dtor(gsp, >libos);
> - nvkm_gsp_mem_dtor(gsp, >rmargs);
> - nvkm_gsp_mem_dtor(gsp, >wpr_meta);
>
> return ret;
> }
> @@ -2163,6 +2161,8 @@ r535_gsp_dtor(struct nvkm_gsp *gsp)
>
> r535_gsp_dtor_fws(gsp);
>
> + nvkm_gsp_mem_dtor(gsp, >rmargs);
> + nvkm_gsp_mem_dtor(gsp, >wpr_meta);
> nvkm_gsp_mem_dtor(gsp, >shm.mem);
> nvkm_gsp_mem_dtor(gsp, >loginit);
> nvkm_gsp_mem_dtor(gsp, >logintr);
To be sure the issue doesn't fall through the cracks unnoticed, I'm
adding it to regzbot, the Linux kernel regression tracking bot:
#regzbot ^introduced 042b5f83841fbf
#regzbot title drm/nouveau: rendering freezes with multi-GPU setup
#regzbot ignore-activity
This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.
Developers: When fixing the issue, remember to add 'Link:' tags pointing
to the report (the parent of this mail). See page linked in footer for
details.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.
[drm-misc:drm-misc-next 12/14] s390-linux-ld: drivers/gpu/drm/panthor/panthor_drv.o:undefined reference to `panthor_device_suspend'
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next head: 216c1282dde38ca87ebdf1ccacee5a0682901574 commit: d72f049087d4f973f6332b599c92177e718107de [12/14] drm/panthor: Allow driver compilation config: s390-allyesconfig (https://download.01.org/0day-ci/archive/20240303/202403031944.eoimq8wk-...@intel.com/config) compiler: s390-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240303/202403031944.eoimq8wk-...@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/202403031944.eoimq8wk-...@intel.com/ All errors (new ones prefixed by >>): >> s390-linux-ld: drivers/gpu/drm/panthor/panthor_drv.o:(.data.rel.ro+0x170): >> undefined reference to `panthor_device_suspend' >> s390-linux-ld: drivers/gpu/drm/panthor/panthor_drv.o:(.data.rel.ro+0x178): >> undefined reference to `panthor_device_resume' -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
[PATCH] nouveau/dmem: handle kcalloc() allocation failure
The kcalloc() in nouveau_dmem_evict_chunk() will return null if
the physical memory has run out. As a result, if we dereference
src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs
will happen.
This patch uses stack variables to replace the kcalloc().
Fixes: 249881232e14 ("nouveau/dmem: evict device private memory during release")
Signed-off-by: Duoming Zhou
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 12feecf71e7..9a578262c6d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -374,13 +374,13 @@ static void
nouveau_dmem_evict_chunk(struct nouveau_dmem_chunk *chunk)
{
unsigned long i, npages = range_len(>pagemap.range) >>
PAGE_SHIFT;
- unsigned long *src_pfns, *dst_pfns;
- dma_addr_t *dma_addrs;
+ unsigned long src_pfns[npages], dst_pfns[npages];
+ dma_addr_t dma_addrs[npages];
struct nouveau_fence *fence;
- src_pfns = kcalloc(npages, sizeof(*src_pfns), GFP_KERNEL);
- dst_pfns = kcalloc(npages, sizeof(*dst_pfns), GFP_KERNEL);
- dma_addrs = kcalloc(npages, sizeof(*dma_addrs), GFP_KERNEL);
+ memset(src_pfns, 0, npages);
+ memset(dst_pfns, 0, npages);
+ memset(dma_addrs, 0, npages);
migrate_device_range(src_pfns, chunk->pagemap.range.start >> PAGE_SHIFT,
npages);
@@ -406,11 +406,8 @@ nouveau_dmem_evict_chunk(struct nouveau_dmem_chunk *chunk)
migrate_device_pages(src_pfns, dst_pfns, npages);
nouveau_dmem_fence_done();
migrate_device_finalize(src_pfns, dst_pfns, npages);
- kfree(src_pfns);
- kfree(dst_pfns);
for (i = 0; i < npages; i++)
dma_unmap_page(chunk->drm->dev->dev, dma_addrs[i], PAGE_SIZE,
DMA_BIDIRECTIONAL);
- kfree(dma_addrs);
}
void
--
2.17.1
Re: [PATCH] drm/fourcc: Add RGB161616 and BGR161616 formats
Hi Jacopo,
Thank you for this patch.
On Mon, 26 Feb 2024 at 13:26, Jacopo Mondi
wrote:
>
> Add FourCC definitions for the 48-bit RGB/BGR formats to the
> DRM/KMS uapi.
>
> The format will be used by the Raspberry Pi PiSP Back End,
> supported by a V4L2 driver in kernel space and by libcamera in
> userspace, which uses the DRM FourCC identifiers.
>
> Signed-off-by: Jacopo Mondi
All the fields look reasonable to me, so:
Reviewed-by: Naushir Patuck
> ---
> drivers/gpu/drm/drm_fourcc.c | 8
> include/uapi/drm/drm_fourcc.h | 4
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 193cf8ed7912..908f20b96fd5 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -210,6 +210,14 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_ABGR2101010, .depth = 30,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_RGBA1010102, .depth = 30,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_BGRA1010102, .depth = 30,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> + { .format = DRM_FORMAT_RGB161616, .depth = 0,
> + .num_planes = 1, .char_per_block = { 6, 0, 0 },
> + .block_w = { 1, 0, 0 }, .block_h = { 1, 0, 0 },
> + .hsub = 1, .vsub = 1, .has_alpha = false },
> + { .format = DRM_FORMAT_BGR161616, .depth = 0,
> + .num_planes = 1, .char_per_block = { 6, 0, 0 },
> + .block_w = { 1, 0, 0 }, .block_h = { 1, 0, 0 },
> + .hsub = 1, .vsub = 1, .has_alpha = false },
> { .format = DRM_FORMAT_ARGB,.depth = 32,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_ABGR,.depth = 32,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_RGBA,.depth = 32,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 84d502e42961..00db00083175 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -210,6 +210,10 @@ extern "C" {
> #define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0') /* [31:0]
> R:G:B:A 10:10:10:2 little endian */
> #define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0') /* [31:0]
> B:G:R:A 10:10:10:2 little endian */
>
> +/* 48 bpp RGB */
> +#define DRM_FORMAT_RGB161616 fourcc_code('R', 'G', '4', '8') /* [47:0] R:G:B
> 16:16:16 little endian */
> +#define DRM_FORMAT_BGR161616 fourcc_code('B', 'G', '4', '8') /* [47:0] B:G:R
> 16:16:16 little endian */
> +
> /* 64 bpp RGB */
> #define DRM_FORMAT_XRGB16161616fourcc_code('X', 'R', '4', '8') /*
> [63:0] x:R:G:B 16:16:16:16 little endian */
> #define DRM_FORMAT_XBGR16161616fourcc_code('X', 'B', '4', '8') /*
> [63:0] x:B:G:R 16:16:16:16 little endian */
> --
> 2.43.0
>
Re: [PATCH] drm/i915: Remove unneeded double drm_rect_visible call in check_overlay_dst
On 2/29/24 15:30, Ville Syrjälä wrote: I prefer the current way where we have no side effects in the if statement. This seem like a valid concern from readability and maintainability standpoint. My patch was aimed mostly at performance and maintainability using tools: some more pedantic analyzers are sensitive to non-checked return values (as of now, drm_rect_intersect is ignored). Would it be a better idea to make an update to the patch with second drm_rect_visible call changed to an appropriately named state flag set with drm_rect_intersect result? BTW, the original patch somehow got mangled while it made its way to the patchwork: source list line in patch got broken, which permits the patch from being applied (the original version did not have that line break). Any ideas how to prevent this happening with the second version of patch (in case the idea is viable)?
Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On Fri, 1 Mar 2024 at 02:27, Nikolai Kondrashov wrote: > > I agree, it's hard to imagine even a simple majority agreeing on how GitLab CI > should be done. Still, we would like to help people, who are interested in > this kind of thing, to set it up. How about we reframe this contribution as a > sort of template, or a reference for people to start their setup with, > assuming that most maintainers would want to tweak it? We would also be glad > to stand by for questions and help, as people try to use it. Ack. I think seeing it as a library for various gitlab CI models would be a lot more palatable. Particularly if you can then show that yes, it is also relevant to our currently existing drm case. So I'm not objecting to having (for example) some kind of CI helper templates - I think a logical place would be in tools/ci/ which is kind of alongside our tools/testing subdirectory. (And then perhaps have a 'gitlab' directory under that. I'm not sure whether - and how much - commonality there might be between the different CI models of different hosts). Just to clarify: when I say "a logical place", I very much want to emphasize the "a" - maybe there are better places, and I'm not saying that is the only possible place. But it sounds more logical to me than some. Linus
Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
Thanks for stopping by, Linus! On 2/29/24 10:21 PM, Linus Torvalds wrote: > On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov wrote: >> >> However, I think a better approach would be *not* to add the .gitlab-ci.yaml >> file in the root of the source tree, but instead change the very same repo >> setting to point to a particular entry YAML, *inside* the repo (somewhere >> under "ci" directory) instead. > > I really don't want some kind of top-level CI for the base kernel project. > > We already have the situation that the drm people have their own ci > model. II'm ok with that, partly because then at least the maintainers > of that subsystem can agree on the rules for that one subsystem. > > I'm not at all interested in having something that people will then > either fight about, or - more likely - ignore, at the top level > because there isn't some global agreement about what the rules are. > > For example, even just running checkpatch is often a stylistic thing, > and not everybody agrees about all the checkpatch warnings. I agree, it's hard to imagine even a simple majority agreeing on how GitLab CI should be done. Still, we would like to help people, who are interested in this kind of thing, to set it up. How about we reframe this contribution as a sort of template, or a reference for people to start their setup with, assuming that most maintainers would want to tweak it? We would also be glad to stand by for questions and help, as people try to use it. > I would suggest the CI project be separate from the kernel. It is possible to have a GitLab CI setup with the YAML files in a separate repository. And we can start with that. However, ultimately I think it's better to have it in the same repo with the code being tested. This way you could submit code changes together with the required tweaks to the CI to keep it passing, making development smoother and faster. With that in mind, and if you agree, where else would you say we could put it? Under "scripts"? Or "Documentation"? And where it would be best for the various subsystems to put theirs? Or could we have the top-level "ci" dir and pile all the different setups there? Or would you like to wait and see how adoption goes, and then decide? > And having that slack channel that is restricted to particular > companies is just another sign of this whole disease. Regarding the Slack channel, we're also on #kernelci on libera.chat, and we have some people there, but if more people start showing up, we'll be spending more time there too. > If you want to make a google/microsoft project to do kernel CI, then > more power to you, but don't expect it to be some kind of agreed-upon > kernel project when it's a closed system. Yes, our Slack is a closed system, unfortunately. However, it's not a part of the proposed CI setup *at all*, and it doesn't depend on Slack. We just like using it, but we're also fine with IRC. GitLab is open-core, and no closed-source software is required for the proposed setup. There is the public gitlab.com where you can deploy your CI, there's also the freedesktop.org instance, and it's possible to set up your own (albeit not easily). Nick
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On 29/02/2024 17:28, Nicolas Dufresne wrote: > Hi, > > Le jeudi 29 février 2024 à 16:16 +0200, Nikolai Kondrashov a écrit : >> On 2/29/24 2:20 PM, Guillaume Tucker wrote: >>> Hello, >>> >>> On 28/02/2024 23:55, Helen Koike wrote: Dear Kernel Community, This patch introduces a `.gitlab-ci` file along with a `ci/` folder, defining a basic test pipeline triggered by code pushes to a GitLab-CI instance. This initial version includes static checks (checkpatch and smatch for now) and build tests across various architectures and configurations. It leverages an integrated cache for efficient build times and introduces a flexible 'scenarios' mechanism for subsystem-specific extensions. >>> >>> This sounds like a nice starting point to me as an additional way >>> to run tests upstream. I have one particular question as I see a >>> pattern through the rest of the email, please see below. >>> >>> [...] >>> 4. **Collaborative Testing Environment:** The kernel community is already engaged in numerous testing efforts, including various GitLab-CI pipelines such as DRM-CI, which I maintain, along with other solutions like KernelCI and BPF-CI. This proposal is designed to further stimulate contributions to the evolving testing landscape. Our goal is to establish a comprehensive suite of common tools and files. >>> >>> [...] >>> **Leveraging External Test Labs:** We can extend our testing to external labs, similar to what DRM-CI currently does. This includes: - Lava labs - Bare metal labs - Using KernelCI-provided labs **Other integrations** - Submit results to KCIDB >>> >>> [...] >>> **Join Our Slack Channel:** We have a Slack channel, #gitlab-ci, on the KernelCI Slack instance https://kernelci.slack.com/ . Feel free to join and contribute to the conversation. The KernelCI team has weekly calls where we also discuss the GitLab-CI pipeline. **Acknowledgments:** A special thanks to Nikolai Kondrashov, Tales da Aparecida - both from Red Hat - and KernelCI community for their valuable feedback and support in this proposal. >>> >>> Where does this fit on the KernelCI roadmap? >>> >>> I see it mentioned a few times but it's not entirely clear >>> whether this initiative is an independent one or in some way >>> linked to KernelCI. Say, are you planning to use the kci tool, >>> new API, compiler toolchains, user-space and Docker images etc? >>> Or, are KernelCI plans evolving to follow this move? >> >> I would say this is an important part of KernelCI the project, considering >> its >> aim to improve testing and CI in the kernel. It's not a part of KernelCI the >> service as it is right now, although I would say it would be good to have >> ability to submit KernelCI jobs from GitLab CI and pull results in the same >> pipeline, as we discussed earlier. Right, I think this needs a bit of disambiguation. The legacy KernelCI system from the Linaro days several years ago is really a service on its own like the many other CIs out there. However, the new KernelCI API and related tooling (kci command line, new web dashboard, modular runtime design etc.) is not that. It's about addressing all the community requirements and that includes being able to run a same test manually in a shell, or in a VM, or automatically from GitLab CI or using a main generic pipeline hosted by KernelCI itself. With this approach, there's no distinction between "the project" and "the service", and as we discussed before there shouldn't even be a distinction with KCIDB. Just KernelCI. However I don't really see this happening, unless I'm missing a part of the story or some upcoming announcement with an updated roadmap. For some reason the old and established paradigm seems unshakeable. The new KernelCI implementation is starting to look just like a refresh of the old one with newer components - which is a huge missed opportunity to really change things IMHO. This may sound like a bit of a tangent, facilitating GitLab CI for the upstream kernel is of course significant progress in any case - no question about that. My comment is more about why it's being driven hand-in-hand with KernelCI in what seems like a diverging direction from KernelCI's announced plans. Why push for a GitLab-centered orchestration when there's a more universal solution being proposed by the project? I would find it easier to understand - and I sense I'm not the only one here reading the thread - if KernelCI wasn't mentioned that many times in the cover letter and if the scripts didn't have KCI_* in so many places, basically if this was clearly an independent initiative such as KUnit, 0-day or regzbot. > I'd like to add that both CI have a different purpose in the Linux project. > This > CI work is a pre-merge verification. Everyone needs to run checkpatch and >
Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On 3/1/24 4:07 PM, Mark Brown wrote: On Fri, Mar 01, 2024 at 12:27:13PM +0200, Nikolai Kondrashov wrote: On 2/29/24 10:21 PM, Linus Torvalds wrote: I would suggest the CI project be separate from the kernel. It is possible to have a GitLab CI setup with the YAML files in a separate repository. And we can start with that. However, ultimately I think it's better to have it in the same repo with the code being tested. This way you could submit code changes together with the required tweaks to the CI to keep it passing, making development smoother and faster. With that in mind, and if you agree, where else would you say we could put it? Under "scripts"? Or "Documentation"? And where it would be best for the various subsystems to put theirs? Or could we have the top-level "ci" dir and pile all the different setups there? Or would you like to wait and see how adoption goes, and then decide? If we were going to put bits of this in tree how about something like tools/testing/forges? I'd hope that things could be shared by multiple services, if not we could always have subdirs I guess. We could put glue bits like defining how to run kunit, checkpatch or whatever with these systems in there so people can share figuring that bit out. Individual trees or CI systems using these forge based systems could then reference these files when defining what specific tests they want to run when which seems more like where the differences will be. I'm not super familiar with this stuff, the above is based on it looking like there's an OK degree of separation between the "what to run" and "how to run" bits. I might be misreading things, and it's not clear to me how often it'll be useful to be able to update things in tree. Yes, facilitating reuse and collaboration between CI setups, even if they're largely different, is another good reason to have it inside the kernel repo. Nick
[PATCH 1/2] dt-bindings: backlight: Add Texas Instruments LM3509 bindings
Add Device Tree bindings for Texas Instruments LM3509 - a
High Efficiency Boost for White LED's and/or OLED Displays
Signed-off-by: Patrick Gansterer
---
.../bindings/leds/backlight/ti,lm3509.yaml| 81 +++
1 file changed, 81 insertions(+)
create mode 100644
Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml
diff --git a/Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml
b/Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml
new file mode 100644
index ..8fbb83934e30
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/ti,lm3509.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI LM3509 High Efficiency Boost for White LED's and/or OLED Displays
+
+maintainers:
+ - Patrick Gansterer
+
+description: |
+ The LM3509 current mode boost converter offers two separate outputs.
+ https://www.ti.com/product/LM3509
+
+properties:
+ compatible:
+const: ti,lm3509
+
+ reg:
+maxItems: 1
+
+ reset-gpios:
+maxItems: 1
+
+ default-brightness:
+minimum: 0
+maximum: 15
+
+ max-brightness:
+minimum: 0
+maximum: 15
+
+ ti,brightness-rate-of-change-us:
+description: Brightness Rate of Change in microseconds.
+enum: [51, 13000, 26000, 52000]
+
+ ti,oled-mode:
+description: Enable OLED mode.
+type: boolean
+
+ ti,unison-mode:
+description: |
+ Enable unison mode. If disabled, then it will provide two
+ independent controllable LED currents for BMAIN and BSUB.
+type: boolean
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+backlight@36 {
+compatible = "ti,lm3509";
+reg = <0x36>;
+
+reset-gpios = < 5 GPIO_ACTIVE_LOW>;
+
+ti,unison-mode;
+};
+};
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+backlight@36 {
+compatible = "ti,lm3509";
+reg = <0x36>;
+
+ti,brightness-rate-of-change-us = <52000>;
+};
+};
--
2.44.0
[PATCH 2/2] backlight: Add new lm3509 backlight driver
This is a general driver for LM3509 backlight chip of TI.
LM3509 is High Efficiency Boost for White LEDs and/or OLED Displays with
Dual Current Sinks. This driver supports OLED/White LED select, brightness
control and sub/main control.
The datasheet can be found at http://www.ti.com/product/lm3509.
Signed-off-by: Patrick Gansterer
---
drivers/video/backlight/Kconfig | 7 +
drivers/video/backlight/Makefile| 1 +
drivers/video/backlight/lm3509_bl.c | 247
3 files changed, 255 insertions(+)
create mode 100644 drivers/video/backlight/lm3509_bl.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index ea2d0d69bd8c..96ad5dc584b6 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -366,6 +366,13 @@ config BACKLIGHT_AAT2870
If you have a AnalogicTech AAT2870 say Y to enable the
backlight driver.
+config BACKLIGHT_LM3509
+ tristate "Backlight Driver for LM3509"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ This supports TI LM3509 Backlight Driver
+
config BACKLIGHT_LM3630A
tristate "Backlight Driver for LM3630A"
depends on I2C && PWM
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 06966cb20459..51a4ac5d0530 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_BACKLIGHT_HP700) += jornada720_bl.o
obj-$(CONFIG_BACKLIGHT_IPAQ_MICRO) += ipaq_micro_bl.o
obj-$(CONFIG_BACKLIGHT_KTD253) += ktd253-backlight.o
obj-$(CONFIG_BACKLIGHT_KTZ8866)+= ktz8866.o
+obj-$(CONFIG_BACKLIGHT_LM3509) += lm3509_bl.o
obj-$(CONFIG_BACKLIGHT_LM3533) += lm3533_bl.o
obj-$(CONFIG_BACKLIGHT_LM3630A)+= lm3630a_bl.o
obj-$(CONFIG_BACKLIGHT_LM3639) += lm3639_bl.o
diff --git a/drivers/video/backlight/lm3509_bl.c
b/drivers/video/backlight/lm3509_bl.c
new file mode 100644
index ..977145374641
--- /dev/null
+++ b/drivers/video/backlight/lm3509_bl.c
@@ -0,0 +1,247 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LM3509_NAME "lm3509_bl"
+
+#define LM3509_DEF_BRIGHTNESS 0x12
+#define LM3509_MAX_BRIGHTNESS 0x1F
+
+#define REG_GP 0x10
+#define REG_BMAIN 0xA0
+#define REG_BSUB 0xB0
+#define REG_MAX 0xFF
+
+enum {
+ REG_GP_ENM_BIT = 0,
+ REG_GP_ENS_BIT,
+ REG_GP_UNI_BIT,
+ REG_GP_RMP0_BIT,
+ REG_GP_RMP1_BIT,
+ REG_GP_OLED_BIT,
+};
+
+struct lm3509_bl {
+ struct regmap *regmap;
+ struct backlight_device *bl_main;
+ struct backlight_device *bl_sub;
+ struct gpio_desc *reset_gpio;
+};
+
+static void lm3509_reset(struct lm3509_bl *data)
+{
+ if (data->reset_gpio) {
+ gpiod_set_value(data->reset_gpio, 1);
+ udelay(1);
+ gpiod_set_value(data->reset_gpio, 0);
+ udelay(10);
+ }
+}
+
+static int lm3509_update_status(struct backlight_device *bl,
+ unsigned int en_mask, unsigned int br_reg)
+{
+ struct lm3509_bl *data = bl_get_data(bl);
+ int ret;
+ bool en;
+
+ ret = regmap_write(data->regmap, br_reg, bl->props.brightness);
+ if (ret < 0)
+ return ret;
+
+ en = bl->props.power <= FB_BLANK_NORMAL;
+ return regmap_update_bits(data->regmap, REG_GP, en_mask,
+ en ? en_mask : 0);
+}
+
+static int lm3509_main_update_status(struct backlight_device *bl)
+{
+ return lm3509_update_status(bl, BIT(REG_GP_ENM_BIT), REG_BMAIN);
+}
+
+static const struct backlight_ops lm3509_main_ops = {
+ .options = BL_CORE_SUSPENDRESUME,
+ .update_status = lm3509_main_update_status,
+};
+
+static int lm3509_sub_update_status(struct backlight_device *bl)
+{
+ return lm3509_update_status(bl, BIT(REG_GP_ENS_BIT), REG_BSUB);
+}
+
+static const struct backlight_ops lm3509_sub_ops = {
+ .options = BL_CORE_SUSPENDRESUME,
+ .update_status = lm3509_sub_update_status,
+};
+
+static struct backlight_device *lm3509_backlight_register(
+ struct device *dev, const char *name_suffix, struct lm3509_bl *data,
+ const struct backlight_ops *ops, int brightness, int max_brightness)
+
+{
+ struct backlight_device *bd;
+ struct backlight_properties props;
+ char name[64];
+
+ memset(, 0, sizeof(props));
+ props.type = BACKLIGHT_RAW;
+ props.brightness = brightness;
+ props.max_brightness = max_brightness;
+ props.power = brightness > 0 ? FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
+
+ snprintf(name, sizeof(name), "lm3509-%s-%s", dev_name(dev),
+name_suffix);
+
+ bd = devm_backlight_device_register(dev, name, dev, data, ops, );
+ if (bd)
+ backlight_update_status(bd);
+
+ return bd;
+}
+
+static
Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On Sun, Mar 3, 2024 at 3:30 AM Randy Dunlap wrote:
> On 3/2/24 14:10, Guenter Roeck wrote:
> > On Thu, Feb 29, 2024 at 12:21 PM Linus Torvalds
> > wrote:
> >> On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov wrote:
> >>>
> >>> However, I think a better approach would be *not* to add the
> >>> .gitlab-ci.yaml
> >>> file in the root of the source tree, but instead change the very same repo
> >>> setting to point to a particular entry YAML, *inside* the repo (somewhere
> >>> under "ci" directory) instead.
> >>
> >> I really don't want some kind of top-level CI for the base kernel project.
> >>
> >> We already have the situation that the drm people have their own ci
> >> model. II'm ok with that, partly because then at least the maintainers
> >> of that subsystem can agree on the rules for that one subsystem.
> >>
> >> I'm not at all interested in having something that people will then
> >> either fight about, or - more likely - ignore, at the top level
> >> because there isn't some global agreement about what the rules are.
> >>
> >> For example, even just running checkpatch is often a stylistic thing,
> >> and not everybody agrees about all the checkpatch warnings.
> >
> > While checkpatch is indeed of arguable value, I think it would help a
> > lot not having to bother about the persistent _build_ failures on
> > 32-bit systems. You mentioned the fancy drm CI system above, but they
> > don't run tests and not even test builds on 32-bit targets, which has
> > repeatedly caused (and currently does cause) build failures in drm
> > code when trying to build, say, arm:allmodconfig in linux-next. Most
> > trivial build failures in linux-next (and, yes, sometimes mainline)
> > could be prevented with a simple generic CI.
>
> Yes, definitely. Thanks for bringing that up.
+1
> > Sure, argue against checkpatch as much as you like, but the code
> > should at least _build_, and it should not be necessary for random
> > people to report build failures to the submitters.
>
> I do 110 randconfig builds nightly (10 each of 11 $ARCH/$BITS).
> That's about all the horsepower that I have. and I am not a CI. :)
>
> So I see quite a bit of what you are saying. It seems that Arnd is
> in the same boat.
You don't even have to do your own builds (although it does help),
and can look at e.g. http://kisskb.ellerman.id.au/kisskb/
Kisskb can send out email when builds get broken, and when they get
fixed again. I receive such emails for the m68k builds.
I have the feeling this is not used up to its full potential yet.
My initial plan with the "Build regressions/improvements in ..." emails
[1] was to fully automate this, and enable it for the other daily builds
(e.g. linux-next), too, but there are only so many hours in a day...
[1] https://lore.kernel.org/all/20240226081253.3688538-1-ge...@linux-m68k.org/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
