* [PATCH] arm64: dts: stingray: Add otp device node
From: Scott Branden @ 2018-06-04 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <efaf0373-2959-b238-e5f3-ae7e16534384@gmail.com>
On 18-06-04 02:33 PM, Florian Fainelli wrote:
> On 06/04/2018 02:30 PM, Scott Branden wrote:
>> Hi Florian,
>>
>>
>> On 18-06-04 02:24 PM, Florian Fainelli wrote:
>>> On 05/23/2018 01:17 PM, Scott Branden wrote:
>>>> Add otp device node for Stingray SOC.
>>>>
>>>> Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>> Applied to devicetree-arm64/next with s/otp/OTP/ and removing the Fixes
>>> line since that is not a bug fix AFAICT.
>> It fixes the issue that OTP is not active as it is missing the device node?
> By that token, any peripheral that is being added at some point in the
> lifetime of this DTS would qualify as a bugfix when it is in fact
> feature/peripheral enabling.
>
> I could not see the relationship between the commit being provided in
> the "Fixes:" tag and OTP, am I missing something?
The relationship is the fixes tag points was selected to the last tag
when the commit applies directly against (and is far enough back that it
covers any possible LTS kernels that would have needed it). In this case
I don't care too much about whether this is fixed in LTS or not.? If
needed I'll send a request for the commit be ported to stable.
^ permalink raw reply
* [PATCH] arm64: dts: stingray: Add otp device node
From: Florian Fainelli @ 2018-06-04 22:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e641f180-0b7e-678c-07c4-834ff0676b34@broadcom.com>
On 06/04/2018 03:33 PM, Scott Branden wrote:
>
>
> On 18-06-04 02:33 PM, Florian Fainelli wrote:
>> On 06/04/2018 02:30 PM, Scott Branden wrote:
>>> Hi Florian,
>>>
>>>
>>> On 18-06-04 02:24 PM, Florian Fainelli wrote:
>>>> On 05/23/2018 01:17 PM, Scott Branden wrote:
>>>>> Add otp device node for Stingray SOC.
>>>>>
>>>>> Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>> Applied to devicetree-arm64/next with s/otp/OTP/ and removing the Fixes
>>>> line since that is not a bug fix AFAICT.
>>> It fixes the issue that OTP is not active as it is missing the device
>>> node?
>> By that token, any peripheral that is being added at some point in the
>> lifetime of this DTS would qualify as a bugfix when it is in fact
>> feature/peripheral enabling.
>>
>> I could not see the relationship between the commit being provided in
>> the "Fixes:" tag and OTP, am I missing something?
> The relationship is the fixes tag points was selected to the last tag
> when the commit applies directly against (and is far enough back that it
> covers any possible LTS kernels that would have needed it).
I understand how ones gets to select an appropriate Fixes: tag, what I
don't understand is the relationship between the two changes, like why
would a GPIO Device Tree node influence the OTP peripheral here when
there is no pinmux or GPIO phandle of some sort linking the two. Also,
since you guys were very trigger happy with Fixes: tag lately (referring
to the internal review of Srinath's changes) this one looked a lot like
that.
The only thing I am questioning here is treating that particular
changeset as a bugfix proper. Yes it is technically a fix in that,
without this changeset the OTP node is not there and that is
functionality you want, but it is not preventing the platform from not
booting for instance, or having an incorrect behavior for an established
behavior before, right?
> In this case
> I don't care too much about whether this is fixed in LTS or not.? If
> needed I'll send a request for the commit be ported to stable.
If this is a true fix, I don't mind taking it as-is and keeping the
Fixes: tag, keep in mind the following:
I always treat bug fixes with a higher priority than features, and I
will do my best to queue up fixes (separate branches, all ending in
/fixes) and submit those at any time in the release cycle so they can
land in Linus' tree and in the -stable trees as fast as possible.
Don't bypass the maintainer if you can convince me this is a proper fix,
then I will just move that patch into the appropriate branch, and you
will get those stable backports automatically.
Thanks for reading me.
--
Florian
^ permalink raw reply
* [PATCH] arm64: dts: stingray: Add otp device node
From: Scott Branden @ 2018-06-04 23:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2d6cc541-7987-5b4c-a847-6fcbb27e12d2@gmail.com>
On 18-06-04 03:41 PM, Florian Fainelli wrote:
> On 06/04/2018 03:33 PM, Scott Branden wrote:
>>
>> On 18-06-04 02:33 PM, Florian Fainelli wrote:
>>> On 06/04/2018 02:30 PM, Scott Branden wrote:
>>>> Hi Florian,
>>>>
>>>>
>>>> On 18-06-04 02:24 PM, Florian Fainelli wrote:
>>>>> On 05/23/2018 01:17 PM, Scott Branden wrote:
>>>>>> Add otp device node for Stingray SOC.
>>>>>>
>>>>>> Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
>>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>> Applied to devicetree-arm64/next with s/otp/OTP/ and removing the Fixes
>>>>> line since that is not a bug fix AFAICT.
>>>> It fixes the issue that OTP is not active as it is missing the device
>>>> node?
>>> By that token, any peripheral that is being added at some point in the
>>> lifetime of this DTS would qualify as a bugfix when it is in fact
>>> feature/peripheral enabling.
>>>
>>> I could not see the relationship between the commit being provided in
>>> the "Fixes:" tag and OTP, am I missing something?
>> The relationship is the fixes tag points was selected to the last tag
>> when the commit applies directly against (and is far enough back that it
>> covers any possible LTS kernels that would have needed it).
> I understand how ones gets to select an appropriate Fixes: tag, what I
> don't understand is the relationship between the two changes, like why
> would a GPIO Device Tree node influence the OTP peripheral here when
> there is no pinmux or GPIO phandle of some sort linking the two. Also,
> since you guys were very trigger happy with Fixes: tag lately (referring
> to the internal review of Srinath's changes) this one looked a lot like
> that.
>
> The only thing I am questioning here is treating that particular
> changeset as a bugfix proper. Yes it is technically a fix in that,
> without this changeset the OTP node is not there and that is
> functionality you want, but it is not preventing the platform from not
> booting for instance, or having an incorrect behavior for an established
> behavior before, right?
>
>> In this case
>> I don't care too much about whether this is fixed in LTS or not.? If
>> needed I'll send a request for the commit be ported to stable.
> If this is a true fix, I don't mind taking it as-is and keeping the
> Fixes: tag, keep in mind the following:
>
> I always treat bug fixes with a higher priority than features, and I
> will do my best to queue up fixes (separate branches, all ending in
> /fixes) and submit those at any time in the release cycle so they can
> land in Linus' tree and in the -stable trees as fast as possible.
>
> Don't bypass the maintainer if you can convince me this is a proper fix,
> then I will just move that patch into the appropriate branch, and you
> will get those stable backports automatically.
For now, nobody needs it in the LTS.? The OTP driver hasn't actively
been used by applications.
So not critical for backport right now.? It's in now so OTP won't be a
problem going forward.
> Thanks for reading me.
^ permalink raw reply
* [PATCH 7/7] regulator: core: Enable voltage balancing
From: kbuild test robot @ 2018-06-04 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528120764-14316-8-git-send-email-m.purski@samsung.com>
Hi Maciej,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on regulator/for-next]
[also build test ERROR on next-20180604]
[cannot apply to v4.17]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Maciej-Purski/regulator-core-Add-debug-messages/20180605-052333
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
config: x86_64-randconfig-x011-201822 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers//regulator/core.c: In function 'regulator_set_voltage_unlocked':
>> drivers//regulator/core.c:3046:1: error: version control conflict marker in file
<<<<<<< HEAD
^~~~~~~
drivers//regulator/core.c:3048:1: error: version control conflict marker in file
=======
^~~~~~~
vim +3046 drivers//regulator/core.c
3035
3036 static int regulator_set_voltage_unlocked(struct regulator *regulator,
3037 int min_uV, int max_uV,
3038 suspend_state_t state)
3039 {
3040 struct regulator_dev *rdev = regulator->rdev;
3041 struct regulator_voltage *voltage = ®ulator->voltage[state];
3042 int ret = 0;
3043 int old_min_uV, old_max_uV;
3044 int current_uV;
3045
> 3046 <<<<<<< HEAD
3047 pr_err("%s: %d\n", __func__, __LINE__);
3048 =======
3049 if (rdev->coupling_desc.n_resolved != rdev->coupling_desc.n_coupled) {
3050 rdev_err(rdev, "not all coupled regulators registered\n");
3051 ret = -EPERM;
3052 goto out;
3053 }
3054
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 34005 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180605/c5e61c9a/attachment-0001.gz>
^ permalink raw reply
* [PATCH 7/7] regulator: core: Enable voltage balancing
From: kbuild test robot @ 2018-06-04 23:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528120764-14316-8-git-send-email-m.purski@samsung.com>
Hi Maciej,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on regulator/for-next]
[also build test ERROR on next-20180604]
[cannot apply to v4.17]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Maciej-Purski/regulator-core-Add-debug-messages/20180605-052333
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
config: i386-randconfig-a1-06041847 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/regulator/core.c: In function 'regulator_set_voltage_unlocked':
>> drivers/regulator/core.c:3046:1: error: expected expression before '<<' token
<<<<<<< HEAD
^
drivers/regulator/core.c:3048:1: error: expected expression before '==' token
=======
^
vim +3046 drivers/regulator/core.c
3035
3036 static int regulator_set_voltage_unlocked(struct regulator *regulator,
3037 int min_uV, int max_uV,
3038 suspend_state_t state)
3039 {
3040 struct regulator_dev *rdev = regulator->rdev;
3041 struct regulator_voltage *voltage = ®ulator->voltage[state];
3042 int ret = 0;
3043 int old_min_uV, old_max_uV;
3044 int current_uV;
3045
> 3046 <<<<<<< HEAD
3047 pr_err("%s: %d\n", __func__, __LINE__);
3048 =======
3049 if (rdev->coupling_desc.n_resolved != rdev->coupling_desc.n_coupled) {
3050 rdev_err(rdev, "not all coupled regulators registered\n");
3051 ret = -EPERM;
3052 goto out;
3053 }
3054
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 26101 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180605/699454b6/attachment-0001.gz>
^ permalink raw reply
* [PATCH v2]irqchip/irq-gic-v3:Avoid a waste of LPI resource
From: Zhang, Lei @ 2018-06-04 23:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8898674D84E3B24BA3A2D289B872026A69F30297@G01JPEXMBKW03>
Hi Marc
Please let me know is there any plan to push your patch to v4.18.
Thanks
Best Regards,
Lei Zhang zhang.lei at fujitsu.com
FUJITSU LIMITED
> -----Original Message-----
> From: linux-arm-kernel
> [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of
> Zhang, Lei
> Sent: Friday, June 01, 2018 10:47 PM
> To: 'Marc Zyngier'; 'linux-arm-kernel at lists.infradead.org'
> Subject: RE: [PATCH v2]irqchip/irq-gic-v3:Avoid a waste of LPI resource
>
> Hi Marc
>
> Thanks. Now I understood the policy of MSI allocation.
> So this patch is great for our bus, and looks no problem for PCI.
>
> Best Regards,
> Lei Zhang zhang.lei at jp.fujitsu.com
> FUJITSU LIMITED
>
> > -----Original Message-----
> > From: Marc Zyngier [mailto:marc.zyngier at arm.com]
> > Sent: Friday, June 01, 2018 9:57 PM
> > To: Zhang, Lei/? ?; 'linux-arm-kernel at lists.infradead.org'
> > Subject: Re: [PATCH v2]irqchip/irq-gic-v3:Avoid a waste of LPI resource
> >
> > Hi Lei,
> >
> > On 01/06/18 13:44, Zhang, Lei wrote:
> > > Hi Marc
> > >
> > > I have reviewed your patch.
> > > I think the approach is same between your patch and mine.
> > > Your patch is simpler and more beautiful, and match our bus's
> > requirement.
> > >
> > > I have only one question.
> > > According your patch, if there are no enough lpis, amount of lpis
> > required
> > > will be divide by 2. it means someone want 16 lpis, maybe they can
> only
> > get 8?
> > > I don?t' understand why we need it.
> >
> > That's the way the MSI allocation works in the kernel.
> >
> > A driver asks a number of MSIs (let's imagine, for example, one MSI
> per
> > CPU in the system), but the underlying HW can only provide a smaller
> > number.
> >
> > Instead of failing and just returning an error, we reduce the allocation
> > in order to provide the driver with something. If that's not enough,
> > well, the driver itself will have the opportunity to give up.
> >
> > See pci_alloc_irq_vectors_affinity(), which takes a min and a max
> number
> > of vectors, for example.
> >
> > Thanks,
> >
> > M.
> > --
> > Jazz is not dead. It just smells funny...
> >
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: imx53-qsb: Let the codec control MCLK pinctrl
From: Fabio Estevam @ 2018-06-05 0:56 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
sgtl5000 codec needs MCLK clock to be present so that it can
successfully read/write via I2C.
In the case of imx53-qsb, MCLK is provided via
MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK pad.
Move the MCLK pinctrl from hog group to the codec group, so that the
codec clock can be present prior to reading the codec ID.
This avoids the following sgtl5000 probe error:
sgtl5000 1-000a: Error reading chip id -6
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx53-qsb-common.dtsi | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx53-qsb-common.dtsi b/arch/arm/boot/dts/imx53-qsb-common.dtsi
index ef7658a..7423d46 100644
--- a/arch/arm/boot/dts/imx53-qsb-common.dtsi
+++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi
@@ -153,7 +153,6 @@
imx53-qsb {
pinctrl_hog: hoggrp {
fsl,pins = <
- MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK 0x80000000
MX53_PAD_GPIO_8__GPIO1_8 0x80000000
MX53_PAD_PATA_DATA14__GPIO2_14 0x80000000
MX53_PAD_PATA_DATA15__GPIO2_15 0x80000000
@@ -180,6 +179,12 @@
>;
};
+ pinctrl_codec: codecgrp {
+ fsl,pins = <
+ MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK 0x1c4
+ >;
+ };
+
pinctrl_esdhc1: esdhc1grp {
fsl,pins = <
MX53_PAD_SD1_DATA0__ESDHC1_DAT0 0x1d5
@@ -310,6 +315,8 @@
sgtl5000: codec@a {
compatible = "fsl,sgtl5000";
reg = <0x0a>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_codec>;
#sound-dai-cells = <0>;
VDDA-supply = <®_3p2v>;
VDDIO-supply = <®_3p2v>;
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: armada388-helios4
From: Dennis Gilmore @ 2018-06-05 1:13 UTC (permalink / raw)
To: linux-arm-kernel
The helios4 is a Armada388 based nas board designed by SolidRun and
based on their SOM. It is sold by kobol.io the dts file came from
https://raw.githubusercontent.com/armbian/build/master/patch/kernel/mvebu-default/95-helios4-device-tree.patch
I added a SPDX license line to match the clearfog it says it was based
on and a compatible line for "solidrun,helios4"
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-388-helios4.dts | 315 +++++++++++++++++++++++
2 files changed, 316 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-388-helios4.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e2424957809..490bfd586198 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1123,6 +1123,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-388-clearfog-pro.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
+ armada-388-helios4.dtb \
armada-388-rd.dtb
dtb-$(CONFIG_MACH_ARMADA_39X) += \
armada-398-db.dtb
diff --git a/arch/arm/boot/dts/armada-388-helios4.dts b/arch/arm/boot/dts/armada-388-helios4.dts
new file mode 100644
index 000000000000..a6d6996e1378
--- /dev/null
+++ b/arch/arm/boot/dts/armada-388-helios4.dts
@@ -0,0 +1,315 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Device Tree file for Helios4
+ * based on SolidRun Clearfog revision A1 rev 2.0 (88F6828)
+ *
+ * Copyright (C) 2017
+ *
+ */
+
+/dts-v1/;
+#include "armada-388.dtsi"
+#include "armada-38x-solidrun-microsom.dtsi"
+
+/ {
+ model = "Helios4";
+ compatible = "solidrun,helios4", "marvell,armada388",
+ "marvell,armada385", "marvell,armada380";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x80000000>; /* 2 GB */
+ };
+
+ aliases {
+ /* So that mvebu u-boot can update the MAC addresses */
+ ethernet1 = ð0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_12v: regulator-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "power_brick_12V";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_hdd: regulator-5v-hdd {
+ compatible = "regulator-fixed";
+ regulator-name = "5V_HDD";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_usb: regulator-5v-usb {
+ compatible = "regulator-fixed";
+ regulator-name = "USB-PWR";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ enable-active-high;
+ gpio = <&expander0 6 GPIO_ACTIVE_HIGH>;
+ vin-supply = <®_12v>;
+ };
+
+ system-leds {
+ compatible = "gpio-leds";
+ status-led {
+ label = "helios4:green:status";
+ gpios = <&gpio0 24 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+
+ fault-led {
+ label = "helios4:red:fault";
+ gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
+ default-state = "keep";
+ };
+ };
+
+ io-leds {
+ compatible = "gpio-leds";
+ sata1-led {
+ label = "helios4:green:ata1";
+ gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata1";
+ default-state = "off";
+ };
+ sata2-led {
+ label = "helios4:green:ata2";
+ gpios = <&gpio1 18 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata2";
+ default-state = "off";
+ };
+ sata3-led {
+ label = "helios4:green:ata3";
+ gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata3";
+ default-state = "off";
+ };
+ sata4-led {
+ label = "helios4:green:ata4";
+ gpios = <&gpio1 21 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata4";
+ default-state = "off";
+ };
+ usb-led {
+ label = "helios4:green:usb";
+ gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "usb-host";
+ default-state = "off";
+ };
+ };
+
+ fan1: j10-pwm {
+ compatible = "pwm-fan";
+ pwms = <&gpio1 9 40000>; /* Target freq:25 kHz */
+ };
+
+ fan2: j17-pwm {
+ compatible = "pwm-fan";
+ pwms = <&gpio1 23 40000>; /* Target freq:25 kHz */
+ };
+
+ usb2_phy: usb2-phy {
+ compatible = "usb-nop-xceiv";
+ vbus-regulator = <®_5p0v_usb>;
+ };
+
+ usb3_phy: usb3-phy {
+ compatible = "usb-nop-xceiv";
+ //vbus-regulator = <®_5p0v_usb>;
+ };
+
+ soc {
+ internal-regs {
+ i2c at 11000 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ /*
+ * PCA9655 GPIO expander, up to 1MHz clock.
+ * 0-Board Revision bit 0 #
+ * 1-Board Revision bit 1 #
+ * 5-USB3 overcurrent
+ * 6-USB3 power
+ */
+ expander0: gpio-expander at 20 {
+ /*
+ * This is how it should be:
+ * compatible = "onnn,pca9655",
+ * "nxp,pca9555";
+ * but you can't do this because of
+ * the way I2C works.
+ */
+ compatible = "nxp,pca9555";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x20>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pca0_pins>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <23 IRQ_TYPE_EDGE_FALLING>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ board_rev_bit_0 {
+ gpio-hog;
+ gpios = <0 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "board-rev-0";
+ };
+ board_rev_bit_1 {
+ gpio-hog;
+ gpios = <1 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "board-rev-1";
+ };
+ usb3_ilimit {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "usb-overcurrent-status";
+ };
+ };
+
+ temp_sensor: temp at 4c {
+ compatible = "ti,lm75";
+ reg = <0x4c>;
+ vcc-supply = <®_3p3v>;
+ };
+ };
+
+ i2c at 11100 {
+ /*
+ * External I2C Bus for user peripheral
+ */
+ clock-frequency = <400000>;
+ pinctrl-0 = <&helios_i2c1_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ sata at a8000 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sata0: sata-port at 0 {
+ reg = <0>;
+ };
+
+ sata1: sata-port at 1 {
+ reg = <1>;
+ };
+ };
+
+ sata at e0000 {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sata2: sata-port at 0 {
+ reg = <0>;
+ };
+
+ sata3: sata-port at 1 {
+ reg = <1>;
+ };
+ };
+
+ spi at 10680 {
+ pinctrl-0 = <&spi1_pins
+ µsom_spi1_cs_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ sdhci at d8000 {
+ bus-width = <4>;
+ cd-gpios = <&gpio0 20 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ pinctrl-0 = <&helios_sdhci_pins
+ &helios_sdhci_cd_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ vmmc = <®_3p3v>;
+ wp-inverted;
+ };
+
+ usb at 58000 {
+ //vcc-supply = <®_5p0v_usb>;
+ usb-phy = <&usb2_phy>;
+ status = "okay";
+ };
+
+ usb3 at f0000 {
+ status = "okay";
+ };
+
+ usb3 at f8000 {
+ status = "okay";
+ };
+
+ pinctrl at 18000 {
+ pca0_pins: pca0-pins {
+ marvell,pins = "mpp23";
+ marvell,function = "gpio";
+ };
+ microsom_phy0_int_pins: microsom-phy0-int-pins {
+ marvell,pins = "mpp18";
+ marvell,function = "gpio";
+ };
+ helios_i2c1_pins: i2c1-pins {
+ marvell,pins = "mpp26", "mpp27";
+ marvell,function = "i2c1";
+ };
+ helios_sdhci_cd_pins: helios-sdhci-cd-pins {
+ marvell,pins = "mpp20";
+ marvell,function = "gpio";
+ };
+ helios_sdhci_pins: helios-sdhci-pins {
+ marvell,pins = "mpp21", "mpp28",
+ "mpp37", "mpp38",
+ "mpp39", "mpp40";
+ marvell,function = "sd0";
+ };
+ helios_led_pins: helios-led-pins {
+ marvell,pins = "mpp24", "mpp25",
+ "mpp49", "mpp50",
+ "mpp52", "mpp53",
+ "mpp54";
+ marvell,function = "gpio";
+ };
+ helios_fan_pins: helios-fan-pins {
+ marvell,pins = "mpp41", "mpp43",
+ "mpp48", "mpp55";
+ marvell,function = "gpio";
+ };
+ microsom_spi1_cs_pins: spi1-cs-pins {
+ marvell,pins = "mpp59";
+ marvell,function = "spi1";
+ };
+ };
+ };
+ };
+};
--
2.17.1
^ permalink raw reply related
* [PATCH 1/6] PCI: iproc: Update iProc PCI binding for INTx support
From: Ray Jui @ 2018-06-05 1:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+ac6dmHKS6m0h5N3bv=VseKVL8XLU5K7j1Rn=mgFNLsA@mail.gmail.com>
Hi Rob/Arnd,
On 6/4/2018 7:17 AM, Rob Herring wrote:
> +Arnd
>
> On Tue, May 29, 2018 at 4:58 PM, Ray Jui <ray.jui@broadcom.com> wrote:
>> Update the iProc PCIe binding document for better modeling of the legacy
>> interrupt (INTx) support
>>
>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>> ---
>> .../devicetree/bindings/pci/brcm,iproc-pcie.txt | 31 +++++++++++++++++-----
>> 1 file changed, 24 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
>> index b8e48b4..7ea24dc 100644
>> --- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
>> +++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
>> @@ -13,9 +13,6 @@ controller, used in Stingray
>> PAXB-based root complex is used for external endpoint devices. PAXC-based
>> root complex is connected to emulated endpoint devices internal to the ASIC
>> - reg: base address and length of the PCIe controller I/O register space
>> -- #interrupt-cells: set to <1>
>> -- interrupt-map-mask and interrupt-map, standard PCI properties to define the
>> - mapping of the PCIe interface to interrupt numbers
>> - linux,pci-domain: PCI domain ID. Should be unique for each host controller
>> - bus-range: PCI bus numbers covered
>> - #address-cells: set to <3>
>> @@ -41,6 +38,16 @@ Required:
>> - brcm,pcie-ob-axi-offset: The offset from the AXI address to the internal
>> address used by the iProc PCIe core (not the PCIe address)
>>
>> +Legacy interrupt (INTx) support (optional):
>> +
>> +Note INTx is for PAXB only.
>> +
>> +- interrupt-controller: claims itself as an interrupt controller for INTx
>> +- #interrupt-cells: set to <1>
>> +- interrupt-map-mask and interrupt-map, standard PCI properties to define
>> +the mapping of the PCIe interface to interrupt numbers
>> +- interrupts: interrupt line wired to the generic GIC for INTx support
>> +
>> MSI support (optional):
>>
>> For older platforms without MSI integrated in the GIC, iProc PCIe core provides
>> @@ -77,9 +84,14 @@ Example:
>> compatible = "brcm,iproc-pcie";
>> reg = <0x18012000 0x1000>;
>>
>> + interrupt-controller;
>> #interrupt-cells = <1>;
>> - interrupt-map-mask = <0 0 0 0>;
>> - interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_NONE>;
>> + interrupt-map-mask = <0 0 0 7>;
>> + interrupt-map = <0 0 0 1 &pcie0 1>,
>
> Are you sure this works? The irq parsing code will ignore
> interrupt-map if interrupt-controller is found. In other words, you
> should have one or the other, but not both.
Yes, it does work. I tested this by using an Intel E1000E PCIe NIC card
installed in our system and have it fall back to INTx.
>
> Maybe it happens to work because "pcie0" is this node and your irq
> numbers are the same.
Perhaps it works because we are claiming "pcie0" as an interrupt
controller by itself and the INTx is modeled under that.
>
> Arnd, any thoughts on this?
>
Please let me know if the above model makes sense or not.
Thanks,
Ray
>> + <0 0 0 2 &pcie0 2>,
>> + <0 0 0 3 &pcie0 3>,
>> + <0 0 0 4 &pcie0 4>;
>> + interrupts = <GIC_SPI 100 IRQ_TYPE_NONE>;
>>
>> linux,pci-domain = <0>;
>>
>> @@ -115,9 +127,14 @@ Example:
>> compatible = "brcm,iproc-pcie";
>> reg = <0x18013000 0x1000>;
>>
>> + interrupt-controller;
>> #interrupt-cells = <1>;
>> - interrupt-map-mask = <0 0 0 0>;
>> - interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_NONE>;
>> + interrupt-map-mask = <0 0 0 7>;
>> + interrupt-map = <0 0 0 1 &pcie1 1>,
>> + <0 0 0 2 &pcie1 2>,
>> + <0 0 0 3 &pcie1 3>,
>> + <0 0 0 4 &pcie1 4>;
>> + interrupts = <GIC_SPI 106 IRQ_TYPE_NONE>;
>>
>> linux,pci-domain = <1>;
>>
>> --
>> 2.1.4
>>
^ permalink raw reply
* [PATCH v5 4/4] ARM: dts: imx: add missing compatible and clock properties for EPIT
From: kbuild test robot @ 2018-06-05 2:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604100035.19558-5-peron.clem@gmail.com>
Hi Colin,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on shawnguo/for-next]
[also build test ERROR on v4.17 next-20180601]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Cl-ment-P-ron/Reintroduce-i-MX-EPIT-Timer/20180604-211036
base: https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git for-next
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> Error: arch/arm/boot/dts/imx6qdl.dtsi:832.21-22 syntax error
FATAL ERROR: Unable to parse input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 23243 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180605/f204908e/attachment-0001.gz>
^ permalink raw reply
* [PATCH V4] PCI: move early dump functionality from x86 arch into the common code
From: Sinan Kaya @ 2018-06-05 2:16 UTC (permalink / raw)
To: linux-arm-kernel
Move early dump functionality into common code so that it is available for
all archtiectures. No need to carry arch specific reads around as the read
hooks are already initialized by the time pci_setup_device() is getting
called during scan.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
arch/x86/include/asm/pci-direct.h | 4 ---
arch/x86/kernel/setup.c | 5 ---
arch/x86/pci/common.c | 4 ---
arch/x86/pci/early.c | 44 -------------------------
drivers/pci/pci.c | 5 +++
drivers/pci/pci.h | 1 +
drivers/pci/probe.c | 19 +++++++++++
8 files changed, 26 insertions(+), 58 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index e490902..e64f1d8 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2995,7 +2995,7 @@
See also Documentation/blockdev/paride.txt.
pci=option[,option...] [PCI] various PCI subsystem options:
- earlydump [X86] dump PCI config space before the kernel
+ earlydump dump PCI config space before the kernel
changes anything
off [X86] don't probe for the PCI bus
bios [X86-32] force use of PCI BIOS, don't access
diff --git a/arch/x86/include/asm/pci-direct.h b/arch/x86/include/asm/pci-direct.h
index e1084f7..94597a3 100644
--- a/arch/x86/include/asm/pci-direct.h
+++ b/arch/x86/include/asm/pci-direct.h
@@ -15,8 +15,4 @@ extern void write_pci_config_byte(u8 bus, u8 slot, u8 func, u8 offset, u8 val);
extern void write_pci_config_16(u8 bus, u8 slot, u8 func, u8 offset, u16 val);
extern int early_pci_allowed(void);
-
-extern unsigned int pci_early_dump_regs;
-extern void early_dump_pci_device(u8 bus, u8 slot, u8 func);
-extern void early_dump_pci_devices(void);
#endif /* _ASM_X86_PCI_DIRECT_H */
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 2f86d88..480f250 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -991,11 +991,6 @@ void __init setup_arch(char **cmdline_p)
setup_clear_cpu_cap(X86_FEATURE_APIC);
}
-#ifdef CONFIG_PCI
- if (pci_early_dump_regs)
- early_dump_pci_devices();
-#endif
-
e820__reserve_setup_data();
e820__finish_early_params();
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 563049c..d4ec117 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -22,7 +22,6 @@
unsigned int pci_probe = PCI_PROBE_BIOS | PCI_PROBE_CONF1 | PCI_PROBE_CONF2 |
PCI_PROBE_MMCONF;
-unsigned int pci_early_dump_regs;
static int pci_bf_sort;
int pci_routeirq;
int noioapicquirk;
@@ -599,9 +598,6 @@ char *__init pcibios_setup(char *str)
pci_probe |= PCI_BIG_ROOT_WINDOW;
return NULL;
#endif
- } else if (!strcmp(str, "earlydump")) {
- pci_early_dump_regs = 1;
- return NULL;
} else if (!strcmp(str, "routeirq")) {
pci_routeirq = 1;
return NULL;
diff --git a/arch/x86/pci/early.c b/arch/x86/pci/early.c
index e5f753c..f5fc953 100644
--- a/arch/x86/pci/early.c
+++ b/arch/x86/pci/early.c
@@ -57,47 +57,3 @@ int early_pci_allowed(void)
PCI_PROBE_CONF1;
}
-void early_dump_pci_device(u8 bus, u8 slot, u8 func)
-{
- u32 value[256 / 4];
- int i;
-
- pr_info("pci 0000:%02x:%02x.%d config space:\n", bus, slot, func);
-
- for (i = 0; i < 256; i += 4)
- value[i / 4] = read_pci_config(bus, slot, func, i);
-
- print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value, 256, false);
-}
-
-void early_dump_pci_devices(void)
-{
- unsigned bus, slot, func;
-
- if (!early_pci_allowed())
- return;
-
- for (bus = 0; bus < 256; bus++) {
- for (slot = 0; slot < 32; slot++) {
- for (func = 0; func < 8; func++) {
- u32 class;
- u8 type;
-
- class = read_pci_config(bus, slot, func,
- PCI_CLASS_REVISION);
- if (class == 0xffffffff)
- continue;
-
- early_dump_pci_device(bus, slot, func);
-
- if (func == 0) {
- type = read_pci_config_byte(bus, slot,
- func,
- PCI_HEADER_TYPE);
- if (!(type & 0x80))
- break;
- }
- }
- }
- }
-}
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 97acba7..04052dc 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -115,6 +115,9 @@ static bool pcie_ari_disabled;
/* If set, the PCIe ATS capability will not be used. */
static bool pcie_ats_disabled;
+/* If set, the PCI config space of each device is printed during boot. */
+bool pci_early_dump;
+
bool pci_ats_disabled(void)
{
return pcie_ats_disabled;
@@ -5805,6 +5808,8 @@ static int __init pci_setup(char *str)
pcie_ats_disabled = true;
} else if (!strcmp(str, "noaer")) {
pci_no_aer();
+ } else if (!strcmp(str, "earlydump")) {
+ pci_early_dump = true;
} else if (!strncmp(str, "realloc=", 8)) {
pci_realloc_get_opt(str + 8);
} else if (!strncmp(str, "realloc", 7)) {
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index c358e7a0..c33265e 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -7,6 +7,7 @@
#define PCI_VSEC_ID_INTEL_TBT 0x1234 /* Thunderbolt */
extern const unsigned char pcie_link_speed[];
+extern bool pci_early_dump;
bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 56771f3..3678f0a 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1545,6 +1545,23 @@ static int pci_intx_mask_broken(struct pci_dev *dev)
return 0;
}
+static void early_dump_pci_device(struct pci_dev *pdev)
+{
+ u32 value[256 / 4];
+ int i;
+
+ if (!pci_early_dump)
+ return;
+
+ pci_info(pdev, "config space:\n");
+
+ for (i = 0; i < 256; i += 4)
+ pci_read_config_dword(pdev, i, &value[i / 4]);
+
+ print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value,
+ 256, false);
+}
+
/**
* pci_setup_device - Fill in class and map information of a device
* @dev: the device structure to fill
@@ -1594,6 +1611,8 @@ int pci_setup_device(struct pci_dev *dev)
pci_printk(KERN_DEBUG, dev, "[%04x:%04x] type %02x class %#08x\n",
dev->vendor, dev->device, dev->hdr_type, dev->class);
+ early_dump_pci_device(dev);
+
/* Need to have dev->class ready */
dev->cfg_size = pci_cfg_space_size(dev);
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: armada388-helios4
From: Baruch Siach @ 2018-06-05 2:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605011343.14999-1-dennis@ausil.us>
Hi Dennis,
On Mon, Jun 04, 2018 at 08:13:43PM -0500, Dennis Gilmore wrote:
> The helios4 is a Armada388 based nas board designed by SolidRun and
> based on their SOM. It is sold by kobol.io the dts file came from
> https://raw.githubusercontent.com/armbian/build/master/patch/kernel/mvebu-default/95-helios4-device-tree.patch
> I added a SPDX license line to match the clearfog it says it was based
> on and a compatible line for "solidrun,helios4"
>
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/armada-388-helios4.dts | 315 +++++++++++++++++++++++
> 2 files changed, 316 insertions(+)
> create mode 100644 arch/arm/boot/dts/armada-388-helios4.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 7e2424957809..490bfd586198 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1123,6 +1123,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
> armada-388-clearfog-pro.dtb \
> armada-388-db.dtb \
> armada-388-gp.dtb \
> + armada-388-helios4.dtb \
> armada-388-rd.dtb
> dtb-$(CONFIG_MACH_ARMADA_39X) += \
> armada-398-db.dtb
> diff --git a/arch/arm/boot/dts/armada-388-helios4.dts b/arch/arm/boot/dts/armada-388-helios4.dts
> new file mode 100644
> index 000000000000..a6d6996e1378
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-388-helios4.dts
> @@ -0,0 +1,315 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Device Tree file for Helios4
> + * based on SolidRun Clearfog revision A1 rev 2.0 (88F6828)
> + *
> + * Copyright (C) 2017
> + *
> + */
> +
> +/dts-v1/;
> +#include "armada-388.dtsi"
> +#include "armada-38x-solidrun-microsom.dtsi"
> +
> +/ {
> + model = "Helios4";
> + compatible = "solidrun,helios4", "marvell,armada388",
SolidRun is not the producer of the Helios4 carrier board. So I think
"kobol,helios4" makes more sense. This is just like the "auvidea,h100"
compatible string for Auvidea H100 which is also using a SolidRun SOM.
baruch
> + "marvell,armada385", "marvell,armada380";
> +
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH 09/10] dpaa_eth: add support for hardware timestamping
From: Y.b. Lu @ 2018-06-05 3:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604134920.ezhe6jz5ntpnqyzj@localhost>
Hi Richard,
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran at gmail.com]
> Sent: Monday, June 4, 2018 9:49 PM
> To: Y.b. Lu <yangbo.lu@nxp.com>
> Cc: netdev at vger.kernel.org; Madalin-cristian Bucur
> <madalin.bucur@nxp.com>; Rob Herring <robh+dt@kernel.org>; Shawn Guo
> <shawnguo@kernel.org>; David S . Miller <davem@davemloft.net>;
> devicetree at vger.kernel.org; linuxppc-dev at lists.ozlabs.org;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org
> Subject: Re: [PATCH 09/10] dpaa_eth: add support for hardware timestamping
>
> On Mon, Jun 04, 2018 at 03:08:36PM +0800, Yangbo Lu wrote:
>
> > +if FSL_DPAA_ETH
> > +config FSL_DPAA_ETH_TS
> > + bool "DPAA hardware timestamping support"
> > + select PTP_1588_CLOCK_QORIQ
> > + default n
> > + help
> > + Enable DPAA hardware timestamping support.
> > + This option is useful for applications to get
> > + hardware time stamps on the Ethernet packets
> > + using the SO_TIMESTAMPING API.
> > +endif
>
> You should drop this #ifdef. In general, if a MAC supports time stamping and
> PHC, then the driver support should simply be compiled in.
>
> [ When time stamping incurs a large run time performance penalty to
> non-PTP users, then it might make sense to have a Kconfig option to
> disable it, but that doesn't appear to be the case here. ]
[Y.b. Lu] Actually these timestamping codes affected DPAA networking performance in our previous performance test.
That's why we used ifdef for it.
>
> > @@ -1615,6 +1635,24 @@ static int dpaa_eth_refill_bpools(struct
> dpaa_priv *priv)
> > skbh = (struct sk_buff **)phys_to_virt(addr);
> > skb = *skbh;
> >
> > +#ifdef CONFIG_FSL_DPAA_ETH_TS
> > + if (priv->tx_tstamp &&
> > + skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) {
>
> This condition fits on one line easily.
[Y.b. Lu] Right. I will use one line in next version.
>
> > + struct skb_shared_hwtstamps shhwtstamps;
> > + u64 ns;
>
> Local variables belong at the top of the function.
[Y.b. Lu] Ok, will move them to the top in next verison.
>
> > + memset(&shhwtstamps, 0, sizeof(shhwtstamps));
> > +
> > + if (!dpaa_get_tstamp_ns(priv->net_dev, &ns,
> > + priv->mac_dev->port[TX],
> > + (void *)skbh)) {
> > + shhwtstamps.hwtstamp = ns_to_ktime(ns);
> > + skb_tstamp_tx(skb, &shhwtstamps);
> > + } else {
> > + dev_warn(dev, "dpaa_get_tstamp_ns failed!\n");
> > + }
> > + }
> > +#endif
> > if (unlikely(qm_fd_get_format(fd) == qm_fd_sg)) {
> > nr_frags = skb_shinfo(skb)->nr_frags;
> > dma_unmap_single(dev, addr, qm_fd_get_offset(fd) + @@ -2086,6
> > +2124,14 @@ static int dpaa_start_xmit(struct sk_buff *skb, struct
> net_device *net_dev)
> > if (unlikely(err < 0))
> > goto skb_to_fd_failed;
> >
> > +#ifdef CONFIG_FSL_DPAA_ETH_TS
> > + if (priv->tx_tstamp &&
> > + skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) {
>
> One line please.
[Y.b. Lu] No problem.
>
> > + fd.cmd |= FM_FD_CMD_UPD;
> > + skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
> > + }
> > +#endif
> > +
> > if (likely(dpaa_xmit(priv, percpu_stats, queue_mapping, &fd) == 0))
> > return NETDEV_TX_OK;
> >
>
> Thanks,
> Richard
^ permalink raw reply
* Common config for N900 and D4
From: Tony Lindgren @ 2018-06-05 4:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180603210115.GA7438@amd>
* Pavel Machek <pavel@ucw.cz> [180603 21:03]:
> Hi!
>
> > > Aaro, I know I have asked before, but if you have common config for
> > > N900 and Droid4, please send me a copy. Yes, it should be somewhere in
> > > my inbox already, but I can't find it and version for v4.17 would be
> > > more useful.
> > >
> > > While trying to came up with common config, I hit:
> > >
> > > [ 0.000000] L2C-310 erratum 727915 enabled
> > > [ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
> > > [ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9
> >
> > I tried disabling outer cache to get rid of this. That got me further
> > in boot, but not to working system:
>
> I now have config that works.
>
> My kernels were probably grossly misconfigured (OMAP4 not enabled on
> droid4)... still I'd expect some kind of panic explaining board is not
> compatible with kernel, not a random oops...
Like "clk-provider not found" error? :) I agree it's not very
descriptive and I think we could easily print something from
after the SoC detection for missing pdata.
Eventually we should just get rid of all ARMv7 Kconfig variants
once most of the hwmod SoC pdata is gone.
Regards,
Tony
^ permalink raw reply
* [PATCH 1/6] arm64: dts: amlogic: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-06-05 4:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180602081418.jcl2vjc6saoj3z3d@localhost>
On 02-06-18, 01:14, Olof Johansson wrote:
> And what I am saying is that it sounds like a broken binding if you don't allow
> that, especially since it'll be a super common case that all CPUs will specify
> the same cooling-device specifier.
I am fine with allowing the #cooling-cells property in the cpus node if the DT
maintainers are fine with it.
@Rob: comments ?
@Olof: What about other properties which are still going to be duplicated for
the most common cases today, like: clocks, supply information, cache
information, cpu-idle-states and others. When we can duplicate these properties,
why not keep following the same for #cpu-cooling property ?
Note that the OPP table doesn't really need to get duplicated (for new
platforms) as the platforms use the v2 bindings now which just duplicates a
phandle assignment for all CPUs. Its a mess with older platforms which use the
earlier version of OPP table.
> > This property is required to declare a device as a cooling-device and
> > the device here is CPU. We use it as a cooling device by limiting its
> > higher range of frequencies, so that it doesn't generate too much
> > heat.
> >
> > It is already there for CPU0 and CPU4, but it should really be there
> > for all the CPUs, like we have clock, supply, caches, etc.
>
> You have #cooling-cells in the cpu node, but the actual data is in the
> thermal-zones nodes. Why isn't #cooling-cells under thermal-zones, next to
> cooling-maps?
Actually I thought about that when I worked on these patches initially and this
is why I felt convinced that the CPU nodes are the right place for this.
We add #interrupt-cells to an Interrupt controller's DT node, #gpio-cells to a
GPIO controller's DT node, #clock-cells to a clock controller's DT node and
that's exactly why we should (and we do) add #cooling-cells property to a
cooling device's DT node. This information is used in two ways, first it enables
the OS to know that the device is capable of being a cooling device and second
it tells us how many arguments will be required with a phandle of this device.
And so the cooling-maps always contain two arguments with the cooling device's
phandle (which is mostly a CPU or a gpio fan) as the #cooling-cells currently
is fixed to 2.
And so I am not really sure if thermal-zones is the right place to define this
thing. Is my understanding correct ?
--
viresh
^ permalink raw reply
* Regression in Linux next again
From: Tony Lindgren @ 2018-06-05 4:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528120764-14316-1-git-send-email-m.purski@samsung.com>
Hi,
* Maciej Purski <m.purski@samsung.com> [180604 14:02]:
> Tony, please apply this patchset and test it on your Beaglebone. It'd be
> great if you could try to find out, which patch causes failure. They should
> be appliable on the current next.
It seems beagle-x15 boots for me except with the last patch in the
series with compile issue fixed. With that applied after modules
get loaded it just hangs with:
[ 25.925607] regulator_resolve_supply: 1608
[ 25.930620] regulator_resolve_supply: 1608
[ 26.098449] lib80211: common routines for IEEE802.11 drivers
[ 26.446713] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 26.514834] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 26.525311] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 26.534250] cfg80211: failed to load regulatory.db
[ 26.998736] regulator_set_voltage: 3381
[ 27.007662] _regulator_do_set_voltage: 2913
[ 27.012593] regulator_set_voltage: 3381
[ 27.016969] _regulator_do_set_voltage: 2913
[ 27.022847] regulator_set_voltage: 3381
Not sure what module gets loaded at that point, I'll test again
with initcall_debug once you post a compiling version of your last
patch.
Regards,
Tony
^ permalink raw reply
* [PATCH V2 1/2] arm: dts: sun8i-h3: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-06-05 4:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601151701.sshwfdbflic6mybv@flea>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Fix other missing properties (clocks, clock-names) as well to make it all
work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
V2: Separated patch for h3.
arch/arm/boot/dts/sun8i-h3.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 41d57c76f290..9dff6887923c 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -84,21 +84,30 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <1>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
cpu at 2 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <2>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
cpu at 3 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <3>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [PATCH V2 2/2] arm: dts: sunxi: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-06-05 4:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d894f425b7c32bce4dc4a982db8f4dface2db31d.1528173943.git.viresh.kumar@linaro.org>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Fix other missing properties (clocks, OPP, clock latency) as well to
make it all work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
V2:
- Separated patch for h3
- Fixed subject s/sun/sunxi/
arch/arm/boot/dts/sun6i-a31.dtsi | 30 ++++++++++++++++++++++++++++++
arch/arm/boot/dts/sun7i-a20.dtsi | 13 +++++++++++++
arch/arm/boot/dts/sun8i-a33.dtsi | 9 +++++++++
3 files changed, 52 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index c72992556a86..debc0bf22ea3 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -119,18 +119,48 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <1>;
+ clocks = <&ccu CLK_CPU>;
+ clock-latency = <244144>; /* 8 32k periods */
+ operating-points = <
+ /* kHz uV */
+ 1008000 1200000
+ 864000 1200000
+ 720000 1100000
+ 480000 1000000
+ >;
+ #cooling-cells = <2>;
};
cpu at 2 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <2>;
+ clocks = <&ccu CLK_CPU>;
+ clock-latency = <244144>; /* 8 32k periods */
+ operating-points = <
+ /* kHz uV */
+ 1008000 1200000
+ 864000 1200000
+ 720000 1100000
+ 480000 1000000
+ >;
+ #cooling-cells = <2>;
};
cpu at 3 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <3>;
+ clocks = <&ccu CLK_CPU>;
+ clock-latency = <244144>; /* 8 32k periods */
+ operating-points = <
+ /* kHz uV */
+ 1008000 1200000
+ 864000 1200000
+ 720000 1100000
+ 480000 1000000
+ >;
+ #cooling-cells = <2>;
};
};
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index e529e4ff2174..35372a0cfc8d 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -122,6 +122,19 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <1>;
+ clocks = <&ccu CLK_CPU>;
+ clock-latency = <244144>; /* 8 32k periods */
+ operating-points = <
+ /* kHz uV */
+ 960000 1400000
+ 912000 1400000
+ 864000 1300000
+ 720000 1200000
+ 528000 1100000
+ 312000 1000000
+ 144000 1000000
+ >;
+ #cooling-cells = <2>;
};
};
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 8d278ee001e9..4e92741b24a7 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -132,21 +132,30 @@
};
cpu at 1 {
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
cpu at 2 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <2>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
cpu at 3 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <3>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
operating-points-v2 = <&cpu0_opp_table>;
+ #cooling-cells = <2>;
};
};
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* [RFC PATCH 0/6] arm64: Initial support Texas Instrument's AM654 Platform
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The following series enables support for newest addition in TI's SoC
portfolio - AM654 SoC.
The series is an RFC based off next-20180604 and will post formally once
v4.18-rc1 is available.
The series (part 1 of 4) is available here:
https://github.com/nmenon/linux-2.6-playground/commits/upstream/next-20180604/k3-1-am6-base
Full Boot log is available here: https://pastebin.ubuntu.com/p/vWCzMKtBCW/
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.
The Linux development follows closely the 66AK2G SoC model in aarch64.
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
Lokesh Vutla (1):
serial: 8250_omap: Make 8250_omap driver driver depend on ARCH_K3
Nishanth Menon (5):
Documentation: arm: ti: Add bindings for AM654 SoC
arm64: Add support for TI's K3 Multicore SoC architecture
serial: 8250_omap: Add support for AM654 UART controller
arm64: dts: ti: Add Support for AM654 SoC
arm64: dts: ti: Add support for AM654 EVM base board
Documentation/devicetree/bindings/arm/ti/k3.txt | 33 +++++
.../devicetree/bindings/serial/omap_serial.txt | 1 +
MAINTAINERS | 9 ++
arch/arm64/Kconfig.platforms | 7 +
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/ti/Makefile | 9 ++
arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 +++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 40 ++++++
arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 +++++++++++++++++
drivers/soc/ti/Kconfig | 14 ++
drivers/tty/serial/8250/8250_omap.c | 1 +
drivers/tty/serial/8250/Kconfig | 2 +-
12 files changed, 377 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt
create mode 100644 arch/arm64/boot/dts/ti/Makefile
create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am654-base-board.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi
--
2.15.1
^ permalink raw reply
* [RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605060125.9518-1-nm@ti.com>
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.
Some highlights of this SoC are:
* Quad ARMv8 A53 cores split over two clusters
* GICv3 compliant GIC500
* Configurable L3 Cache and IO-coherent architecture
* Dual lock-step capable R5F uC for safety-critical applications
* High data throughput capable distributed DMA architecture under NAVSS
* Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
* Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
* Centralized System Controller for Security, Power, and Resource
management.
* Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
* Flash subystem with OSPI and Hyperbus interfaces
* Multimedia capability with CAL, DSS7-UL, SGX544, McASP
* Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
GPIO
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Documentation/devicetree/bindings/arm/ti/k3.txt | 33 +++++++++++++++++++++++++
MAINTAINERS | 7 ++++++
2 files changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.txt b/Documentation/devicetree/bindings/arm/ti/k3.txt
new file mode 100644
index 000000000000..cbabb1b89f6f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/ti/k3.txt
@@ -0,0 +1,33 @@
+Texas Instruments K3 Multicore SoC architecture device tree bindings
+--------------------------------------------------------------------
+
+Boards based on K3 Multicore SoC architecture shall have the following property:
+- compatible: Every hardware block introduced in K3 Multicore SoC
+ architecture shall be of the form:
+ "ti,XXX-YYY", where:
+ 'XXX' represents the specific SoC part for which the support is added.
+ 'YYY' represents the corresponding peripheral in SoC being supported.
+
+ NOTE: Generic devices such as GIC or legacy devices shall use the specified
+ compatible for those devices.
+
+ Example:
+ compatible = "ti,am654-i2c";
+
+SoCs
+-------------------------------------------
+
+Each device tree root node must specify which exact SoC in K3 Multicore SoC
+architecture it uses, using one of the following compatible values:
+
+- AM654
+ compatible = "ti,am654";
+
+Boards
+-------------------------------------------
+
+In addition, each device tree root node must specify which one or more
+of the following board-specific compatible values:
+
+- AM654 EVM
+ compatible = "ti,am654-evm", "ti,am654";
diff --git a/MAINTAINERS b/MAINTAINERS
index f39a8de1bbd7..cfb35b252ac7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2086,6 +2086,13 @@ L: linux-kernel at vger.kernel.org
S: Maintained
F: drivers/memory/*emif*
+ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE
+M: Tero Kristo <t-kristo@ti.com>
+M: Nishanth Menon <nm@ti.com>
+L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S: Supported
+F: Documentation/devicetree/bindings/arm/ti/k3.txt
+
ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
M: Santosh Shilimkar <ssantosh@kernel.org>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 2/6] arm64: Add support for TI's K3 Multicore SoC architecture
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605060125.9518-1-nm@ti.com>
Add support for Texas Instrument's K3 Multicore SoC architecture
processors.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm64/Kconfig.platforms | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index d5aeac351fc3..52df25bf4f8c 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -71,6 +71,13 @@ config ARCH_EXYNOS
help
This enables support for ARMv8 based Samsung Exynos SoC family.
+config ARCH_K3
+ bool "Texas Instruments Inc. K3 multicore SoC architecture"
+ select PM_GENERIC_DOMAINS if PM
+ help
+ This enables support for Texas Instruments' K3 multicore SoC
+ architecture.
+
config ARCH_LAYERSCAPE
bool "ARMv8 based Freescale Layerscape SoC family"
select EDAC_SUPPORT
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605060125.9518-1-nm@ti.com>
AM654 uses a UART controller that is compatible (partially) with
existing 8250 UART, however, has a few differences with respect to DMA
support and control paths. Introduce a base definition that allows us
to build up the differences in follow on patches.
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Vignesh R <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
drivers/tty/serial/8250/8250_omap.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 4b0f05adb228..c35d5ece1156 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -1,6 +1,7 @@
OMAP UART controller
Required properties:
+- compatible : should be "ti,am654-uart" for AM654 controllers
- compatible : should be "ti,omap2-uart" for OMAP2 controllers
- compatible : should be "ti,omap3-uart" for OMAP3 controllers
- compatible : should be "ti,omap4-uart" for OMAP4 controllers
diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 1b337fee07ed..a019286f8bb6 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1115,6 +1115,7 @@ static const u8 am3352_habit = OMAP_DMA_TX_KICK | UART_ERRATA_CLOCK_DISABLE;
static const u8 dra742_habit = UART_ERRATA_CLOCK_DISABLE;
static const struct of_device_id omap8250_dt_ids[] = {
+ { .compatible = "ti,am654-uart" },
{ .compatible = "ti,omap2-uart" },
{ .compatible = "ti,omap3-uart" },
{ .compatible = "ti,omap4-uart", .data = &omap4_habit, },
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 4/6] serial: 8250_omap: Make 8250_omap driver driver depend on ARCH_K3
From: Nishanth Menon @ 2018-06-05 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605060125.9518-1-nm@ti.com>
From: Lokesh Vutla <lokeshvutla@ti.com>
Allow 8250 omap serial driver to be used for K3 platforms.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
drivers/tty/serial/8250/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index f005eaf8bc57..15c2c5463835 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -375,7 +375,7 @@ config SERIAL_8250_RT288X
config SERIAL_8250_OMAP
tristate "Support for OMAP internal UART (8250 based driver)"
- depends on SERIAL_8250 && ARCH_OMAP2PLUS
+ depends on SERIAL_8250 && (ARCH_OMAP2PLUS || ARCH_K3)
help
If you have a machine based on an Texas Instruments OMAP CPU you
can enable its onboard serial ports by enabling this option.
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
From: Nishanth Menon @ 2018-06-05 6:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <=<20180605060125.9518-1-nm@ti.com>
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.
Some highlights of this SoC are:
* Quad ARMv8 A53 cores split over two clusters
* GICv3 compliant GIC500
* Configurable L3 Cache and IO-coherent architecture
* Dual lock-step capable R5F uC for safety-critical applications
* High data throughput capable distributed DMA architecture under NAVSS
* Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
* Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
* Centralized System Controller for Security, Power, and Resource
management.
* Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
* Flash subystem with OSPI and Hyperbus interfaces
* Multimedia capability with CAL, DSS7-UL, SGX544, McASP
* Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
GPIO
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
We introduce the Kconfig symbol for the SoC along with this patch since
it is logically relevant point, however the usage is in subsequent
patches.
NOTE: AM654 is the first of the device variants, hence we introduce a
generic am6.dtsi.
Signed-off-by: Benjamin Fair <b-fair@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
MAINTAINERS | 1 +
arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 +++++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 ++++++++++++++++++++++++++++
drivers/soc/ti/Kconfig | 14 ++++
4 files changed, 276 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index cfb35b252ac7..5f5c4eddec7a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2092,6 +2092,7 @@ M: Nishanth Menon <nm@ti.com>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/arm/ti/k3.txt
+F: arch/arm64/boot/dts/ti/k3-*
ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
M: Santosh Shilimkar <ssantosh@kernel.org>
diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi b/arch/arm64/boot/dts/ti/k3-am6.dtsi
new file mode 100644
index 000000000000..cdfa12173aac
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi
@@ -0,0 +1,144 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM6 SoC Family
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ model = "Texas Instruments K3 AM654 SoC";
+ compatible = "ti,am654";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 = &wkup_uart0;
+ serial1 = &mcu_uart0;
+ serial2 = &main_uart0;
+ serial3 = &main_uart1;
+ serial4 = &main_uart2;
+ };
+
+ chosen { };
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+
+ psci: psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+ };
+
+ soc0: soc0 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ a53_timer0: timer-cl0-cpu0 {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
+ };
+
+ pmu: pmu {
+ compatible = "arm,armv8-pmuv3";
+ /* Recommendation from GIC500 TRM Table A.3 */
+ interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ gic: interrupt-controller at 1800000 {
+ compatible = "arm,gic-v3";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ /*
+ * NOTE: we are NOT gicv2 backward compat, so no GICC,
+ * GICH or GICV
+ */
+ reg = <0x0 0x01800000 0x0 0x10000>, /* GICD */
+ <0x0 0x01880000 0x0 0x90000>; /* GICR */
+
+ /*
+ * vcpumntirq:
+ * virtual CPU interface maintenance interrupt
+ */
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+
+ gic_its: gic-its at 1000000 {
+ compatible = "arm,gic-v3-its";
+ reg = <0x0 0x1820000 0x0 0x10000>;
+ msi-controller;
+ #msi-cells = <1>;
+ };
+ };
+
+ wkup_uart0: serial at 42300000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x0 0x42300000 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 697 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ mcu_uart0: serial at 40a00000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x0 0x40a00000 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 565 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <96000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ main_uart0: serial at 2800000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x0 0x02800000 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ main_uart1: serial at 2810000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x0 0x02810000 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ main_uart2: serial at 2820000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x0 0x02820000 0x0 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am654.dtsi b/arch/arm64/boot/dts/ti/k3-am654.dtsi
new file mode 100644
index 000000000000..d9b70081daba
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am654.dtsi
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM6 SoC family in Quad core configuration
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include "k3-am6.dtsi"
+
+/ {
+ cpus: cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu-map {
+ cluster0: cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+
+ core1 {
+ cpu = <&cpu1>;
+ };
+ };
+
+ cluster1: cluster1 {
+ core0 {
+ cpu = <&cpu2>;
+ };
+
+ core1 {
+ cpu = <&cpu3>;
+ };
+ };
+ };
+
+ cpu0: cpu at 0 {
+ compatible = "arm,cortex-a53","arm,armv8";
+ reg = <0x000>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_0>;
+ };
+
+ cpu1: cpu at 1 {
+ compatible = "arm,cortex-a53","arm,armv8";
+ reg = <0x001>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_0>;
+ };
+
+ cpu2: cpu at 100 {
+ compatible = "arm,cortex-a53","arm,armv8";
+ reg = <0x100>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_1>;
+ };
+
+ cpu3: cpu at 101 {
+ compatible = "arm,cortex-a53","arm,armv8";
+ reg = <0x101>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_1>;
+ };
+ };
+};
+
+&soc0 {
+ L2_0: l2-cache0 {
+ compatible = "cache";
+ cache-level = <2>;
+ cache-size = <0x80000>;
+ cache-line-size = <64>;
+ cache-sets = <512>;
+ next-level-cache = <&msmc_l3>;
+ };
+
+ L2_1: l2-cache1 {
+ compatible = "cache";
+ cache-level = <2>;
+ cache-size = <0x80000>;
+ cache-line-size = <64>;
+ cache-sets = <512>;
+ next-level-cache = <&msmc_l3>;
+ };
+
+ msmc_l3: l3-cache0 {
+ compatible = "cache";
+ cache-level = <3>;
+ };
+};
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index 92770d84a288..be4570baad96 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -1,3 +1,17 @@
+# 64-bit ARM SoCs from TI
+if ARM64
+
+if ARCH_K3
+
+config ARCH_K3_AM6_SOC
+ bool "K3 AM6 SoC"
+ help
+ Enable support for TI's AM6 SoC Family support
+
+endif
+
+endif
+
#
# TI SOC drivers
#
--
2.15.1
^ permalink raw reply related
* [RFC PATCH 6/6] arm64: dts: ti: Add support for AM654 EVM base board
From: Nishanth Menon @ 2018-06-05 6:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605060510.32473-1-nm@ti.com>
The EValuation Module(EVM) platform for AM654 consists of a
common Base board + one or more of daughter cards, which include:
a) "Personality Modules", which can be specific to a profile, such as
ICSSG enabled or Multi-media (including audio).
b) SERDES modules, which may be 2 lane PCIe or two port PCIe + USB2
c) Camera daughter card
d) various display panels
Among other options. There are two basic configurations defined which
include an "EVM" configuration and "IDK" (Industrial development kit)
which differ in the specific combination of daughter cards that are
used.
To simplify support, we choose to support just the base board as the
core device tree file and all daughter cards would be expected to be
device tree overlays.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
MAINTAINERS | 1 +
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/ti/Makefile | 9 ++++++
arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 40 ++++++++++++++++++++++++++
4 files changed, 51 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/Makefile
create mode 100644 arch/arm64/boot/dts/ti/k3-am654-base-board.dts
diff --git a/MAINTAINERS b/MAINTAINERS
index 5f5c4eddec7a..4491a0f0625f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2092,6 +2092,7 @@ M: Nishanth Menon <nm@ti.com>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/arm/ti/k3.txt
+F: arch/arm64/boot/dts/ti/Makefile
F: arch/arm64/boot/dts/ti/k3-*
ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 3543bc324553..4690364d584b 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -23,5 +23,6 @@ subdir-y += rockchip
subdir-y += socionext
subdir-y += sprd
subdir-y += synaptics
+subdir-y += ti
subdir-y += xilinx
subdir-y += zte
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
new file mode 100644
index 000000000000..63e619d0b5b8
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Make file to build device tree binaries for boards based on
+# Texas Instruments Inc processors
+#
+# Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+#
+
+dtb-$(CONFIG_ARCH_K3_AM6_SOC) += k3-am654-base-board.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
new file mode 100644
index 000000000000..d227d792de60
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+
+#include "k3-am654.dtsi"
+
+/ {
+ compatible = "ti,am654-evm", "ti,am654";
+ model = "Texas Instruments AM654 Base Board";
+
+ chosen {
+ stdout-path = "serial2:115200n8";
+ bootargs = "earlycon=ns16550a,mmio32,0x02800000";
+ };
+
+ memory at 80000000 {
+ device_type = "memory";
+ /* 4G RAM */
+ reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
+ <0x00000008 0x80000000 0x00000000 0x80000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ secure_ddr: secure_ddr at 9e800000 {
+ reg = <0 0x9e800000 0 0x01800000>; /* for OP-TEE */
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+};
+
+&main_uart0 {
+ status = "okay";
+};
--
2.15.1
^ 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