* Re: [PATCH 2/2] arm64: dts: ti: k3-am654-base-board: Add MMC/SD support
From: Nishanth Menon @ 2018-12-08 15:54 UTC (permalink / raw)
To: Faiz Abbas
Cc: mark.rutland, devicetree, ulf.hansson, linux-kernel, kishon,
t-kristo, robh+dt, adrian.hunter, michal.simek, linux-arm-kernel
In-Reply-To: <20181207084233.13700-3-faiz_abbas@ti.com>
On 14:12-20181207, Faiz Abbas wrote:
> +
> +&sdhci0 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_mmc0_pins_default>;
> + bus-width = <8>;
> + non-removable;
> + ti,driver-strength-ohm = <50>;
^^
> +};
> +
> +&sdhci1 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_mmc1_pins_default>;
> + ti,driver-strength-ohm = <50>;
NAK.
$ git checkout next-20181207
$ git grep ti,driver-strength-ohm Documentation
$
Nada.. And.. I think "new phy binding" probably introduces this.
[1] https://patchwork.kernel.org/project/linux-mmc/list/?series=53185
If your patches are'nt really ready, please send them as RFC, I am not
really in a mood to track the status of every single driver subsystem.
If your binding is not in linux next at the baremin, as far as I am
concerned, this is not ready, and should be RFC.
--
Regards,
Nishanth Menon
_______________________________________________
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 1/2] arm64: dts: ti: k3-am654: Add Support for MMC/SD
From: Nishanth Menon @ 2018-12-08 15:45 UTC (permalink / raw)
To: Vignesh R
Cc: mark.rutland, devicetree, ulf.hansson, linux-kernel, robh+dt,
adrian.hunter, t-kristo, Faiz Abbas, kishon, michal.simek,
linux-arm-kernel
In-Reply-To: <a6aacd53-e1c4-fce0-7712-f276c80bbffc@ti.com>
On 10:56-20181208, Vignesh R wrote:
>
>
> On 07/12/18 2:12 PM, Faiz Abbas wrote:
> > There are two MMC host controller instances present on the TI's
> > Am654 SOCs. Add device tree nodes for the same.
> >
> > Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> > ---
> > arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 28 ++++++++++++++++++++++++
> > 1 file changed, 28 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> > index 916434839603..d07212f16a81 100644
> > --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> > +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> > @@ -129,4 +129,32 @@
> > clocks = <&k3_clks 113 1>;
> > power-domains = <&k3_pds 113>;
> > };
> > +
> > + sdhci0: sdhci@4f80000 {
> > + compatible = "ti,am654-sdhci-5.1";
> > + reg = <0x0 0x4f80000 0x0 0x260>, <0x0 0x4f90000 0x0 0x134>;
> > + power-domains = <&k3_pds 47>;
> > + clocks = <&k3_clks 47 0>, <&k3_clks 47 1>;
> > + clock-names = "clk_ahb", "clk_xin";
> > + interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
> > + sdhci-caps-mask = <0x80000007 0x0>;
> > + mmc-ddr-1_8v;
> > + ti,otap-del-sel = <0x2>;
> > + ti,trm-icp = <0x8>;
> > + status = "disabled";
> > + };
>
> Please drop "status=disabled" from dtsi. Can be disabled as required in
> the board dts.
yes - the standard in k3 is to disable the nodes that are'nt needed in
board.dtsi.
This is different from "disabled by default" approach in DRA7 or OMAP4
for example.
--
Regards,
Nishanth Menon
_______________________________________________
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 v6 8/8] mfd: axp20x: Add supported cells for AXP803
From: Quentin Schulz @ 2018-12-08 15:05 UTC (permalink / raw)
To: Lee Jones
Cc: Mark Rutland, devicetree, linux-pm, Maxime Ripard,
Sebastian Reichel, linux-kernel, Vasily Khoruzhick, Chen-Yu Tsai,
Rob Herring, Oskari Lemmela, arm-linux
In-Reply-To: <20181207192237.GK26661@dell>
[-- Attachment #1.1: Type: text/plain, Size: 2004 bytes --]
Hi Lee,
On Fri, Dec 07, 2018 at 07:22:37PM +0000, Lee Jones wrote:
> On Fri, 07 Dec 2018, Vasily Khoruzhick wrote:
>
> > On Fri, Dec 7, 2018 at 8:40 AM Lee Jones <lee.jones@linaro.org> wrote:
> >
> > > My OCD-dar is going crazy.
> > >
> > > Why haven't you used the same alignment as is already there?
> > >
> > > If it starts to run over 80-chars then bring the others back.
> > >
> > > Also why is there a single liner shoved in the middle of the
> > > multi-line entries? Please move the singles to the top or the
> > > bottom.
> >
> > Hi Lee,
> >
> > Could you please reformat it in the way that makes your OCD-dar happy?
> > It would be really nice to get
>
> I'm afraid not, for a multitude of reasons.
>
> The most important of which surround testing.
>
> > AC and battery support for APX8x3 merged -- it'll make Pinebook and
> > Teres-I pretty well supported by mainline kernel.
>
> That's great. A worthy cause indeed. So I'm sure you guys will want
> to turn the patch around in short order so that it's applied in time
> for the next merge window.
>
Aren't the MFD cells probed in order?
In that case, it makes little sense to short order them for this
particular device (X-Powers PMICs in general). It will just make the
system boot slower because of probe deferring.
Why? As explained by Chen-Yu in v3[1], axp-gpios can be muxed as
regulators, thus should be probed before axp-regulators. axp-adc is
often used by axp-battery, axp-usb-power, axp-ac-power, thus should be
probed beforehand as well.
For the alignment that also triggered your OCD, I can send you a patch
the day you merge this one if it can help. I sent a few patches for this
driver that didn't respect the alignment so I'm fine fixing the mfd
cells (and eventually re-order them as I saw a few axp-gpio cells being
declared after axp-regulators).
Does that make this patch OK for you, Lee?
Thanks,
Quentin
[1] https://lkml.org/lkml/2018/10/11/338
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* TK1: DRM, Nouveau and VIC
From: Marcel Ziswiler @ 2018-12-08 14:54 UTC (permalink / raw)
To: nouveau@lists.freedesktop.org, jonathanh@nvidia.com,
mperttunen@nvidia.com, bskeggs@redhat.com,
thierry.reding@gmail.com, dri-devel@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org, linux-tegra@vger.kernel.org
Hi Thierry et al.
I noticed that since commit 3dde5a2342cd ("ARM: tegra: Add VIC on
Tegra124") graphics on Apalis TK1 is broken. During boot it fails
loading the vic firmware:
[ 1.595824] tegra-vic 54340000.vic: Direct firmware load for
nvidia/tegra124/vic03_ucode.bin failed with error -2
[ 1.606140] tegra-vic: probe of 54340000.vic failed with error -2
Subsequently Tegra HDMI seems to fail completely:
[ 2.379860] tegra-hdmi 54280000.hdmi: failed to get PLL regulator
And finally, Nouveau even crashes:
[ 8.241115] nouveau 57000000.gpu: Linked as a consumer to
regulator.31
[ 8.247889] nouveau 57000000.gpu: NVIDIA GK20A (0ea000a1)
[ 8.253396] nouveau 57000000.gpu: imem: using IOMMU
[ 8.270210] Unable to handle kernel NULL pointer dereference at
virtual address 0000006c
[ 8.278340] pgd = (ptrval)
[ 8.281250] [0000006c] *pgd=00000000
[ 8.284944] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 8.290260] Modules linked in: nouveau(+) ttm
[ 8.294625] CPU: 2 PID: 203 Comm: systemd-udevd Not tainted 4.20.0-
rc5-next-20181207-00008-g85b0f8e25f86-dirty #110
[ 8.305055] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[ 8.311331] PC is at drm_plane_register_all+0x18/0x50
[ 8.316373] LR is at drm_modeset_register_all+0xc/0x70
[ 8.321513] pc : [<c056200c>] lr : [<c0564cc8>] psr: a0060013
[ 8.327768] sp : ed527c70 ip : ecc43ec0 fp : 00000000
[ 8.332993] r10: 00000016 r9 : ecc43e80 r8 : 00000000
[ 8.338209] r7 : bf182c80 r6 : 00000000 r5 : ed61b24c r4 :
fffffffc
[ 8.344735] r3 : 0002f000 r2 : ffffffff r1 : 2e124000 r0 :
ed61b000
[ 8.351260] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA
ARM Segment none
[ 8.358383] Control: 10c5387d Table: ad64c06a DAC: 00000051
[ 8.364127] Process systemd-udevd (pid: 203, stack limit =
0x(ptrval))
[ 8.370654] Stack: (0xed527c70 to 0xed528000)
[ 8.375004] 7c60: ed61b000
ed61b000 00000000 c0564cc8
[ 8.383177] 7c80: ed61b000 00000000 00000000 c054b5b8 00000001
00000001 ffffffff ffffffff
[ 8.391355] 7ca0: ed527cc0 c0f08c48 ed61b000 00000000 00000000
00000000 bf180c5c bf0dc900
[ 8.399531] 7cc0: eda29208 5dfe844b 00000000 ee9f2a10 00000000
bf180c5c 00000000 c05a9328
[ 8.407695] 7ce0: c1006828 ee9f2a10 c100682c 00000000 00000000
c05a744c ee9f2a10 bf180c5c
[ 8.415871] 7d00: ee9f2a44 c05a77a8 00000000 c0f08c48 bf182980
c05a769c eefd14d0 c05a77a8
[ 8.424048] 7d20: 00000000 ee9f2a10 bf180c5c ee9f2a44 c05a77a8
00000000 c0f08c48 bf182980
[ 8.432226] 7d40: 00000000 c05a7884 ee9ebfb4 c0f08c48 bf180c5c
c05a5790 00000000 ee88135c
[ 8.440405] 7d60: ee9ebfb4 5dfe844b c0f71168 bf180c5c ee379e80
c0f71168 00000000 c05a692c
[ 8.448570] 7d80: bf15dc00 bf180ac8 ffffe000 bf180c5c bf180ac8
ffffe000 bf1aa000 c05a84a0
[ 8.456746] 7da0: bf182b80 bf180ac8 ffffe000 bf1aa170 c0fbd220
c0f08c48 ffffe000 c0102ed0
[ 8.464924] 7dc0: ed53f4c0 006000c0 c01b3d98 0000000c 60000113
bf182980 00000040 c02592d0
[ 8.473102] 7de0: eda60200 2e124000 ee800000 006000c0 006000c0
c01b3d98 0000000c c025a8cc
[ 8.481281] 7e00: c024ce54 a0000113 bf182980 5dfe844b bf182980
00000002 ed53f4c0 00000002
[ 8.489459] 7e20: eceba000 c01b3dd4 c0f08c48 bf182980 00000000
ed527f40 00000002 eceb9fc0
[ 8.497625] 7e40: 00000002 c01b61a4 bf18298c 00007fff bf182980
c01b2f88 00000000 c01b279c
[ 8.505800] 7e60: bf1829c8 bf182a80 bf182b6c bf182ab0 c0b03ab0
c0d58964 c0ca726c c0ca7278
[ 8.513978] 7e80: c0ca72d0 c0f08c48 00000000 c02654a0 00000000
00000000 ffffe000 bf000000
[ 8.522157] 7ea0: 00000000 00000000 00000000 00000000 00000000
00000000 6e72656b 00006c65
[ 8.530336] 7ec0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 8.538502] 7ee0: 00000000 00000000 00000000 00000000 00000000
5dfe844b 7fffffff c0f08c48
[ 8.546677] 7f00: 00000000 0000000f b6f761cc c0101204 ed526000
0000017b 004a3270 c01b66a4
[ 8.554855] 7f20: 7fffffff 00000000 00000003 00000001 004a3270
f0ced000 06e8994c 00000000
[ 8.563032] 7f40: f0e37f3a f0e50a40 f0ced000 06e8994c f7b75f9c
f7b75d34 f63e62dc 0016b000
[ 8.571209] 7f60: 0017f6f0 00000000 00000000 00000000 00050a48
0000003b 0000003c 00000023
[ 8.579388] 7f80: 00000000 00000014 00000000 5dfe844b 00000000
004c0ec0 00000000 00000001
[ 8.587554] 7fa0: 0000017b c0101000 004c0ec0 00000000 0000000f
b6f761cc 00000000 00020000
[ 8.595730] 7fc0: 004c0ec0 00000000 00000001 0000017b 0048e114
00000000 00000000 004a3270
[ 8.603908] 7fe0: bea8f990 bea8f980 b6f71269 b6e9f6c0 400d0010
0000000f 00000000 00000000
[ 8.612096] [<c056200c>] (drm_plane_register_all) from [<c0564cc8>]
(drm_modeset_register_all+0xc/0x70)
[ 8.621499] [<c0564cc8>] (drm_modeset_register_all) from
[<c054b5b8>] (drm_dev_register+0x168/0x1c4)
[ 8.630855] [<c054b5b8>] (drm_dev_register) from [<bf0dc900>]
(nouveau_platform_probe+0x6c/0x88 [nouveau])
[ 8.640739] [<bf0dc900>] (nouveau_platform_probe [nouveau]) from
[<c05a9328>] (platform_drv_probe+0x48/0x98)
[ 8.650574] [<c05a9328>] (platform_drv_probe) from [<c05a744c>]
(really_probe+0x1e0/0x2cc)
[ 8.658827] [<c05a744c>] (really_probe) from [<c05a769c>]
(driver_probe_device+0x60/0x16c)
[ 8.667096] [<c05a769c>] (driver_probe_device) from [<c05a7884>]
(__driver_attach+0xdc/0xe0)
[ 8.675543] [<c05a7884>] (__driver_attach) from [<c05a5790>]
(bus_for_each_dev+0x74/0xb4)
[ 8.683729] [<c05a5790>] (bus_for_each_dev) from [<c05a692c>]
(bus_add_driver+0x1c0/0x204)
[ 8.692004] [<c05a692c>] (bus_add_driver) from [<c05a84a0>]
(driver_register+0x74/0x108)
[ 8.700324] [<c05a84a0>] (driver_register) from [<bf1aa170>]
(nouveau_drm_init+0x170/0x1000 [nouveau])
[ 8.709857] [<bf1aa170>] (nouveau_drm_init [nouveau]) from
[<c0102ed0>] (do_one_initcall+0x54/0x284)
[ 8.718980] [<c0102ed0>] (do_one_initcall) from [<c01b3dd4>]
(do_init_module+0x64/0x214)
[ 8.727079] [<c01b3dd4>] (do_init_module) from [<c01b61a4>]
(load_module+0x21b8/0x246c)
[ 8.735094] [<c01b61a4>] (load_module) from [<c01b66a4>]
(sys_finit_module+0xc4/0xdc)
[ 8.742937] [<c01b66a4>] (sys_finit_module) from [<c0101000>]
(ret_fast_syscall+0x0/0x54)
[ 8.751114] Exception stack(0xed527fa8 to 0xed527ff0)
[ 8.756157] 7fa0: 004c0ec0 00000000 0000000f
b6f761cc 00000000 00020000
[ 8.764333] 7fc0: 004c0ec0 00000000 00000001 0000017b 0048e114
00000000 00000000 004a3270
[ 8.772510] 7fe0: bea8f990 bea8f980 b6f71269 b6e9f6c0
[ 8.777556] Code: e5b5424c e1550004 0a00000c e2444004 (e5943070)
[ 8.784011] ---[ end trace ad8c21587c118655 ]---
Of course my root file system does include resp. vic firmware:
7ef01d2e3f507c91ca79584e89edcc64 /lib/firmware/nvidia/tegra124/vic03_u
code.bin
If I bake that one into the kernel binary, Nouveau still crashes like
above albeit VIC loading and Tegra DRM now at least showing something
on HDMI.
Just reverting above mentioned commit still leaves Nouveau crashing.
This has been observed using latest next-20181207.
Does anybody know what exactly is going on and how exactly one may get
graphics working again as before?
Thanks!
Cheers
Marcel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Coresight etmv4 enable over 32bit kernel
From: Lei Wen @ 2018-12-08 12:04 UTC (permalink / raw)
To: mathieu.poirier; +Cc: leiwen, linux-kernel, linux-arm-kernel
Hi Mathieu,
I am enabling etmv4 coresight over one Cortex-A7 soc, using 32bit kernel.
And I am following [1] to do experiment regarding the addr_range feature.
The default addr_range is set as _stext~_etext, and it works fine with
etb as sink,
and etm as source. I could see there are valid kernel addresses using OpenCSD.
But while I try to store one small range of address pair, which contain only one
kernel function. It doesn't behavior like what said in [1], the write
pointer would
grows rapidly with the read pointer. And I dump the etb buffer and parse it with
openCSD, finding that there is no I_ASYNC packet in the dump and is fulled with
I_NOT_SYNC.
So my question is why ETB continue to grow when there is no trigger at all?
Is it normal? I could provide more info if you need it.
[1]: https://wiki.linaro.org/WorklingGroups/Kernel/Coresight/traceDecodingWithDS5
Thanks,
Lei
_______________________________________________
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 2/6] arm64: add basic DTS for i.MX8MQ
From: Abel Vesa @ 2018-12-08 11:52 UTC (permalink / raw)
To: Lucas Stach
Cc: Aisheng Dong, Rob Herring, devicetree@vger.kernel.org,
patchwork-lst@pengutronix.de, dl-linux-imx, kernel@pengutronix.de,
Fabio Estevam, Shawn Guo, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181207210718.ueg2uw6tfniniscl@fsr-ub1664-175>
On Fri, Dec 07, 2018 at 09:07:19PM +0000, Abel Vesa wrote:
> On Fri, Dec 07, 2018 at 05:36:52PM +0100, Lucas Stach wrote:
> > Hi Abel,
> >
> > Am Freitag, den 07.12.2018, 16:17 +0000 schrieb Abel Vesa:
> > > On Fri, Nov 16, 2018 at 05:25:24PM -0600, Rob Herring wrote:
> > >
> > > > > +
> > > > > + clk_ext1: clock-ext1 {
> > > > > + compatible = "fixed-clock";
> > > > > + #clock-cells = <0>;
> > > > > + clock-frequency = <133000000>;
> > > > > + clock-output-names = "clk_ext1";
> > > > > + };
> > > > > +
> > > > > + clk_ext2: clock-ext2 {
> > > > > + compatible = "fixed-clock";
> > > > > + #clock-cells = <0>;
> > > > > + clock-frequency = <133000000>;
> > > > > + clock-output-names = "clk_ext2";
> > > > > + };
> > > > > +
> > > > > + clk_ext3: clock-ext3 {
> > > > > + compatible = "fixed-clock";
> > > > > + #clock-cells = <0>;
> > > > > + clock-frequency = <133000000>;
> > > > > + clock-output-names = "clk_ext3";
> > > > > + };
> > > > > +
> > > > > + clk_ext4: clock-ext4 {
> > > > > + compatible = "fixed-clock";
> > > > > + #clock-cells = <0>;
> > > > > + clock-frequency= <133000000>;
> > > > > + clock-output-names = "clk_ext4";
> > > > > + };
> > > >
> > > > This is really 4 independent clocks or is 1 clock connected to 4
> > > > sinks?
> > >
> > > According to the RM, yes, there are 4 independent clocks. Here is a
> > > link to the rm:
> > >
> > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nxp.com%2Fwebapp%2FDownload%3FcolCode%3DIMX8MEVKBHUG&data=02%7C01%7Cabel.vesa%40nxp.com%7C303f3053feb94a3c1c9f08d65c623255%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636797974154936811&sdata=CuJSqDl1WiL%2Bc%2B4wYnr3ssDDpH3DorYIzLN87PNHVh4%3D&reserved=0 (page 829)
> > >
> > > Unfortunately, the old link (which worked without login) does not
> > > work anymore.
> >
> > It's really 4 clock inputs to the SoC, but they may actually be
> > connected to the same clock source on the board. So I really wonder if
> > we should even put this into the base SoC DT, but rather push this into
> > individual board DTs.
>
> Hmm, it's part of the SoC, right ? So I would keep it in the dtsi rather than
> having it duplicated into every new dts.
>
On a second thought, you're right, they seem to be input from the board and
would make sense to be in the board specific dts file.
Though, one problem with that is that the imx8mq CCM driver expects them to
be available.
One solution would be to keep as is since there is only one board (evk)
that is supported.
Later on, when another board comes around (and if it doesn't provide all the ext
clocks) we can rework the CCM driver to supoort that.
> >
> > Regards,
> > Lucas
>
> --
--
_______________________________________________
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 3/4] iio: adc: add STMPE ADC devicetree bindings
From: Jonathan Cameron @ 2018-12-08 10:55 UTC (permalink / raw)
To: Philippe Schenker
Cc: Mark Rutland, devicetree, Dmitry Torokhov, Alexandre Torgue,
marcel.ziswiler, Peter Meerwald-Stadler, linux-input,
linux-kernel, stefan, linux-iio, Rob Herring, linux-arm-kernel,
Max Krummenacher, Hartmut Knaack, Lee Jones, linux-stm32,
Maxime Coquelin, Lars-Peter Clausen
In-Reply-To: <08da9873dd9b20512a7fce01399c9d778e0ea652.camel@pschenker.ch>
On Thu, 06 Dec 2018 16:49:33 +0100
Philippe Schenker <dev@pschenker.ch> wrote:
> On Sun, 2018-11-25 at 10:04 +0000, Jonathan Cameron wrote:
> > On Fri, 23 Nov 2018 15:24:10 +0100
> > Philippe Schenker <dev@pschenker.ch> wrote:
> >
> > > From: Stefan Agner <stefan@agner.ch>
> > >
> > > This adds the devicetree bindings for the STMPE ADC.
> > >
> > > Signed-off-by: Stefan Agner <stefan@agner.ch>
> > > Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
> > > Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> > Clearly this will need review from input and mfd.
> >
> > I've suggested inline that you split the realignment out to a
> > separate patch for reviewability reasons.
>
> Thank you again Jonathan for your feedback, and of course also all the others!
>
> I will split it much more so everything will be much more readable in v4. You
> suggested again, to use the naming 'adc {'. I know that this is standard naming,
> but unfortunately, this naming is given by drivers/mfd/stmpe.c (line 1311).
> What do you suggest to do? break the naming scheme in mfd, or just use
> 'stmpe_adc {' ?
Leave it as it is, but add a note ideally to say that is the reason.
Jonathan
>
> >
> > > ---
> > >
> > > Changes in v3:
> > > - Reformatted documentation for touchscreen to use tabs and have a better
> > > overview of the settings.
> > > - Added note which adc-settings will take precedence.
> > > - changed typo in sample-time setting from 144 clocks to 124 clocks, as
> > > stated
> > > in the datasheet.
> > >
> > > Changes in v2:
> > > - Moved the bindings for ADC to the overlying mfd.
> > > - Reformatted for better readability
> > >
> > > .../devicetree/bindings/iio/adc/stmpe-adc.txt | 21 +++++++
> > > .../bindings/input/touchscreen/stmpe.txt | 60 ++++++++++++-------
> > > .../devicetree/bindings/mfd/stmpe.txt | 28 ++++++---
> > > 3 files changed, 80 insertions(+), 29 deletions(-)
> > > create mode 100644 Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> > > b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> > > new file mode 100644
> > > index 000000000000..480e66422625
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> > > @@ -0,0 +1,21 @@
> > > +STMPE ADC driver
> > > +----------------
> > > +
> > > +Required properties:
> > > + - compatible: "st,stmpe-adc"
> > > +
> > > +Optional properties:
> > > +Note that the ADC is shared with the STMPE touchscreen. ADC related
> > > settings
> > > +have to be done in the mfd.
> > > +- st,norequest-mask: bitmask specifying which ADC channels should _not_ be
> > > + requestable due to different usage (e.g. touch)
> > > +
> > > +Node name must be stmpe_adc and should be child node of stmpe node to
> > > +which it belongs.
> > > +
> > > +Example:
> > > +
> > > + stmpe_adc {
> >
> > Can we use adc { here to match standard naming?
> >
> > > + compatible = "st,stmpe-adc";
> > > + st,norequest-mask = <0x0F>; /* dont use ADC CH3-0 */
> > > + };
> > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> > > b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> > > index 127baa31a77a..414586513a02 100644
> > > --- a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> > > +++ b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> > > @@ -5,36 +5,52 @@ Required properties:
> > > - compatible: "st,stmpe-ts"
> > >
> > > Optional properties:
> > > -- st,sample-time: ADC converstion time in number of clock. (0 -> 36
> > > clocks, 1 ->
> > > - 44 clocks, 2 -> 56 clocks, 3 -> 64 clocks, 4 -> 80 clocks, 5 -> 96
> > > clocks, 6
> > > - -> 144 clocks), recommended is 4.
> > > -- st,mod-12b: ADC Bit mode (0 -> 10bit ADC, 1 -> 12bit ADC)
> > > -- st,ref-sel: ADC reference source (0 -> internal reference, 1 -> external
> > > - reference)
> > > -- st,adc-freq: ADC Clock speed (0 -> 1.625 MHz, 1 -> 3.25 MHz, 2 || 3 ->
> > > 6.5 MHz)
> > > -- st,ave-ctrl: Sample average control (0 -> 1 sample, 1 -> 2 samples, 2 ->
> > > 4
> > > - samples, 3 -> 8 samples)
> > > -- st,touch-det-delay: Touch detect interrupt delay (0 -> 10 us, 1 -> 50 us,
> > > 2 ->
> > > - 100 us, 3 -> 500 us, 4-> 1 ms, 5 -> 5 ms, 6 -> 10 ms, 7 -> 50 ms)
> > > recommended
> > > - is 3
> > > -- st,settling: Panel driver settling time (0 -> 10 us, 1 -> 100 us, 2 ->
> > > 500 us, 3
> > > - -> 1 ms, 4 -> 5 ms, 5 -> 10 ms, 6 for 50 ms, 7 -> 100 ms) recommended is
> > > 2
> > > -- st,fraction-z: Length of the fractional part in z (fraction-z ([0..7]) =
> > > Count of
> > > - the fractional part) recommended is 7
> > > -- st,i-drive: current limit value of the touchscreen drivers (0 -> 20 mA
> > > typical 35
> > > - mA max, 1 -> 50 mA typical 80 mA max)
> > > +- st,ave-ctrl : Sample average control
> > > + 0 -> 1 sample
> > > + 1 -> 2 samples
> > > + 2 -> 4 samples
> > > + 3 -> 8 samples
> > > +- st,touch-det-delay : Touch detect interrupt delay (recommended is
> > > 3)
> > > + 0 -> 10 us 5 -> 5 ms
> > > + 1 -> 50 us 6 -> 10 ms
> > > + 2 -> 100 us 7 -> 50 ms
> > > + 3 -> 500 us
> > > + 4-> 1 ms
> > > +- st,settling : Panel driver settling time (recommended is 2)
> > > + 0 -> 10 us 5 -> 10 ms
> > > + 1 -> 100 us 6 for 50 ms
> > > + 2 -> 500 us 7 -> 100 ms
> > > + 3 -> 1 ms
> > > + 4 -> 5 ms
> > > +- st,fraction-z : Length of the fractional part in z
> > > (recommended is 7)
> > > + (fraction-z ([0..7]) = Count of the fractional part)
> > > +- st,i-drive : current limit value of the touchscreen drivers
> > > + 0 -> 20 mA (typical 35mA max)
> > > + 1 -> 50 mA (typical 80 mA max)
> > > +
> > > +Optional properties common with MFD (deprecated):
> > > + - st,sample-time : ADC conversion time in number of clock.
> > > + 0 -> 36 clocks 4 -> 80 clocks
> > > (recommended)
> > > + 1 -> 44 clocks 5 -> 96 clocks
> > > + 2 -> 56 clocks 6 -> 124 clocks
> > > + 3 -> 64 clocks
> > > + - st,mod-12b : ADC Bit mode
> > > + 0 -> 10bit ADC 1 -> 12bit ADC
> > > + - st,ref-sel : ADC reference source
> > > + 0 -> internal 1 -> external
> > > + - st,adc-freq : ADC Clock speed
> > > + 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
> > > + 1 -> 3.25 MHz
> > >
> > > Node name must be stmpe_touchscreen and should be child node of stmpe node
> > > to
> > > which it belongs.
> > >
> > > +Note that common ADC settings of stmpe_touchscreen will take precedence.
> > > +
> > > Example:
> > >
> > > stmpe_touchscreen {
> > > compatible = "st,stmpe-ts";
> > > - st,sample-time = <4>;
> > > - st,mod-12b = <1>;
> > > - st,ref-sel = <0>;
> > > - st,adc-freq = <1>;
> > > st,ave-ctrl = <1>;
> > > st,touch-det-delay = <2>;
> > > st,settling = <2>;
> > > diff --git a/Documentation/devicetree/bindings/mfd/stmpe.txt
> > > b/Documentation/devicetree/bindings/mfd/stmpe.txt
> > > index c797c05cd3c2..d4408a417193 100644
> > > --- a/Documentation/devicetree/bindings/mfd/stmpe.txt
> > > +++ b/Documentation/devicetree/bindings/mfd/stmpe.txt
> > > @@ -4,15 +4,29 @@ STMPE is an MFD device which may expose the following
> > > inbuilt devices: gpio,
> > > keypad, touchscreen, adc, pwm, rotator.
> > >
> > > Required properties:
> > > - - compatible :
> > > "st,stmpe[610|801|811|1600|1601|2401|2403]"
> > > - - reg : I2C/SPI address of the device
> > > + - compatible :
> > > "st,stmpe[610|801|811|1600|1601|2401|2403]"
> > > + - reg : I2C/SPI address of the device
> >
> > Nothing wrong with correcting alignment, but it shouldn't be in the same patch
> > as a fundamental change lie this. Just adds noise.
> >
> > If that means you first have to introduce the new block missaligned, then
> > fix up the alignment in a follow up patch, then do that as we can then
> > effectively ignore the realignment as obviously correct and focus on
> > the real changes.
> >
> > >
> > > Optional properties:
> > > - - interrupts : The interrupt outputs from the controller
> > > - - interrupt-controller : Marks the device node as an interrupt
> > > controller
> > > - - wakeup-source : Marks the input device as wakable
> > > - - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64, 128,
> > > 256, 512 and 1024
> > > - - irq-gpio : If present, which GPIO to use for event
> > > IRQ
> > > + - interrupts : The interrupt outputs from the
> > > controller
> > > + - interrupt-controller : Marks the device node as an interrupt
> > > controller
> > > + - wakeup-source : Marks the input device as wakable
> > > + - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64,
> > > 128, 256, 512 and 1024
> > > + - irq-gpio : If present, which GPIO to use for
> > > event IRQ
> > > +
> > > +Optional properties for devices with touch and ADC (STMPE811|STMPE610):
> > > + - st,sample-time : ADC conversion time in number of clock.
> > > + 0 -> 36 clocks 4 -> 80
> > > clocks (recommended)
> > > + 1 -> 44 clocks 5 -> 96
> > > clocks
> > > + 2 -> 56 clocks 6 -> 124
> > > clocks
> > > + 3 -> 64 clocks
> > > + - st,mod-12b : ADC Bit mode
> > > + 0 -> 10bit ADC 1 -> 12bit
> > > ADC
> > > + - st,ref-sel : ADC reference source
> > > + 0 -> internal 1 ->
> > > external
> > > + - st,adc-freq : ADC Clock speed
> > > + 0 -> 1.625 MHz 2 || 3 ->
> > > 6.5 MHz
> > > + 1 -> 3.25 MHz
> > >
> > > Example:
> > >
>
_______________________________________________
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 2/2] arm: dts: meson: Fix IRQ trigger type for macirq
From: Carlo Caione @ 2018-12-08 10:46 UTC (permalink / raw)
To: Emiliano Ingrassia
Cc: mark.rutland, devicetree, martin.blumenstingl, khilman, robh+dt,
linux-amlogic, linux-arm-kernel
In-Reply-To: <20181207185136.GB17435@ingrassia.epigenesys.com>
On Fri, 2018-12-07 at 19:51 +0100, Emiliano Ingrassia wrote:
> Hi Carlo,
Hi Emiliano,
> tests[0] conducted on an Odroid-C1+ board equipped with a Meson8b SoC
> have shown an high packet loss (90% and more) during a simple ping
> test from a laptop to the board.
> Testing the two patches separately clearly showed that this depends
> on the
> removal of the "eee-broken-1000t" flag from the board PHY description
> in the relative device tree.
>
> About the first patch (MAC IRQ type), no tests have shown an evidence
> that it is needed. I suggest you to conduct some test on real
> hardware
> as I do to confirm or disprove my tests.
Let's try to step back a bit and see what we can do to clarify this
situation.
First of all for arm64 we are pretty sure that both patches are needed
because we ran extensive and lengthy tests, especially regarding the
change in the IRQ trigger type. For arm things are not so clear, so for
now we decided to merge the arm64 patch and just wait on the arm one.
First of all we can focus on the patch regarding the change in the IRQ
type.
The problem with the IRQ type is triggered on the arm64 boards we
tested using the script in [0]. If we run this stress test on the arm64
boards without the trigger changing patch after a few hours (variable
from 2h to 6h sometimes more) we can see the connection dropping from
~1Gbps to <30Mbps. Jerome gave a nice explanation of the why, but after
changing the IRQ trigger type we couldn't see the issue anymore. This
was confirmed not just by BayLibre but also from other different
sources, so we are pretty confident in this solution.
So my first two points for you to answer are:
1) Can you reproduce this problem on your board without the patches
when running this script?
2) If yes, does only the first patch solve the problem?
This brings us to the second issue, the one regarding the 'eee-broken-
1000t' quirk. Since the two issues are strictly related we are
confident that the change in the IRQ type solves this problem as well
(and this was confirmed by Jerome as well on the arm64 boards).
For this case I cannot provide a real reproducer so we need only to
stress test the network with iperf3 trying to reproduce the issue. This
is also because we think that you approach of using UDP and your packet
generator probably is not the best way to test the patch given that (1)
using UDP is not reliable according to our tests, (2) there is an
asymmetry in TX/RX, (3) the packet loss could be due to the saturation
on the bandwidth, etc...
So AFAIK the best way to test this problem is using iperf3, the same
way it is done in the script in [0]. I was not involved with this issue
1 year and half ago but AFAIK this is the way it was reproduced.
This brings me to more answers for you to answer:
3) Running iperf3 tests in TX / RX / TX+RX without the 'eee-broken-
1000' quirk applied are you able to reproduce the EEE problem?
4) Any change when the 'eee-broken-1000' quirk is applied?
When testing (3) and (4) also please check the status of the EEE using
ethtool.
Hopefully this will bring a bit of clarity to the whole situation :)
Cheers,
[0] https://paste.fedoraproject.org/paste/GBFxjAQ0JULsYQlyYO2KOw
--
Carlo Caione
_______________________________________________
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 v6 04/13] arm64/kvm: hide ptrauth from guests
From: Marc Zyngier @ 2018-12-08 10:32 UTC (permalink / raw)
To: Kristina Martsenko
Cc: Mark Rutland, Andrew Jones, linux-kernel, Jacob Bramley,
Ard Biesheuvel, Catalin Marinas, Adam Wallis, Suzuki K Poulose,
Richard Henderson, Christoffer Dall, Will Deacon, kvmarm,
Cyrill Gorcunov, Ramana Radhakrishnan, Amit Kachhap,
Dave P Martin, linux-arm-kernel, Kees Cook
In-Reply-To: <20181207183931.4285-5-kristina.martsenko@arm.com>
On Fri, 07 Dec 2018 18:39:22 +0000,
Kristina Martsenko <kristina.martsenko@arm.com> wrote:
>
> From: Mark Rutland <mark.rutland@arm.com>
>
> In subsequent patches we're going to expose ptrauth to the host kernel
> and userspace, but things are a bit trickier for guest kernels. For the
> time being, let's hide ptrauth from KVM guests.
>
> Regardless of how well-behaved the guest kernel is, guest userspace
> could attempt to use ptrauth instructions, triggering a trap to EL2,
> resulting in noise from kvm_handle_unknown_ec(). So let's write up a
> handler for the PAC trap, which silently injects an UNDEF into the
> guest, as if the feature were really missing.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
> Reviewed-by: Andrew Jones <drjones@redhat.com>
> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: kvmarm@lists.cs.columbia.edu
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead, it just smell funny.
_______________________________________________
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 v6 03/13] arm64/kvm: consistently handle host HCR_EL2 flags
From: Marc Zyngier @ 2018-12-08 10:31 UTC (permalink / raw)
To: Kristina Martsenko
Cc: Mark Rutland, Andrew Jones, linux-kernel, Jacob Bramley,
Ard Biesheuvel, Catalin Marinas, Adam Wallis, Suzuki K Poulose,
Richard Henderson, Christoffer Dall, Will Deacon, kvmarm,
Cyrill Gorcunov, Ramana Radhakrishnan, Amit Kachhap,
Dave P Martin, linux-arm-kernel, Kees Cook
In-Reply-To: <20181207183931.4285-4-kristina.martsenko@arm.com>
On Fri, 07 Dec 2018 18:39:21 +0000,
Kristina Martsenko <kristina.martsenko@arm.com> wrote:
>
> From: Mark Rutland <mark.rutland@arm.com>
>
> In KVM we define the configuration of HCR_EL2 for a VHE HOST in
> HCR_HOST_VHE_FLAGS, but we don't have a similar definition for the
> non-VHE host flags, and open-code HCR_RW. Further, in head.S we
> open-code the flags for VHE and non-VHE configurations.
>
> In future, we're going to want to configure more flags for the host, so
> lets add a HCR_HOST_NVHE_FLAGS defintion, and consistently use both
> HCR_HOST_VHE_FLAGS and HCR_HOST_NVHE_FLAGS in the kvm code and head.S.
>
> We now use mov_q to generate the HCR_EL2 value, as we use when
> configuring other registers in head.S.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: kvmarm@lists.cs.columbia.edu
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead, it just smell funny.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Moving ARM dts files
From: Ian Campbell @ 2018-12-08 10:07 UTC (permalink / raw)
To: Rob Herring, arm
Cc: Andrew Lunn, Alexandre Belloni, Tony Lindgren, Linus Walleij,
Liviu Dudau, Masahiro Yamada, Thierry Reding, Florian Fainelli,
Kevin Hilman, Gregory Clement, Michal Simek, Krzysztof Kozlowski,
Joel Stanley, Andy Gross, devicetree, Jason Cooper, Simon Horman,
linux-arm-kernel, Maxime Coquelin, Shawn Guo, Andreas Färber,
Daniel Mack
In-Reply-To: <20181204183649.GA5716@bogus>
On Tue, 2018-12-04 at 12:36 -0600, Rob Herring wrote:
> I've put together a script to move the dts files and update the
> makefiles.
Anything here which the split-devicetree tree[0] needs to care about?
I think this is all just about file movement contained entirely
underneath arch/arm/boot/dts, in which case the answer *should* be
"no".
Ian.
[0] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 08/18] iommu/mediatek: Add larb-id remapped support
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1544258371-4600-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.
This also is a preparing patch for mt8183.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 3 +++
drivers/iommu/mtk_iommu.h | 4 ++++
2 files changed, 7 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index eda062a..8ab3b69 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -220,6 +220,9 @@ 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);
+ if (data->plat_data->larbid_remap_enable)
+ fault_larb = data->plat_data->larbid_remapped[fault_larb];
+
if (report_iommu_fault(&dom->domain, data->dev, fault_iova,
write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ)) {
dev_err_ratelimited(
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index b8749ac..3877050 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -47,6 +47,10 @@ struct mtk_iommu_plat_data {
/* HW will use the EMI clock if there isn't the "bclk". */
bool has_bclk;
+
+ /* The larb-id may be remapped in the smi-common. */
+ bool larbid_remap_enable;
+ unsigned int larbid_remapped[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
* Re: Moving ARM dts files
From: Krzysztof Kozlowski @ 2018-12-08 9:25 UTC (permalink / raw)
To: robh
Cc: andrew, alexandre.belloni, tony, linus.walleij, liviu.dudau,
yamada.masahiro, thierry.reding, f.fainelli, khilman,
gregory.clement, michal.simek, arm, joel, andy.gross, devicetree,
jason, horms, linux-arm-kernel, mcoquelin.stm32, shawnguo,
afaerber, daniel
In-Reply-To: <CAL_JsqKK4F7QX=B-CcQkMsgN--r3xv6PS4JabzOb4kqfATwtsQ@mail.gmail.com>
On Fri, 7 Dec 2018 at 23:33, Rob Herring <robh@kernel.org> wrote:
>
> On Tue, Dec 4, 2018 at 12:36 PM Rob Herring <robh@kernel.org> wrote:
> >
> > Olof, Arnd,
> >
> > I've put together a script to move the dts files and update the
> > makefiles. It doesn't handle files not following a common prefix which
> > isn't many and some includes within the dts files will need some fixups
> > by hand.
> >
> > MAINTAINERS will also need updating.
> >
> > A few questions:
> >
> > Do we want to move absolutely everything to subdirs? There's quite a
> > few platforms with only 1-2 platforms. I haven't added these to the
> > list yet, but can.
> >
> > Do any vendors need another level of directories? davinci, omap, nspire,
> > etc. for TI for example.
> >
> > What to do with armv7m.dtsi? I guess it should remain and we just fixup
> > the include. There may be a few other cross vendor things.
> >
> >
> > Sub-arch maintainers,
> > 'vendor_map' below is the mapping of file prefix to new subdirectory
> > (the SoC vendor prefix). Please comment if there are any issues.
>
> Here's an updated mapping filled out with the rest of the platforms
> and using SoC family names in some cases as discussed. The move is
> completely scripted now including include fixups (though any new
> includes could break things). So mainly just need to bikeshed the
> directory mapping. Not sure if marvell should be split up more or not.
> I split out pxa2xx and pxa3xx, but then there's other pxa chips I
> think aren't really related. TI is still all one directory except
> nspire. I was going to split out davinci too, but it's only a couple
> of files. Sub-arch maintainers need to chime in with what they want.
>
> A branch is here including a fix to dtbs_install:
> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git arm-dts-move
>
> vendor_map = {
> 'alphascale' : 'alphascale',
> 'alpine' : 'alpine',
> 'artpec' : 'axis',
> 'atlas' : 'sirf',
> 'prima' : 'sirf',
> 'axm' : 'lsi',
> 'cx9' : 'cnxt',
> 'ecx' : 'calxeda',
> 'highbank' : 'calxeda',
> 'efm' : 'efm32',
> 'ep7' : 'cirrus',
> 'mxs': 'mxs',
> 'imx23': 'mxs',
> 'imx28': 'mxs',
> 'imx': 'imx',
> 'ls': 'fsl',
> 'vf': 'fsl',
> 'qcom': 'qcom',
> 'am3' : 'ti',
> 'am4' : 'ti',
> 'am5' : 'ti',
> 'dra' : 'ti',
> 'keystone' : 'ti',
> 'omap' : 'ti',
> 'compulab' : 'ti',
> 'logicpd' : 'ti',
> 'elpida' : 'ti',
> 'motorola-cpcap' : 'ti',
> 'twl' : 'ti',
> 'da' : 'ti',
> 'dm' : 'ti',
> 'nspire' : 'nspire',
> 'armada' : 'marvell',
> 'dove' : 'marvell',
> 'kirkwood' : 'marvell',
> 'orion' : 'marvell',
> 'mvebu' : 'marvell',
> 'mmp2' : 'marvell',
> 'berlin' : 'berlin',
> 'pxa2' : 'pxa',
> 'pxa3' : 'pxa',
> 'pxa' : 'marvell',
> 'arm-' : 'arm',
> 'integ' : 'arm',
> 'mps' : 'arm',
> 've' : 'arm',
> 'aspeed' : 'aspeed',
> 'at91' : 'at91',
> 'sama' : 'at91',
> 'usb_' : 'at91',
> 'tny_' : 'at91',
> 'mpa1600' : 'at91',
> 'animeo_ip' : 'at91',
> 'aks-cdu' : 'at91',
> 'ethernut5' : 'at91',
> 'evk-pro3' : 'at91',
> 'pm9g45' : 'at91',
> 'ge86' : 'at91',
> 'bcm' : 'brcm',
> 'exynos' : 'exynos',
> 's3c' : 'samsung',
> 's5p' : 'samsung',
Since Exynos is Samsung, I would prefer consistency here so let's put
everything under vendor - samsung. I understand that It will be
different than arm64 but that's the problem of choosing non-vendor
name for arm64 at first place. So let's go with:
'exynos' : 'samsung',
's3c' : 'samsung',
's5p' : 'samsung',
Best regards,
Krzysztof
> 'gemini' : 'gemini',
> 'hi3' : 'hisilicon',
> 'hip' : 'hisilicon',
> 'hisi' : 'hisilicon',
> 'mt' : 'mediatek',
> 'meson' : 'meson',
> 'moxa' : 'moxa',
> 'nuvo' : 'nuvoton',
> 'lpc' : 'lpc',
> 'owl' : 'actions',
> 'ox8' : 'oxsemi',
> 'picox' : 'picoxcell',
> 'r7' : 'renesas',
> 'r8' : 'renesas',
> 'r9' : 'renesas',
> 'emev2' : 'renesas',
> 'sh73a' : 'renesas',
> 'gr-' : 'renesas',
> 'iwg' : 'renesas',
> 'rk' : 'rockchip',
> 'rv11' : 'rockchip',
> 'socfpga' : 'socfpga',
> 'stm' : 'stm32',
> 'sti' : 'sti',
> 'st-pin' : 'sti',
> 'ste' : 'st-ericsson',
> 'spear' : 'spear',
> 'sun' : 'allwinner',
> 'axp' : 'allwinner',
> 'tango' : 'sigma',
> 'tegra' : 'nvidia',
> 'uniph' : 'socionext',
> 'vt8500' : 'vt8500',
> 'wm8' : 'vt8500',
> 'xen' : 'xen',
> 'zx' : 'zte',
> 'zynq' : 'xilinx',
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 06/18] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1544258371-4600-1-git-send-email-yong.wu@mediatek.com>
MediaTek extend the arm v7s descriptor to support the dram over 4GB.
In the mt2712 and mt8173, it's called "4GB mode", the physical address
is from 0x4000_0000 to 0x1_3fff_ffff, but from EMI point of view, it
is remapped to high address from 0x1_0000_0000 to 0x1_ffff_ffff, the
bit32 is always enabled. thus, in the M4U, we always enable the bit9
for all PTEs which means to enable bit32 of physical address.
but in mt8183, M4U support the dram from 0x4000_0000 to 0x3_ffff_ffff
which isn't remaped. We extend the PTEs: the bit9 represent bit32 of
PA and the bit4 represent bit33 of PA. Meanwhile the iova still is
32bits.
In order to unify code, in the "4GB mode", we add the bit32 for the
physical address manually in our driver.
Correspondingly, Adding bit32 and bit33 for the PA in the iova_to_phys
has to been moved into v7s.
Regarding whether the pagetable address could be over 4GB, the mt8183
support it while the previous mt8173 don't. thus keep it as is.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/io-pgtable-arm-v7s.c | 31 ++++++++++++++++++++++++-------
drivers/iommu/io-pgtable.h | 7 +++----
drivers/iommu/mtk_iommu.c | 14 ++++++++------
drivers/iommu/mtk_iommu.h | 1 +
4 files changed, 36 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index 03bb7b9..a006fe7 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -124,7 +124,9 @@
#define ARM_V7S_TEX_MASK 0x7
#define ARM_V7S_ATTR_TEX(val) (((val) & ARM_V7S_TEX_MASK) << ARM_V7S_TEX_SHIFT)
-#define ARM_V7S_ATTR_MTK_4GB BIT(9) /* MTK extend it for 4GB mode */
+/* MediaTek extend the two bits below for over 4GB mode */
+#define ARM_V7S_ATTR_MTK_PA_BIT32 BIT(9)
+#define ARM_V7S_ATTR_MTK_PA_BIT33 BIT(4)
/* *well, except for TEX on level 2 large pages, of course :( */
#define ARM_V7S_CONT_PAGE_TEX_SHIFT 6
@@ -183,13 +185,22 @@ static dma_addr_t __arm_v7s_dma_addr(void *pages)
static arm_v7s_iopte paddr_to_iopte(phys_addr_t paddr, int lvl,
struct io_pgtable_cfg *cfg)
{
- return paddr & ARM_V7S_LVL_MASK(lvl);
+ arm_v7s_iopte pte = paddr & ARM_V7S_LVL_MASK(lvl);
+
+ if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB) {
+ if (paddr & BIT_ULL(32))
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT32;
+ if (paddr & BIT_ULL(33))
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT33;
+ }
+ return pte;
}
static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int lvl,
struct io_pgtable_cfg *cfg)
{
arm_v7s_iopte mask;
+ phys_addr_t paddr;
if (ARM_V7S_PTE_IS_TABLE(pte, lvl))
mask = ARM_V7S_TABLE_MASK;
@@ -198,7 +209,14 @@ static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int lvl,
else
mask = ARM_V7S_LVL_MASK(lvl);
- return pte & mask;
+ paddr = pte & mask;
+ if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB) {
+ if (pte & ARM_V7S_ATTR_MTK_PA_BIT32)
+ paddr |= BIT_ULL(32);
+ if (pte & ARM_V7S_ATTR_MTK_PA_BIT33)
+ paddr |= BIT_ULL(33);
+ }
+ return paddr;
}
static arm_v7s_iopte *iopte_deref(arm_v7s_iopte pte, int lvl,
@@ -315,9 +333,6 @@ static arm_v7s_iopte arm_v7s_prot_to_pte(int prot, int lvl,
if (lvl == 1 && (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS))
pte |= ARM_V7S_ATTR_NS_SECTION;
- if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB)
- pte |= ARM_V7S_ATTR_MTK_4GB;
-
return pte;
}
@@ -504,7 +519,9 @@ static int arm_v7s_map(struct io_pgtable_ops *ops, unsigned long iova,
if (!(prot & (IOMMU_READ | IOMMU_WRITE)))
return 0;
- if (WARN_ON(upper_32_bits(iova) || upper_32_bits(paddr)))
+ if (WARN_ON(upper_32_bits(iova)) ||
+ WARN_ON(upper_32_bits(paddr) &&
+ !(iop->cfg.quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB)))
return -ERANGE;
ret = __arm_v7s_map(data, iova, paddr, size, prot, 1, data->pgd);
diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
index 47d5ae5..69db115 100644
--- a/drivers/iommu/io-pgtable.h
+++ b/drivers/iommu/io-pgtable.h
@@ -62,10 +62,9 @@ struct io_pgtable_cfg {
* (unmapped) entries but the hardware might do so anyway, perform
* TLB maintenance when mapping as well as when unmapping.
*
- * IO_PGTABLE_QUIRK_ARM_MTK_4GB: (ARM v7s format) Set bit 9 in all
- * PTEs, for Mediatek IOMMUs which treat it as a 33rd address bit
- * when the SoC is in "4GB mode" and they can only access the high
- * remap of DRAM (0x1_00000000 to 0x1_ffffffff).
+ * IO_PGTABLE_QUIRK_ARM_MTK_4GB: (ARM v7s format) MediaTek IOMMUs extend
+ * to support up to 34 bits PA where the bit32 and bit33 are
+ * encoded in the bit9 and bit4 of the PTE respectively.
*
* IO_PGTABLE_QUIRK_NO_DMA: Guarantees that the tables will only ever
* be accessed by a fully cache-coherent IOMMU or CPU (e.g. for a
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 9a2225b..8eb110e 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -367,12 +367,16 @@ static int mtk_iommu_map(struct iommu_domain *domain, unsigned long iova,
phys_addr_t paddr, size_t size, int prot)
{
struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+ struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
unsigned long flags;
int ret;
+ /* The "4GB mode" M4U physically can not use the lower remap of Dram. */
+ if (data->plat_data->has_4gb_mode && data->enable_4GB)
+ paddr |= BIT_ULL(32);
+
spin_lock_irqsave(&dom->pgtlock, flags);
- ret = dom->iop->map(dom->iop, iova, paddr & DMA_BIT_MASK(32),
- size, prot);
+ ret = dom->iop->map(dom->iop, iova, paddr, size, prot);
spin_unlock_irqrestore(&dom->pgtlock, flags);
return ret;
@@ -401,7 +405,6 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
dma_addr_t iova)
{
struct mtk_iommu_domain *dom = to_mtk_domain(domain);
- struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
unsigned long flags;
phys_addr_t pa;
@@ -409,9 +412,6 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
pa = dom->iop->iova_to_phys(dom->iop, iova);
spin_unlock_irqrestore(&dom->pgtlock, flags);
- if (data->enable_4GB)
- pa |= BIT_ULL(32);
-
return pa;
}
@@ -735,10 +735,12 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
static const struct mtk_iommu_plat_data mt2712_data = {
.m4u_plat = M4U_MT2712,
+ .has_4gb_mode = true,
};
static const struct mtk_iommu_plat_data mt8173_data = {
.m4u_plat = M4U_MT8173,
+ .has_4gb_mode = true,
};
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 333a0ef..5890e55 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -43,6 +43,7 @@ enum mtk_iommu_plat {
struct mtk_iommu_plat_data {
enum mtk_iommu_plat m4u_plat;
+ bool has_4gb_mode;
};
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 v4 09/18] memory: mtk-smi: Add gals support
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1544258371-4600-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.
Signed-off-by: Yong Wu <yong.wu@mediatek.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 a5ddd42..3720c77 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -56,6 +56,7 @@ enum mtk_smi_gen {
struct mtk_smi_common_plat {
enum mtk_smi_gen gen;
+ bool has_gals;
};
struct mtk_smi_larb_gen {
@@ -63,11 +64,13 @@ struct mtk_smi_larb_gen {
int port_in_larb[MTK_LARB_NR_MAX + 1];
void (*config_port)(struct device *);
unsigned int larb_special_mask; /* The special larbs 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;
@@ -99,8 +102,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:
@@ -110,6 +125,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);
@@ -310,6 +327,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) {
@@ -402,6 +428,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 v4 10/18] iommu/mediatek: Add mt8183 IOMMU support
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1544258371-4600-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) the larb-id in smi-common is remapped. M4U should enable
larbid_remapped support.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 31 ++++++++++++++++++++++---------
drivers/iommu/mtk_iommu.h | 1 +
drivers/memory/mtk-smi.c | 19 +++++++++++++++++++
3 files changed, 42 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 8ab3b69..d91a554 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -36,6 +36,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
@@ -54,7 +55,7 @@
#define REG_MMU_CTRL_REG 0x110
#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)
+ ((data)->plat_data->m4u_plat == M4U_MT8173 ? 5 : 4)
/* 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))
@@ -347,7 +348,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);
}
@@ -510,6 +511,7 @@ static int mtk_iommu_of_xlate(struct device *dev, struct of_phandle_args *args)
static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
{
+ enum mtk_iommu_plat m4u_plat = data->plat_data->m4u_plat;
u32 regval;
int ret;
@@ -520,7 +522,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
}
regval = F_MMU_TF_PROTECT_SEL(2, data);
- if (data->plat_data->m4u_plat == M4U_MT8173)
+ if (m4u_plat == M4U_MT8173)
regval |= F_MMU_PREFETCH_RT_REPLACE_MOD;
writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
@@ -541,14 +543,14 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
F_INT_PRETETCH_TRANSATION_FIFO_FAULT;
writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
- if (data->plat_data->m4u_plat == M4U_MT8173)
+ if (m4u_plat == M4U_MT8173)
regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
else
regval = lower_32_bits(data->protect_base) |
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 && m4u_plat == M4U_MT2712) {
/*
* If 4GB mode is enabled, the validate PA range is from
* 0x1_0000_0000 to 0x1_ffff_ffff. here record bit[32:30].
@@ -558,8 +560,11 @@ 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)
+ /*
+ * It's MISC control register whose default value is ok
+ * except mt8173 and mt8183.
+ */
+ if (m4u_plat == M4U_MT8173 || m4u_plat == M4U_MT8183)
writel_relaxed(0, data->base + REG_MMU_STANDARD_AXI_MODE);
if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
@@ -713,6 +718,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;
@@ -728,8 +734,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;
}
@@ -750,9 +756,16 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
.has_bclk = true,
};
+static const struct mtk_iommu_plat_data mt8183_data = {
+ .m4u_plat = M4U_MT8183,
+ .larbid_remap_enable = true,
+ .larbid_remapped = {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 3877050..6385dec 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -39,6 +39,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 3720c77..bced778 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -285,6 +285,12 @@ static void mtk_smi_larb_config_port_gen1(struct device *dev)
.larb_special_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_special_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",
@@ -298,6 +304,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
+ },
{}
};
@@ -391,6 +401,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",
@@ -404,6 +419,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 v4 13/18] memory: mtk-smi: Add bus_sel for mt8183
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1544258371-4600-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.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/memory/mtk-smi.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index ee6165e..88eb61a 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -49,6 +49,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
@@ -57,6 +63,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 {
@@ -72,8 +79,8 @@ 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;
-
+ void __iomem *smi_ao_base; /* only for gen1 */
+ void __iomem *base; /* only for gen2 */
const struct mtk_smi_common_plat *plat;
};
@@ -409,6 +416,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[] = {
@@ -481,6 +490,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);
@@ -496,6 +510,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);
@@ -503,6 +518,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
* [GIT PULL] ARM: mvebu: dt64 for v4.21 (#1)
From: Gregory CLEMENT @ 2018-12-08 8:51 UTC (permalink / raw)
To: Arnd Bergmann, Olof Johansson, arm
Cc: Andrew Lunn, Jason Cooper, linux-arm-kernel,
Sebastian Hesselbarth
Hi,
Here is the first pull request for dt64 for mvebu for v4.21.
I'd like to do a second pull request early next week because I saw
some other patches wich were part of driver series that could go in
4.21.
Gregory
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
are available in the Git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-dt64-4.21-1
for you to fetch changes up to dfc1259a3f7a116b96e23e3467607c713c38a383:
arm64: dts: clearfog-gt-8k: describe mini-PCIe CON2 USB (2018-12-08 09:26:51 +0100)
----------------------------------------------------------------
mvebu dt64 for 4.21 (part 1)
- complete the description of the clearfog-gt-8k board (Armada 8040
based board)
- declare eMMC on espressobin (Armada 3720 based board) which still
need to be enable by the bootloader as it is not present on all the
board.
- add a new version of the Macchiatobin (Armada 8040 based board): the
Single Shot (without the 10G 3310 PHYs).
----------------------------------------------------------------
Baruch Siach (4):
arm64: dts: clearfog-gt-8k: fix USB regulator gpio polarity
arm64: dts: clearfog-gt-8k: 1G eth PHY reset signal
arm64: dts: clearfog-gt-8k: enable mini-PCIe CON2 USB
arm64: dts: clearfog-gt-8k: describe mini-PCIe CON2 USB
Ding Tao (2):
arm64: dts: marvell: armada37xx: Add emmc/sdio pinctrl definition
arm64: dts: marvell: armada-37xx: Enable emmc on espressobin
Russell King (1):
arm64: dts: add support for Macchiatobin Single Shot board
arch/arm64/boot/dts/marvell/Makefile | 1 +
.../boot/dts/marvell/armada-3720-espressobin.dts | 22 ++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 10 +
.../dts/marvell/armada-8040-clearfog-gt-8k.dts | 22 +-
.../dts/marvell/armada-8040-mcbin-singleshot.dts | 29 ++
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 333 +-------------------
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi | 346 +++++++++++++++++++++
7 files changed, 433 insertions(+), 330 deletions(-)
create mode 100644 arch/arm64/boot/dts/marvell/armada-8040-mcbin-singleshot.dts
create mode 100644 arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi
_______________________________________________
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 01/10] mailbox: Support blocking transfers in atomic context
From: Greg KH @ 2018-12-08 8:50 UTC (permalink / raw)
To: Jassi Brar
Cc: Devicetree List, Mikko Perttunen, mliljeberg, Mikko Perttunen,
talho, Thierry Reding, linux-serial, jslaby, linux-tegra, ppessi,
Jon Hunter, linux-arm-kernel
In-Reply-To: <CABb+yY3_uWv1YVxXxjgygPemBZraCTAXNyXT9G4aTMZv1t7d0g@mail.gmail.com>
On Sat, Dec 08, 2018 at 11:21:41AM +0530, Jassi Brar wrote:
> On Fri, Dec 7, 2018 at 11:50 AM Mikko Perttunen <cyndis@kapsi.fi> wrote:
> >
> > On 07/12/2018 11.26, Jassi Brar wrote:
> > >> I thought that I could also mitigate 2) by busy looping in the TCU driver,
> > >> but it turns out that that doesn't work. The reason is that since we are
> > >> in atomic context with all interrupts disabled, the mailbox won't ever
> > >> consume any new characters, so the read pointer in the circular buffer
> > >> won't increment, leaving me with no condition upon which to loop that
> > >> would work.
> > >>
> > > So you want to be able to rely on an emulated console (running on a
> > > totally different subsystem) to dump development-phase early-boot
> > > logs? At the cost of legitimizing busy looping in atomic context - one
> > > random driver messing up the api for ever. Maybe you could have the
> > > ring buffer in some shmem and only pass the number of valid characters
> > > in it, to the remote?
> > >
> >
> > I would like to note that this is the one and only console interface
> > that exists on these systems, for both development phase and production.
> > Other UARTs are not externally accessible on the systems, or they are
> > comparatively difficult to access as they aren't intended to be used as
> > consoles in the system design.
>
> > The combination of hardware and firmware
> > implementing the console is black box from software's point of view
> > (similarly to any other UART HW). The interface has also been fixed at
> > an early system design phase, as there are many operating systems
> > running on these boards, each with their own drivers.
> >
> That is the saddest part - someone, who writes test cases for the h/w
> team and with almost no knowledge of how OSes work, decides how the
> firmware is going to work and calls it done. Then the Linux is left to
> deal with the mess as we "can't do anything about it".
That is totally normal, and is how hardware has been almost _always_
been designed and implemented. Nothing new here at all, it's just the
life us kernel developers get used to very quickly as it is our job to
make that hardware work and appear to userspace as something sane and
universal.
Sorry,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH -next] media: rockchip/vpu: remove set but not used variables 'luma_qtable_p, chroma_qtable_p'
From: YueHaibing @ 2018-12-08 8:49 UTC (permalink / raw)
To: mchehab, gregkh, heiko, hverkuil-cisco
Cc: devel, YueHaibing, linux-kernel, linux-rockchip, linux-arm-kernel,
linux-media
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:101:10: warning:
variable 'chroma_qtable_p' set but not used [-Wunused-but-set-variable]
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:100:10: warning:
variable 'luma_qtable_p' set but not used [-Wunused-but-set-variable]
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:70:10: warning:
variable 'chroma_qtable_p' set but not used [-Wunused-but-set-variable]
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:69:10: warning:
variable 'luma_qtable_p' set but not used [-Wunused-but-set-variable]
It never used since introduction in
commit 775fec69008d ("media: add Rockchip VPU JPEG encoder driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 5 -----
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 5 -----
2 files changed, 10 deletions(-)
diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
index e27c108..5282236 100644
--- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
@@ -66,13 +66,8 @@ rk3288_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev *vpu,
unsigned char *luma_qtable,
unsigned char *chroma_qtable)
{
- __be32 *luma_qtable_p;
- __be32 *chroma_qtable_p;
u32 reg, i;
- luma_qtable_p = (__be32 *)luma_qtable;
- chroma_qtable_p = (__be32 *)chroma_qtable;
-
for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
reg = get_unaligned_be32(&luma_qtable[i]);
vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
index 5f75e4d..dbc86d9 100644
--- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
@@ -97,13 +97,8 @@ rk3399_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev *vpu,
unsigned char *luma_qtable,
unsigned char *chroma_qtable)
{
- __be32 *luma_qtable_p;
- __be32 *chroma_qtable_p;
u32 reg, i;
- luma_qtable_p = (__be32 *)luma_qtable;
- chroma_qtable_p = (__be32 *)chroma_qtable;
-
for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
reg = get_unaligned_be32(&luma_qtable[i]);
vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
--
2.7.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 17/18] iommu/mediatek: Constify iommu_ops
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1544258371-4600-1-git-send-email-yong.wu@mediatek.com>
From: Arvind Yadav <arvind.yadav.cs@gmail.com>
iommu_ops are not supposed to change at runtime.
Functions 'iommu_device_set_ops' and 'bus_set_iommu' working with
const iommu_ops provided by <linux/iommu.h>. So mark the non-const
structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
[Yong: Change the title to iommu/mediatek: xx]
---
drivers/iommu/mtk_iommu.c | 4 ++--
drivers/iommu/mtk_iommu_v1.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 9280031..03f5eee 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -119,7 +119,7 @@ struct mtk_iommu_domain {
struct iommu_domain domain;
};
-static struct iommu_ops mtk_iommu_ops;
+static const struct iommu_ops mtk_iommu_ops;
static LIST_HEAD(m4ulist); /* List all the M4U HWs */
@@ -503,7 +503,7 @@ static int mtk_iommu_of_xlate(struct device *dev, struct of_phandle_args *args)
return iommu_fwspec_add_ids(dev, args->args, 1);
}
-static struct iommu_ops mtk_iommu_ops = {
+static const struct iommu_ops mtk_iommu_ops = {
.domain_alloc = mtk_iommu_domain_alloc,
.domain_free = mtk_iommu_domain_free,
.attach_dev = mtk_iommu_attach_device,
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 6d4551e..5fbf3ce 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -364,7 +364,7 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
return pa;
}
-static struct iommu_ops mtk_iommu_ops;
+static const struct iommu_ops mtk_iommu_ops;
/*
* MTK generation one iommu HW only support one iommu domain, and all the client
@@ -526,7 +526,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
return 0;
}
-static struct iommu_ops mtk_iommu_ops = {
+static const struct iommu_ops mtk_iommu_ops = {
.domain_alloc = mtk_iommu_domain_alloc,
.domain_free = mtk_iommu_domain_free,
.attach_dev = mtk_iommu_attach_device,
--
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 v4 16/18] memory: mtk-smi: Get rid of need_larbid
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1544258371-4600-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.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/memory/mtk-smi.c | 26 ++------------------------
1 file changed, 2 insertions(+), 24 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 88eb61a..8be858e 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -67,7 +67,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_special_mask; /* The special larbs mask. */
@@ -153,18 +152,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;
}
@@ -243,7 +233,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
@@ -252,7 +241,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_special_mask = BIT(8) | BIT(9), /* bdpsys */
};
@@ -290,7 +278,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)
@@ -320,15 +307,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;
--
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 v4 18/18] iommu/mediatek: Switch to SPDX license identifier
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1544258371-4600-1-git-send-email-yong.wu@mediatek.com>
Switch to SPDX license identifier for MediaTek iommu/smi and their
header files.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
drivers/iommu/mtk_iommu.c | 10 +---------
drivers/iommu/mtk_iommu.h | 10 +---------
drivers/iommu/mtk_iommu_v1.c | 10 +---------
drivers/memory/mtk-smi.c | 10 +---------
include/dt-bindings/memory/mt2701-larb-port.h | 10 +---------
include/dt-bindings/memory/mt8173-larb-port.h | 10 +---------
include/soc/mediatek/smi.h | 10 +---------
7 files changed, 7 insertions(+), 63 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 03f5eee..c717c00 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -1,15 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2015-2016 MediaTek Inc.
* Author: Yong Wu <yong.wu@mediatek.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#include <linux/memblock.h>
#include <linux/bug.h>
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 17996e0..1049042 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -1,15 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
/*
* Copyright (c) 2015-2016 MediaTek Inc.
* Author: Honghui Zhang <honghui.zhang@mediatek.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#ifndef _MTK_IOMMU_H_
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 5fbf3ce..207f58b 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* IOMMU API for MTK architected m4u v1 implementations
*
@@ -5,15 +6,6 @@
* Author: Honghui Zhang <honghui.zhang@mediatek.com>
*
* Based on driver/iommu/mtk_iommu.c
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#include <linux/memblock.h>
#include <linux/bug.h>
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 8be858e..bfd0a8a 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -1,15 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2015-2016 MediaTek Inc.
* Author: Yong Wu <yong.wu@mediatek.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#include <linux/clk.h>
#include <linux/component.h>
diff --git a/include/dt-bindings/memory/mt2701-larb-port.h b/include/dt-bindings/memory/mt2701-larb-port.h
index 6764d74..c511f0f 100644
--- a/include/dt-bindings/memory/mt2701-larb-port.h
+++ b/include/dt-bindings/memory/mt2701-larb-port.h
@@ -1,15 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
/*
* Copyright (c) 2015 MediaTek Inc.
* Author: Honghui Zhang <honghui.zhang@mediatek.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#ifndef _MT2701_LARB_PORT_H_
diff --git a/include/dt-bindings/memory/mt8173-larb-port.h b/include/dt-bindings/memory/mt8173-larb-port.h
index 111b4b0..a62bfeb 100644
--- a/include/dt-bindings/memory/mt8173-larb-port.h
+++ b/include/dt-bindings/memory/mt8173-larb-port.h
@@ -1,15 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
/*
* Copyright (c) 2015-2016 MediaTek Inc.
* Author: Yong Wu <yong.wu@mediatek.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#ifndef __DTS_IOMMU_PORT_MT8173_H
#define __DTS_IOMMU_PORT_MT8173_H
diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
index 5201e90..2b410d2 100644
--- a/include/soc/mediatek/smi.h
+++ b/include/soc/mediatek/smi.h
@@ -1,15 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
/*
* Copyright (c) 2015-2016 MediaTek Inc.
* Author: Yong Wu <yong.wu@mediatek.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#ifndef MTK_IOMMU_SMI_H
#define MTK_IOMMU_SMI_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 related
* [PATCH v4 15/18] iommu/mediatek: Add shutdown callback
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1544258371-4600-1-git-send-email-yong.wu@mediatek.com>
In the reboot burning test, if some Multimedia HW has something wrong,
It may keep send the invalid request to IOMMU. In order to avoid
affect the reboot flow, we add the shutdown callback to disable
M4U HW when shutdown.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index c3b4325..9280031 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -708,6 +708,11 @@ static int mtk_iommu_remove(struct platform_device *pdev)
return 0;
}
+static void mtk_iommu_shutdown(struct platform_device *pdev)
+{
+ mtk_iommu_remove(pdev);
+}
+
static int __maybe_unused mtk_iommu_suspend(struct device *dev)
{
struct mtk_iommu_data *data = dev_get_drvdata(dev);
@@ -785,6 +790,7 @@ static int __maybe_unused mtk_iommu_resume(struct device *dev)
static struct platform_driver mtk_iommu_driver = {
.probe = mtk_iommu_probe,
.remove = mtk_iommu_remove,
+ .shutdown = mtk_iommu_shutdown,
.driver = {
.name = "mtk-iommu",
.of_match_table = of_match_ptr(mtk_iommu_of_ids),
--
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 v4 14/18] iommu/mediatek: Fix VLD_PA_RANGE register backup when suspend
From: Yong Wu @ 2018-12-08 8:39 UTC (permalink / raw)
To: Joerg Roedel, Matthias Brugger, Robin Murphy, Rob Herring
Cc: youlin.pei, devicetree, Nicolas Boichat, arnd, srv_heupstream,
Will Deacon, linux-kernel, Tomasz Figa, iommu, linux-mediatek,
yong.wu, Arvind Yadav, yingjoe.chen, linux-arm-kernel
In-Reply-To: <1544258371-4600-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>
---
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 1a87a1d..c3b4325 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -721,6 +721,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_range = readl_relaxed(base + REG_MMU_VLD_PA_RNG);
clk_disable_unprepare(data->bclk);
return 0;
}
@@ -745,6 +746,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_range, 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 6385dec..17996e0 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -33,6 +33,7 @@ struct mtk_iommu_suspend_reg {
u32 int_control0;
u32 int_main_control;
u32 ivrp_paddr;
+ u32 vld_pa_range;
};
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
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