* Re: [PATCH v2 02/18] PCI: endpoint: Introduce pci_epc_map_align()
From: Manivannan Sadhasivam @ 2024-04-03 7:45 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-3-dlemoal@kernel.org>
On Sat, Mar 30, 2024 at 01:19:12PM +0900, Damien Le Moal wrote:
> Some endpoint controllers have requirements on the alignment of the
> controller physical memory address that must be used to map a RC PCI
> address region. For instance, the rockchip endpoint controller uses
> at most the lower 20 bits of a physical memory address region as the
> lower bits of an RC PCI address. For mapping a PCI address region of
> size bytes starting from pci_addr, the exact number of address bits
> used is the number of address bits changing in the address range
> [pci_addr..pci_addr + size - 1].
>
> For this example, this creates the following constraints:
> 1) The offset into the controller physical memory allocated for a
> mapping depends on the mapping size *and* the starting PCI address
> for the mapping.
> 2) A mapping size cannot exceed the controller windows size (1MB) minus
> the offset needed into the allocated physical memory, which can end
> up being a smaller size than the desired mapping size.
>
> Handling these constraints independently of the controller being used in
> a PCI EP function driver is not possible with the current EPC API as
> it only provides the ->align field in struct pci_epc_features.
> Furthermore, this alignment is static and does not depend on a mapping
> pci address and size.
>
> Solve this by introducing the function pci_epc_map_align() and the
> endpoint controller operation ->map_align to allow endpoint function
> drivers to obtain the size and the offset into a controller address
> region that must be used to map an RC PCI address region. The size
> of the physical address region provided by pci_epc_map_align() can then
> be used as the size argument for the function pci_epc_mem_alloc_addr().
> The offset into the allocated controller memory can be used to
> correctly handle data transfers. Of note is that pci_epc_map_align() may
> indicate upon return a mapping size that is smaller (but not 0) than the
> requested PCI address region size. For such case, an endpoint function
> driver must handle data transfers in fragments.
>
Is there any incentive in exposing pci_epc_map_align()? I mean, why can't it be
hidden inside the new alloc() API itself?
Furthermore, is it possible to avoid the map_align() callback and handle the
alignment within the EPC driver?
- Mani
> The controller operation ->map_align is optional: controllers that do
> not have any address alignment constraints for mapping a RC PCI address
> region do not need to implement this operation. For such controllers,
> pci_epc_map_align() always returns the mapping size as equal
> to the requested size and an offset equal to 0.
>
> The structure pci_epc_map is introduced to represent a mapping start PCI
> address, size and the size and offset into the controller memory needed
> for mapping the PCI address region.
>
> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
> ---
> drivers/pci/endpoint/pci-epc-core.c | 66 +++++++++++++++++++++++++++++
> include/linux/pci-epc.h | 33 +++++++++++++++
> 2 files changed, 99 insertions(+)
>
> diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
> index 754afd115bbd..37758ca91d7f 100644
> --- a/drivers/pci/endpoint/pci-epc-core.c
> +++ b/drivers/pci/endpoint/pci-epc-core.c
> @@ -433,6 +433,72 @@ void pci_epc_unmap_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> }
> EXPORT_SYMBOL_GPL(pci_epc_unmap_addr);
>
> +/**
> + * pci_epc_map_align() - Get the offset into and the size of a controller memory
> + * address region needed to map a RC PCI address region
> + * @epc: the EPC device on which address is allocated
> + * @func_no: the physical endpoint function number in the EPC device
> + * @vfunc_no: the virtual endpoint function number in the physical function
> + * @pci_addr: PCI address to which the physical address should be mapped
> + * @size: the size of the mapping starting from @pci_addr
> + * @map: populate here the actual size and offset into the controller memory
> + * that must be allocated for the mapping
> + *
> + * Invoke the controller map_align operation to obtain the size and the offset
> + * into a controller address region that must be allocated to map @size
> + * bytes of the RC PCI address space starting from @pci_addr.
> + *
> + * The size of the mapping that can be handled by the controller is indicated
> + * using the pci_size field of @map. This size may be smaller than the requested
> + * @size. In such case, the function driver must handle the mapping using
> + * several fragments. The offset into the controller memory for the effective
> + * mapping of the @pci_addr..@pci_addr+@map->pci_size address range is indicated
> + * using the map_ofst field of @map.
> + */
> +int pci_epc_map_align(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> + u64 pci_addr, size_t size, struct pci_epc_map *map)
> +{
> + const struct pci_epc_features *features;
> + size_t mask;
> + int ret;
> +
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> + return -EINVAL;
> +
> + if (!size || !map)
> + return -EINVAL;
> +
> + memset(map, 0, sizeof(*map));
> + map->pci_addr = pci_addr;
> + map->pci_size = size;
> +
> + if (epc->ops->map_align) {
> + mutex_lock(&epc->lock);
> + ret = epc->ops->map_align(epc, func_no, vfunc_no, map);
> + mutex_unlock(&epc->lock);
> + return ret;
> + }
> +
> + /*
> + * Assume a fixed alignment constraint as specified by the controller
> + * features.
> + */
> + features = pci_epc_get_features(epc, func_no, vfunc_no);
> + if (!features || !features->align) {
> + map->map_pci_addr = pci_addr;
> + map->map_size = size;
> + map->map_ofst = 0;
These values are overwritten anyway below.
> + }
> +
> + mask = features->align - 1;
> + map->map_pci_addr = map->pci_addr & ~mask;
> + map->map_ofst = map->pci_addr & mask;
> + map->map_size = ALIGN(map->map_ofst + map->pci_size, features->align);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pci_epc_map_align);
> +
> /**
> * pci_epc_map_addr() - map CPU address to PCI address
> * @epc: the EPC device on which address is allocated
> diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
> index cc2f70d061c8..8cfb4aaf2628 100644
> --- a/include/linux/pci-epc.h
> +++ b/include/linux/pci-epc.h
> @@ -32,11 +32,40 @@ pci_epc_interface_string(enum pci_epc_interface_type type)
> }
> }
>
> +/**
> + * struct pci_epc_map - information about EPC memory for mapping a RC PCI
> + * address range
> + * @pci_addr: start address of the RC PCI address range to map
> + * @pci_size: size of the RC PCI address range to map
> + * @map_pci_addr: RC PCI address used as the first address mapped
> + * @map_size: size of the controller memory needed for the mapping
> + * @map_ofst: offset into the controller memory needed for the mapping
> + * @phys_base: base physical address of the allocated EPC memory
> + * @phys_addr: physical address at which @pci_addr is mapped
> + * @virt_base: base virtual address of the allocated EPC memory
> + * @virt_addr: virtual address at which @pci_addr is mapped
> + */
> +struct pci_epc_map {
> + phys_addr_t pci_addr;
> + size_t pci_size;
> +
> + phys_addr_t map_pci_addr;
> + size_t map_size;
> + phys_addr_t map_ofst;
> +
> + phys_addr_t phys_base;
> + phys_addr_t phys_addr;
> + void __iomem *virt_base;
> + void __iomem *virt_addr;
> +};
> +
> /**
> * struct pci_epc_ops - set of function pointers for performing EPC operations
> * @write_header: ops to populate configuration space header
> * @set_bar: ops to configure the BAR
> * @clear_bar: ops to reset the BAR
> + * @map_align: operation to get the size and offset into a controller memory
> + * window needed to map an RC PCI address region
> * @map_addr: ops to map CPU address to PCI address
> * @unmap_addr: ops to unmap CPU address and PCI address
> * @set_msi: ops to set the requested number of MSI interrupts in the MSI
> @@ -61,6 +90,8 @@ struct pci_epc_ops {
> struct pci_epf_bar *epf_bar);
> void (*clear_bar)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> struct pci_epf_bar *epf_bar);
> + int (*map_align)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> + struct pci_epc_map *map);
> int (*map_addr)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> phys_addr_t addr, u64 pci_addr, size_t size);
> void (*unmap_addr)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> @@ -234,6 +265,8 @@ int pci_epc_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> struct pci_epf_bar *epf_bar);
> void pci_epc_clear_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> struct pci_epf_bar *epf_bar);
> +int pci_epc_map_align(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> + u64 pci_addr, size_t size, struct pci_epc_map *map);
> int pci_epc_map_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> phys_addr_t phys_addr,
> u64 pci_addr, size_t size);
> --
> 2.44.0
>
--
மணிவண்ணன் சதாசிவம்
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v12 0/7] drm/meson: add support for MIPI DSI Display
From: Neil Armstrong @ 2024-04-03 7:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Martin Blumenstingl, Jerome Brunet, Kevin Hilman,
Michael Turquette, Stephen Boyd, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Jagan Teki,
Nicolas Belin
Cc: devicetree, linux-kernel, linux-amlogic, linux-clk,
linux-arm-kernel, dri-devel, Neil Armstrong, Conor Dooley,
Lukas F. Hartmann
The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a),
with a custom glue managing the IP resets, clock and data input similar to the DW-HDMI
glue on the same Amlogic SoCs.
This is a follow-up of v5 now the DRM patches are applied, the clk & DT changes
remains for a full DSI support on G12A & SM1 platforms.
The DW-MIPI-DSI transceiver + D-PHY are clocked by the GP0 PLL, and the ENCL encoder + VIU
pixel reader by the VCLK2 clock using the HDMI PLL.
The DW-MIPI-DSI transceiver gets this pixel stream as input clocked with the VCLK2 clock.
An optional "MEAS" clock can be enabled to measure the delay between each vsync feeding the
DW-MIPI-DSI transceiver.
The clock setup has been redesigned to use CCF, a common PLL (GP0) and the VCLK2 clock
path for DSI in preparation of full CCF support and possibly dual display with HDMI.
The change from v5 is that now we use a "VCLK" driver instead of notifier and rely
on CLK_SET_RATE_GATE to ensure the VCLK gate operation are called.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
Changes in v12:
- fix parameters alignment in patch 2
- update g12a_mipi_dsi_pxclk_div_table comment with jerome's suggestions
- fix dtbs overlay build, fix missed v11... thx khadas for reporting it off-list & testing
- Link to v11: https://lore.kernel.org/r/20240325-amlogic-v6-4-upstream-dsi-ccf-vim3-v11-0-04f55de44604@linaro.org
Changes in v11:
- Rebased on v6.9-rc1
- Fixed overlay handling/creation
- Link to v10: https://lore.kernel.org/r/20240205-amlogic-v6-4-upstream-dsi-ccf-vim3-v10-0-dc06073d5330@linaro.org
Changes in v10:
- Rename regmap_vclk to meson_clk and add _gate for the gate
- Move COMMON_CLK_MESON_VCLK to following patch
- Remove CLK_SET_RATE_PARENT from g12a_vclk2_sel, keep it only on mipi_dsi_pxclk_sel
- Add more info on commit message to specify how clock setup is designed
- Remove forgotten CLK_IGNORE_UNUSED on g12a_vclk2_input
- Remove useless CLK_SET_RATE_PARENT on g12a_vclk2_div to stop propagatting rate _after_ vclk2_div
- Remove invalid CLK_SET_RATE_GATE on g12a_vclk2 since it's not a divider...
- Drop already applied patches
- move Khadas TS050 changes as an overlay
- Link to v9: https://lore.kernel.org/r/20231124-amlogic-v6-4-upstream-dsi-ccf-vim3-v9-0-95256ed139e6@linaro.org
Changes in v9:
- Colledte reviewed-bys
- Fixed patches 2 & 4, commit messages and bindings format
- Link to v8: https://lore.kernel.org/r/20231109-amlogic-v6-4-upstream-dsi-ccf-vim3-v8-0-81e4aeeda193@linaro.org
Changes in v8:
- Switch vclk clk driver to parm as requested by Jerome
- Added bindings fixes to amlogic,meson-axg-mipi-pcie-analog & amlogic,g12a-mipi-dphy-analog
- Fixed DT errors in vim3 example and MNT Reform DT
- Rebased on next-20231107, successfully tested on VIM3L
- Link to v7: https://lore.kernel.org/r/20230803-amlogic-v6-4-upstream-dsi-ccf-vim3-v7-0-762219fc5b28@linaro.org
Changes in v7:
- Added review tags
- Fixed patch 5 thanks to George
- Link to v6: https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v6-0-fd2ac9845472@linaro.org
Changes in v6:
- dropped applied DRM patches
- dropped clk private prefix patches
- rebased on top of 20230607-topic-amlogic-upstream-clkid-public-migration-v2-0-38172d17c27a@linaro.org
- re-ordered/cleaned ENCL patches to match clkid public migration
- Added new "vclk" driver
- uses vclk driver instead of notifier
- cleaned VCLK2 clk flags
- add px_clk gating from DSI driver
- Link to v5: https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v5-0-56eb7a4d5b8e@linaro.org
Changes in v5:
- Aded PRIV all the G12 internal clk IDS to simplify public exposing
- Fixed the DSI bindings
- Fixed the DSI HSYNC/VSYNC polarity handling
- Fixed the DSI clock setup
- Fixed the DSI phy timings
- Dropped components for DSI, only keeping it for HDMI
- Added MNT Reform 2 CM4 DT
- Dropped already applied PHY fix
- Link to v4: https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v4-0-2592c29ea263@linaro.org
Changes from v3 at [3]:
- switched all clk setup via CCF
- using single PLL for DSI controller & ENCL encoder
- added ENCL clocks to CCF
- make the VCLK2 clocks configuration by CCF
- fixed probe/bind of DSI controller to work with panels & bridges
- added bit_clk to controller to it can setup the BIT clock aswell
- added fix for components unbind
- added fix for analog phy setup value
- added TS050 timings fix
- dropped previous clk control patch
Changes from v2 at [2]:
- Fixed patch 3
- Added reviews from Jagan
- Rebased on v5.19-rc1
Changes from v1 at [1]:
- fixed DSI host bindings
- add reviewed-by tags for bindings
- moved magic values to defines thanks to Martin's searches
- added proper prefixes to defines
- moved phy_configure to phy_init() dw-mipi-dsi callback
- moved phy_on to a new phy_power_on() dw-mipi-dsi callback
- correctly return phy_init/configure errors to callback returns
[1] https://lore.kernel.org/r/20200907081825.1654-1-narmstrong@baylibre.com
[2] https://lore.kernel.org/r/20220120083357.1541262-1-narmstrong@baylibre.com
[3] https://lore.kernel.org/r/20220617072723.1742668-1-narmstrong@baylibre.com
---
Neil Armstrong (7):
dt-bindings: arm: amlogic: Document the MNT Reform 2 CM4 adapter with a BPI-CM4 Module
clk: meson: add vclk driver
clk: meson: g12a: make VCLK2 and ENCL clock path configurable by CCF
drm/meson: gate px_clk when setting rate
arm64: meson: g12-common: add the MIPI DSI nodes
arm64: meson: khadas-vim3l: add TS050 DSI panel overlay
arm64: dts: amlogic: meson-g12b-bananapi-cm4: add support for MNT Reform2 with CM4 adaper
Documentation/devicetree/bindings/arm/amlogic.yaml | 1 +
arch/arm64/boot/dts/amlogic/Makefile | 5 +
arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 70 ++++
.../meson-g12b-bananapi-cm4-mnt-reform2.dts | 384 +++++++++++++++++++++
.../boot/dts/amlogic/meson-khadas-vim3-ts050.dtso | 108 ++++++
drivers/clk/meson/Kconfig | 5 +
drivers/clk/meson/Makefile | 1 +
drivers/clk/meson/g12a.c | 76 ++--
drivers/clk/meson/vclk.c | 141 ++++++++
drivers/clk/meson/vclk.h | 51 +++
drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 7 +
11 files changed, 829 insertions(+), 20 deletions(-)
---
base-commit: 4cece764965020c22cff7665b18a012006359095
change-id: 20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-b8e5217e1f4a
Best regards,
--
Neil Armstrong <neil.armstrong@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v12 3/7] clk: meson: g12a: make VCLK2 and ENCL clock path configurable by CCF
From: Neil Armstrong @ 2024-04-03 7:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Martin Blumenstingl, Jerome Brunet, Kevin Hilman,
Michael Turquette, Stephen Boyd, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Jagan Teki,
Nicolas Belin
Cc: devicetree, linux-kernel, linux-amlogic, linux-clk,
linux-arm-kernel, dri-devel, Neil Armstrong
In-Reply-To: <20240403-amlogic-v6-4-upstream-dsi-ccf-vim3-v12-0-99ecdfdc87fc@linaro.org>
In order to setup the DSI clock, let's make the unused VCLK2 clock path
configuration via CCF.
The nocache option is removed from following clocks:
- vclk2_sel
- vclk2_input
- vclk2_div
- vclk2
- vclk_div1
- vclk2_div2_en
- vclk2_div4_en
- vclk2_div6_en
- vclk2_div12_en
- vclk2_div2
- vclk2_div4
- vclk2_div6
- vclk2_div12
- cts_encl_sel
vclk2 and vclk2_div uses the newly introduced vclk regmap driver
to handle the enable and reset bits.
In order to set a rate on cts_encl via the vclk2 clock path,
the NO_REPARENT flag is set on cts_encl_sel & vclk2_sel in order
to keep CCF from selection a parent.
The parents of cts_encl_sel & vclk2_sel are expected to be defined
in DT or manually set by the display driver at some point.
The following clock scheme is to be used for DSI:
xtal
\_ gp0_pll_dco
\_ gp0_pll
|- vclk2_sel
| \_ vclk2_input
| \_ vclk2_div
| \_ vclk2
| \_ vclk2_div1
| \_ cts_encl_sel
| \_ cts_encl -> to VPU LCD Encoder
|- mipi_dsi_pxclk_sel
\_ mipi_dsi_pxclk_div
\_ mipi_dsi_pxclk -> to DSI controller
The mipi_dsi_pxclk_div is set as bypass with a single /1 entry in div_table
in order to use the same GP0 for mipi_dsi_pxclk and vclk2_input.
The SET_RATE_PARENT is only set on the mipi_dsi_pxclk_sel clock so the
DSI bitclock is the reference base clock to calculate the vclk2_div value
when pixel clock is set on the cts_encl endpoint.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
drivers/clk/meson/Kconfig | 1 +
drivers/clk/meson/g12a.c | 76 ++++++++++++++++++++++++++++++++++-------------
2 files changed, 57 insertions(+), 20 deletions(-)
diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
index 8a9823789fa3..59a40a49f8e1 100644
--- a/drivers/clk/meson/Kconfig
+++ b/drivers/clk/meson/Kconfig
@@ -144,6 +144,7 @@ config COMMON_CLK_G12A
select COMMON_CLK_MESON_EE_CLKC
select COMMON_CLK_MESON_CPU_DYNDIV
select COMMON_CLK_MESON_VID_PLL_DIV
+ select COMMON_CLK_MESON_VCLK
select MFD_SYSCON
help
Support for the clock controller on Amlogic S905D2, S905X2 and S905Y2
diff --git a/drivers/clk/meson/g12a.c b/drivers/clk/meson/g12a.c
index 90f4c6103014..df7e17c850d8 100644
--- a/drivers/clk/meson/g12a.c
+++ b/drivers/clk/meson/g12a.c
@@ -22,6 +22,7 @@
#include "clk-regmap.h"
#include "clk-cpu-dyndiv.h"
#include "vid-pll-div.h"
+#include "vclk.h"
#include "meson-eeclk.h"
#include "g12a.h"
@@ -3165,7 +3166,7 @@ static struct clk_regmap g12a_vclk2_sel = {
.ops = &clk_regmap_mux_ops,
.parent_hws = g12a_vclk_parent_hws,
.num_parents = ARRAY_SIZE(g12a_vclk_parent_hws),
- .flags = CLK_SET_RATE_NO_REPARENT | CLK_GET_RATE_NOCACHE,
+ .flags = CLK_SET_RATE_NO_REPARENT,
},
};
@@ -3193,7 +3194,6 @@ static struct clk_regmap g12a_vclk2_input = {
.ops = &clk_regmap_gate_ops,
.parent_hws = (const struct clk_hw *[]) { &g12a_vclk2_sel.hw },
.num_parents = 1,
- .flags = CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
},
};
@@ -3215,19 +3215,32 @@ static struct clk_regmap g12a_vclk_div = {
};
static struct clk_regmap g12a_vclk2_div = {
- .data = &(struct clk_regmap_div_data){
- .offset = HHI_VIID_CLK_DIV,
- .shift = 0,
- .width = 8,
+ .data = &(struct meson_vclk_div_data){
+ .div = {
+ .reg_off = HHI_VIID_CLK_DIV,
+ .shift = 0,
+ .width = 8,
+ },
+ .enable = {
+ .reg_off = HHI_VIID_CLK_DIV,
+ .shift = 16,
+ .width = 1,
+ },
+ .reset = {
+ .reg_off = HHI_VIID_CLK_DIV,
+ .shift = 17,
+ .width = 1,
+ },
+ .flags = CLK_DIVIDER_ROUND_CLOSEST,
},
.hw.init = &(struct clk_init_data){
.name = "vclk2_div",
- .ops = &clk_regmap_divider_ops,
+ .ops = &meson_vclk_div_ops,
.parent_hws = (const struct clk_hw *[]) {
&g12a_vclk2_input.hw
},
.num_parents = 1,
- .flags = CLK_GET_RATE_NOCACHE,
+ .flags = CLK_SET_RATE_GATE,
},
};
@@ -3246,16 +3259,24 @@ static struct clk_regmap g12a_vclk = {
};
static struct clk_regmap g12a_vclk2 = {
- .data = &(struct clk_regmap_gate_data){
- .offset = HHI_VIID_CLK_CNTL,
- .bit_idx = 19,
+ .data = &(struct meson_vclk_gate_data){
+ .enable = {
+ .reg_off = HHI_VIID_CLK_CNTL,
+ .shift = 19,
+ .width = 1,
+ },
+ .reset = {
+ .reg_off = HHI_VIID_CLK_CNTL,
+ .shift = 15,
+ .width = 1,
+ },
},
.hw.init = &(struct clk_init_data) {
.name = "vclk2",
- .ops = &clk_regmap_gate_ops,
+ .ops = &meson_vclk_gate_ops,
.parent_hws = (const struct clk_hw *[]) { &g12a_vclk2_div.hw },
.num_parents = 1,
- .flags = CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
+ .flags = CLK_SET_RATE_PARENT,
},
};
@@ -3339,7 +3360,7 @@ static struct clk_regmap g12a_vclk2_div1 = {
.ops = &clk_regmap_gate_ops,
.parent_hws = (const struct clk_hw *[]) { &g12a_vclk2.hw },
.num_parents = 1,
- .flags = CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
+ .flags = CLK_SET_RATE_PARENT,
},
};
@@ -3353,7 +3374,7 @@ static struct clk_regmap g12a_vclk2_div2_en = {
.ops = &clk_regmap_gate_ops,
.parent_hws = (const struct clk_hw *[]) { &g12a_vclk2.hw },
.num_parents = 1,
- .flags = CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
+ .flags = CLK_SET_RATE_PARENT,
},
};
@@ -3367,7 +3388,7 @@ static struct clk_regmap g12a_vclk2_div4_en = {
.ops = &clk_regmap_gate_ops,
.parent_hws = (const struct clk_hw *[]) { &g12a_vclk2.hw },
.num_parents = 1,
- .flags = CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
+ .flags = CLK_SET_RATE_PARENT,
},
};
@@ -3381,7 +3402,7 @@ static struct clk_regmap g12a_vclk2_div6_en = {
.ops = &clk_regmap_gate_ops,
.parent_hws = (const struct clk_hw *[]) { &g12a_vclk2.hw },
.num_parents = 1,
- .flags = CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
+ .flags = CLK_SET_RATE_PARENT,
},
};
@@ -3395,7 +3416,7 @@ static struct clk_regmap g12a_vclk2_div12_en = {
.ops = &clk_regmap_gate_ops,
.parent_hws = (const struct clk_hw *[]) { &g12a_vclk2.hw },
.num_parents = 1,
- .flags = CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
+ .flags = CLK_SET_RATE_PARENT,
},
};
@@ -3461,6 +3482,7 @@ static struct clk_fixed_factor g12a_vclk2_div2 = {
&g12a_vclk2_div2_en.hw
},
.num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
},
};
@@ -3474,6 +3496,7 @@ static struct clk_fixed_factor g12a_vclk2_div4 = {
&g12a_vclk2_div4_en.hw
},
.num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
},
};
@@ -3487,6 +3510,7 @@ static struct clk_fixed_factor g12a_vclk2_div6 = {
&g12a_vclk2_div6_en.hw
},
.num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
},
};
@@ -3500,6 +3524,7 @@ static struct clk_fixed_factor g12a_vclk2_div12 = {
&g12a_vclk2_div12_en.hw
},
.num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
},
};
@@ -3561,7 +3586,7 @@ static struct clk_regmap g12a_cts_encl_sel = {
.ops = &clk_regmap_mux_ops,
.parent_hws = g12a_cts_parent_hws,
.num_parents = ARRAY_SIZE(g12a_cts_parent_hws),
- .flags = CLK_SET_RATE_NO_REPARENT | CLK_GET_RATE_NOCACHE,
+ .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT,
},
};
@@ -3717,15 +3742,26 @@ static struct clk_regmap g12a_mipi_dsi_pxclk_sel = {
.ops = &clk_regmap_mux_ops,
.parent_hws = g12a_mipi_dsi_pxclk_parent_hws,
.num_parents = ARRAY_SIZE(g12a_mipi_dsi_pxclk_parent_hws),
- .flags = CLK_SET_RATE_NO_REPARENT,
+ .flags = CLK_SET_RATE_NO_REPARENT | CLK_SET_RATE_PARENT,
},
};
+/*
+ * FIXME: Force as bypass by forcing a single /1 table entry, and doensn't on boot value
+ * when setting a clock whith this node in the clock path, but doesn't garantee the divider
+ * is at /1 at boot until a rate is set.
+ */
+static const struct clk_div_table g12a_mipi_dsi_pxclk_div_table[] = {
+ { .val = 0, .div = 1 },
+ { /* sentinel */ },
+};
+
static struct clk_regmap g12a_mipi_dsi_pxclk_div = {
.data = &(struct clk_regmap_div_data){
.offset = HHI_MIPIDSI_PHY_CLK_CNTL,
.shift = 0,
.width = 7,
+ .table = g12a_mipi_dsi_pxclk_div_table,
},
.hw.init = &(struct clk_init_data){
.name = "mipi_dsi_pxclk_div",
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v12 2/7] clk: meson: add vclk driver
From: Neil Armstrong @ 2024-04-03 7:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Martin Blumenstingl, Jerome Brunet, Kevin Hilman,
Michael Turquette, Stephen Boyd, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Jagan Teki,
Nicolas Belin
Cc: devicetree, linux-kernel, linux-amlogic, linux-clk,
linux-arm-kernel, dri-devel, Neil Armstrong
In-Reply-To: <20240403-amlogic-v6-4-upstream-dsi-ccf-vim3-v12-0-99ecdfdc87fc@linaro.org>
The VCLK and VCLK_DIV clocks have supplementary bits.
The VCLK gate has a "SOFT RESET" bit to toggle after the whole
VCLK sub-tree rate has been set, this is implemented in
the gate enable callback.
The VCLK_DIV clocks as enable and reset bits used to disable
and reset the divider, associated with CLK_SET_RATE_GATE it ensures
the rate is set while the divider is disabled and in reset mode.
The VCLK_DIV enable bit isn't implemented as a gate since it's part
of the divider logic and vendor does this exact sequence to ensure
the divider is correctly set.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
drivers/clk/meson/Kconfig | 4 ++
drivers/clk/meson/Makefile | 1 +
drivers/clk/meson/vclk.c | 141 +++++++++++++++++++++++++++++++++++++++++++++
drivers/clk/meson/vclk.h | 51 ++++++++++++++++
4 files changed, 197 insertions(+)
diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
index 29ffd14d267b..8a9823789fa3 100644
--- a/drivers/clk/meson/Kconfig
+++ b/drivers/clk/meson/Kconfig
@@ -30,6 +30,10 @@ config COMMON_CLK_MESON_VID_PLL_DIV
tristate
select COMMON_CLK_MESON_REGMAP
+config COMMON_CLK_MESON_VCLK
+ tristate
+ select COMMON_CLK_MESON_REGMAP
+
config COMMON_CLK_MESON_CLKC_UTILS
tristate
diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index 9ee4b954c896..9ba43fe7a07a 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK_MESON_PLL) += clk-pll.o
obj-$(CONFIG_COMMON_CLK_MESON_REGMAP) += clk-regmap.o
obj-$(CONFIG_COMMON_CLK_MESON_SCLK_DIV) += sclk-div.o
obj-$(CONFIG_COMMON_CLK_MESON_VID_PLL_DIV) += vid-pll-div.o
+obj-$(CONFIG_COMMON_CLK_MESON_VCLK) += vclk.o
# Amlogic Clock controllers
diff --git a/drivers/clk/meson/vclk.c b/drivers/clk/meson/vclk.c
new file mode 100644
index 000000000000..45dc216941ea
--- /dev/null
+++ b/drivers/clk/meson/vclk.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2024 Neil Armstrong <neil.armstrong@linaro.org>
+ */
+
+#include <linux/module.h>
+#include "vclk.h"
+
+/* The VCLK gate has a supplementary reset bit to pulse after ungating */
+
+static inline struct meson_vclk_gate_data *
+clk_get_meson_vclk_gate_data(struct clk_regmap *clk)
+{
+ return (struct meson_vclk_gate_data *)clk->data;
+}
+
+static int meson_vclk_gate_enable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
+
+ meson_parm_write(clk->map, &vclk->enable, 1);
+
+ /* Do a reset pulse */
+ meson_parm_write(clk->map, &vclk->reset, 1);
+ meson_parm_write(clk->map, &vclk->reset, 0);
+
+ return 0;
+}
+
+static void meson_vclk_gate_disable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
+
+ meson_parm_write(clk->map, &vclk->enable, 0);
+}
+
+static int meson_vclk_gate_is_enabled(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
+
+ return meson_parm_read(clk->map, &vclk->enable);
+}
+
+const struct clk_ops meson_vclk_gate_ops = {
+ .enable = meson_vclk_gate_enable,
+ .disable = meson_vclk_gate_disable,
+ .is_enabled = meson_vclk_gate_is_enabled,
+};
+EXPORT_SYMBOL_GPL(meson_vclk_gate_ops);
+
+/* The VCLK Divider has supplementary reset & enable bits */
+
+static inline struct meson_vclk_div_data *
+clk_get_meson_vclk_div_data(struct clk_regmap *clk)
+{
+ return (struct meson_vclk_div_data *)clk->data;
+}
+
+static unsigned long meson_vclk_div_recalc_rate(struct clk_hw *hw,
+ unsigned long prate)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
+
+ return divider_recalc_rate(hw, prate, meson_parm_read(clk->map, &vclk->div),
+ vclk->table, vclk->flags, vclk->div.width);
+}
+
+static int meson_vclk_div_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
+
+ return divider_determine_rate(hw, req, vclk->table, vclk->div.width,
+ vclk->flags);
+}
+
+static int meson_vclk_div_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
+ int ret;
+
+ ret = divider_get_val(rate, parent_rate, vclk->table, vclk->div.width,
+ vclk->flags);
+ if (ret < 0)
+ return ret;
+
+ meson_parm_write(clk->map, &vclk->div, ret);
+
+ return 0;
+};
+
+static int meson_vclk_div_enable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
+
+ /* Unreset the divider when ungating */
+ meson_parm_write(clk->map, &vclk->reset, 0);
+ meson_parm_write(clk->map, &vclk->enable, 1);
+
+ return 0;
+}
+
+static void meson_vclk_div_disable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
+
+ /* Reset the divider when gating */
+ meson_parm_write(clk->map, &vclk->enable, 0);
+ meson_parm_write(clk->map, &vclk->reset, 1);
+}
+
+static int meson_vclk_div_is_enabled(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
+
+ return meson_parm_read(clk->map, &vclk->enable);
+}
+
+const struct clk_ops meson_vclk_div_ops = {
+ .recalc_rate = meson_vclk_div_recalc_rate,
+ .determine_rate = meson_vclk_div_determine_rate,
+ .set_rate = meson_vclk_div_set_rate,
+ .enable = meson_vclk_div_enable,
+ .disable = meson_vclk_div_disable,
+ .is_enabled = meson_vclk_div_is_enabled,
+};
+EXPORT_SYMBOL_GPL(meson_vclk_div_ops);
+
+MODULE_DESCRIPTION("Amlogic vclk clock driver");
+MODULE_AUTHOR("Neil Armstrong <neil.armstrong@linaro.org>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/clk/meson/vclk.h b/drivers/clk/meson/vclk.h
new file mode 100644
index 000000000000..20b0b181db09
--- /dev/null
+++ b/drivers/clk/meson/vclk.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2024 Neil Armstrong <neil.armstrong@linaro.org>
+ */
+
+#ifndef __VCLK_H
+#define __VCLK_H
+
+#include "clk-regmap.h"
+#include "parm.h"
+
+/**
+ * struct meson_vclk_gate_data - vclk_gate regmap backed specific data
+ *
+ * @enable: vclk enable field
+ * @reset: vclk reset field
+ * @flags: hardware-specific flags
+ *
+ * Flags:
+ * Same as clk_gate except CLK_GATE_HIWORD_MASK which is ignored
+ */
+struct meson_vclk_gate_data {
+ struct parm enable;
+ struct parm reset;
+ u8 flags;
+};
+
+extern const struct clk_ops meson_vclk_gate_ops;
+
+/**
+ * struct meson_vclk_div_data - vclk_div regmap back specific data
+ *
+ * @div: divider field
+ * @enable: vclk divider enable field
+ * @reset: vclk divider reset field
+ * @table: array of value/divider pairs, last entry should have div = 0
+ *
+ * Flags:
+ * Same as clk_divider except CLK_DIVIDER_HIWORD_MASK which is ignored
+ */
+struct meson_vclk_div_data {
+ struct parm div;
+ struct parm enable;
+ struct parm reset;
+ const struct clk_div_table *table;
+ u8 flags;
+};
+
+extern const struct clk_ops meson_vclk_div_ops;
+
+#endif /* __VCLK_H */
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v12 6/7] arm64: meson: khadas-vim3l: add TS050 DSI panel overlay
From: Neil Armstrong @ 2024-04-03 7:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Martin Blumenstingl, Jerome Brunet, Kevin Hilman,
Michael Turquette, Stephen Boyd, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Jagan Teki,
Nicolas Belin
Cc: devicetree, linux-kernel, linux-amlogic, linux-clk,
linux-arm-kernel, dri-devel, Neil Armstrong
In-Reply-To: <20240403-amlogic-v6-4-upstream-dsi-ccf-vim3-v12-0-99ecdfdc87fc@linaro.org>
This add dtbo overlay to support the Khadas TS050 panel on the
Khadas VIM3 & VIM3L boards.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/amlogic/Makefile | 4 +
.../boot/dts/amlogic/meson-khadas-vim3-ts050.dtso | 108 +++++++++++++++++++++
2 files changed, 112 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index 1ab160bf928a..0b7961de3db7 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -16,6 +16,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-g12a-u200.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12a-x96-max.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-bananapi-m2s.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3-ts050.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-bananapi-cm4-cm4io.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gsking-x.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking-pro.dtb
@@ -76,6 +77,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-sm1-bananapi-m2-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-bananapi-m5.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-h96-max.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-khadas-vim3l.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-sm1-khadas-vim3l-ts050.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-s905d3-libretech-cc.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-odroid-c4.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-odroid-hc4.dtb
@@ -86,3 +88,5 @@ dtb-$(CONFIG_ARCH_MESON) += meson-sm1-x96-air.dtb
# Overlays
meson-g12a-fbx8am-brcm-dtbs := meson-g12a-fbx8am.dtb meson-g12a-fbx8am-brcm.dtbo
meson-g12a-fbx8am-realtek-dtbs := meson-g12a-fbx8am.dtb meson-g12a-fbx8am-realtek.dtbo
+meson-g12b-a311d-khadas-vim3-ts050-dtbs := meson-g12b-a311d-khadas-vim3.dtb meson-khadas-vim3-ts050.dtbo
+meson-sm1-khadas-vim3l-ts050-dtbs := meson-sm1-khadas-vim3l.dtb meson-khadas-vim3-ts050.dtbo
diff --git a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3-ts050.dtso b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3-ts050.dtso
new file mode 100644
index 000000000000..a41b4e619580
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3-ts050.dtso
@@ -0,0 +1,108 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/clock/g12a-clkc.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/amlogic,meson-g12a-gpio-intc.h>
+
+/dts-v1/;
+/plugin/;
+
+/*
+ * Enable Khadas TS050 DSI Panel + Touch Controller
+ * on Khadas VIM3 (A311D) and VIM3L (S905D3)
+ */
+
+&{/} {
+ panel_backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm_AO_cd 0 25000 0>;
+ brightness-levels = <0 255>;
+ num-interpolated-steps = <255>;
+ default-brightness-level = <200>;
+ };
+};
+
+&i2c3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-0 = <&i2c3_sda_a_pins>, <&i2c3_sck_a_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ touch-controller@38 {
+ compatible = "edt,edt-ft5206";
+ reg = <0x38>;
+ interrupt-parent = <&gpio_intc>;
+ interrupts = <IRQID_GPIOA_5 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio_expander 6 GPIO_ACTIVE_LOW>;
+ touchscreen-size-x = <1080>;
+ touchscreen-size-y = <1920>;
+ status = "okay";
+ };
+};
+
+&mipi_dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ assigned-clocks = <&clkc CLKID_GP0_PLL>,
+ <&clkc CLKID_MIPI_DSI_PXCLK_SEL>,
+ <&clkc CLKID_MIPI_DSI_PXCLK>,
+ <&clkc CLKID_CTS_ENCL_SEL>,
+ <&clkc CLKID_VCLK2_SEL>;
+ assigned-clock-parents = <0>,
+ <&clkc CLKID_GP0_PLL>,
+ <0>,
+ <&clkc CLKID_VCLK2_DIV1>,
+ <&clkc CLKID_GP0_PLL>;
+ assigned-clock-rates = <960000000>,
+ <0>,
+ <960000000>,
+ <0>,
+ <0>;
+
+ panel@0 {
+ compatible = "khadas,ts050";
+ reset-gpios = <&gpio_expander 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpio_expander 1 GPIO_ACTIVE_HIGH>;
+ power-supply = <&vcc_3v3>;
+ backlight = <&panel_backlight>;
+ reg = <0>;
+
+ port {
+ mipi_in_panel: endpoint {
+ remote-endpoint = <&mipi_out_panel>;
+ };
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ mipi_out_panel: endpoint {
+ remote-endpoint = <&mipi_in_panel>;
+ };
+ };
+ };
+};
+
+&mipi_analog_dphy {
+ status = "okay";
+};
+
+&mipi_dphy {
+ status = "okay";
+};
+
+&pwm_AO_cd {
+ pinctrl-0 = <&pwm_ao_c_6_pins>, <&pwm_ao_d_e_pins>;
+};
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v12 4/7] drm/meson: gate px_clk when setting rate
From: Neil Armstrong @ 2024-04-03 7:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Martin Blumenstingl, Jerome Brunet, Kevin Hilman,
Michael Turquette, Stephen Boyd, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Jagan Teki,
Nicolas Belin
Cc: devicetree, linux-kernel, linux-amlogic, linux-clk,
linux-arm-kernel, dri-devel, Neil Armstrong
In-Reply-To: <20240403-amlogic-v6-4-upstream-dsi-ccf-vim3-v12-0-99ecdfdc87fc@linaro.org>
Disable the px_clk when setting the rate to recover a fully
configured and correctly reset VCLK clock tree after the rate
is set.
Fixes: 77d9e1e6b846 ("drm/meson: add support for MIPI-DSI transceiver")
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
index a6bc1bdb3d0d..a10cff3ca1fe 100644
--- a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
+++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
@@ -95,6 +95,7 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
return ret;
}
+ clk_disable_unprepare(mipi_dsi->px_clk);
ret = clk_set_rate(mipi_dsi->px_clk, mipi_dsi->mode->clock * 1000);
if (ret) {
@@ -103,6 +104,12 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
return ret;
}
+ ret = clk_prepare_enable(mipi_dsi->px_clk);
+ if (ret) {
+ dev_err(mipi_dsi->dev, "Failed to enable DSI Pixel clock (ret %d)\n", ret);
+ return ret;
+ }
+
switch (mipi_dsi->dsi_device->format) {
case MIPI_DSI_FMT_RGB888:
dpi_data_format = DPI_COLOR_24BIT;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v12 5/7] arm64: meson: g12-common: add the MIPI DSI nodes
From: Neil Armstrong @ 2024-04-03 7:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Martin Blumenstingl, Jerome Brunet, Kevin Hilman,
Michael Turquette, Stephen Boyd, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Jagan Teki,
Nicolas Belin
Cc: devicetree, linux-kernel, linux-amlogic, linux-clk,
linux-arm-kernel, dri-devel, Neil Armstrong
In-Reply-To: <20240403-amlogic-v6-4-upstream-dsi-ccf-vim3-v12-0-99ecdfdc87fc@linaro.org>
Add the MIPI DSI Analog & Digital PHY nodes and the DSI control
nodes with proper port endpoint to the VPU.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 70 +++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
index 9d5eab6595d0..b058ed78faf0 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
@@ -1663,9 +1663,28 @@ pwrc: power-controller {
<250000000>,
<0>; /* Do Nothing */
};
+
+ mipi_analog_dphy: phy {
+ compatible = "amlogic,g12a-mipi-dphy-analog";
+ #phy-cells = <0>;
+ status = "disabled";
+ };
};
};
+ mipi_dphy: phy@44000 {
+ compatible = "amlogic,axg-mipi-dphy";
+ reg = <0x0 0x44000 0x0 0x2000>;
+ clocks = <&clkc CLKID_MIPI_DSI_PHY>;
+ clock-names = "pclk";
+ resets = <&reset RESET_MIPI_DSI_PHY>;
+ reset-names = "phy";
+ phys = <&mipi_analog_dphy>;
+ phy-names = "analog";
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
usb3_pcie_phy: phy@46000 {
compatible = "amlogic,g12a-usb3-pcie-phy";
reg = <0x0 0x46000 0x0 0x2000>;
@@ -2152,6 +2171,15 @@ hdmi_tx_out: endpoint {
remote-endpoint = <&hdmi_tx_in>;
};
};
+
+ /* DPI output port */
+ dpi_port: port@2 {
+ reg = <2>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <&mipi_dsi_in>;
+ };
+ };
};
gic: interrupt-controller@ffc01000 {
@@ -2189,6 +2217,48 @@ gpio_intc: interrupt-controller@f080 {
amlogic,channel-interrupts = <64 65 66 67 68 69 70 71>;
};
+ mipi_dsi: dsi@7000 {
+ compatible = "amlogic,meson-g12a-dw-mipi-dsi";
+ reg = <0x0 0x7000 0x0 0x1000>;
+ resets = <&reset RESET_MIPI_DSI_HOST>;
+ reset-names = "top";
+ clocks = <&clkc CLKID_MIPI_DSI_HOST>,
+ <&clkc CLKID_MIPI_DSI_PXCLK>,
+ <&clkc CLKID_CTS_ENCL>;
+ clock-names = "pclk", "bit", "px";
+ phys = <&mipi_dphy>;
+ phy-names = "dphy";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ assigned-clocks = <&clkc CLKID_MIPI_DSI_PXCLK_SEL>,
+ <&clkc CLKID_CTS_ENCL_SEL>,
+ <&clkc CLKID_VCLK2_SEL>;
+ assigned-clock-parents = <&clkc CLKID_GP0_PLL>,
+ <&clkc CLKID_VCLK2_DIV1>,
+ <&clkc CLKID_GP0_PLL>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* VPU VENC Input */
+ mipi_dsi_venc_port: port@0 {
+ reg = <0>;
+
+ mipi_dsi_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ /* DSI Output */
+ mipi_dsi_panel_port: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
watchdog: watchdog@f0d0 {
compatible = "amlogic,meson-gxbb-wdt";
reg = <0x0 0xf0d0 0x0 0x10>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v12 7/7] arm64: dts: amlogic: meson-g12b-bananapi-cm4: add support for MNT Reform2 with CM4 adaper
From: Neil Armstrong @ 2024-04-03 7:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Martin Blumenstingl, Jerome Brunet, Kevin Hilman,
Michael Turquette, Stephen Boyd, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Jagan Teki,
Nicolas Belin
Cc: devicetree, linux-kernel, linux-amlogic, linux-clk,
linux-arm-kernel, dri-devel, Neil Armstrong, Lukas F. Hartmann
In-Reply-To: <20240403-amlogic-v6-4-upstream-dsi-ccf-vim3-v12-0-99ecdfdc87fc@linaro.org>
This adds a basic devicetree for the MNT Reform2 DIY laptop when using a
CM4 adapter and a BPI-CM4 module.
Co-developed-by: Lukas F. Hartmann <lukas@mntre.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../meson-g12b-bananapi-cm4-mnt-reform2.dts | 384 +++++++++++++++++++++
2 files changed, 385 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index 0b7961de3db7..d525e5123fbc 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -18,6 +18,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-bananapi-m2s.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3-ts050.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-bananapi-cm4-cm4io.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-g12b-bananapi-cm4-mnt-reform2.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gsking-x.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dts
new file mode 100644
index 000000000000..003efed529ba
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dts
@@ -0,0 +1,384 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Neil Armstrong <neil.armstrong@linaro.org>
+ * Copyright 2023 MNT Research GmbH
+ */
+
+/dts-v1/;
+
+#include "meson-g12b-bananapi-cm4.dtsi"
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/sound/meson-g12a-tohdmitx.h>
+
+/ {
+ model = "MNT Reform 2 with BPI-CM4 Module";
+ compatible = "mntre,reform2-cm4", "bananapi,bpi-cm4", "amlogic,a311d", "amlogic,g12b";
+ chassis-type = "laptop";
+
+ aliases {
+ ethernet0 = ðmac;
+ i2c0 = &i2c1;
+ i2c1 = &i2c3;
+ };
+
+ hdmi_connector: hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_tx_tmds_out>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-blue {
+ color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio_ao GPIOAO_7 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led-green {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio_ao GPIOAO_2 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ sound {
+ compatible = "amlogic,axg-sound-card";
+ model = "MNT-REFORM2-BPI-CM4";
+ audio-widgets = "Headphone", "Headphone Jack",
+ "Speaker", "External Speaker",
+ "Microphone", "Mic Jack";
+ audio-aux-devs = <&tdmout_a>, <&tdmout_b>, <&tdmin_b>;
+ audio-routing = "TDMOUT_A IN 0", "FRDDR_A OUT 0",
+ "TDMOUT_A IN 1", "FRDDR_B OUT 0",
+ "TDMOUT_A IN 2", "FRDDR_C OUT 0",
+ "TDM_A Playback", "TDMOUT_A OUT",
+ "TDMOUT_B IN 0", "FRDDR_A OUT 1",
+ "TDMOUT_B IN 1", "FRDDR_B OUT 1",
+ "TDMOUT_B IN 2", "FRDDR_C OUT 1",
+ "TDM_B Playback", "TDMOUT_B OUT",
+ "TDMIN_B IN 1", "TDM_B Capture",
+ "TDMIN_B IN 4", "TDM_B Loopback",
+ "TODDR_A IN 1", "TDMIN_B OUT",
+ "TODDR_B IN 1", "TDMIN_B OUT",
+ "TODDR_C IN 1", "TDMIN_B OUT",
+ "Headphone Jack", "HP_L",
+ "Headphone Jack", "HP_R",
+ "External Speaker", "SPK_LP",
+ "External Speaker", "SPK_LN",
+ "External Speaker", "SPK_RP",
+ "External Speaker", "SPK_RN",
+ "LINPUT1", "Mic Jack",
+ "Mic Jack", "MICB";
+
+ assigned-clocks = <&clkc CLKID_MPLL2>,
+ <&clkc CLKID_MPLL0>,
+ <&clkc CLKID_MPLL1>;
+ assigned-clock-parents = <0>, <0>, <0>;
+ assigned-clock-rates = <294912000>,
+ <270950400>,
+ <393216000>;
+
+ dai-link-0 {
+ sound-dai = <&frddr_a>;
+ };
+
+ dai-link-1 {
+ sound-dai = <&frddr_b>;
+ };
+
+ dai-link-2 {
+ sound-dai = <&frddr_c>;
+ };
+
+ dai-link-3 {
+ sound-dai = <&toddr_a>;
+ };
+
+ dai-link-4 {
+ sound-dai = <&toddr_b>;
+ };
+
+ dai-link-5 {
+ sound-dai = <&toddr_c>;
+ };
+
+ /* 8ch hdmi interface */
+ dai-link-6 {
+ sound-dai = <&tdmif_a>;
+ dai-format = "i2s";
+ dai-tdm-slot-tx-mask-0 = <1 1>;
+ dai-tdm-slot-tx-mask-1 = <1 1>;
+ dai-tdm-slot-tx-mask-2 = <1 1>;
+ dai-tdm-slot-tx-mask-3 = <1 1>;
+ mclk-fs = <256>;
+
+ codec {
+ sound-dai = <&tohdmitx TOHDMITX_I2S_IN_A>;
+ };
+ };
+
+ /* Analog Audio */
+ dai-link-7 {
+ sound-dai = <&tdmif_b>;
+ dai-format = "i2s";
+ dai-tdm-slot-tx-mask-0 = <1 1>;
+ mclk-fs = <256>;
+
+ codec {
+ sound-dai = <&wm8960>;
+ };
+ };
+
+ /* hdmi glue */
+ dai-link-8 {
+ sound-dai = <&tohdmitx TOHDMITX_I2S_OUT>;
+
+ codec {
+ sound-dai = <&hdmi_tx>;
+ };
+ };
+ };
+
+ reg_main_1v8: regulator-main-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <®_main_3v3>;
+ };
+
+ reg_main_1v2: regulator-main-1v2 {
+ compatible = "regulator-fixed";
+ regulator-name = "1V2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ vin-supply = <®_main_5v>;
+ };
+
+ reg_main_3v3: regulator-main-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ reg_main_5v: regulator-main-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ reg_main_usb: regulator-main-usb {
+ compatible = "regulator-fixed";
+ regulator-name = "USB_PWR";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <®_main_5v>;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm_AO_ab 0 10000 0>;
+ power-supply = <®_main_usb>;
+ enable-gpios = <&gpio 58 GPIO_ACTIVE_HIGH>;
+ brightness-levels = <0 32 64 128 160 200 255>;
+ default-brightness-level = <6>;
+ };
+
+ panel {
+ compatible = "innolux,n125hce-gn1";
+ power-supply = <®_main_3v3>;
+ backlight = <&backlight>;
+ no-hpd;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&edp_bridge_out>;
+ };
+ };
+ };
+
+ clock_12288: clock_12288 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <12288000>;
+ };
+};
+
+&mipi_analog_dphy {
+ status = "okay";
+};
+
+&mipi_dphy {
+ status = "okay";
+};
+
+&mipi_dsi {
+ status = "okay";
+
+ assigned-clocks = <&clkc CLKID_GP0_PLL>,
+ <&clkc CLKID_MIPI_DSI_PXCLK_SEL>,
+ <&clkc CLKID_MIPI_DSI_PXCLK>,
+ <&clkc CLKID_CTS_ENCL_SEL>,
+ <&clkc CLKID_VCLK2_SEL>;
+ assigned-clock-parents = <0>,
+ <&clkc CLKID_GP0_PLL>,
+ <0>,
+ <&clkc CLKID_VCLK2_DIV1>,
+ <&clkc CLKID_GP0_PLL>;
+ assigned-clock-rates = <936000000>,
+ <0>,
+ <936000000>,
+ <0>,
+ <0>;
+};
+
+&mipi_dsi_panel_port {
+ mipi_dsi_out: endpoint {
+ remote-endpoint = <&edp_bridge_in>;
+ };
+};
+
+&cecb_AO {
+ status = "okay";
+};
+
+ðmac {
+ status = "okay";
+};
+
+&hdmi_tx {
+ status = "okay";
+};
+
+&hdmi_tx_tmds_port {
+ hdmi_tx_tmds_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+};
+
+&pwm_AO_ab {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm_ao_a_pins>;
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+};
+
+&i2c3 {
+ status = "okay";
+
+ edp_bridge: bridge@2c {
+ compatible = "ti,sn65dsi86";
+ reg = <0x2c>;
+ enable-gpios = <&gpio GPIOX_10 GPIO_ACTIVE_HIGH>; // PIN_24 / GPIO8
+ vccio-supply = <®_main_1v8>;
+ vpll-supply = <®_main_1v8>;
+ vcca-supply = <®_main_1v2>;
+ vcc-supply = <®_main_1v2>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ edp_bridge_in: endpoint {
+ remote-endpoint = <&mipi_dsi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ edp_bridge_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+ };
+};
+
+&i2c2 {
+ status = "okay";
+
+ wm8960: codec@1a {
+ compatible = "wlf,wm8960";
+ reg = <0x1a>;
+ clocks = <&clock_12288>;
+ clock-names = "mclk";
+ #sound-dai-cells = <0>;
+ wlf,shared-lrclk;
+ };
+
+ rtc@68 {
+ compatible = "nxp,pcf8523";
+ reg = <0x68>;
+ };
+};
+
+&pcie {
+ status = "okay";
+};
+
+&sd_emmc_b {
+ status = "okay";
+};
+
+&tdmif_a {
+ status = "okay";
+};
+
+&tdmout_a {
+ status = "okay";
+};
+
+&tdmif_b {
+ pinctrl-0 = <&tdm_b_dout0_pins>, <&tdm_b_fs_pins>, <&tdm_b_sclk_pins>, <&tdm_b_din1_pins>;
+ pinctrl-names = "default";
+
+ assigned-clocks = <&clkc_audio AUD_CLKID_TDM_SCLK_PAD1>,
+ <&clkc_audio AUD_CLKID_TDM_LRCLK_PAD1>;
+ assigned-clock-parents = <&clkc_audio AUD_CLKID_MST_B_SCLK>,
+ <&clkc_audio AUD_CLKID_MST_B_LRCLK>;
+ assigned-clock-rates = <0>, <0>;
+};
+
+&tdmin_b {
+ status = "okay";
+};
+
+&toddr_a {
+ status = "okay";
+};
+
+&toddr_b {
+ status = "okay";
+};
+
+&toddr_c {
+ status = "okay";
+};
+
+&tohdmitx {
+ status = "okay";
+};
+
+&usb {
+ dr_mode = "host";
+
+ status = "okay";
+};
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 05/18] PCI: endpoint: test: Synchronously cancel command handler work
From: Manivannan Sadhasivam @ 2024-04-03 7:47 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-6-dlemoal@kernel.org>
On Sat, Mar 30, 2024 at 01:19:15PM +0900, Damien Le Moal wrote:
> Replace the call to cancel_delayed_work() with a call to
> cancel_delayed_work_sync() in pci_epf_test_unbind(). This ensures that
> the command handler is really stopped when proceeding with dma and bar
> cleanup.
>
> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
- Mani
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> ---
> drivers/pci/endpoint/functions/pci-epf-test.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
> index 0e285e539538..ab40c3182677 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -709,7 +709,7 @@ static void pci_epf_test_unbind(struct pci_epf *epf)
> struct pci_epf_bar *epf_bar;
> int bar;
>
> - cancel_delayed_work(&epf_test->cmd_handler);
> + cancel_delayed_work_sync(&epf_test->cmd_handler);
> pci_epf_test_clean_dma_chan(epf_test);
> for (bar = 0; bar < PCI_STD_NUM_BARS; bar++) {
> epf_bar = &epf->bar[bar];
> --
> 2.44.0
>
--
மணிவண்ணன் சதாசிவம்
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 00/13] firmware: qcom: qseecom: convert to using the TZ allocator
From: Bartosz Golaszewski @ 2024-04-03 7:47 UTC (permalink / raw)
To: Maximilian Luz
Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Elliot Berman,
Krzysztof Kozlowski, Guru Das Srinagesh, Andrew Halaney,
Alex Elder, Srini Kandagatla, Arnd Bergmann, linux-arm-msm,
linux-kernel, linux-arm-kernel, kernel, Bartosz Golaszewski
In-Reply-To: <CAMRc=Me0MamtJoPtQnucKyZx9pfkEPDAAZqWFWRU0CBcj+P50A@mail.gmail.com>
On Tue, Apr 2, 2024 at 10:44 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> On Sat, Mar 30, 2024 at 8:16 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > On Fri, 29 Mar 2024 20:57:52 +0100, Maximilian Luz <luzmaximilian@gmail.com> said:
> > > On 3/29/24 8:46 PM, Bartosz Golaszewski wrote:
> > >> On Fri, 29 Mar 2024 at 20:39, Maximilian Luz <luzmaximilian@gmail.com> wrote:
> > >>>
> > >>> On 3/29/24 8:26 PM, Bartosz Golaszewski wrote:
> > >>>> On Fri, 29 Mar 2024 at 20:22, Maximilian Luz <luzmaximilian@gmail.com> wrote:
> > >>>>>
> > >>>>> On 3/29/24 8:07 PM, Bartosz Golaszewski wrote:
> > >>>>>>
> > >>>>>> Both with and without SHM bridge?
> > >>>>>
> > >>>>> With CONFIG_QCOM_TZMEM_MODE_GENERIC=y (and the upcoming fix) everything
> > >>>>> works. With CONFIG_QCOM_TZMEM_MODE_SHMBRIDGE=y things unfortunately
> > >>>>> still get stuck at boot (regardless of the fix). I think that's
> > >>>>> happening even before anything efivar related should come up.
> > >>>>>
> > >>>>
> > >>>> This is on X13s? I will get one in 3 weeks. Can you get the bootlog
> > >>>> somehow? Does the laptop have any serial console?
> > >>>
> > >>> Surface Pro X (sc8180x), but it should be similar enough to the X13s in
> > >>> that regard. At least from what people with access to the X13s told me,
> > >>> the qseecom stuff seems to behave the same.
> > >>>
> > >>> Unfortunately I don't have a direct serial console. Best I have is
> > >>> USB-serial, but it's not even getting there. I'll have to try and see if
> > >>> I can get some more info on the screen.
> > >>>
> > >>
> > >> I have access to a sc8180x-primus board, does it make sense to test
> > >> with this one? If so, could you give me instructions on how to do it?
> > >
> > > I guess it's worth a shot.
> > >
> > > From what I can tell, there shouldn't be any patches in my tree that
> > > would conflict with it. So I guess it should just be building it with
> > > CONFIG_QCOM_TZMEM_MODE_SHMBRIDGE=y and booting.
> > >
> > > I am currently testing it on top of a patched v6.8 tree though (but that
> > > should just contain patches to get the Pro X running). You can find the
> > > full tree at
> > >
> > > https://github.com/linux-surface/kernel/tree/spx/v6.8
> > >
> > > The last commit is the fix I mentioned, so you might want to revert
> > > that, since the shmem issue triggers regardless of that and it prevents
> > > your series from applying cleanly.
> > >
> > > Best regards,
> > > Max
> > >
> >
> > sc8180x-primus' support upstream is quite flaky. The board boots 50% of time.
> > However it's true that with SHM bridge it gets to:
> >
> > mount: mounting efivarfs on /sys/firmware/efi/efivars failed: Operation not supported
> >
> > and stops 100% of the time. Without SHM bridge I cannot boot it either because
> > I suppose I need the patch you sent yesterday. I haven't had the time to
> > rebase it yet, it's quite intrusive to my series.
> >
> > I can confirm that with that patch the board still boots but still 50% of the
> > time.
> >
> > Bart
>
> Hi!
>
> I was under the impression that until v8, the series worked on sc8180x
> but I'm seeing that even v7 has the same issue with SHM Bridge on
> sc8180x-primus. Could you confirm? Because I'm not sure if I should
> track the differences or the whole thing was broken for this platform
> from the beginning.
>
> Bart
Interestingly, it doesn't seem like a problem with qseecom - even if I
disable the driver, the board still freezes after the first SCM call
using SHM bridge. I suspect - and am trying to clarify that with qcom
- that this architecture doesn't support SHM bridge but doesn't report
it either unlike other older platforms. Or maybe there's some quirk
somewhere. Anyway, I'm on it.
Bart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 06/18] PCI: endpoint: test: Implement link_down event operation
From: Manivannan Sadhasivam @ 2024-04-03 7:48 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-7-dlemoal@kernel.org>
On Sat, Mar 30, 2024 at 01:19:16PM +0900, Damien Le Moal wrote:
> Implement the link_down event operation to stop the command execution
> delayed work when the endpoint controller notifies a link down event.
>
> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
This patch is already part of another series I posted [1] and under review. So
this can be dropped.
- Mani
[1] https://lore.kernel.org/linux-pci/20240401-pci-epf-rework-v2-9-970dbe90b99d@linaro.org/
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> ---
> drivers/pci/endpoint/functions/pci-epf-test.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
> index ab40c3182677..e6d4e1747c9f 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -824,9 +824,19 @@ static int pci_epf_test_link_up(struct pci_epf *epf)
> return 0;
> }
>
> +static int pci_epf_test_link_down(struct pci_epf *epf)
> +{
> + struct pci_epf_test *epf_test = epf_get_drvdata(epf);
> +
> + cancel_delayed_work_sync(&epf_test->cmd_handler);
> +
> + return 0;
> +}
> +
> static const struct pci_epc_event_ops pci_epf_test_event_ops = {
> .core_init = pci_epf_test_core_init,
> .link_up = pci_epf_test_link_up,
> + .link_down = pci_epf_test_link_down,
> };
>
> static int pci_epf_test_alloc_space(struct pci_epf *epf)
> --
> 2.44.0
>
--
மணிவண்ணன் சதாசிவம்
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 00/18] Improve PCI memory mapping API
From: Manivannan Sadhasivam @ 2024-04-03 7:50 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-1-dlemoal@kernel.org>
On Sat, Mar 30, 2024 at 01:19:10PM +0900, Damien Le Moal wrote:
> This series introduces the new functions pci_epc_map_align(),
> pci_epc_mem_map() and pci_epc_mem_unmap() to improve handling of the
> PCI address mapping alignment constraints of endpoint controllers in a
> controller independent manner.
>
> The issue fixed is that the fixed alignment defined by the "align" field
> of struct pci_epc_features assumes that the alignment of the endpoint
> memory used to map a RC PCI address range is independent of the PCI
> address being mapped. But that is not the case for the rk3399 SoC
> controller: in endpoint mode, this controller uses the lower bits of the
> local endpoint memory address as the lower bits for the PCI addresses
> for data transfers. That is, when mapping local memory, one must take
> into account the number of bits of the RC PCI address that change from
> the start address of the mapping.
>
> To fix this, the new endpoint controller method .map_align is introduced
> and called from pci_epc_map_align(). This method is optional and for
> controllers that do not define it, the mapping information returned
> is based of the fixed alignment constraint as defined by the align
> feature.
>
> The functions pci_epc_mem_map() is a helper function which obtains
> mapping information, allocates endpoint controller memory according to
> the mapping size obtained and maps the memory. pci_epc_mem_map() unmaps
> and frees the endpoint memory.
>
> This series is organized as follows:
> - Patch 1 tidy up the epc core code
> - Patch 2 and 3 introduce the new map_align endpoint controller method
> and related epc functions.
> - Patch 4 to 6 modify the test endpoint driver to use these new
> functions and improve the code of this driver.
While posting the next version, please split the endpoint patches into a
separate series. It helps in code review and can be applied separately.
- Mani
> - Finally, Patch 7 to 18 fix the rk3399 endpoint driver, defining a
> .map_align method for it and improving its overall code readability
> and features.
>
> Changes from v1:
> - Changed pci_epc_check_func() to pci_epc_function_is_valid() in patch
> 1.
> - Removed patch "PCI: endpoint: Improve pci_epc_mem_alloc_addr()"
> (former patch 2 of v1)
> - Various typos cleanups all over. Also fixed some blank space
> indentation.
> - Added review tags
>
> Damien Le Moal (17):
> PCI: endpoint: Introduce pci_epc_function_is_valid()
> PCI: endpoint: Introduce pci_epc_map_align()
> PCI: endpoint: Introduce pci_epc_mem_map()/unmap()
> PCI: endpoint: test: Use pci_epc_mem_map/unmap()
> PCI: endpoint: test: Synchronously cancel command handler work
> PCI: endpoint: test: Implement link_down event operation
> PCI: rockchip-ep: Fix address translation unit programming
> PCI: rockchip-ep: Use a macro to define EP controller .align feature
> PCI: rockchip-ep: Improve rockchip_pcie_ep_unmap_addr()
> PCI: rockchip-ep: Improve rockchip_pcie_ep_map_addr()
> PCI: rockchip-ep: Implement the map_align endpoint controller operation
> PCI: rockchip-ep: Refactor rockchip_pcie_ep_probe() memory allocations
> PCI: rockchip-ep: Refactor rockchip_pcie_ep_probe() MSI-X hiding
> PCI: rockchip-ep: Refactor endpoint link training enable
> PCI: rockship-ep: Introduce rockchip_pcie_ep_stop()
> PCI: rockchip-ep: Improve link training
> PCI: rockchip-ep: Handle PERST# signal in endpoint mode
>
> Wilfred Mallawa (1):
> dt-bindings: pci: rockchip,rk3399-pcie-ep: Add ep-gpios property
>
> .../bindings/pci/rockchip,rk3399-pcie-ep.yaml | 3 +
> drivers/pci/controller/pcie-rockchip-ep.c | 393 ++++++++++++++----
> drivers/pci/controller/pcie-rockchip.c | 17 +-
> drivers/pci/controller/pcie-rockchip.h | 22 +
> drivers/pci/endpoint/functions/pci-epf-test.c | 390 +++++++++--------
> drivers/pci/endpoint/pci-epc-core.c | 213 +++++++---
> include/linux/pci-epc.h | 39 ++
> 7 files changed, 768 insertions(+), 309 deletions(-)
>
> --
> 2.44.0
>
--
மணிவண்ணன் சதாசிவம்
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 02/18] PCI: endpoint: Introduce pci_epc_map_align()
From: Damien Le Moal @ 2024-04-03 7:54 UTC (permalink / raw)
To: Manivannan Sadhasivam
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: <20240403074520.GC25309@thinkpad>
On 4/3/24 16:45, Manivannan Sadhasivam wrote:
> On Sat, Mar 30, 2024 at 01:19:12PM +0900, Damien Le Moal wrote:
>> Some endpoint controllers have requirements on the alignment of the
>> controller physical memory address that must be used to map a RC PCI
>> address region. For instance, the rockchip endpoint controller uses
>> at most the lower 20 bits of a physical memory address region as the
>> lower bits of an RC PCI address. For mapping a PCI address region of
>> size bytes starting from pci_addr, the exact number of address bits
>> used is the number of address bits changing in the address range
>> [pci_addr..pci_addr + size - 1].
>>
>> For this example, this creates the following constraints:
>> 1) The offset into the controller physical memory allocated for a
>> mapping depends on the mapping size *and* the starting PCI address
>> for the mapping.
>> 2) A mapping size cannot exceed the controller windows size (1MB) minus
>> the offset needed into the allocated physical memory, which can end
>> up being a smaller size than the desired mapping size.
>>
>> Handling these constraints independently of the controller being used in
>> a PCI EP function driver is not possible with the current EPC API as
>> it only provides the ->align field in struct pci_epc_features.
>> Furthermore, this alignment is static and does not depend on a mapping
>> pci address and size.
>>
>> Solve this by introducing the function pci_epc_map_align() and the
>> endpoint controller operation ->map_align to allow endpoint function
>> drivers to obtain the size and the offset into a controller address
>> region that must be used to map an RC PCI address region. The size
>> of the physical address region provided by pci_epc_map_align() can then
>> be used as the size argument for the function pci_epc_mem_alloc_addr().
>> The offset into the allocated controller memory can be used to
>> correctly handle data transfers. Of note is that pci_epc_map_align() may
>> indicate upon return a mapping size that is smaller (but not 0) than the
>> requested PCI address region size. For such case, an endpoint function
>> driver must handle data transfers in fragments.
>>
>
> Is there any incentive in exposing pci_epc_map_align()? I mean, why can't it be
> hidden inside the new alloc() API itself?
I could drop pci_epc_map_align(), but the idea here was to have an API that is
not restrictive. E.g., a function driver could allocate memory, keep it and
repetedly use map_align and map() function to remap it to different PCI
addresses. With your suggestion, that would not be possible.
>
> Furthermore, is it possible to avoid the map_align() callback and handle the
> alignment within the EPC driver?
I am not so sure that this is possible because handling the alignment can
potentially result in changing the amount of memory to allocate, based on the
PCI address also. So the allocation API would need to change, a lot.
>> + /*
>> + * Assume a fixed alignment constraint as specified by the controller
>> + * features.
>> + */
>> + features = pci_epc_get_features(epc, func_no, vfunc_no);
>> + if (!features || !features->align) {
>> + map->map_pci_addr = pci_addr;
>> + map->map_size = size;
>> + map->map_ofst = 0;
>
> These values are overwritten anyway below.
Looks like "return" got dropped. Bug. Will re-add it.
--
Damien Le Moal
Western Digital Research
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 7/7] x86: mm: accelerate pagefault when badaccess
From: Kefeng Wang @ 2024-04-03 7:58 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: akpm, Russell King, Catalin Marinas, Will Deacon,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexander Gordeev,
Gerald Schaefer, Dave Hansen, Andy Lutomirski, Peter Zijlstra,
x86, linux-arm-kernel, linuxppc-dev, linux-riscv, linux-s390
In-Reply-To: <CAJuCfpFoxP78+P1+4WQcCqMzGv7jpC9V8pR_-R8t8zPUg-t+aA@mail.gmail.com>
On 2024/4/3 13:59, Suren Baghdasaryan wrote:
> On Tue, Apr 2, 2024 at 12:53 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>>
>> The vm_flags of vma already checked under per-VMA lock, if it is a
>> bad access, directly handle error and return, there is no need to
>> lock_mm_and_find_vma() and check vm_flags again.
>>
>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>
> Looks safe to me.
> Using (mm != NULL) to indicate that we are holding mmap_lock is not
> ideal but I guess that works.
>
Yes, I will add this part it into change too,
The access_error() of vma already checked under per-VMA lock, if it
is a bad access, directly handle error, no need to retry with mmap_lock
again. In order to release the correct lock, pass the mm_struct into
bad_area_access_error(), if mm is NULL, release vma lock, or release
mmap_lock. Since the page faut is handled under per-VMA lock, count it
as a vma lock event with VMA_LOCK_SUCCESS.
Thanks.
> Reviewed-by: Suren Baghdasaryan <surenb@google.com>
>
>> ---
>> arch/x86/mm/fault.c | 23 ++++++++++++++---------
>> 1 file changed, 14 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
>> index a4cc20d0036d..67b18adc75dd 100644
>> --- a/arch/x86/mm/fault.c
>> +++ b/arch/x86/mm/fault.c
>> @@ -866,14 +866,17 @@ bad_area_nosemaphore(struct pt_regs *regs, unsigned long error_code,
>>
>> static void
>> __bad_area(struct pt_regs *regs, unsigned long error_code,
>> - unsigned long address, u32 pkey, int si_code)
>> + unsigned long address, struct mm_struct *mm,
>> + struct vm_area_struct *vma, u32 pkey, int si_code)
>> {
>> - struct mm_struct *mm = current->mm;
>> /*
>> * Something tried to access memory that isn't in our memory map..
>> * Fix it, but check if it's kernel or user first..
>> */
>> - mmap_read_unlock(mm);
>> + if (mm)
>> + mmap_read_unlock(mm);
>> + else
>> + vma_end_read(vma);
>>
>> __bad_area_nosemaphore(regs, error_code, address, pkey, si_code);
>> }
>> @@ -897,7 +900,8 @@ static inline bool bad_area_access_from_pkeys(unsigned long error_code,
>>
>> static noinline void
>> bad_area_access_error(struct pt_regs *regs, unsigned long error_code,
>> - unsigned long address, struct vm_area_struct *vma)
>> + unsigned long address, struct mm_struct *mm,
>> + struct vm_area_struct *vma)
>> {
>> /*
>> * This OSPKE check is not strictly necessary at runtime.
>> @@ -927,9 +931,9 @@ bad_area_access_error(struct pt_regs *regs, unsigned long error_code,
>> */
>> u32 pkey = vma_pkey(vma);
>>
>> - __bad_area(regs, error_code, address, pkey, SEGV_PKUERR);
>> + __bad_area(regs, error_code, address, mm, vma, pkey, SEGV_PKUERR);
>> } else {
>> - __bad_area(regs, error_code, address, 0, SEGV_ACCERR);
>> + __bad_area(regs, error_code, address, mm, vma, 0, SEGV_ACCERR);
>> }
>> }
>>
>> @@ -1357,8 +1361,9 @@ void do_user_addr_fault(struct pt_regs *regs,
>> goto lock_mmap;
>>
>> if (unlikely(access_error(error_code, vma))) {
>> - vma_end_read(vma);
>> - goto lock_mmap;
>> + bad_area_access_error(regs, error_code, address, NULL, vma);
>> + count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
>> + return;
>> }
>> fault = handle_mm_fault(vma, address, flags | FAULT_FLAG_VMA_LOCK, regs);
>> if (!(fault & (VM_FAULT_RETRY | VM_FAULT_COMPLETED)))
>> @@ -1394,7 +1399,7 @@ void do_user_addr_fault(struct pt_regs *regs,
>> * we can handle it..
>> */
>> if (unlikely(access_error(error_code, vma))) {
>> - bad_area_access_error(regs, error_code, address, vma);
>> + bad_area_access_error(regs, error_code, address, mm, vma);
>> return;
>> }
>>
>> --
>> 2.27.0
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 00/18] Improve PCI memory mapping API
From: Damien Le Moal @ 2024-04-03 7:58 UTC (permalink / raw)
To: Manivannan Sadhasivam
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: <20240403075034.GF25309@thinkpad>
On 4/3/24 16:50, Manivannan Sadhasivam wrote:
> On Sat, Mar 30, 2024 at 01:19:10PM +0900, Damien Le Moal wrote:
>> This series introduces the new functions pci_epc_map_align(),
>> pci_epc_mem_map() and pci_epc_mem_unmap() to improve handling of the
>> PCI address mapping alignment constraints of endpoint controllers in a
>> controller independent manner.
>>
>> The issue fixed is that the fixed alignment defined by the "align" field
>> of struct pci_epc_features assumes that the alignment of the endpoint
>> memory used to map a RC PCI address range is independent of the PCI
>> address being mapped. But that is not the case for the rk3399 SoC
>> controller: in endpoint mode, this controller uses the lower bits of the
>> local endpoint memory address as the lower bits for the PCI addresses
>> for data transfers. That is, when mapping local memory, one must take
>> into account the number of bits of the RC PCI address that change from
>> the start address of the mapping.
>>
>> To fix this, the new endpoint controller method .map_align is introduced
>> and called from pci_epc_map_align(). This method is optional and for
>> controllers that do not define it, the mapping information returned
>> is based of the fixed alignment constraint as defined by the align
>> feature.
>>
>> The functions pci_epc_mem_map() is a helper function which obtains
>> mapping information, allocates endpoint controller memory according to
>> the mapping size obtained and maps the memory. pci_epc_mem_map() unmaps
>> and frees the endpoint memory.
>>
>> This series is organized as follows:
>> - Patch 1 tidy up the epc core code
>> - Patch 2 and 3 introduce the new map_align endpoint controller method
>> and related epc functions.
>> - Patch 4 to 6 modify the test endpoint driver to use these new
>> functions and improve the code of this driver.
>
> While posting the next version, please split the endpoint patches into a
> separate series. It helps in code review and can be applied separately.
Which patches ? They are all endpoint related:
(1) Core code
(2) test function driver
(3) rockchip rk3399 controller
(2) and (3) depend on the patches in (1), so splitting the series is a big
possible only if (1) is applied first, so that is a source of delays and breaks
the context of the patches...
--
Damien Le Moal
Western Digital Research
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Re: [PATCH] arm64: dts: rockchip: remove startup-delay-us from vcc3v3_pcie2x1l0 on rock-5b
From: Jianfeng Liu @ 2024-04-03 7:59 UTC (permalink / raw)
To: heiko
Cc: conor+dt, devicetree, krzysztof.kozlowski+dt, linux-arm-kernel,
linux-kernel, linux-rockchip, liujianfeng1994, robh, sfr
In-Reply-To: <2535182.Sgy9Pd6rRy@diego>
Hi Heiko,
Tue, 02 Apr 2024 12:39:17 +0200, Heiko Stübner wrote:
>Does the pcie driver enable the regulator too late somehow?
The pcie driver will enable the regulator imediately when it is probed.
I added log at when driver is probed and when regulator is enabled.
Here is the log with "startup-delay-us = <50000>":
```
[ 1.572991] rockchip-dw-pcie a40800000.pcie: rockchip_pcie_probe start
[ 1.573697] rockchip-dw-pcie a40800000.pcie: going to enable vpcie3v3 regulator
[ 1.575194] rockchip-dw-pcie a40800000.pcie: enable vpcie3v3 regulator done
```
And here is the log without "startup-delay-us":
```
[ 1.518490] rockchip-dw-pcie a40800000.pcie: rockchip_pcie_probe start
[ 1.518603] rockchip-dw-pcie a40800000.pcie: going to enable vpcie3v3 regulator
[ 1.518610] rockchip-dw-pcie a40800000.pcie: enable vpcie3v3 regulator done
```
We can see startup-delay-us will delay the driver probe.
I also take a look at rockchip's SDK kernel, their pci driver is probed
very late:
```
[ 3.398682] dw-pcie fe170000.pcie: invalid resource
[ 3.398686] dw-pcie fe170000.pcie: Failed to initialize host
[ 3.398688] dw-pcie: probe of fe170000.pcie failed with error -22
[ 3.399396] rk-pcie fe170000.pcie: invalid prsnt-gpios property in node
[ 3.399410] rk-pcie fe170000.pcie: Looking up vpcie3v3-supply from device tree
[ 3.405195] rk-pcie fe170000.pcie: host bridge /pcie@fe170000 ranges:
[ 3.405253] rk-pcie fe170000.pcie: IO 0x00f2100000..0x00f21fffff -> 0x00f2100000
[ 3.405283] rk-pcie fe170000.pcie: MEM 0x00f2200000..0x00f2ffffff -> 0x00f2200000
[ 3.405310] rk-pcie fe170000.pcie: MEM 0x0980000000..0x09bfffffff -> 0x0980000000
[ 3.405372] rk-pcie fe170000.pcie: iATU unroll: enabled
[ 3.405381] rk-pcie fe170000.pcie: iATU regions: 8 ob, 8 ib, align 64K, limit 8G
[ 3.666917] rk-pcie fe170000.pcie: PCIe Link up, LTSSM is 0x30011
[ 3.666932] rk-pcie fe170000.pcie: PCIe Gen.1 x1 link up
[ 3.667139] rk-pcie fe170000.pcie: PCI host bridge to bus 0002:20
```
And it is reported that startup-delay-us is necessary in rockchip's SDK
kernel. But in mainline kernel it is different.
Jianfeng
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 4/9] soc: mediatek: cmdq: Add cmdq_pkt_write_s_reg_value to support write value to reg
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 cmdq_pkt_write_s_reg_value to support write a value to a register.
It appends write_s command to the command buffer in a CMDQ packet,
ask GCE to excute a write instruction to write a value to a register
with low 16 bits physical address offset.
Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 13 +++++++++++++
include/linux/soc/mediatek/mtk-cmdq.h | 11 +++++++++++
2 files changed, 24 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 818e6ab24370a..1d79a127f2d3e 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -289,6 +289,19 @@ int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
}
EXPORT_SYMBOL(cmdq_pkt_write_s_value);
+int cmdq_pkt_write_s_reg_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx, u32 value)
+{
+ struct cmdq_instruction inst = {};
+
+ inst.op = CMDQ_CODE_WRITE_S;
+ inst.dst_t = CMDQ_REG_TYPE;
+ inst.reg_dst = high_addr_reg_idx;
+ inst.value = value;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s_reg_value);
+
int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
u16 addr_low, u32 value, u32 mask)
{
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index 1edb391ec604a..854b8b3d6fad0 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -219,6 +219,17 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
*/
int cmdq_pkt_mem_move(struct cmdq_pkt *pkt, dma_addr_t src_addr, dma_addr_t dst_addr);
+/**
+ * cmdq_pkt_write_s_reg_value() - append write_s command to the CMDQ packet which
+ * write value to a register with low address pa
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @value: the specified target value
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_write_s_reg_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx, u32 value);
+
/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 3/9] soc: mediatek: cmdq: Add cmdq_pkt_logic_command to support math operation
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 cmdq_pkt_logic_command to support math operation.
cmdq_pkt_logic_command can append logic command to the CMDQ packet,
ask GCE to execute a arithmetic calculate instruction,
such as add, subtract, multiply, AND, OR and NOT, etc.
Note that all arithmetic instructions are unsigned calculations.
If there are any overflows, GCE will sent the invalid IRQ to notify
CMDQ driver.
Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 36 ++++++++++++++++++++++
include/linux/soc/mediatek/mtk-cmdq.h | 42 ++++++++++++++++++++++++++
2 files changed, 78 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 8acd8e38283e0..818e6ab24370a 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -15,9 +15,18 @@
/* dedicate the last GPR_R15 to assign the register address to be poll */
#define CMDQ_POLL_ADDR_GPR (15)
#define CMDQ_EOC_IRQ_EN BIT(0)
+#define CMDQ_IMMEDIATE_VALUE 0
#define CMDQ_REG_TYPE 1
#define CMDQ_JUMP_RELATIVE 1
+#define CMDQ_OPERAND_GET_IDX_VALUE(operand) \
+ ({ \
+ struct cmdq_operand *op = operand; \
+ op->reg ? op->idx : op->value; \
+ })
+#define CMDQ_OPERAND_TYPE(operand) \
+ ((operand)->reg ? CMDQ_REG_TYPE : CMDQ_IMMEDIATE_VALUE)
+
struct cmdq_instruction {
union {
u32 value;
@@ -470,6 +479,33 @@ int cmdq_pkt_poll_addr(struct cmdq_pkt *pkt, dma_addr_t addr, u32 value, u32 mas
}
EXPORT_SYMBOL(cmdq_pkt_poll_addr);
+int cmdq_pkt_logic_command(struct cmdq_pkt *pkt, u16 result_reg_idx,
+ struct cmdq_operand *left_operand,
+ enum cmdq_logic_op s_op,
+ struct cmdq_operand *right_operand)
+{
+ struct cmdq_instruction inst = { {0} };
+ u32 left_idx_value;
+ u32 right_idx_value;
+
+ if (!left_operand || !right_operand || s_op >= CMDQ_LOGIC_MAX)
+ return -EINVAL;
+
+ left_idx_value = CMDQ_OPERAND_GET_IDX_VALUE(left_operand);
+ right_idx_value = CMDQ_OPERAND_GET_IDX_VALUE(right_operand);
+ inst.op = CMDQ_CODE_LOGIC;
+ inst.dst_t = CMDQ_REG_TYPE;
+ inst.src_t = CMDQ_OPERAND_TYPE(left_operand);
+ inst.arg_c_t = CMDQ_OPERAND_TYPE(right_operand);
+ inst.sop = s_op;
+ inst.arg_c = right_idx_value;
+ inst.src_reg = left_idx_value;
+ inst.reg_dst = result_reg_idx;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_logic_command);
+
int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value)
{
struct cmdq_instruction inst = {};
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index f708bcfebdd8a..1edb391ec604a 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -25,6 +25,31 @@
struct cmdq_pkt;
+enum cmdq_logic_op {
+ CMDQ_LOGIC_ASSIGN = 0,
+ CMDQ_LOGIC_ADD = 1,
+ CMDQ_LOGIC_SUBTRACT = 2,
+ CMDQ_LOGIC_MULTIPLY = 3,
+ CMDQ_LOGIC_XOR = 8,
+ CMDQ_LOGIC_NOT = 9,
+ CMDQ_LOGIC_OR = 10,
+ CMDQ_LOGIC_AND = 11,
+ CMDQ_LOGIC_LEFT_SHIFT = 12,
+ CMDQ_LOGIC_RIGHT_SHIFT = 13,
+ CMDQ_LOGIC_MAX,
+};
+
+struct cmdq_operand {
+ /* register type */
+ bool reg;
+ union {
+ /* index */
+ u16 idx;
+ /* value */
+ u16 value;
+ };
+};
+
struct cmdq_client_reg {
u8 subsys;
u16 offset;
@@ -286,6 +311,23 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
*/
int cmdq_pkt_poll_addr(struct cmdq_pkt *pkt, dma_addr_t addr, u32 value, u32 mask);
+/**
+ * cmdq_pkt_logic_command() - Append logic command to the CMDQ packet, ask GCE to
+ * execute an instruction that store the result of logic operation
+ * with left and right operand into result_reg_idx.
+ * @pkt: the CMDQ packet
+ * @result_reg_idx: SPR index that store operation result of left_operand and right_operand
+ * @left_operand: left operand
+ * @s_op: the logic operator enum
+ * @right_operand: right operand
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_logic_command(struct cmdq_pkt *pkt, u16 result_reg_idx,
+ struct cmdq_operand *left_operand,
+ enum cmdq_logic_op s_op,
+ struct cmdq_operand *right_operand);
+
/**
* cmdq_pkt_assign() - Append logic assign command to the CMDQ packet, ask GCE
* to execute an instruction that set a constant value into
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 6/9] mediatek: cmdq: Add cmdq_pkt_finalize_loop for looping cmd with irq
From: Shawn Sung @ 2024-04-03 6:56 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 cmdq_pkt_finalize_loop to CMDQ driver.
cmdq_pkt_finalize_loop appends end of command(EOC) instruction and
jump to start of command buffer instruction to make the command
buffer loopable.
Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 23 +++++++++++++++++++++++
include/linux/soc/mediatek/mtk-cmdq.h | 8 ++++++++
2 files changed, 31 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 1d79a127f2d3e..676eb62ea82b8 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -565,6 +565,29 @@ int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
}
EXPORT_SYMBOL(cmdq_pkt_finalize);
+int cmdq_pkt_finalize_loop(struct cmdq_pkt *pkt)
+{
+ struct cmdq_instruction inst = { {0} };
+ int err;
+
+ /* insert EOC and generate IRQ for each command iteration */
+ inst.op = CMDQ_CODE_EOC;
+ inst.value = CMDQ_EOC_IRQ_EN;
+ err = cmdq_pkt_append_command(pkt, inst);
+ if (err < 0)
+ return err;
+
+ /* JUMP to start of pkt */
+ err = cmdq_pkt_jump(pkt, pkt->pa_base);
+ if (err < 0)
+ return err;
+
+ pkt->loop = true;
+
+ return err;
+}
+EXPORT_SYMBOL(cmdq_pkt_finalize_loop);
+
int cmdq_pkt_flush_async(struct cmdq_pkt *pkt)
{
int err;
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index 854b8b3d6fad0..46e4217f1d338 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -371,6 +371,14 @@ int cmdq_pkt_jump(struct cmdq_pkt *pkt, dma_addr_t addr);
*/
int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
+/**
+ * cmdq_pkt_finalize_loop() - Append EOC and jump to start command.
+ * @pkt: the CMDQ packet
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_finalize_loop(struct cmdq_pkt *pkt);
+
/**
* cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
* packet and call back at the end of done packet
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 5/9] mailbox: mtk-cmdq: Support GCE loop packets in interrupt handler
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>
1. Add a loop flag for CMDQ packet struct.
CMDQ helper will use a loop flag to mark CMDQ packet as lopping command
and make current command buffer jumps to the beginning when GCE executes
to the end of command buffer.
2. Add a looping task handle flow in irq handler.
GCE irq occurs when GCE executes to the end of command(EOC) instruction.
If the CMDQ packet is a loopping command, GCE irq handler can not
delete the CMDQ task and disable the GCE thread.
Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com>
---
drivers/mailbox/mtk-cmdq-mailbox.c | 11 +++++++++++
include/linux/mailbox/mtk-cmdq-mailbox.h | 1 +
2 files changed, 12 insertions(+)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
index ead2200f39ba0..5906e0343d1fc 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -267,6 +267,17 @@ static void cmdq_thread_irq_handler(struct cmdq *cmdq,
curr_pa = readl(thread->base + CMDQ_THR_CURR_ADDR) << cmdq->pdata->shift;
+ task = list_first_entry_or_null(&thread->task_busy_list,
+ struct cmdq_task, list_entry);
+ if (task && task->pkt->loop) {
+ struct cmdq_cb_data data;
+
+ data.sta = err;
+ data.pkt = task->pkt;
+ mbox_chan_received_data(task->thread->chan, &data);
+ return;
+ }
+
list_for_each_entry_safe(task, tmp, &thread->task_busy_list,
list_entry) {
task_end_pa = task->pa_base + task->pkt->cmd_buf_size;
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
index a8f0070c7aa98..f78a08e7c6ede 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -76,6 +76,7 @@ struct cmdq_pkt {
size_t cmd_buf_size; /* command occupied size */
size_t buf_size; /* real buffer size */
void *cl;
+ bool loop;
};
u8 cmdq_get_shift_pa(struct mbox_chan *chan);
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support
From: Cristian Marussi @ 2024-04-03 8:06 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Peng Fan, Peng Fan (OSS), Sudeep Holla, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij, Dan Carpenter,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, Oleksii Moisieiev
In-Reply-To: <CAHp75VeOB2_ivX5y8YfPEb64YUZBi+3U_1xUdjDVWzLiD=f+nw@mail.gmail.com>
On Tue, Apr 02, 2024 at 07:39:44PM +0300, Andy Shevchenko wrote:
> On Tue, Apr 2, 2024 at 6:58 PM Cristian Marussi
> <cristian.marussi@arm.com> wrote:
> > On Tue, Apr 02, 2024 at 04:06:06PM +0300, Andy Shevchenko wrote:
> > > On Tue, Apr 2, 2024 at 10:48 AM Cristian Marussi
> > > <cristian.marussi@arm.com> wrote:
> > > > On Sun, Mar 31, 2024 at 01:44:28PM +0000, Peng Fan wrote:
> > > > > > Sat, Mar 23, 2024 at 08:15:16PM +0800, Peng Fan (OSS) kirjoitti:
>
> ...
>
> > > > > > > +#include <linux/module.h>
> > > > > > > +#include <linux/scmi_protocol.h>
> > > > > > > +#include <linux/slab.h>
> > > > > >
> > > > > > This is semi-random list of headers. Please, follow IWYU principle (include
> > > > > > what you use). There are a lot of inclusions I see missing (just in the context of
> > > > > > this page I see bits.h, types.h, and asm/byteorder.h).
> > > > >
> > > > > Is there any documentation about this requirement?
> > > > > Some headers are already included by others.
> > >
> > > The documentation here is called "a common sense".
> > > The C language is built like this and we expect that nobody will
> > > invest into the dependency hell that we have already, that's why IWYU
> > > principle, please follow it.
> >
> > Yes, but given that we have a growing number of SCMI protocols there is a
> > common local protocols.h header to group all includes needed by any
> > protocols: the idea behind this (and the devm_ saga down below) was to ease
> > development of protocols, since there are lots of them and growing, given
> > the SCMI spec is extensible.
>
> Yes, and what you are effectively suggesting is: "Technical debt? Oh,
> fine, we do not care!" This is not good. I'm in a long term of
> cleaning up the dependency hell in the kernel (my main focus is
> kernel.h for now) and I am talking from my experience. I do not like
> what people are doing in 95% of the code, that's why I really want to
> stop the bad practices as soon as possible.
>
Not at all, the aim was exactly the opposite, avoiding that some protocol
could have been written without all the needed includes: since a basic set
of headers is definitely common to any protocol you may think to write,
grouping all there was meant to avoid this...I thought that by moving the
problem away in one single internal common header was easier to monitor.
I certainly maybe wrong, but I dont see how you can deduce I dont care...
...and maybe, only maybe, what that 95% of people is trying to do in their
horrible code is to deliver the best reasonably possible thing within their
timeline while you are barking at them in chase of never to be released utter
perfection.
> Last to add, but not least is that your code may be used as an example
> for others, hence we really have to do our best in order to avoid bad
> design, practices, and cargo cults. If this requires more refactoring
> of the existing code, then do it sooner than later.
>
> ...
>
> > > > Andy made (mostly) the same remarks on this same patch ~1-year ago on
> > > > this same patch while it was posted by Oleksii.
> > > >
> > > > And I told that time that most of the remarks around devm_ usage were
> > > > wrong due to how the SCMI core handles protocol initialization (using a
> > > > devres group transparently).
> > > >
> > > > This is what I answered that time.
> > > >
> > > > https://lore.kernel.org/linux-arm-kernel/ZJ78hBcjAhiU+ZBO@e120937-lin/#t
> > > >
> > > > I wont repeat myself, but, in a nutshell the memory allocation like it
> > > > is now is fine: a bit happens via devm_ at protocol initialization, the
> > > > other is doe via explicit kmalloc at runtime and freed via kfree at
> > > > remove time (if needed...i.e. checking the present flag of some structs)
> > >
> > > This sounds like a mess. devm_ is expected to be used only for the
> > > ->probe() stage, otherwise you may consider cleanup.h (__free() macro)
> > > to have automatic free at the paths where memory is not needed.
> >
> > Indeed, this protocol_init code is called by the SCMI core once for all when
> > an SCMI driver tries at first to use this specific protocol by 'getting' its
> > protocol_ops, so it is indeed called inside the probe chain of the driver:
> > at this point you *can* decide to use devres to allocate memory and be assured
> > that if the init fails, or when the driver cease to use this protocol (calling
> > its remove()) and no other driver is using it, all the stuff that have been
> > allocated related to this protocol will be released by the core for you.
> > (using an internal devres group)
> >
> > Without this you should handle manually all the deallocation manually on
> > the init error-paths AND also provide all the cleanup explicitly when
> > the protocol is no more used by any driver (multiple users of the same
> > protocol instance are possible)...for all protocols.
>
> Yes. Is it a problem?
>
Well, no, but is it not a repetitive and error-prone process ?
Is it not the exact reason why devres management exist in first place, to avoid
repetitive manual alloc/free of resources and related pitfalls ? (even though
certainly it is normally used in a more conventional and straightforward way)
The idea was to give some sort of aid in the SCMI stack for writing protocols,
so regarding mem_mgmt, I just built on top of devres facilities, not invented
anything, to try to avoid repetitions and let the core handle mem allocs/free
during the probe phases as much as possible: in pinctrl case would be
particularly trivial to instead manually allocate stuff at init (due to many
lazy delayed allocations) but other protocols need a lot more to be done at init,
frequently in a loop to allocate multiple resources descriptors, and manually
undoing all of that on each error-path and on cleanup is definitely error-prone
and a pain.
Last but not least, this whole thing was designed to address the needs of the
protocols that existed at that time....it is only now with pinctrl lazy-allocations
at runtime that the ugly cohexistence of devm_ and non-devm allocations became a
thing....so clearly the thing needs to be improved/rethinked...even dropped if no
more fitting...
... or alternatively since devres allocations are anyway optional, you could just
use regular kmalloc/kfree for this protocol and avoid this dual handling...
...this was just to put things in context...and I'll happily let Sudeep decide
what he prefers in the immediate for pinctrl or more in general about all the
scmi devres, that I've got enough of these pleasant interactions for now...
Thanks,
Cristian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 07/34] Input: stmpe-ts - mark OF related data as maybe unused
From: Arnd Bergmann @ 2024-04-03 8:06 UTC (permalink / raw)
To: linux-kernel, Dmitry Torokhov, Maxime Coquelin, Alexandre Torgue
Cc: Krzysztof Kozlowski, Arnd Bergmann, Uwe Kleine-König,
linux-input, linux-stm32, linux-arm-kernel
In-Reply-To: <20240403080702.3509288-1-arnd@kernel.org>
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
When compile tested with W=1 on x86_64 with driver as built-in:
stmpe-ts.c:371:34: error: unused variable 'stmpe_ts_ids' [-Werror,-Wunused-const-variable]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/input/touchscreen/stmpe-ts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/stmpe-ts.c b/drivers/input/touchscreen/stmpe-ts.c
index b204fdb2d22c..022b3e94266d 100644
--- a/drivers/input/touchscreen/stmpe-ts.c
+++ b/drivers/input/touchscreen/stmpe-ts.c
@@ -366,7 +366,7 @@ static struct platform_driver stmpe_ts_driver = {
};
module_platform_driver(stmpe_ts_driver);
-static const struct of_device_id stmpe_ts_ids[] = {
+static const struct of_device_id stmpe_ts_ids[] __maybe_unused = {
{ .compatible = "st,stmpe-ts", },
{ },
};
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [Linux-stm32] [PATCH net-next 1/2] net: stmmac: introduce pcs_init/pcs_exit stmmac operations
From: Maxime Chevallier @ 2024-04-03 8:11 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Romain Gantois, Rob Herring, Conor Dooley, Maxime Coquelin,
Geert Uytterhoeven, devicetree, Thomas Petazzoni, netdev,
linux-stm32, Magnus Damm, linux-kernel, linux-renesas-soc,
Eric Dumazet, Jose Abreu, Krzysztof Kozlowski, Jakub Kicinski,
Paolo Abeni, Clément Léger, David S. Miller,
linux-arm-kernel
In-Reply-To: <E1rrgQJ-005ZO4-GB@rmk-PC.armlinux.org.uk>
Hello Russell,
On Tue, 02 Apr 2024 16:51:43 +0100
"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> wrote:
> Introduce a mechanism whereby platforms can create their PCS instances
> prior to the network device being published to userspace, but after
> some of the core stmmac initialisation has been completed. This means
> that the data structures that platforms need will be available.
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC][PATCH 0/2] Amlogic T7 (A113D2) Clock Driver
From: Lucas Tanure @ 2024-04-03 8:12 UTC (permalink / raw)
To: Xianwei Zhao
Cc: Yu Tu, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stephen Boyd, Michael Turquette, linux-arm-kernel,
linux-amlogic, devicetree, linux-kernel, linux-clk
In-Reply-To: <1e6ce146-ebf6-4200-be8b-a4ec78675d40@amlogic.com>
On Wed, Apr 3, 2024 at 7:44 AM Xianwei Zhao <xianwei.zhao@amlogic.com> wrote:
>
> 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?
Hi Xianwei,
I made some progress, and now the SD card controller probes but fails
to read blocks from the SD card. I do think my port of the clock
driver is okay, but I will not send my clock driver until the SD card
fully works, so I am sure the clocking driver is tested.
But if you have something already done, please send it, and I will
test and review it from my side.
Any help with the sdcard controller is also much appreciated.
Thanks
Lucas
> 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
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [Linux-stm32] [PATCH net-next 2/2] net: stmmac: dwmac-socfpga: use pcs_init/pcs_exit
From: Maxime Chevallier @ 2024-04-03 8:12 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Romain Gantois, Rob Herring, Conor Dooley, Maxime Coquelin,
Geert Uytterhoeven, devicetree, Thomas Petazzoni, netdev,
linux-stm32, Magnus Damm, linux-kernel, linux-renesas-soc,
Eric Dumazet, Jose Abreu, Krzysztof Kozlowski, Jakub Kicinski,
Paolo Abeni, Clément Léger, David S. Miller,
linux-arm-kernel
In-Reply-To: <E1rrgQO-005ZOA-KT@rmk-PC.armlinux.org.uk>
Hello Russell,
On Tue, 02 Apr 2024 16:51:48 +0100
"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> wrote:
> Use the newly introduced pcs_init() and pcs_exit() operations to
> create and destroy the PCS instance at a more appropriate moment during
> the driver lifecycle, thereby avoiding publishing a network device to
> userspace that has not yet finished its PCS initialisation.
>
> There are other similar issues with this driver which remain
> unaddressed, but these are out of scope for this patch.
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Thanks for addressing this,
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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