* [PATCH v4 2/9] dt-bindings: mailbox: Add mboxes property for CMDQ secure driver
From: Shawn Sung @ 2024-04-03 6:55 UTC (permalink / raw)
To: CK Hu, Jassi Brar, AngeloGioacchino Del Regno
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Hsiao Chien Sung, Jason-JH . Lin, Houlong Wei, linux-kernel,
devicetree, linux-arm-kernel, linux-mediatek
In-Reply-To: <20240403065603.21920-1-shawn.sung@mediatek.com>
From: "Jason-JH.Lin" <jason-jh.lin@mediatek.com>
Add mboxes to define a GCE loopping thread as a secure irq handler.
This property is only required if CMDQ secure driver is supported.
Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com>
---
.../devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
index cef9d76013985..cf39e70747de6 100644
--- a/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
+++ b/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
@@ -49,6 +49,9 @@ properties:
items:
- const: gce
+ mboxes:
+ maxItems: 1
+
required:
- compatible
- "#mbox-cells"
--
2.18.0
^ permalink raw reply related
* [PATCH v4 0/9] Add CMDQ secure driver for SVP
From: Shawn Sung @ 2024-04-03 6:55 UTC (permalink / raw)
To: CK Hu, Jassi Brar, AngeloGioacchino Del Regno
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Hsiao Chien Sung, Jason-JH . Lin, Houlong Wei, linux-kernel,
devicetree, linux-arm-kernel, linux-mediatek, Hsiao Chien Sung
From: Hsiao Chien Sung <shawn.sung@mediatek.corp-partner.google.com>
For the Secure Video Path (SVP) feature, inculding the memory stored
secure video content, the registers of display HW pipeline and the
HW configure operations are required to execute in the secure world.
So using a CMDQ secure driver to make all display HW registers
configuration secure DRAM access permision settings execute by GCE
secure thread in the secure world.
We are landing this feature on mt8188 and mt8195 currently.
---
Based on 2 series and 1 patch:
[1] Add CMDQ driver support for mt8188
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=810382
[2] Add mediatek,gce-events definition to mediatek,gce-mailbox bindings
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=810938
[3] soc: mediatek: Add register definitions for GCE
- https://patchwork.kernel.org/project/linux-mediatek/patch/20231017064717.21616-2-shawn.sung@mediatek.com/
---
Changes in v4:
1. Rebase on mediatek-drm-next(278640d4d74cd) and fix the conflicts
2. This series is based on 20240307013458.23550-1-jason-jh.lin@mediatek.com
Changes in v3:
1. separate mt8188 driver porting patches to another series
2. separate adding 'mediatek,gce-events' event prop to another series
3. sepatate mailbox helper and controller driver modification to a
single patch for adding looping thread
4. add kerneldoc for secure mailbox related definition
5. add moving reuseable definition patch before adding secure mailbox
driver patch
6. adjust redundant logic in mtk-cmdq-sec-mailbox
Changes in v2:
1. adjust dt-binding SW event define patch before the dt-binding patch using it
2. adjust dt-binding patch for secure cmdq driver
3. remove the redundant patches or merge the patches of modification for the same API
Jason-JH.Lin (9):
dt-bindings: gce: mt8195: Add CMDQ_SYNC_TOKEN_SECURE_THR_EOF event id
dt-bindings: mailbox: Add mboxes property for CMDQ secure driver
soc: mediatek: cmdq: Add cmdq_pkt_logic_command to support math
operation
soc: mediatek: cmdq: Add cmdq_pkt_write_s_reg_value to support write
value to reg
mailbox: mtk-cmdq: Support GCE loop packets in interrupt handler
mediatek: cmdq: Add cmdq_pkt_finalize_loop for looping cmd with irq
mailbox: mediatek: Move reuseable definition to header for secure
driver
mailbox: mediatek: Add CMDQ secure mailbox driver
mailbox: mediatek: Add secure CMDQ driver support for CMDQ driver
.../mailbox/mediatek,gce-mailbox.yaml | 3 +
drivers/mailbox/Makefile | 2 +-
drivers/mailbox/mtk-cmdq-mailbox.c | 79 +-
drivers/mailbox/mtk-cmdq-sec-mailbox.c | 1091 +++++++++++++++++
drivers/mailbox/mtk-cmdq-sec-tee.c | 165 +++
drivers/soc/mediatek/mtk-cmdq-helper.c | 72 ++
include/dt-bindings/gce/mt8195-gce.h | 6 +
include/linux/mailbox/mtk-cmdq-mailbox.h | 36 +
.../linux/mailbox/mtk-cmdq-sec-iwc-common.h | 385 ++++++
include/linux/mailbox/mtk-cmdq-sec-mailbox.h | 158 +++
include/linux/mailbox/mtk-cmdq-sec-tee.h | 105 ++
include/linux/soc/mediatek/mtk-cmdq.h | 61 +
12 files changed, 2132 insertions(+), 31 deletions(-)
create mode 100644 drivers/mailbox/mtk-cmdq-sec-mailbox.c
create mode 100644 drivers/mailbox/mtk-cmdq-sec-tee.c
create mode 100644 include/linux/mailbox/mtk-cmdq-sec-iwc-common.h
create mode 100644 include/linux/mailbox/mtk-cmdq-sec-mailbox.h
create mode 100644 include/linux/mailbox/mtk-cmdq-sec-tee.h
--
2.18.0
^ permalink raw reply
* Re: [PATCH 1/2] drm/bridge: lt8912b: add support for P/N pin swap
From: Francesco Dolcini @ 2024-04-03 6:52 UTC (permalink / raw)
To: Alexandru Ardelean
Cc: Francesco Dolcini, linux-kernel, dri-devel, devicetree,
adrien.grassein, andrzej.hajda, neil.armstrong, rfoss,
Laurent.pinchart, jonas, jernej.skrabec, airlied, daniel,
maarten.lankhorst, mripard, tzimmermann, robh,
krzysztof.kozlowski+dt, conor+dt, stefan.eichenberger,
francesco.dolcini, marius.muresan, irina.muresan
In-Reply-To: <CAH3L5Qr-sT+Q9ZvNSxHKwVMr8-3fU5WPvvaccEWWH49x7oWMyQ@mail.gmail.com>
On Wed, Apr 03, 2024 at 09:32:41AM +0300, Alexandru Ardelean wrote:
> I did it like this, because I don't have a board with the P/N in the
You use this 'P/N' both here and in the binding document, to me this is
just too generic and confusing.
Just use some wording that people familiar with the topic can easily undestand,
the Lontium datasheet uses MIPI RX DP/DN, MIPI DSI DP/DN would also work fine
for me, or at least DP/DN that is the working used on some MIPI documentation.
This comment applies to both the changes in the driver and the binding.
Thanks,
Francesco
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible
From: Siddharth Vadapalli @ 2024-04-03 6:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Siddharth Vadapalli, lee, robh, krzk+dt, conor+dt, devicetree,
linux-kernel, linux-arm-kernel, srk
In-Reply-To: <083e50de-1c99-4a58-8b55-4dec26d97c1b@kernel.org>
On Wed, Apr 03, 2024 at 08:40:19AM +0200, Krzysztof Kozlowski wrote:
> On 03/04/2024 08:32, Siddharth Vadapalli wrote:
> > On Wed, Apr 03, 2024 at 08:27:06AM +0200, Krzysztof Kozlowski wrote:
> >> On 03/04/2024 07:35, Siddharth Vadapalli wrote:
> >>> On Tue, Apr 02, 2024 at 08:06:27PM +0200, Krzysztof Kozlowski wrote:
> >>>> On 02/04/2024 14:30, Siddharth Vadapalli wrote:
> >>>>> On Tue, Apr 02, 2024 at 02:08:32PM +0200, Krzysztof Kozlowski wrote:
> >>>>>> On 02/04/2024 12:57, Siddharth Vadapalli wrote:
> >>>>>>> The CTRLMMR_MAC_IDx registers within the CTRL_MMR space of TI's AM62p SoC
> >>>>>>> contain the MAC Address programmed in the eFuse. Add compatible for
> >>>>>>> allowing the CPSW driver to obtain a regmap for the CTRLMMR_MAC_IDx
> >>>>>>> registers within the System Controller device-tree node. The default MAC
> >>>>>>> Address for the interface corresponding to the first MAC port will be set
> >>>>>>> to the value programmed in the eFuse.
> >>>>>>>
> >>>>>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> >>>>>>> ---
> >>>>>>>
> >>>>>>> This patch is based on linux-next tagged next-20240402.
> >>>>>>
> >>>>>> Where is the DTS using it?
> >>>>>
> >>>>> The current implementation in the device-tree for older TI K3 SoCs is as
> >>>>> follows:
> >>>>>
> >>>>> cpsw_port1: port@1 {
> >>>>> reg = <1>;
> >>>>> ti,mac-only;
> >>>>> label = "port1";
> >>>>> phys = <&phy_gmii_sel 1>;
> >>>>> mac-address = [00 00 00 00 00 00];
> >>>>> ti,syscon-efuse = <&wkup_conf 0x200>;
> >>>>> };
> >>>>>
> >>>>> The "ti,syscon-efuse" property passes the reference to the System
> >>>>> Controller node as well as the offset to the CTRLMMR_MAC_IDx registers
> >>>>> within the CTRL_MMR space.
> >>>>
> >>>> Please reference upstream DTS or lore link to patch under review.
> >>>
> >>> An example of the existing implementation in the device-tree for AM64x
> >>> is:
> >>> https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L697
> >>> It uses:
> >>> ti,syscon-efuse = <&main_conf 0x200>;
> >>>
> >>> and "main_conf" node is defined at:
> >>> https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L40
> >>
> >> It is quite different than your bindings, so your bindings are incorrect.
> >
> > Sorry I didn't understand what you mean. The references I have provided
> > are for existing DTS where "main_conf"/"wkup_conf" (System Controller
> > nodes) have the compatible "syscon", unlike in AM62p at:
> > https://github.com/torvalds/linux/blob/20f8173afaac90dd9dca11be4aa602a47776077f/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi#L8
> > which has the "simple-bus" compatible for the "wkup_conf" node.
> >
> > Also, shouldn't the device-tree bindings patches be posted first and get
> > merged before I post the device-tree patches that utilize the
> > compatible/properties that have been added in the bindings? That is the
> > reason why I had shared the "DIFF" for the DTS changes that I will be
> > posting once this patch for the new compatible is accepted.
> >
>
> That's not the process. I will be NAKing bindings which do not have any
> users, because I do not trust you test them.
>
> The process is almost always:
> 1. Send bindings,
> 2. Send driver changes (if applicable) in the same patchset.
> 3. Send DTS, usually in separate patches and provide lore link to the
> bindings in the changelog or cover letter.
Thank you for clarifying. I will post the DTS patches corresponding to
this patch and reference this patch in the DTS patch series.
Regards,
Siddharth.
^ permalink raw reply
* Re: [PATCH v2 01/18] PCI: endpoint: Introduce pci_epc_function_is_valid()
From: Manivannan Sadhasivam @ 2024-04-03 6:46 UTC (permalink / raw)
To: Damien Le Moal
Cc: Lorenzo Pieralisi, Kishon Vijay Abraham I, Shawn Lin,
Krzysztof Wilczyński, Bjorn Helgaas, Heiko Stuebner,
linux-pci, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, linux-rockchip, linux-arm-kernel, Rick Wertenbroek,
Wilfred Mallawa, Niklas Cassel
In-Reply-To: <20240330041928.1555578-2-dlemoal@kernel.org>
On Sat, Mar 30, 2024 at 01:19:11PM +0900, Damien Le Moal wrote:
> Introduce the epc core helper function pci_epc_function_is_valid() to
> verify that an epc pointer, a physical function number and a virtual
> function number are all valid. This avoids repeating the code pattern:
>
> if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
> return err;
>
> if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> return err;
>
> in many functions of the endpoint controller core code.
>
> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
One nit below. With that fixed,
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> drivers/pci/endpoint/pci-epc-core.c | 79 +++++++++++------------------
> 1 file changed, 31 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
> index da3fc0795b0b..754afd115bbd 100644
> --- a/drivers/pci/endpoint/pci-epc-core.c
> +++ b/drivers/pci/endpoint/pci-epc-core.c
> @@ -126,6 +126,18 @@ enum pci_barno pci_epc_get_next_free_bar(const struct pci_epc_features
> }
> EXPORT_SYMBOL_GPL(pci_epc_get_next_free_bar);
>
> +static inline bool pci_epc_function_is_valid(struct pci_epc *epc,
> + u8 func_no, u8 vfunc_no)
No need to add 'inline' keyword to function definitions in a .c file. Compiler
will handle that.
- Mani
> +{
> + if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
> + return false;
> +
> + if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + return false;
> +
> + return true;
> +}
> +
> /**
> * pci_epc_get_features() - get the features supported by EPC
> * @epc: the features supported by *this* EPC device will be returned
> @@ -143,10 +155,7 @@ const struct pci_epc_features *pci_epc_get_features(struct pci_epc *epc,
> {
> const struct pci_epc_features *epc_features;
>
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
> - return NULL;
> -
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return NULL;
>
> if (!epc->ops->get_features)
> @@ -216,10 +225,7 @@ int pci_epc_raise_irq(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> {
> int ret;
>
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
> - return -EINVAL;
> -
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return -EINVAL;
>
> if (!epc->ops->raise_irq)
> @@ -260,10 +266,7 @@ int pci_epc_map_msi_irq(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> {
> int ret;
>
> - if (IS_ERR_OR_NULL(epc))
> - return -EINVAL;
> -
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return -EINVAL;
>
> if (!epc->ops->map_msi_irq)
> @@ -291,10 +294,7 @@ int pci_epc_get_msi(struct pci_epc *epc, u8 func_no, u8 vfunc_no)
> {
> int interrupt;
>
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
> - return 0;
> -
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return 0;
>
> if (!epc->ops->get_msi)
> @@ -327,11 +327,10 @@ int pci_epc_set_msi(struct pci_epc *epc, u8 func_no, u8 vfunc_no, u8 interrupts)
> int ret;
> u8 encode_int;
>
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions ||
> - interrupts < 1 || interrupts > 32)
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return -EINVAL;
>
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (interrupts < 1 || interrupts > 32)
> return -EINVAL;
>
> if (!epc->ops->set_msi)
> @@ -359,10 +358,7 @@ int pci_epc_get_msix(struct pci_epc *epc, u8 func_no, u8 vfunc_no)
> {
> int interrupt;
>
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
> - return 0;
> -
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return 0;
>
> if (!epc->ops->get_msix)
> @@ -395,11 +391,10 @@ int pci_epc_set_msix(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> {
> int ret;
>
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions ||
> - interrupts < 1 || interrupts > 2048)
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return -EINVAL;
>
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (interrupts < 1 || interrupts > 2048)
> return -EINVAL;
>
> if (!epc->ops->set_msix)
> @@ -426,10 +421,7 @@ EXPORT_SYMBOL_GPL(pci_epc_set_msix);
> void pci_epc_unmap_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> phys_addr_t phys_addr)
> {
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
> - return;
> -
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return;
>
> if (!epc->ops->unmap_addr)
> @@ -457,10 +449,7 @@ int pci_epc_map_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> {
> int ret;
>
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
> - return -EINVAL;
> -
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return -EINVAL;
>
> if (!epc->ops->map_addr)
> @@ -487,12 +476,11 @@ EXPORT_SYMBOL_GPL(pci_epc_map_addr);
> void pci_epc_clear_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> struct pci_epf_bar *epf_bar)
> {
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions ||
> - (epf_bar->barno == BAR_5 &&
> - epf_bar->flags & PCI_BASE_ADDRESS_MEM_TYPE_64))
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return;
>
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (epf_bar->barno == BAR_5 &&
> + epf_bar->flags & PCI_BASE_ADDRESS_MEM_TYPE_64)
> return;
>
> if (!epc->ops->clear_bar)
> @@ -519,18 +507,16 @@ int pci_epc_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> int ret;
> int flags = epf_bar->flags;
>
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions ||
> - (epf_bar->barno == BAR_5 &&
> - flags & PCI_BASE_ADDRESS_MEM_TYPE_64) ||
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> + return -EINVAL;
> +
> + if ((epf_bar->barno == BAR_5 && flags & PCI_BASE_ADDRESS_MEM_TYPE_64) ||
> (flags & PCI_BASE_ADDRESS_SPACE_IO &&
> flags & PCI_BASE_ADDRESS_IO_MASK) ||
> (upper_32_bits(epf_bar->size) &&
> !(flags & PCI_BASE_ADDRESS_MEM_TYPE_64)))
> return -EINVAL;
>
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> - return -EINVAL;
> -
> if (!epc->ops->set_bar)
> return 0;
>
> @@ -559,10 +545,7 @@ int pci_epc_write_header(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> {
> int ret;
>
> - if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
> - return -EINVAL;
> -
> - if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> return -EINVAL;
>
> /* Only Virtual Function #1 has deviceID */
> --
> 2.44.0
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [RFC][PATCH 0/2] Amlogic T7 (A113D2) Clock Driver
From: Xianwei Zhao @ 2024-04-03 6:44 UTC (permalink / raw)
To: Lucas Tanure, Yu Tu, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stephen Boyd, Michael Turquette
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-clk
In-Reply-To: <20240318114346.112935-1-tanure@linux.com>
Hi Lucas,
As we are preparing the T7 clock patchset, we would like to your
purpose and plan of this RFC patches. Are you going to submit these
patches at last?
On 2024/3/18 19:43, Lucas Tanure wrote:
> [ EXTERNAL EMAIL ]
>
> I am trying to port the T7 clock driver from Khadas 5.4 kernel for Vim4
> to mainline, but I am encountering some issues in the path.
>
> The kernel panics at clk_mux_val_to_index, but I believe that all the
> needed clocks are registered.
>
> If anyone from Amlogic or the community could help me understand what
> my driver is missing, that would be great.
> I will continue to try to figure out, but it has been some weeks
> without progress =/.
>
> Lucas Tanure (2):
> clk: meson: T7: add support for Amlogic T7 SoC PLL clock driver
> arm64: dts: amlogic: t7: SDCard, Ethernet and Clocking
>
> .../amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 66 +
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 189 +
> drivers/clk/meson/Kconfig | 25 +
> drivers/clk/meson/Makefile | 2 +
> drivers/clk/meson/t7-peripherals.c | 6368 +++++++++++++++++
> drivers/clk/meson/t7-peripherals.h | 131 +
> drivers/clk/meson/t7-pll.c | 1543 ++++
> drivers/clk/meson/t7-pll.h | 83 +
> .../clock/amlogic,t7-peripherals-clkc.h | 410 ++
> .../dt-bindings/clock/amlogic,t7-pll-clkc.h | 69 +
> 10 files changed, 8886 insertions(+)
> create mode 100644 drivers/clk/meson/t7-peripherals.c
> create mode 100644 drivers/clk/meson/t7-peripherals.h
> create mode 100644 drivers/clk/meson/t7-pll.c
> create mode 100644 drivers/clk/meson/t7-pll.h
> create mode 100644 include/dt-bindings/clock/amlogic,t7-peripherals-clkc.h
> create mode 100644 include/dt-bindings/clock/amlogic,t7-pll-clkc.h
>
> Starting kernel ...
>
> uboot time: 14277917 us
> boot 64bit kernel
> [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd092]
> [ 0.000000] Linux version 6.8.0-09793-gda876e5b54b3-dirty (tanureal@ryzen) (aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 10.3-2021.07 (arm-10.29)) 10.3.1 20210621, GNU ld (GNU Toolchain for the A-pr4
> [ 0.000000] KASLR disabled due to lack of seed
> [ 0.000000] Machine model: Khadas vim4
> [ 0.000000] efi: UEFI not found.
> [ 0.000000] OF: reserved mem: 0x0000000005000000..0x00000000052fffff (3072 KiB) nomap non-reusable secmon@5000000
> [ 0.000000] OF: reserved mem: 0x0000000005300000..0x00000000072fffff (32768 KiB) nomap non-reusable secmon@5300000
> [ 0.000000] NUMA: No NUMA configuration found
> [ 0.000000] NUMA: Faking a node at [mem 0x0000000000000000-0x00000000df7fffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0xdf10c9c0-0xdf10efff]
> [ 0.000000] Zone ranges:
> [ 0.000000] DMA [mem 0x0000000000000000-0x00000000df7fffff]
> [ 0.000000] DMA32 empty
> [ 0.000000] Normal empty
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000000000000-0x0000000004ffffff]
> [ 0.000000] node 0: [mem 0x0000000005000000-0x00000000072fffff]
> [ 0.000000] node 0: [mem 0x0000000007300000-0x00000000df7fffff]
> [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000000df7fffff]
> [ 0.000000] On node 0, zone DMA: 2048 pages in unavailable ranges
> [ 0.000000] cma: Reserved 32 MiB at 0x00000000d9800000 on node -1
> [ 0.000000] psci: probing for conduit method from DT.
> [ 0.000000] psci: PSCIv1.0 detected in firmware.
> [ 0.000000] psci: Using standard PSCI v0.2 function IDs
> [ 0.000000] psci: Trusted OS migration not required
> [ 0.000000] psci: SMC Calling Convention v1.1
> [ 0.000000] percpu: Embedded 24 pages/cpu s58152 r8192 d31960 u98304
> [ 0.000000] Detected VIPT I-cache on CPU0
> [ 0.000000] CPU features: detected: Spectre-v2
> [ 0.000000] CPU features: detected: Spectre-v4
> [ 0.000000] CPU features: detected: Spectre-BHB
> [ 0.000000] CPU features: detected: ARM erratum 858921
> [ 0.000000] alternatives: applying boot alternatives
> [ 0.000000] Kernel command line: root=UUID=a91e7bfe-4263-4e53-867d-7824e7c6a992 rw rootfstype=ext4 console=ttyS0,921600 no_console_suspend earlycon=ttyS0,0xfe078000 khadas_board=VIM4 androidboot.selinux=permissive androidboot.0
> [ 0.000000] Unknown kernel command line parameters "khadas_board=VIM4", will be passed to user space.
> [ 0.000000] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
> [ 0.000000] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
> [ 0.000000] Fallback order for Node 0: 0
> [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 901152
> [ 0.000000] Policy zone: DMA
> [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
> [ 0.000000] software IO TLB: SWIOTLB bounce buffer size adjusted to 3MB
> [ 0.000000] software IO TLB: area num 8.
> [ 0.000000] software IO TLB: SWIOTLB bounce buffer size roundup to 4MB
> [ 0.000000] software IO TLB: mapped [mem 0x00000000d8e00000-0x00000000d9200000] (4MB)
> [ 0.000000] Memory: 3445944K/3661824K available (16896K kernel code, 4426K rwdata, 9184K rodata, 9728K init, 611K bss, 183112K reserved, 32768K cma-reserved)
> [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
> [ 0.000000] rcu: Preemptible hierarchical RCU implementation.
> [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=8.
> [ 0.000000] Trampoline variant of Tasks RCU enabled.
> [ 0.000000] Tracing variant of Tasks RCU enabled.
> [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
> [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8
> [ 0.000000] RCU Tasks: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1.
> [ 0.000000] RCU Tasks Trace: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1.
> [ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
> [ 0.000000] GIC: GICv2 detected, but range too small and irqchip.gicv2_force_probe not set
> [ 0.000000] Root IRQ handler: gic_handle_irq
> [ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
> [ 0.000000] arch_timer: Enabling local workaround for ARM erratum 858921
> [ 0.000000] arch_timer: CPU0: Trapping CNTVCT access
> [ 0.000000] arch_timer: cp15 timer(s) running at 24.00MHz (phys).
> [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
> [ 0.000000] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns
> [ 0.000210] Console: colour dummy device 80x25
> [ 0.000253] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=96000)
> [ 0.000261] pid_max: default: 32768 minimum: 301
> [ 0.000300] LSM: initializing lsm=capability
> [ 0.000358] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
> [ 0.000371] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
> [ 0.000920] cacheinfo: Unable to detect cache hierarchy for CPU 0
> [ 0.001389] rcu: Hierarchical SRCU implementation.
> [ 0.001391] rcu: Max phase no-delay instances is 1000.
> [ 0.001834] EFI services will not be available.
> [ 0.001999] smp: Bringing up secondary CPUs ...
> [ 0.002408] CPU features: detected: ARM erratum 845719
> [ 0.002426] Detected VIPT I-cache on CPU1
> [ 0.002516] CPU1: Booted secondary processor 0x0000000100 [0x410fd034]
> [ 0.003007] Detected VIPT I-cache on CPU2
> [ 0.003054] CPU2: Booted secondary processor 0x0000000101 [0x410fd034]
> [ 0.003497] Detected VIPT I-cache on CPU3
> [ 0.003546] CPU3: Booted secondary processor 0x0000000102 [0x410fd034]
> [ 0.003988] Detected VIPT I-cache on CPU4
> [ 0.004038] CPU4: Booted secondary processor 0x0000000103 [0x410fd034]
> [ 0.004472] Detected VIPT I-cache on CPU5
> [ 0.004509] arch_timer: Enabling local workaround for ARM erratum 858921
> [ 0.004519] arch_timer: CPU5: Trapping CNTVCT access
> [ 0.004527] CPU5: Booted secondary processor 0x0000000001 [0x410fd092]
> [ 0.004915] Detected VIPT I-cache on CPU6
> [ 0.004940] arch_timer: Enabling local workaround for ARM erratum 858921
> [ 0.004946] arch_timer: CPU6: Trapping CNTVCT access
> [ 0.004951] CPU6: Booted secondary processor 0x0000000002 [0x410fd092]
> [ 0.005333] Detected VIPT I-cache on CPU7
> [ 0.005358] arch_timer: Enabling local workaround for ARM erratum 858921
> [ 0.005364] arch_timer: CPU7: Trapping CNTVCT access
> [ 0.005369] CPU7: Booted secondary processor 0x0000000003 [0x410fd092]
> [ 0.005414] smp: Brought up 1 node, 8 CPUs
> [ 0.005419] SMP: Total of 8 processors activated.
> [ 0.005421] CPU: All CPU(s) started at EL2
> [ 0.005434] CPU features: detected: 32-bit EL0 Support
> [ 0.005437] CPU features: detected: 32-bit EL1 Support
> [ 0.005440] CPU features: detected: CRC32 instructions
> [ 0.005485] alternatives: applying system-wide alternatives
> [ 0.006730] devtmpfs: initialized
> [ 0.008534] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
> [ 0.008545] futex hash table entries: 2048 (order: 5, 131072 bytes, linear)
> [ 0.008989] pinctrl core: initialized pinctrl subsystem
> [ 0.009581] DMI not present or invalid.
> [ 0.011290] NET: Registered PF_NETLINK/PF_ROUTE protocol family
> [ 0.011944] DMA: preallocated 512 KiB GFP_KERNEL pool for atomic allocations
> [ 0.012293] DMA: preallocated 512 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
> [ 0.012711] DMA: preallocated 512 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
> [ 0.012832] audit: initializing netlink subsys (disabled)
> [ 0.013075] audit: type=2000 audit(0.012:1): state=initialized audit_enabled=0 res=1
> [ 0.013508] thermal_sys: Registered thermal governor 'step_wise'
> [ 0.013512] thermal_sys: Registered thermal governor 'power_allocator'
> [ 0.013557] cpuidle: using governor menu
> [ 0.013675] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
> [ 0.013784] ASID allocator initialised with 65536 entries
> [ 0.014630] Serial: AMBA PL011 UART driver
> [ 0.017553] Modules: 22496 pages in range for non-PLT usage
> [ 0.017556] Modules: 514016 pages in range for PLT usage
> [ 0.017980] HugeTLB: registered 1.00 GiB page size, pre-allocated 0 pages
> [ 0.017984] HugeTLB: 0 KiB vmemmap can be freed for a 1.00 GiB page
> [ 0.017988] HugeTLB: registered 32.0 MiB page size, pre-allocated 0 pages
> [ 0.017990] HugeTLB: 0 KiB vmemmap can be freed for a 32.0 MiB page
> [ 0.017993] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages
> [ 0.017995] HugeTLB: 0 KiB vmemmap can be freed for a 2.00 MiB page
> [ 0.017997] HugeTLB: registered 64.0 KiB page size, pre-allocated 0 pages
> [ 0.018000] HugeTLB: 0 KiB vmemmap can be freed for a 64.0 KiB page
> [ 0.018247] Demotion targets for Node 0: null
> [ 0.018884] ACPI: Interpreter disabled.
> [ 0.019584] iommu: Default domain type: Translated
> [ 0.019587] iommu: DMA domain TLB invalidation policy: strict mode
> [ 0.019979] SCSI subsystem initialized
> [ 0.020174] usbcore: registered new interface driver usbfs
> [ 0.020187] usbcore: registered new interface driver hub
> [ 0.020200] usbcore: registered new device driver usb
> [ 0.020434] pps_core: LinuxPPS API ver. 1 registered
> [ 0.020437] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
> [ 0.020443] PTP clock support registered
> [ 0.020487] EDAC MC: Ver: 3.0.0
> [ 0.020717] scmi_core: SCMI protocol bus registered
> [ 0.021039] FPGA manager framework
> [ 0.021076] Advanced Linux Sound Architecture Driver Initialized.
> [ 0.021612] vgaarb: loaded
> [ 0.021857] clocksource: Switched to clocksource arch_sys_counter
> [ 0.021967] VFS: Disk quotas dquot_6.6.0
> [ 0.021984] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
> [ 0.022062] pnp: PnP ACPI: disabled
> [ 0.026651] NET: Registered PF_INET protocol family
> [ 0.026781] IP idents hash table entries: 65536 (order: 7, 524288 bytes, linear)
> [ 0.028598] tcp_listen_portaddr_hash hash table entries: 2048 (order: 3, 32768 bytes, linear)
> [ 0.028615] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
> [ 0.028622] TCP established hash table entries: 32768 (order: 6, 262144 bytes, linear)
> [ 0.028750] TCP bind hash table entries: 32768 (order: 8, 1048576 bytes, linear)
> [ 0.029019] TCP: Hash tables configured (established 32768 bind 32768)
> [ 0.029096] UDP hash table entries: 2048 (order: 4, 65536 bytes, linear)
> [ 0.029124] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes, linear)
> [ 0.029225] NET: Registered PF_UNIX/PF_LOCAL protocol family
> [ 0.029506] RPC: Registered named UNIX socket transport module.
> [ 0.029510] RPC: Registered udp transport module.
> [ 0.029512] RPC: Registered tcp transport module.
> [ 0.029513] RPC: Registered tcp-with-tls transport module.
> [ 0.029515] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [ 0.029524] PCI: CLS 0 bytes, default 64
> [ 0.029649] Unpacking initramfs...
> [ 0.033933] kvm [1]: IPA Size Limit: 40 bits
> [ 0.034713] kvm [1]: Hyp mode initialized successfully
> [ 0.035476] Initialise system trusted keyrings
> [ 0.035582] workingset: timestamp_bits=42 max_order=20 bucket_order=0
> [ 0.035747] squashfs: version 4.0 (2009/01/31) Phillip Lougher
> [ 0.035906] NFS: Registering the id_resolver key type
> [ 0.035919] Key type id_resolver registered
> [ 0.035922] Key type id_legacy registered
> [ 0.035933] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
> [ 0.035935] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
> [ 0.036031] 9p: Installing v9fs 9p2000 file system support
> [ 0.062587] Key type asymmetric registered
> [ 0.062596] Asymmetric key parser 'x509' registered
> [ 0.062657] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245)
> [ 0.062661] io scheduler mq-deadline registered
> [ 0.062664] io scheduler kyber registered
> [ 0.062688] io scheduler bfq registered
> [ 0.063318] irq_meson_gpio: 157 to 12 gpio interrupt mux initialized
> [ 0.068061] EINJ: ACPI disabled.
> [ 0.072570] amlogic_t7_pll_probe
> [ 0.072855] amlogic_t7_pll_probe ret 0
> [ 0.072943] amlogic_a1_periphs_probe
> [ 0.078155] amlogic_a1_periphs_probe ret 0
> [ 0.084876] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> [ 0.086691] fe078000.serial: ttyS0 at MMIO 0xfe078000 (irq = 14, base_baud = 1500000) is a meson_uart
> [ 0.086710] printk: legacy console [ttyS0] enabled
> [ 0.229167] sysfs: cannot create duplicate filename '/class/tty/ttyS0'
> [ 0.229669] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 6.8.0-09793-gda876e5b54b3-dirty #15
> [ 0.230684] Hardware name: Khadas vim4 (DT)
> [ 0.231205] Call trace:
> [ 0.231509] dump_backtrace+0x94/0xec
> [ 0.231963] show_stack+0x18/0x24
> [ 0.232374] dump_stack_lvl+0x78/0x90
> [ 0.232829] dump_stack+0x18/0x24
> [ 0.233241] sysfs_warn_dup+0x64/0x80
> [ 0.233696] sysfs_do_create_link_sd+0xf0/0xf8
> [ 0.234248] sysfs_create_link+0x20/0x40
> [ 0.234736] device_add+0x27c/0x77c
> [ 0.235169] device_register+0x20/0x30
> [ 0.235635] tty_register_device_attr+0xfc/0x240
> [ 0.236209] tty_port_register_device_attr_serdev+0x8c/0xac
> [ 0.236902] serial_core_register_port+0x318/0x658
> [ 0.237498] serial_ctrl_register_port+0x10/0x1c
> [ 0.238072] uart_add_one_port+0x10/0x1c
> [ 0.238560] meson_uart_probe+0x2c0/0x3b4
> [ 0.239058] platform_probe+0x68/0xd8
> [ 0.239513] really_probe+0x148/0x2b4
> [ 0.239968] __driver_probe_device+0x78/0x12c
> [ 0.240510] driver_probe_device+0xdc/0x160
> [ 0.241030] __driver_attach+0x94/0x19c
> [ 0.241507] bus_for_each_dev+0x74/0xd4
> [ 0.241983] driver_attach+0x24/0x30
> [ 0.242428] bus_add_driver+0xe4/0x1e8
> [ 0.242893] driver_register+0x60/0x128
> [ 0.243370] __platform_driver_register+0x28/0x34
> [ 0.243955] meson_uart_platform_driver_init+0x1c/0x28
> [ 0.244594] do_one_initcall+0x6c/0x1b0
> [ 0.245071] kernel_init_freeable+0x1cc/0x294
> [ 0.245613] kernel_init+0x20/0x1dc
> [ 0.246046] ret_from_fork+0x10/0x20
> [ 0.246555] meson_uart fe078000.serial: Cannot register tty device on line 0
> [ 0.247729] msm_serial: driver initialized
> [ 0.248150] SuperH (H)SCI(F) driver initialized
> [ 0.248544] STM32 USART driver initialized
> [ 0.263927] loop: module loaded
> [ 0.264952] megasas: 07.727.03.00-rc1
> [ 0.271065] tun: Universal TUN/TAP device driver, 1.6
> [ 0.271824] thunder_xcv, ver 1.0
> [ 0.271878] thunder_bgx, ver 1.0
> [ 0.271956] nicpf, ver 1.0
> [ 0.273230] hns3: Hisilicon Ethernet Network Driver for Hip08 Family - version
> [ 0.273437] hns3: Copyright (c) 2017 Huawei Corporation.
> [ 0.274148] hclge is initializing
> [ 0.274541] e1000: Intel(R) PRO/1000 Network Driver
> [ 0.275116] e1000: Copyright (c) 1999-2006 Intel Corporation.
> [ 0.275860] e1000e: Intel(R) PRO/1000 Network Driver
> [ 0.276449] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
> [ 0.277209] igb: Intel(R) Gigabit Ethernet Network Driver
> [ 0.277867] igb: Copyright (c) 2007-2014 Intel Corporation.
> [ 0.278576] igbvf: Intel(R) Gigabit Virtual Function Network Driver
> [ 0.279330] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
> [ 0.280319] sky2: driver version 1.30
> [ 0.281597] VFIO - User Level meta-driver version: 0.3
> [ 0.283859] usbcore: registered new interface driver usb-storage
> [ 0.286328] i2c_dev: i2c /dev entries driver
> [ 0.292404] sdhci: Secure Digital Host Controller Interface driver
> [ 0.292481] sdhci: Copyright(c) Pierre Ossman
> [ 0.293577] Synopsys Designware Multimedia Card Interface Driver
> [ 0.294572] sdhci-pltfm: SDHCI platform and OF driver helper
> [ 0.296259] ledtrig-cpu: registered to indicate activity on CPUs
> [ 0.298966] meson-sm: secure-monitor enabled
> [ 0.299963] usbcore: registered new interface driver usbhid
> [ 0.299997] usbhid: USB HID core driver
> [ 0.306803] NET: Registered PF_PACKET protocol family
> [ 0.306919] 9pnet: Installing 9P2000 support
> [ 0.307331] Key type dns_resolver registered
> [ 0.318926] Timer migration: 1 hierarchy levels; 8 children per group; 1 crossnode level
> [ 0.319462] registered taskstats version 1
> [ 0.319968] Loading compiled-in X.509 certificates
> [ 0.362771] clk: Disabling unused clocks
> [ 0.363100] PM: genpd: Disabling unused power domains
> [ 0.363383] ALSA device list:
> [ 0.363580] No soundcards found.
> [ 0.368194] meson-gx-mmc fe08a000.sd: Got CD GPIO
> [ 0.368524] SError Interrupt on CPU6, code 0x00000000bf000002 -- SError
> [ 0.368531] CPU: 6 PID: 87 Comm: kworker/u32:3 Not tainted 6.8.0-09793-gda876e5b54b3-dirty #15
> [ 0.368537] Hardware name: Khadas vim4 (DT)
> [ 0.368540] Workqueue: async async_run_entry_fn
> [ 0.368552] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 0.368556] pc : clk_mux_val_to_index+0x0/0xc0
> [ 0.368565] lr : clk_mux_get_parent+0x4c/0x84
> [ 0.368571] sp : ffff800082efba10
> [ 0.368572] x29: ffff800082efba10 x28: ffff8000823279c0 x27: ffff800082327000
> [ 0.368578] x26: ffff000004c361c0 x25: 0000000000000000 x24: 0000000000000002
> [ 0.368584] x23: ffff000003f1d300 x22: ffff000003f1d2a0 x21: ffff000004c37280
> [ 0.368589] x20: ffff000004c36ec0 x19: ffff000004bba800 x18: 0000000000000020
> [ 0.368594] x17: ffff000000022000 x16: 0000000000000003 x15: ffffffffffffffff
> [ 0.368599] x14: ffffffffffffffff x13: 0078756d2364732e x12: 3030306138306566
> [ 0.368604] x11: 7f7f7f7f7f7f7f7f x10: ffff7fff83438910 x9 : 0000000000000005
> [ 0.368609] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 05114367045e5359
> [ 0.368613] x5 : 0000000000000006 x4 : 0000000000000000 x3 : 0000000000000000
> [ 0.368618] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000004c36ec0
> [ 0.368624] Kernel panic - not syncing: Asynchronous SError Interrupt
> [ 0.368626] CPU: 6 PID: 87 Comm: kworker/u32:3 Not tainted 6.8.0-09793-gda876e5b54b3-dirty #15
> [ 0.368630] Hardware name: Khadas vim4 (DT)
> [ 0.368631] Workqueue: async async_run_entry_fn
> [ 0.368635] Call trace:
> [ 0.368637] dump_backtrace+0x94/0xec
> [ 0.368644] show_stack+0x18/0x24
> [ 0.368649] dump_stack_lvl+0x38/0x90
> [ 0.368656] dump_stack+0x18/0x24
> [ 0.368661] panic+0x388/0x3c8
> [ 0.368666] nmi_panic+0x48/0x94
> [ 0.368670] arm64_serror_panic+0x6c/0x78
> [ 0.368674] do_serror+0x3c/0x78
> [ 0.368677] el1h_64_error_handler+0x30/0x48
> [ 0.368681] el1h_64_error+0x64/0x68
> [ 0.368684] clk_mux_val_to_index+0x0/0xc0
> [ 0.368689] __clk_register+0x440/0x82c
> [ 0.368693] devm_clk_register+0x5c/0xbc
> [ 0.368697] meson_mmc_clk_init+0x11c/0x2a8
> [ 0.368702] meson_mmc_probe+0x18c/0x3c0
> [ 0.368705] platform_probe+0x68/0xd8
> [ 0.368711] really_probe+0x148/0x2b4
> [ 0.368714] __driver_probe_device+0x78/0x12c
> [ 0.368718] driver_probe_device+0xdc/0x160
> [ 0.368721] __device_attach_driver+0xb8/0x134
> [ 0.368724] bus_for_each_drv+0x84/0xe0
> [ 0.368727] __device_attach_async_helper+0xac/0xd0
> [ 0.368730] async_run_entry_fn+0x34/0xe0
> [ 0.368734] process_one_work+0x150/0x294
> [ 0.368740] worker_thread+0x304/0x408
> [ 0.368744] kthread+0x118/0x11c
> [ 0.368748] ret_from_fork+0x10/0x20
> [ 0.368753] SMP: stopping secondary CPUs
> [ 0.368760] Kernel Offset: disabled
> [ 0.368761] CPU features: 0x0,00000060,d0080000,0200421b
> [ 0.368765] Memory Limit: none
> [ 0.400328] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
>
>
> --
> 2.44.0
>
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop
From: Krzysztof Kozlowski @ 2024-04-03 6:44 UTC (permalink / raw)
To: Marc Gonzalez, Kalle Valo, Jeff Johnson, ath10k
Cc: wireless, DT, MSM, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Pierre-Hugues Husson, Arnaud Vrac, Bjorn Andersson, Konrad Dybcio,
Jami Kettunen, Jeffrey Hugo
In-Reply-To: <ea18f91a-710a-4eac-903d-90928caa3090@freebox.fr>
On 30/03/2024 23:04, Marc Gonzalez wrote:
> On 30/03/2024 19:23, Krzysztof Kozlowski wrote:
>
>> On 30/03/2024 19:20, Krzysztof Kozlowski wrote:
>>
>>> On 28/03/2024 18:36, Marc Gonzalez wrote:
>>>
>>>> The ath10k driver waits for an "MSA_READY" indicator
>>>> to complete initialization. If the indicator is not
>>>> received, then the device remains unusable.
>>>>
>>>> cf. ath10k_qmi_driver_event_work()
>>>>
>>>> Several msm8998-based devices are affected by this issue.
>>>> Oddly, it seems safe to NOT wait for the indicator, and
>>>> proceed immediately when QMI_EVENT_SERVER_ARRIVE.
>>>
>>> This is v2, so where is the changelog?
>>
>> Expecting reviewer to dig previous discussions will not help your case.
>> It helps reviewers if you provide necessary information, like resolution
>> of previous discussion in the changelog.
>>
>> I dig the previous discussion, since you did not mention it here, and it
>> seems you entirely ignored its outcome. That's not a DT property.
>>
>> NAK, sorry. Please go back to v1 and read the comments you got there.
>
> My apologies for omitting the changelog.
>
> And I don't blame you for missing the thread's resolution,
> since I made a bit of a mess of it with my various messages.
>
> The firmware-5.bin approach was deemed DOA since these files
> are parsed too late with respect to the required work-around.
> Thus, we went back to either DT or a to-be-written system used
> in the vendor driver.
Then please mention it briefly in the commit msg. Explain there why such
implementation is the correct way to solve your problem.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible
From: Krzysztof Kozlowski @ 2024-04-03 6:40 UTC (permalink / raw)
To: Siddharth Vadapalli
Cc: lee, robh, krzk+dt, conor+dt, devicetree, linux-kernel,
linux-arm-kernel, srk
In-Reply-To: <af61424e-7006-49f5-b614-3caa3674685a@ti.com>
On 03/04/2024 08:32, Siddharth Vadapalli wrote:
> On Wed, Apr 03, 2024 at 08:27:06AM +0200, Krzysztof Kozlowski wrote:
>> On 03/04/2024 07:35, Siddharth Vadapalli wrote:
>>> On Tue, Apr 02, 2024 at 08:06:27PM +0200, Krzysztof Kozlowski wrote:
>>>> On 02/04/2024 14:30, Siddharth Vadapalli wrote:
>>>>> On Tue, Apr 02, 2024 at 02:08:32PM +0200, Krzysztof Kozlowski wrote:
>>>>>> On 02/04/2024 12:57, Siddharth Vadapalli wrote:
>>>>>>> The CTRLMMR_MAC_IDx registers within the CTRL_MMR space of TI's AM62p SoC
>>>>>>> contain the MAC Address programmed in the eFuse. Add compatible for
>>>>>>> allowing the CPSW driver to obtain a regmap for the CTRLMMR_MAC_IDx
>>>>>>> registers within the System Controller device-tree node. The default MAC
>>>>>>> Address for the interface corresponding to the first MAC port will be set
>>>>>>> to the value programmed in the eFuse.
>>>>>>>
>>>>>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>>>>>>> ---
>>>>>>>
>>>>>>> This patch is based on linux-next tagged next-20240402.
>>>>>>
>>>>>> Where is the DTS using it?
>>>>>
>>>>> The current implementation in the device-tree for older TI K3 SoCs is as
>>>>> follows:
>>>>>
>>>>> cpsw_port1: port@1 {
>>>>> reg = <1>;
>>>>> ti,mac-only;
>>>>> label = "port1";
>>>>> phys = <&phy_gmii_sel 1>;
>>>>> mac-address = [00 00 00 00 00 00];
>>>>> ti,syscon-efuse = <&wkup_conf 0x200>;
>>>>> };
>>>>>
>>>>> The "ti,syscon-efuse" property passes the reference to the System
>>>>> Controller node as well as the offset to the CTRLMMR_MAC_IDx registers
>>>>> within the CTRL_MMR space.
>>>>
>>>> Please reference upstream DTS or lore link to patch under review.
>>>
>>> An example of the existing implementation in the device-tree for AM64x
>>> is:
>>> https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L697
>>> It uses:
>>> ti,syscon-efuse = <&main_conf 0x200>;
>>>
>>> and "main_conf" node is defined at:
>>> https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L40
>>
>> It is quite different than your bindings, so your bindings are incorrect.
>
> Sorry I didn't understand what you mean. The references I have provided
> are for existing DTS where "main_conf"/"wkup_conf" (System Controller
> nodes) have the compatible "syscon", unlike in AM62p at:
> https://github.com/torvalds/linux/blob/20f8173afaac90dd9dca11be4aa602a47776077f/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi#L8
> which has the "simple-bus" compatible for the "wkup_conf" node.
>
> Also, shouldn't the device-tree bindings patches be posted first and get
> merged before I post the device-tree patches that utilize the
> compatible/properties that have been added in the bindings? That is the
> reason why I had shared the "DIFF" for the DTS changes that I will be
> posting once this patch for the new compatible is accepted.
>
That's not the process. I will be NAKing bindings which do not have any
users, because I do not trust you test them.
The process is almost always:
1. Send bindings,
2. Send driver changes (if applicable) in the same patchset.
3. Send DTS, usually in separate patches and provide lore link to the
bindings in the changelog or cover letter.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH 5/6] watchdog: ROHM BD96801 PMIC WDG driver
From: Matti Vaittinen @ 2024-04-03 6:34 UTC (permalink / raw)
To: Guenter Roeck
Cc: Matti Vaittinen, Lee Jones, Wim Van Sebroeck, devicetree,
linux-kernel, linux-watchdog
In-Reply-To: <4fa3a64b-60fb-4e5e-8785-0f14da37eea2@roeck-us.net>
Hi Guenter,
First of all, thanks for the review. It was quick! Especially when we
speak of a RFC series. Very much appreciated.
On 4/2/24 20:11, Guenter Roeck wrote:
> On Tue, Apr 02, 2024 at 04:11:41PM +0300, Matti Vaittinen wrote >> +static int init_wdg_hw(struct wdtbd96801 *w)
>> +{
>> + u32 hw_margin[2];
>> + int count, ret;
>> + u32 hw_margin_max = BD96801_WDT_DEFAULT_MARGIN, hw_margin_min = 0;
>> +
>> + count = device_property_count_u32(w->dev->parent, "rohm,hw-timeout-ms");
>> + if (count < 0 && count != -EINVAL)
>> + return count;
>> +
>> + if (count > 0) {
>> + if (count > ARRAY_SIZE(hw_margin))
>> + return -EINVAL;
>> +
>> + ret = device_property_read_u32_array(w->dev->parent,
>> + "rohm,hw-timeout-ms",
>> + &hw_margin[0], count);
>> + if (ret < 0)
>> + return ret;
>> +
>> + if (count == 1)
>> + hw_margin_max = hw_margin[0];
>> +
>> + if (count == 2) {
>> + hw_margin_max = hw_margin[1];
>> + hw_margin_min = hw_margin[0];
>> + }
>> + }
>> +
>> + ret = bd96801_set_wdt_mode(w, hw_margin_max, hw_margin_min);
>> + if (ret)
>> + return ret;
>> +
>> + ret = device_property_match_string(w->dev->parent, "rohm,wdg-action",
>> + "prstb");
>> + if (ret >= 0) {
>> + ret = regmap_update_bits(w->regmap, BD96801_REG_WD_CONF,
>> + BD96801_WD_ASSERT_MASK,
>> + BD96801_WD_ASSERT_RST);
>> + return ret;
>> + }
>> +
>> + ret = device_property_match_string(w->dev->parent, "rohm,wdg-action",
>> + "intb-only");
>> + if (ret >= 0) {
>> + ret = regmap_update_bits(w->regmap, BD96801_REG_WD_CONF,
>> + BD96801_WD_ASSERT_MASK,
>> + BD96801_WD_ASSERT_IRQ);
>> + return ret;
>> + }
>
> I don't see the devicetree bindings documented in the series.
Seems like I have missed this WDG binding. But after reading your
comment below, I am wondering if I should just drop the binding and
default to "prstb" (shutdown should the feeding be skipped) - and leave
the "intb-only" case for one who actually needs such.
> I am also a bit surprised that the interrupt isn't handled in the driver.
> Please explain.
Basically, I just had no idea what the IRQ should do in the generic
case. If we get an interrupt, it means the WDG feeding has failed. My
thinking is that, what should happen is forced reset. I don't see how
that can be done in reliably manner from an IRQ handler.
When the "prstb WDG action" is set (please, see the above DT binding
handling), the PMIC shall shut down power outputs. This should get the
watchdog's job done.
With the "intb-only"-option, PMIC will not turn off the power. I'd
expect there to be some external HW connection which handles the reset
by HW.
After all this being said, I wonder if I should just unconditionally
configure the PMIC to always turn off the power (prstb option) should
the feeding fail? Or do someone have some suggestion what the IRQ
handler should do (except maybe print an error msg)?
>
>> +
>> + return 0;
>> +}
>> +
>> +static int bd96801_wdt_probe(struct platform_device *pdev)
>> +{
>> + struct wdtbd96801 *w;
>> + int ret;
>> + unsigned int val;
>> +
>> + w = devm_kzalloc(&pdev->dev, sizeof(*w), GFP_KERNEL);
>> + if (!w)
>> + return -ENOMEM;
>> +
>> + w->regmap = dev_get_regmap(pdev->dev.parent, NULL);
>
> dev_get_regmap() can return NULL.
>
>> + w->dev = &pdev->dev;
>> +
>> + w->wdt.info = &bd96801_wdt_info;
>> + w->wdt.ops = &bd96801_wdt_ops;
>> + w->wdt.parent = pdev->dev.parent;
>> + w->wdt.timeout = DEFAULT_TIMEOUT;
>> + watchdog_set_drvdata(&w->wdt, w);
>> +
>> + w->always_running = device_property_read_bool(pdev->dev.parent,
>> + "always-running");
>> +
> Without documentation, it looks like the always-running (from
> linux,wdt-gpio.yaml) may be abused. Its defined meaning is
> "the watchdog is always running and can not be stopped". Its
> use here seems to be "start watchdog when loading the module and
> prevent it from being stopped".
Yes. You're right.
> Oh well, looks like the abuse was introduced with bd9576_wdt. That
> doesn't make it better. At the very least it needs to be documented
> that the property does not have the intended (documented) meaning.
I can raise my hand for a sign of an error here. I've been misreading
the intended meaning of the always-running. Not sure if I've picked it
from another driver (maybe GPIO watchdog), or if I've just
misinterpreted the binding docs.
Do you suggest me to add a note in the BD9576 binding doc (there is no
BD9576 specific binding doc for watchdog. I wonder whether this warrants
adding one under watchdog or if the note can be added under
Documentation/devicetree/bindings/mfd/rohm,bd9576...).
>> + ret = regmap_read(w->regmap, BD96801_REG_WD_CONF, &val);
>> + if (ret)
>> + return dev_err_probe(&pdev->dev, ret,
>> + "Failed to get the watchdog state\n");
>> +
>> + /*
>> + * If the WDG is already enabled we assume it is configured by boot.
>> + * In this case we just update the hw-timeout based on values set to
>> + * the timeout / mode registers and leave the hardware configs
>> + * untouched.
>> + */
>> + if ((val & BD96801_WD_EN_MASK) != BD96801_WD_DISABLE) {
>> + dev_dbg(&pdev->dev, "watchdog was running during probe\n");
>> + ret = bd96801_set_heartbeat_from_hw(w, val);
>> + if (ret)
>> + return ret;
>> +
>> + set_bit(WDOG_HW_RUNNING, &w->wdt.status);
>> + } else {
>> + /* If WDG is not running so we will initializate it */
>> + ret = init_wdg_hw(w);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> + watchdog_init_timeout(&w->wdt, 0, pdev->dev.parent);
>> + watchdog_set_nowayout(&w->wdt, nowayout);
>> + watchdog_stop_on_reboot(&w->wdt);
>> +
>> + if (w->always_running)
>> + bd96801_wdt_start(&w->wdt);
>
> I think this needs to set WDOG_HW_RUNNING or the watchdog will trigger
> a reboot if the watchdog device is not opened and the watchdog wasn't
> already running when the module was loaded.
I believe you're right. Seems I haven't properly tested this path.
> That makes me wonder what happens if the property is set and the
> watchdog daemon isn't started in the bd9576_wdt driver.
My assumption is the dog starts barking. I'll see if I find the BD9576
break-out board from one of my boxes to wire it up and test this. If the
always-running is not working it might be justified to just drop it from
both drivers. I believe it'd be indication that no-one is really using
the always-running with the upstream driver.
Thanks a ton!
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ permalink raw reply
* Re: [PATCH 1/2] drm/bridge: lt8912b: add support for P/N pin swap
From: Alexandru Ardelean @ 2024-04-03 6:32 UTC (permalink / raw)
To: Francesco Dolcini
Cc: linux-kernel, dri-devel, devicetree, adrien.grassein,
andrzej.hajda, neil.armstrong, rfoss, Laurent.pinchart, jonas,
jernej.skrabec, airlied, daniel, maarten.lankhorst, mripard,
tzimmermann, robh, krzysztof.kozlowski+dt, conor+dt,
stefan.eichenberger, francesco.dolcini, marius.muresan,
irina.muresan
In-Reply-To: <20240402165307.GA31874@francesco-nb>
On Tue, Apr 2, 2024 at 7:53 PM Francesco Dolcini <francesco@dolcini.it> wrote:
>
> Hello Alexandru, thanks for your patch.
>
> On Tue, Apr 02, 2024 at 01:59:24PM +0300, Alexandru Ardelean wrote:
> > On some HW designs, it's easier for the layout if the P/N pins are swapped.
> > In those cases, we need to adjust (for this) by configuring the MIPI analog
> > registers differently. Specifically, register 0x3e needs to be 0xf6
> > (instead of 0xd6).
> >
> > This change adds a 'lontium,pn-swap' device-tree property to configure the
> > MIPI analog registers for P/N swap.
> >
> > Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
> > ---
> > drivers/gpu/drm/bridge/lontium-lt8912b.c | 25 +++++++++++++++++++++---
> > 1 file changed, 22 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c b/drivers/gpu/drm/bridge/lontium-lt8912b.c
> > index 4b2ae27f0a57f..154126bb922b4 100644
> > --- a/drivers/gpu/drm/bridge/lontium-lt8912b.c
> > +++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
> > @@ -47,6 +47,7 @@ struct lt8912 {
> >
> > u8 data_lanes;
> > bool is_power_on;
> > + bool do_pn_swap;
> > };
> >
> > static int lt8912_write_init_config(struct lt8912 *lt)
> > @@ -78,15 +79,31 @@ static int lt8912_write_init_config(struct lt8912 *lt)
> > {0x55, 0x44},
> > {0x57, 0x01},
> > {0x5a, 0x02},
> > -
> > - /*MIPI Analog*/
> > + };
> > + const struct reg_sequence mipi_analog_seq[] = {
> > {0x3e, 0xd6},
> > {0x3f, 0xd4},
> > {0x41, 0x3c},
> > {0xB2, 0x00},
> > };
> > + const struct reg_sequence mipi_analog_pn_swap_seq[] = {
> > + {0x3e, 0xf6},
> > + {0x3f, 0xd4},
> > + {0x41, 0x3c},
> > + {0xB2, 0x00},
> > + };
> > + int ret;
> >
> > - return regmap_multi_reg_write(lt->regmap[I2C_MAIN], seq, ARRAY_SIZE(seq));
> > + ret = regmap_multi_reg_write(lt->regmap[I2C_MAIN], seq, ARRAY_SIZE(seq));
> > + if (ret < 0)
> > + return ret;
> > +
> > + if (!lt->do_pn_swap)
> > + return regmap_multi_reg_write(lt->regmap[I2C_MAIN], mipi_analog_seq,
> > + ARRAY_SIZE(mipi_analog_seq));
> > +
> > + return regmap_multi_reg_write(lt->regmap[I2C_MAIN], mipi_analog_pn_swap_seq,
> > + ARRAY_SIZE(mipi_analog_pn_swap_seq));
>
> Can you just remove {0x3e, 0xd6} from the register/value array and write
> it afterward depending on `do_pn_swap` value? Or keep it with the
> current value and only overwrite it when do_pn_swap is true?
>
> If you do it this way is a 4 line change.
Hmm, good point.
I did it like this, because I don't have a board with the P/N in the
0xd6 configuration, to test.
But, if I leave it like this, and just overwrite 0x3e when
`do_pn_swap` is true, I can test that; and I don't need to test the
original case.
I'm actually not 100% sure here if the order of registers (being
written) matters for the initialization.
>
>
> > static int lt8912_write_mipi_basic_config(struct lt8912 *lt)
> > @@ -702,6 +719,8 @@ static int lt8912_parse_dt(struct lt8912 *lt)
> > }
> > lt->gp_reset = gp_reset;
> >
> > + lt->do_pn_swap = device_property_read_bool(dev, "lontium,pn-swap");
>
> I would call this variable the same that is called in the lontium
> documentation, mipirx_diff_swap
Oh.
I actually based this change on a reference software for the LT8912B.
I didn't get a chance to see/find a documentation for the registers.
I compared with the Linux driver, to see what was missing to get
output on the HDMI display (for our setup).
>
> Francesco
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible
From: Siddharth Vadapalli @ 2024-04-03 6:32 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Siddharth Vadapalli, lee, robh, krzk+dt, conor+dt, devicetree,
linux-kernel, linux-arm-kernel, srk
In-Reply-To: <eb7a0d5c-c197-44b9-baea-e9b54792b447@kernel.org>
On Wed, Apr 03, 2024 at 08:27:06AM +0200, Krzysztof Kozlowski wrote:
> On 03/04/2024 07:35, Siddharth Vadapalli wrote:
> > On Tue, Apr 02, 2024 at 08:06:27PM +0200, Krzysztof Kozlowski wrote:
> >> On 02/04/2024 14:30, Siddharth Vadapalli wrote:
> >>> On Tue, Apr 02, 2024 at 02:08:32PM +0200, Krzysztof Kozlowski wrote:
> >>>> On 02/04/2024 12:57, Siddharth Vadapalli wrote:
> >>>>> The CTRLMMR_MAC_IDx registers within the CTRL_MMR space of TI's AM62p SoC
> >>>>> contain the MAC Address programmed in the eFuse. Add compatible for
> >>>>> allowing the CPSW driver to obtain a regmap for the CTRLMMR_MAC_IDx
> >>>>> registers within the System Controller device-tree node. The default MAC
> >>>>> Address for the interface corresponding to the first MAC port will be set
> >>>>> to the value programmed in the eFuse.
> >>>>>
> >>>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> >>>>> ---
> >>>>>
> >>>>> This patch is based on linux-next tagged next-20240402.
> >>>>
> >>>> Where is the DTS using it?
> >>>
> >>> The current implementation in the device-tree for older TI K3 SoCs is as
> >>> follows:
> >>>
> >>> cpsw_port1: port@1 {
> >>> reg = <1>;
> >>> ti,mac-only;
> >>> label = "port1";
> >>> phys = <&phy_gmii_sel 1>;
> >>> mac-address = [00 00 00 00 00 00];
> >>> ti,syscon-efuse = <&wkup_conf 0x200>;
> >>> };
> >>>
> >>> The "ti,syscon-efuse" property passes the reference to the System
> >>> Controller node as well as the offset to the CTRLMMR_MAC_IDx registers
> >>> within the CTRL_MMR space.
> >>
> >> Please reference upstream DTS or lore link to patch under review.
> >
> > An example of the existing implementation in the device-tree for AM64x
> > is:
> > https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L697
> > It uses:
> > ti,syscon-efuse = <&main_conf 0x200>;
> >
> > and "main_conf" node is defined at:
> > https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L40
>
> It is quite different than your bindings, so your bindings are incorrect.
Sorry I didn't understand what you mean. The references I have provided
are for existing DTS where "main_conf"/"wkup_conf" (System Controller
nodes) have the compatible "syscon", unlike in AM62p at:
https://github.com/torvalds/linux/blob/20f8173afaac90dd9dca11be4aa602a47776077f/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi#L8
which has the "simple-bus" compatible for the "wkup_conf" node.
Also, shouldn't the device-tree bindings patches be posted first and get
merged before I post the device-tree patches that utilize the
compatible/properties that have been added in the bindings? That is the
reason why I had shared the "DIFF" for the DTS changes that I will be
posting once this patch for the new compatible is accepted.
Regards,
Siddharth.
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible
From: Krzysztof Kozlowski @ 2024-04-03 6:27 UTC (permalink / raw)
To: Siddharth Vadapalli
Cc: lee, robh, krzk+dt, conor+dt, devicetree, linux-kernel,
linux-arm-kernel, srk
In-Reply-To: <aabea385-16e0-4116-a12b-3ce1e06574e3@ti.com>
On 03/04/2024 07:35, Siddharth Vadapalli wrote:
> On Tue, Apr 02, 2024 at 08:06:27PM +0200, Krzysztof Kozlowski wrote:
>> On 02/04/2024 14:30, Siddharth Vadapalli wrote:
>>> On Tue, Apr 02, 2024 at 02:08:32PM +0200, Krzysztof Kozlowski wrote:
>>>> On 02/04/2024 12:57, Siddharth Vadapalli wrote:
>>>>> The CTRLMMR_MAC_IDx registers within the CTRL_MMR space of TI's AM62p SoC
>>>>> contain the MAC Address programmed in the eFuse. Add compatible for
>>>>> allowing the CPSW driver to obtain a regmap for the CTRLMMR_MAC_IDx
>>>>> registers within the System Controller device-tree node. The default MAC
>>>>> Address for the interface corresponding to the first MAC port will be set
>>>>> to the value programmed in the eFuse.
>>>>>
>>>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>>>>> ---
>>>>>
>>>>> This patch is based on linux-next tagged next-20240402.
>>>>
>>>> Where is the DTS using it?
>>>
>>> The current implementation in the device-tree for older TI K3 SoCs is as
>>> follows:
>>>
>>> cpsw_port1: port@1 {
>>> reg = <1>;
>>> ti,mac-only;
>>> label = "port1";
>>> phys = <&phy_gmii_sel 1>;
>>> mac-address = [00 00 00 00 00 00];
>>> ti,syscon-efuse = <&wkup_conf 0x200>;
>>> };
>>>
>>> The "ti,syscon-efuse" property passes the reference to the System
>>> Controller node as well as the offset to the CTRLMMR_MAC_IDx registers
>>> within the CTRL_MMR space.
>>
>> Please reference upstream DTS or lore link to patch under review.
>
> An example of the existing implementation in the device-tree for AM64x
> is:
> https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L697
> It uses:
> ti,syscon-efuse = <&main_conf 0x200>;
>
> and "main_conf" node is defined at:
> https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L40
It is quite different than your bindings, so your bindings are incorrect.
Please fix them and send when your DTS is ready.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: display: bridge: lt8912b: document 'lontium,pn-swap' property
From: Alexandru Ardelean @ 2024-04-03 6:16 UTC (permalink / raw)
To: Conor Dooley
Cc: linux-kernel, dri-devel, devicetree, adrien.grassein,
andrzej.hajda, neil.armstrong, rfoss, Laurent.pinchart, jonas,
jernej.skrabec, airlied, daniel, maarten.lankhorst, mripard,
tzimmermann, robh, krzysztof.kozlowski+dt, conor+dt,
stefan.eichenberger, francesco.dolcini, marius.muresan,
irina.muresan
In-Reply-To: <20240402-sheet-retread-025759b22faf@spud>
On Tue, Apr 2, 2024 at 9:06 PM Conor Dooley <conor@kernel.org> wrote:
>
> On Tue, Apr 02, 2024 at 01:59:25PM +0300, Alexandru Ardelean wrote:
> > On some HW designs, it's easier for the layout if the P/N pins are swapped.
> > The driver currently has a DT property to do that.
>
> "currently", because 1/2 adds it. bindings patches should precede the
> driver patches in the series, so please swap the patches and remove this
> portion of the description.
ack;
i'll invert the order and remove this;
>
> >
> > This change documents the 'lontium,pn-swap' property.
> >
> > Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
> > ---
> > .../devicetree/bindings/display/bridge/lontium,lt8912b.yaml | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
> > index 2cef252157985..3a804926b288a 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
> > @@ -24,6 +24,12 @@ properties:
> > maxItems: 1
> > description: GPIO connected to active high RESET pin.
> >
> > + lontium,pn-swap:
> > + description: Swap the polarities of the P/N pins in software.
> > + On some HW designs, the layout is simplified if the P/N pins
> > + are inverted.
>
> Please explain what configuration of a board would cause these to be
> swapped, rather than why someone might want to configure the board this
> way. I've got no idea what this hardware is actually doing, so this is
> being pulled out of a hat, but I'd expect something like "Some boards
> swap the polarity of the P/N pins, use this property to indicate this to
> software".
ack
if it's fine with you, i'll use your suggested description;
for a broader context, we were using a DSI-HDMI converter [1] from
SomLabs on a different (than SomLabs) board;
and we were not seeing anything on the HDMI-connected display;
as I understand it, some DSI-HDMI bridges support P/N auto-inversion;
this one doesn't AFAICT;
on this DSI-HDMI converter [1], we've noticed that the P/N pins were
inverted from the DSI to the chip (vs what we expected to see)
after changing the register value (for the P/N swap), it worked;
our conclusion was that, the design of the converter (board) was done
as-such, because it made the layout easier
[1] https://wiki.somlabs.com/index.php/SL-MIPI-LVDS-HDMI-CNV-11_Datasheet_and_Pinout
>
> > + type: boolean
>
> The type here should be flag.
ack; i'll change the type
>
> Cheers,
> Conor.
>
> > +
> > ports:
> > $ref: /schemas/graph.yaml#/properties/ports
> >
> > --
> > 2.44.0
> >
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: syscon: Add ti,am62p-cpsw-mac-efuse compatible
From: Siddharth Vadapalli @ 2024-04-03 5:35 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Siddharth Vadapalli, lee, robh, krzk+dt, conor+dt, devicetree,
linux-kernel, linux-arm-kernel, srk
In-Reply-To: <4b1380a8-0136-4395-ba42-9bcff2e1bdb0@kernel.org>
On Tue, Apr 02, 2024 at 08:06:27PM +0200, Krzysztof Kozlowski wrote:
> On 02/04/2024 14:30, Siddharth Vadapalli wrote:
> > On Tue, Apr 02, 2024 at 02:08:32PM +0200, Krzysztof Kozlowski wrote:
> >> On 02/04/2024 12:57, Siddharth Vadapalli wrote:
> >>> The CTRLMMR_MAC_IDx registers within the CTRL_MMR space of TI's AM62p SoC
> >>> contain the MAC Address programmed in the eFuse. Add compatible for
> >>> allowing the CPSW driver to obtain a regmap for the CTRLMMR_MAC_IDx
> >>> registers within the System Controller device-tree node. The default MAC
> >>> Address for the interface corresponding to the first MAC port will be set
> >>> to the value programmed in the eFuse.
> >>>
> >>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> >>> ---
> >>>
> >>> This patch is based on linux-next tagged next-20240402.
> >>
> >> Where is the DTS using it?
> >
> > The current implementation in the device-tree for older TI K3 SoCs is as
> > follows:
> >
> > cpsw_port1: port@1 {
> > reg = <1>;
> > ti,mac-only;
> > label = "port1";
> > phys = <&phy_gmii_sel 1>;
> > mac-address = [00 00 00 00 00 00];
> > ti,syscon-efuse = <&wkup_conf 0x200>;
> > };
> >
> > The "ti,syscon-efuse" property passes the reference to the System
> > Controller node as well as the offset to the CTRLMMR_MAC_IDx registers
> > within the CTRL_MMR space.
>
> Please reference upstream DTS or lore link to patch under review.
An example of the existing implementation in the device-tree for AM64x
is:
https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L697
It uses:
ti,syscon-efuse = <&main_conf 0x200>;
and "main_conf" node is defined at:
https://github.com/torvalds/linux/blob/d4e8c8ad5d14ad51ed8813442d81c43019fd669d/arch/arm64/boot/dts/ti/k3-am64-main.dtsi#L40
Regards,
Siddharth.
^ permalink raw reply
* [PATCH v4 5/7] PCI: dwc: rcar-gen4: Add .ltssm_enable() for other SoC support
From: Yoshihiro Shimoda @ 2024-04-03 5:33 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda
In-Reply-To: <20240403053304.3695096-1-yoshihiro.shimoda.uh@renesas.com>
This driver can reuse other R-Car Gen4 SoCs support like r8a779g0 and
r8a779h0. However, r8a779g0 and r8a779h0 require other initializing
settings that differ than r8a779f0. So, add a new function pointer
.ltssm_enable() for it. No behavior changes.
After applied this patch, probing SoCs by rcar_gen4_pcie_of_match[]
will be changed like below:
- r8a779f0 as "renesas,r8a779f0-pcie" and "renesas,r8a779f0-pcie-ep"
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/pci/controller/dwc/pcie-rcar-gen4.c | 41 ++++++++++++++++++---
1 file changed, 36 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
index da2821d6efce..e760bcd30c4e 100644
--- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
+++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
@@ -48,7 +48,9 @@
#define RCAR_GEN4_PCIE_EP_FUNC_DBI_OFFSET 0x1000
#define RCAR_GEN4_PCIE_EP_FUNC_DBI2_OFFSET 0x800
+struct rcar_gen4_pcie;
struct rcar_gen4_pcie_platdata {
+ int (*ltssm_enable)(struct rcar_gen4_pcie *rcar);
enum dw_pcie_device_mode mode;
};
@@ -61,8 +63,8 @@ struct rcar_gen4_pcie {
#define to_rcar_gen4_pcie(_dw) container_of(_dw, struct rcar_gen4_pcie, dw)
/* Common */
-static void rcar_gen4_pcie_ltssm_enable(struct rcar_gen4_pcie *rcar,
- bool enable)
+static void rcar_gen4_pcie_ltssm_control(struct rcar_gen4_pcie *rcar,
+ bool enable)
{
u32 val;
@@ -127,9 +129,13 @@ static int rcar_gen4_pcie_speed_change(struct dw_pcie *dw)
static int rcar_gen4_pcie_start_link(struct dw_pcie *dw)
{
struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
- int i, changes;
+ int i, changes, ret;
- rcar_gen4_pcie_ltssm_enable(rcar, true);
+ if (rcar->platdata->ltssm_enable) {
+ ret = rcar->platdata->ltssm_enable(rcar);
+ if (ret)
+ return ret;
+ }
/*
* Require direct speed change with retrying here if the link_gen is
@@ -157,7 +163,7 @@ static void rcar_gen4_pcie_stop_link(struct dw_pcie *dw)
{
struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
- rcar_gen4_pcie_ltssm_enable(rcar, false);
+ rcar_gen4_pcie_ltssm_control(rcar, false);
}
static int rcar_gen4_pcie_common_init(struct rcar_gen4_pcie *rcar)
@@ -504,6 +510,23 @@ static void rcar_gen4_pcie_remove(struct platform_device *pdev)
rcar_gen4_pcie_unprepare(rcar);
}
+static int r8a779f0_pcie_ltssm_enable(struct rcar_gen4_pcie *rcar)
+{
+ rcar_gen4_pcie_ltssm_control(rcar, true);
+
+ return 0;
+}
+
+static struct rcar_gen4_pcie_platdata platdata_r8a779f0_pcie = {
+ .ltssm_enable = r8a779f0_pcie_ltssm_enable,
+ .mode = DW_PCIE_RC_TYPE,
+};
+
+static struct rcar_gen4_pcie_platdata platdata_r8a779f0_pcie_ep = {
+ .ltssm_enable = r8a779f0_pcie_ltssm_enable,
+ .mode = DW_PCIE_EP_TYPE,
+};
+
static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie = {
.mode = DW_PCIE_RC_TYPE,
};
@@ -513,6 +536,14 @@ static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie_ep = {
};
static const struct of_device_id rcar_gen4_pcie_of_match[] = {
+ {
+ .compatible = "renesas,r8a779f0-pcie",
+ .data = &platdata_r8a779f0_pcie,
+ },
+ {
+ .compatible = "renesas,r8a779f04-pcie-ep",
+ .data = &platdata_r8a779f0_pcie_ep,
+ },
{
.compatible = "renesas,rcar-gen4-pcie",
.data = &platdata_rcar_gen4_pcie,
--
2.25.1
^ permalink raw reply related
* [PATCH v4 7/7] misc: pci_endpoint_test: Document a policy about adding pci_device_id
From: Yoshihiro Shimoda @ 2024-04-03 5:33 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda, Frank Li
In-Reply-To: <20240403053304.3695096-1-yoshihiro.shimoda.uh@renesas.com>
To avoid becoming struct pci_device_id pci_endpoint_test_tbl longer
and longer, document a policy. For example, if PCIe endpoint controller
can configure vendor id and/or product id, you can reuse one of
existing entries to test.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
Cc: Frank Li <Frank.li@nxp.com>
---
drivers/misc/pci_endpoint_test.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index c38a6083f0a7..3c8a0afad91d 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -980,6 +980,7 @@ static const struct pci_endpoint_test_data j721e_data = {
.irq_type = IRQ_TYPE_MSI,
};
+/* Don't need to add a new entry if you can use existing entry to test */
static const struct pci_device_id pci_endpoint_test_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA74x),
.driver_data = (kernel_ulong_t)&default_data,
--
2.25.1
^ permalink raw reply related
* [PATCH v4 3/7] PCI: dwc: Add PCIE_PORT_{FORCE,LANE_SKEW} macros
From: Yoshihiro Shimoda @ 2024-04-03 5:33 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda
In-Reply-To: <20240403053304.3695096-1-yoshihiro.shimoda.uh@renesas.com>
R-Car Gen4 PCIe controller needs to use the Synopsys-specific PCIe
configuration registers. So, add the macros.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/pci/controller/dwc/pcie-designware.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 26dae4837462..aa4db6eaf02a 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -71,6 +71,9 @@
#define LINK_WAIT_IATU 9
/* Synopsys-specific PCIe configuration registers */
+#define PCIE_PORT_FORCE 0x708
+#define PORT_FORCE_DO_DESKEW_FOR_SRIS BIT(23)
+
#define PCIE_PORT_AFR 0x70C
#define PORT_AFR_N_FTS_MASK GENMASK(15, 8)
#define PORT_AFR_N_FTS(n) FIELD_PREP(PORT_AFR_N_FTS_MASK, n)
@@ -92,6 +95,9 @@
#define PORT_LINK_MODE_4_LANES PORT_LINK_MODE(0x7)
#define PORT_LINK_MODE_8_LANES PORT_LINK_MODE(0xf)
+#define PCIE_PORT_LANE_SKEW 0x714
+#define PORT_LANE_SKEW_INSERT_MASK GENMASK(23, 0)
+
#define PCIE_PORT_DEBUG0 0x728
#define PORT_LOGIC_LTSSM_STATE_MASK 0x1f
#define PORT_LOGIC_LTSSM_STATE_L0 0x11
--
2.25.1
^ permalink raw reply related
* [PATCH v4 6/7] PCI: dwc: rcar-gen4: Add support for r8a779g0
From: Yoshihiro Shimoda @ 2024-04-03 5:33 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda
In-Reply-To: <20240403053304.3695096-1-yoshihiro.shimoda.uh@renesas.com>
This driver previously supported r8a779f0 (R-Car S4-8). Add support
for r8a779g0 (R-Car V4H).
To support r8a779g0, it requires specific firmware.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/pci/controller/dwc/pcie-rcar-gen4.c | 201 +++++++++++++++++++-
1 file changed, 200 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
index e760bcd30c4e..5d5a088bd2c1 100644
--- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
+++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
@@ -5,8 +5,10 @@
*/
#include <linux/delay.h>
+#include <linux/firmware.h>
#include <linux/interrupt.h>
#include <linux/io.h>
+#include <linux/iopoll.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/pci.h>
@@ -20,9 +22,10 @@
/* Renesas-specific */
/* PCIe Mode Setting Register 0 */
#define PCIEMSR0 0x0000
-#define BIFUR_MOD_SET_ON BIT(0)
+#define APP_SRIS_MODE BIT(6)
#define DEVICE_TYPE_EP 0
#define DEVICE_TYPE_RC BIT(4)
+#define BIFUR_MOD_SET_ON BIT(0)
/* PCIe Interrupt Status 0 */
#define PCIEINTSTS0 0x0084
@@ -37,19 +40,47 @@
#define PCIEDMAINTSTSEN 0x0314
#define PCIEDMAINTSTSEN_INIT GENMASK(15, 0)
+/* Port Logic Registers 89 */
+#define PRTLGC89 0x0b70
+
+/* Port Logic Registers 90 */
+#define PRTLGC90 0x0b74
+
/* PCIe Reset Control Register 1 */
#define PCIERSTCTRL1 0x0014
#define APP_HOLD_PHY_RST BIT(16)
#define APP_LTSSM_ENABLE BIT(0)
+/* PCIe Power Management Control */
+#define PCIEPWRMNGCTRL 0x0070
+#define APP_CLK_REQ_N BIT(11)
+#define APP_CLK_PM_EN BIT(10)
+
+/*
+ * The R-Car Gen4 documents don't describe the PHY registers' name.
+ * But, the initialization procedure describes these offsets. So,
+ * this driver makes up own #defines for the offsets.
+ */
+#define RCAR_GEN4_PCIE_PHY_0f8 0x0f8
+#define RCAR_GEN4_PCIE_PHY_148 0x148
+#define RCAR_GEN4_PCIE_PHY_1d4 0x1d4
+#define RCAR_GEN4_PCIE_PHY_514 0x514
+#define RCAR_GEN4_PCIE_PHY_700 0x700
+
#define RCAR_NUM_SPEED_CHANGE_RETRIES 10
#define RCAR_MAX_LINK_SPEED 4
#define RCAR_GEN4_PCIE_EP_FUNC_DBI_OFFSET 0x1000
#define RCAR_GEN4_PCIE_EP_FUNC_DBI2_OFFSET 0x800
+#define RCAR_GEN4_PCIE_FIRMWARE_NAME "rcar_gen4_pcie.bin"
+#define RCAR_GEN4_PCIE_FIRMWARE_BASE_ADDR 0xc000
+
+MODULE_FIRMWARE(RCAR_GEN4_PCIE_FIRMWARE_NAME);
+
struct rcar_gen4_pcie;
struct rcar_gen4_pcie_platdata {
+ void (*additional_common_init)(struct rcar_gen4_pcie *rcar);
int (*ltssm_enable)(struct rcar_gen4_pcie *rcar);
enum dw_pcie_device_mode mode;
};
@@ -57,12 +88,144 @@ struct rcar_gen4_pcie_platdata {
struct rcar_gen4_pcie {
struct dw_pcie dw;
void __iomem *base;
+ void __iomem *phy_base;
struct platform_device *pdev;
const struct rcar_gen4_pcie_platdata *platdata;
};
#define to_rcar_gen4_pcie(_dw) container_of(_dw, struct rcar_gen4_pcie, dw)
/* Common */
+static void rcar_gen4_pcie_phy_reg_update_bits(struct rcar_gen4_pcie *rcar,
+ u32 offset, u32 mask, u32 val)
+{
+ u32 tmp;
+
+ tmp = readl(rcar->phy_base + offset);
+ tmp &= ~mask;
+ tmp |= val;
+ writel(tmp, rcar->phy_base + offset);
+}
+
+static int rcar_gen4_pcie_reg_check_bit(struct rcar_gen4_pcie *rcar,
+ u32 offset, u32 mask)
+{
+ struct dw_pcie *dw = &rcar->dw;
+
+ if (dw_pcie_readl_dbi(dw, offset) & mask)
+ return -EAGAIN;
+
+ return 0;
+}
+
+static int rcar_gen4_pcie_update_phy_firmware(struct rcar_gen4_pcie *rcar)
+{
+ const u32 check_addr[] = { 0x00101018, 0x00101118, 0x00101021, 0x00101121};
+ struct dw_pcie *dw = &rcar->dw;
+ const struct firmware *fw;
+ unsigned int i, timeout;
+ u32 data;
+ int ret;
+
+ ret = request_firmware(&fw, RCAR_GEN4_PCIE_FIRMWARE_NAME, dw->dev);
+ if (ret) {
+ dev_err(dw->dev, "%s: Requesting firmware failed\n", __func__);
+ return ret;
+ }
+
+ for (i = 0; i < (fw->size / 2); i++) {
+ data = fw->data[i * 2] | fw->data[(i * 2) + 1] << 8;
+ timeout = 100;
+ do {
+ dw_pcie_writel_dbi(dw, PRTLGC89, RCAR_GEN4_PCIE_FIRMWARE_BASE_ADDR + i);
+ dw_pcie_writel_dbi(dw, PRTLGC90, data);
+ if (rcar_gen4_pcie_reg_check_bit(rcar, PRTLGC89, BIT(30)) >= 0)
+ break;
+ if (!(--timeout)) {
+ ret = -ETIMEDOUT;
+ goto exit;
+ }
+ usleep_range(100, 200);
+ } while (1);
+ }
+
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_0f8, BIT(17), BIT(17));
+
+ for (i = 0; i < ARRAY_SIZE(check_addr); i++) {
+ timeout = 100;
+ do {
+ dw_pcie_writel_dbi(dw, PRTLGC89, check_addr[i]);
+ ret = rcar_gen4_pcie_reg_check_bit(rcar, PRTLGC89, BIT(30));
+ ret |= rcar_gen4_pcie_reg_check_bit(rcar, PRTLGC90, BIT(0));
+ if (ret >= 0)
+ break;
+ if (!(--timeout)) {
+ ret = -ETIMEDOUT;
+ goto exit;
+ }
+ usleep_range(100, 200);
+ } while (1);
+ }
+
+ ret = 0;
+exit:
+ release_firmware(fw);
+
+ return ret;
+}
+
+static int rcar_gen4_pcie_enable_phy(struct rcar_gen4_pcie *rcar)
+{
+ struct dw_pcie *dw = &rcar->dw;
+ u32 val;
+ int ret;
+
+ val = dw_pcie_readl_dbi(dw, PCIE_PORT_FORCE);
+ val |= PORT_FORCE_DO_DESKEW_FOR_SRIS;
+ dw_pcie_writel_dbi(dw, PCIE_PORT_FORCE, val);
+
+ val = readl(rcar->base + PCIEMSR0);
+ val |= APP_SRIS_MODE;
+ writel(val, rcar->base + PCIEMSR0);
+
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_700, BIT(28), 0);
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_700, BIT(20), 0);
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_700, BIT(12), 0);
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_700, BIT(4), 0);
+
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_148,
+ GENMASK(23, 22), BIT(22));
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_148,
+ GENMASK(18, 16), GENMASK(17, 16));
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_148,
+ GENMASK(7, 6), BIT(6));
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_148,
+ GENMASK(2, 0), GENMASK(11, 0));
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_1d4,
+ GENMASK(16, 15), GENMASK(16, 15));
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_514, BIT(26), BIT(26));
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_0f8, BIT(16), 0);
+ rcar_gen4_pcie_phy_reg_update_bits(rcar, RCAR_GEN4_PCIE_PHY_0f8, BIT(19), BIT(19));
+
+ val = readl(rcar->base + PCIERSTCTRL1);
+ val &= ~APP_HOLD_PHY_RST;
+ writel(val, rcar->base + PCIERSTCTRL1);
+
+ ret = readl_poll_timeout(rcar->phy_base + RCAR_GEN4_PCIE_PHY_0f8, val,
+ !(val & BIT(18)), 100, 10000);
+ if (ret < 0)
+ return ret;
+
+ ret = rcar_gen4_pcie_update_phy_firmware(rcar);
+ if (ret)
+ return ret;
+
+ val = readl(rcar->base + PCIERSTCTRL1);
+ val |= APP_LTSSM_ENABLE;
+ writel(val, rcar->base + PCIERSTCTRL1);
+
+ return 0;
+}
+
static void rcar_gen4_pcie_ltssm_control(struct rcar_gen4_pcie *rcar,
bool enable)
{
@@ -200,6 +363,9 @@ static int rcar_gen4_pcie_common_init(struct rcar_gen4_pcie *rcar)
if (ret)
goto err_unprepare;
+ if (rcar->platdata->additional_common_init)
+ rcar->platdata->additional_common_init(rcar);
+
return 0;
err_unprepare:
@@ -241,6 +407,10 @@ static void rcar_gen4_pcie_unprepare(struct rcar_gen4_pcie *rcar)
static int rcar_gen4_pcie_get_resources(struct rcar_gen4_pcie *rcar)
{
+ rcar->phy_base = devm_platform_ioremap_resource_byname(rcar->pdev, "phy");
+ if (IS_ERR(rcar->phy_base))
+ return PTR_ERR(rcar->base);
+
/* Renesas-specific registers */
rcar->base = devm_platform_ioremap_resource_byname(rcar->pdev, "app");
@@ -517,6 +687,31 @@ static int r8a779f0_pcie_ltssm_enable(struct rcar_gen4_pcie *rcar)
return 0;
}
+static void rcar_gen4_pcie_additional_common_init(struct rcar_gen4_pcie *rcar)
+{
+ struct dw_pcie *dw = &rcar->dw;
+ u32 val;
+
+ /*
+ * The SoC manual said the register setting is required. Otherwise,
+ * linkup failed.
+ */
+ val = dw_pcie_readl_dbi(dw, PCIE_PORT_LANE_SKEW);
+ val &= ~PORT_LANE_SKEW_INSERT_MASK;
+ if (dw->num_lanes < 4)
+ val |= BIT(6);
+ dw_pcie_writel_dbi(dw, PCIE_PORT_LANE_SKEW, val);
+
+ val = readl(rcar->base + PCIEPWRMNGCTRL);
+ val |= APP_CLK_REQ_N | APP_CLK_PM_EN;
+ writel(val, rcar->base + PCIEPWRMNGCTRL);
+}
+
+static int rcar_gen4_pcie_ltssm_enable(struct rcar_gen4_pcie *rcar)
+{
+ return rcar_gen4_pcie_enable_phy(rcar);
+}
+
static struct rcar_gen4_pcie_platdata platdata_r8a779f0_pcie = {
.ltssm_enable = r8a779f0_pcie_ltssm_enable,
.mode = DW_PCIE_RC_TYPE,
@@ -528,10 +723,14 @@ static struct rcar_gen4_pcie_platdata platdata_r8a779f0_pcie_ep = {
};
static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie = {
+ .additional_common_init = rcar_gen4_pcie_additional_common_init,
+ .ltssm_enable = rcar_gen4_pcie_ltssm_enable,
.mode = DW_PCIE_RC_TYPE,
};
static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie_ep = {
+ .additional_common_init = rcar_gen4_pcie_additional_common_init,
+ .ltssm_enable = rcar_gen4_pcie_ltssm_enable,
.mode = DW_PCIE_EP_TYPE,
};
--
2.25.1
^ permalink raw reply related
* [PATCH v4 2/7] dt-bindings: PCI: rcar-gen4-pci-ep: Add R-Car V4H compatible
From: Yoshihiro Shimoda @ 2024-04-03 5:32 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda, Conor Dooley, Geert Uytterhoeven
In-Reply-To: <20240403053304.3695096-1-yoshihiro.shimoda.uh@renesas.com>
Document bindings for R-Car V4H (R8A779G0) PCIe endpoint module.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml
index fe38f62da066..91b81ac75592 100644
--- a/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml
@@ -16,7 +16,9 @@ allOf:
properties:
compatible:
items:
- - const: renesas,r8a779f0-pcie-ep # R-Car S4-8
+ - enum:
+ - renesas,r8a779f0-pcie-ep # R-Car S4-8
+ - renesas,r8a779g0-pcie-ep # R-Car V4H
- const: renesas,rcar-gen4-pcie-ep # R-Car Gen4
reg:
--
2.25.1
^ permalink raw reply related
* [PATCH v4 4/7] PCI: dwc: rcar-gen4: Add rcar_gen4_pcie_platdata
From: Yoshihiro Shimoda @ 2024-04-03 5:33 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda
In-Reply-To: <20240403053304.3695096-1-yoshihiro.shimoda.uh@renesas.com>
This driver supports r8a779f0 now. In the future, add support for
r8a779g0 and r8a779h0. To support these new SoCs, need other
initializing settings. So, at first, add rcar_gen4_pcie_platdata
and have a member with mode. No behavior changes.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/pci/controller/dwc/pcie-rcar-gen4.c | 30 ++++++++++++++-------
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
index 0be760ed420b..da2821d6efce 100644
--- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
+++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
@@ -48,11 +48,15 @@
#define RCAR_GEN4_PCIE_EP_FUNC_DBI_OFFSET 0x1000
#define RCAR_GEN4_PCIE_EP_FUNC_DBI2_OFFSET 0x800
+struct rcar_gen4_pcie_platdata {
+ enum dw_pcie_device_mode mode;
+};
+
struct rcar_gen4_pcie {
struct dw_pcie dw;
void __iomem *base;
struct platform_device *pdev;
- enum dw_pcie_device_mode mode;
+ const struct rcar_gen4_pcie_platdata *platdata;
};
#define to_rcar_gen4_pcie(_dw) container_of(_dw, struct rcar_gen4_pcie, dw)
@@ -137,7 +141,7 @@ static int rcar_gen4_pcie_start_link(struct dw_pcie *dw)
* Since dw_pcie_setup_rc() sets it once, PCIe Gen2 will be trained.
* So, this needs remaining times for up to PCIe Gen4 if RC mode.
*/
- if (changes && rcar->mode == DW_PCIE_RC_TYPE)
+ if (changes && rcar->platdata->mode == DW_PCIE_RC_TYPE)
changes--;
for (i = 0; i < changes; i++) {
@@ -172,9 +176,9 @@ static int rcar_gen4_pcie_common_init(struct rcar_gen4_pcie *rcar)
reset_control_assert(dw->core_rsts[DW_PCIE_PWR_RST].rstc);
val = readl(rcar->base + PCIEMSR0);
- if (rcar->mode == DW_PCIE_RC_TYPE) {
+ if (rcar->platdata->mode == DW_PCIE_RC_TYPE) {
val |= DEVICE_TYPE_RC;
- } else if (rcar->mode == DW_PCIE_EP_TYPE) {
+ } else if (rcar->platdata->mode == DW_PCIE_EP_TYPE) {
val |= DEVICE_TYPE_EP;
} else {
ret = -EINVAL;
@@ -437,9 +441,9 @@ static void rcar_gen4_remove_dw_pcie_ep(struct rcar_gen4_pcie *rcar)
/* Common */
static int rcar_gen4_add_dw_pcie(struct rcar_gen4_pcie *rcar)
{
- rcar->mode = (uintptr_t)of_device_get_match_data(&rcar->pdev->dev);
+ rcar->platdata = of_device_get_match_data(&rcar->pdev->dev);
- switch (rcar->mode) {
+ switch (rcar->platdata->mode) {
case DW_PCIE_RC_TYPE:
return rcar_gen4_add_dw_pcie_rp(rcar);
case DW_PCIE_EP_TYPE:
@@ -480,7 +484,7 @@ static int rcar_gen4_pcie_probe(struct platform_device *pdev)
static void rcar_gen4_remove_dw_pcie(struct rcar_gen4_pcie *rcar)
{
- switch (rcar->mode) {
+ switch (rcar->platdata->mode) {
case DW_PCIE_RC_TYPE:
rcar_gen4_remove_dw_pcie_rp(rcar);
break;
@@ -500,14 +504,22 @@ static void rcar_gen4_pcie_remove(struct platform_device *pdev)
rcar_gen4_pcie_unprepare(rcar);
}
+static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie = {
+ .mode = DW_PCIE_RC_TYPE,
+};
+
+static struct rcar_gen4_pcie_platdata platdata_rcar_gen4_pcie_ep = {
+ .mode = DW_PCIE_EP_TYPE,
+};
+
static const struct of_device_id rcar_gen4_pcie_of_match[] = {
{
.compatible = "renesas,rcar-gen4-pcie",
- .data = (void *)DW_PCIE_RC_TYPE,
+ .data = &platdata_rcar_gen4_pcie,
},
{
.compatible = "renesas,rcar-gen4-pcie-ep",
- .data = (void *)DW_PCIE_EP_TYPE,
+ .data = &platdata_rcar_gen4_pcie_ep,
},
{},
};
--
2.25.1
^ permalink raw reply related
* [PATCH v4 1/7] dt-bindings: PCI: rcar-gen4-pci-host: Add R-Car V4H compatible
From: Yoshihiro Shimoda @ 2024-04-03 5:32 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda, Conor Dooley, Geert Uytterhoeven
In-Reply-To: <20240403053304.3695096-1-yoshihiro.shimoda.uh@renesas.com>
Document bindings for R-Car V4H (R8A779G0) PCIe host module.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml
index ffb34339b637..955c664f1fbb 100644
--- a/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml
+++ b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml
@@ -16,7 +16,9 @@ allOf:
properties:
compatible:
items:
- - const: renesas,r8a779f0-pcie # R-Car S4-8
+ - enum:
+ - renesas,r8a779f0-pcie # R-Car S4-8
+ - renesas,r8a779g0-pcie # R-Car V4H
- const: renesas,rcar-gen4-pcie # R-Car Gen4
reg:
--
2.25.1
^ permalink raw reply related
* [PATCH v4 0/7] PCI: dwc: rcar-gen4: Add R-Car V4H support
From: Yoshihiro Shimoda @ 2024-04-03 5:32 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, krzysztof.kozlowski+dt, conor+dt,
jingoohan1, mani
Cc: marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc,
Yoshihiro Shimoda
The pcie-rcar-gen4 driver can reuse other R-Car Gen4 support like
r8a779g0 (R-Car V4H) and r8a779h0 (R-Car V4M). However, some
initializing settings differ between R-Car S4-8 (r8a779f0) and
others. The R-Car S4-8 will be minority about the setting way. So,
R-Car V4H will be majority and this is generic initialization way
as "renesas,rcar-gen4-pcie{-ep}" compatible. For now, I tested
both R-Car S4-8 and R-Car V4H on this driver. I'll support one more
other SoC (R-Car V4M) in the future.
Changes from v3:
https://lore.kernel.org/linux-pci/20240401023942.134704-1-yoshihiro.shimoda.uh@renesas.com/
- Modify the code to use "do .. while" instead of goto in patch 6/7.
Changes from v2:
https://lore.kernel.org/linux-pci/20240326024540.2336155-1-yoshihiro.shimoda.uh@renesas.com/
- Add a new patch which just add a platdata in patch 4/7.
- Modify the subjects in patch [56]/7.
- Modify the description and code about Bjorn's comment in patch [56]/7.
- Add missing MODULE_FIRMWARE(9 in patch 6/7.
- Document a policy aboud adding pci_device_id instead of adding r8a779g0's id
in patch 7/7.
Changes from v1:
https://lore.kernel.org/linux-pci/20240229120719.2553638-1-yoshihiro.shimoda.uh@renesas.com/
- Based on v6.9-rc1.
- Add Acked-by and/or Reviewed-by in patch [126/6].
Yoshihiro Shimoda (7):
dt-bindings: PCI: rcar-gen4-pci-host: Add R-Car V4H compatible
dt-bindings: PCI: rcar-gen4-pci-ep: Add R-Car V4H compatible
PCI: dwc: Add PCIE_PORT_{FORCE,LANE_SKEW} macros
PCI: dwc: rcar-gen4: Add rcar_gen4_pcie_platdata
PCI: dwc: rcar-gen4: Add .ltssm_enable() for other SoC support
PCI: dwc: rcar-gen4: Add support for r8a779g0
misc: pci_endpoint_test: Document a policy about adding pci_device_id
.../bindings/pci/rcar-gen4-pci-ep.yaml | 4 +-
.../bindings/pci/rcar-gen4-pci-host.yaml | 4 +-
drivers/misc/pci_endpoint_test.c | 1 +
drivers/pci/controller/dwc/pcie-designware.h | 6 +
drivers/pci/controller/dwc/pcie-rcar-gen4.c | 272 +++++++++++++++++-
5 files changed, 270 insertions(+), 17 deletions(-)
--
2.25.1
^ permalink raw reply
* Re: [PATCH v8 1/3] input: pm8xxx-vibrator: refactor to support new SPMI vibrator
From: Fenglin Wu @ 2024-04-03 5:29 UTC (permalink / raw)
To: Konrad Dybcio, kernel, Andy Gross, Bjorn Andersson,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-input, linux-kernel, devicetree
In-Reply-To: <21641459-d7c0-412d-8244-6f2f2c458551@linaro.org>
On 4/2/2024 11:21 PM, Konrad Dybcio wrote:
> On 1.04.2024 10:38 AM, Fenglin Wu via B4 Relay wrote:
>> From: Fenglin Wu <quic_fenglinw@quicinc.com>
>>
>> Currently, vibrator control register addresses are hard coded,
>> including the base address and offsets, it's not flexible to
>> support new SPMI vibrator module which is usually included in
>> different PMICs with different base address. Refactor it by using
>> the base address defined in devicetree.
>>
>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>> ---
>
> [...]
>
>> if (regs->enable_mask)
>> - rc = regmap_update_bits(vib->regmap, regs->enable_addr,
>> + rc = regmap_update_bits(vib->regmap, vib->enable_addr,
>> regs->enable_mask, on ? ~0 : 0);
>
> The idiomatic way across the kernel seems to be writing the mask value
> instead of ~0 (which also saves like 2 cpu instructions)
>
>
> Not sure about how ssbi addressing works, but except for that lgtm
>
Agree.
SSBI driver doesn't provide reg_update_bits function call so similar
mathematics is done on the value before writing to the register, I can
update it to use enable_mask directly in next version.
> Konrad
^ permalink raw reply
* Re: [PATCH v18 2/9] usb: dwc3: core: Access XHCI address space temporarily to read port info
From: Krishna Kurapati PSSNV @ 2024-04-03 5:24 UTC (permalink / raw)
To: Thinh Nguyen
Cc: Krzysztof Kozlowski, Rob Herring, Bjorn Andersson, Wesley Cheng,
Konrad Dybcio, Greg Kroah-Hartman, Conor Dooley, Felipe Balbi,
Johan Hovold, devicetree@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, quic_ppratap@quicinc.com,
quic_jackp@quicinc.com, Johan Hovold
In-Reply-To: <20240402233218.5kngtj56qellnrmo@synopsys.com>
On 4/3/2024 5:02 AM, Thinh Nguyen wrote:
> On Tue, Mar 26, 2024, Krishna Kurapati wrote:
>> All DWC3 Multi Port controllers that exist today only support host mode.
>> Temporarily map XHCI address space for host-only controllers and parse
>> XHCI Extended Capabilities registers to read number of usb2 ports and
>> usb3 ports present on multiport controller. Each USB Port is at least HS
>> capable.
>>
>> The port info for usb2 and usb3 phy are identified as num_usb2_ports
>> and num_usb3_ports. The intention is as follows:
>>
>> Wherever we need to perform phy operations like:
>>
>> LOOP_OVER_NUMBER_OF_AVAILABLE_PORTS()
>> {
>> phy_set_mode(dwc->usb2_generic_phy[i], PHY_MODE_USB_HOST);
>> phy_set_mode(dwc->usb3_generic_phy[i], PHY_MODE_USB_HOST);
>> }
>>
>> If number of usb2 ports is 3, loop can go from index 0-2 for
>> usb2_generic_phy. If number of usb3-ports is 2, we don't know for sure,
>> if the first 2 ports are SS capable or some other ports like (2 and 3)
>> are SS capable. So instead, num_usb2_ports is used to loop around all
>> phy's (both hs and ss) for performing phy operations. If any
>> usb3_generic_phy turns out to be NULL, phy operation just bails out.
>> num_usb3_ports is used to modify GUSB3PIPECTL registers while setting up
>> phy's as we need to know how many SS capable ports are there for this.
>>
>> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
>> Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
>> ---
>> drivers/usb/dwc3/core.c | 61 +++++++++++++++++++++++++++++++++++++++++
>> drivers/usb/dwc3/core.h | 5 ++++
>> 2 files changed, 66 insertions(+)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 3e55838c0001..fab7664c12c0 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -39,6 +39,7 @@
>> #include "io.h"
>>
>> #include "debug.h"
>> +#include "../host/xhci-ext-caps.h"
>>
>> #define DWC3_DEFAULT_AUTOSUSPEND_DELAY 5000 /* ms */
>>
>> @@ -1879,10 +1880,56 @@ static int dwc3_get_clocks(struct dwc3 *dwc)
>> return 0;
>> }
>>
>> +static int dwc3_read_port_info(struct dwc3 *dwc)
>> +{
>> + void __iomem *base;
>> + u8 major_revision;
>> + u32 offset;
>> + u32 val;
>> +
>> + /*
>> + * Remap xHCI address space to access XHCI ext cap regs since it is
>> + * needed to get information on number of ports present.
>> + */
>> + base = ioremap(dwc->xhci_resources[0].start,
>> + resource_size(&dwc->xhci_resources[0]));
>> + if (IS_ERR(base))
>> + return PTR_ERR(base);
>
> Looks like you forgot to address some of the comments you said you'd
> update previously if you submit a new version to the series.
>
> [*] https://lore.kernel.org/linux-usb/af73110d-e13e-4183-af11-aed869ac0a31@quicinc.com/
>
Apologies. I agree. I was too much focused on acpi removal and interrupt
cleanup, I forgot the last comment you gave.
Can I send in a separate patch for this ?
Regards,
Krishna,
^ permalink raw reply
* RE: [PATCH v2 2/3] dt-bindings: phy: Add i.MX8Q HSIO SerDes PHY binding
From: Hongxing Zhu @ 2024-04-03 5:16 UTC (permalink / raw)
To: Conor Dooley, Frank Li
Cc: vkoul@kernel.org, kishon@kernel.org, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel@pengutronix.de,
imx@lists.linux.dev
In-Reply-To: <20240402-anemic-aerospace-bc428fff280c@spud>
> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: 2024年4月3日 2:17
> To: Frank Li <frank.li@nxp.com>
> Cc: Hongxing Zhu <hongxing.zhu@nxp.com>; vkoul@kernel.org;
> kishon@kernel.org; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org;
> conor+dt@kernel.org; linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; imx@lists.linux.dev
> Subject: Re: [PATCH v2 2/3] dt-bindings: phy: Add i.MX8Q HSIO SerDes PHY
> binding
>
> On Tue, Apr 02, 2024 at 10:23:45AM -0400, Frank Li wrote:
> > On Tue, Apr 02, 2024 at 01:45:03PM +0800, Richard Zhu wrote:
> > > Add i.MX8QM and i.MX8QXP HSIO SerDes PHY binding.
> > > - Use the controller ID to specify which controller is binded to the
> > > PHY.
> > > - Introduce one HSIO configuration, mandatory required to set
> > > "PCIE_AB_SELECT" and "PHY_X1_EPCS_SEL" during the initialization.
> > >
> > > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> >
> > You missed all conor's comments.
> > Please double check v1's comments.
>
Hi Frank:
Thanks a lot for your reminder.
It's my fault that I missed this email.
> > > + fsl,refclk-pad-mode:
> > > + description: |
> > > + Specifies the mode of the refclk pad used. It can be UNUSED(PHY
> > > + refclock is derived from SoC internal source), INPUT(PHY refclock
> > > + is provided externally via the refclk pad) or OUTPUT(PHY refclock
> > > + is derived from SoC internal source and provided on the refclk pad).
> > > + Refer include/dt-bindings/phy/phy-imx8-pcie.h for the constants
> > > + to be used.
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + enum: [ 0, 1, 2 ]
> >
> > I remember needn't enum because there are header file.
>
> Yah, specifically my comments about this property were missed and were
> probably the most meaningful comments I left.
Hi Conor:
I'm so sorry about it.
I made the mistake missing your last review email.
Would follow your comments in next review cycle.
Best Regards
Richard Zhu
>
> Thanks for the reminder Frank.
^ 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