* [PATCH v2 0/3] Add support for Emcraft Systems NavQ+ kit
From: Gilles Talis @ 2024-03-30 13:34 UTC (permalink / raw)
To: devicetree, imx, linux-arm-kernel
Cc: conor+dt, krzysztof.kozlowski+dt, robh, shawnguo, festevam, alex,
andrew, Gilles Talis
Hello
This series adds a device tree file for the Emcraft Systems NavQ+ kit [1]
The first patch adds a new vendor prefix for Emcraft Systems
The second one adds the board to the arm/fsl.yaml DT bindings.
Last patch adds device tree file for the kit.
[1] https://www.emcraft.com/products/1222
Changes in v2:
- Add Acked-by review tags
- Fixed device tree warnings reported by dtbs_check
- Reworked leds node
- Remove unused i2c6 pinctrl entry
- Removed unused regulator node in Ethernet entry
- Link to v1: https://lore.kernel.org/imx/20240328202320.187596-1-gilles.talis@gmail.com/
---
Gilles Talis (3):
dt-bindings: vendor-prefixes: Add Emcraft Systems
dt-bindings: arm: Add Emcraft Systems i.MX8M Plus NavQ+ Kit
arm64: dts: freescale: Add device tree for Emcraft Systems NavQ+ Kit
.../devicetree/bindings/arm/fsl.yaml | 1 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../arm64/boot/dts/freescale/imx8mp-navqp.dts | 424 ++++++++++++++++++
4 files changed, 428 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-navqp.dts
base-commit: 4cece764965020c22cff7665b18a012006359095
--
2.39.2
^ permalink raw reply
* [net-next,v2] dt-bindings: net: renesas,ethertsn: Create child-node for MDIO bus
From: Niklas Söderlund @ 2024-03-30 13:12 UTC (permalink / raw)
To: Sergey Shtylyov, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, netdev, devicetree
Cc: linux-renesas-soc, Niklas Söderlund, Rob Herring
The bindings for Renesas Ethernet TSN was just merged in v6.9 and the
design for the bindings followed that of other Renesas Ethernet drivers
and thus did not force a child-node for the MDIO bus. As there
are no upstream drivers or users of this binding yet take the
opportunity to correct this and force the usage of a child-node for the
MDIO bus.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Rob Herring <robh@kernel.org>
---
* Changes since v1
- Expand on history in commit message.
Hello,
The Ethernet TSN driver is still in review and have not been merged and
no usage of the bindings are merged either. So while this breaks the
binding it effects no one. So we can correct this mistake without
breaking any use-cases before we need to support any backward
compatibility.
---
.../bindings/net/renesas,ethertsn.yaml | 33 ++++++++-----------
1 file changed, 14 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/renesas,ethertsn.yaml b/Documentation/devicetree/bindings/net/renesas,ethertsn.yaml
index ea35d19be829..b4680a1d0a06 100644
--- a/Documentation/devicetree/bindings/net/renesas,ethertsn.yaml
+++ b/Documentation/devicetree/bindings/net/renesas,ethertsn.yaml
@@ -71,16 +71,8 @@ properties:
enum: [0, 2000]
default: 0
- '#address-cells':
- const: 1
-
- '#size-cells':
- const: 0
-
-patternProperties:
- "^ethernet-phy@[0-9a-f]$":
- type: object
- $ref: ethernet-phy.yaml#
+ mdio:
+ $ref: /schemas/net/mdio.yaml#
unevaluatedProperties: false
required:
@@ -94,8 +86,7 @@ required:
- resets
- phy-mode
- phy-handle
- - '#address-cells'
- - '#size-cells'
+ - mdio
additionalProperties: false
@@ -122,14 +113,18 @@ examples:
tx-internal-delay-ps = <2000>;
phy-handle = <&phy3>;
- #address-cells = <1>;
- #size-cells = <0>;
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
- phy3: ethernet-phy@3 {
- compatible = "ethernet-phy-ieee802.3-c45";
- reg = <0>;
- interrupt-parent = <&gpio4>;
- interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
reset-gpios = <&gpio1 23 GPIO_ACTIVE_LOW>;
+ reset-post-delay-us = <4000>;
+
+ phy3: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+ };
};
};
--
2.44.0
^ permalink raw reply related
* Re: [PATCH 3/3] arm64: dts: rockchip: Remove UART2 from RGB30
From: Ahmad Fatoum @ 2024-03-30 13:13 UTC (permalink / raw)
To: Chris Morgan, linux-rockchip
Cc: linux-clk, devicetree, sboyd, mturquette, heiko, conor+dt,
krzysztof.kozlowski+dt, robh+dt, Chris Morgan
In-Reply-To: <20231018153357.343142-4-macroalpha82@gmail.com>
Hello Chris,
On 18.10.23 17:33, Chris Morgan wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> The Powkiddy RGB30 has no onboard UART header, so remove the reference
> to it in the device tree. This was left on by mistake in the initial
> commit.
Do you know if the UART is perhaps available over testpoints?
If yes, having a DT-overlay upstream enabling it along with documentation could be useful.
If not, how do you do low-level debugging on the RBG30 in absence of the serial console?
Thanks,
Ahmad
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> ---
> arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb30.dts | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb30.dts b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb30.dts
> index 3ebc21608213..1ead3c5c24b3 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb30.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-powkiddy-rgb30.dts
> @@ -64,6 +64,10 @@ simple-audio-card,cpu {
>
> /delete-node/ &adc_keys;
>
> +&chosen {
> + /delete-property/ stdout-path;
> +};
> +
> &cru {
> assigned-clocks = <&pmucru CLK_RTC_32K>, <&cru PLL_GPLL>,
> <&pmucru PLL_PPLL>, <&cru PLL_VPLL>;
> @@ -149,4 +153,9 @@ rk817_charger: charger {
> };
> };
>
> +/* There is no UART header visible on the board for this device. */
> +&uart2 {
> + status = "disabled";
> +};
> +
> /delete-node/ &vibrator;
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: adc: Document XuanTie TH1520 ADC
From: kernel test robot @ 2024-03-30 11:58 UTC (permalink / raw)
To: wefu, jszhang, guoren, conor, robh, krzysztof.kozlowski+dt,
paul.walmsley, palmer, aou, jic23, lars, andriy.shevchenko,
nuno.sa, marcelo.schmitt, bigunclemax, marius.cristea, fr0st61te,
okan.sahin, marcus.folkesson, schnelle, lee, mike.looijmans
Cc: oe-kbuild-all, linux-riscv, devicetree, linux-kernel, linux-iio,
Wei Fu
In-Reply-To: <20240329200241.4122000-4-wefu@redhat.com>
Hi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on jic23-iio/togreg]
[also build test WARNING on robh/for-next linus/master v6.9-rc1 next-20240328]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/wefu-redhat-com/drivers-iio-adc-Add-XuanTie-TH1520-ADC-driver/20240330-041029
base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
patch link: https://lore.kernel.org/r/20240329200241.4122000-4-wefu%40redhat.com
patch subject: [PATCH 3/3] dt-bindings: adc: Document XuanTie TH1520 ADC
compiler: loongarch64-linux-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20240330/202403301900.9wSnTE6y-lkp@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 <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202403301900.9wSnTE6y-lkp@intel.com/
dtcheck warnings: (new ones prefixed by >>)
>> Documentation/devicetree/bindings/iio/adc/thead,th1520.yaml:45:1: [error] syntax error: found character '\t' that cannot start any token (syntax)
--
>> Documentation/devicetree/bindings/iio/adc/thead,th1520.yaml:45:1: found a tab character where an indentation space is expected
--
>> Documentation/devicetree/bindings/iio/adc/thead,th1520.yaml: ignoring, error parsing file
vim +45 Documentation/devicetree/bindings/iio/adc/thead,th1520.yaml
41
42 examples:
43 - |
44 adc: adc@0xfffff51000 {
> 45 compatible = "thead,th1520-adc";
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [v1 0/3] Add i.MX8Q HSIO PHY driver support
From: Krzysztof Kozlowski @ 2024-03-30 11:55 UTC (permalink / raw)
To: Richard Zhu, vkoul, kishon, robh+dt, krzysztof.kozlowski+dt,
conor+dt, frank.li
Cc: linux-phy, devicetree, linux-arm-kernel, linux-kernel, kernel,
linux-imx
In-Reply-To: <1711699790-16494-1-git-send-email-hongxing.zhu@nxp.com>
On 29/03/2024 09:09, Richard Zhu wrote:
> v1 changes:
> - Rebase to the 6.9-rc1, and constify of_phandle_args in xlate.
> No other changes.
>
I found some RFC of this... confusing so:
1. v1 is the first version. If you send RFC, that RFC is v1, so anything
newer is v2 or whatever.
2. One patchset per 24h. Give people chance to actually review your code.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: display/msm: sm8150-mdss: add DP node
From: Krzysztof Kozlowski @ 2024-03-30 11:52 UTC (permalink / raw)
To: Dmitry Baryshkov, Rob Clark, Abhinav Kumar, Sean Paul,
Marijn Suijten, David Airlie, Daniel Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Vinod Koul
Cc: linux-arm-msm, dri-devel, freedreno, devicetree
In-Reply-To: <966deb7d-847f-451b-8f93-017d703b50c3@linaro.org>
On 27/03/2024 11:11, Krzysztof Kozlowski wrote:
> On 26/03/2024 21:02, Dmitry Baryshkov wrote:
>> As Qualcomm SM8150 got support for the DisplayPort, add displayport@
>> node as a valid child to the MDSS node.
>>
>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>> ---
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
If there is going to be resend, please switch to "contains" and only
sm8150 compatible just like:
https://lore.kernel.org/all/20240329-sm6350-dp-v2-2-e46dceb32ef5@fairphone.com/
(but no need to resend just for that)
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: display: msm: sm6350-mdss: document DP controller subnode
From: Krzysztof Kozlowski @ 2024-03-30 11:49 UTC (permalink / raw)
To: Luca Weiss, Rob Clark, Abhinav Kumar, Dmitry Baryshkov, Sean Paul,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kuogee Hsieh,
Krishna Manikandan, Bjorn Andersson, Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel
In-Reply-To: <20240329-sm6350-dp-v2-2-e46dceb32ef5@fairphone.com>
On 29/03/2024 08:45, Luca Weiss wrote:
> Document the displayport controller subnode of the SM6350 MDSS.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 2/5] soc: qcom: llcc: Add regmap for Broadcast_AND region
From: Krzysztof Kozlowski @ 2024-03-30 11:46 UTC (permalink / raw)
To: Unnathi Chalicheemala, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, kernel
In-Reply-To: <20240329-llcc-broadcast-and-v4-2-107c76fd8ceb@quicinc.com>
On 29/03/2024 22:53, Unnathi Chalicheemala wrote:
> Define new regmap structure for Broadcast_AND region and initialize
> this regmap when HW block version is greater than 4.1, otherwise
> initialize as a NULL pointer for backwards compatibility.
>
> + struct regmap *regmap;
> u32 act_ctrl_reg;
> u32 act_clear_reg;
> u32 status_reg;
> @@ -849,7 +850,8 @@ static int llcc_update_act_ctrl(u32 sid,
> return ret;
>
> if (drv_data->version >= LLCC_VERSION_4_1_0_0) {
> - ret = regmap_read_poll_timeout(drv_data->bcast_regmap, status_reg,
> + regmap = drv_data->bcast_and_regmap ?: drv_data->bcast_regmap;
> + ret = regmap_read_poll_timeout(regmap, status_reg,
> slice_status, (slice_status & ACT_COMPLETE),
> 0, LLCC_STATUS_READ_DELAY);
> if (ret)
> @@ -1284,6 +1286,16 @@ static int qcom_llcc_probe(struct platform_device *pdev)
>
> drv_data->version = version;
>
> + /* Applicable only when drv_data->version >= 4.1 */
> + drv_data->bcast_and_regmap = qcom_llcc_init_mmio(pdev, i + 1, "llcc_broadcast_and_base");
> + if (IS_ERR(drv_data->bcast_and_regmap)) {
I am pretty sure this breaks all users. Can you please explain how do
you maintain ABI and that IS_ERR() is applied only for version >= 4.1?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: arm: msm: Add llcc Broadcast_AND register
From: Krzysztof Kozlowski @ 2024-03-30 11:44 UTC (permalink / raw)
To: Unnathi Chalicheemala, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, kernel
In-Reply-To: <20240329-llcc-broadcast-and-v4-1-107c76fd8ceb@quicinc.com>
On 29/03/2024 22:53, Unnathi Chalicheemala wrote:
> The LLCC block in SM8450, SM8550 and SM8650 have a new register
> space for Broadcast_AND region. This is used to check that all
> channels have bit set to "1", mainly in SCID activation/deactivation.
>
> Previously we were mapping only the Broadcast_OR region assuming
> there was only one broadcast register region. Now we also map
> Broadcast_AND region.
>
> Signed-off-by: Unnathi Chalicheemala <quic_uchalich@quicinc.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
This is an automated instruction, just in case, because many review tags
are being ignored. If you know the process, you can skip it (please do
not feel offended by me posting it here - no bad intentions intended).
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, under or above your Signed-off-by tag. Tag is "received", when
provided in a message replied to you on the mailing list. Tools like b4
can help here. However, there's no need to repost patches *only* to add
the tags. The upstream maintainer will do that for tags received on the
version they apply.
https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 0/5] LLCC: Support for Broadcast_AND region
From: Krzysztof Kozlowski @ 2024-03-30 11:42 UTC (permalink / raw)
To: Unnathi Chalicheemala, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, kernel
In-Reply-To: <20240329-llcc-broadcast-and-v4-0-107c76fd8ceb@quicinc.com>
On 29/03/2024 22:53, Unnathi Chalicheemala wrote:
> This series adds:
> 1. Device tree register mapping for Broadcast_AND region in SM8450,
> SM8550, SM8650.
> 2. LLCC driver updates to reflect addition of Broadcast_AND regmap.
>
> To support CSR programming, a broadcast interface is used to program all
> channels in a single command. Until SM8450 there was only one broadcast
> region (Broadcast_OR) used to broadcast write and check for status bit
> 0. From SM8450 onwards another broadcast region (Broadcast_AND) has been
> added which checks for status bit 1.
>
> This series updates the device trees from SM8450 onwards to have a
> mapping to this Broadcast_AND region. It also updates the llcc_drv_data
> structure with a regmap for Broadcast_AND region and corrects the
> broadcast region used to check for status bit 1.
Your way of sending patches makes it difficult for us to review them.
b4 diff -C '<20240329-llcc-broadcast-and-v4-0-107c76fd8ceb@quicinc.com>'
Grabbing thread from
lore.kernel.org/all/20240329-llcc-broadcast-and-v4-0-107c76fd8ceb@quicinc.com/t.mbox.gz
Checking for older revisions
Added from v3: 5 patches
---
Analyzing 39 messages in the thread
Preparing fake-am for v3: dt-bindings: arm: msm: Add llcc Broadcast_AND
register
ERROR: v3 series incomplete; unable to create a fake-am range
---
Could not create fake-am range for lower series v3
Please reach internally within Qualcomm to get some guidance how to
properly set up your work environment.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 5/5] cadence-xspi: Add xfer capabilities
From: Krzysztof Kozlowski @ 2024-03-30 11:37 UTC (permalink / raw)
To: Witold Sadowski, linux-kernel, linux-spi, devicetree
Cc: broonie, robh, krzysztof.kozlowski+dt, conor+dt, pthombar
In-Reply-To: <20240329194849.25554-6-wsadowski@marvell.com>
On 29/03/2024 20:48, Witold Sadowski wrote:
> Add support for iMRVL xfer hw_overlay of Cadence xSPI
> block.
> MRVL Xfer overlay extend xSPI capabilities, to support
> non-memory SPI operations.
> With generic xSPI command it allows to create any
> required SPI transaction
Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching.
Please wrap commit message according to Linux coding style / submission
process (neither too early nor over the limit):
https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
... and build your code because this does not compile. :(
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/5] driver: spi: cadence: Add ACPI support
From: Krzysztof Kozlowski @ 2024-03-30 11:36 UTC (permalink / raw)
To: Witold Sadowski, linux-kernel, linux-spi, devicetree
Cc: broonie, robh, krzysztof.kozlowski+dt, conor+dt, pthombar,
Piyush Malgujar
In-Reply-To: <20240329194849.25554-5-wsadowski@marvell.com>
On 29/03/2024 20:48, Witold Sadowski wrote:
> From: Piyush Malgujar <pmalgujar@marvell.com>
>
> These changes enables to read the configs from ACPI tables as
> required for successful probing in ACPI uefi environment.
> In case of ACPI disabled/dts based environment, it will continue to
> read configs from dts as before.
>
Random subjects... Please use subject prefixes matching the subsystem.
You can get them for example with `git log --oneline --
DIRECTORY_OR_FILE` on the directory your patch is touching.
> }
>
> +static const struct acpi_device_id cdns_xspi_acpi_match[] = {
> + {"cdns,xspi-nor", 0},
> + {"mrvl,xspi-nor", 0},
How is this ACPI?
> + {},
> +};
> +MODULE_DEVICE_TABLE(acpi, cdns_xspi_acpi_match);
> +#ifdef CONFIG_OF
This was never compiled. I could understand not testing bindings,
because it is something relatively new - like 5 or 6 years. But not
compiling code is less understandable.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/5] spi: cadence: Add Marvell IP modification changes
From: Krzysztof Kozlowski @ 2024-03-30 11:33 UTC (permalink / raw)
To: Witold Sadowski, linux-kernel, linux-spi, devicetree
Cc: broonie, robh, krzysztof.kozlowski+dt, conor+dt, pthombar
In-Reply-To: <20240329194849.25554-3-wsadowski@marvell.com>
On 29/03/2024 20:48, Witold Sadowski wrote:
> Add support for Marvell IP modification - clock divider,
> and PHY config, and IRQ clearing.
> Clock divider block is build into Cadence XSPI controller
> and is connected directly to 800MHz clock.
> As PHY config is not set directly in IP block, driver can
> load custom PHY configuration values.
> To correctly clear interrupt in Marvell implementation
> MSI-X must be cleared too.
Please wrap commit message according to Linux coding style / submission
process (neither too early nor over the limit):
https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
>
> Signed-off-by: Witold Sadowski <wsadowski@marvell.com>
> ---
> +
> +static bool cdns_xspi_get_hw_overlay(struct platform_device *pdev)
> +{
> + int err;
> +
> + err = device_property_match_string(&pdev->dev,
> + "compatible", "mrvl,xspi-nor");
No, do not add matching in some random parts of the code, but use driver
match/data from ID table.
....
>
> + cdns_xspi_print_phy_config(cdns_xspi);
> ret = cdns_xspi_controller_init(cdns_xspi);
> if (ret) {
> dev_err(dev, "Failed to initialize controller\n");
> @@ -613,6 +911,9 @@ static const struct of_device_id cdns_xspi_of_match[] = {
> {
> .compatible = "cdns,xspi-nor",
> },
> + {
> + .compatible = "mrvl,xspi-nor",
This falsely suggest they are compatible :/
> + },
> { /* end of table */}
> };
> MODULE_DEVICE_TABLE(of, cdns_xspi_of_match);
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/5] spi: cadence: Add new bindings documentation for Cadence XSPI
From: Krzysztof Kozlowski @ 2024-03-30 11:32 UTC (permalink / raw)
To: Witold Sadowski, linux-kernel, linux-spi, devicetree
Cc: broonie, robh, krzysztof.kozlowski+dt, conor+dt, pthombar
In-Reply-To: <20240329194849.25554-2-wsadowski@marvell.com>
On 29/03/2024 20:48, Witold Sadowski wrote:
> Add new bindings:
> - mrvl,xspi-nor compatible string
> Compatible string to enable Marvell XSPI modification
> - Multiple PHY configuration registers
> - base for xfer register set
>
> Signed-off-by: Witold Sadowski <wsadowski@marvell.com>
Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching.
> ---
> .../devicetree/bindings/spi/cdns,xspi.yaml | 84 ++++++++++++++++++-
> 1 file changed, 83 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/spi/cdns,xspi.yaml b/Documentation/devicetree/bindings/spi/cdns,xspi.yaml
> index eb0f92468185..d1fde8d4e9b8 100644
> --- a/Documentation/devicetree/bindings/spi/cdns,xspi.yaml
> +++ b/Documentation/devicetree/bindings/spi/cdns,xspi.yaml
> @@ -20,23 +20,74 @@ allOf:
>
> properties:
> compatible:
> - const: cdns,xspi-nor
> + - const: cdns,xspi-nor
> + - const: mrvl,xspi-nor
It does not look like you tested the bindings, at least after quick
look. Please run `make dt_binding_check` (see
Documentation/devicetree/bindings/writing-schema.rst for instructions).
Maybe you need to update your dtschema and yamllint.
There is a lot of things happening here, but I won't perform review if
the code was never tested. Sorry, please test before sending.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/9] arm64: dts: rockchip: Add cpu regulators and vcc5v0_sys to Khadas Edge 2
From: efectn @ 2024-03-30 11:25 UTC (permalink / raw)
To: heiko
Cc: conor+dt, devicetree, efectn, krzysztof.kozlowski+dt,
linux-arm-kernel, linux-kernel, linux-rockchip, robh+dt,
sebastian.reichel
In-Reply-To: <5a7bd2cd8703e51382abfc11242de59d45286477.1708381247.git.efectn@protonmail.com>
Hi Heiko,
Sorry if i bother you. Can you review the series? If there is a problem i will send the v2.
^ permalink raw reply
* Re: [PATCH v5 4/5] clk: qcom: ipq9574: Use icc-clk for enabling NoC related clocks
From: Varadarajan Narayanan @ 2024-03-30 11:17 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Stephen Boyd, andersson, conor+dt, devicetree, djakov,
dmitry.baryshkov, konrad.dybcio, krzysztof.kozlowski+dt,
linux-arm-msm, linux-clk, linux-kernel, linux-pm, mturquette,
quic_anusha, robh
In-Reply-To: <5570c921-0103-4e92-be9a-da9c1b7cbd79@linaro.org>
On Sat, Mar 30, 2024 at 11:28:09AM +0100, Krzysztof Kozlowski wrote:
> On 30/03/2024 10:30, Varadarajan Narayanan wrote:
> > On Fri, Mar 29, 2024 at 01:10:03PM +0100, Krzysztof Kozlowski wrote:
> >> On 29/03/2024 11:55, Varadarajan Narayanan wrote:
> >>>>> +
> >>>>> +enum {
> >>>>> + ICC_ANOC_PCIE0,
> >>>>> + ICC_SNOC_PCIE0,
> >>>>> + ICC_ANOC_PCIE1,
> >>>>> + ICC_SNOC_PCIE1,
> >>>>> + ICC_ANOC_PCIE2,
> >>>>> + ICC_SNOC_PCIE2,
> >>>>> + ICC_ANOC_PCIE3,
> >>>>> + ICC_SNOC_PCIE3,
> >>>>> + ICC_SNOC_USB,
> >>>>> + ICC_ANOC_USB_AXI,
> >>>>> + ICC_NSSNOC_NSSCC,
> >>>>> + ICC_NSSNOC_SNOC_0,
> >>>>> + ICC_NSSNOC_SNOC_1,
> >>>>> + ICC_NSSNOC_PCNOC_1,
> >>>>> + ICC_NSSNOC_QOSGEN_REF,
> >>>>> + ICC_NSSNOC_TIMEOUT_REF,
> >>>>> + ICC_NSSNOC_XO_DCD,
> >>>>> + ICC_NSSNOC_ATB,
> >>>>> + ICC_MEM_NOC_NSSNOC,
> >>>>> + ICC_NSSNOC_MEMNOC,
> >>>>> + ICC_NSSNOC_MEM_NOC_1,
> >>>>> +};
> >>>>
> >>>> Are these supposed to be in a dt-binding header?
> >>>
> >>> Since these don't directly relate to the ids in the dt-bindings
> >>> not sure if they will be permitted there. Will move and post a
> >>> new version and get feedback.
> >>
> >> You can answer this by yourself by looking at your DTS. Do you use them
> >> as well in the DTS?
> >
> > I can use them in the DTS. The icc-clk framework automatically
> > creates master and slave nodes as 'n' and 'n+1'. Hence I can have
> > something like this in the dt-bindings include file
> >
> > #define ICC_ANOC_PCIE0 0
> > #define ICC_SNOC_PCIE0 1
> > .
> > .
> > .
> > #define ICC_NSSNOC_MEM_NOC_1 20
> >
> > #define MASTER(x) ((ICC_ ## x) * 2)
> > #define SLAVE(x) (MASTER(x) + 1)
>
> I don't understand this or maybe I misunderstood the purpose of this
> define. It does not matter if you "can" use something in DT. The
> question is: do you use them.
Yes. It will be used fot the pcie nodes. These defines are for
specifying the endpoints. The icc driver identifies a path that
can connect these endpoints. The peripheral drivers' DT nodes
will make use of these defines.
> >> It's a pity we see here only parts of DTS, instead of full interconnect
> >> usage.
> >
> > Unfortunately cannot include the pcie dts changes with this
> > patch, but you can refer to them at https://lore.kernel.org/linux-arm-msm/20230519090219.15925-5-quic_devipriy@quicinc.com/
> >
> > The above macros will be used in the pcie node as follows
> >
> > pcie0: pci@28000000 {
> > compatible = "qcom,pcie-ipq9574";
> > . . .
> > interconnects = <&gcc MASTER(ANOC_PCIE0) &gcc SLAVE(ANOC_PCIE0)>,
> > <&gcc MASTER(SNOC_PCIE0) &gcc SLAVE(SNOC_PCIE0)>;
> > interconnect-names = "pcie-mem", "cpu-pcie";
>
> Then why did you add header which is not used?
Since they are a part of the interconnect driver. The peripherals
that use the interconnects will make use of them to specify the
endpoints. After changing per Boyd's comments, the header will
be used from gcc driver. Will post a new version. Kindly review
that.
Thanks
Varada
> I will respond there...
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: pm6150: correct USB VBUS regulator compatible
From: Konrad Dybcio @ 2024-03-30 10:49 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Greg Kroah-Hartman, Danila Tikhonov, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20240330091311.6224-2-krzysztof.kozlowski@linaro.org>
On 30.03.2024 10:13 AM, Krzysztof Kozlowski wrote:
> The first part of the compatible of USB VBUS node misses ending quote,
> thus we have one long compatible consisting of two compatible strings
> leading to dtbs_check warnings:
>
> sc7180-idp.dtb: usb-vbus-regulator@1100: compatible:0: 'qcom,pm6150-vbus-reg,\n qcom,pm8150b-vbus-reg' does not match '^[a-zA-Z0-9][a-zA-Z0-9,+\\-._/]+$'
> sc7180-idp.dtb: /soc@0/spmi@c440000/pmic@0/usb-vbus-regulator@1100: failed to match any schema with compatible: ['qcom,pm6150-vbus-reg,\n qcom,pm8150b-vbus-reg']
>
> Reported-by: Rob Herring <robh@kernel.org>
> Fixes: f81c2f01cad6 ("arm64: dts: qcom: pm6150: define USB-C related blocks")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: qcom: pm6150: correct Type-C compatible
From: Konrad Dybcio @ 2024-03-30 10:48 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Greg Kroah-Hartman, Danila Tikhonov, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20240330091311.6224-1-krzysztof.kozlowski@linaro.org>
On 30.03.2024 10:13 AM, Krzysztof Kozlowski wrote:
> The first part of the compatible of Type-C node misses ending quote,
> thus we have one long compatible consisting of two compatible strings
> leading to dtbs_check warnings:
>
> sc7180-acer-aspire1.dtb: pmic@0: typec@1500:compatible: 'oneOf' conditional failed, one must be fixed
> sc7180-acer-aspire1.dtb: typec@1500: compatible:0: 'qcom,pm6150-typec,\n qcom,pm8150b-typec' does not match '^[a-zA-Z0-9][a-zA-Z0-9,+\\-._/]+$'
>
> Reported-by: Rob Herring <robh@kernel.org>
> Fixes: f81c2f01cad6 ("arm64: dts: qcom: pm6150: define USB-C related blocks")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> ---
LOL!
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
^ permalink raw reply
* Re: [PATCH 3/3] drm: panel: Add LG sw43408 panel driver
From: Marijn Suijten @ 2024-03-30 10:27 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Sumit Semwal, Caleb Connolly, Neil Armstrong, Jessica Zhang,
Sam Ravnborg, David Airlie, Daniel Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, dri-devel, devicetree,
linux-kernel, linux-arm-msm, Vinod Koul, Caleb Connolly
In-Reply-To: <20240330-lg-sw43408-panel-v1-3-f5580fc9f2da@linaro.org>
On 2024-03-30 05:59:30, Dmitry Baryshkov wrote:
> From: Sumit Semwal <sumit.semwal@linaro.org>
>
> LG SW43408 is 1080x2160, 4-lane MIPI-DSI panel, used in some Pixel3
> phones.
>
> Whatever init sequence we have for this panel isn't capable of
> initialising it completely, toggling the reset gpio ever causes the
> panel to die. Until this is resolved we avoid resetting the panel. The
Are you sure it is avoided? This patch seems to be toggling reset_gpio in
sw43408_prepare()?
> disable/unprepare functions only put the panel to sleep mode and
> disable the backlight.
>
> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
> [vinod: Add DSC support]
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
> [caleb: cleanup and support turning off the panel]
> Signed-off-by: Caleb Connolly <caleb@connolly.tech>
> [DB: partially rewrote the driver and fixed DSC programming]
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> MAINTAINERS | 8 +
> drivers/gpu/drm/panel/Kconfig | 11 ++
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-lg-sw43408.c | 322 +++++++++++++++++++++++++++++++
> 4 files changed, 342 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4b511a55101c..f4cf7ee97376 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6755,6 +6755,14 @@ S: Maintained
> F: Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
> F: drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
>
> +DRM DRIVER FOR LG SW43408 PANELS
> +M: Sumit Semwal <sumit.semwal@linaro.org>
> +M: Caleb Connolly <caleb.connolly@linaro.org>
> +S: Maintained
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +F: Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml
> +F: drivers/gpu/drm/panel/panel-lg-sw43408.c
> +
> DRM DRIVER FOR LOGICVC DISPLAY CONTROLLER
> M: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> S: Supported
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index d037b3b8b999..f94c702735cb 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -335,6 +335,17 @@ config DRM_PANEL_LG_LG4573
> Say Y here if you want to enable support for LG4573 RGB panel.
> To compile this driver as a module, choose M here.
>
> +config DRM_PANEL_LG_SW43408
> + tristate "LG SW43408 panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> + Say Y here if you want to enable support for LG sw43408 panel.
> + The panel has a 1080x2160 resolution and uses
> + 24 bit RGB per pixel. It provides a MIPI DSI interface to
> + the host and has a built-in LED backlight.
> +
> config DRM_PANEL_MAGNACHIP_D53E6EA8966
> tristate "Magnachip D53E6EA8966 DSI panel"
> depends on OF && SPI
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index f156d7fa0bcc..a75687d13caf 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -34,6 +34,7 @@ obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) += panel-leadtek-ltk050h3146w.o
> obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
> obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
> obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
> +obj-$(CONFIG_DRM_PANEL_LG_SW43408) += panel-lg-sw43408.o
> obj-$(CONFIG_DRM_PANEL_MAGNACHIP_D53E6EA8966) += panel-magnachip-d53e6ea8966.o
> obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
> obj-$(CONFIG_DRM_PANEL_NEWVISION_NV3051D) += panel-newvision-nv3051d.o
> diff --git a/drivers/gpu/drm/panel/panel-lg-sw43408.c b/drivers/gpu/drm/panel/panel-lg-sw43408.c
> new file mode 100644
> index 000000000000..365d25e14d54
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-lg-sw43408.c
> @@ -0,0 +1,322 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019-2024 Linaro Ltd
> + * Author: Sumit Semwal <sumit.semwal@linaro.org>
> + * Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> + */
> +
> +#include <linux/backlight.h>
> +#include <linux/delay.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include <video/mipi_display.h>
> +
> +#include <drm/drm_mipi_dsi.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_probe_helper.h>
> +#include <drm/display/drm_dsc.h>
> +#include <drm/display/drm_dsc_helper.h>
> +
> +#define NUM_SUPPLIES 2
> +
> +struct sw43408_panel {
> + struct drm_panel base;
> + struct mipi_dsi_device *link;
> +
> + const struct drm_display_mode *mode;
> +
> + struct regulator_bulk_data supplies[NUM_SUPPLIES];
> +
> + struct gpio_desc *reset_gpio;
> +};
> +
> +static inline struct sw43408_panel *to_panel_info(struct drm_panel *panel)
> +{
> + return container_of(panel, struct sw43408_panel, base);
> +}
> +
> +static int sw43408_unprepare(struct drm_panel *panel)
> +{
> + struct sw43408_panel *ctx = to_panel_info(panel);
> + int ret;
> +
> + ret = mipi_dsi_dcs_set_display_off(ctx->link);
> + if (ret < 0)
> + dev_err(panel->dev, "set_display_off cmd failed ret = %d\n", ret);
> +
> + ret = mipi_dsi_dcs_enter_sleep_mode(ctx->link);
> + if (ret < 0)
> + dev_err(panel->dev, "enter_sleep cmd failed ret = %d\n", ret);
> +
> + msleep(100);
> +
> + gpiod_set_value(ctx->reset_gpio, 1);
> +
> + return regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> +}
> +
> +static int sw43408_program(struct drm_panel *panel)
> +{
> + struct sw43408_panel *ctx = to_panel_info(panel);
> + struct drm_dsc_picture_parameter_set pps;
> + u8 dsc_en = 0x11;
Yeah, this is completely strange. Bit 0, 0x1, is to enable DSC which is
normal. 0x10 however, which is bit 4, selects PPS table 2. Do you ever set
pps_identifier in struct drm_dsc_picture_parameter_set to 2? Or is the table
that you send below bogus and/or not used? Maybe the Driver IC on the other
end of the DSI link has a default PPS table with identifier 2 that works out of
the box?
> + mipi_dsi_dcs_write_seq(ctx->link, MIPI_DCS_SET_GAMMA_CURVE, 0x02);
> +
> + mipi_dsi_dcs_set_tear_on(ctx->link, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
> +
> + mipi_dsi_dcs_write_seq(ctx->link, 0x53, 0x0c, 0x30);
> + mipi_dsi_dcs_write_seq(ctx->link, 0x55, 0x00, 0x70, 0xdf, 0x00, 0x70, 0xdf);
> + mipi_dsi_dcs_write_seq(ctx->link, 0xf7, 0x01, 0x49, 0x0c);
> +
> + mipi_dsi_dcs_exit_sleep_mode(ctx->link);
> +
> + msleep(135);
> +
> + mipi_dsi_compression_mode_raw(ctx->link, &dsc_en, 1);
Even though I think we should change this function to describe the known
bit layout of command 0x7 per the VESA DSI spec, for now replace 1 with
sizeof(dsc_en)?
> +
> + mipi_dsi_dcs_write_seq(ctx->link, 0xb0, 0xac);
> + mipi_dsi_dcs_write_seq(ctx->link, 0xe5,
> + 0x00, 0x3a, 0x00, 0x3a, 0x00, 0x0e, 0x10);
> + mipi_dsi_dcs_write_seq(ctx->link, 0xb5,
> + 0x75, 0x60, 0x2d, 0x5d, 0x80, 0x00, 0x0a, 0x0b,
> + 0x00, 0x05, 0x0b, 0x00, 0x80, 0x0d, 0x0e, 0x40,
> + 0x00, 0x0c, 0x00, 0x16, 0x00, 0xb8, 0x00, 0x80,
> + 0x0d, 0x0e, 0x40, 0x00, 0x0c, 0x00, 0x16, 0x00,
> + 0xb8, 0x00, 0x81, 0x00, 0x03, 0x03, 0x03, 0x01,
> + 0x01);
> + msleep(85);
> + mipi_dsi_dcs_write_seq(ctx->link, 0xcd,
> + 0x00, 0x00, 0x00, 0x19, 0x19, 0x19, 0x19, 0x19,
> + 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19, 0x19,
> + 0x16, 0x16);
> + mipi_dsi_dcs_write_seq(ctx->link, 0xcb, 0x80, 0x5c, 0x07, 0x03, 0x28);
> + mipi_dsi_dcs_write_seq(ctx->link, 0xc0, 0x02, 0x02, 0x0f);
> + mipi_dsi_dcs_write_seq(ctx->link, 0x55, 0x04, 0x61, 0xdb, 0x04, 0x70, 0xdb);
> + mipi_dsi_dcs_write_seq(ctx->link, 0xb0, 0xca);
> +
> + mipi_dsi_dcs_set_display_on(ctx->link);
Any specific reason to not have the (un)blanking sequence in the enable/disable
callbacks and leaving display configuration in (un)prepare?
> + msleep(50);
> +
> + ctx->link->mode_flags &= ~MIPI_DSI_MODE_LPM;
> +
> + drm_dsc_pps_payload_pack(&pps, ctx->link->dsc);
> + mipi_dsi_picture_parameter_set(ctx->link, &pps);
I'm always surprised why this is sent _after_ turning the display on (unblanking
it). Wouldn't that cause unnecessary corruption?
> +
> + ctx->link->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> + return 0;
> +}
> +
> +static int sw43408_prepare(struct drm_panel *panel)
> +{
> + struct sw43408_panel *ctx = to_panel_info(panel);
> + int ret;
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> + if (ret < 0)
> + return ret;
> +
> + usleep_range(5000, 6000);
> +
> + gpiod_set_value(ctx->reset_gpio, 0);
> + usleep_range(9000, 10000);
> + gpiod_set_value(ctx->reset_gpio, 1);
> + usleep_range(1000, 2000);
> + gpiod_set_value(ctx->reset_gpio, 0);
> + usleep_range(9000, 10000);
> +
> + ret = sw43408_program(panel);
> + if (ret)
> + goto poweroff;
> +
> + return 0;
> +
> +poweroff:
> + gpiod_set_value(ctx->reset_gpio, 1);
> + regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> + return ret;
> +}
> +
> +static int sw43408_get_modes(struct drm_panel *panel,
> + struct drm_connector *connector)
> +{
> + struct sw43408_panel *ctx = to_panel_info(panel);
> +
> + return drm_connector_helper_get_modes_fixed(connector, ctx->mode);
> +}
> +
> +static int sw43408_backlight_update_status(struct backlight_device *bl)
> +{
> + struct mipi_dsi_device *dsi = bl_get_data(bl);
> + uint16_t brightness = backlight_get_brightness(bl);
> +
> + return mipi_dsi_dcs_set_display_brightness_large(dsi, brightness);
> +}
> +
> +const struct backlight_ops sw43408_backlight_ops = {
> + .update_status = sw43408_backlight_update_status,
> +};
> +
> +static int sw43408_backlight_init(struct sw43408_panel *ctx)
> +{
> + struct device *dev = &ctx->link->dev;
> + const struct backlight_properties props = {
> + .type = BACKLIGHT_PLATFORM,
> + .brightness = 255,
> + .max_brightness = 255,
> + };
> +
> + ctx->base.backlight = devm_backlight_device_register(dev, dev_name(dev), dev,
> + ctx->link,
> + &sw43408_backlight_ops,
> + &props);
> +
> + if (IS_ERR(ctx->base.backlight))
> + return dev_err_probe(dev, PTR_ERR(ctx->base.backlight),
> + "Failed to create backlight\n");
> +
> + return 0;
> +}
> +
> +static const struct drm_panel_funcs sw43408_funcs = {
> + .unprepare = sw43408_unprepare,
> + .prepare = sw43408_prepare,
> + .get_modes = sw43408_get_modes,
> +};
> +
> +static const struct drm_display_mode sw43408_default_mode = {
> + .clock = 152340,
> +
> + .hdisplay = 1080,
> + .hsync_start = 1080 + 20,
> + .hsync_end = 1080 + 20 + 32,
> + .htotal = 1080 + 20 + 32 + 20,
> +
> + .vdisplay = 2160,
> + .vsync_start = 2160 + 20,
> + .vsync_end = 2160 + 20 + 4,
> + .vtotal = 2160 + 20 + 4 + 20,
> +
> + .width_mm = 62,
> + .height_mm = 124,
> +
> + .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> +};
> +
> +static const struct of_device_id sw43408_of_match[] = {
> + { .compatible = "lg,sw43408", .data = &sw43408_default_mode },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, sw43408_of_match);
> +
> +static int sw43408_add(struct sw43408_panel *ctx)
> +{
> + struct device *dev = &ctx->link->dev;
> + int ret;
> +
> + ctx->supplies[0].supply = "vddi"; /* 1.88 V */
> + ctx->supplies[0].init_load_uA = 62000;
> + ctx->supplies[1].supply = "vpnl"; /* 3.0 V */
> + ctx->supplies[1].init_load_uA = 857000;
> +
> + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies),
> + ctx->supplies);
> + if (ret < 0)
> + return ret;
> +
> + ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> + if (IS_ERR(ctx->reset_gpio)) {
> + dev_err(dev, "cannot get reset gpio %ld\n",
> + PTR_ERR(ctx->reset_gpio));
> + return PTR_ERR(ctx->reset_gpio);
> + }
> +
> + ret = sw43408_backlight_init(ctx);
> + if (ret < 0)
> + return ret;
> +
> + ctx->base.prepare_prev_first = true;
> +
> + drm_panel_init(&ctx->base, dev, &sw43408_funcs, DRM_MODE_CONNECTOR_DSI);
> +
> + drm_panel_add(&ctx->base);
> + return ret;
> +}
> +
> +static int sw43408_probe(struct mipi_dsi_device *dsi)
> +{
> + struct sw43408_panel *ctx;
> + struct drm_dsc_config *dsc;
> + int ret;
> +
> + ctx = devm_kzalloc(&dsi->dev, sizeof(*ctx), GFP_KERNEL);
> + if (!ctx)
> + return -ENOMEM;
> +
> + ctx->mode = of_device_get_match_data(&dsi->dev);
> + dsi->mode_flags = MIPI_DSI_MODE_LPM;
> + dsi->format = MIPI_DSI_FMT_RGB888;
> + dsi->lanes = 4;
> +
> + ctx->link = dsi;
> + mipi_dsi_set_drvdata(dsi, ctx);
> +
> + ret = sw43408_add(ctx);
> + if (ret < 0)
> + return ret;
> +
> + /* The panel is DSC panel only, set the dsc params */
> + dsc = devm_kzalloc(&dsi->dev, sizeof(*dsc), GFP_KERNEL);
We've recently decided to store struct drm_dsc_config in struct sw43408_panel
and save on an extra allocation.
> + if (!dsc)
> + return -ENOMEM;
> +
> + dsc->dsc_version_major = 0x1;
> + dsc->dsc_version_minor = 0x1;
> +
> + dsc->slice_height = 16;
> + dsc->slice_width = 540;
> + dsc->slice_count = 2;
Maybe incorporate with a comment that slice_count * slice_width == the width of
the mode?
- Marijn
> + dsc->bits_per_component = 8;
> + dsc->bits_per_pixel = 8 << 4;
> + dsc->block_pred_enable = true;
> +
> + dsi->dsc = dsc;
> +
> + return mipi_dsi_attach(dsi);
> +}
> +
> +static void sw43408_remove(struct mipi_dsi_device *dsi)
> +{
> + struct sw43408_panel *ctx = mipi_dsi_get_drvdata(dsi);
> + int ret;
> +
> + ret = sw43408_unprepare(&ctx->base);
> + if (ret < 0)
> + dev_err(&dsi->dev, "failed to unprepare panel: %d\n",
> + ret);
> +
> + ret = mipi_dsi_detach(dsi);
> + if (ret < 0)
> + dev_err(&dsi->dev, "failed to detach from DSI host: %d\n", ret);
> +
> + drm_panel_remove(&ctx->base);
> +}
> +
> +static struct mipi_dsi_driver sw43408_driver = {
> + .driver = {
> + .name = "panel-lg-sw43408",
> + .of_match_table = sw43408_of_match,
> + },
> + .probe = sw43408_probe,
> + .remove = sw43408_remove,
> +};
> +module_mipi_dsi_driver(sw43408_driver);
> +
> +MODULE_AUTHOR("Sumit Semwal <sumit.semwal@linaro.org>");
> +MODULE_DESCRIPTION("LG SW436408 MIPI-DSI LED panel");
> +MODULE_LICENSE("GPL");
>
> --
> 2.39.2
>
^ permalink raw reply
* Re: [PATCH v5 1/5] dt-bindings: interconnect: Add Qualcomm IPQ9574 support
From: Krzysztof Kozlowski @ 2024-03-30 10:30 UTC (permalink / raw)
To: Varadarajan Narayanan, andersson, konrad.dybcio, mturquette,
sboyd, robh, krzysztof.kozlowski+dt, conor+dt, djakov,
dmitry.baryshkov, quic_anusha, linux-arm-msm, linux-clk,
devicetree, linux-kernel, linux-pm
In-Reply-To: <20240328075936.223461-2-quic_varada@quicinc.com>
On 28/03/2024 08:59, Varadarajan Narayanan wrote:
> Add interconnect-cells to clock provider so that it can be
> used as icc provider.
>
> Add master/slave ids for Qualcomm IPQ9574 Network-On-Chip
> interfaces. This will be used by the gcc-ipq9574 driver
> that will for providing interconnect services using the
> icc-clk framework.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Please remove my Reviewed tag.
It seems you do not use this binding header: neither in your DTS and nor
in the driver.
Consider the patch NAK-ed and send new version which removes unused header.
Please provide link to upstreamed DTS using this, so we can validate
your usage. Otherwise it looks just wrong and you try to upstream
something which will not pass dtbs checks on the first day, for example.
NAK
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 4/5] clk: qcom: ipq9574: Use icc-clk for enabling NoC related clocks
From: Krzysztof Kozlowski @ 2024-03-30 10:28 UTC (permalink / raw)
To: Varadarajan Narayanan
Cc: Stephen Boyd, andersson, conor+dt, devicetree, djakov,
dmitry.baryshkov, konrad.dybcio, krzysztof.kozlowski+dt,
linux-arm-msm, linux-clk, linux-kernel, linux-pm, mturquette,
quic_anusha, robh
In-Reply-To: <Zgfbs5SFN2cA0gSK@hu-varada-blr.qualcomm.com>
On 30/03/2024 10:30, Varadarajan Narayanan wrote:
> On Fri, Mar 29, 2024 at 01:10:03PM +0100, Krzysztof Kozlowski wrote:
>> On 29/03/2024 11:55, Varadarajan Narayanan wrote:
>>>>> +
>>>>> +enum {
>>>>> + ICC_ANOC_PCIE0,
>>>>> + ICC_SNOC_PCIE0,
>>>>> + ICC_ANOC_PCIE1,
>>>>> + ICC_SNOC_PCIE1,
>>>>> + ICC_ANOC_PCIE2,
>>>>> + ICC_SNOC_PCIE2,
>>>>> + ICC_ANOC_PCIE3,
>>>>> + ICC_SNOC_PCIE3,
>>>>> + ICC_SNOC_USB,
>>>>> + ICC_ANOC_USB_AXI,
>>>>> + ICC_NSSNOC_NSSCC,
>>>>> + ICC_NSSNOC_SNOC_0,
>>>>> + ICC_NSSNOC_SNOC_1,
>>>>> + ICC_NSSNOC_PCNOC_1,
>>>>> + ICC_NSSNOC_QOSGEN_REF,
>>>>> + ICC_NSSNOC_TIMEOUT_REF,
>>>>> + ICC_NSSNOC_XO_DCD,
>>>>> + ICC_NSSNOC_ATB,
>>>>> + ICC_MEM_NOC_NSSNOC,
>>>>> + ICC_NSSNOC_MEMNOC,
>>>>> + ICC_NSSNOC_MEM_NOC_1,
>>>>> +};
>>>>
>>>> Are these supposed to be in a dt-binding header?
>>>
>>> Since these don't directly relate to the ids in the dt-bindings
>>> not sure if they will be permitted there. Will move and post a
>>> new version and get feedback.
>>
>> You can answer this by yourself by looking at your DTS. Do you use them
>> as well in the DTS?
>
> I can use them in the DTS. The icc-clk framework automatically
> creates master and slave nodes as 'n' and 'n+1'. Hence I can have
> something like this in the dt-bindings include file
>
> #define ICC_ANOC_PCIE0 0
> #define ICC_SNOC_PCIE0 1
> .
> .
> .
> #define ICC_NSSNOC_MEM_NOC_1 20
>
> #define MASTER(x) ((ICC_ ## x) * 2)
> #define SLAVE(x) (MASTER(x) + 1)
I don't understand this or maybe I misunderstood the purpose of this
define. It does not matter if you "can" use something in DT. The
question is: do you use them.
>
>> It's a pity we see here only parts of DTS, instead of full interconnect
>> usage.
>
> Unfortunately cannot include the pcie dts changes with this
> patch, but you can refer to them at https://lore.kernel.org/linux-arm-msm/20230519090219.15925-5-quic_devipriy@quicinc.com/
>
> The above macros will be used in the pcie node as follows
>
> pcie0: pci@28000000 {
> compatible = "qcom,pcie-ipq9574";
> . . .
> interconnects = <&gcc MASTER(ANOC_PCIE0) &gcc SLAVE(ANOC_PCIE0)>,
> <&gcc MASTER(SNOC_PCIE0) &gcc SLAVE(SNOC_PCIE0)>;
> interconnect-names = "pcie-mem", "cpu-pcie";
Then why did you add header which is not used?
I will respond there...
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/2] arm64: dts: rockchip: Enable gpu on Cool Pi CM5
From: Andy Yan @ 2024-03-30 10:01 UTC (permalink / raw)
To: heiko
Cc: krzysztof.kozlowski+dt, devicetree, dsimic, conor+dt,
linux-arm-kernel, linux-kernel, linux-rockchip, sebastian.reichel,
Andy Yan
Enable mali gpu node and add the board specific supply-regulator.
Signed-off-by: Andy Yan <andyshrk@163.com>
---
arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5.dtsi
index 94ecb9b4f98f..6f5cf6a06c2c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5.dtsi
@@ -136,6 +136,11 @@ &gmac0_rgmii_clk
status = "okay";
};
+&gpu {
+ mali-supply = <&vdd_gpu_s0>;
+ status = "okay";
+};
+
&i2c0 {
pinctrl-0 = <&i2c0m2_xfer>;
status = "okay";
--
2.34.1
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: rockchip: Enable gpu on Cool Pi 4B
From: Andy Yan @ 2024-03-30 10:01 UTC (permalink / raw)
To: heiko
Cc: krzysztof.kozlowski+dt, devicetree, dsimic, conor+dt,
linux-arm-kernel, linux-kernel, linux-rockchip, sebastian.reichel,
Andy Yan
In-Reply-To: <20240330100134.3588223-1-andyshrk@163.com>
Enable mali gpu node and add the board specific supply-regulator.
Signed-off-by: Andy Yan <andyshrk@163.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts b/arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts
index e037bf9db75a..25a2ae7d4827 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts
@@ -203,6 +203,11 @@ &cpu_b2 {
cpu-supply = <&vdd_cpu_big1_s0>;
};
+&gpu {
+ mali-supply = <&vdd_gpu_s0>;
+ status = "okay";
+};
+
&i2c0 {
pinctrl-0 = <&i2c0m2_xfer>;
status = "okay";
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v5 4/5] clk: qcom: ipq9574: Use icc-clk for enabling NoC related clocks
From: Varadarajan Narayanan @ 2024-03-30 9:30 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Stephen Boyd, andersson, conor+dt, devicetree, djakov,
dmitry.baryshkov, konrad.dybcio, krzysztof.kozlowski+dt,
linux-arm-msm, linux-clk, linux-kernel, linux-pm, mturquette,
quic_anusha, robh
In-Reply-To: <031d0a35-b192-4161-beef-97b89d5d1da6@linaro.org>
On Fri, Mar 29, 2024 at 01:10:03PM +0100, Krzysztof Kozlowski wrote:
> On 29/03/2024 11:55, Varadarajan Narayanan wrote:
> >>> +
> >>> +enum {
> >>> + ICC_ANOC_PCIE0,
> >>> + ICC_SNOC_PCIE0,
> >>> + ICC_ANOC_PCIE1,
> >>> + ICC_SNOC_PCIE1,
> >>> + ICC_ANOC_PCIE2,
> >>> + ICC_SNOC_PCIE2,
> >>> + ICC_ANOC_PCIE3,
> >>> + ICC_SNOC_PCIE3,
> >>> + ICC_SNOC_USB,
> >>> + ICC_ANOC_USB_AXI,
> >>> + ICC_NSSNOC_NSSCC,
> >>> + ICC_NSSNOC_SNOC_0,
> >>> + ICC_NSSNOC_SNOC_1,
> >>> + ICC_NSSNOC_PCNOC_1,
> >>> + ICC_NSSNOC_QOSGEN_REF,
> >>> + ICC_NSSNOC_TIMEOUT_REF,
> >>> + ICC_NSSNOC_XO_DCD,
> >>> + ICC_NSSNOC_ATB,
> >>> + ICC_MEM_NOC_NSSNOC,
> >>> + ICC_NSSNOC_MEMNOC,
> >>> + ICC_NSSNOC_MEM_NOC_1,
> >>> +};
> >>
> >> Are these supposed to be in a dt-binding header?
> >
> > Since these don't directly relate to the ids in the dt-bindings
> > not sure if they will be permitted there. Will move and post a
> > new version and get feedback.
>
> You can answer this by yourself by looking at your DTS. Do you use them
> as well in the DTS?
I can use them in the DTS. The icc-clk framework automatically
creates master and slave nodes as 'n' and 'n+1'. Hence I can have
something like this in the dt-bindings include file
#define ICC_ANOC_PCIE0 0
#define ICC_SNOC_PCIE0 1
.
.
.
#define ICC_NSSNOC_MEM_NOC_1 20
#define MASTER(x) ((ICC_ ## x) * 2)
#define SLAVE(x) (MASTER(x) + 1)
> It's a pity we see here only parts of DTS, instead of full interconnect
> usage.
Unfortunately cannot include the pcie dts changes with this
patch, but you can refer to them at https://lore.kernel.org/linux-arm-msm/20230519090219.15925-5-quic_devipriy@quicinc.com/
The above macros will be used in the pcie node as follows
pcie0: pci@28000000 {
compatible = "qcom,pcie-ipq9574";
. . .
interconnects = <&gcc MASTER(ANOC_PCIE0) &gcc SLAVE(ANOC_PCIE0)>,
<&gcc MASTER(SNOC_PCIE0) &gcc SLAVE(SNOC_PCIE0)>;
interconnect-names = "pcie-mem", "cpu-pcie";
. . .
};
Hope this is acceptable.
Thanks
Varada
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: mfd: x-powers,axp152: add boost regulator
From: Krzysztof Kozlowski @ 2024-03-30 9:30 UTC (permalink / raw)
To: Andre Przywara, Chen-Yu Tsai, Lee Jones, Liam Girdwood,
Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: devicetree, linux-kernel, linux-sunxi, Jernej Skrabec,
Samuel Holland, Ryan Walklin, Chris Morgan
In-Reply-To: <20240329235033.25309-3-andre.przywara@arm.com>
On 30/03/2024 00:50, Andre Przywara wrote:
> The X-Powers AXP717 contains a boost regulator, that it meant to provide
> the 5V USB VBUS voltage when the devices operates on battery.
>
> Add the name "boost" to the regexp describing the allowed node names,
> to allow the regulator to be described in the devicetree.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
> index b8e8db0d58e9c..14ab367fc8871 100644
> --- a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
> +++ b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
> @@ -274,7 +274,7 @@ properties:
> Defines the work frequency of DC-DC in kHz.
>
> patternProperties:
> - "^(([a-f])?ldo[0-9]|dcdc[0-7a-e]|ldo(_|-)io(0|1)|(dc1)?sw|rtc(_|-)ldo|cpusldo|drivevbus|dc5ldo)$":
> + "^(([a-f])?ldo[0-9]|dcdc[0-7a-e]|ldo(_|-)io(0|1)|(dc1)?sw|rtc(_|-)ldo|cpusldo|drivevbus|dc5ldo|boost)$":
That's not an easy to read regex...
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
If driver does not depend on _, please consider dropping (_|-).
Best regards,
Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox