* [PATCH 0/3] soc: renesas: ARM errata updates
From: Geert Uytterhoeven @ 2019-08-21 12:45 UTC (permalink / raw)
To: Simon Horman, Magnus Damm
Cc: linux-renesas-soc, Geert Uytterhoeven, linux-arm-kernel
Hi all,
This patch series updates the handling of ARM errata for affected
Renesas SoCs.
The first patch enables the new ARM_ERRATA_814220 for Cortex-A7, using
Kconfig logic.
The second patch moves enablement of ARM_ERRATA_754322 for Cortex-A9
from shmobile_defconfig to Kconfig logic, to make sure it's always
enabled when needed.
The third patch disables PL310_ERRATA_588369, as it doesn't affect any
Renesas SoCs.
The last patch is marked RFC, as I don't know the revision of PL310 on
EMMA Mobile EV2, and cannot test it on EMEV2.
Thanks for your comments!
Geert Uytterhoeven (3):
soc: renesas: Enable ARM_ERRATA_814220 for affected Cortex-A7
soc: renesas: Enable ARM_ERRATA_754322 for affected Cortex-A9
[RFC] ARM: shmobile: defconfig: Disable PL310_ERRATA_588369
arch/arm/configs/shmobile_defconfig | 2 --
drivers/soc/renesas/Kconfig | 11 +++++++++++
2 files changed, 11 insertions(+), 2 deletions(-)
--
2.17.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] soc: renesas: Enable ARM_ERRATA_814220 for affected Cortex-A7
From: Geert Uytterhoeven @ 2019-08-21 12:46 UTC (permalink / raw)
To: Simon Horman, Magnus Damm
Cc: linux-renesas-soc, Geert Uytterhoeven, linux-arm-kernel
In-Reply-To: <20190821124602.29317-1-geert+renesas@glider.be>
ARM Erratum 814220 affects Cortex-A7 revisions r0p2-r0p5.
Enable automatically support to mitigate the erratum when compiling a
kernel for any of the affected Renesas SoCs:
- R-Mobile APE6: r0p2,
- RZ/G1E: r0p5,
- RZ/G1C: r0p5,
- R-Car H2: r0p3,
- R-Car E2: r0p5,
- RZ/N1: r0p5.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/soc/renesas/Kconfig | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index 2bbf49e5d441808b..a72d014ea37cc788 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -72,6 +72,7 @@ config ARCH_R8A73A4
bool "R-Mobile APE6 (R8A73A40)"
select ARCH_RMOBILE
select ARM_ERRATA_798181 if SMP
+ select ARM_ERRATA_814220
select HAVE_ARM_ARCH_TIMER
select RENESAS_IRQC
@@ -95,11 +96,13 @@ config ARCH_R8A7744
config ARCH_R8A7745
bool "RZ/G1E (R8A77450)"
select ARCH_RCAR_GEN2
+ select ARM_ERRATA_814220
select SYSC_R8A7745
config ARCH_R8A77470
bool "RZ/G1C (R8A77470)"
select ARCH_RCAR_GEN2
+ select ARM_ERRATA_814220
select SYSC_R8A77470
config ARCH_R8A7778
@@ -117,6 +120,7 @@ config ARCH_R8A7790
bool "R-Car H2 (R8A77900)"
select ARCH_RCAR_GEN2
select ARM_ERRATA_798181 if SMP
+ select ARM_ERRATA_814220
select I2C
select SYSC_R8A7790
@@ -143,11 +147,13 @@ config ARCH_R8A7793
config ARCH_R8A7794
bool "R-Car E2 (R8A77940)"
select ARCH_RCAR_GEN2
+ select ARM_ERRATA_814220
select SYSC_R8A7794
config ARCH_R9A06G032
bool "RZ/N1D (R9A06G032)"
select ARCH_RZN1
+ select ARM_ERRATA_814220
config ARCH_SH73A0
bool "SH-Mobile AG5 (R8A73A00)"
--
2.17.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 2/3] soc: renesas: Enable ARM_ERRATA_754322 for affected Cortex-A9
From: Geert Uytterhoeven @ 2019-08-21 12:46 UTC (permalink / raw)
To: Simon Horman, Magnus Damm
Cc: linux-renesas-soc, Geert Uytterhoeven, linux-arm-kernel
In-Reply-To: <20190821124602.29317-1-geert+renesas@glider.be>
ARM Erratum 754322 affects Cortex-A9 revisions r2p* and r3p*.
Enable support code to mitigate the erratum when compiling a kernel for
any of the affected Renesas SoCs:
- RZ/A1: r3p0,
- R-Mobile A1: r2p4,
- R-Car M1A: r2p2-00rel0,
- R-Car H1: r3p0,
- SH-Mobile AG5: r2p2,
and drop the corresponding config symbol from shmobile_defconfig.
EMMA Mobile EV2 (r1p3) and RZ/A2 (r4p1) are not affected.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Looks like my R-Mobile A1 is actually r2p3, and the R-Car M1A in Magnus'
farm is r2p4?
arch/arm/configs/shmobile_defconfig | 1 -
drivers/soc/renesas/Kconfig | 5 +++++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index c6c70355141c38fa..123821e63873dafa 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -9,7 +9,6 @@ CONFIG_PERF_EVENTS=y
CONFIG_SLAB=y
CONFIG_ARCH_RENESAS=y
CONFIG_PL310_ERRATA_588369=y
-CONFIG_ARM_ERRATA_754322=y
CONFIG_SMP=y
CONFIG_SCHED_MC=y
CONFIG_NR_CPUS=8
diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index a72d014ea37cc788..3c5e017bacbaca11 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -55,6 +55,7 @@ config ARCH_EMEV2
config ARCH_R7S72100
bool "RZ/A1H (R7S72100)"
+ select ARM_ERRATA_754322
select PM
select PM_GENERIC_DOMAINS
select RENESAS_OSTM
@@ -79,6 +80,7 @@ config ARCH_R8A73A4
config ARCH_R8A7740
bool "R-Mobile A1 (R8A77400)"
select ARCH_RMOBILE
+ select ARM_ERRATA_754322
select RENESAS_INTC_IRQPIN
config ARCH_R8A7743
@@ -108,10 +110,12 @@ config ARCH_R8A77470
config ARCH_R8A7778
bool "R-Car M1A (R8A77781)"
select ARCH_RCAR_GEN1
+ select ARM_ERRATA_754322
config ARCH_R8A7779
bool "R-Car H1 (R8A77790)"
select ARCH_RCAR_GEN1
+ select ARM_ERRATA_754322
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
select SYSC_R8A7779
@@ -158,6 +162,7 @@ config ARCH_R9A06G032
config ARCH_SH73A0
bool "SH-Mobile AG5 (R8A73A00)"
select ARCH_RMOBILE
+ select ARM_ERRATA_754322
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
select RENESAS_INTC_IRQPIN
--
2.17.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/3] [RFC] ARM: shmobile: defconfig: Disable PL310_ERRATA_588369
From: Geert Uytterhoeven @ 2019-08-21 12:46 UTC (permalink / raw)
To: Simon Horman, Magnus Damm
Cc: linux-renesas-soc, Geert Uytterhoeven, linux-arm-kernel
In-Reply-To: <20190821124602.29317-1-geert+renesas@glider.be>
PL310 Erratum 588369 affects PL310 cache controller revisions older than
r2p0.
As Renesas ARM SoCs contain the following revisions:
- SH-Mobile AG5: r3p1,
- R-Mobile A1: r3p1-50rel0,
- R-Car H1: r3p2,
- RZ/A1: r3p2,
- RZ/A2: r3p3,
none of them are affected, and support for the errata can be disabled
safely.
The EMMA Mobile EV2 documentation doesn't mention the revision of its
PL310 cache controller, so this SoC might be affected. However, the L2
cache controller is not enabled by Linux.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/configs/shmobile_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 123821e63873dafa..95a127cbe8e6fcd7 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -8,7 +8,6 @@ CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_PERF_EVENTS=y
CONFIG_SLAB=y
CONFIG_ARCH_RENESAS=y
-CONFIG_PL310_ERRATA_588369=y
CONFIG_SMP=y
CONFIG_SCHED_MC=y
CONFIG_NR_CPUS=8
--
2.17.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 v4 07/21] ARM: dts: imx7-colibri: fix 1.8V/UHS support
From: Philippe Schenker @ 2019-08-21 12:49 UTC (permalink / raw)
To: shawnguo@kernel.org
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
michal.vokac@ysoft.com, Max Krummenacher, Stefan Agner,
Marcel Ziswiler, s.hauer@pengutronix.de,
linux-kernel@vger.kernel.org, stefan@agner.ch, robh+dt@kernel.org,
linux-imx@nxp.com, kernel@pengutronix.de, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819111847.GQ5999@X250>
On Mon, 2019-08-19 at 13:18 +0200, Shawn Guo wrote:
> On Mon, Aug 12, 2019 at 02:21:25PM +0000, Philippe Schenker wrote:
> > From: Stefan Agner <stefan.agner@toradex.com>
> >
> > Add pinmuxing and do not specify voltage restrictions for the usdhc
> > instance available on the modules edge connector. This allows to use
> > SD-cards with higher transfer modes if supported by the carrier
> > board.
> >
> > Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
> > Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> > Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> >
> > ---
> >
> > Changes in v4:
> > - Add Marcel Ziswiler's Ack
> >
> > Changes in v3:
> > - Add new commit message from Stefan's proposal on ML
> >
> > Changes in v2: None
> >
> > arch/arm/boot/dts/imx7-colibri.dtsi | 23 ++++++++++++++++++++++-
> > 1 file changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi
> > b/arch/arm/boot/dts/imx7-colibri.dtsi
> > index 5347ed38acb2..c563bb821b5e 100644
> > --- a/arch/arm/boot/dts/imx7-colibri.dtsi
> > +++ b/arch/arm/boot/dts/imx7-colibri.dtsi
> > @@ -326,7 +326,6 @@
> > &usdhc1 {
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_usdhc1 &pinctrl_cd_usdhc1>;
> > - no-1-8-v;
> > cd-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
> > disable-wp;
> > vqmmc-supply = <®_LDO2>;
> > @@ -671,6 +670,28 @@
> > >;
> > };
> >
> > + pinctrl_usdhc1_100mhz: usdhc1grp_100mhz {
> > + fsl,pins = <
> > + MX7D_PAD_SD1_CMD__SD1_CMD 0x5a
> > + MX7D_PAD_SD1_CLK__SD1_CLK 0x1a
> > + MX7D_PAD_SD1_DATA0__SD1_DATA0 0x5a
> > + MX7D_PAD_SD1_DATA1__SD1_DATA1 0x5a
> > + MX7D_PAD_SD1_DATA2__SD1_DATA2 0x5a
> > + MX7D_PAD_SD1_DATA3__SD1_DATA3 0x5a
> > + >;
> > + };
> > +
> > + pinctrl_usdhc1_200mhz: usdhc1grp_200mhz {
>
> No reference to them from usdhc1 node?
>
> Shawn
No. I'd like to have that pinmuxing prepared for someone to add UHS
support to SD. Primary functionality of that pins is something else so
this will have priority.
Philippe
>
> > + fsl,pins = <
> > + MX7D_PAD_SD1_CMD__SD1_CMD 0x5b
> > + MX7D_PAD_SD1_CLK__SD1_CLK 0x1b
> > + MX7D_PAD_SD1_DATA0__SD1_DATA0 0x5b
> > + MX7D_PAD_SD1_DATA1__SD1_DATA1 0x5b
> > + MX7D_PAD_SD1_DATA2__SD1_DATA2 0x5b
> > + MX7D_PAD_SD1_DATA3__SD1_DATA3 0x5b
> > + >;
> > + };
> > +
> > pinctrl_usdhc3: usdhc3grp {
> > fsl,pins = <
> > MX7D_PAD_SD3_CMD__SD3_CMD 0x59
> > --
> > 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
* Re: [PATCH v4 08/21] ARM: dts: imx7-colibri: Add touch controllers
From: Philippe Schenker @ 2019-08-21 12:51 UTC (permalink / raw)
To: shawnguo@kernel.org
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
michal.vokac@ysoft.com, Max Krummenacher, Marcel Ziswiler,
s.hauer@pengutronix.de, linux-kernel@vger.kernel.org,
stefan@agner.ch, robh+dt@kernel.org, linux-imx@nxp.com,
kernel@pengutronix.de, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819112124.GR5999@X250>
On Mon, 2019-08-19 at 13:21 +0200, Shawn Guo wrote:
> On Mon, Aug 12, 2019 at 02:21:26PM +0000, Philippe Schenker wrote:
> > Add touch controller that is connected over an I2C bus.
> >
> > Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> > Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> >
> > ---
> >
> > Changes in v4:
> > - Add Marcel Ziswiler's Ack
> >
> > Changes in v3:
> > - Fix commit message
> >
> > Changes in v2:
> > - Deleted touchrevolution downstream stuff
> > - Use generic node name
> > - Better comment
> >
> > arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 24
> > +++++++++++++++++++++
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> > b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> > index d4dbc4fc1adf..576dec9ff81c 100644
> > --- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> > +++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
> > @@ -145,6 +145,21 @@
> > &i2c4 {
> > status = "okay";
> >
> > + /*
> > + * Touchscreen is using SODIMM 28/30, also used for PWM<B>,
> > PWM<C>,
> > + * aka pwm2, pwm3. so if you enable touchscreen, disable the
> > pwms
> > + */
> > + touchscreen@4a {
> > + compatible = "atmel,maxtouch";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_gpiotouch>;
> > + reg = <0x4a>;
> > + interrupt-parent = <&gpio1>;
> > + interrupts = <9 IRQ_TYPE_EDGE_FALLING>; /*
> > SODIMM 28 */
> > + reset-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>; /* SODIMM 30
> > */
> > + status = "disabled";
>
> Why disabled?
>
> Shawn
Also here, this is meant as an example to get our touchscreen faster
running. But those pins are primarily used as PWM's and they should by
default muxed for PWM's.
If a customer want's to add that touchscreen he just have to switch the
status of this and PWM...
Philippe
>
> > + };
> > +
> > /* M41T0M6 real time clock on carrier board */
> > rtc: m41t0m6@68 {
> > compatible = "st,m41t0";
> > @@ -200,3 +215,12 @@
> > vmmc-supply = <®_3v3>;
> > status = "okay";
> > };
> > +
> > +&iomuxc {
> > + pinctrl_gpiotouch: touchgpios {
> > + fsl,pins = <
> > + MX7D_PAD_GPIO1_IO09__GPIO1_IO9 0x74
> > + MX7D_PAD_GPIO1_IO10__GPIO1_IO10 0x14
> > + >;
> > + };
> > +};
> > --
> > 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
* Re: [PATCH 3/4] iommu/io-pgtable-arm: Rationalise TCR handling
From: Robin Murphy @ 2019-08-21 12:56 UTC (permalink / raw)
To: Will Deacon; +Cc: robdclark, joro, jcrouse, iommu, linux-arm-kernel
In-Reply-To: <20190821121120.34wqo7vj56pqk57c@willie-the-truck>
On 21/08/2019 13:11, Will Deacon wrote:
> On Tue, Aug 20, 2019 at 07:41:52PM +0100, Robin Murphy wrote:
>> On 20/08/2019 17:07, Will Deacon wrote:
>>> On Tue, Aug 20, 2019 at 04:25:56PM +0100, Robin Murphy wrote:
>>>> On 20/08/2019 11:31, Will Deacon wrote:
>>>>> On Mon, Aug 19, 2019 at 07:19:30PM +0100, Robin Murphy wrote:
>>>>>> Although it's conceptually nice for the io_pgtable_cfg to provide a
>>>>>> standard VMSA TCR value, the reality is that no VMSA-compliant IOMMU
>>>>>> looks exactly like an Arm CPU, and they all have various other TCR
>>>>>> controls which io-pgtable can't be expected to understand. Thus since
>>>>>> there is an expectation that drivers will have to add to the given TCR
>>>>>> value anyway, let's strip it down to just the essentials that are
>>>>>> directly relevant to io-pgatble's inner workings - namely the address
>>>>>> sizes, walk attributes, and where appropriate, format selection.
>>>>>>
>>>>>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>>>>>> ---
>>>>>> drivers/iommu/arm-smmu-v3.c | 7 +------
>>>>>> drivers/iommu/arm-smmu.c | 1 +
>>>>>> drivers/iommu/arm-smmu.h | 2 ++
>>>>>> drivers/iommu/io-pgtable-arm-v7s.c | 6 ++----
>>>>>> drivers/iommu/io-pgtable-arm.c | 4 ----
>>>>>> drivers/iommu/qcom_iommu.c | 2 +-
>>>>>> 6 files changed, 7 insertions(+), 15 deletions(-)
>>>>>
>>>>> Hmm, so I'm a bit nervous about this one since I think we really should
>>>>> be providing a TCR with EPD1 set if we're only giving you TTBR0. Relying
>>>>> on the driver to do this worries me. See my comments on the next patch.
>>>>
>>>> The whole idea is that we already know we can't provide a *complete* TCR
>>>> value (not least because anything above bit 31 is the wild west), thus
>>>> there's really no point in io-pgtable trying to provide anything other than
>>>> the parts it definitely controls. It makes sense to provide this partial TCR
>>>> value "as if" for TTBR0, since that's the most common case, but ultimately
>>>> io-pgatble doesn't know (or need to) which TTBR the caller intends to
>>>> actually use for this table. Even if the caller *is* allocating it for
>>>> TTBR0, io-pgtable doesn't know that they haven't got something live in TTBR1
>>>> already, so it still wouldn't be in a position to make the EPD1 call either
>>>> way.
>>>
>>> Ok, but the driver can happily rewrite/ignore what it gets back. I suppose
>>> an alternative would be scrapped the 'u64 tcr' and instead having a bunch
>>> of named bitfields for the stuff we're actually providing, although I'd
>>> still like EPDx to be in there.
>>
>> I like the bitfield idea; it would certainly emphasise the "you have to do
>> something more with this" angle that I'm pushing towards here, but still
>> leave things framed in TCR terms without having to go to some more general
>> abstraction. It really doesn't play into your EPD argument though - such a
>> config would be providing TxSZ/TGx/IRGNx/ORGNx/SHx, but EPDy, for y = !x.
>> For a driver to understand that and do the right thing with it is even more
>> involved than for the driver to just set EPD1 by itself anyway.
>
> Having considered the bitfield idea some more, I'm less attached to EPDx
> because we simply wouldn't be making a statement about them, rather than a
> (dangerous) zero value and expecting it to be ignored. So I think we're in
> agreement on that.
Cool, I'll give bitfields a go for v2.
> The only part I'm still stuck to is that I think io-pgtable should know
> whether it's targetting TTBR0 or TTBR1 so that it can sanitise input
> addresses correctly. Doing this in the driver code is possible, but I'd
> rather not start from that position, particularly as it would require things
> like sign-extension in the TLBI callbacks.
Good point, and thanks for the prod that the way I end up propagating
masked-off IOVAs through to the TLBI calls here is busted either way.
I'm OK with introducing an explicit TTBR1 quirk to begin with, as it
should make things a little easier to reason about, and we can always
revisit later if and when we do find a need for more flexibility.
>> If only LPAE had created these bits as enables rather than disables then
>> things would be logical and we could all be happy, but here we are...
>
> I'm happy! :D:D:D
Yeah, but I refuse to believe it's ever because of pagetables ;)
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 v3 1/2] PM / devfreq: Add dev_pm_qos support
From: Leonard Crestez @ 2019-08-21 13:00 UTC (permalink / raw)
To: Chanwoo Choi, MyungJoo Ham, Kyungmin Park
Cc: Artur Świgoń, Jacky Bai, Saravana Kannan,
linux-pm@vger.kernel.org, Viresh Kumar, Krzysztof Kozlowski,
Alexandre Bailon, cpgs (cpgs@samsung.com), Georgi Djakov,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <6134bb9e-9a16-b432-c191-c91f93844319@samsung.com>
On 21.08.2019 04:40, Chanwoo Choi wrote:
> On 19. 8. 21. 오전 12:24, Leonard Crestez wrote:
>> Add dev_pm_qos notifies to devfreq core in order to support frequency
>> limits via the dev_pm_qos_add_request.
>>
>> +static unsigned long get_effective_min_freq(struct devfreq *devfreq)
>
> I'm not sure that 'effective' expression is correct.
> From this function, the devfreq can get the final target frequency.
>
> I think that we need to use the more correct expression
> to give the meaning of function as following:
>
> get_min_freq
> get_max_freq
OK, will rename to get_min_freq and get_max_freq
>> @@ -636,21 +688,40 @@ struct devfreq *devfreq_add_device(struct device *dev,
>> err = -ENOMEM;
>> goto err_out;
>> }
>>
>> mutex_init(&devfreq->lock);
>> - mutex_lock(&devfreq->lock);
>
> Basically, I think that it is safe to lock when touch
> the variable of the devfreq.
>
> it is not proper way for the dev_pm_qos because
> it breaks the existing locking reason of devfreq's variables.
I don't understand what you mean. I'm initializing some stuff outside
the lock to avoid circular lock warning between:
(&devfreq->lock){+.+.}, at: devfreq_qos_min_notifier_call+0x24/0x48
(&(n)->rwsem){++++}, at: blocking_notifier_call_chain+0x3c/0x78
In general you don't need to lock an object while initializing except
after it becomes accessible from the outside so devfreq_add_device
doesn't need to take the lock so early.
The QOS notifiers are registered on the parent device so in theory it's
possible for somebody to add QOS requests while devfreq_add_device is
executing. Maybe notifier registration should be moved at the end after
unlock?
--
Regards,
Leonard
_______________________________________________
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 v3 2/2] PM / devfreq: Use dev_pm_qos for sysfs min/max_freq
From: Leonard Crestez @ 2019-08-21 13:03 UTC (permalink / raw)
To: Chanwoo Choi, MyungJoo Ham, Kyungmin Park
Cc: Artur Świgoń, Jacky Bai, Saravana Kannan,
linux-pm@vger.kernel.org, Viresh Kumar, Krzysztof Kozlowski,
Alexandre Bailon, cpgs (cpgs@samsung.com), Georgi Djakov,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <e2ba9b0d-1930-0d2a-c262-72f0f85c86d0@samsung.com>
On 21.08.2019 05:02, Chanwoo Choi wrote:
> On 19. 8. 21. 오전 12:24, Leonard Crestez wrote:
>> Now that devfreq supports dev_pm_qos requests we can use them to handle
>> the min/max_freq values set by userspace in sysfs, similar to cpufreq.
>>
>> Since dev_pm_qos handles frequencies as kHz this change reduces the
>> precision of min_freq and max_freq. This shouldn't introduce problems
>> because frequencies which are not an integer number of kHz are likely
>> not an integer number of Hz either.
>>
>> Try to ensure compatibilitity by rounding min values down and rounding
>> max values up.
>>
>> Simplify the {min,max}_freq_store code by setting "null" values of 0 and
>> MAX_S32 respectively instead of clamping to what freq tables are
>> actually supported. Values are already automatically clamped on
>> readback.
>>
>> Also simplify by droping the limitation that userspace min_freq must be
>> lower than userspace max_freq, it is already documented that max_freq
>> takes precedence.
>>
>> @@ -1358,33 +1371,20 @@ static ssize_t min_freq_store(struct device *dev, struct device_attribute *attr,
>>
>> ret = sscanf(buf, "%lu", &value);
>> if (ret != 1)
>> return -EINVAL;
>>
>> - mutex_lock(&df->lock);
>> -
>> - if (value) {
>> - if (value > df->max_freq) {
>> - ret = -EINVAL;
>> - goto unlock;
>> - }
>
> Actually, the user can input the value they want.
> So, the above code is not necessary because the devfreq->scaling_max_freq
> is never overflow from supported maximum frequency. The devfreq->scaling_max_freq
> is based on OPP entries from DT.
>
> But, if we replace the existing request way of devfreq-cooling.c
> with dev_pm_qos, devfreq->scaling_max_freq doesn't guarantee
> the supported maximum frequency. >
> We need to keep the supported min_freq/max_freq value without dev_pm_qos
> requirement because the dev_pm_qos requirement might have the overflow value.
> the dev_pm_qos doesn't know the supported minimum and maximum frequency
> of devfreq device.
I'm not sure I understand what you mean. My patch allows user to set
entirely arbitrary min/max rates and this is good because we already
have a well-defined way to handle this: max overrides min.
The scaling_min_freq and scaling_max_freq variables can just be kept
around indefinitely no matter what happens to thermal. They're just a
cache for dev_pm_opp_find_freq_ceil and dev_pm_opp_find_freq_floor.
BTW: I noticed that scaling_min_freq and scaling_max_freq are updated in
devfreq_notifier_call but devfreq->nb is not registered by default, only
when a driver requests it explicitly. Is there a reason for this?
Because I'd call dev_pm_opp_register_notifier inside devfreq_add_device
and remove all the devfreq_register/unregister_notifier APIs.
--
Regards,
Leonard
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 0/4] ASoC: sun4i-i2s: Number of fixes and TDM Support
From: Maxime Ripard @ 2019-08-21 13:06 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, lgirdwood, broonie
Cc: codekipper, alsa-devel, linux-kernel, linux-arm-kernel
From: Maxime Ripard <maxime.ripard@bootlin.com>
Hi,
This series aims at fixing a number of issues in the current i2s driver,
mostly related to the i2s master support and the A83t support. It also uses
that occasion to cleanup a few things and simplify the driver. Finally, it
builds on those fixes and cleanups to introduce TDM and DSP formats support.
Let me know what you think,
Maxime
Changes from v1:
- Removed patches applied
- Refactor a bit the call to sun4i_i2s_set_clk_rate
- Fix build issue
- Add an extra patch to cleanup sun4i_i2s_hw_params
Maxime Ripard (4):
ASoC: sun4i-i2s: Use the physical / slot width for the clocks
ASoC: sun4i-i2s: Use the actual format width instead of an hardcoded one
ASoC: sun4i-i2s: Replace call to params_width by local variable
ASoC: sun4i-i2s: Add support for DSP formats
sound/soc/sunxi/sun4i-i2s.c | 58 ++++++++++++++++++++++++++++----------
1 file changed, 43 insertions(+), 15 deletions(-)
base-commit: 137befe19f310400a8b20fd8a4ce8c4141aafde0
--
git-series 0.9.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 v2 1/4] ASoC: sun4i-i2s: Use the physical / slot width for the clocks
From: Maxime Ripard @ 2019-08-21 13:06 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, lgirdwood, broonie
Cc: codekipper, alsa-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <cover.6022d5fe61fb8a11565a71bee24d5280b0259c63.1566392800.git-series.maxime.ripard@bootlin.com>
From: Maxime Ripard <maxime.ripard@bootlin.com>
The clock dividers function has been using the word size to compute the
clock rate at which it's supposed to be running, but the proper formula
would be to use the physical width and / or slot width in TDM.
It doesn't make any difference at the moment since all the formats
supported have the same sample width and physical width, but it's not going
to last forever.
Fixes: 7d2993811a1e ("ASoC: sun4i-i2s: Add support for H3")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
sound/soc/sunxi/sun4i-i2s.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 8326b8cfa569..cdc3fa60ff33 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -290,7 +290,7 @@ static bool sun4i_i2s_oversample_is_valid(unsigned int oversample)
static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
unsigned int rate,
unsigned int slots,
- unsigned int word_size)
+ unsigned int slot_width)
{
struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
unsigned int oversample_rate, clk_rate, bclk_parent_rate;
@@ -337,7 +337,7 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
bclk_parent_rate = i2s->variant->get_bclk_parent_rate(i2s);
bclk_div = sun4i_i2s_get_bclk_div(i2s, bclk_parent_rate,
- rate, slots, word_size);
+ rate, slots, slot_width);
if (bclk_div < 0) {
dev_err(dai->dev, "Unsupported BCLK divider: %d\n", bclk_div);
return -EINVAL;
@@ -458,6 +458,7 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream,
{
struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
unsigned int word_size = params_width(params);
+ unsigned int slot_width = params_physical_width(params);
unsigned int channels = params_channels(params);
unsigned int slots = channels;
int ret, sr, wss;
@@ -467,7 +468,7 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream,
slots = i2s->slots;
if (i2s->slot_width)
- word_size = i2s->slot_width;
+ slot_width = i2s->slot_width;
ret = i2s->variant->set_chan_cfg(i2s, params);
if (ret < 0) {
@@ -490,14 +491,15 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream,
if (sr < 0)
return -EINVAL;
- wss = i2s->variant->get_wss(i2s, word_size);
+ wss = i2s->variant->get_wss(i2s, slot_width);
if (wss < 0)
return -EINVAL;
regmap_field_write(i2s->field_fmt_wss, wss);
regmap_field_write(i2s->field_fmt_sr, sr);
- return sun4i_i2s_set_clk_rate(dai, params_rate(params), slots, word_size);
+ return sun4i_i2s_set_clk_rate(dai, params_rate(params),
+ slots, slot_width);
}
static int sun4i_i2s_set_soc_fmt(const struct sun4i_i2s *i2s,
--
git-series 0.9.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 v2 2/4] ASoC: sun4i-i2s: Use the actual format width instead of an hardcoded one
From: Maxime Ripard @ 2019-08-21 13:06 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, lgirdwood, broonie
Cc: codekipper, alsa-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <cover.6022d5fe61fb8a11565a71bee24d5280b0259c63.1566392800.git-series.maxime.ripard@bootlin.com>
From: Maxime Ripard <maxime.ripard@bootlin.com>
The LRCK period field in the FMT0 register holds the number of LRCK period
for one channel in I2S mode.
This has been hardcoded to 32, while it really should be the physical width
of the format, which creates an improper clock when using a 16bit format,
with the i2s controller as LRCK master.
Fixes: 7d2993811a1e ("ASoC: sun4i-i2s: Add support for H3")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
sound/soc/sunxi/sun4i-i2s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index cdc3fa60ff33..9ef784b8867c 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -359,7 +359,7 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
if (i2s->variant->has_fmt_set_lrck_period)
regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG,
SUN8I_I2S_FMT0_LRCK_PERIOD_MASK,
- SUN8I_I2S_FMT0_LRCK_PERIOD(32));
+ SUN8I_I2S_FMT0_LRCK_PERIOD(slot_width));
return 0;
}
--
git-series 0.9.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 v2 3/4] ASoC: sun4i-i2s: Replace call to params_width by local variable
From: Maxime Ripard @ 2019-08-21 13:06 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, lgirdwood, broonie
Cc: codekipper, alsa-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <cover.6022d5fe61fb8a11565a71bee24d5280b0259c63.1566392800.git-series.maxime.ripard@bootlin.com>
From: Maxime Ripard <maxime.ripard@bootlin.com>
The sun4i_i2s_hw_params function already has a variable holding the value
returned by params_width, so let's just use that variable instead of
calling params_width multiple times.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
sound/soc/sunxi/sun4i-i2s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 9ef784b8867c..69162af9fd65 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -487,7 +487,7 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream,
}
i2s->playback_dma_data.addr_width = width;
- sr = i2s->variant->get_sr(i2s, params_width(params));
+ sr = i2s->variant->get_sr(i2s, word_size);
if (sr < 0)
return -EINVAL;
--
git-series 0.9.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 v2 4/4] ASoC: sun4i-i2s: Add support for DSP formats
From: Maxime Ripard @ 2019-08-21 13:06 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard, lgirdwood, broonie
Cc: codekipper, alsa-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <cover.6022d5fe61fb8a11565a71bee24d5280b0259c63.1566392800.git-series.maxime.ripard@bootlin.com>
From: Maxime Ripard <maxime.ripard@bootlin.com>
In addition to the I2S format, the controller also supports the DSP_*
formats.
This requires some extra care on the LRCK period calculation, since the
controller, with the PCM formats, require that the value set is no longer
the periods of LRCK for a single channel, but for all of them.
Let's add the code to deal with this, and support the DSP_A and DSP_B
formats.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
sound/soc/sunxi/sun4i-i2s.c | 44 ++++++++++++++++++++++++++++++--------
1 file changed, 35 insertions(+), 9 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 69162af9fd65..57bf2a33753e 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -130,7 +130,6 @@ struct sun4i_i2s;
* struct sun4i_i2s_quirks - Differences between SoC variants.
*
* @has_reset: SoC needs reset deasserted.
- * @has_fmt_set_lrck_period: SoC requires lrclk period to be set.
* @reg_offset_txdata: offset of the tx fifo.
* @sun4i_i2s_regmap: regmap config to use.
* @field_clkdiv_mclk_en: regmap field to enable mclk output.
@@ -139,7 +138,6 @@ struct sun4i_i2s;
*/
struct sun4i_i2s_quirks {
bool has_reset;
- bool has_fmt_set_lrck_period;
unsigned int reg_offset_txdata; /* TX FIFO */
const struct regmap_config *sun4i_i2s_regmap;
@@ -167,6 +165,7 @@ struct sun4i_i2s {
struct regmap *regmap;
struct reset_control *rst;
+ unsigned int format;
unsigned int mclk_freq;
unsigned int slots;
unsigned int slot_width;
@@ -355,12 +354,6 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
regmap_field_write(i2s->field_clkdiv_mclk_en, 1);
- /* Set sync period */
- if (i2s->variant->has_fmt_set_lrck_period)
- regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG,
- SUN8I_I2S_FMT0_LRCK_PERIOD_MASK,
- SUN8I_I2S_FMT0_LRCK_PERIOD(slot_width));
-
return 0;
}
@@ -422,6 +415,7 @@ static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s,
{
unsigned int channels = params_channels(params);
unsigned int slots = channels;
+ unsigned int lrck_period;
if (i2s->slots)
slots = i2s->slots;
@@ -445,6 +439,26 @@ static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s,
SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM_MASK,
SUN8I_I2S_CHAN_CFG_RX_SLOT_NUM(channels));
+ switch (i2s->format & SND_SOC_DAIFMT_FORMAT_MASK) {
+ case SND_SOC_DAIFMT_DSP_A:
+ case SND_SOC_DAIFMT_DSP_B:
+ case SND_SOC_DAIFMT_LEFT_J:
+ case SND_SOC_DAIFMT_RIGHT_J:
+ lrck_period = params_physical_width(params) * slots;
+ break;
+
+ case SND_SOC_DAIFMT_I2S:
+ lrck_period = params_physical_width(params);
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG,
+ SUN8I_I2S_FMT0_LRCK_PERIOD_MASK,
+ SUN8I_I2S_FMT0_LRCK_PERIOD(lrck_period));
+
regmap_update_bits(i2s->regmap, SUN8I_I2S_TX_CHAN_SEL_REG,
SUN8I_I2S_TX_CHAN_EN_MASK,
SUN8I_I2S_TX_CHAN_EN(channels));
@@ -616,6 +630,16 @@ static int sun8i_i2s_set_soc_fmt(const struct sun4i_i2s *i2s,
/* DAI Mode */
switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
+ case SND_SOC_DAIFMT_DSP_A:
+ mode = SUN8I_I2S_CTRL_MODE_PCM;
+ offset = 1;
+ break;
+
+ case SND_SOC_DAIFMT_DSP_B:
+ mode = SUN8I_I2S_CTRL_MODE_PCM;
+ offset = 0;
+ break;
+
case SND_SOC_DAIFMT_I2S:
mode = SUN8I_I2S_CTRL_MODE_LEFT;
offset = 1;
@@ -684,6 +708,9 @@ static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
SUN4I_I2S_FIFO_CTRL_RX_MODE_MASK,
SUN4I_I2S_FIFO_CTRL_TX_MODE(1) |
SUN4I_I2S_FIFO_CTRL_RX_MODE(1));
+
+ i2s->format = fmt;
+
return 0;
}
@@ -1074,7 +1101,6 @@ static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
.has_reset = true,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
.sun4i_i2s_regmap = &sun4i_i2s_regmap_config,
- .has_fmt_set_lrck_period = true,
.field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 8, 8),
.field_fmt_wss = REG_FIELD(SUN4I_I2S_FMT0_REG, 0, 2),
.field_fmt_sr = REG_FIELD(SUN4I_I2S_FMT0_REG, 4, 6),
--
git-series 0.9.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 v3 2/9] soc: samsung: Convert exynos-chipid driver to use the regmap API
From: Krzysztof Kozlowski @ 2019-08-21 13:10 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, linux-samsung-soc@vger.kernel.org, Arnd Bergmann,
Bartlomiej Zolnierkiewicz, Sylwester Nawrocki, vireshk, linux-pm,
linux-kernel@vger.kernel.org, Jon Hunter, robh+dt, kgene,
pankaj.dubey, linux-tegra, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <537999b7-b0e8-33a7-4bdc-c6952a0a5d06@samsung.com>
On Wed, 21 Aug 2019 at 14:41, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
>
> On 8/21/19 14:16, Krzysztof Kozlowski wrote:
> >>> I'm also inclined to have it converted to a regular driver. We already
> >>> have "exynos-asv" driver matching on the chipid node (patch 3/9).
> >>> The ASV patches will not be merged soon anyway, all this needs some more
> >>> thought. Krzysztof, can we abandon the chipid patches for now? Your
> >>
> >> chipid driver is good and useful on its own. The preferred solution
> >> IMHO would be to just revert "soc: samsung: Convert exynos-chipid
> >> driver to use the regmap API" commit.
> >
> > I queued the chipid as a dependency for ASV but ASV requires the
> > regmap. What would be left after reverting the regmap part? Simple
> > unused printk driver? No need for such. If reverting, then let's drop
> > entire driver and rework it offline.
>
> In fact there is now no dependency between the chipid and the ASV
> driver (patch 3/9), the regmap is provided by the syscon driver/API.
> I should have added "depends on REGMAP && MFD_SYSCON" to Kconfig.
> Both drivers (chipid, ASV) share the registers region so the regmap
> API seemed appropriate here.
Indeed, ASV needs only the header + DT change... Then actually we do
not need chipid driver at all. Just to print the SoC and provide sysfs
entry? If this is the only purpose, then it should be a driver.
> Converting the chipid code to platform driver wouldn't make sense as
> it wouldn't be useful early in arch/arm/mach-exynos and we can't have
> two drivers for same device (the ASV driver matches on the chipid
> compatible now).
There is no use case for arm/mach-exynos. This code was not
resubmitted and I doubt it will be (unless now someone wants to prove
I am wrong and sends it again :) ). The two-device case is indeed a
problem but it is possible. Clocks are doing it with PMU driver. See
CLK_OF_DECLARE_DRIVER(), although I do not remember whether it is
maybe obsolete pattern (discouraged).
Best regards,
Krzysztof
_______________________________________________
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 v4 11/21] ARM: dts: imx6qdl-apalis: Add sleep state to can interfaces
From: Philippe Schenker @ 2019-08-21 13:15 UTC (permalink / raw)
To: shawnguo@kernel.org
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
michal.vokac@ysoft.com, Max Krummenacher, Marcel Ziswiler,
s.hauer@pengutronix.de, linux-kernel@vger.kernel.org,
stefan@agner.ch, robh+dt@kernel.org, linux-imx@nxp.com,
kernel@pengutronix.de, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819112754.GU5999@X250>
On Mon, 2019-08-19 at 13:27 +0200, Shawn Guo wrote:
> On Mon, Aug 12, 2019 at 02:21:31PM +0000, Philippe Schenker wrote:
> > This patch prepares the devicetree for the new Ixora V1.2 where we
> > are
> > able to turn off the supply of the can transceiver. This implies to
> > use
> > a sleep state on transmission pins in order to prevent backfeeding.
> >
> > Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> > Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> >
> > ---
> >
> > Changes in v4:
> > - Add Marcel Ziswiler's Ack
> >
> > Changes in v3: None
> > Changes in v2:
> > - Changed commit title to '...imx6qdl-apalis:...'
> >
> > arch/arm/boot/dts/imx6qdl-apalis.dtsi | 27 +++++++++++++++++++++---
> > ---
> > 1 file changed, 21 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > index 7c4ad541c3f5..59ed2e4a1fd1 100644
> > --- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> > @@ -148,14 +148,16 @@
> > };
> >
> > &can1 {
> > - pinctrl-names = "default";
> > - pinctrl-0 = <&pinctrl_flexcan1>;
>
> This line doesn't need to be changed.
You're right, but by adding pinctrl_flexcan1_sleep here, I'd like to
emphasize between "default" and "sleep" and change that.
Since it's only used in this file I don't see any problems.
Philippe
>
> > + pinctrl-names = "default", "sleep";
> > + pinctrl-0 = <&pinctrl_flexcan1_default>;
> > + pinctrl-1 = <&pinctrl_flexcan1_sleep>;
> > status = "disabled";
> > };
> >
> > &can2 {
> > - pinctrl-names = "default";
> > - pinctrl-0 = <&pinctrl_flexcan2>;
> > + pinctrl-names = "default", "sleep";
> > + pinctrl-0 = <&pinctrl_flexcan2_default>;
> > + pinctrl-1 = <&pinctrl_flexcan2_sleep>;
> > status = "disabled";
> > };
> >
> > @@ -599,19 +601,32 @@
> > >;
> > };
> >
> > - pinctrl_flexcan1: flexcan1grp {
>
> Ditto. I take them as unnecessary changes.
>
> Shawn
>
> > + pinctrl_flexcan1_default: flexcan1defgrp {
> > fsl,pins = <
> > MX6QDL_PAD_GPIO_7__FLEXCAN1_TX 0x1b0b0
> > MX6QDL_PAD_GPIO_8__FLEXCAN1_RX 0x1b0b0
> > >;
> > };
> >
> > - pinctrl_flexcan2: flexcan2grp {
> > + pinctrl_flexcan1_sleep: flexcan1slpgrp {
> > + fsl,pins = <
> > + MX6QDL_PAD_GPIO_7__GPIO1_IO07 0x0
> > + MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x0
> > + >;
> > + };
> > +
> > + pinctrl_flexcan2_default: flexcan2defgrp {
> > fsl,pins = <
> > MX6QDL_PAD_KEY_COL4__FLEXCAN2_TX 0x1b0b0
> > MX6QDL_PAD_KEY_ROW4__FLEXCAN2_RX 0x1b0b0
> > >;
> > };
> > + pinctrl_flexcan2_sleep: flexcan2slpgrp {
> > + fsl,pins = <
> > + MX6QDL_PAD_KEY_COL4__GPIO4_IO14 0x0
> > + MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x0
> > + >;
> > + };
> >
> > pinctrl_gpio_bl_on: gpioblon {
> > fsl,pins = <
> > --
> > 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
* Re: [PATCH v4 1/2] ACPI/PPTT: Add support for ACPI 6.3 thread flag
From: Jeremy Linton @ 2019-08-21 13:20 UTC (permalink / raw)
To: John Garry, Will Deacon, Rafael J. Wysocki
Cc: lorenzo.pieralisi@arm.com, rric@kernel.org,
catalin.marinas@arm.com, rjw@rjwysocki.net,
linux-acpi@vger.kernel.org, Robert Richter, wanghuiqiang,
sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org,
lenb@kernel.org
In-Reply-To: <a2960c68-d422-3cdb-4354-6f357433ad6c@huawei.com>
Hi,
On 8/20/19 4:01 AM, John Garry wrote:
> On 12/08/2019 12:59, Will Deacon wrote:
>> On Mon, Aug 12, 2019 at 11:06:07AM +0200, Rafael J. Wysocki wrote:
>>> On Fri, Aug 9, 2019 at 12:25 AM Robert Richter <rrichter@marvell.com>
>>> wrote:
>>>>
>>>> On 08.08.19 15:40:06, Jeremy Linton wrote:
>>>>> ACPI 6.3 adds a flag to the CPU node to indicate whether
>>>>> the given PE is a thread. Add a function to return that
>>>>> information for a given linux logical CPU.
>>>>>
>>>>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>>>>> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
>>>>> ---
>>>>> drivers/acpi/pptt.c | 53
>>>>> +++++++++++++++++++++++++++++++++++++++++++-
>>>>> include/linux/acpi.h | 5 +++++
>>>>> 2 files changed, 57 insertions(+), 1 deletion(-)
>>>>
>>>> Reviewed-by: Robert Richter <rrichter@marvell.com>
>>>
>>> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>
>>> and please push it through ARM64 along with the second patch.
>>
>> Thanks. I'll push these into -next shortly.
>
>
> Hi Jeremy,
>
> We're considering requesting this support is backported to stable. We
> have a platform which incorrectly sets the MT bit. To update our
> firmware to PPTT v2, we need the kernel to support PPTT v2 also.
>
> Please let me know if you anticipate an issue in this.
No I don't see any issues with that once it lands.
I believe the ball is rolling in the case of some older distro kernel's
as well.
Thanks,
_______________________________________________
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 v4 1/2] ACPI/PPTT: Add support for ACPI 6.3 thread flag
From: John Garry @ 2019-08-21 13:25 UTC (permalink / raw)
To: Jeremy Linton, Will Deacon, Rafael J. Wysocki
Cc: lorenzo.pieralisi@arm.com, rric@kernel.org,
catalin.marinas@arm.com, rjw@rjwysocki.net,
linux-acpi@vger.kernel.org, Robert Richter, wanghuiqiang,
sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org,
lenb@kernel.org
In-Reply-To: <72ee16ea-1038-37a1-25b1-f28b5c6b6edb@arm.com>
On 21/08/2019 14:20, Jeremy Linton wrote:
> Hi,
>
> On 8/20/19 4:01 AM, John Garry wrote:
>> On 12/08/2019 12:59, Will Deacon wrote:
>>> On Mon, Aug 12, 2019 at 11:06:07AM +0200, Rafael J. Wysocki wrote:
>>>> On Fri, Aug 9, 2019 at 12:25 AM Robert Richter
>>>> <rrichter@marvell.com> wrote:
>>>>>
>>>>> On 08.08.19 15:40:06, Jeremy Linton wrote:
>>>>>> ACPI 6.3 adds a flag to the CPU node to indicate whether
>>>>>> the given PE is a thread. Add a function to return that
>>>>>> information for a given linux logical CPU.
>>>>>>
>>>>>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>>>>>> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
>>>>>> ---
>>>>>> drivers/acpi/pptt.c | 53
>>>>>> +++++++++++++++++++++++++++++++++++++++++++-
>>>>>> include/linux/acpi.h | 5 +++++
>>>>>> 2 files changed, 57 insertions(+), 1 deletion(-)
>>>>>
>>>>> Reviewed-by: Robert Richter <rrichter@marvell.com>
>>>>
>>>> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>>
>>>> and please push it through ARM64 along with the second patch.
>>>
>>> Thanks. I'll push these into -next shortly.
>>
>>
>> Hi Jeremy,
>>
>> We're considering requesting this support is backported to stable. We
>> have a platform which incorrectly sets the MT bit. To update our
>> firmware to PPTT v2, we need the kernel to support PPTT v2 also.
>>
>> Please let me know if you anticipate an issue in this.
>
> No I don't see any issues with that once it lands.
>
> I believe the ball is rolling in the case of some older distro kernel's
> as well.
Cool.
Cheers,
John
>
> Thanks,
>
> .
>
_______________________________________________
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 v3 2/9] soc: samsung: Convert exynos-chipid driver to use the regmap API
From: Bartlomiej Zolnierkiewicz @ 2019-08-21 13:31 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, linux-samsung-soc@vger.kernel.org, Arnd Bergmann,
linux-pm, Sylwester Nawrocki, vireshk,
linux-kernel@vger.kernel.org, Jon Hunter, robh+dt, kgene,
Sylwester Nawrocki, pankaj.dubey, linux-tegra, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <CAJKOXPdh9eHrAuCxHkQBvJMqEnUCeU2xwkK=9yyiJ6BuTLJ+_A@mail.gmail.com>
On 8/21/19 2:16 PM, Krzysztof Kozlowski wrote:
> On Wed, 21 Aug 2019 at 13:51, Bartlomiej Zolnierkiewicz
> <b.zolnierkie@samsung.com> wrote:
>>>>> Following this change, I am now seeing the above error on our Tegra
>>>>> boards where this driver is enabled. This is triggering a kernel
>>>>> warnings test we have to fail. Hence, I don't think that you can remove
>>>>> the compatible node test here, unless you have a better way to determine
>>>>> if this is a samsung device.
>>>>
>>>> Right, this is really wrong... I missed that it is not a probe but
>>>> early init. And this init will be called on every board... Probably it
>>>> should be converted to a regular driver.
>>
>> Early initialization is needed for SoC driver to be used from within
>> arch/arm/mach-exynos/ and _initcall() usage is the usual way for SoC
>> drivers to be initialized:
>>
>> drivers/soc/amlogic/meson-gx-socinfo.c
>> drivers/soc/amlogic/meson-mx-socinfo.c
>> drivers/soc/atmel/soc.c
>> drivers/soc/bcm/brcmstb/common.c
>> drivers/soc/imx/soc-imx-scu.c
>> drivers/soc/imx/soc-imx8.c
>> drivers/soc/renesas/renesas-soc.c
>> drivers/soc/tegra/fuse/fuse-tegra.c
>> drivers/soc/ux500/ux500-soc-id.c
>> drivers/soc/versatile/soc-integrator.c
>> drivers/soc/versatile/soc-integrator.c
>>
>> The only SoC drivers that are regular drivers are:
>>
>> drivers/soc/fsl/guts.c
>> drivers/soc/versatile/soc-realview.c
>
> Thanks for pointing it out.
>
> Indeed, the initcall was needed in your set of patches here:
> https://patchwork.kernel.org/project/linux-samsung-soc/list/?series=43565&state=*
> but this work was not continued here. Maybe it will be later
> resubmitted... maybe not... who knows? Therefore I would prefer proper
The work got delayed mainly because of the request for the formal
audit of each usage vs cache coherency. Since it is rather small
cleanup and such audit is time consuming it became a low priority.
> solution for current case (driver), unless patches for mach are being
> brought back to life now.
>
>>> I'm also inclined to have it converted to a regular driver. We already
>>> have "exynos-asv" driver matching on the chipid node (patch 3/9).
>>> The ASV patches will not be merged soon anyway, all this needs some more
>>> thought. Krzysztof, can we abandon the chipid patches for now? Your
>>
>> chipid driver is good and useful on its own. The preferred solution
>> IMHO would be to just revert "soc: samsung: Convert exynos-chipid
>> driver to use the regmap API" commit.
Or just fix it by re-adding removed Exynos chipid compatible checking:
diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
index 006a95feb618..d9912bd52479 100644
--- a/drivers/soc/samsung/exynos-chipid.c
+++ b/drivers/soc/samsung/exynos-chipid.c
@@ -55,6 +55,11 @@ int __init exynos_chipid_early_init(void)
u32 revision;
int ret;
+ /* look up for chipid node */
+ np = of_find_compatible_node(NULL, NULL, "samsung,exynos4210-chipid");
+ if (!np)
+ return -ENODEV;
+
regmap = syscon_regmap_lookup_by_compatible("samsung,exynos4210-chipid");
if (IS_ERR(regmap)) {
pr_err("Failed to get CHIPID regmap\n");
> I queued the chipid as a dependency for ASV but ASV requires the
> regmap. What would be left after reverting the regmap part? Simple
> unused printk driver? No need for such. If reverting, then let's drop
It provides sysfs information about SoC/platform and is useful on its
own (for debugging, reporting etc. purposes). Maybe not terrible useful
but on OTOH the driver is only ~100 LOC.
> entire driver and rework it offline.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
_______________________________________________
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] usb: dwc3: meson-g12a: fix suspend resume regulator unbalanced disables
From: Neil Armstrong @ 2019-08-21 13:35 UTC (permalink / raw)
To: balbi
Cc: Neil Armstrong, Kevin Hilman, linux-usb, linux-kernel,
linux-amlogic, linux-arm-kernel
When going in suspend, in Device mode, then resuming back leads
to the following:
unbalanced disables for USB_PWR_EN
WARNING: CPU: 0 PID: 163 at ../drivers/regulator/core.c:2590 _regulator_disable+0x104/0x180
Hardware name: Amlogic Meson G12A U200 Development Board (DT)
[...]
pc : _regulator_disable+0x104/0x180
lr : _regulator_disable+0x104/0x180
[...]
Call trace:
_regulator_disable+0x104/0x180
regulator_disable+0x40/0x78
dwc3_meson_g12a_otg_mode_set+0x84/0xb0
dwc3_meson_g12a_irq_thread+0x58/0xb8
irq_thread_fn+0x28/0x80
irq_thread+0x118/0x1b8
kthread+0xf4/0x120
ret_from_fork+0x10/0x18
This disables the regulator if enabled on suspend, and the reverse on
resume.
Fixes: c99993376f72 ("usb: dwc3: Add Amlogic G12A DWC3 glue")
Reported-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/usb/dwc3/dwc3-meson-g12a.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-meson-g12a.c b/drivers/usb/dwc3/dwc3-meson-g12a.c
index bca7e92a10e9..12dda04b004d 100644
--- a/drivers/usb/dwc3/dwc3-meson-g12a.c
+++ b/drivers/usb/dwc3/dwc3-meson-g12a.c
@@ -564,7 +564,13 @@ static int __maybe_unused dwc3_meson_g12a_runtime_resume(struct device *dev)
static int __maybe_unused dwc3_meson_g12a_suspend(struct device *dev)
{
struct dwc3_meson_g12a *priv = dev_get_drvdata(dev);
- int i;
+ int i, ret;
+
+ if (priv->vbus && priv->otg_phy_mode == PHY_MODE_USB_HOST) {
+ ret = regulator_disable(priv->vbus);
+ if (ret)
+ return ret;
+ }
for (i = 0 ; i < PHY_COUNT ; ++i) {
phy_power_off(priv->phys[i]);
@@ -599,6 +605,12 @@ static int __maybe_unused dwc3_meson_g12a_resume(struct device *dev)
return ret;
}
+ if (priv->vbus && priv->otg_phy_mode == PHY_MODE_USB_HOST) {
+ ret = regulator_enable(priv->vbus);
+ if (ret)
+ return ret;
+ }
+
return 0;
}
--
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 1/5] dt-bindings: power: add Amlogic Everything-Else power domains bindings
From: Rob Herring @ 2019-08-21 13:46 UTC (permalink / raw)
To: Neil Armstrong
Cc: devicetree, Ulf Hansson, open list:THERMAL, Kevin Hilman,
linux-kernel@vger.kernel.org, linux-amlogic,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190821114121.10430-2-narmstrong@baylibre.com>
On Wed, Aug 21, 2019 at 6:41 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> Add the bindings for the Amlogic Everything-Else power domains,
> controlling the Everything-Else peripherals power domains.
>
> The bindings targets the Amlogic G12A and SM1 compatible SoCs,
> support for earlier SoCs will be added later.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../bindings/power/amlogic,meson-ee-pwrc.yaml | 93 +++++++++++++++++++
> include/dt-bindings/power/meson-g12a-power.h | 13 +++
> include/dt-bindings/power/meson-sm1-power.h | 18 ++++
> 3 files changed, 124 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml
> create mode 100644 include/dt-bindings/power/meson-g12a-power.h
> create mode 100644 include/dt-bindings/power/meson-sm1-power.h
Reviewed-by: Rob Herring <robh@kernel.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 net-next] net: stmmac: dwmac-meson8b: use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-21 13:51 UTC (permalink / raw)
To: davem, peppe.cavallaro, alexandre.torgue, joabreu, khilman,
mcoquelin.stm32
Cc: netdev, YueHaibing, linux-kernel, linux-amlogic, linux-stm32,
linux-arm-kernel
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index 786ca4a..9cda29e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -308,7 +308,6 @@ static int meson8b_dwmac_probe(struct platform_device *pdev)
{
struct plat_stmmacenet_data *plat_dat;
struct stmmac_resources stmmac_res;
- struct resource *res;
struct meson8b_dwmac *dwmac;
int ret;
@@ -332,8 +331,7 @@ static int meson8b_dwmac_probe(struct platform_device *pdev)
ret = -EINVAL;
goto err_remove_config_dt;
}
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- dwmac->regs = devm_ioremap_resource(&pdev->dev, res);
+ dwmac->regs = devm_platform_ioremap_resource(pdev, 1);
if (IS_ERR(dwmac->regs)) {
ret = PTR_ERR(dwmac->regs);
goto err_remove_config_dt;
--
2.7.4
_______________________________________________
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 v10 00/23] MT8183 IOMMU SUPPORT
From: Yong Wu @ 2019-08-21 13:53 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Will Deacon
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang,
srv_heupstream, chao.hao, linux-kernel, Evan Green, Tomasz Figa,
iommu, Rob Herring, linux-mediatek, yong.wu, ming-fan.chen,
anan.sun, Matthias Kaehlcke, linux-arm-kernel
This patchset mainly adds support for mt8183 IOMMU and SMI.
mt8183 has only one M4U like mt8173 and is also MTK IOMMU gen2 which
uses ARM Short-Descriptor translation table format.
The mt8183 M4U-SMI HW diagram is as below:
EMI
|
M4U
|
----------
| |
gals0-rx gals1-rx
| |
| |
gals0-tx gals1-tx
| |
------------
SMI Common
------------
|
+-----+-----+--------+-----+-----+-------+-------+
| | | | | | | |
| | gals-rx gals-rx | gals-rx gals-rx gals-rx
| | | | | | | |
| | | | | | | |
| | gals-tx gals-tx | gals-tx gals-tx gals-tx
| | | | | | | |
larb0 larb1 IPU0 IPU1 larb4 larb5 larb6 CCU
disp vdec img cam venc img cam
All the connections are HW fixed, SW can NOT adjust it.
Compared with mt8173, we add a GALS(Global Async Local Sync) module
between SMI-common and M4U, and additional GALS between larb2/3/5/6
and SMI-common. GALS can help synchronize for the modules in different
clock frequency, it can be seen as a "asynchronous fifo".
GALS can only help transfer the command/data while it doesn't have
the configuring register, thus it has the special "smi" clock and it
doesn't have the "apb" clock. From the diagram above, we add "gals0"
and "gals1" clocks for smi-common and add a "gals" clock for smi-larb.
From the diagram above, IPU0/IPU1(Image Processor Unit) and CCU(Camera
Control Unit) is connected with smi-common directly, we can take them
as "larb2", "larb3" and "larb7", and their register spaces are
different with the normal larb.
The dtsi was sent at: [1] https://lore.kernel.org/patchwork/patch/1054099/
Change notes:
v10:
1) Keep v7s only dealing with the pa32/pa33. Move the special "4gb mode"
flow into mtk iommu. like v8 did.
2) Split the "4gb mode" into two patches. one is only for the v7s, the other
is for mtk iommu.
3) Add a fixup patch(5/23) for 4gb mode, like v8 did.
v9: https://lists.linuxfoundation.org/pipermail/iommu/2019-August/037925.html
1) rebase on v5.3-rc1.
2) In v7s, Use oas to implement MTK 4GB mode. It nearly reconstruct the
patch, so I don't keep the R-b.
v8: https://lists.linuxfoundation.org/pipermail/iommu/2019-June/037095.html
1) From the 4GB mode:
a. Move the patch sequency(Move "iommu/mediatek: Fix iova_to_phys PA
start for 4GB mode" before "iommu/io-pgtable-arm-v7s: Extend MediaTek
4G Mode").
b. Remove the patch "Rename enable_4GB to dram_is_4gb" and Use Evan's
suggestion.
2) add a "union" for smi gen1/gen2 base.
3) Clean up the structure "struct mtk_smi_iommu" since it have only one item,
suggested from Matthias.
v7: https://lists.linuxfoundation.org/pipermail/iommu/2019-June/036552.html
1) rebase on v5.2-rc1.
2) Add fixed tags in patch 20.
3) Remove shutdown patch. I will send it independently if necessary.
v6: https://lists.linuxfoundation.org/pipermail/iommu/2019-February/033685.html
1) rebase on v5.0-rc1.
2) About the register name (VLD_PA_RNG), Keep consistent in the patches.
3) In the 4GB mode, Always add MTK_4GB_quirk.
4) Reword some commit message helped from Evan. like common->smi_ao_base is
completely different from common->base; STANDARD_AXI_MODE reg is completely
different from CTRL_MISC; commit in the shutdown patch.
5) Add 2 new patches again:
iommu/mediatek: Rename enable_4GB to dram_is_4gb
iommu/mediatek: Fix iova_to_phys PA start for 4GB mode
v5: https://lists.linuxfoundation.org/pipermail/iommu/2019-January/032387.html
1) Remove this patch "iommu/mediatek: Constify iommu_ops" from here as it
was applied for v5.0.
2) Again, add 3 preparing patches. Move two property into the plat_data.
iommu/mediatek: Move vld_pa_rng into plat_data
iommu/mediatek: Move reset_axi into plat_data
iommu/mediatek: Refine protect memory definition
3) Add shutdown callback for mtk_iommu_v1 in patch[19/20].
v4: http://lists.infradead.org/pipermail/linux-mediatek/2018-December/016205.html
1) Add 3 preparing patches. Seperate some minor meaningful code into
a new patch according to Matthias's suggestion.
memory: mtk-smi: Add gals support
iommu/mediatek: Add larb-id remapped support
iommu/mediatek: Add bclk can be supported optionally
2) rebase on "iommu/mediatek: Make it explicitly non-modular"
which was applied.
https://lore.kernel.org/patchwork/patch/1020125/
3) add some comment about "mediatek,larb-id" in the commit message of
the patch "mtk-smi: Get rid of need_larbid".
4) Fix bus_sel value.
v3: https://lists.linuxfoundation.org/pipermail/iommu/2018-November/031121.html
1) rebase on v4.20-rc1.
2) In the dt-binding, add a minor string "mt7623" which also use gen1
since Matthias added it in v4.20.
3) About v7s:
a) for paddr_to_pte, change the param from "arm_v7s_io_pgtable" to
"arm_pgtable_cfg", according to Robin suggestion.
b) Don't use CONFIG_PHYS_ADDR_T_64BIT.
c) add a little comment(pgtable address still don't over 4GB) in the
commit message of the patch "Extend MediaTek 4GB Mode".
4) add "iommu/mediatek: Constify iommu_ops" into this patchset. this may
be helpful for review and merge.
https://lists.linuxfoundation.org/pipermail/iommu/2018-October/030637.html
v2: https://lists.linuxfoundation.org/pipermail/iommu/2018-September/030164.html
1) Fix typo in the commit message of dt-binding.
2) Change larb2/larb3 to the special larbs.
3) Refactor the larb-id remapped array(larbid_remapped), then we
don't need add the new function(mtk_iommu_get_larbid).
4) Add a new patch for v7s two helpers(paddr_to_iopte and
iopte_to_paddr).
5) Change some comment for MTK 4GB mode.
v1: base on v4.19-rc1.
http://lists.infradead.org/pipermail/linux-mediatek/2018-September/014881.html
Yong Wu (23):
dt-bindings: mediatek: Add binding for mt8183 IOMMU and SMI
iommu/mediatek: Use a struct as the platform data
memory: mtk-smi: Use a general config_port interface
memory: mtk-smi: Use a struct for the platform data for smi-common
iommu/mediatek: Fix iova_to_phys PA start for 4GB mode
iommu/io-pgtable-arm-v7s: Add paddr_to_iopte and iopte_to_paddr
helpers
iommu/io-pgtable-arm-v7s: Use ias/oas to check the valid iova/pa
iommu/io-pgtable-arm-v7s: Rename the quirk from MTK_4GB to MTK_EXT
iommu/io-pgtable-arm-v7s: Extend to support PA[33:32] for MediaTek
iommu/mediatek: Adjust the PA for the 4GB Mode
iommu/mediatek: Add bclk can be supported optionally
iommu/mediatek: Add larb-id remapped support
iommu/mediatek: Refine protect memory definition
iommu/mediatek: Move reset_axi into plat_data
iommu/mediatek: Move vld_pa_rng into plat_data
memory: mtk-smi: Add gals support
iommu/mediatek: Add mt8183 IOMMU support
iommu/mediatek: Add mmu1 support
memory: mtk-smi: Invoke pm runtime_callback to enable clocks
memory: mtk-smi: Add bus_sel for mt8183
iommu/mediatek: Fix VLD_PA_RNG register backup when suspend
memory: mtk-smi: Get rid of need_larbid
iommu/mediatek: Clean up struct mtk_smi_iommu
.../devicetree/bindings/iommu/mediatek,iommu.txt | 30 ++-
.../memory-controllers/mediatek,smi-common.txt | 12 +-
.../memory-controllers/mediatek,smi-larb.txt | 4 +
drivers/iommu/io-pgtable-arm-v7s.c | 80 ++++--
drivers/iommu/mtk_iommu.c | 168 +++++++++----
drivers/iommu/mtk_iommu.h | 21 +-
drivers/iommu/mtk_iommu_v1.c | 6 +-
drivers/memory/mtk-smi.c | 268 ++++++++++++++-------
include/dt-bindings/memory/mt8183-larb-port.h | 130 ++++++++++
include/linux/io-pgtable.h | 9 +-
include/soc/mediatek/smi.h | 5 -
11 files changed, 553 insertions(+), 180 deletions(-)
create mode 100644 include/dt-bindings/memory/mt8183-larb-port.h
--
1.9.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 net-next] net: stmmac: dwmac-meson: use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-21 13:54 UTC (permalink / raw)
To: davem, peppe.cavallaro, alexandre.torgue, joabreu, khilman,
mcoquelin.stm32
Cc: netdev, YueHaibing, linux-kernel, linux-amlogic, linux-stm32,
linux-arm-kernel
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c
index 88eb169..bbc16b5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c
@@ -46,7 +46,6 @@ static int meson6_dwmac_probe(struct platform_device *pdev)
struct plat_stmmacenet_data *plat_dat;
struct stmmac_resources stmmac_res;
struct meson_dwmac *dwmac;
- struct resource *res;
int ret;
ret = stmmac_get_platform_resources(pdev, &stmmac_res);
@@ -63,8 +62,7 @@ static int meson6_dwmac_probe(struct platform_device *pdev)
goto err_remove_config_dt;
}
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- dwmac->reg = devm_ioremap_resource(&pdev->dev, res);
+ dwmac->reg = devm_platform_ioremap_resource(pdev, 1);
if (IS_ERR(dwmac->reg)) {
ret = PTR_ERR(dwmac->reg);
goto err_remove_config_dt;
--
2.7.4
_______________________________________________
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 v10 01/23] dt-bindings: mediatek: Add binding for mt8183 IOMMU and SMI
From: Yong Wu @ 2019-08-21 13:53 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Will Deacon
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang,
srv_heupstream, chao.hao, linux-kernel, Evan Green, Tomasz Figa,
iommu, Rob Herring, linux-mediatek, yong.wu, ming-fan.chen,
anan.sun, Matthias Kaehlcke, linux-arm-kernel
In-Reply-To: <1566395606-7975-1-git-send-email-yong.wu@mediatek.com>
This patch adds decriptions for mt8183 IOMMU and SMI.
mt8183 has only one M4U like mt8173 and is also MTK IOMMU gen2 which
uses ARM Short-Descriptor translation table format.
The mt8183 M4U-SMI HW diagram is as below:
EMI
|
M4U
|
----------
| |
gals0-rx gals1-rx
| |
| |
gals0-tx gals1-tx
| |
------------
SMI Common
------------
|
+-----+-----+--------+-----+-----+-------+-------+
| | | | | | | |
| | gals-rx gals-rx | gals-rx gals-rx gals-rx
| | | | | | | |
| | | | | | | |
| | gals-tx gals-tx | gals-tx gals-tx gals-tx
| | | | | | | |
larb0 larb1 IPU0 IPU1 larb4 larb5 larb6 CCU
disp vdec img cam venc img cam
All the connections are HW fixed, SW can NOT adjust it.
Compared with mt8173, we add a GALS(Global Async Local Sync) module
between SMI-common and M4U, and additional GALS between larb2/3/5/6
and SMI-common. GALS can help synchronize for the modules in different
clock frequency, it can be seen as a "asynchronous fifo".
GALS can only help transfer the command/data while it doesn't have
the configuring register, thus it has the special "smi" clock and it
doesn't have the "apb" clock. From the diagram above, we add "gals0"
and "gals1" clocks for smi-common and add a "gals" clock for smi-larb.
From the diagram above, IPU0/IPU1(Image Processor Unit) and CCU(Camera
Control Unit) is connected with smi-common directly, we can take them
as "larb2", "larb3" and "larb7", and their register spaces are
different with the normal larb.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Evan Green <evgreen@chromium.org>
---
.../devicetree/bindings/iommu/mediatek,iommu.txt | 30 ++++-
.../memory-controllers/mediatek,smi-common.txt | 12 +-
.../memory-controllers/mediatek,smi-larb.txt | 4 +
include/dt-bindings/memory/mt8183-larb-port.h | 130 +++++++++++++++++++++
4 files changed, 170 insertions(+), 6 deletions(-)
create mode 100644 include/dt-bindings/memory/mt8183-larb-port.h
diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
index 6922db5..ce59a50 100644
--- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
@@ -11,10 +11,23 @@ ARM Short-Descriptor translation table format for address translation.
|
m4u (Multimedia Memory Management Unit)
|
+ +--------+
+ | |
+ gals0-rx gals1-rx (Global Async Local Sync rx)
+ | |
+ | |
+ gals0-tx gals1-tx (Global Async Local Sync tx)
+ | | Some SoCs may have GALS.
+ +--------+
+ |
SMI Common(Smart Multimedia Interface Common)
|
+----------------+-------
| |
+ | gals-rx There may be GALS in some larbs.
+ | |
+ | |
+ | gals-tx
| |
SMI larb0 SMI larb1 ... SoCs have several SMI local arbiter(larb).
(display) (vdec)
@@ -36,6 +49,10 @@ each local arbiter.
like display, video decode, and camera. And there are different ports
in each larb. Take a example, There are many ports like MC, PP, VLD in the
video decode local arbiter, all these ports are according to the video HW.
+ In some SoCs, there may be a GALS(Global Async Local Sync) module between
+smi-common and m4u, and additional GALS module between smi-larb and
+smi-common. GALS can been seen as a "asynchronous fifo" which could help
+synchronize for the modules in different clock frequency.
Required properties:
- compatible : must be one of the following string:
@@ -44,18 +61,25 @@ Required properties:
"mediatek,mt7623-m4u", "mediatek,mt2701-m4u" for mt7623 which uses
generation one m4u HW.
"mediatek,mt8173-m4u" for mt8173 which uses generation two m4u HW.
+ "mediatek,mt8183-m4u" for mt8183 which uses generation two m4u HW.
- reg : m4u register base and size.
- interrupts : the interrupt of m4u.
- clocks : must contain one entry for each clock-names.
-- clock-names : must be "bclk", It is the block clock of m4u.
+- clock-names : Only 1 optional clock:
+ - "bclk": the block clock of m4u.
+ Here is the list which require this "bclk":
+ - mt2701, mt2712, mt7623 and mt8173.
+ Note that m4u use the EMI clock which always has been enabled before kernel
+ if there is no this "bclk".
- mediatek,larbs : List of phandle to the local arbiters in the current Socs.
Refer to bindings/memory-controllers/mediatek,smi-larb.txt. It must sort
according to the local arbiter index, like larb0, larb1, larb2...
- iommu-cells : must be 1. This is the mtk_m4u_id according to the HW.
Specifies the mtk_m4u_id as defined in
dt-binding/memory/mt2701-larb-port.h for mt2701, mt7623
- dt-binding/memory/mt2712-larb-port.h for mt2712, and
- dt-binding/memory/mt8173-larb-port.h for mt8173.
+ dt-binding/memory/mt2712-larb-port.h for mt2712,
+ dt-binding/memory/mt8173-larb-port.h for mt8173, and
+ dt-binding/memory/mt8183-larb-port.h for mt8183.
Example:
iommu: iommu@10205000 {
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
index e937ddd..b478ade 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
@@ -2,9 +2,10 @@ SMI (Smart Multimedia Interface) Common
The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
-Mediatek SMI have two generations of HW architecture, mt2712 and mt8173 use
-the second generation of SMI HW while mt2701 uses the first generation HW of
-SMI.
+Mediatek SMI have two generations of HW architecture, here is the list
+which generation the SoCs use:
+generation 1: mt2701 and mt7623.
+generation 2: mt2712, mt8173 and mt8183.
There's slight differences between the two SMI, for generation 2, the
register which control the iommu port is at each larb's register base. But
@@ -19,6 +20,7 @@ Required properties:
"mediatek,mt2712-smi-common"
"mediatek,mt7623-smi-common", "mediatek,mt2701-smi-common"
"mediatek,mt8173-smi-common"
+ "mediatek,mt8183-smi-common"
- reg : the register and size of the SMI block.
- power-domains : a phandle to the power domain of this local arbiter.
- clocks : Must contain an entry for each entry in clock-names.
@@ -30,6 +32,10 @@ Required properties:
They may be the same if both source clocks are the same.
- "async" : asynchronous clock, it help transform the smi clock into the emi
clock domain, this clock is only needed by generation 1 smi HW.
+ and these 2 option clocks for generation 2 smi HW:
+ - "gals0": the path0 clock of GALS(Global Async Local Sync).
+ - "gals1": the path1 clock of GALS(Global Async Local Sync).
+ Here is the list which has this GALS: mt8183.
Example:
smi_common: smi@14022000 {
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
index 94eddca..4b369b3 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
@@ -8,6 +8,7 @@ Required properties:
"mediatek,mt2712-smi-larb"
"mediatek,mt7623-smi-larb", "mediatek,mt2701-smi-larb"
"mediatek,mt8173-smi-larb"
+ "mediatek,mt8183-smi-larb"
- reg : the register and size of this local arbiter.
- mediatek,smi : a phandle to the smi_common node.
- power-domains : a phandle to the power domain of this local arbiter.
@@ -16,6 +17,9 @@ Required properties:
- "apb" : Advanced Peripheral Bus clock, It's the clock for setting
the register.
- "smi" : It's the clock for transfer data and command.
+ and this optional clock name:
+ - "gals": the clock for GALS(Global Async Local Sync).
+ Here is the list which has this GALS: mt8183.
Required property for mt2701, mt2712 and mt7623:
- mediatek,larb-id :the hardware id of this larb.
diff --git a/include/dt-bindings/memory/mt8183-larb-port.h b/include/dt-bindings/memory/mt8183-larb-port.h
new file mode 100644
index 0000000..2c579f3
--- /dev/null
+++ b/include/dt-bindings/memory/mt8183-larb-port.h
@@ -0,0 +1,130 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Yong Wu <yong.wu@mediatek.com>
+ */
+#ifndef __DTS_IOMMU_PORT_MT8183_H
+#define __DTS_IOMMU_PORT_MT8183_H
+
+#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
+
+#define M4U_LARB0_ID 0
+#define M4U_LARB1_ID 1
+#define M4U_LARB2_ID 2
+#define M4U_LARB3_ID 3
+#define M4U_LARB4_ID 4
+#define M4U_LARB5_ID 5
+#define M4U_LARB6_ID 6
+#define M4U_LARB7_ID 7
+
+/* larb0 */
+#define M4U_PORT_DISP_OVL0 MTK_M4U_ID(M4U_LARB0_ID, 0)
+#define M4U_PORT_DISP_2L_OVL0_LARB0 MTK_M4U_ID(M4U_LARB0_ID, 1)
+#define M4U_PORT_DISP_2L_OVL1_LARB0 MTK_M4U_ID(M4U_LARB0_ID, 2)
+#define M4U_PORT_DISP_RDMA0 MTK_M4U_ID(M4U_LARB0_ID, 3)
+#define M4U_PORT_DISP_RDMA1 MTK_M4U_ID(M4U_LARB0_ID, 4)
+#define M4U_PORT_DISP_WDMA0 MTK_M4U_ID(M4U_LARB0_ID, 5)
+#define M4U_PORT_MDP_RDMA0 MTK_M4U_ID(M4U_LARB0_ID, 6)
+#define M4U_PORT_MDP_WROT0 MTK_M4U_ID(M4U_LARB0_ID, 7)
+#define M4U_PORT_MDP_WDMA0 MTK_M4U_ID(M4U_LARB0_ID, 8)
+#define M4U_PORT_DISP_FAKE0 MTK_M4U_ID(M4U_LARB0_ID, 9)
+
+/* larb1 */
+#define M4U_PORT_HW_VDEC_MC_EXT MTK_M4U_ID(M4U_LARB1_ID, 0)
+#define M4U_PORT_HW_VDEC_PP_EXT MTK_M4U_ID(M4U_LARB1_ID, 1)
+#define M4U_PORT_HW_VDEC_VLD_EXT MTK_M4U_ID(M4U_LARB1_ID, 2)
+#define M4U_PORT_HW_VDEC_AVC_MV_EXT MTK_M4U_ID(M4U_LARB1_ID, 3)
+#define M4U_PORT_HW_VDEC_PRED_RD_EXT MTK_M4U_ID(M4U_LARB1_ID, 4)
+#define M4U_PORT_HW_VDEC_PRED_WR_EXT MTK_M4U_ID(M4U_LARB1_ID, 5)
+#define M4U_PORT_HW_VDEC_PPWRAP_EXT MTK_M4U_ID(M4U_LARB1_ID, 6)
+
+/* larb2 VPU0 */
+#define M4U_PORT_IMG_IPUO MTK_M4U_ID(M4U_LARB2_ID, 0)
+#define M4U_PORT_IMG_IPU3O MTK_M4U_ID(M4U_LARB2_ID, 1)
+#define M4U_PORT_IMG_IPUI MTK_M4U_ID(M4U_LARB2_ID, 2)
+
+/* larb3 VPU1 */
+#define M4U_PORT_CAM_IPUO MTK_M4U_ID(M4U_LARB3_ID, 0)
+#define M4U_PORT_CAM_IPU2O MTK_M4U_ID(M4U_LARB3_ID, 1)
+#define M4U_PORT_CAM_IPU3O MTK_M4U_ID(M4U_LARB3_ID, 2)
+#define M4U_PORT_CAM_IPUI MTK_M4U_ID(M4U_LARB3_ID, 3)
+#define M4U_PORT_CAM_IPU2I MTK_M4U_ID(M4U_LARB3_ID, 4)
+
+/* larb4 */
+#define M4U_PORT_VENC_RCPU MTK_M4U_ID(M4U_LARB4_ID, 0)
+#define M4U_PORT_VENC_REC MTK_M4U_ID(M4U_LARB4_ID, 1)
+#define M4U_PORT_VENC_BSDMA MTK_M4U_ID(M4U_LARB4_ID, 2)
+#define M4U_PORT_VENC_SV_COMV MTK_M4U_ID(M4U_LARB4_ID, 3)
+#define M4U_PORT_VENC_RD_COMV MTK_M4U_ID(M4U_LARB4_ID, 4)
+#define M4U_PORT_JPGENC_RDMA MTK_M4U_ID(M4U_LARB4_ID, 5)
+#define M4U_PORT_JPGENC_BSDMA MTK_M4U_ID(M4U_LARB4_ID, 6)
+#define M4U_PORT_VENC_CUR_LUMA MTK_M4U_ID(M4U_LARB4_ID, 7)
+#define M4U_PORT_VENC_CUR_CHROMA MTK_M4U_ID(M4U_LARB4_ID, 8)
+#define M4U_PORT_VENC_REF_LUMA MTK_M4U_ID(M4U_LARB4_ID, 9)
+#define M4U_PORT_VENC_REF_CHROMA MTK_M4U_ID(M4U_LARB4_ID, 10)
+
+/* larb5 */
+#define M4U_PORT_CAM_IMGI MTK_M4U_ID(M4U_LARB5_ID, 0)
+#define M4U_PORT_CAM_IMG2O MTK_M4U_ID(M4U_LARB5_ID, 1)
+#define M4U_PORT_CAM_IMG3O MTK_M4U_ID(M4U_LARB5_ID, 2)
+#define M4U_PORT_CAM_VIPI MTK_M4U_ID(M4U_LARB5_ID, 3)
+#define M4U_PORT_CAM_LCEI MTK_M4U_ID(M4U_LARB5_ID, 4)
+#define M4U_PORT_CAM_SMXI MTK_M4U_ID(M4U_LARB5_ID, 5)
+#define M4U_PORT_CAM_SMXO MTK_M4U_ID(M4U_LARB5_ID, 6)
+#define M4U_PORT_CAM_WPE0_RDMA1 MTK_M4U_ID(M4U_LARB5_ID, 7)
+#define M4U_PORT_CAM_WPE0_RDMA0 MTK_M4U_ID(M4U_LARB5_ID, 8)
+#define M4U_PORT_CAM_WPE0_WDMA MTK_M4U_ID(M4U_LARB5_ID, 9)
+#define M4U_PORT_CAM_FDVT_RP MTK_M4U_ID(M4U_LARB5_ID, 10)
+#define M4U_PORT_CAM_FDVT_WR MTK_M4U_ID(M4U_LARB5_ID, 11)
+#define M4U_PORT_CAM_FDVT_RB MTK_M4U_ID(M4U_LARB5_ID, 12)
+#define M4U_PORT_CAM_WPE1_RDMA0 MTK_M4U_ID(M4U_LARB5_ID, 13)
+#define M4U_PORT_CAM_WPE1_RDMA1 MTK_M4U_ID(M4U_LARB5_ID, 14)
+#define M4U_PORT_CAM_WPE1_WDMA MTK_M4U_ID(M4U_LARB5_ID, 15)
+#define M4U_PORT_CAM_DPE_RDMA MTK_M4U_ID(M4U_LARB5_ID, 16)
+#define M4U_PORT_CAM_DPE_WDMA MTK_M4U_ID(M4U_LARB5_ID, 17)
+#define M4U_PORT_CAM_MFB_RDMA0 MTK_M4U_ID(M4U_LARB5_ID, 18)
+#define M4U_PORT_CAM_MFB_RDMA1 MTK_M4U_ID(M4U_LARB5_ID, 19)
+#define M4U_PORT_CAM_MFB_WDMA MTK_M4U_ID(M4U_LARB5_ID, 20)
+#define M4U_PORT_CAM_RSC_RDMA0 MTK_M4U_ID(M4U_LARB5_ID, 21)
+#define M4U_PORT_CAM_RSC_WDMA MTK_M4U_ID(M4U_LARB5_ID, 22)
+#define M4U_PORT_CAM_OWE_RDMA MTK_M4U_ID(M4U_LARB5_ID, 23)
+#define M4U_PORT_CAM_OWE_WDMA MTK_M4U_ID(M4U_LARB5_ID, 24)
+
+/* larb6 */
+#define M4U_PORT_CAM_IMGO MTK_M4U_ID(M4U_LARB6_ID, 0)
+#define M4U_PORT_CAM_RRZO MTK_M4U_ID(M4U_LARB6_ID, 1)
+#define M4U_PORT_CAM_AAO MTK_M4U_ID(M4U_LARB6_ID, 2)
+#define M4U_PORT_CAM_AFO MTK_M4U_ID(M4U_LARB6_ID, 3)
+#define M4U_PORT_CAM_LSCI0 MTK_M4U_ID(M4U_LARB6_ID, 4)
+#define M4U_PORT_CAM_LSCI1 MTK_M4U_ID(M4U_LARB6_ID, 5)
+#define M4U_PORT_CAM_PDO MTK_M4U_ID(M4U_LARB6_ID, 6)
+#define M4U_PORT_CAM_BPCI MTK_M4U_ID(M4U_LARB6_ID, 7)
+#define M4U_PORT_CAM_LCSO MTK_M4U_ID(M4U_LARB6_ID, 8)
+#define M4U_PORT_CAM_CAM_RSSO_A MTK_M4U_ID(M4U_LARB6_ID, 9)
+#define M4U_PORT_CAM_UFEO MTK_M4U_ID(M4U_LARB6_ID, 10)
+#define M4U_PORT_CAM_SOCO MTK_M4U_ID(M4U_LARB6_ID, 11)
+#define M4U_PORT_CAM_SOC1 MTK_M4U_ID(M4U_LARB6_ID, 12)
+#define M4U_PORT_CAM_SOC2 MTK_M4U_ID(M4U_LARB6_ID, 13)
+#define M4U_PORT_CAM_CCUI MTK_M4U_ID(M4U_LARB6_ID, 14)
+#define M4U_PORT_CAM_CCUO MTK_M4U_ID(M4U_LARB6_ID, 15)
+#define M4U_PORT_CAM_RAWI_A MTK_M4U_ID(M4U_LARB6_ID, 16)
+#define M4U_PORT_CAM_CCUG MTK_M4U_ID(M4U_LARB6_ID, 17)
+#define M4U_PORT_CAM_PSO MTK_M4U_ID(M4U_LARB6_ID, 18)
+#define M4U_PORT_CAM_AFO_1 MTK_M4U_ID(M4U_LARB6_ID, 19)
+#define M4U_PORT_CAM_LSCI_2 MTK_M4U_ID(M4U_LARB6_ID, 20)
+#define M4U_PORT_CAM_PDI MTK_M4U_ID(M4U_LARB6_ID, 21)
+#define M4U_PORT_CAM_FLKO MTK_M4U_ID(M4U_LARB6_ID, 22)
+#define M4U_PORT_CAM_LMVO MTK_M4U_ID(M4U_LARB6_ID, 23)
+#define M4U_PORT_CAM_UFGO MTK_M4U_ID(M4U_LARB6_ID, 24)
+#define M4U_PORT_CAM_SPARE MTK_M4U_ID(M4U_LARB6_ID, 25)
+#define M4U_PORT_CAM_SPARE_2 MTK_M4U_ID(M4U_LARB6_ID, 26)
+#define M4U_PORT_CAM_SPARE_3 MTK_M4U_ID(M4U_LARB6_ID, 27)
+#define M4U_PORT_CAM_SPARE_4 MTK_M4U_ID(M4U_LARB6_ID, 28)
+#define M4U_PORT_CAM_SPARE_5 MTK_M4U_ID(M4U_LARB6_ID, 29)
+#define M4U_PORT_CAM_SPARE_6 MTK_M4U_ID(M4U_LARB6_ID, 30)
+
+/* CCU */
+#define M4U_PORT_CCU0 MTK_M4U_ID(M4U_LARB7_ID, 0)
+#define M4U_PORT_CCU1 MTK_M4U_ID(M4U_LARB7_ID, 1)
+
+#endif
--
1.9.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
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