* Re: [PATCH 4/4] iommu/io-pgtable-arm: Prepare for TTBR1 usage
From: Robin Murphy @ 2019-08-20 13:51 UTC (permalink / raw)
To: will, joro, iommu, linux-arm-kernel, robdclark
In-Reply-To: <20190819223439.GG28465@jcrouse1-lnx.qualcomm.com>
On 19/08/2019 23:34, Jordan Crouse wrote:
> On Mon, Aug 19, 2019 at 07:19:31PM +0100, Robin Murphy wrote:
>> Now that callers are free to use a given table for TTBR1 if they wish
>> (all they need do is shift the provided attributes when constructing
>> their final TCR value), the only remaining impediment is the address
>> validation on map/unmap. The fact that the LPAE address space split is
>> symmetric makes this easy to accommodate - by simplifying the current
>> range checks into explicit tests that address bits above IAS are all
>> zero, it then follows straightforwardly to add the inverse test to
>> allow the all-ones case as well.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/iommu/io-pgtable-arm.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
>> index 09cb20671fbb..f39c50356351 100644
>> --- a/drivers/iommu/io-pgtable-arm.c
>> +++ b/drivers/iommu/io-pgtable-arm.c
>> @@ -475,13 +475,13 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
>> arm_lpae_iopte *ptep = data->pgd;
>> int ret, lvl = ARM_LPAE_START_LVL(data);
>> arm_lpae_iopte prot;
>> + long iaext = (long)iova >> data->iop.cfg.ias;
>>
>> /* If no access, then nothing to do */
>> if (!(iommu_prot & (IOMMU_READ | IOMMU_WRITE)))
>> return 0;
>>
>> - if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias) ||
>> - paddr >= (1ULL << data->iop.cfg.oas)))
>> + if (WARN_ON((iaext && ~iaext) || paddr >> data->iop.cfg.oas))
>> return -ERANGE;
>>
>> prot = arm_lpae_prot_to_pte(data, iommu_prot);
>
> We'll want to cast away the sign extended bits before mapping the iova, this
> might be a good patch for that too as long as we are calculating the iaext.
Ah good point, I'd forgotten that ARM_LPAE_LVL_IDX() doesn't actually
cap to IAS if the top level is smaller than bits_per_level (I suppose we
*could* make it do so for purity, but that's bound to hurt efficiency
far more than just zeroing out the offending bits here).
Thanks,
Robin.
>
>> @@ -647,8 +647,9 @@ static size_t arm_lpae_unmap(struct io_pgtable_ops *ops, unsigned long iova,
>> struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
>> arm_lpae_iopte *ptep = data->pgd;
>> int lvl = ARM_LPAE_START_LVL(data);
>> + long iaext = (long)iova >> data->iop.cfg.ias;
>>
>> - if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias)))
>> + if (WARN_ON(iaext && ~iaext))
>> return 0;
>>
>> return __arm_lpae_unmap(data, iova, size, lvl, ptep);
>
> And here too.
>
> Jordan
>
_______________________________________________
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] iommu/arm-smmu: Break insecure users by disabling bypass by default
From: Marc Gonzalez @ 2019-08-20 13:55 UTC (permalink / raw)
To: Will Deacon, Jean-Philippe Brucker, Michael S. Tsirkin
Cc: Joerg Roedel, Will Deacon, Douglas Anderson, Jon Hunter,
Thierry Reding, Robin Murphy, Linux ARM
In-Reply-To: <20190819144827.6h4hm2gytogwepi7@willie-the-truck>
On 19/08/2019 16:48, Will Deacon wrote:
> If we can get by with extending the iommu-map entries for the masters,
> that would certainly be the neatest imo. Sounds like it's worth a quick
> hack, if nothing else.
Tangent: I've been meaning to ask about some iommu-map shenanigan.
My kernel reports:
OF: /soc/pci@1c00000: no iommu-map translation for rid 0x0 on (null)
Errr... "Is that a problem, doctor?"
It's a pr_info() message from of_map_rid() in drivers/of/base.c
I note that it used to be an error before fb709b5e1cca5
Regards.
_______________________________________________
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] ARM: dts: rockchip: remove rk3288 fennec board support
From: Heiko Stuebner @ 2019-08-20 13:56 UTC (permalink / raw)
To: Kever Yang
Cc: Mark Rutland, devicetree, linux-kernel, linux-rockchip,
Rob Herring, linux-arm-kernel
In-Reply-To: <20190820100353.17728-1-kever.yang@rock-chips.com>
Hi Kever,
Am Dienstag, 20. August 2019, 12:03:52 CEST schrieb Kever Yang:
> Since there is no one using this board, remove it.
so just to elaborate a bit, I guess this board was internal to Rockchip,
never went to the market and therefore is obsolete without any users,
right?
Also we should remove the binding from
Documentation/devicetree/bindings/arm/rockchip.yaml as well
Heiko
> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
> ---
>
> arch/arm/boot/dts/rk3288-fennec.dts | 347 ----------------------------
> 1 file changed, 347 deletions(-)
> delete mode 100644 arch/arm/boot/dts/rk3288-fennec.dts
>
> diff --git a/arch/arm/boot/dts/rk3288-fennec.dts b/arch/arm/boot/dts/rk3288-fennec.dts
> deleted file mode 100644
> index 4847cf902a15..000000000000
> --- a/arch/arm/boot/dts/rk3288-fennec.dts
> +++ /dev/null
> @@ -1,347 +0,0 @@
> -// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> -
> -/dts-v1/;
> -
> -#include "rk3288.dtsi"
> -
> -/ {
> - model = "Rockchip RK3288 Fennec Board";
> - compatible = "rockchip,rk3288-fennec", "rockchip,rk3288";
> -
> - memory@0 {
> - reg = <0x0 0x0 0x0 0x80000000>;
> - device_type = "memory";
> - };
> -
> - ext_gmac: external-gmac-clock {
> - compatible = "fixed-clock";
> - #clock-cells = <0>;
> - clock-frequency = <125000000>;
> - clock-output-names = "ext_gmac";
> - };
> -
> - vcc_sys: vsys-regulator {
> - compatible = "regulator-fixed";
> - regulator-name = "vcc_sys";
> - regulator-min-microvolt = <5000000>;
> - regulator-max-microvolt = <5000000>;
> - regulator-always-on;
> - regulator-boot-on;
> - };
> -};
> -
> -&cpu0 {
> - cpu0-supply = <&vdd_cpu>;
> -};
> -
> -&emmc {
> - bus-width = <8>;
> - cap-mmc-highspeed;
> - non-removable;
> - pinctrl-names = "default";
> - pinctrl-0 = <&emmc_clk &emmc_cmd &emmc_pwr &emmc_bus8>;
> - status = "okay";
> -};
> -
> -&gmac {
> - assigned-clocks = <&cru SCLK_MAC>;
> - assigned-clock-parents = <&ext_gmac>;
> - clock_in_out = "input";
> - pinctrl-names = "default";
> - pinctrl-0 = <&rgmii_pins>, <&phy_rst>, <&phy_pmeb>, <&phy_int>;
> - phy-supply = <&vcc_lan>;
> - phy-mode = "rgmii";
> - snps,reset-active-low;
> - snps,reset-delays-us = <0 10000 1000000>;
> - snps,reset-gpio = <&gpio4 RK_PB0 GPIO_ACTIVE_LOW>;
> - tx_delay = <0x30>;
> - rx_delay = <0x10>;
> - status = "okay";
> -};
> -
> -&gpu {
> - mali-supply = <&vdd_gpu>;
> - status = "okay";
> -};
> -
> -&hdmi {
> - status = "okay";
> -};
> -
> -&i2c0 {
> - status = "okay";
> - clock-frequency = <400000>;
> -
> - rk808: pmic@1b {
> - compatible = "rockchip,rk808";
> - reg = <0x1b>;
> - interrupt-parent = <&gpio0>;
> - interrupts = <RK_PA4 IRQ_TYPE_LEVEL_LOW>;
> - #clock-cells = <1>;
> - clock-output-names = "xin32k", "rk808-clkout2";
> - pinctrl-names = "default";
> - pinctrl-0 = <&pmic_int &global_pwroff>;
> - rockchip,system-power-controller;
> - wakeup-source;
> -
> - vcc1-supply = <&vcc_sys>;
> - vcc2-supply = <&vcc_sys>;
> - vcc3-supply = <&vcc_sys>;
> - vcc4-supply = <&vcc_sys>;
> - vcc6-supply = <&vcc_sys>;
> - vcc7-supply = <&vcc_sys>;
> - vcc8-supply = <&vcc_io>;
> - vcc9-supply = <&vcc_io>;
> - vcc10-supply = <&vcc_io>;
> - vcc11-supply = <&vcc_io>;
> - vcc12-supply = <&vcc_io>;
> - vddio-supply = <&vcc_io>;
> -
> - regulators {
> - vdd_cpu: DCDC_REG1 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <750000>;
> - regulator-max-microvolt = <1350000>;
> - regulator-name = "vdd_arm";
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vdd_gpu: DCDC_REG2 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <850000>;
> - regulator-max-microvolt = <1250000>;
> - regulator-name = "vdd_gpu";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <1000000>;
> - };
> - };
> -
> - vcc_ddr: DCDC_REG3 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-name = "vcc_ddr";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - };
> - };
> -
> - vcc_io: DCDC_REG4 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <3300000>;
> - regulator-max-microvolt = <3300000>;
> - regulator-name = "vcc_io";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <3300000>;
> - };
> - };
> -
> - vccio_pmu: LDO_REG1 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <3300000>;
> - regulator-max-microvolt = <3300000>;
> - regulator-name = "vccio_pmu";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <3300000>;
> - };
> - };
> -
> - vcca_33: LDO_REG2 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <3300000>;
> - regulator-max-microvolt = <3300000>;
> - regulator-name = "vcca_33";
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vdd_10: LDO_REG3 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1000000>;
> - regulator-max-microvolt = <1000000>;
> - regulator-name = "vdd_10";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <1000000>;
> - };
> - };
> -
> - vcc_wl: LDO_REG4 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-name = "vcc_wl";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <1800000>;
> - };
> - };
> -
> - vccio_sd: LDO_REG5 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <3300000>;
> - regulator-name = "vccio_sd";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <3300000>;
> - };
> - };
> -
> - vdd10_lcd: LDO_REG6 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1000000>;
> - regulator-max-microvolt = <1000000>;
> - regulator-name = "vdd10_lcd";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <1000000>;
> - };
> - };
> -
> - vcc_18: LDO_REG7 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-name = "vcc_18";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <1800000>;
> - };
> - };
> -
> - vcc18_lcd: LDO_REG8 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-name = "vcc18_lcd";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <1800000>;
> - };
> - };
> -
> - vcc_sd: SWITCH_REG1 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-name = "vcc_sd";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - };
> - };
> -
> - vcc_lan: SWITCH_REG2 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-name = "vcc_lan";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - };
> - };
> - };
> - };
> -};
> -
> -&pinctrl {
> - pcfg_output_high: pcfg-output-high {
> - output-high;
> - };
> -
> - pcfg_output_low: pcfg-output-low {
> - output-low;
> - };
> -
> - pcfg_pull_none_drv_8ma: pcfg-pull-none-drv-8ma {
> - drive-strength = <8>;
> - };
> -
> - pcfg_pull_up_drv_8ma: pcfg-pull-up-drv-8ma {
> - bias-pull-up;
> - drive-strength = <8>;
> - };
> -
> - gmac {
> - phy_int: phy-int {
> - rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_up>;
> - };
> -
> - phy_pmeb: phy-pmeb {
> - rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
> - };
> -
> - phy_rst: phy-rst {
> - rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO &pcfg_output_high>;
> - };
> - };
> -
> - pmic {
> - pmic_int: pmic-int {
> - rockchip,pins = <0 RK_PA4 RK_FUNC_GPIO &pcfg_pull_up>;
> - };
> - };
> -
> - usbphy {
> - host_drv: host-drv {
> - rockchip,pins = <0 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
> - };
> - };
> -};
> -
> -&uart2 {
> - status = "okay";
> -};
> -
> -&usbphy {
> - pinctrl-names = "default";
> - pinctrl-0 = <&host_drv>;
> - vbus_drv-gpios = <&gpio0 RK_PB6 GPIO_ACTIVE_HIGH>;
> - status = "okay";
> -};
> -
> -&usb_host0_ehci {
> - status = "okay";
> -};
> -
> -&usb_host1 {
> - status = "okay";
> -};
> -
> -&usb_otg {
> - status = "okay";
> -};
> -
> -&usb_hsic {
> - status = "okay";
> -};
> -
> -&vopb {
> - status = "okay";
> -};
> -
> -&vopb_mmu {
> - status = "okay";
> -};
> -
> -&vopl {
> - status = "okay";
> -};
> -
> -&vopl_mmu {
> - status = "okay";
> -};
>
_______________________________________________
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] ARM64: dts: allwinner: Add devicetree for pine H64 modelA evaluation board
From: Maxime Ripard @ 2019-08-20 13:58 UTC (permalink / raw)
To: Corentin Labbe
Cc: mark.rutland, devicetree, linux-sunxi, linux-kernel, wens,
robh+dt, linux-arm-kernel
In-Reply-To: <20190816140016.GA30445@Red>
[-- Attachment #1.1: Type: text/plain, Size: 5840 bytes --]
On Fri, Aug 16, 2019 at 04:00:16PM +0200, Corentin Labbe wrote:
> On Fri, Aug 16, 2019 at 03:52:06PM +0200, Maxime Ripard wrote:
> > On Fri, Aug 16, 2019 at 01:57:50PM +0200, Corentin Labbe wrote:
> > > On Fri, Aug 16, 2019 at 01:36:50PM +0200, Maxime Ripard wrote:
> > > > On Fri, Aug 16, 2019 at 11:35:13AM +0200, Corentin Labbe wrote:
> > > > > On Wed, Aug 14, 2019 at 03:33:22PM +0200, Maxime Ripard wrote:
> > > > > > On Wed, Aug 14, 2019 at 03:17:41PM +0200, Corentin Labbe wrote:
> > > > > > > On Mon, Aug 12, 2019 at 11:40:00AM +0200, Maxime Ripard wrote:
> > > > > > > > On Thu, Aug 08, 2019 at 10:42:53AM +0200, Corentin Labbe wrote:
> > > > > > > > > This patch adds the evaluation variant of the model A of the PineH64.
> > > > > > > > > The model A has the same size of the pine64 and has a PCIE slot.
> > > > > > > > >
> > > > > > > > > The only devicetree difference with current pineH64, is the PHY
> > > > > > > > > regulator.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > > > > > > > ---
> > > > > > > > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> > > > > > > > > .../sun50i-h6-pine-h64-modelA-eval.dts | 26 +++++++++++++++++++
> > > > > > > > > 2 files changed, 27 insertions(+)
> > > > > > > > > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> > > > > > > > >
> > > > > > > > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> > > > > > > > > index f6db0611cb85..9a02166cbf72 100644
> > > > > > > > > --- a/arch/arm64/boot/dts/allwinner/Makefile
> > > > > > > > > +++ b/arch/arm64/boot/dts/allwinner/Makefile
> > > > > > > > > @@ -25,3 +25,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-3.dtb
> > > > > > > > > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-lite2.dtb
> > > > > > > > > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
> > > > > > > > > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> > > > > > > > > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-modelA-eval.dtb
> > > > > > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> > > > > > > > > new file mode 100644
> > > > > > > > > index 000000000000..d8ff02747efe
> > > > > > > > > --- /dev/null
> > > > > > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> > > > > > > > > @@ -0,0 +1,26 @@
> > > > > > > > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > > > > > > > > +/*
> > > > > > > > > + * Copyright (C) 2019 Corentin Labbe <clabbe.montjoie@gmail.com>
> > > > > > > > > + */
> > > > > > > > > +
> > > > > > > > > +#include "sun50i-h6-pine-h64.dts"
> > > > > > > > > +
> > > > > > > > > +/ {
> > > > > > > > > + model = "Pine H64 model A evaluation board";
> > > > > > > > > + compatible = "pine64,pine-h64-modelA-eval", "allwinner,sun50i-h6";
> > > > > > > > > +
> > > > > > > > > + reg_gmac_3v3: gmac-3v3 {
> > > > > > > > > + compatible = "regulator-fixed";
> > > > > > > > > + regulator-name = "vcc-gmac-3v3";
> > > > > > > > > + regulator-min-microvolt = <3300000>;
> > > > > > > > > + regulator-max-microvolt = <3300000>;
> > > > > > > > > + startup-delay-us = <100000>;
> > > > > > > > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>;
> > > > > > > > > + enable-active-high;
> > > > > > > > > + };
> > > > > > > > > +
> > > > > > > > > +};
> > > > > > > > > +
> > > > > > > > > +&emac {
> > > > > > > > > + phy-supply = <®_gmac_3v3>;
> > > > > > > > > +};
> > > > > > > >
> > > > > > > > I might be missing some context here, but I'm pretty sure that the
> > > > > > > > initial intent of the pine h64 DTS was to support the model A all
> > > > > > > > along.
> > > > > > > >
> > > > > > >
> > > > > > > The regulator changed between modelA and B.
> > > > > > > See this old patchset (supporting modelA) https://patchwork.kernel.org/patch/10539149/ for example.
> > > > > >
> > > > > > I'm not sure what your point is, but mine is that everything about the
> > > > > > model A should be in sun50i-h6-pine-h64.dts.
> > > > > >
> > > > >
> > > > > model A and B are different enough for distinct dtb, (see sub-thread
> > > > > on HDMI difference for an other difference than PHY regulator)
> > > >
> > > > I don't mind having separate DTBs for model A and model B.
> > > >
> > > > > And clearly, the current dtb is for model B.
> > > >
> > > > That DTS was added almost a year before the model B was announced, and
> > > > no commit to that file mention the model B, so it's definitely not
> > > > clear.
> > >
> > > Normal it was added for model A (without any ethernet/HDMI support,
> > > so nothing distinct from model B), and the modelB ethernet/HDMI
> > > support cames after.
> >
> > Changing the board a DT is meant to halfway through the development is
> > definitely not ok.
> >
> > > > > So do you mean that we need to create a new dtb for model B ? (and
> > > > > hack the current back to model A ?)
> > > >
> > > > I'd prefer not to hack anything, but yes
> > > >
> > >
> > > Since model A is not public (only evaluations boards exists), the
> > > probability of a production model A is low and the current dtb is
> > > perfect for model B , could you reconsider this ?
> >
> > I mean, you could buy it, so it's definitely public.
>
> Where ? official pineh64 site speaks only of modelB.
It's not available anymore, but it used to be.
> >
> > Model A also had HDMI, and it doesn't look like there's anything
> > particularly specific with that board.
>
> A subthread just say the opposite, modelA need something more for HDMI
> https://lkml.org/lkml/2019/8/12/394
Right, but that's not in the DT at the moment.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Best representation for TDM devices
From: Maxime Ripard @ 2019-08-20 14:06 UTC (permalink / raw)
To: Mark Brown; +Cc: Ali Burak Parım, linux-arm-kernel
In-Reply-To: <20190819154514.GB5563@sirena.co.uk>
[-- Attachment #1.1: Type: text/plain, Size: 1197 bytes --]
On Mon, Aug 19, 2019 at 04:45:14PM +0100, Mark Brown wrote:
> On Mon, Aug 19, 2019 at 10:41:41AM +0200, Maxime Ripard wrote:
> > On Wed, Aug 14, 2019 at 05:02:34PM +0100, Mark Brown wrote:
>
> > > OK, in that case I'd recommend providing them to userspace as a single
> > > four channel stream - keeping everything bundled together as long as
> > > possible to make it easier to keep the processing synced up.
>
> > Ok, that's what I had in mind as well :)
>
> > However, it looks like we can only capture as many channels as the max
> > being exposed by the codec on the link?
>
> > Any attempt at capturing something with 4 channels here using arecord
> > was either reduced to two channels (the amount of channels provided by
> > the adau7002 driver), or just refused by the ALSA core.
>
> > Is there anything that we need to configure / work on to enable this?
>
> I'd expect there's some issue in the capability/constraint matching code
> that needs fixing - that should work but I can totally see it not
> working unless someone goes in and does something to fix it.
Ok, I'll have a look, thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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] ARM: dts: vf610-zii-cfu1: Slow I2C0 down to 100kHz
From: Chris Healy @ 2019-08-20 14:08 UTC (permalink / raw)
To: Andrey Smirnov; +Cc: Fabio Estevam, Shawn Guo, linux-kernel, linux ARM
In-Reply-To: <20190820030804.8892-1-andrew.smirnov@gmail.com>
On Mon, Aug 19, 2019 at 8:08 PM Andrey Smirnov <andrew.smirnov@gmail.com> wrote:
>
> Fiber-optic module attached to the bus is only rated to work at
> 100kHz, so drop the bus frequncy to accomodate that.
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Chris Healy <cphealy@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/arm/boot/dts/vf610-zii-cfu1.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/vf610-zii-cfu1.dts b/arch/arm/boot/dts/vf610-zii-cfu1.dts
> index ff460a1de85a..28732249cfc0 100644
> --- a/arch/arm/boot/dts/vf610-zii-cfu1.dts
> +++ b/arch/arm/boot/dts/vf610-zii-cfu1.dts
> @@ -207,7 +207,7 @@
> };
>
> &i2c0 {
> - clock-frequency = <400000>;
> + clock-frequency = <100000>;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_i2c0>;
> status = "okay";
> --
> 2.21.0
>
Reviewed-by: Chris Healy <cphealy@gmail.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: [PATCH v2] iommu/arm-smmu: Break insecure users by disabling bypass by default
From: Robin Murphy @ 2019-08-20 14:10 UTC (permalink / raw)
To: Marc Gonzalez, Will Deacon, Jean-Philippe Brucker,
Michael S. Tsirkin
Cc: Joerg Roedel, Will Deacon, Douglas Anderson, Jon Hunter,
Thierry Reding, Linux ARM
In-Reply-To: <ada29112-87c1-e223-aa66-b7871e20a49a@free.fr>
On 20/08/2019 14:55, Marc Gonzalez wrote:
> On 19/08/2019 16:48, Will Deacon wrote:
>
>> If we can get by with extending the iommu-map entries for the masters,
>> that would certainly be the neatest imo. Sounds like it's worth a quick
>> hack, if nothing else.
>
> Tangent: I've been meaning to ask about some iommu-map shenanigan.
>
> My kernel reports:
>
> OF: /soc/pci@1c00000: no iommu-map translation for rid 0x0 on (null)
>
> Errr... "Is that a problem, doctor?"
>
> It's a pr_info() message from of_map_rid() in drivers/of/base.c
> I note that it used to be an error before fb709b5e1cca5
It means your host bridge doesn't have a stream ID. Depending on how the
root complex is wired up to the SMMU that may or may not be technically
accurate, but either way if your host bridge ever starts doing DMA for
itself then you should probably be more concerned with tracking down PCI
SIG's exorcism spec.
Robin.
_______________________________________________
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 2/4] iommu/io-pgtable-arm: Rationalise TTBRn handling
From: Robin Murphy @ 2019-08-20 14:17 UTC (permalink / raw)
To: Will Deacon; +Cc: robdclark, joro, jcrouse, iommu, linux-arm-kernel
In-Reply-To: <20190820101911.ndwtaf76kn3zplk2@willie-the-truck>
On 20/08/2019 11:19, Will Deacon wrote:
> On Mon, Aug 19, 2019 at 07:19:29PM +0100, Robin Murphy wrote:
>> TTBR1 values have so far been redundant since no users implement any
>> support for split address spaces. Crucially, though, one of the main
>> reasons for wanting to do so is to be able to manage each half entirely
>> independently, e.g. context-switching one set of mappings without
>> disturbing the other. Thus it seems unlikely that tying two tables
>> together in a single io_pgtable_cfg would ever be particularly desirable
>> or useful.
>>
>> Streamline the configs to just a single conceptual TTBR value
>> representing the allocated table. This paves the way for future users to
>> support split address spaces by simply allocating a table and dealing
>> with the detailed TTBRn logistics themselves.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/iommu/arm-smmu-v3.c | 2 +-
>> drivers/iommu/arm-smmu.c | 9 ++++-----
>> drivers/iommu/io-pgtable-arm-v7s.c | 16 +++++++---------
>> drivers/iommu/io-pgtable-arm.c | 7 +++----
>> drivers/iommu/ipmmu-vmsa.c | 2 +-
>> drivers/iommu/msm_iommu.c | 4 ++--
>> drivers/iommu/mtk_iommu.c | 4 ++--
>> drivers/iommu/qcom_iommu.c | 3 +--
>> include/linux/io-pgtable.h | 4 ++--
>> 9 files changed, 23 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>> index 2a8db896d698..2e50cf49c3c4 100644
>> --- a/drivers/iommu/arm-smmu-v3.c
>> +++ b/drivers/iommu/arm-smmu-v3.c
>> @@ -1722,7 +1722,7 @@ static int arm_smmu_domain_finalise_s1(struct arm_smmu_domain *smmu_domain,
>> }
>>
>> cfg->cd.asid = (u16)asid;
>> - cfg->cd.ttbr = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>> + cfg->cd.ttbr = pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
>> cfg->cd.tcr = pgtbl_cfg->arm_lpae_s1_cfg.tcr;
>> cfg->cd.mair = pgtbl_cfg->arm_lpae_s1_cfg.mair;
>> return 0;
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 184ca41e9de7..19030c4b5904 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -473,13 +473,12 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>> /* TTBRs */
>> if (stage1) {
>> if (cfg->fmt == ARM_SMMU_CTX_FMT_AARCH32_S) {
>> - cb->ttbr[0] = pgtbl_cfg->arm_v7s_cfg.ttbr[0];
>> - cb->ttbr[1] = pgtbl_cfg->arm_v7s_cfg.ttbr[1];
>> + cb->ttbr[0] = pgtbl_cfg->arm_v7s_cfg.ttbr;
>> + cb->ttbr[1] = 0;
>> } else {
>> - cb->ttbr[0] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>> + cb->ttbr[0] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
>> cb->ttbr[0] |= FIELD_PREP(TTBRn_ASID, cfg->asid);
>> - cb->ttbr[1] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
>> - cb->ttbr[1] |= FIELD_PREP(TTBRn_ASID, cfg->asid);
>> + cb->ttbr[1] = FIELD_PREP(TTBRn_ASID, cfg->asid);
>
> Why do you continue to put the ASID in here?
For the same reason we put it there before ;)
Although I guess if TCR.A1 were ever to get flipped accidentally then
we're still cool.
>> diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
>> index 34bb357b3cfa..de55b6d82ef1 100644
>> --- a/drivers/iommu/qcom_iommu.c
>> +++ b/drivers/iommu/qcom_iommu.c
>> @@ -247,10 +247,9 @@ static int qcom_iommu_init_domain(struct iommu_domain *domain,
>>
>> /* TTBRs */
>> iommu_writeq(ctx, ARM_SMMU_CB_TTBR0,
>> - pgtbl_cfg.arm_lpae_s1_cfg.ttbr[0] |
>> + pgtbl_cfg.arm_lpae_s1_cfg.ttbr |
>> FIELD_PREP(TTBRn_ASID, ctx->asid));
>> iommu_writeq(ctx, ARM_SMMU_CB_TTBR1,
>> - pgtbl_cfg.arm_lpae_s1_cfg.ttbr[1] |
>> FIELD_PREP(TTBRn_ASID, ctx->asid));
>
> Same here.
>
>> diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
>> index a6c8aa204733..7a0905d7a006 100644
>> --- a/include/linux/io-pgtable.h
>> +++ b/include/linux/io-pgtable.h
>> @@ -90,7 +90,7 @@ struct io_pgtable_cfg {
>> /* Low-level data specific to the table format */
>> union {
>> struct {
>> - u64 ttbr[2];
>> + u64 ttbr;
>> u64 tcr;
>> u64 mair;
>> } arm_lpae_s1_cfg;
>> @@ -101,7 +101,7 @@ struct io_pgtable_cfg {
>> } arm_lpae_s2_cfg;
>>
>> struct {
>> - u32 ttbr[2];
>> + u32 ttbr;
>
> We could probably do with a comment for these 'ttbr' field now saying that
> they refer to ttbr0 (since the tcr will have EPD1 set).
Yeah, I did wonder whether this might want elaboration, or whether the
commit messages plus the code consuming it made the idea sufficiently
clear - I guess that's my answer...
Robin.
_______________________________________________
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] ARM: dts: vf610-zii-cfu1: Slow I2C0 down to 100kHz
From: Marc Gonzalez @ 2019-08-20 14:39 UTC (permalink / raw)
To: Andrey Smirnov, Linux ARM; +Cc: Fabio Estevam, Shawn Guo, LKML, Chris Healy
In-Reply-To: <20190820030804.8892-1-andrew.smirnov@gmail.com>
On 20/08/2019 05:08, Andrey Smirnov wrote:
> Fiber-optic module attached to the bus is only rated to work at
> 100kHz, so drop the bus frequncy to accomodate that.
s/100kHz/100 kHz
s/frequncy/frequency
s/accomodate/accommodate
Regards.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/6] dt-bindings: soc: amlogic: clk-measure: Add SM1 compatible
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman
Cc: devicetree, Neil Armstrong, Martin Blumenstingl, linux-kernel,
linux-amlogic, Rob Herring, linux-arm-kernel
In-Reply-To: <20190820144052.18269-1-narmstrong@baylibre.com>
Add the Amlogic SM1 Compatible for the clk-measurer IP.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt b/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt
index 6bf6b43f8dd8..3dd563cec794 100644
--- a/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt
+++ b/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt
@@ -11,6 +11,7 @@ Required properties:
"amlogic,meson8b-clk-measure" for Meson8b SoCs
"amlogic,meson-axg-clk-measure" for AXG SoCs
"amlogic,meson-g12a-clk-measure" for G12a SoCs
+ "amlogic,meson-sm1-clk-measure" for SM1 SoCs
- reg: base address and size of the Clock Measurer register space.
Example:
--
2.22.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 4/6] dt-bindings: arm: amlogic: add SM1 bindings
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, devicetree, linux-kernel, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190820144052.18269-1-narmstrong@baylibre.com>
Add bindings for the new Amlogic SM1 SoC Family.
It a derivative of the G12A SoC Family with :
- Cortex-A55 core instead of A53
- more power domains
- a neural network co-processor
- a CSI input and image processor
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index 96f66911e3c6..d701e8447363 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -150,4 +150,7 @@ properties:
- const: amlogic,s922x
- const: amlogic,g12b
+ - description: Boards with the Amlogic Meson SM1 S905X3 SoC
+ items:
+ - const: amlogic,sm1
...
--
2.22.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 1/6] soc: amlogic: meson-gx-socinfo: Add SM1 and S905X3 IDs
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman
Cc: Neil Armstrong, Martin Blumenstingl, linux-kernel, linux-amlogic,
linux-arm-kernel, Jerome Brunet
In-Reply-To: <20190820144052.18269-1-narmstrong@baylibre.com>
Add the SoC IDs for the S905X3 Amlogic SM1 SoC.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/soc/amlogic/meson-gx-socinfo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/amlogic/meson-gx-socinfo.c b/drivers/soc/amlogic/meson-gx-socinfo.c
index ff86a75939e8..b9f4c6f4fd03 100644
--- a/drivers/soc/amlogic/meson-gx-socinfo.c
+++ b/drivers/soc/amlogic/meson-gx-socinfo.c
@@ -39,6 +39,7 @@ static const struct meson_gx_soc_id {
{ "TXHD", 0x27 },
{ "G12A", 0x28 },
{ "G12B", 0x29 },
+ { "SM1", 0x2b },
};
static const struct meson_gx_package_id {
@@ -66,6 +67,7 @@ static const struct meson_gx_package_id {
{ "S905X2", 0x28, 0x40, 0xf0 },
{ "S922X", 0x29, 0x40, 0xf0 },
{ "A311D", 0x29, 0x10, 0xf0 },
+ { "S905X3", 0x2b, 0x5, 0xf },
};
static inline unsigned int socinfo_to_major(u32 socinfo)
--
2.22.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 0/6] arm64: Add support for Amlogic SM1 SoC Family
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
The new Amlogic SM1 SoC Family is a derivative of the Amlogic G12A
SoC Family, with the following changes :
- Cortex-A55 cores instead of A53
- more power domains, including USB & PCIe
- a neural network co-processor (NNA)
- a CSI input and image processor
- some changes in the audio complex, thus not yet enabled
- new clocks, for NNA, CSI and a clock tree for each CPU Core
This serie does not add support for NNA, CSI, Audio, USB, Display
or DVFS, it only aligns with the current G12A Support.
With this serie, the SEI610 Board has supported :
- Default-boot CPU frequency
- Ethernet
- LEDs
- IR
- GPIO Buttons
- eMMC
- SDCard
- SDIO WiFi
- UART Bluetooth
Audio (HDMI, Embedded HP, MIcs), USB, HDMI, IR Output, & RGB Led
would be supported in following patchsets.
Dependencies:
- g12-common.dtsi from the DVFS patchset at [1]
Changes from rfc at [2]:
- Removed Power domain patches & display/USB support, will resend separately
- Removed applied AO-CEC patches
- Fixed clk-measure IDs
- Collected reviewed-by tags
[1] https://patchwork.kernel.org/cover/11025309/
[2] https://patchwork.kernel.org/cover/11025511/
Neil Armstrong (6):
soc: amlogic: meson-gx-socinfo: Add SM1 and S905X3 IDs
dt-bindings: soc: amlogic: clk-measure: Add SM1 compatible
soc: amlogic: clk-measure: Add support for SM1
dt-bindings: arm: amlogic: add SM1 bindings
dt-bindings: arm: amlogic: add SEI Robotics SEI610 bindings
arm64: dts: add support for SM1 based SEI Robotics SEI610
.../devicetree/bindings/arm/amlogic.yaml | 5 +
.../bindings/soc/amlogic/clk-measure.txt | 1 +
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-sm1-sei610.dts | 300 ++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 68 ++++
drivers/soc/amlogic/meson-clk-measure.c | 134 ++++++++
drivers/soc/amlogic/meson-gx-socinfo.c | 2 +
7 files changed, 511 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
--
2.22.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 5/6] dt-bindings: arm: amlogic: add SEI Robotics SEI610 bindings
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, devicetree, linux-kernel, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190820144052.18269-1-narmstrong@baylibre.com>
Add the compatible for the Amlogic SM1 Based SEI610 board.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index d701e8447363..b48ea1e4913a 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -152,5 +152,7 @@ properties:
- description: Boards with the Amlogic Meson SM1 S905X3 SoC
items:
+ - enum:
+ - seirobotics,sei610
- const: amlogic,sm1
...
--
2.22.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 3/6] soc: amlogic: clk-measure: Add support for SM1
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190820144052.18269-1-narmstrong@baylibre.com>
Add the clk-measurer clocks IDs for the Amlogic SM1 SoC family.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/soc/amlogic/meson-clk-measure.c | 134 ++++++++++++++++++++++++
1 file changed, 134 insertions(+)
diff --git a/drivers/soc/amlogic/meson-clk-measure.c b/drivers/soc/amlogic/meson-clk-measure.c
index f09b404b39d3..0fa47d77577d 100644
--- a/drivers/soc/amlogic/meson-clk-measure.c
+++ b/drivers/soc/amlogic/meson-clk-measure.c
@@ -357,6 +357,136 @@ static struct meson_msr_id clk_msr_g12a[CLK_MSR_MAX] = {
CLK_MSR_ID(122, "audio_pdm_dclk"),
};
+static struct meson_msr_id clk_msr_sm1[CLK_MSR_MAX] = {
+ CLK_MSR_ID(0, "ring_osc_out_ee_0"),
+ CLK_MSR_ID(1, "ring_osc_out_ee_1"),
+ CLK_MSR_ID(2, "ring_osc_out_ee_2"),
+ CLK_MSR_ID(3, "ring_osc_out_ee_3"),
+ CLK_MSR_ID(4, "gp0_pll"),
+ CLK_MSR_ID(5, "gp1_pll"),
+ CLK_MSR_ID(6, "enci"),
+ CLK_MSR_ID(7, "clk81"),
+ CLK_MSR_ID(8, "encp"),
+ CLK_MSR_ID(9, "encl"),
+ CLK_MSR_ID(10, "vdac"),
+ CLK_MSR_ID(11, "eth_tx"),
+ CLK_MSR_ID(12, "hifi_pll"),
+ CLK_MSR_ID(13, "mod_tcon"),
+ CLK_MSR_ID(14, "fec_0"),
+ CLK_MSR_ID(15, "fec_1"),
+ CLK_MSR_ID(16, "fec_2"),
+ CLK_MSR_ID(17, "sys_pll_div16"),
+ CLK_MSR_ID(18, "sys_cpu_div16"),
+ CLK_MSR_ID(19, "lcd_an_ph2"),
+ CLK_MSR_ID(20, "rtc_osc_out"),
+ CLK_MSR_ID(21, "lcd_an_ph3"),
+ CLK_MSR_ID(22, "eth_phy_ref"),
+ CLK_MSR_ID(23, "mpll_50m"),
+ CLK_MSR_ID(24, "eth_125m"),
+ CLK_MSR_ID(25, "eth_rmii"),
+ CLK_MSR_ID(26, "sc_int"),
+ CLK_MSR_ID(27, "in_mac"),
+ CLK_MSR_ID(28, "sar_adc"),
+ CLK_MSR_ID(29, "pcie_inp"),
+ CLK_MSR_ID(30, "pcie_inn"),
+ CLK_MSR_ID(31, "mpll_test_out"),
+ CLK_MSR_ID(32, "vdec"),
+ CLK_MSR_ID(34, "eth_mpll_50m"),
+ CLK_MSR_ID(35, "mali"),
+ CLK_MSR_ID(36, "hdmi_tx_pixel"),
+ CLK_MSR_ID(37, "cdac"),
+ CLK_MSR_ID(38, "vdin_meas"),
+ CLK_MSR_ID(39, "bt656"),
+ CLK_MSR_ID(40, "arm_ring_osc_out_4"),
+ CLK_MSR_ID(41, "eth_rx_or_rmii"),
+ CLK_MSR_ID(42, "mp0_out"),
+ CLK_MSR_ID(43, "fclk_div5"),
+ CLK_MSR_ID(44, "pwm_b"),
+ CLK_MSR_ID(45, "pwm_a"),
+ CLK_MSR_ID(46, "vpu"),
+ CLK_MSR_ID(47, "ddr_dpll_pt"),
+ CLK_MSR_ID(48, "mp1_out"),
+ CLK_MSR_ID(49, "mp2_out"),
+ CLK_MSR_ID(50, "mp3_out"),
+ CLK_MSR_ID(51, "sd_emmc_c"),
+ CLK_MSR_ID(52, "sd_emmc_b"),
+ CLK_MSR_ID(53, "sd_emmc_a"),
+ CLK_MSR_ID(54, "vpu_clkc"),
+ CLK_MSR_ID(55, "vid_pll_div_out"),
+ CLK_MSR_ID(56, "wave420l_a"),
+ CLK_MSR_ID(57, "wave420l_c"),
+ CLK_MSR_ID(58, "wave420l_b"),
+ CLK_MSR_ID(59, "hcodec"),
+ CLK_MSR_ID(60, "arm_ring_osc_out_5"),
+ CLK_MSR_ID(61, "gpio_msr"),
+ CLK_MSR_ID(62, "hevcb"),
+ CLK_MSR_ID(63, "dsi_meas"),
+ CLK_MSR_ID(64, "spicc_1"),
+ CLK_MSR_ID(65, "spicc_0"),
+ CLK_MSR_ID(66, "vid_lock"),
+ CLK_MSR_ID(67, "dsi_phy"),
+ CLK_MSR_ID(68, "hdcp22_esm"),
+ CLK_MSR_ID(69, "hdcp22_skp"),
+ CLK_MSR_ID(70, "pwm_f"),
+ CLK_MSR_ID(71, "pwm_e"),
+ CLK_MSR_ID(72, "pwm_d"),
+ CLK_MSR_ID(73, "pwm_c"),
+ CLK_MSR_ID(74, "arm_ring_osc_out_6"),
+ CLK_MSR_ID(75, "hevcf"),
+ CLK_MSR_ID(76, "arm_ring_osc_out_7"),
+ CLK_MSR_ID(77, "rng_ring_osc_0"),
+ CLK_MSR_ID(78, "rng_ring_osc_1"),
+ CLK_MSR_ID(79, "rng_ring_osc_2"),
+ CLK_MSR_ID(80, "rng_ring_osc_3"),
+ CLK_MSR_ID(81, "vapb"),
+ CLK_MSR_ID(82, "ge2d"),
+ CLK_MSR_ID(83, "co_rx"),
+ CLK_MSR_ID(84, "co_tx"),
+ CLK_MSR_ID(85, "arm_ring_osc_out_8"),
+ CLK_MSR_ID(86, "arm_ring_osc_out_9"),
+ CLK_MSR_ID(87, "mipi_dsi_phy"),
+ CLK_MSR_ID(88, "cis2_adapt"),
+ CLK_MSR_ID(89, "hdmi_todig"),
+ CLK_MSR_ID(90, "hdmitx_sys"),
+ CLK_MSR_ID(91, "nna_core"),
+ CLK_MSR_ID(92, "nna_axi"),
+ CLK_MSR_ID(93, "vad"),
+ CLK_MSR_ID(94, "eth_phy_rx"),
+ CLK_MSR_ID(95, "eth_phy_pll"),
+ CLK_MSR_ID(96, "vpu_b"),
+ CLK_MSR_ID(97, "cpu_b_tmp"),
+ CLK_MSR_ID(98, "ts"),
+ CLK_MSR_ID(99, "arm_ring_osc_out_10"),
+ CLK_MSR_ID(100, "arm_ring_osc_out_11"),
+ CLK_MSR_ID(101, "arm_ring_osc_out_12"),
+ CLK_MSR_ID(102, "arm_ring_osc_out_13"),
+ CLK_MSR_ID(103, "arm_ring_osc_out_14"),
+ CLK_MSR_ID(104, "arm_ring_osc_out_15"),
+ CLK_MSR_ID(105, "arm_ring_osc_out_16"),
+ CLK_MSR_ID(106, "ephy_test"),
+ CLK_MSR_ID(107, "au_dac_g128x"),
+ CLK_MSR_ID(108, "audio_locker_out"),
+ CLK_MSR_ID(109, "audio_locker_in"),
+ CLK_MSR_ID(110, "audio_tdmout_c_sclk"),
+ CLK_MSR_ID(111, "audio_tdmout_b_sclk"),
+ CLK_MSR_ID(112, "audio_tdmout_a_sclk"),
+ CLK_MSR_ID(113, "audio_tdmin_lb_sclk"),
+ CLK_MSR_ID(114, "audio_tdmin_c_sclk"),
+ CLK_MSR_ID(115, "audio_tdmin_b_sclk"),
+ CLK_MSR_ID(116, "audio_tdmin_a_sclk"),
+ CLK_MSR_ID(117, "audio_resample"),
+ CLK_MSR_ID(118, "audio_pdm_sys"),
+ CLK_MSR_ID(119, "audio_spdifout_b"),
+ CLK_MSR_ID(120, "audio_spdifout"),
+ CLK_MSR_ID(121, "audio_spdifin"),
+ CLK_MSR_ID(122, "audio_pdm_dclk"),
+ CLK_MSR_ID(123, "audio_resampled"),
+ CLK_MSR_ID(124, "earcrx_pll"),
+ CLK_MSR_ID(125, "earcrx_pll_test"),
+ CLK_MSR_ID(126, "csi_phy0"),
+ CLK_MSR_ID(127, "csi2_data"),
+};
+
static int meson_measure_id(struct meson_msr_id *clk_msr_id,
unsigned int duration)
{
@@ -545,6 +675,10 @@ static const struct of_device_id meson_msr_match_table[] = {
.compatible = "amlogic,meson-g12a-clk-measure",
.data = (void *)clk_msr_g12a,
},
+ {
+ .compatible = "amlogic,meson-sm1-clk-measure",
+ .data = (void *)clk_msr_sm1,
+ },
{ /* sentinel */ }
};
--
2.22.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 6/6] arm64: dts: add support for SM1 based SEI Robotics SEI610
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190820144052.18269-1-narmstrong@baylibre.com>
Add support for the Amlogic SM1 Based SEI610 board.
The SM1 SoC is a derivative of the G12A SoC Family with :
- Cortex-A55 core instead of A53
- more power domains, including USB & PCIe
- a neural network co-processor (NNA)
- a CSI input and image processor
- some changes in the audio complex, thus not yet enabled
The SEI610 board is a derivative of the SEI510 board with :
- removed ADC based touch button, replaced with 3x GPIO buttons
- physical switch disabling on-board MICs
- USB-C port for USB 2.0 OTG
- On-board FTDI USB2SERIAL port for Linux console
Audio, Display and USB support will be added later when support of the
corresponding power domains will be added, for now they are kept disabled.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-sm1-sei610.dts | 300 ++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 68 ++++
3 files changed, 369 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index ae5e8d0c08da..edbf128e7707 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -34,3 +34,4 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q200.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q201.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-rbox-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-sm1-sei610.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
new file mode 100644
index 000000000000..12dab0ba2f26
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
@@ -0,0 +1,300 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre SAS. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include "meson-sm1.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/gpio/meson-g12a-gpio.h>
+
+/ {
+ compatible = "seirobotics,sei610", "amlogic,sm1";
+ model = "SEI Robotics SEI610";
+
+ aliases {
+ serial0 = &uart_AO;
+ ethernet0 = ðmac;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ emmc_pwrseq: emmc-pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&gpio BOOT_12 GPIO_ACTIVE_LOW>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys-polled";
+ poll-interval = <100>;
+
+ key1 {
+ label = "A";
+ linux,code = <BTN_0>;
+ gpios = <&gpio GPIOH_6 GPIO_ACTIVE_LOW>;
+ };
+
+ key2 {
+ label = "B";
+ linux,code = <BTN_1>;
+ gpios = <&gpio GPIOH_7 GPIO_ACTIVE_LOW>;
+ };
+
+ key3 {
+ label = "C";
+ linux,code = <BTN_2>;
+ gpios = <&gpio_ao GPIOAO_2 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ bluetooth {
+ label = "sei610:blue:bt";
+ gpios = <&gpio GPIOC_7 (GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN)>;
+ default-state = "off";
+ };
+ };
+
+ pwmleds {
+ compatible = "pwm-leds";
+
+ power {
+ label = "sei610:red:power";
+ pwms = <&pwm_AO_ab 0 30518 0>;
+ max-brightness = <255>;
+ linux,default-trigger = "default-on";
+ active-low;
+ };
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x40000000>;
+ };
+
+ ao_5v: regulator-ao_5v {
+ compatible = "regulator-fixed";
+ regulator-name = "AO_5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&dc_in>;
+ regulator-always-on;
+ };
+
+ dc_in: regulator-dc_in {
+ compatible = "regulator-fixed";
+ regulator-name = "DC_IN";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ emmc_1v8: regulator-emmc_1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "EMMC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vddao_3v3>;
+ regulator-always-on;
+ };
+
+ vddao_3v3: regulator-vddao_3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDAO_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&dc_in>;
+ regulator-always-on;
+ };
+
+ /* Used by Tuner, RGB Led & IR Emitter LED array */
+ vddao_3v3_t: regultor-vddao_3v3_t {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDAO_3V3_T";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vddao_3v3>;
+ gpio = <&gpio GPIOH_8 GPIO_OPEN_DRAIN>;
+ enable-active-low;
+ regulator-always-on;
+ };
+
+ vddio_ao1v8: regulator-vddio_ao1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vddao_3v3>;
+ regulator-always-on;
+ };
+
+ reserved-memory {
+ /* TEE Reserved Memory */
+ bl32_reserved: bl32@5000000 {
+ reg = <0x0 0x05300000 0x0 0x2000000>;
+ no-map;
+ };
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
+ clocks = <&wifi32k>;
+ clock-names = "ext_clock";
+ };
+
+ wifi32k: wifi32k {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
+ };
+};
+
+&cec_AO {
+ pinctrl-0 = <&cec_ao_a_h_pins>;
+ pinctrl-names = "default";
+ status = "disabled";
+ hdmi-phandle = <&hdmi_tx>;
+};
+
+&cecb_AO {
+ pinctrl-0 = <&cec_ao_b_h_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ hdmi-phandle = <&hdmi_tx>;
+};
+
+ðmac {
+ status = "okay";
+ phy-handle = <&internal_ephy>;
+ phy-mode = "rmii";
+};
+
+&i2c3 {
+ status = "okay";
+ pinctrl-0 = <&i2c3_sda_a_pins>, <&i2c3_sck_a_pins>;
+ pinctrl-names = "default";
+};
+
+&ir {
+ status = "okay";
+ pinctrl-0 = <&remote_input_ao_pins>;
+ pinctrl-names = "default";
+};
+
+&pwm_AO_ab {
+ status = "okay";
+ pinctrl-0 = <&pwm_ao_a_pins>;
+ pinctrl-names = "default";
+ clocks = <&xtal>;
+ clock-names = "clkin0";
+};
+
+&pwm_ef {
+ status = "okay";
+ pinctrl-0 = <&pwm_e_pins>;
+ pinctrl-names = "default";
+ clocks = <&xtal>;
+ clock-names = "clkin0";
+};
+
+&saradc {
+ status = "okay";
+ vref-supply = <&vddio_ao1v8>;
+};
+
+/* SDIO */
+&sd_emmc_a {
+ status = "okay";
+ pinctrl-0 = <&sdio_pins>;
+ pinctrl-1 = <&sdio_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ sd-uhs-sdr50;
+ max-frequency = <100000000>;
+
+ non-removable;
+ disable-wp;
+
+ mmc-pwrseq = <&sdio_pwrseq>;
+
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_ao1v8>;
+
+ brcmf: wifi@1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ };
+};
+
+/* SD card */
+&sd_emmc_b {
+ status = "okay";
+ pinctrl-0 = <&sdcard_c_pins>;
+ pinctrl-1 = <&sdcard_clk_gate_c_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <50000000>;
+ disable-wp;
+
+ cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddao_3v3>;
+};
+
+/* eMMC */
+&sd_emmc_c {
+ status = "okay";
+ pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
+ pinctrl-1 = <&emmc_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+
+ mmc-pwrseq = <&emmc_pwrseq>;
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&emmc_1v8>;
+};
+
+&uart_A {
+ status = "okay";
+ pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
+ pinctrl-names = "default";
+ uart-has-rtscts;
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
+ max-speed = <2000000>;
+ clocks = <&wifi32k>;
+ clock-names = "lpo";
+ vbat-supply = <&vddao_3v3>;
+ vddio-supply = <&vddio_ao1v8>;
+ };
+};
+
+/* Exposed via the on-board USB to Serial FT232RL IC */
+&uart_AO {
+ status = "okay";
+ pinctrl-0 = <&uart_ao_a_pins>;
+ pinctrl-names = "default";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
new file mode 100644
index 000000000000..e902d4f9165f
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ */
+
+#include "meson-g12-common.dtsi"
+
+/ {
+ compatible = "amlogic,sm1";
+
+ cpus {
+ #address-cells = <0x2>;
+ #size-cells = <0x0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x2>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x3>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ l2: l2-cache0 {
+ compatible = "cache";
+ };
+ };
+};
+
+&cecb_AO {
+ compatible = "amlogic,meson-sm1-ao-cec";
+};
+
+&clk_msr {
+ compatible = "amlogic,meson-sm1-clk-measure";
+};
+
+&pwrc_vpu {
+ status = "disabled";
+};
+
+&vpu {
+ status = "disabled";
+};
--
2.22.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 4/4] iommu/io-pgtable-arm: Prepare for TTBR1 usage
From: Robin Murphy @ 2019-08-20 14:51 UTC (permalink / raw)
To: Will Deacon; +Cc: robdclark, joro, jcrouse, iommu, linux-arm-kernel
In-Reply-To: <20190820103048.xacfbtn5o4wermhi@willie-the-truck>
On 20/08/2019 11:30, Will Deacon wrote:
> On Mon, Aug 19, 2019 at 07:19:31PM +0100, Robin Murphy wrote:
>> Now that callers are free to use a given table for TTBR1 if they wish
>> (all they need do is shift the provided attributes when constructing
>> their final TCR value), the only remaining impediment is the address
>> validation on map/unmap. The fact that the LPAE address space split is
>> symmetric makes this easy to accommodate - by simplifying the current
>> range checks into explicit tests that address bits above IAS are all
>> zero, it then follows straightforwardly to add the inverse test to
>> allow the all-ones case as well.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/iommu/io-pgtable-arm.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
>> index 09cb20671fbb..f39c50356351 100644
>> --- a/drivers/iommu/io-pgtable-arm.c
>> +++ b/drivers/iommu/io-pgtable-arm.c
>> @@ -475,13 +475,13 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
>> arm_lpae_iopte *ptep = data->pgd;
>> int ret, lvl = ARM_LPAE_START_LVL(data);
>> arm_lpae_iopte prot;
>> + long iaext = (long)iova >> data->iop.cfg.ias;
>>
>> /* If no access, then nothing to do */
>> if (!(iommu_prot & (IOMMU_READ | IOMMU_WRITE)))
>> return 0;
>>
>> - if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias) ||
>> - paddr >= (1ULL << data->iop.cfg.oas)))
>> + if (WARN_ON((iaext && ~iaext) || paddr >> data->iop.cfg.oas))
>
> I had to read that '&&' twice, but I see what you're doing now :)
>
>> return -ERANGE;
>
> This doesn't seem sufficient to prevent a mixture of TTBR1 and TTBR0
> addresses from being mapped in the same TTBR. Perhaps we need a quirk for
> TTBR1, which could then take care of setting EPDx appropriately?
Right, that's the one downside of going for the minimalist "io-pgtable
doesn't even have to know" approach. On reflection, though, in that
paradigm it should probably be the caller's responsibility to convert
TTBR1 addresses to preserve the "as if TTBR0" illusion anyway :/
The advantage of not having a quirk is that it allows split address
spaces to fit more closely with the aux_domain idea, i.e. we could
allocate and initialise a domain without having to assume, or even care,
whether it will end up attached as a primary or aux domain. It *might*
even be potentially useful to have a domain attached to TTBR0 of one
device's context and TTBR1 of another's at the same time, although
that's pretty niche.
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/6] Add ethernet support for Orange Pi 3
From: megous @ 2019-08-20 14:53 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin
Cc: Ondrej Jirman, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
From: Ondrej Jirman <megous@megous.com>
This series implements ethernet support for Xunlong Orange Pi 3 board, by:
- making small cleanups of existing dwmac-sun8i code
- adding DT bindings docummentation
- adding support for phy-io-supply to dwmac-sun8i code
- adding DT configuration for Orange Pi 3 board
For some people, ethernet doesn't work after reboot because u-boot doesn't
support AXP805 PMIC, and will not turn off the etherent PHY regulators.
So the regulator controlled by gpio will be shut down, but the other one
controlled by the AXP PMIC will not.
This is a problem only when running with a builtin driver. This needs
to be fixed in u-boot and should not prevent these patches from being
merged.
This evolved out of the Orange Pi 3 patches series, as I didn't want
to stretch that out any longer.
Please take a look.
thank you and regards,
Ondrej Jirman
Ondrej Jirman (6):
dt-bindings: net: sun8i-a83t-emac: Add phy-supply property
dt-bindings: net: sun8i-a83t-emac: Add phy-io-supply property
net: stmmac: sun8i: Use devm_regulator_get for PHY regulator
net: stmmac: sun8i: Rename PHY regulator variable to regulator_phy
net: stmmac: sun8i: Add support for enabling a regulator for PHY I/O
pins
arm64: dts: allwinner: orange-pi-3: Enable ethernet
.../net/allwinner,sun8i-a83t-emac.yaml | 8 ++
.../dts/allwinner/sun50i-h6-orangepi-3.dts | 40 ++++++++++
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 74 ++++++++++++-------
3 files changed, 96 insertions(+), 26 deletions(-)
--
2.22.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/6] dt-bindings: net: sun8i-a83t-emac: Add phy-io-supply property
From: megous @ 2019-08-20 14:53 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin
Cc: Ondrej Jirman, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190820145343.29108-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Some PHYs require separate power supply for I/O pins in some modes
of operation. Add phy-io-supply property, to allow enabling this
power supply.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
index 304f244e9ab5..782e202aa124 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
@@ -47,6 +47,10 @@ properties:
description:
PHY regulator
+ phy-io-supply:
+ description:
+ PHY I/O pins regulator
+
required:
- compatible
- reg
--
2.22.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 1/6] dt-bindings: net: sun8i-a83t-emac: Add phy-supply property
From: megous @ 2019-08-20 14:53 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin
Cc: Ondrej Jirman, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190820145343.29108-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
This is already supported by the driver, but is missing from the
bindings.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
index 3fb0714e761e..304f244e9ab5 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
@@ -43,6 +43,10 @@ properties:
Phandle to the device containing the EMAC or GMAC clock
register
+ phy-supply:
+ description:
+ PHY regulator
+
required:
- compatible
- reg
--
2.22.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 4/6] net: stmmac: sun8i: Rename PHY regulator variable to regulator_phy
From: megous @ 2019-08-20 14:53 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin
Cc: Ondrej Jirman, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190820145343.29108-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
We'll be adding further optional regulators, and this makes it clearer
what the regulator is for.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 32 ++++++++++---------
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 3e951a11aec3..e7df30d3cab1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -57,19 +57,21 @@ struct emac_variant {
};
/* struct sunxi_priv_data - hold all sunxi private data
- * @tx_clk: reference to MAC TX clock
- * @ephy_clk: reference to the optional EPHY clock for the internal PHY
- * @regulator: reference to the optional regulator
- * @rst_ephy: reference to the optional EPHY reset for the internal PHY
- * @variant: reference to the current board variant
- * @regmap: regmap for using the syscon
- * @internal_phy_powered: Does the internal PHY is enabled
- * @mux_handle: Internal pointer used by mdio-mux lib
+ * @tx_clk: reference to MAC TX clock
+ * @ephy_clk: reference to the optional EPHY clock for
+ * the internal PHY
+ * @regulator_phy: reference to the optional regulator
+ * @rst_ephy: reference to the optional EPHY reset for
+ * the internal PHY
+ * @variant: reference to the current board variant
+ * @regmap: regmap for using the syscon
+ * @internal_phy_powered: Does the internal PHY is enabled
+ * @mux_handle: Internal pointer used by mdio-mux lib
*/
struct sunxi_priv_data {
struct clk *tx_clk;
struct clk *ephy_clk;
- struct regulator *regulator;
+ struct regulator *regulator_phy;
struct reset_control *rst_ephy;
const struct emac_variant *variant;
struct regmap_field *regmap_field;
@@ -528,9 +530,9 @@ static int sun8i_dwmac_init(struct platform_device *pdev, void *priv)
struct sunxi_priv_data *gmac = priv;
int ret;
- ret = regulator_enable(gmac->regulator);
+ ret = regulator_enable(gmac->regulator_phy);
if (ret) {
- dev_err(&pdev->dev, "Fail to enable regulator\n");
+ dev_err(&pdev->dev, "Fail to enable PHY regulator\n");
return ret;
}
@@ -990,7 +992,7 @@ static void sun8i_dwmac_exit(struct platform_device *pdev, void *priv)
clk_disable_unprepare(gmac->tx_clk);
- regulator_disable(gmac->regulator);
+ regulator_disable(gmac->regulator_phy);
}
static void sun8i_dwmac_set_mac_loopback(void __iomem *ioaddr, bool enable)
@@ -1126,9 +1128,9 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
}
/* Optional regulator for PHY */
- gmac->regulator = devm_regulator_get(dev, "phy");
- if (IS_ERR(gmac->regulator)) {
- ret = PTR_ERR(gmac->regulator);
+ gmac->regulator_phy = devm_regulator_get(dev, "phy");
+ if (IS_ERR(gmac->regulator_phy)) {
+ ret = PTR_ERR(gmac->regulator_phy);
if (ret != -EPROBE_DEFER)
dev_err(dev, "Failed to get PHY regulator (%d)\n", ret);
return ret;
--
2.22.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 3/6] net: stmmac: sun8i: Use devm_regulator_get for PHY regulator
From: megous @ 2019-08-20 14:53 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin
Cc: Ondrej Jirman, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190820145343.29108-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Use devm_regulator_get instead of devm_regulator_get_optional and rely
on dummy supply. This avoids NULL checks before regulator_enable/disable
calls.
This path also improves error reporting, because we now report both
use of dummy supply and error during registration with more detail,
instead of generic info level message "No regulator found" that
was reported previously on errors and lack of regulator property in DT.
Finally, we'll be adding further optional regulators, and the overall
code will be simpler.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 23 ++++++++-----------
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 4083019c547a..3e951a11aec3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -528,12 +528,10 @@ static int sun8i_dwmac_init(struct platform_device *pdev, void *priv)
struct sunxi_priv_data *gmac = priv;
int ret;
- if (gmac->regulator) {
- ret = regulator_enable(gmac->regulator);
- if (ret) {
- dev_err(&pdev->dev, "Fail to enable regulator\n");
- return ret;
- }
+ ret = regulator_enable(gmac->regulator);
+ if (ret) {
+ dev_err(&pdev->dev, "Fail to enable regulator\n");
+ return ret;
}
ret = clk_prepare_enable(gmac->tx_clk);
@@ -992,8 +990,7 @@ static void sun8i_dwmac_exit(struct platform_device *pdev, void *priv)
clk_disable_unprepare(gmac->tx_clk);
- if (gmac->regulator)
- regulator_disable(gmac->regulator);
+ regulator_disable(gmac->regulator);
}
static void sun8i_dwmac_set_mac_loopback(void __iomem *ioaddr, bool enable)
@@ -1129,12 +1126,12 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
}
/* Optional regulator for PHY */
- gmac->regulator = devm_regulator_get_optional(dev, "phy");
+ gmac->regulator = devm_regulator_get(dev, "phy");
if (IS_ERR(gmac->regulator)) {
- if (PTR_ERR(gmac->regulator) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
- dev_info(dev, "No regulator found\n");
- gmac->regulator = NULL;
+ ret = PTR_ERR(gmac->regulator);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get PHY regulator (%d)\n", ret);
+ return ret;
}
/* The "GMAC clock control" register might be located in the
--
2.22.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 5/6] net: stmmac: sun8i: Add support for enabling a regulator for PHY I/O pins
From: megous @ 2019-08-20 14:53 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin
Cc: Ondrej Jirman, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190820145343.29108-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Orange Pi 3 has two regulators that power the Realtek RTL8211E. According
to the phy datasheet, both regulators need to be enabled at the same time.
Add support for the second optional regulator, "phy-io", to the glue
driver.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 31 ++++++++++++++++---
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index e7df30d3cab1..e96337b7cd12 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -61,6 +61,8 @@ struct emac_variant {
* @ephy_clk: reference to the optional EPHY clock for
* the internal PHY
* @regulator_phy: reference to the optional regulator
+ * @regulator_phy_io: reference to the optional regulator for
+ * PHY I/O pins
* @rst_ephy: reference to the optional EPHY reset for
* the internal PHY
* @variant: reference to the current board variant
@@ -72,6 +74,7 @@ struct sunxi_priv_data {
struct clk *tx_clk;
struct clk *ephy_clk;
struct regulator *regulator_phy;
+ struct regulator *regulator_phy_io;
struct reset_control *rst_ephy;
const struct emac_variant *variant;
struct regmap_field *regmap_field;
@@ -530,21 +533,30 @@ static int sun8i_dwmac_init(struct platform_device *pdev, void *priv)
struct sunxi_priv_data *gmac = priv;
int ret;
+ ret = regulator_enable(gmac->regulator_phy_io);
+ if (ret) {
+ dev_err(&pdev->dev, "Fail to enable PHY I/O regulator\n");
+ return ret;
+ }
+
ret = regulator_enable(gmac->regulator_phy);
if (ret) {
dev_err(&pdev->dev, "Fail to enable PHY regulator\n");
- return ret;
+ goto err_disable_regulator_phy_io;
}
ret = clk_prepare_enable(gmac->tx_clk);
if (ret) {
- if (gmac->regulator)
- regulator_disable(gmac->regulator);
dev_err(&pdev->dev, "Could not enable AHB clock\n");
- return ret;
+ goto err_disable_regulator_phy;
}
return 0;
+err_disable_regulator_phy:
+ regulator_disable(gmac->regulator_phy);
+err_disable_regulator_phy_io:
+ regulator_disable(gmac->regulator_phy_io);
+ return ret;
}
static void sun8i_dwmac_core_init(struct mac_device_info *hw,
@@ -993,6 +1005,7 @@ static void sun8i_dwmac_exit(struct platform_device *pdev, void *priv)
clk_disable_unprepare(gmac->tx_clk);
regulator_disable(gmac->regulator_phy);
+ regulator_disable(gmac->regulator_phy_io);
}
static void sun8i_dwmac_set_mac_loopback(void __iomem *ioaddr, bool enable)
@@ -1136,6 +1149,16 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
return ret;
}
+ /* Optional regulator for PHY I/O pins */
+ gmac->regulator_phy_io = devm_regulator_get(dev, "phy-io");
+ if (IS_ERR(gmac->regulator_phy_io)) {
+ ret = PTR_ERR(gmac->regulator_phy_io);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get PHY I/O regulator (%d)\n",
+ ret);
+ return ret;
+ }
+
/* The "GMAC clock control" register might be located in the
* CCU address range (on the R40), or the system control address
* range (on most other sun8i and later SoCs).
--
2.22.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 6/6] arm64: dts: allwinner: orange-pi-3: Enable ethernet
From: megous @ 2019-08-20 14:53 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin
Cc: Ondrej Jirman, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190820145343.29108-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Orange Pi 3 has two regulators that power the Realtek RTL8211E
PHY. According to the datasheet, both regulators need to be enabled
at the same time, or that "phy-io" should be enabled slightly earlier
than "phy" regulator.
RTL8211E/RTL8211EG datasheet says:
Note 4: 2.5V (or 1.8/1.5V) RGMII power should be risen simultaneously
or slightly earlier than 3.3V power. Rising 2.5V (or 1.8/1.5V) power
later than 3.3V power may lead to errors.
The driver ensures the regulator enable ordering. The timing is set
in DT via startup-delay-us.
We also need to wait at least 30ms after power-up/reset, before
accessing the PHY registers.
All values of RX/TX delay were tested exhaustively and a middle one
of the range of working values was chosen.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../dts/allwinner/sun50i-h6-orangepi-3.dts | 40 +++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
index eda9d5f640b9..18349e60b8c6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -15,6 +15,7 @@
aliases {
serial0 = &uart0;
+ ethernet0 = &emac;
};
chosen {
@@ -56,6 +57,15 @@
regulator-max-microvolt = <5000000>;
regulator-always-on;
};
+
+ reg_gmac_2v5: gmac-2v5 {
+ compatible = "regulator-fixed";
+ regulator-name = "gmac-2v5";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ enable-active-high;
+ gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
+ };
};
&cpu0 {
@@ -74,6 +84,35 @@
status = "okay";
};
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ext_rgmii_pins>;
+ phy-mode = "rgmii";
+ phy-handle = <&ext_rgmii_phy>;
+ /*
+ * The board uses 2.5V RGMII signalling. Power sequence to enable
+ * the phy is to enable GMAC-2V5 and GMAC-3V (aldo2) power rails
+ * at the same time and to wait 100ms. The driver enables phy-io
+ * first. Delay is achieved with enable-ramp-delay on reg_aldo2.
+ */
+ phy-supply = <®_aldo2>;
+ phy-io-supply = <®_gmac_2v5>;
+ allwinner,rx-delay-ps = <1500>;
+ allwinner,tx-delay-ps = <700>;
+ status = "okay";
+};
+
+&mdio {
+ ext_rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+
+ reset-gpios = <&pio 3 14 GPIO_ACTIVE_LOW>; /* PD14 */
+ reset-assert-us = <15000>;
+ reset-deassert-us = <40000>;
+ };
+};
+
&hdmi {
status = "okay";
};
@@ -136,6 +175,7 @@
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-name = "vcc33-audio-tv-ephy-mac";
+ regulator-enable-ramp-delay = <100000>;
};
/* ALDO3 is shorted to CLDO1 */
--
2.22.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: [RFC 04/11] soc: amlogic: Add support for SM1 power controller
From: Neil Armstrong @ 2019-08-20 14:55 UTC (permalink / raw)
To: Kevin Hilman, jbrunet; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel
In-Reply-To: <7hftlwvhdk.fsf@baylibre.com>
On 20/08/2019 01:56, Kevin Hilman wrote:
> Neil Armstrong <narmstrong@baylibre.com> writes:
>
>> Add support for the General Purpose Amlogic SM1 Power controller,
>> dedicated to the PCIe, USB, NNA and GE2D Power Domains.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>
> I like this driver in general, but as I look at all the EE power domains
> for GX, G12 and SM1 they are really very similar. I had started to
> generalize the gx-pwrc-vpu driver and it ends up looking just like this.
Yes I developed it to be generic, but when starting to fill up the GXBB/GXL/G12A
domains, except the VPU, they only need the PD parts.
>
> I think this driver could be generalized just a little bit more and then
> replace the the GX-specific VPU one, and AFAICT, then be used across all
> the 64-bit SoCs, and be called "meson-pwrc-ee" or something like that...
>
>> ---
>> drivers/soc/amlogic/Kconfig | 11 ++
>> drivers/soc/amlogic/Makefile | 1 +
>> drivers/soc/amlogic/meson-sm1-pwrc.c | 245 +++++++++++++++++++++++++++
>> 3 files changed, 257 insertions(+)
>> create mode 100644 drivers/soc/amlogic/meson-sm1-pwrc.c
>>
>> diff --git a/drivers/soc/amlogic/Kconfig b/drivers/soc/amlogic/Kconfig
>> index 5501ad5650b2..596f1afef1a7 100644
>> --- a/drivers/soc/amlogic/Kconfig
>> +++ b/drivers/soc/amlogic/Kconfig
>> @@ -36,6 +36,17 @@ config MESON_GX_PM_DOMAINS
>> Say yes to expose Amlogic Meson GX Power Domains as
>> Generic Power Domains.
>>
>> +config MESON_SM1_PM_DOMAINS
>> + bool "Amlogic Meson SM1 Power Domains driver"
>> + depends on ARCH_MESON || COMPILE_TEST
>> + depends on PM && OF
>> + default ARCH_MESON
>> + select PM_GENERIC_DOMAINS
>> + select PM_GENERIC_DOMAINS_OF
>> + help
>> + Say yes to expose Amlogic Meson SM1 Power Domains as
>> + Generic Power Domains.
>> +
>> config MESON_MX_SOCINFO
>> bool "Amlogic Meson MX SoC Information driver"
>> depends on ARCH_MESON || COMPILE_TEST
>> diff --git a/drivers/soc/amlogic/Makefile b/drivers/soc/amlogic/Makefile
>> index bf2d109f61e9..f99935499ee6 100644
>> --- a/drivers/soc/amlogic/Makefile
>> +++ b/drivers/soc/amlogic/Makefile
>> @@ -3,3 +3,4 @@ obj-$(CONFIG_MESON_CLK_MEASURE) += meson-clk-measure.o
>> obj-$(CONFIG_MESON_GX_SOCINFO) += meson-gx-socinfo.o
>> obj-$(CONFIG_MESON_GX_PM_DOMAINS) += meson-gx-pwrc-vpu.o
>> obj-$(CONFIG_MESON_MX_SOCINFO) += meson-mx-socinfo.o
>> +obj-$(CONFIG_MESON_SM1_PM_DOMAINS) += meson-sm1-pwrc.o
>> diff --git a/drivers/soc/amlogic/meson-sm1-pwrc.c b/drivers/soc/amlogic/meson-sm1-pwrc.c
>> new file mode 100644
>> index 000000000000..9ece1d06f417
>> --- /dev/null
>> +++ b/drivers/soc/amlogic/meson-sm1-pwrc.c
>> @@ -0,0 +1,245 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (c) 2017 BayLibre, SAS
>> + * Author: Neil Armstrong <narmstrong@baylibre.com>
>> + */
>> +
>> +#include <linux/of_address.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pm_domain.h>
>> +#include <linux/bitfield.h>
>> +#include <linux/regmap.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/of_device.h>
>> +#include <dt-bindings/power/meson-sm1-power.h>
>> +
>> +/* AO Offsets */
>> +
>> +#define AO_RTI_GEN_PWR_SLEEP0 (0x3a << 2)
>> +#define AO_RTI_GEN_PWR_ISO0 (0x3b << 2)
>> +
>> +/* HHI Offsets */
>> +
>> +#define HHI_MEM_PD_REG0 (0x40 << 2)
>> +#define HHI_NANOQ_MEM_PD_REG0 (0x46 << 2)
>> +#define HHI_NANOQ_MEM_PD_REG1 (0x47 << 2)
>> +
>> +struct meson_sm1_pwrc;
>> +
>> +struct meson_sm1_pwrc_mem_domain {
>> + unsigned int reg;
>> + unsigned int mask;
>> +};
>> +
>> +struct meson_sm1_pwrc_domain_desc {
>> + char *name;
>> + unsigned int sleep_reg;
>> + unsigned int sleep_bit;
>> + unsigned int iso_reg;
>> + unsigned int iso_bit;
>> + unsigned int mem_pd_count;
>> + struct meson_sm1_pwrc_mem_domain *mem_pd;
>> +};
>
> If you add resets and clocks (using clk bulk like my other proposed
> patch to gx-pwrc-vpu) then this could be used for VPU also. We could
> ignore my clk bulk patch and then just deprecate the old driver and use
> this one for everything.
>
> We would just need SoC-specific tables selected by compatible-string to
> select the memory pds, and the clocks and resets could (optionaly) come
> from the DT.
Could you elaborate ?
Do you mean I should slit out the memory PDs as different compatible ?
Let me try to fit the VPU stuff in it.
Neil
>
> Kevin
>
_______________________________________________
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