* [PATCH v2, 2/3] dt-bindings: arm: amlogic: Add support for the Ugoos AM6
From: Christian Hewitt @ 2019-08-24 8:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Oleg Ivanov, Chrisitian Hewitt
In-Reply-To: <1566633850-9421-1-git-send-email-christianshewitt@gmail.com>
The Ugoos AM6 is based on the Amlogic W400 (G12B) reference design using the
S922X chipset.
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index 325c6fd..2ded61d 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -139,6 +139,7 @@ properties:
items:
- enum:
- hardkernel,odroid-n2
+ - ugoos,am6
- const: amlogic,g12b
...
--
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 v2,1/3] dt-bindings: Add vendor prefix for Ugoos
From: Christian Hewitt @ 2019-08-24 8:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Oleg Ivanov, Chrisitian Hewitt
In-Reply-To: <1566633850-9421-1-git-send-email-christianshewitt@gmail.com>
Ugoos Industrial Co., Ltd. are a manufacturer of ARM based TV Boxes,
Dongles, Digital Signage and Advertisement Solutions [0].
[0] (https://ugoos.com)
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 6992bbb..d962be9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -965,6 +965,8 @@ patternProperties:
description: Ubiquiti Networks
"^udoo,.*":
description: Udoo
+ "^ugoos,.*":
+ description: Ugoos Industrial Co., Ltd.
"^uniwest,.*":
description: United Western Technologies Corp (UniWest)
"^upisemi,.*":
--
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 v2,0/3] arm64: meson-g12b: Add support for the Ugoos AM6
From: Christian Hewitt @ 2019-08-24 8:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Oleg Ivanov, Chrisitian Hewitt
This patchset adds support for the Ugoos AM6, an Android STB based on
the Amlogic W400 reference design with the S922X chipset.
v2: correction of minor nits
Christian Hewitt (3):
dt-bindings: arm: amlogic: Add support for the Ugoos AM6
dt-bindings: Add vendor prefix for Ugoos
arm64: dts: meson-g12b-ugoos-am6: add initial device-tree
Documentation/devicetree/bindings/arm/amlogic.yaml | 1 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-g12b-ugoos-am6.dts | 567 +++++++++++++++++++++
4 files changed, 571 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
--
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
* Re: [linux-sunxi] [PATCH v2 0/3] Add basic support for RTC on Allwinner H6 SoC
From: Jernej Škrabec @ 2019-08-24 8:04 UTC (permalink / raw)
To: linux-sunxi, megous
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, devicetree,
Maxime Ripard, linux-kernel, Chen-Yu Tsai, Rob Herring,
linux-arm-kernel, linux-rtc
In-Reply-To: <20190820151934.3860-1-megous@megous.com>
Hi!
Dne torek, 20. avgust 2019 ob 17:19:31 CEST je megous@megous.com napisal(a):
> From: Ondrej Jirman <megous@megous.com>
>
> I went through the datasheets for H6 and H5, and compared the differences.
> RTCs are largely similar, but not entirely compatible. Incompatibilities
> are in details not yet implemented by the rtc driver though.
>
> I also corrected the clock tree in H6 DTSI.
>
> This patchset is necessary for implementing the WiFi/Bluetooth support
> on boards using H6 SoC.
>
> There was some discussion previously of describing HOSC, DCXO and XO
> oscillators and clocks as part of RTC in DT, but I decided against it
> because it's not necessary, becuse information that would be provided
> as a part of DT can already be determined at runtime from RTC registers,
> so this woudn't add any value and would only introduce complications
> to the driver. See: https://patchwork.kernel.org/cover/10898083/
>
> Please take a look.
>
>
> Thank you and regards,
> Ondrej Jirman
Sorry for a bit late test, but with your patches on Tanix TX6 box I get this
in dmesg:
[ 17.431742] sun6i-rtc 7000000.rtc: Failed to set rtc time.
[ 20.439742] sun6i-rtc 7000000.rtc: rtc is still busy.
[ 21.435744] sun6i-rtc 7000000.rtc: rtc is still busy.
[ 24.055741] sun6i-rtc 7000000.rtc: rtc is still busy.
[ 24.439752] sun6i-rtc 7000000.rtc: rtc is still busy.
Last line is repeated non-stop.
Any idea what could be wrong?
Best regards,
Jernej
_______________________________________________
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 V5 1/5] iommu/amd: Remove unnecessary locking from AMD iommu driver
From: Tom Murphy @ 2019-08-24 7:56 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Heiko Stuebner, virtualization, Matthias Brugger, Thierry Reding,
Will Deacon, Jean-Philippe Brucker, linux-samsung-soc,
Krzysztof Kozlowski, Jonathan Hunter, linux-rockchip, Kukjin Kim,
Andy Gross, linux-s390, Gerald Schaefer, linux-arm-msm,
linux-mediatek, linux-tegra, linux-arm-kernel, David Woodhouse,
Linux Kernel Mailing List, iommu, Robin Murphy
In-Reply-To: <20190820094143.GA24154@infradead.org>
>I have to admit I don't fully understand the concurrency issues here, but neither do I understand what the mutex you removed might have helped to start with.
Each range in the page tables is protected by the IO virtual address
allocator. The iommu driver allocates an IOVA range using locks before
it writes to a page table range. The IOVA allocator acts like a lock
on a specific range of the page tables. So we can handle most of the
concurrency issues in the IOVA allocator and avoid locking while
writing to a range in the page tables.
However because we have multiple levels of pages we might have to
allocate a middle page (a PMD) which covers more than the IOVA range
we have allocated.
To solve this we could use locks:
//pseudo code
lock_page_table()
if (we need to allocate middle pages) {
//allocate the page
//set the PMD value
}
unlock_page_table()
but we can actually avoid having any locking by doing the following:
//pseudo code
if (we need to allocate middle pages) {
//allocate the page
//cmpxchg64 to set the PMD if it wasn't already set since we last checked
if (the PMD was set while since we last checked)
//free the page we just allocated
}
In this case we can end up doing a pointless page allocate and free
but it's worth it to avoid using locks
You can see this in the intel iommu code here:
https://github.com/torvalds/linux/blob/9140d8bdd4c5a04abe181bb300378355d56990a4/drivers/iommu/intel-iommu.c#L904
>what the mutex you removed might have helped to start with.
The mutex I removed is arguably completely useless.
In the dma ops path we handle the IOVA allocations in the driver so we
can be sure a certain range is protected by the IOVA allocator.
Because the iommu ops path doesn't handle the IOVA allocations it
seems reasonable to lock the page tables to avoid two writers writing
to the same range at the same time. Without the lock it's complete
chaos and all writers can be writing to the same range at the same
time resulting in complete garbage.
BUT the locking doesn't actually make any real difference. Even with
locking we still have a race condition if two writers want to write to
the same range at the same time, the race is just whoever gets the
lock first, we still can't be sure what the result will be. So the
result is still garbage, just slightly more usable garbage because at
least the range is correct for one writer.
It just makes no sense to ever have two writers writing to the same
range and adding a lock doesn't fix that.
Already the Intel iommu ops path doesn't use locks for it's page table
so this isn't a new idea I'm just doing the same for the AMD iommu
driver
Does all that make sense?
On Tue, 20 Aug 2019 at 10:41, Christoph Hellwig <hch@infradead.org> wrote:
>
> On Thu, Aug 15, 2019 at 12:09:39PM +0100, Tom Murphy wrote:
> > We can remove the mutex lock from amd_iommu_map and amd_iommu_unmap.
> > iommu_map doesn’t lock while mapping and so no two calls should touch
> > the same iova range. The AMD driver already handles the page table page
> > allocations without locks so we can safely remove the locks.
>
> I've been looking over the code and trying to understand how the
> synchronization works. I gues we the cmpxchg64 in free_clear_pte
> is the important point here? I have to admit I don't fully understand
> the concurrency issues here, but neither do I understand what the
> mutex you removed might have helped to start with.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Aw: [PATCH net-next v3 0/3] net: ethernet: mediatek: convert to PHYLINK
From: René van Dorst @ 2019-08-24 7:41 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Nelson Chang, netdev, Sean Wang, linux-mips, Russell King,
linux-mediatek, John Crispin, Matthias Brugger, Stefan Roese,
David S . Miller, linux-arm-kernel
In-Reply-To: <trinity-df75d11a-c27f-4941-a880-b017ebabd3dc-1566583013438@3c-app-gmx-bs75>
Hi Frank,
Quoting Frank Wunderlich <frank-w@public-files.de>:
> tested on bpi-r2 (mt7623/mt7530) and bpi-r64 (mt7622/rtl8367)
>
Thanks for testing!
> as reported to rene directly rx-path needs some rework because
> current rx-speed
> on bpi-r2 is 865 Mbits/sec instead of ~940 Mbits/sec
I still think it is a result of the extra code in the rx path when mt76x8
was introduced.
Greats,
René
>
> Tested-by: Frank Wunderlich <frank-w@public-files.de>
>
> regards Frank
>
>
>> Gesendet: Freitag, 23. August 2019 um 15:45 Uhr
>> Von: "René van Dorst" <opensource@vdorst.com>
>> An: "John Crispin" <john@phrozen.org>, "Sean Wang"
>> <sean.wang@mediatek.com>, "Nelson Chang"
>> <nelson.chang@mediatek.com>, "David S . Miller"
>> <davem@davemloft.net>, "Matthias Brugger" <matthias.bgg@gmail.com>
>> Cc: netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
>> linux-mediatek@lists.infradead.org, linux-mips@vger.kernel.org,
>> "Russell King" <linux@armlinux.org.uk>, "Frank Wunderlich"
>> <frank-w@public-files.de>, "Stefan Roese" <sr@denx.de>, "René van
>> Dorst" <opensource@vdorst.com>
>> Betreff: [PATCH net-next v3 0/3] net: ethernet: mediatek: convert to PHYLINK
>>
>> These patches converts mediatek driver to PHYLINK API.
>>
>> v2->v3:
>> * Phylink improvements and clean-ups after review
>> v1->v2:
>> * Rebase for mt76x8 changes
>> * Phylink improvements and clean-ups after review
>> * SGMII port doesn't support 2.5Gbit in SGMII mode only in BASE-X mode.
>> Refactor the code.
>>
>> René van Dorst (3):
>> net: ethernet: mediatek: Add basic PHYLINK support
>> net: ethernet: mediatek: Re-add support SGMII
>> dt-bindings: net: ethernet: Update mt7622 docs and dts to reflect the
>> new phylink API
>>
>> .../arm/mediatek/mediatek,sgmiisys.txt | 2 -
>> .../dts/mediatek/mt7622-bananapi-bpi-r64.dts | 28 +-
>> arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 -
>> drivers/net/ethernet/mediatek/Kconfig | 2 +-
>> drivers/net/ethernet/mediatek/mtk_eth_path.c | 75 +--
>> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 529 ++++++++++++------
>> drivers/net/ethernet/mediatek/mtk_eth_soc.h | 68 ++-
>> drivers/net/ethernet/mediatek/mtk_sgmii.c | 65 ++-
>> 8 files changed, 477 insertions(+), 293 deletions(-)
>>
>> --
>> 2.20.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/3] pwm: bcm2835: fix period_ns range check
From: Stefan Wahren @ 2019-08-24 7:07 UTC (permalink / raw)
To: Thierry Reding, Eric Anholt, Florian Fainelli, Ray Jui,
Scott Branden
Cc: linux-pwm, Stefan Wahren, linux-arm-kernel
In-Reply-To: <1566630445-4599-1-git-send-email-wahrenst@gmx.net>
The range check for period_ns was written under assumption of a fixed
PWM clock. With clk-bcm2835 driver the PWM clock is a dynamic one.
So fix this by doing the range check on the period register value.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
---
drivers/pwm/pwm-bcm2835.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
index 5276306..2c82386 100644
--- a/drivers/pwm/pwm-bcm2835.c
+++ b/drivers/pwm/pwm-bcm2835.c
@@ -21,7 +21,7 @@
#define PERIOD(x) (((x) * 0x10) + 0x10)
#define DUTY(x) (((x) * 0x10) + 0x14)
-#define MIN_PERIOD 108 /* 9.2 MHz max. PWM clock */
+#define PERIOD_MIN 0x2
struct bcm2835_pwm {
struct pwm_chip chip;
@@ -64,6 +64,7 @@ static int bcm2835_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
struct bcm2835_pwm *pc = to_bcm2835_pwm(chip);
unsigned long rate = clk_get_rate(pc->clk);
unsigned long scaler;
+ u32 period;
if (!rate) {
dev_err(pc->dev, "failed to get clock rate\n");
@@ -71,14 +72,14 @@ static int bcm2835_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
}
scaler = DIV_ROUND_CLOSEST(NSEC_PER_SEC, rate);
+ period = DIV_ROUND_CLOSEST(period_ns, scaler);
- if (period_ns <= MIN_PERIOD)
+ if (period < PERIOD_MIN)
return -EINVAL;
writel(DIV_ROUND_CLOSEST(duty_ns, scaler),
pc->base + DUTY(pwm->hwpwm));
- writel(DIV_ROUND_CLOSEST(period_ns, scaler),
- pc->base + PERIOD(pwm->hwpwm));
+ writel(period, pc->base + PERIOD(pwm->hwpwm));
return 0;
}
--
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 1/3] pwm: bcm2835: suppress error message for invalid period_ns
From: Stefan Wahren @ 2019-08-24 7:07 UTC (permalink / raw)
To: Thierry Reding, Eric Anholt, Florian Fainelli, Ray Jui,
Scott Branden
Cc: linux-pwm, Stefan Wahren, linux-arm-kernel
In-Reply-To: <1566630445-4599-1-git-send-email-wahrenst@gmx.net>
The PWM config can be triggered via sysfs, so we better suppress the
error message in case of an invalid period to avoid kernel log spamming.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
---
drivers/pwm/pwm-bcm2835.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
index f6fe0b9..5276306 100644
--- a/drivers/pwm/pwm-bcm2835.c
+++ b/drivers/pwm/pwm-bcm2835.c
@@ -72,11 +72,8 @@ static int bcm2835_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
scaler = DIV_ROUND_CLOSEST(NSEC_PER_SEC, rate);
- if (period_ns <= MIN_PERIOD) {
- dev_err(pc->dev, "period %d not supported, minimum %d\n",
- period_ns, MIN_PERIOD);
+ if (period_ns <= MIN_PERIOD)
return -EINVAL;
- }
writel(DIV_ROUND_CLOSEST(duty_ns, scaler),
pc->base + DUTY(pwm->hwpwm));
--
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 3/3] pwm: bcm2835: suppress error message during deferred probe
From: Stefan Wahren @ 2019-08-24 7:07 UTC (permalink / raw)
To: Thierry Reding, Eric Anholt, Florian Fainelli, Ray Jui,
Scott Branden
Cc: linux-pwm, Stefan Wahren, linux-arm-kernel
In-Reply-To: <1566630445-4599-1-git-send-email-wahrenst@gmx.net>
This suppresses error messages in case the PWM clock isn't ready yet.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
---
drivers/pwm/pwm-bcm2835.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
index 2c82386..ce362be 100644
--- a/drivers/pwm/pwm-bcm2835.c
+++ b/drivers/pwm/pwm-bcm2835.c
@@ -153,7 +153,10 @@ static int bcm2835_pwm_probe(struct platform_device *pdev)
pc->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(pc->clk)) {
- dev_err(&pdev->dev, "clock not found: %ld\n", PTR_ERR(pc->clk));
+ if (PTR_ERR(pc->clk) != -EPROBE_DEFER) {
+ dev_err(&pdev->dev, "clock not found: %ld\n",
+ PTR_ERR(pc->clk));
+ }
return PTR_ERR(pc->clk);
}
--
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 0/3] pwm: bcm2835: Minor fixes
From: Stefan Wahren @ 2019-08-24 7:07 UTC (permalink / raw)
To: Thierry Reding, Eric Anholt, Florian Fainelli, Ray Jui,
Scott Branden
Cc: linux-pwm, Stefan Wahren, linux-arm-kernel
This small patch series contains minor fixes for clock handling and the
period range check.
Stefan Wahren (3):
pwm: bcm2835: suppress error message for invalid period_ns
pwm: bcm2835: fix period_ns range check
pwm: bcm2835: suppress error message during deferred probe
drivers/pwm/pwm-bcm2835.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
--
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
* Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode support for ls1088a and ls2088a
From: christophe leroy @ 2019-08-24 6:45 UTC (permalink / raw)
To: Xiaowei Bao, Andrew Murray
Cc: mark.rutland@arm.com, Roy Zang, bhelgaas@google.com,
lorenzo.pieralisi@arm.co, arnd@arndb.de,
devicetree@vger.kernel.org, gregkh@linuxfoundation.org, Leo Li,
linux-kernel@vger.kernel.org, kishon@ti.com, M.h. Lian,
robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-pci@vger.kernel.org, jingoohan1@gmail.com,
shawnguo@kernel.org, gustavo.pimentel@synopsys.com,
linuxppc-dev@lists.ozlabs.org, Mingkai Hu
In-Reply-To: <AM5PR04MB32990473D4AD65354B5B2235F5A70@AM5PR04MB3299.eurprd04.prod.outlook.com>
Le 24/08/2019 à 02:18, Xiaowei Bao a écrit :
>
>
>> -----Original Message-----
>> From: Andrew Murray <andrew.murray@arm.com>
>> Sent: 2019年8月23日 22:28
>> To: Xiaowei Bao <xiaowei.bao@nxp.com>
>> Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
>> shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
>> lorenzo.pieralisi@arm.co; arnd@arndb.de; gregkh@linuxfoundation.org; M.h.
>> Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
>> Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
>> gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
>> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
>> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
>> Subject: Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode support for
>> ls1088a and ls2088a
>>
>> On Thu, Aug 22, 2019 at 07:22:40PM +0800, Xiaowei Bao wrote:
>>> Add PCIe EP mode support for ls1088a and ls2088a, there are some
>>> difference between LS1 and LS2 platform, so refactor the code of the
>>> EP driver.
>>>
>>> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
>>> ---
>>> v2:
>>> - New mechanism for layerscape EP driver.
>>
>> Was there a v1 of this patch?
>
> Yes, but I don't know how to comments, ^_^
As far as I can see, in the previous version of the series
(https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=125315&state=*),
the 8/10 was something completely different, and I can't find any other
patch in the series that could have been the v1 of this patch.
Christophe
>
>>
>>>
>>> drivers/pci/controller/dwc/pci-layerscape-ep.c | 76
>>> ++++++++++++++++++++------
>>> 1 file changed, 58 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
>>> b/drivers/pci/controller/dwc/pci-layerscape-ep.c
>>> index 7ca5fe8..2a66f07 100644
>>> --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
>>> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
>>> @@ -20,27 +20,29 @@
>>>
>>> #define PCIE_DBI2_OFFSET 0x1000 /* DBI2 base address*/
>>>
>>> -struct ls_pcie_ep {
>>> - struct dw_pcie *pci;
>>> - struct pci_epc_features *ls_epc;
>>> +#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
>>> +
>>> +struct ls_pcie_ep_drvdata {
>>> + u32 func_offset;
>>> + const struct dw_pcie_ep_ops *ops;
>>> + const struct dw_pcie_ops *dw_pcie_ops;
>>> };
>>>
>>> -#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
>>> +struct ls_pcie_ep {
>>> + struct dw_pcie *pci;
>>> + struct pci_epc_features *ls_epc;
>>> + const struct ls_pcie_ep_drvdata *drvdata; };
>>>
>>> static int ls_pcie_establish_link(struct dw_pcie *pci) {
>>> return 0;
>>> }
>>>
>>> -static const struct dw_pcie_ops ls_pcie_ep_ops = {
>>> +static const struct dw_pcie_ops dw_ls_pcie_ep_ops = {
>>> .start_link = ls_pcie_establish_link, };
>>>
>>> -static const struct of_device_id ls_pcie_ep_of_match[] = {
>>> - { .compatible = "fsl,ls-pcie-ep",},
>>> - { },
>>> -};
>>> -
>>> static const struct pci_epc_features* ls_pcie_ep_get_features(struct
>>> dw_pcie_ep *ep) { @@ -82,10 +84,44 @@ static int
>>> ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
>>> }
>>> }
>>>
>>> -static const struct dw_pcie_ep_ops pcie_ep_ops = {
>>> +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep *ep,
>>> + u8 func_no)
>>> +{
>>> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
>>> + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
>>> + u8 header_type;
>>> +
>>> + header_type = ioread8(pci->dbi_base + PCI_HEADER_TYPE);
>>> +
>>> + if (header_type & (1 << 7))
>>> + return pcie->drvdata->func_offset * func_no;
>>> + else
>>> + return 0;
>>
>> It looks like there isn't a PCI define for multi function, the nearest I could find
>> was PCI_HEADER_TYPE_MULTIDEVICE in hotplug/ibmphp.h. A comment
>> above the test might be helpful to explain the test.
>
> Yes, I have not find the PCI_HEADER_TYPE_MULTIDEVICE define. OK, I will add
> The comments in next version patch.
>
>>
>> As the ls_pcie_ep_drvdata structures are static, the unset .func_offset will be
>> initialised to 0, so you could just drop the test above.
>
> OK, thanks
>
>>
>> However something to the effect of the following may help spot
>> misconfiguration:
>>
>> WARN_ON(func_no && !pcie->drvdata->func_offset); return
>> pcie->drvdata->func_offset * func_no;
>
> Thanks a lot, this looks better.
>
>>
>> The WARN is probably quite useful as if you are attempting to use non-zero
>> functions and func_offset isn't set - then things may appear to work normally
>> but actually will break horribly.
>
> got it, thanks.
>
>>
>> Thanks,
>>
>> Andrew Murray
>>
>>> +}
>>> +
>>> +static const struct dw_pcie_ep_ops ls_pcie_ep_ops = {
>>> .ep_init = ls_pcie_ep_init,
>>> .raise_irq = ls_pcie_ep_raise_irq,
>>> .get_features = ls_pcie_ep_get_features,
>>> + .func_conf_select = ls_pcie_ep_func_conf_select, };
>>> +
>>> +static const struct ls_pcie_ep_drvdata ls1_ep_drvdata = {
>>> + .ops = &ls_pcie_ep_ops,
>>> + .dw_pcie_ops = &dw_ls_pcie_ep_ops,
>>> +};
>>> +
>>> +static const struct ls_pcie_ep_drvdata ls2_ep_drvdata = {
>>> + .func_offset = 0x20000,
>>> + .ops = &ls_pcie_ep_ops,
>>> + .dw_pcie_ops = &dw_ls_pcie_ep_ops,
>>> +};
>>> +
>>> +static const struct of_device_id ls_pcie_ep_of_match[] = {
>>> + { .compatible = "fsl,ls1046a-pcie-ep", .data = &ls1_ep_drvdata },
>>> + { .compatible = "fsl,ls1088a-pcie-ep", .data = &ls2_ep_drvdata },
>>> + { .compatible = "fsl,ls2088a-pcie-ep", .data = &ls2_ep_drvdata },
>>> + { },
>>> };
>>>
>>> static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie, @@ -98,7
>>> +134,7 @@ static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
>>> int ret;
>>>
>>> ep = &pci->ep;
>>> - ep->ops = &pcie_ep_ops;
>>> + ep->ops = pcie->drvdata->ops;
>>>
>>> res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>> "addr_space");
>>> if (!res)
>>> @@ -137,14 +173,11 @@ static int __init ls_pcie_ep_probe(struct
>> platform_device *pdev)
>>> if (!ls_epc)
>>> return -ENOMEM;
>>>
>>> - dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>> "regs");
>>> - pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
>>> - if (IS_ERR(pci->dbi_base))
>>> - return PTR_ERR(pci->dbi_base);
>>> + pcie->drvdata = of_device_get_match_data(dev);
>>>
>>> - pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
>>> pci->dev = dev;
>>> - pci->ops = &ls_pcie_ep_ops;
>>> + pci->ops = pcie->drvdata->dw_pcie_ops;
>>> +
>>> pcie->pci = pci;
>>>
>>> ls_epc->linkup_notifier = false,
>>> @@ -152,6 +185,13 @@ static int __init ls_pcie_ep_probe(struct
>>> platform_device *pdev)
>>>
>>> pcie->ls_epc = ls_epc;
>>>
>>> + dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>> "regs");
>>> + pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
>>> + if (IS_ERR(pci->dbi_base))
>>> + return PTR_ERR(pci->dbi_base);
>>> +
>>> + pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
>>> +
>>> platform_set_drvdata(pdev, pcie);
>>>
>>> ret = ls_add_pcie_ep(pcie, pdev);
>>> --
>>> 2.9.5
>>>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] mmc: bcm2835: Take SWIOTLB memory size limitation into account
From: Stefan Wahren @ 2019-08-24 6:31 UTC (permalink / raw)
To: Ulf Hansson, Eric Anholt, Florian Fainelli, Ray Jui,
Scott Branden, Lukas Wunner
Cc: linux-mmc, Stefan Wahren, linux-arm-kernel
Make sure the sdhost driver doesn't use requests bigger than SWIOTLB
can handle.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
---
drivers/mmc/host/bcm2835.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/bcm2835.c b/drivers/mmc/host/bcm2835.c
index 7e0d3a4..7ec0d95 100644
--- a/drivers/mmc/host/bcm2835.c
+++ b/drivers/mmc/host/bcm2835.c
@@ -1314,7 +1314,7 @@ static int bcm2835_add_host(struct bcm2835_host *host)
}
mmc->max_segs = 128;
- mmc->max_req_size = 524288;
+ mmc->max_req_size = min_t(size_t, 524288, dma_max_mapping_size(dev));
mmc->max_seg_size = mmc->max_req_size;
mmc->max_blk_size = 1024;
mmc->max_blk_count = 65535;
--
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
* Re: [PATCH v2] i2c: mediatek: disable zero-length transfers for mt8183
From: Qii Wang @ 2019-08-24 3:23 UTC (permalink / raw)
To: Hsin-Yi Wang
Cc: Nicolas Boichat, Alexandru M Stan, Wolfram Sang, Jun Gao, lkml,
linux-mediatek, linux-i2c, Matthias Brugger, Yingjoe Chen,
Thomas Gleixner,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAJMQK-gb+A9dwyMqMcA5yaaXak9no8_=urwK0XbLnNAEGyZ_hg@mail.gmail.com>
On Fri, 2019-08-23 at 16:13 +0800, Hsin-Yi Wang wrote:
> On Fri, Aug 23, 2019 at 4:09 PM Qii Wang <qii.wang@mediatek.com> wrote:
>
> > >
> > > static u32 mtk_i2c_functionality(struct i2c_adapter *adap)
> > > {
> > > - return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
> > > + if (adap->quirks->flags & I2C_AQ_NO_ZERO_LEN)
> > > + return I2C_FUNC_I2C |
> > > + (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK);
> > > + else
> > > + return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
> >
> > It can be removed?
> See previous discussion: https://patchwork.kernel.org/patch/10814391/#22484435
> but not all SoC's quirks has I2C_AQ_NO_ZERO_LEN.
ok, it looks good for me, thanks.
Reviewed-by: Qii Wang <qii.wang@mediatek.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v11 19/23] memory: mtk-smi: Invoke pm runtime_callback to enable clocks
From: Yong Wu @ 2019-08-24 3:02 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: <1566615728-26388-1-git-send-email-yong.wu@mediatek.com>
This patch only move the clk_prepare_enable and config_port into the
runtime suspend/resume callback. It doesn't change the code content
and sequence.
This is a preparing patch for adjusting SMI_BUS_SEL for mt8183.
(SMI_BUS_SEL need to be restored after smi-common resume every time.)
Also it gives a chance to get rid of mtk_smi_larb_get/put which could
be a next topic.
CC: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/memory/mtk-smi.c | 113 ++++++++++++++++++++++++++++++-----------------
1 file changed, 72 insertions(+), 41 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 3dd05de..2bb55b86 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -78,17 +78,13 @@ struct mtk_smi_larb { /* larb: local arbiter */
u32 *mmu;
};
-static int mtk_smi_enable(const struct mtk_smi *smi)
+static int mtk_smi_clk_enable(const struct mtk_smi *smi)
{
int ret;
- ret = pm_runtime_get_sync(smi->dev);
- if (ret < 0)
- return ret;
-
ret = clk_prepare_enable(smi->clk_apb);
if (ret)
- goto err_put_pm;
+ return ret;
ret = clk_prepare_enable(smi->clk_smi);
if (ret)
@@ -110,59 +106,28 @@ static int mtk_smi_enable(const struct mtk_smi *smi)
clk_disable_unprepare(smi->clk_smi);
err_disable_apb:
clk_disable_unprepare(smi->clk_apb);
-err_put_pm:
- pm_runtime_put_sync(smi->dev);
return ret;
}
-static void mtk_smi_disable(const struct mtk_smi *smi)
+static void mtk_smi_clk_disable(const struct mtk_smi *smi)
{
clk_disable_unprepare(smi->clk_gals1);
clk_disable_unprepare(smi->clk_gals0);
clk_disable_unprepare(smi->clk_smi);
clk_disable_unprepare(smi->clk_apb);
- pm_runtime_put_sync(smi->dev);
}
int mtk_smi_larb_get(struct device *larbdev)
{
- struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
- const struct mtk_smi_larb_gen *larb_gen = larb->larb_gen;
- struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
- int ret;
+ int ret = pm_runtime_get_sync(larbdev);
- /* Enable the smi-common's power and clocks */
- ret = mtk_smi_enable(common);
- if (ret)
- return ret;
-
- /* Enable the larb's power and clocks */
- ret = mtk_smi_enable(&larb->smi);
- if (ret) {
- mtk_smi_disable(common);
- return ret;
- }
-
- /* Configure the iommu info for this larb */
- larb_gen->config_port(larbdev);
-
- return 0;
+ return (ret < 0) ? ret : 0;
}
EXPORT_SYMBOL_GPL(mtk_smi_larb_get);
void mtk_smi_larb_put(struct device *larbdev)
{
- struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
- struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
-
- /*
- * Don't de-configure the iommu info for this larb since there may be
- * several modules in this larb.
- * The iommu info will be reset after power off.
- */
-
- mtk_smi_disable(&larb->smi);
- mtk_smi_disable(common);
+ pm_runtime_put_sync(larbdev);
}
EXPORT_SYMBOL_GPL(mtk_smi_larb_put);
@@ -377,12 +342,52 @@ static int mtk_smi_larb_remove(struct platform_device *pdev)
return 0;
}
+static int __maybe_unused mtk_smi_larb_resume(struct device *dev)
+{
+ struct mtk_smi_larb *larb = dev_get_drvdata(dev);
+ const struct mtk_smi_larb_gen *larb_gen = larb->larb_gen;
+ int ret;
+
+ /* Power on smi-common. */
+ ret = pm_runtime_get_sync(larb->smi_common_dev);
+ if (ret < 0) {
+ dev_err(dev, "Failed to pm get for smi-common(%d).\n", ret);
+ return ret;
+ }
+
+ ret = mtk_smi_clk_enable(&larb->smi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to enable clock(%d).\n", ret);
+ pm_runtime_put_sync(larb->smi_common_dev);
+ return ret;
+ }
+
+ /* Configure the basic setting for this larb */
+ larb_gen->config_port(dev);
+
+ return 0;
+}
+
+static int __maybe_unused mtk_smi_larb_suspend(struct device *dev)
+{
+ struct mtk_smi_larb *larb = dev_get_drvdata(dev);
+
+ mtk_smi_clk_disable(&larb->smi);
+ pm_runtime_put_sync(larb->smi_common_dev);
+ return 0;
+}
+
+static const struct dev_pm_ops smi_larb_pm_ops = {
+ SET_RUNTIME_PM_OPS(mtk_smi_larb_suspend, mtk_smi_larb_resume, NULL)
+};
+
static struct platform_driver mtk_smi_larb_driver = {
.probe = mtk_smi_larb_probe,
.remove = mtk_smi_larb_remove,
.driver = {
.name = "mtk-smi-larb",
.of_match_table = mtk_smi_larb_of_ids,
+ .pm = &smi_larb_pm_ops,
}
};
@@ -481,12 +486,38 @@ static int mtk_smi_common_remove(struct platform_device *pdev)
return 0;
}
+static int __maybe_unused mtk_smi_common_resume(struct device *dev)
+{
+ struct mtk_smi *common = dev_get_drvdata(dev);
+ int ret;
+
+ ret = mtk_smi_clk_enable(common);
+ if (ret) {
+ dev_err(common->dev, "Failed to enable clock(%d).\n", ret);
+ return ret;
+ }
+ return 0;
+}
+
+static int __maybe_unused mtk_smi_common_suspend(struct device *dev)
+{
+ struct mtk_smi *common = dev_get_drvdata(dev);
+
+ mtk_smi_clk_disable(common);
+ return 0;
+}
+
+static const struct dev_pm_ops smi_common_pm_ops = {
+ SET_RUNTIME_PM_OPS(mtk_smi_common_suspend, mtk_smi_common_resume, NULL)
+};
+
static struct platform_driver mtk_smi_common_driver = {
.probe = mtk_smi_common_probe,
.remove = mtk_smi_common_remove,
.driver = {
.name = "mtk-smi-common",
.of_match_table = mtk_smi_common_of_ids,
+ .pm = &smi_common_pm_ops,
}
};
--
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
* [PATCH v11 22/23] memory: mtk-smi: Get rid of need_larbid
From: Yong Wu @ 2019-08-24 3:02 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: <1566615728-26388-1-git-send-email-yong.wu@mediatek.com>
The "mediatek,larb-id" has already been parsed in MTK IOMMU driver.
It's no need to parse it again in SMI driver. Only clean some codes.
This patch is fit for all the current mt2701, mt2712, mt7623, mt8173
and mt8183.
After this patch, the "mediatek,larb-id" only be needed for mt2712
which have 2 M4Us. In the other SoCs, we can get the larb-id from M4U
in which the larbs in the "mediatek,larbs" always are ordered.
Correspondingly, the larb_nr in the "struct mtk_smi_iommu" could also
be deleted.
CC: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/iommu/mtk_iommu.c | 1 -
drivers/iommu/mtk_iommu_v1.c | 2 --
drivers/memory/mtk-smi.c | 26 ++------------------------
include/soc/mediatek/smi.h | 1 -
4 files changed, 2 insertions(+), 28 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 5d5341c..cc81de2 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -656,7 +656,6 @@ static int mtk_iommu_probe(struct platform_device *pdev)
"mediatek,larbs", NULL);
if (larb_nr < 0)
return larb_nr;
- data->smi_imu.larb_nr = larb_nr;
for (i = 0; i < larb_nr; i++) {
struct device_node *larbnode;
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index abeeac4..3922358 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -616,8 +616,6 @@ static int mtk_iommu_probe(struct platform_device *pdev)
larb_nr++;
}
- data->smi_imu.larb_nr = larb_nr;
-
platform_set_drvdata(pdev, data);
ret = mtk_iommu_hw_init(data);
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 289e595..d6dc62f 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -59,7 +59,6 @@ struct mtk_smi_common_plat {
};
struct mtk_smi_larb_gen {
- bool need_larbid;
int port_in_larb[MTK_LARB_NR_MAX + 1];
void (*config_port)(struct device *);
unsigned int larb_direct_to_common_mask;
@@ -147,18 +146,9 @@ void mtk_smi_larb_put(struct device *larbdev)
struct mtk_smi_iommu *smi_iommu = data;
unsigned int i;
- if (larb->larb_gen->need_larbid) {
- larb->mmu = &smi_iommu->larb_imu[larb->larbid].mmu;
- return 0;
- }
-
- /*
- * If there is no larbid property, Loop to find the corresponding
- * iommu information.
- */
- for (i = 0; i < smi_iommu->larb_nr; i++) {
+ for (i = 0; i < MTK_LARB_NR_MAX; i++) {
if (dev == smi_iommu->larb_imu[i].dev) {
- /* The 'mmu' may be updated in iommu-attach/detach. */
+ larb->larbid = i;
larb->mmu = &smi_iommu->larb_imu[i].mmu;
return 0;
}
@@ -237,7 +227,6 @@ static void mtk_smi_larb_config_port_gen1(struct device *dev)
};
static const struct mtk_smi_larb_gen mtk_smi_larb_mt2701 = {
- .need_larbid = true,
.port_in_larb = {
LARB0_PORT_OFFSET, LARB1_PORT_OFFSET,
LARB2_PORT_OFFSET, LARB3_PORT_OFFSET
@@ -246,7 +235,6 @@ static void mtk_smi_larb_config_port_gen1(struct device *dev)
};
static const struct mtk_smi_larb_gen mtk_smi_larb_mt2712 = {
- .need_larbid = true,
.config_port = mtk_smi_larb_config_port_gen2_general,
.larb_direct_to_common_mask = BIT(8) | BIT(9), /* bdpsys */
};
@@ -285,7 +273,6 @@ static int mtk_smi_larb_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct device_node *smi_node;
struct platform_device *smi_pdev;
- int err;
larb = devm_kzalloc(dev, sizeof(*larb), GFP_KERNEL);
if (!larb)
@@ -315,15 +302,6 @@ static int mtk_smi_larb_probe(struct platform_device *pdev)
}
larb->smi.dev = dev;
- if (larb->larb_gen->need_larbid) {
- err = of_property_read_u32(dev->of_node, "mediatek,larb-id",
- &larb->larbid);
- if (err) {
- dev_err(dev, "missing larbid property\n");
- return err;
- }
- }
-
smi_node = of_parse_phandle(dev->of_node, "mediatek,smi", 0);
if (!smi_node)
return -EINVAL;
diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
index 79b74ce..6f0b00c 100644
--- a/include/soc/mediatek/smi.h
+++ b/include/soc/mediatek/smi.h
@@ -21,7 +21,6 @@ struct mtk_smi_larb_iommu {
};
struct mtk_smi_iommu {
- unsigned int larb_nr;
struct mtk_smi_larb_iommu larb_imu[MTK_LARB_NR_MAX];
};
--
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
* [PATCH v11 23/23] iommu/mediatek: Clean up struct mtk_smi_iommu
From: Yong Wu @ 2019-08-24 3:02 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: <1566615728-26388-1-git-send-email-yong.wu@mediatek.com>
Remove the "struct mtk_smi_iommu" to simplify the code since it has only
one item in it right now.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/iommu/mtk_iommu.c | 4 ++--
drivers/iommu/mtk_iommu.h | 6 +++---
drivers/iommu/mtk_iommu_v1.c | 4 ++--
drivers/memory/mtk-smi.c | 6 +++---
include/soc/mediatek/smi.h | 4 ----
5 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index cc81de2..400066d 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -278,7 +278,7 @@ static void mtk_iommu_config(struct mtk_iommu_data *data,
for (i = 0; i < fwspec->num_ids; ++i) {
larbid = MTK_M4U_TO_LARB(fwspec->ids[i]);
portid = MTK_M4U_TO_PORT(fwspec->ids[i]);
- larb_mmu = &data->smi_imu.larb_imu[larbid];
+ larb_mmu = &data->larb_imu[larbid];
dev_dbg(dev, "%s iommu port: %d\n",
enable ? "enable" : "disable", portid);
@@ -680,7 +680,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
of_node_put(larbnode);
return -EPROBE_DEFER;
}
- data->smi_imu.larb_imu[id].dev = &plarbdev->dev;
+ data->larb_imu[id].dev = &plarbdev->dev;
component_match_add_release(dev, &match, release_of,
compare_of, larbnode);
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 56b579c..fc0f16e 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -56,7 +56,6 @@ struct mtk_iommu_data {
struct mtk_iommu_suspend_reg reg;
struct mtk_iommu_domain *m4u_dom;
struct iommu_group *m4u_group;
- struct mtk_smi_iommu smi_imu; /* SMI larb iommu info */
bool enable_4GB;
bool tlb_flush_active;
@@ -64,6 +63,7 @@ struct mtk_iommu_data {
const struct mtk_iommu_plat_data *plat_data;
struct list_head list;
+ struct mtk_smi_larb_iommu larb_imu[MTK_LARB_NR_MAX];
};
static inline int compare_of(struct device *dev, void *data)
@@ -80,14 +80,14 @@ static inline int mtk_iommu_bind(struct device *dev)
{
struct mtk_iommu_data *data = dev_get_drvdata(dev);
- return component_bind_all(dev, &data->smi_imu);
+ return component_bind_all(dev, &data->larb_imu);
}
static inline void mtk_iommu_unbind(struct device *dev)
{
struct mtk_iommu_data *data = dev_get_drvdata(dev);
- component_unbind_all(dev, &data->smi_imu);
+ component_unbind_all(dev, &data->larb_imu);
}
#endif
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 3922358..860926c 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -206,7 +206,7 @@ static void mtk_iommu_config(struct mtk_iommu_data *data,
for (i = 0; i < fwspec->num_ids; ++i) {
larbid = mt2701_m4u_to_larb(fwspec->ids[i]);
portid = mt2701_m4u_to_port(fwspec->ids[i]);
- larb_mmu = &data->smi_imu.larb_imu[larbid];
+ larb_mmu = &data->larb_imu[larbid];
dev_dbg(dev, "%s iommu port: %d\n",
enable ? "enable" : "disable", portid);
@@ -610,7 +610,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
}
}
- data->smi_imu.larb_imu[larb_nr].dev = &plarbdev->dev;
+ data->larb_imu[larb_nr].dev = &plarbdev->dev;
component_match_add_release(dev, &match, release_of,
compare_of, larb_spec.np);
larb_nr++;
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index d6dc62f..439d7d8 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -143,13 +143,13 @@ void mtk_smi_larb_put(struct device *larbdev)
mtk_smi_larb_bind(struct device *dev, struct device *master, void *data)
{
struct mtk_smi_larb *larb = dev_get_drvdata(dev);
- struct mtk_smi_iommu *smi_iommu = data;
+ struct mtk_smi_larb_iommu *larb_mmu = data;
unsigned int i;
for (i = 0; i < MTK_LARB_NR_MAX; i++) {
- if (dev == smi_iommu->larb_imu[i].dev) {
+ if (dev == larb_mmu[i].dev) {
larb->larbid = i;
- larb->mmu = &smi_iommu->larb_imu[i].mmu;
+ larb->mmu = &larb_mmu[i].mmu;
return 0;
}
}
diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
index 6f0b00c..5a34b87 100644
--- a/include/soc/mediatek/smi.h
+++ b/include/soc/mediatek/smi.h
@@ -20,10 +20,6 @@ struct mtk_smi_larb_iommu {
unsigned int mmu;
};
-struct mtk_smi_iommu {
- struct mtk_smi_larb_iommu larb_imu[MTK_LARB_NR_MAX];
-};
-
/*
* mtk_smi_larb_get: Enable the power domain and clocks for this local arbiter.
* It also initialize some basic setting(like iommu).
--
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
* [PATCH v11 21/23] iommu/mediatek: Fix VLD_PA_RNG register backup when suspend
From: Yong Wu @ 2019-08-24 3:02 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: <1566615728-26388-1-git-send-email-yong.wu@mediatek.com>
The register VLD_PA_RNG(0x118) was forgot to backup while adding 4GB
mode support for mt2712. this patch add it.
Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
for 4GB mode")
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/iommu/mtk_iommu.c | 2 ++
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 470de8b..5d5341c 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -742,6 +742,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device *dev)
reg->int_control0 = readl_relaxed(base + REG_MMU_INT_CONTROL0);
reg->int_main_control = readl_relaxed(base + REG_MMU_INT_MAIN_CONTROL);
reg->ivrp_paddr = readl_relaxed(base + REG_MMU_IVRP_PADDR);
+ reg->vld_pa_rng = readl_relaxed(base + REG_MMU_VLD_PA_RNG);
clk_disable_unprepare(data->bclk);
return 0;
}
@@ -766,6 +767,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
writel_relaxed(reg->ivrp_paddr, base + REG_MMU_IVRP_PADDR);
+ writel_relaxed(reg->vld_pa_rng, base + REG_MMU_VLD_PA_RNG);
if (m4u_dom)
writel(m4u_dom->cfg.arm_v7s_cfg.ttbr[0] & MMU_PT_ADDR_MASK,
base + REG_MMU_PT_BASE_ADDR);
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 6b1f833..56b579c 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -24,6 +24,7 @@ struct mtk_iommu_suspend_reg {
u32 int_control0;
u32 int_main_control;
u32 ivrp_paddr;
+ u32 vld_pa_rng;
};
enum mtk_iommu_plat {
--
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
* [PATCH v11 20/23] memory: mtk-smi: Add bus_sel for mt8183
From: Yong Wu @ 2019-08-24 3:02 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: <1566615728-26388-1-git-send-email-yong.wu@mediatek.com>
There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
mmu0 or mmu1 to balance the bandwidth via the smi-common register
SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
In mt8183, For better performance, we switch larb1/2/5/7 to enter
mmu1 while the others still keep enter mmu0.
In mt8173 and mt2712, we don't get the performance issue,
Keep its default value(0x0), that means all the larbs enter mmu0.
Note: smi gen1(mt2701/mt7623) don't have this bus_sel.
And, the base of smi-common is completely different with smi_ao_base
of gen1, thus I add new variable for that.
CC: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/memory/mtk-smi.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 2bb55b86..289e595 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -41,6 +41,12 @@
#define SMI_LARB_NONSEC_CON(id) (0x380 + ((id) * 4))
#define F_MMU_EN BIT(0)
+/* SMI COMMON */
+#define SMI_BUS_SEL 0x220
+#define SMI_BUS_LARB_SHIFT(larbid) ((larbid) << 1)
+/* All are MMU0 defaultly. Only specialize mmu1 here. */
+#define F_MMU1_LARB(larbid) (0x1 << SMI_BUS_LARB_SHIFT(larbid))
+
enum mtk_smi_gen {
MTK_SMI_GEN1,
MTK_SMI_GEN2
@@ -49,6 +55,7 @@ enum mtk_smi_gen {
struct mtk_smi_common_plat {
enum mtk_smi_gen gen;
bool has_gals;
+ u32 bus_sel; /* Balance some larbs to enter mmu0 or mmu1 */
};
struct mtk_smi_larb_gen {
@@ -64,8 +71,10 @@ struct mtk_smi {
struct clk *clk_apb, *clk_smi;
struct clk *clk_gals0, *clk_gals1;
struct clk *clk_async; /*only needed by mt2701*/
- void __iomem *smi_ao_base;
-
+ union {
+ void __iomem *smi_ao_base; /* only for gen1 */
+ void __iomem *base; /* only for gen2 */
+ };
const struct mtk_smi_common_plat *plat;
};
@@ -402,6 +411,8 @@ static int __maybe_unused mtk_smi_larb_suspend(struct device *dev)
static const struct mtk_smi_common_plat mtk_smi_common_mt8183 = {
.gen = MTK_SMI_GEN2,
.has_gals = true,
+ .bus_sel = F_MMU1_LARB(1) | F_MMU1_LARB(2) | F_MMU1_LARB(5) |
+ F_MMU1_LARB(7),
};
static const struct of_device_id mtk_smi_common_of_ids[] = {
@@ -474,6 +485,11 @@ static int mtk_smi_common_probe(struct platform_device *pdev)
ret = clk_prepare_enable(common->clk_async);
if (ret)
return ret;
+ } else {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ common->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(common->base))
+ return PTR_ERR(common->base);
}
pm_runtime_enable(dev);
platform_set_drvdata(pdev, common);
@@ -489,6 +505,7 @@ static int mtk_smi_common_remove(struct platform_device *pdev)
static int __maybe_unused mtk_smi_common_resume(struct device *dev)
{
struct mtk_smi *common = dev_get_drvdata(dev);
+ u32 bus_sel = common->plat->bus_sel;
int ret;
ret = mtk_smi_clk_enable(common);
@@ -496,6 +513,9 @@ static int __maybe_unused mtk_smi_common_resume(struct device *dev)
dev_err(common->dev, "Failed to enable clock(%d).\n", ret);
return ret;
}
+
+ if (common->plat->gen == MTK_SMI_GEN2 && bus_sel)
+ writel(bus_sel, common->base + SMI_BUS_SEL);
return 0;
}
--
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
* [PATCH v11 18/23] iommu/mediatek: Add mmu1 support
From: Yong Wu @ 2019-08-24 3:02 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: <1566615728-26388-1-git-send-email-yong.wu@mediatek.com>
Normally the M4U HW connect EMI with smi. the diagram is like below:
EMI
|
M4U
|
smi-common
|
-----------------
| | | | ...
larb0 larb1 larb2 larb3
Actually there are 2 mmu cells in the M4U HW, like this diagram:
EMI
---------
| |
mmu0 mmu1 <- M4U
| |
---------
|
smi-common
|
-----------------
| | | | ...
larb0 larb1 larb2 larb3
This patch add support for mmu1. In order to get better performance,
we could adjust some larbs go to mmu1 while the others still go to
mmu0. This is controlled by a SMI COMMON register SMI_BUS_SEL(0x220).
mt2712, mt8173 and mt8183 M4U HW all have 2 mmu cells. the default
value of that register is 0 which means all the larbs go to mmu0
defaultly.
This is a preparing patch for adjusting SMI_BUS_SEL for mt8183.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/iommu/mtk_iommu.c | 46 +++++++++++++++++++++++++++++-----------------
1 file changed, 29 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index ee3a664..470de8b 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -64,26 +64,32 @@
#define F_INT_CLR_BIT BIT(12)
#define REG_MMU_INT_MAIN_CONTROL 0x124
-#define F_INT_TRANSLATION_FAULT BIT(0)
-#define F_INT_MAIN_MULTI_HIT_FAULT BIT(1)
-#define F_INT_INVALID_PA_FAULT BIT(2)
-#define F_INT_ENTRY_REPLACEMENT_FAULT BIT(3)
-#define F_INT_TLB_MISS_FAULT BIT(4)
-#define F_INT_MISS_TRANSACTION_FIFO_FAULT BIT(5)
-#define F_INT_PRETETCH_TRANSATION_FIFO_FAULT BIT(6)
+ /* mmu0 | mmu1 */
+#define F_INT_TRANSLATION_FAULT (BIT(0) | BIT(7))
+#define F_INT_MAIN_MULTI_HIT_FAULT (BIT(1) | BIT(8))
+#define F_INT_INVALID_PA_FAULT (BIT(2) | BIT(9))
+#define F_INT_ENTRY_REPLACEMENT_FAULT (BIT(3) | BIT(10))
+#define F_INT_TLB_MISS_FAULT (BIT(4) | BIT(11))
+#define F_INT_MISS_TRANSACTION_FIFO_FAULT (BIT(5) | BIT(12))
+#define F_INT_PRETETCH_TRANSATION_FIFO_FAULT (BIT(6) | BIT(13))
#define REG_MMU_CPE_DONE 0x12C
#define REG_MMU_FAULT_ST1 0x134
+#define F_REG_MMU0_FAULT_MASK GENMASK(6, 0)
+#define F_REG_MMU1_FAULT_MASK GENMASK(13, 7)
-#define REG_MMU_FAULT_VA 0x13c
+#define REG_MMU0_FAULT_VA 0x13c
#define F_MMU_FAULT_VA_WRITE_BIT BIT(1)
#define F_MMU_FAULT_VA_LAYER_BIT BIT(0)
-#define REG_MMU_INVLD_PA 0x140
-#define REG_MMU_INT_ID 0x150
-#define F_MMU0_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
-#define F_MMU0_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
+#define REG_MMU0_INVLD_PA 0x140
+#define REG_MMU1_FAULT_VA 0x144
+#define REG_MMU1_INVLD_PA 0x148
+#define REG_MMU0_INT_ID 0x150
+#define REG_MMU1_INT_ID 0x154
+#define F_MMU_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
+#define F_MMU_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
#define MTK_PROTECT_PA_ALIGN 128
@@ -226,13 +232,19 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
/* Read error info from registers */
int_state = readl_relaxed(data->base + REG_MMU_FAULT_ST1);
- fault_iova = readl_relaxed(data->base + REG_MMU_FAULT_VA);
+ if (int_state & F_REG_MMU0_FAULT_MASK) {
+ regval = readl_relaxed(data->base + REG_MMU0_INT_ID);
+ fault_iova = readl_relaxed(data->base + REG_MMU0_FAULT_VA);
+ fault_pa = readl_relaxed(data->base + REG_MMU0_INVLD_PA);
+ } else {
+ regval = readl_relaxed(data->base + REG_MMU1_INT_ID);
+ fault_iova = readl_relaxed(data->base + REG_MMU1_FAULT_VA);
+ fault_pa = readl_relaxed(data->base + REG_MMU1_INVLD_PA);
+ }
layer = fault_iova & F_MMU_FAULT_VA_LAYER_BIT;
write = fault_iova & F_MMU_FAULT_VA_WRITE_BIT;
- fault_pa = readl_relaxed(data->base + REG_MMU_INVLD_PA);
- regval = readl_relaxed(data->base + REG_MMU_INT_ID);
- fault_larb = F_MMU0_INT_ID_LARB_ID(regval);
- fault_port = F_MMU0_INT_ID_PORT_ID(regval);
+ fault_larb = F_MMU_INT_ID_LARB_ID(regval);
+ fault_port = F_MMU_INT_ID_PORT_ID(regval);
fault_larb = data->plat_data->larbid_remap[fault_larb];
--
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
* [PATCH v11 16/23] memory: mtk-smi: Add gals support
From: Yong Wu @ 2019-08-24 3:02 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: <1566615728-26388-1-git-send-email-yong.wu@mediatek.com>
In some SoCs like mt8183, SMI add GALS(Global Async Local Sync) module
which can help synchronize for the modules in different clock frequency.
It can be seen as a "asynchronous fifo". This is a example diagram:
M4U
|
----------
| |
gals0-rx gals1-rx
| |
| |
gals0-tx gals1-tx
| |
------------
SMI Common
------------
|
+-----+--------+-----+- ...
| | | |
| gals-rx gals-rx |
| | | |
| | | |
| gals-tx gals-tx |
| | | |
larb1 larb2 larb3 larb4
GALS only help transfer the command/data while it doesn't have the
configuring register, thus it has the special "smi" clock and 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.
This patch adds gals clock supporting in the SMI. Note that some larbs
may still don't have the "gals" clock like larb1 and larb4 above.
This is also a preparing patch for mt8183 which has GALS.
CC: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/memory/mtk-smi.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 47df7d0..53bd379 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -48,6 +48,7 @@ enum mtk_smi_gen {
struct mtk_smi_common_plat {
enum mtk_smi_gen gen;
+ bool has_gals;
};
struct mtk_smi_larb_gen {
@@ -55,11 +56,13 @@ struct mtk_smi_larb_gen {
int port_in_larb[MTK_LARB_NR_MAX + 1];
void (*config_port)(struct device *);
unsigned int larb_direct_to_common_mask;
+ bool has_gals;
};
struct mtk_smi {
struct device *dev;
struct clk *clk_apb, *clk_smi;
+ struct clk *clk_gals0, *clk_gals1;
struct clk *clk_async; /*only needed by mt2701*/
void __iomem *smi_ao_base;
@@ -91,8 +94,20 @@ static int mtk_smi_enable(const struct mtk_smi *smi)
if (ret)
goto err_disable_apb;
+ ret = clk_prepare_enable(smi->clk_gals0);
+ if (ret)
+ goto err_disable_smi;
+
+ ret = clk_prepare_enable(smi->clk_gals1);
+ if (ret)
+ goto err_disable_gals0;
+
return 0;
+err_disable_gals0:
+ clk_disable_unprepare(smi->clk_gals0);
+err_disable_smi:
+ clk_disable_unprepare(smi->clk_smi);
err_disable_apb:
clk_disable_unprepare(smi->clk_apb);
err_put_pm:
@@ -102,6 +117,8 @@ static int mtk_smi_enable(const struct mtk_smi *smi)
static void mtk_smi_disable(const struct mtk_smi *smi)
{
+ clk_disable_unprepare(smi->clk_gals1);
+ clk_disable_unprepare(smi->clk_gals0);
clk_disable_unprepare(smi->clk_smi);
clk_disable_unprepare(smi->clk_apb);
pm_runtime_put_sync(smi->dev);
@@ -302,6 +319,15 @@ static int mtk_smi_larb_probe(struct platform_device *pdev)
larb->smi.clk_smi = devm_clk_get(dev, "smi");
if (IS_ERR(larb->smi.clk_smi))
return PTR_ERR(larb->smi.clk_smi);
+
+ if (larb->larb_gen->has_gals) {
+ /* The larbs may still haven't gals even if the SoC support.*/
+ larb->smi.clk_gals0 = devm_clk_get(dev, "gals");
+ if (PTR_ERR(larb->smi.clk_gals0) == -ENOENT)
+ larb->smi.clk_gals0 = NULL;
+ else if (IS_ERR(larb->smi.clk_gals0))
+ return PTR_ERR(larb->smi.clk_gals0);
+ }
larb->smi.dev = dev;
if (larb->larb_gen->need_larbid) {
@@ -394,6 +420,16 @@ static int mtk_smi_common_probe(struct platform_device *pdev)
if (IS_ERR(common->clk_smi))
return PTR_ERR(common->clk_smi);
+ if (common->plat->has_gals) {
+ common->clk_gals0 = devm_clk_get(dev, "gals0");
+ if (IS_ERR(common->clk_gals0))
+ return PTR_ERR(common->clk_gals0);
+
+ common->clk_gals1 = devm_clk_get(dev, "gals1");
+ if (IS_ERR(common->clk_gals1))
+ return PTR_ERR(common->clk_gals1);
+ }
+
/*
* for mtk smi gen 1, we need to get the ao(always on) base to config
* m4u port, and we need to enable the aync clock for transform the smi
--
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
* [PATCH v11 14/23] iommu/mediatek: Move reset_axi into plat_data
From: Yong Wu @ 2019-08-24 3:01 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: <1566615728-26388-1-git-send-email-yong.wu@mediatek.com>
In mt8173 and mt8183, 0x48 is REG_MMU_STANDARD_AXI_MODE while it is
REG_MMU_CTRL in the other SoCs, and the bits meaning is completely
different with the REG_MMU_STANDARD_AXI_MODE.
This patch moves this property to plat_data, it's also a preparing
patch for mt8183.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/iommu/mtk_iommu.c | 4 ++--
drivers/iommu/mtk_iommu.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 947a8c6b8..b43f36a 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -577,8 +577,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
}
writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
- /* It's MISC control register whose default value is ok except mt8173.*/
- if (data->plat_data->m4u_plat == M4U_MT8173)
+ if (data->plat_data->reset_axi)
writel_relaxed(0, data->base + REG_MMU_STANDARD_AXI_MODE);
if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
@@ -774,6 +773,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
.m4u_plat = M4U_MT8173,
.has_4gb_mode = true,
.has_bclk = true,
+ .reset_axi = true,
.larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index d1a1d88..8d3b525 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -38,7 +38,7 @@ struct mtk_iommu_plat_data {
/* HW will use the EMI clock if there isn't the "bclk". */
bool has_bclk;
-
+ bool reset_axi;
unsigned char larbid_remap[MTK_LARB_NR_MAX];
};
--
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
* [PATCH v11 15/23] iommu/mediatek: Move vld_pa_rng into plat_data
From: Yong Wu @ 2019-08-24 3:02 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: <1566615728-26388-1-git-send-email-yong.wu@mediatek.com>
Both mt8173 and mt8183 don't have this vld_pa_rng(valid physical address
range) register while mt2712 have. Move it into the plat_data.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/iommu/mtk_iommu.c | 3 ++-
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index b43f36a..eaf6a23 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -567,7 +567,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
upper_32_bits(data->protect_base);
writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
- if (data->enable_4GB && data->plat_data->m4u_plat != M4U_MT8173) {
+ if (data->enable_4GB && data->plat_data->has_vld_pa_rng) {
/*
* If 4GB mode is enabled, the validate PA range is from
* 0x1_0000_0000 to 0x1_ffff_ffff. here record bit[32:30].
@@ -766,6 +766,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
.m4u_plat = M4U_MT2712,
.has_4gb_mode = true,
.has_bclk = true,
+ .has_vld_pa_rng = true,
.larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 8d3b525..973d6e0 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -38,6 +38,7 @@ struct mtk_iommu_plat_data {
/* HW will use the EMI clock if there isn't the "bclk". */
bool has_bclk;
+ bool has_vld_pa_rng;
bool reset_axi;
unsigned char larbid_remap[MTK_LARB_NR_MAX];
};
--
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
* [PATCH v11 17/23] iommu/mediatek: Add mt8183 IOMMU support
From: Yong Wu @ 2019-08-24 3:02 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: <1566615728-26388-1-git-send-email-yong.wu@mediatek.com>
The M4U IP blocks in mt8183 is MediaTek's generation2 M4U which use
the ARM Short-descriptor like mt8173, and most of the HW registers
are the same.
Here list main differences between mt8183 and mt8173/mt2712:
1) mt8183 has only one M4U HW like mt8173 while mt2712 has two.
2) mt8183 don't have the "bclk" clock, it use the EMI clock instead.
3) mt8183 can support the dram over 4GB, but it doesn't call this "4GB
mode".
4) mt8183 pgtable base register(0x0) extend bit[1:0] which represent
the bit[33:32] in the physical address of the pgtable base, But the
standard ttbr0[1] means the S bit which is enabled defaultly, Hence,
we add a mask.
5) mt8183 HW has a GALS modules, SMI should enable "has_gals" support.
6) mt8183 need reset_axi like mt8173.
7) the larb-id in smi-common is remapped. M4U should add its larbid_remap.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/iommu/mtk_iommu.c | 15 ++++++++++++---
drivers/iommu/mtk_iommu.h | 1 +
drivers/memory/mtk-smi.c | 20 ++++++++++++++++++++
3 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index eaf6a23..ee3a664 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -28,6 +28,7 @@
#include "mtk_iommu.h"
#define REG_MMU_PT_BASE_ADDR 0x000
+#define MMU_PT_ADDR_MASK GENMASK(31, 7)
#define REG_MMU_INVALIDATE 0x020
#define F_ALL_INVLD 0x2
@@ -357,7 +358,7 @@ static int mtk_iommu_attach_device(struct iommu_domain *domain,
/* Update the pgtable base address register of the M4U HW */
if (!data->m4u_dom) {
data->m4u_dom = dom;
- writel(dom->cfg.arm_v7s_cfg.ttbr[0],
+ writel(dom->cfg.arm_v7s_cfg.ttbr[0] & MMU_PT_ADDR_MASK,
data->base + REG_MMU_PT_BASE_ADDR);
}
@@ -737,6 +738,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
{
struct mtk_iommu_data *data = dev_get_drvdata(dev);
struct mtk_iommu_suspend_reg *reg = &data->reg;
+ struct mtk_iommu_domain *m4u_dom = data->m4u_dom;
void __iomem *base = data->base;
int ret;
@@ -752,8 +754,8 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
writel_relaxed(reg->ivrp_paddr, base + REG_MMU_IVRP_PADDR);
- if (data->m4u_dom)
- writel(data->m4u_dom->cfg.arm_v7s_cfg.ttbr[0],
+ if (m4u_dom)
+ writel(m4u_dom->cfg.arm_v7s_cfg.ttbr[0] & MMU_PT_ADDR_MASK,
base + REG_MMU_PT_BASE_ADDR);
return 0;
}
@@ -778,9 +780,16 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
.larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
};
+static const struct mtk_iommu_plat_data mt8183_data = {
+ .m4u_plat = M4U_MT8183,
+ .reset_axi = true,
+ .larbid_remap = {0, 4, 5, 6, 7, 2, 3, 1},
+};
+
static const struct of_device_id mtk_iommu_of_ids[] = {
{ .compatible = "mediatek,mt2712-m4u", .data = &mt2712_data},
{ .compatible = "mediatek,mt8173-m4u", .data = &mt8173_data},
+ { .compatible = "mediatek,mt8183-m4u", .data = &mt8183_data},
{}
};
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 973d6e0..6b1f833 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -30,6 +30,7 @@ enum mtk_iommu_plat {
M4U_MT2701,
M4U_MT2712,
M4U_MT8173,
+ M4U_MT8183,
};
struct mtk_iommu_plat_data {
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 53bd379..3dd05de 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -277,6 +277,13 @@ static void mtk_smi_larb_config_port_gen1(struct device *dev)
.larb_direct_to_common_mask = BIT(8) | BIT(9), /* bdpsys */
};
+static const struct mtk_smi_larb_gen mtk_smi_larb_mt8183 = {
+ .has_gals = true,
+ .config_port = mtk_smi_larb_config_port_gen2_general,
+ .larb_direct_to_common_mask = BIT(2) | BIT(3) | BIT(7),
+ /* IPU0 | IPU1 | CCU */
+};
+
static const struct of_device_id mtk_smi_larb_of_ids[] = {
{
.compatible = "mediatek,mt8173-smi-larb",
@@ -290,6 +297,10 @@ static void mtk_smi_larb_config_port_gen1(struct device *dev)
.compatible = "mediatek,mt2712-smi-larb",
.data = &mtk_smi_larb_mt2712
},
+ {
+ .compatible = "mediatek,mt8183-smi-larb",
+ .data = &mtk_smi_larb_mt8183
+ },
{}
};
@@ -383,6 +394,11 @@ static int mtk_smi_larb_remove(struct platform_device *pdev)
.gen = MTK_SMI_GEN2,
};
+static const struct mtk_smi_common_plat mtk_smi_common_mt8183 = {
+ .gen = MTK_SMI_GEN2,
+ .has_gals = true,
+};
+
static const struct of_device_id mtk_smi_common_of_ids[] = {
{
.compatible = "mediatek,mt8173-smi-common",
@@ -396,6 +412,10 @@ static int mtk_smi_larb_remove(struct platform_device *pdev)
.compatible = "mediatek,mt2712-smi-common",
.data = &mtk_smi_common_gen2,
},
+ {
+ .compatible = "mediatek,mt8183-smi-common",
+ .data = &mtk_smi_common_mt8183,
+ },
{}
};
--
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
* [PATCH v11 12/23] iommu/mediatek: Add larb-id remapped support
From: Yong Wu @ 2019-08-24 3:01 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: <1566615728-26388-1-git-send-email-yong.wu@mediatek.com>
The larb-id may be remapped in the smi-common, this means the
larb-id reported in the mtk_iommu_isr isn't the real larb-id,
Take mt8183 as a example:
M4U
|
---------------------------------------------
| SMI common |
-0-----7-----5-----6-----1-----2------3-----4- <- Id remapped
| | | | | | | |
larb0 larb1 IPU0 IPU1 larb4 larb5 larb6 CCU
disp vdec img cam venc img cam
As above, larb0 connects with the id 0 in smi-common.
larb1 connects with the id 7 in smi-common.
...
If the larb-id reported in the isr is 7, actually it's larb1(vdec).
In order to output the right larb-id in the isr, we add a larb-id
remapping relationship in this patch.
If there is no this larb-id remapping in some SoCs, use the linear
mapping array instead.
This also is a preparing patch for mt8183.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/iommu/mtk_iommu.c | 4 ++++
drivers/iommu/mtk_iommu.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 4df3cb4..34f0203 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -236,6 +236,8 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
fault_larb = F_MMU0_INT_ID_LARB_ID(regval);
fault_port = F_MMU0_INT_ID_PORT_ID(regval);
+ fault_larb = data->plat_data->larbid_remap[fault_larb];
+
if (report_iommu_fault(&dom->domain, data->dev, fault_iova,
write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ)) {
dev_err_ratelimited(
@@ -766,12 +768,14 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
.m4u_plat = M4U_MT2712,
.has_4gb_mode = true,
.has_bclk = true,
+ .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
};
static const struct mtk_iommu_plat_data mt8173_data = {
.m4u_plat = M4U_MT8173,
.has_4gb_mode = true,
.has_bclk = true,
+ .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
};
static const struct of_device_id mtk_iommu_of_ids[] = {
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 821172b..d1a1d88 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -38,6 +38,8 @@ struct mtk_iommu_plat_data {
/* HW will use the EMI clock if there isn't the "bclk". */
bool has_bclk;
+
+ unsigned char larbid_remap[MTK_LARB_NR_MAX];
};
struct mtk_iommu_domain;
--
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
* [PATCH v11 13/23] iommu/mediatek: Refine protect memory definition
From: Yong Wu @ 2019-08-24 3:01 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: <1566615728-26388-1-git-send-email-yong.wu@mediatek.com>
The protect memory setting is a little different in the different SoCs.
In the register REG_MMU_CTRL_REG(0x110), the TF_PROT(translation fault
protect) shift bit is normally 4 while it shift 5 bits only in the
mt8173. This patch delete the complex MACRO and use a common if-else
instead.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/iommu/mtk_iommu.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 34f0203..947a8c6b8 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -44,12 +44,9 @@
#define REG_MMU_DCM_DIS 0x050
#define REG_MMU_CTRL_REG 0x110
+#define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4)
#define F_MMU_PREFETCH_RT_REPLACE_MOD BIT(4)
-#define F_MMU_TF_PROTECT_SEL_SHIFT(data) \
- ((data)->plat_data->m4u_plat == M4U_MT2712 ? 4 : 5)
-/* It's named by F_MMU_TF_PROT_SEL in mt2712. */
-#define F_MMU_TF_PROTECT_SEL(prot, data) \
- (((prot) & 0x3) << F_MMU_TF_PROTECT_SEL_SHIFT(data))
+#define F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173 (2 << 5)
#define REG_MMU_IVRP_PADDR 0x114
@@ -539,9 +536,11 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
return ret;
}
- regval = F_MMU_TF_PROTECT_SEL(2, data);
if (data->plat_data->m4u_plat == M4U_MT8173)
- regval |= F_MMU_PREFETCH_RT_REPLACE_MOD;
+ regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
+ F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
+ else
+ regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR;
writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
regval = F_L2_MULIT_HIT_EN |
--
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